V4.4 Scope defined (part 2)

.dockerignore

@@ -0,0 +1,13 @@
+.git
+.gitignore
+.vscode
+.venv
+.pytest_cache
+.ruff_cache
+__pycache__/
+*.py[cod]
+*.db
+.env
+tests/
+docs/
+uploads/

.env.example

@@ -1,8 +1,54 @@
-PROVIDER=openrouter
-OPENROUTER_API_KEY=sk-or-...
-# PROVIDER_MODEL=          # optional: OpenRouter adapter supplies default
+# --- NiceGUI Server ---
+# HOST=`0.0.0.0` (default)
+# PORT=8000 (default)
+# LOG_LEVEL: [`critical`, `error`, `warning`, `info` (default), `debug`, `trace`]
+# RELOAD=false (default)
+
+# --- AI provider ---
+# PROVIDER=[`openrouter`(default), `google_genai`] 
+PROVIDER=openrouter
+# OPENROUTER_API_KEY - Required when `PROVIDER=openrouter`
+OPENROUTER_API_KEY=your-api-key-goes-here
+# GEMINI_API_KEY - Required when `PROVIDER=google_genai`
+# PROVIDER_MODEL= specify model. If left blank OpenRouter will supply default.
+PROVIDER_MODEL=google/gemini-2.5-flash
 # OPENROUTER_HTTP_REFERER=https://example.com
-# OPENROUTER_APP_TITLE=Historical Transcription MVP
-# DATABASE_URL=sqlite:///./transcription.db
-# UPLOAD_DIR=./uploads
-# PROMPT_DIR=./prompts
+# OPENROUTER_APP_TITLE="Google: Gemini 2.5 Flash (openrouter)"
+
+# --- runtime environment ---
+# ENVIRONMENT: [`development`(default), `test`, `production`]
+
+# --- persistence ---
+# Use nested settings with double underscore because env_nested_delimiter="__".
+# SQLite example:
+# DATABASE__DRIVER=sqlite
+# DATABASE__PATH=app.db
+#
+# SQLite with custom relative path:
+# DATABASE__DRIVER=sqlite
+DATABASE__PATH=./data/transcription.db
+#
+# Postgres example:
+# DATABASE__DRIVER=postgres
+# DATABASE__HOST=localhost
+# DATABASE__PORT=5432
+# DATABASE__DATABASE=transcription
+# DATABASE__USER=postgres
+# DATABASE__PASSWORD=change-me
+#
+# Optional persistence flags:
+# BOOTSTRAP_SCHEMA_ON_STARTUP=false
+# SQLITE_CHECK_SAME_THREAD=false
+
+# --- filesystem paths ---
+UPLOAD_DIR="./data"
+PROMPT_DIR="./prompts"
+
+# --- worker reliability ---
+WORKER_MAX_RETRIES=0
+WORKER_RETRY_BACKOFF_SECONDS=0
+# WORKER_PROVIDER_TIMEOUT_SECONDS=[0-20]
+WORKER_PROVIDER_TIMEOUT_SECONDS=20
+WORKER_MIN_TRANSCRIPTION_CHARS=0
+WORKER_MIN_TRANSCRIPTION_LINES=0
+WORKER_FAIL_ON_FINISH_REASON_LENGTH=false

.github/instructions/services.instructions.md

@@ -0,0 +1,77 @@
+---
+description: Follow these guidelines when editing the services
+applyTo: 'src/transcription/services/*.py'
+---
+
+# Services
+
+## Structure
+
+- Project core data models defined in [models](../../src/transcription/models.py)
+- 1 service class per data model
+- Only services directly interact with the database, and only through async methods
+- Services are completely independent of one another. Any operation that needs to use more than a single service, which is most of them, needs to have a separate orchestration function.
+
+## Error Handling
+
+- Service-specific errors defined at the top of the respective module and inherit from `AppError`
+- Use a context manager for large `try/except` blocks like in [transcription](../../src/transcription/services/transcription.py)
+
+## Checklist
+
+- [ ] Uses `ServiceBase` for common logic
+- [ ] CRUD methods created at the top
+- [ ] Session kwarg for `AsyncSession` to pass in a session object to each method
+- [ ] Services use `self._session_scope` in their methods to pass the session thru.
+    - Multiple operations on the same object(s) require sharing a session between all the methods used.
+
+## CRUD Methods
+
+- Create, read, update, and delete, created in that order
+- Name format `<operation>_<model >`, for example `create_document` or `update_job`
+- All services must define these 4 methods first, and in that order
+
+## Transaction Finalization
+
+When a service method accepts an optional `session` kwarg, write methods must use `self._finalize` to finalize the transaction properly according to whether or not they are sharing a session.
+
+- If `session` is `None`: the method owns the transaction and should `commit()`.
+- If `session` is provided: the method must **not** commit; it should `flush()` so IDs and FK values are available to the caller's transaction.
+- Use `refresh()` on returned ORM objects when the caller needs DB-populated values (defaults, triggers, merged state).
+
+Recommended helper behavior:
+
+- Inputs: active session object, original `session` arg (or a boolean ownership flag), and an optional list of objects to refresh.
+- Logic: `commit` when service-owned session, `flush` when caller-owned session, then refresh requested objects.
+
+This keeps orchestration functions atomic: they can pass one shared session across multiple services and commit exactly once at the workflow boundary.
+
+## Workflow Transaction Boundaries
+
+For multi-step job lifecycles (for example queued transcription jobs), orchestration functions must use explicit transaction phases.
+
+Required boundary model:
+
+- **Transaction A (claim):** transition `JobStatus.QUEUED -> JobStatus.PROCESSING` and commit immediately.
+- Perform provider/network work **outside** database transactions.
+- **Transaction B (terminal success):** write transcript content and set `JobStatus.TRANSCRIBED` in the same shared-session commit.
+- **Transaction B (terminal failure):** write transcript error detail and set `JobStatus.FAILED` in the same shared-session commit.
+- **Transaction C (retry path):** write transcript error detail, increment retry count, and set `JobStatus.QUEUED` in one shared-session commit.
+
+Atomicity rules:
+
+- Never commit transcript updates separately from the paired terminal/retry job status change.
+- Terminal state (`TRANSCRIBED` or `FAILED`) and transcript row changes must succeed or roll back together.
+- Retry persistence (`QUEUED` + retry increment + error detail) must succeed or roll back together.
+
+Separation of concerns:
+
+- Worker modules should stay lightweight and delegate lifecycle transitions to service/workflow orchestration functions.
+- In `workflows.py`, `process_queued_job` should own one complete attempt lifecycle: `QUEUED -> PROCESSING -> TRANSCRIBED|FAILED`.
+- In `workflows.py`, `advance_job` should coordinate broader status progression around attempts (for example retry scheduling from `FAILED -> QUEUED`).
+- Services should expose session-aware write helpers (flush on caller-owned session) so orchestration controls commit boundaries.
+- Backoff/sleep behavior must run outside transactional scopes.
+
+# Service Composition
+
+Some operations, like uploading a picutre, require modifications to multiple tables, which can be done by composing methods from the service object into a separate function.

.github/instructions/ui.instructions.md

@@ -0,0 +1,53 @@
+---
+description: "Use when modifying the NiceGUI application under src/transcription/ui. Defines ownership and dependency boundaries for UI registration, pages, components, services, persistence, state, and static assets."
+applyTo: 'src/transcription/ui/**/*.py'
+---
+
+# UI Conceptual Boundaries
+
+Keep dependencies flowing in this direction:
+
+`ui/__init__.py` -> `pages` -> `components`
+
+Pages may depend on application services and framework-provided dependencies. Components may depend on smaller components and shared presentation helpers. Services and domain modules must never depend on the UI.
+
+## Package Root
+
+- Keep `ui/__init__.py` as the UI composition root: register global assets, register pages, and mount NiceGUI on FastAPI.
+- Do not put feature rendering, service calls, persistence, or route-specific state in the package root.
+
+## Pages
+
+- Pages own route registration and route-level orchestration.
+- Resolve request or application dependencies, call [services](../../src/transcription/services/), adapt returned data for presentation when needed, and coordinate refresh, navigation, and notifications here.
+- Do not query, mutate, commit, or roll back the database from a page. Do not import database engines, sessions, operations, or query-building APIs. Persistence belongs to services or workflow functions.
+- Framework dependency types may cross into page handlers only to construct or invoke services; do not pass sessions or session factories into components.
+- Keep business rules, lifecycle transitions, transaction boundaries, and cross-service workflows out of page callbacks.
+
+## Components
+
+- Components own reusable rendering, widget-local state, input normalization, and presentation-only formatting.
+- Expose user actions through typed callback parameters. The calling page decides which service or workflow runs and what refresh or navigation follows.
+- Do not register routes, resolve request/app state, instantiate services, or access persistence from components.
+- Components may accept ORM models returned by services as read-only snapshots. Only use fields and relationships that the service loaded eagerly; never mutate models, trigger lazy loading, or expose session behavior.
+- A component may compose lower-level components, but it must not import from `pages`.
+
+## Shared UI Infrastructure
+
+- Keep app-wide navigation and layout primitives in `components/app_shell.py`.
+- Keep generic table/event adaptation in `components/table/common.py`; feature-specific columns, row read models, and formatting belong in the feature table module.
+- Keep exception normalization and user-facing error display in `components/error_presenter.py`; preserve `AppError` details and operation identifiers at page/component boundaries.
+
+## CSS Assets
+
+- Keep all application CSS in `ui/static/theme.css`; do not add page- or component-specific stylesheets or embed style blocks in Python components.
+- Load `theme.css` once from the composition root with `ui.add_css(..., shared=True)`.
+- Read stylesheet text through `importlib.resources.files(...)` so loading works from installed packages and is independent of the working directory.
+- Centralize CSS reading in one typed helper cached by resource path with `functools.cache` or an equivalent unbounded `lru_cache`. Cache the immutable stylesheet text to avoid repeated resource I/O; keep NiceGUI registration at the composition root.
+- Do not encode application behavior in CSS or other static assets.
+
+## State and Side Effects
+
+- Limit component state to ephemeral interaction state such as loading flags, form values, dialogs, and expansion state.
+- Application and worker state must be resolved at the page or application boundary and passed through narrow interfaces such as callbacks or notifier protocols.
+- Keep filesystem, network, provider, and worker orchestration behind application services or dedicated adapters. UI code may trigger those operations but must not implement them.

.gitignore

@@ -14,3 +14,10 @@ wheels/
 
 # SQLite database
 *.db
+
+# Document images
+uploads/*
+data/*
+
+# Local destructive-test backups
+.test-backups/

.vscode/launch.json

@@ -0,0 +1,23 @@
+{
+    "version": "0.2.0",
+    "configurations": [
+        {
+            "name": "Python: Debug transcription app",
+            "type": "debugpy",
+            "request": "launch",
+            "module": "debugpy",
+            "args": [
+                "-m",
+                "transcription",
+                "--host", "127.0.0.1",
+                "--port", "9999",
+                "--database.driver", "sqlite"
+            ],
+            "justMyCode": true,
+            "console": "integratedTerminal",
+            "env": {
+                "PYTHONPATH": "${workspaceFolder}/src"
+            }
+        }
+    ]
+}

.vscode/settings.json

@@ -0,0 +1,3 @@
+{
+    "chat.sessionSync.enabled": true
+}

Dockerfile

@@ -0,0 +1,47 @@
+FROM python:3.12-slim AS builder
+
+ENV PYTHONDONTWRITEBYTECODE=1 \
+    PYTHONUNBUFFERED=1 \
+    UV_LINK_MODE=copy
+
+WORKDIR /app
+
+COPY --from=ghcr.io/astral-sh/uv:0.5.24 /uv /uvx /bin/
+
+COPY pyproject.toml uv.lock README.md ./
+RUN uv sync --frozen --no-dev --no-install-project
+
+COPY src ./src
+COPY prompts ./prompts
+RUN uv sync --frozen --no-dev
+
+
+FROM python:3.12-slim AS runtime
+
+ENV PYTHONDONTWRITEBYTECODE=1 \
+    PYTHONUNBUFFERED=1 \
+    PATH="/app/.venv/bin:$PATH" \
+    PYTHONPATH="/app/src" \
+    UPLOAD_DIR="/app/uploads" \
+    PROMPT_DIR="/app/prompts"
+
+WORKDIR /app
+
+RUN groupadd --system --gid 1001 appgroup \
+    && useradd --system --uid 1001 --gid appgroup --create-home appuser
+
+COPY --from=builder /app/.venv /app/.venv
+COPY --from=builder /app/src /app/src
+COPY --from=builder /app/prompts /app/prompts
+
+RUN mkdir -p /app/uploads /app/data \
+    && chown -R appuser:appgroup /app
+
+USER appuser
+
+EXPOSE 8000
+
+HEALTHCHECK --interval=30s --timeout=3s --start-period=3s --retries=3 \
+    CMD python -c "import urllib.request; urllib.request.urlopen('http://localhost:8000/healthz')"
+
+CMD ["uvicorn", "transcription.app:create_app", "--factory", "--host", "0.0.0.0", "--port", "8000", "--proxy-headers"]

README.md

@@ -22,73 +22,105 @@ uv sync
 
 ### 2) Configure environment
 
-Create a `.env` file in the project root (minimum required setting shown):
+Create a `.env` file in the project root with the required OpenRouter API key:
 
 ```env
 OPENROUTER_API_KEY=your_openrouter_api_key
 ```
 
-Optional settings (defaults shown):
+Settings are read from CLI arguments first, then environment variables, then `.env`, then the defaults below.
+
+### Configuration Source Precedence
+
+When the same setting is provided in multiple places, the value is chosen in this order (highest priority first):
+
+1. CLI arguments (for example `--port 9999`)
+2. Settings constructor arguments (used mainly in tests)
+3. Environment variables
+4. `.env` file values
+5. Model defaults in code
+
+Practical examples:
+
+- `--port 9999` overrides both `PORT=8000` in the shell and `PORT=7000` in `.env`.
+- `DATABASE__PATH=prod.db` in the shell overrides `DATABASE__PATH=dev.db` in `.env`.
+
+#### Server and runtime
+
+| Environment variable | Default | Description |
+| --- | --- | --- |
+| `HOST` | `0.0.0.0` | Address on which the server listens. |
+| `PORT` | `8000` | Server port. |
+| `LOG_LEVEL` | `info` | Uvicorn and application log level. |
+| `RELOAD` | `false` | Restart the development server when source files change. |
+| `ENVIRONMENT` | `development` | Runtime environment: `development`, `test`, or `production`. |
+
+#### Provider
+
+| Environment variable | Default | Description |
+| --- | --- | --- |
+| `PROVIDER` | `openrouter` | Transcription provider. |
+| `OPENROUTER_API_KEY` | Required | OpenRouter API key. |
+| `PROVIDER_MODEL` | Provider default | Optional model override. |
+| `OPENROUTER_HTTP_REFERER` | Unset | Optional OpenRouter attribution URL. |
+| `OPENROUTER_APP_TITLE` | Unset | Optional OpenRouter attribution title. |
+
+#### Database and files
+
+Use nested env vars for database settings (recommended):
 
 ```env
-DATABASE_URL=sqlite:///./transcription.db
+DATABASE__DRIVER=sqlite
+DATABASE__PATH=app.db
+# BOOTSTRAP_SCHEMA_ON_STARTUP=true
+SQLITE_CHECK_SAME_THREAD=false
 UPLOAD_DIR=./uploads
 PROMPT_DIR=./prompts
-MAX_UPLOAD_BYTES=15728640
-OPERATOR_ACCESS_ENABLED=false
-OPERATOR_USERNAME=operator
-# OPERATOR_PASSWORD=replace_with_secure_value
+DEFAULT_PROMPT_NAME=transcribe_document.md
+# TRANSCRIPTION_TEMPERATURE=0.2  # range: 0.0-2.0
+# TRANSCRIPTION_TOP_P=0.9       # range: 0.0-1.0
 ```
 
+For PostgreSQL:
+
+```env
+DATABASE__DRIVER=postgres
+DATABASE__HOST=localhost
+DATABASE__PORT=5432
+DATABASE__DATABASE=transcription
+DATABASE__USER=postgres
+DATABASE__PASSWORD=change-me
+```
+
+This uses Pydantic nested settings (`env_nested_delimiter='__'`) and avoids JSON blobs in `.env`. A top-level `DATABASE={...}` JSON value is still supported as a fallback, and nested keys such as `DATABASE__PATH` take precedence over conflicting JSON keys.
+
+`BOOTSTRAP_SCHEMA_ON_STARTUP` creates missing tables when the app starts. When unset, it is enabled in `development` and `test`, and disabled in `production`; set it explicitly to override that policy. `SQLITE_CHECK_SAME_THREAD` defaults to `false`.
+
+#### Worker
+
+```env
+WORKER_MAX_RETRIES=0
+WORKER_RETRY_BACKOFF_SECONDS=0
+WORKER_PROVIDER_TIMEOUT_SECONDS=20
+WORKER_MIN_TRANSCRIPTION_CHARS=0
+WORKER_MIN_TRANSCRIPTION_LINES=0
+WORKER_FAIL_ON_FINISH_REASON_LENGTH=false
+```
 
 ### 3) Run the app
 
 ```bash
-uv run uvicorn transcription.app:create_app --factory --reload
+uv run python -m transcription --port 9999 --reload --database.driver sqlite --bootstrap-schema-on-startup
 ```
 
-### 4) (Optional) Run explicit migrations/checks
+This starts the development server with SQLite, creates missing tables, and enables automatic reload. Run `uv run python -m transcription --help` for all CLI options; CLI names use kebab case and nested database options use dot notation, such as `--database.path ./data/transcription.db`.
 
-Use the migration runner for Step 4 schema safety workflows:
-
-```bash
-uv run python -m transcription.migration_runner --list
-uv run python -m transcription.migration_runner --apply
-uv run python -m transcription.migration_runner --check
-```
-
-### 5) Open in browser
-
-
-- GUI: [http://[IP_ADDRESS]:8000/ui](http://[IP_ADDRESS]:8000/ui)
-- Health check: [http://[IP_ADDRESS]:8000/healthz](http://[IP_ADDRESS]:8000/healthz)
-
-### Schema safety settings
-
-Optional environment settings (defaults shown):
-
-```env
-MIGRATION_AUTO_APPLY_ON_STARTUP=false
-VALIDATE_SCHEMA_ON_STARTUP=true
-```
-
-### Step 5 security settings
-
-Use this baseline for trusted private-network operation:
-
-```env
-OPERATOR_ACCESS_ENABLED=true
-OPERATOR_USERNAME=operator
-OPERATOR_PASSWORD=replace_with_strong_local_secret
-MAX_UPLOAD_BYTES=15728640
-```
-
-Notes:
-- `/healthz` remains unauthenticated for operational checks.
-- `/ui` and `/api` require HTTP Basic credentials when operator access is enabled.
-- Keep `OPERATOR_PASSWORD` in environment variables only (never commit secrets).
+### 4) Open in browser
 
+- GUI: [http://localhost:9999/ui](http://localhost:9999/ui)
+- Health check: [http://localhost:9999/healthz](http://localhost:9999/healthz)
 
+Replace `localhost` with the server's hostname or IP address when connecting from another machine.
 
 ## How to navigate the GUI
 
@@ -109,7 +141,65 @@ Notes:
 
 ## Prompt artifacts
 
-Prompt files are stored in `prompts/` and loaded from `PROMPT_DIR` (default: `./prompts`).
+Prompt files are stored directly in `PROMPT_DIR` (default: `./prompts`). `DEFAULT_PROMPT_NAME` must be a filename,
+not a path. Each job snapshots the validated prompt text, SHA-256 hash, and sampling values for reproducibility.
 
 The canonical MVP prompt is:
 - `prompts/transcribe_document.md`
+
+## Destructive test procedure (with data backup)
+
+AI execution policy: before the first unit-test run in a test/fix cycle, create one backup of `./data`. Reuse that same backup for every subsequent test run in the cycle. After tests succeed, always pause and ask whether to restore now.
+
+Use the cross-platform Python wrapper below whenever an AI agent runs tests against this repository.
+
+1. Create one backup of `./data` and mark it as the active test-cycle backup.
+2. Run your test command.
+3. On failure, fix the errors and run the wrapper again; it reuses the active backup and never backs up post-test data.
+4. On success, always prompt whether to restore now (do not auto-restore unless explicitly approved).
+5. Close the cycle only by restoring the active backup or explicitly accepting the current data.
+
+Preflight behavior:
+
+- Backup preflight is warning-only when `data/transcription.db` appears in use.
+- Restore preflight is blocking: the script prompts you to close conflicting applications, then type `retry` to re-check or `cancel` to skip restore.
+
+### Run with confirmation-gated restore (default)
+
+```bash
+uv run python tools/run_destructive_tests.py -- pytest tests/services/test_job_service.py tests/ui/test_jobs_page.py
+```
+
+After tests pass, the script asks whether to restore backup immediately.
+
+This is the required default mode for AI-assisted test runs because it gives time to verify and accept code changes before any restoration happens.
+
+### Run with automatic restore (non-interactive)
+
+```bash
+uv run python tools/run_destructive_tests.py --auto-restore -- pytest
+```
+
+### Run without terminal prompt (decide restore later)
+
+```bash
+uv run python tools/run_destructive_tests.py --skip-restore-prompt -- pytest
+```
+
+This keeps both the current post-test state and the backup, so restore can be decided explicitly later.
+
+Repeated wrapper invocations reuse the backup recorded in `.test-backups/.active-backup`. If that backup is missing, the wrapper stops rather than creating a replacement from potentially destructive post-test data.
+
+### Restore later from a saved backup
+
+```bash
+uv run python tools/run_destructive_tests.py --restore-from data-backup-YYYYMMDD-HHMMSS
+```
+
+To keep the current data and close the active cycle without restoring:
+
+```bash
+uv run python tools/run_destructive_tests.py --accept-current-data
+```
+
+Backups are stored in `.test-backups/` and ignored by git.

docker-compose.yml

@@ -0,0 +1,21 @@
+services:
+  transcription:
+    build:
+      context: .
+      dockerfile: Dockerfile
+    container_name: transcription-app
+    env_file:
+      - .env
+    environment:
+      DATABASE_URL: sqlite:////app/data/transcription.db
+      UPLOAD_DIR: /app/uploads
+      PROMPT_DIR: /app/prompts
+    ports:
+      - "8002:8000"
+    volumes:
+      - ./uploads:/app/uploads
+      - transcription_data:/app/data
+    restart: unless-stopped
+
+volumes:
+  transcription_data:

docs/Intent.md

@@ -1,40 +0,0 @@
-# Historical Document Transcription
-I have several thousand pages of family history told through letters, postcards, books, and other documents that I want to transcribe to text. 
-
-## Goals
-1. Preserve our family history
-2. Unburden my family (and descendants) from having to store and care for the physical media. Once the documents have been transcribed and organized, they can be donated (or kept by a family member that wants to retain them).
-3. Make the text easily available and searchable by family members, as well as AI (which may have different requirements).
-4. Ability create timelines or assemble the historical record of the family or specific individuals from across the complete document archive. Perhaps use AI to create the timelines in a more narrative form.
-
-## Source material
-1. **letters, cards, diaries** - handwritten; mostly stored in tubs, with little organization
-2. **books** - typed or typeset; mostly self-published books 50-100 pages in length. This may be expanded to include selected pages from other publications.
-3. **newspaper clippings, event programs, invitations, and other ephemera**
-
- ## Methodology
-### Verbatim vs. Clean Copy
-Transcriptions should be Verbatim and follow scholarly research guidelines, with no modifications to the original text.
-
-### Prompt Curation Policy
-Transcription behavior should be implemented with prompt assets that are human-maintainable over time.
-
-1. Each transcription prompt is stored as an individual Markdown file.
-2. Prompt files are refined iteratively as document quality and edge cases are discovered.
-3. Prompt changes should be scoped to one prompt file at a time whenever possible to keep review history clear.
-
-### Potential Document Issues
-| Document Issue | How to Handle It | Example |
-| :--- | :--- | :--- |
-| **Misspellings & Errors** | Retain original spelling and insert italicized `[sic]` directly after the error. | `The weather was very cold and publick [sic] business delayed.` |
-| **Missing Words / Slips** | Insert the missing word inside square brackets to restore basic readability. | `We went [to] the store to buy supplies.` |
-| **Uncertain / Guesswork** | Place your best hypothesis followed by a question mark inside square brackets. | `He went to [Boston?] yesterday to meet the governor.` |
-| **Completely Illegible** | Use a clear descriptive term like `[illegible]` or specify the reason (e.g., `[torn]`, `[ink blot]`). | `The total cost was [illegible] dollars.` or `The letter ends here [remainder of page torn].` |
-| **Crossed-out Text** | Wrap the removed word or phrase in a deleted tag to preserve the author's edits. | `We left at [deleted: noon] one o'clock instead.` |
-| **Squeezed-in Text** | Wrap text that was added above the line or in a tight space in an inserted tag. | `The [inserted: red] house on the hill was abandoned.` |
-| **Superscripts & Abbreviations** | Bring raised letters down to the main line, or optionally expand them in brackets. | `Change Gen^l to Genl` OR `Change to Gen[era]l depending on project preference.` |
-| **Images / Seals / Signs** | Describe the non-textual element using italicized text inside square brackets. | `[wax notary seal attached here]` or `[sketch of a fort layout]` |
-| **Marginalia / Notes** | Note the spatial transition clearly before transcribing the note itself. | `[written in left margin:] Do not share this with anyone.` |
-| **Line Breaks / Hyphens** | Rejoin words split across a page margin silently, dropping the line-break hyphen. | `Original: "estab- / lishment" becomes "establishment"` |
-| **Ambiguous Capitalization** | Default to modern capitalization rules unless an archaic uppercase letter is clearly intentional. | `If a standard noun like 'Farm' looks randomly capitalized, type 'farm'.` |
-**Hierarchical Outlines** | Preserve exact numbering characters (including lowercase Roman numerals or terminal 'j'). Replicate indentation levels using spaces/tabs. Do not correct math or sequence errors silently. | `I. Main Topic`<br>`&nbsp;&nbsp;a. Sub-point`<br>`&nbsp;&nbsp;b. Next point`<br>`III. [sic] Third Topic` |

docs/adr/ADR-0001-lifespan-owned-runtime-resources.md

@@ -1,35 +0,0 @@
-# ADR-0001: Lifespan-owned runtime resources
-
-- **Status:** accepted
-- **Date:** 2026-06-25
-
-## Context
-
-MVP initialized core runtime resources (database engine and worker dependencies) through module-level globals and startup side effects. `REQ-7` requires lifespan-owned runtime resources with explicit ownership and cleanup.
-
-## Decision
-
-Adopt lifespan-owned runtime resource initialization in `transcription.app`:
-
-1. Initialize database runtime during app lifespan startup.
-2. Store runtime handles on `app.state`.
-3. Pass runtime-owned dependencies (engine) to worker startup.
-4. Dispose runtime resources explicitly during lifespan shutdown.
-
-## Consequences
-
-### Positive
-- Explicit startup and shutdown ownership.
-- Predictable cleanup ordering.
-- Reduced hidden global side effects.
-
-### Tradeoffs
-- Minor wiring complexity in app startup.
-- Some call-sites still support fallback lazy initialization for compatibility.
-
-## Alternatives Considered
-
-1. **Keep module-level global ownership**
-   - Rejected: conflicts with `REQ-7` and increases ambiguity.
-2. **Introduce full async DB stack immediately**
-   - Rejected for Step 1: too broad for architecture-consolidation scope.

docs/adr/ADR-0002-explicit-schema-bootstrap-policy.md

@@ -1,36 +0,0 @@
-# ADR-0002: Explicit schema bootstrap policy
-
-- **Status:** accepted
-- **Date:** 2026-06-25
-
-## Context
-
-MVP called schema bootstrap (`create_all`) on every startup. `REQ-10` requires explicit, opt-in schema bootstrap behavior so normal production startup does not mutate schema.
-
-## Decision
-
-Add environment-aware bootstrap policy:
-
-1. New settings:
-   - `environment`: `development` | `test` | `production`
-   - `bootstrap_schema_on_startup`: optional explicit override
-2. Default behavior:
-   - Development/test: bootstrap enabled
-   - Production: bootstrap disabled
-3. App startup calls `create_all` only when policy evaluates true.
-
-## Consequences
-
-### Positive
-- Production startup behavior is safer and policy-driven.
-- Local development remains simple by default.
-
-### Tradeoffs
-- Deployments now require explicit schema management in production.
-
-## Alternatives Considered
-
-1. **Always bootstrap in all environments**
-   - Rejected: violates `REQ-10` intent.
-2. **Disable bootstrap everywhere immediately**
-   - Rejected: hurts local developer workflow without migration tool replacement yet.

docs/adr/ADR-0003-persistence-baseline-and-transition-path.md

@@ -1,31 +0,0 @@
-# ADR-0003: Persistence baseline and transition path
-
-- **Status:** accepted
-- **Date:** 2026-06-25
-
-## Context
-
-Architecture targets PostgreSQL baseline (optional MongoDB), while MVP currently runs on SQLite by default. V1 needs a clear transition path without destabilizing ongoing work.
-
-## Decision
-
-1. Preserve database URL configurability through centralized settings.
-2. Keep SQLite functional for local dev/test and fast feedback.
-3. Treat PostgreSQL as production baseline target for V1 completion.
-4. Keep persistence access behind `transcription.db` runtime/session access points.
-
-## Consequences
-
-### Positive
-- Clear migration path without immediate broad rewrite.
-- Controlled risk while preserving velocity.
-
-### Tradeoffs
-- Temporary dual-path assumptions (SQLite local vs PostgreSQL target).
-
-## Alternatives Considered
-
-1. **Immediate forced PostgreSQL-only migration**
-   - Rejected: higher short-term disruption risk.
-2. **Remain SQLite-only for V1**
-   - Rejected: inconsistent with architecture and requirement trajectory.

docs/adr/ADR-0004-in-process-worker-topology.md

@@ -1,32 +0,0 @@
-# ADR-0004: In-process worker topology for V1
-
-- **Status:** accepted
-- **Date:** 2026-06-25
-
-## Context
-
-The current system uses an in-process background worker. Architecture docs allow this in foundation stage and permit later hardening (optional external worker/queue).
-
-## Decision
-
-Retain in-process worker topology for V1, with improved lifecycle ownership:
-
-1. Worker starts/stops via app lifespan.
-2. Worker receives runtime-owned DB engine dependency explicitly.
-3. Extension path to external worker remains behind existing service/adapter seams.
-
-## Consequences
-
-### Positive
-- Keeps operational complexity low for personal-scale use.
-- Preserves delivery focus on V1 completion.
-
-### Tradeoffs
-- Throughput/scaling limits remain compared to external queue-based topology.
-
-## Alternatives Considered
-
-1. **Immediate queue/external worker introduction**
-   - Rejected: premature complexity for current scale.
-2. **Ad hoc thread lifecycle management outside lifespan**
-   - Rejected: weaker shutdown guarantees and poorer ownership clarity.

docs/adr/README.md

@@ -1,20 +0,0 @@
-# Architecture Decision Records (ADRs)
-
-This directory records significant architecture decisions for Version 1.
-
-## ADR Format
-
-Each ADR should include:
-
-1. **Status** (`proposed`, `accepted`, `superseded`)
-2. **Context**
-3. **Decision**
-4. **Consequences**
-5. **Alternatives Considered**
-
-## Index
-
-- [ADR-0001: Lifespan-owned runtime resources](ADR-0001-lifespan-owned-runtime-resources.md)
-- [ADR-0002: Explicit schema bootstrap policy](ADR-0002-explicit-schema-bootstrap-policy.md)
-- [ADR-0003: Persistence baseline and transition path](ADR-0003-persistence-baseline-and-transition-path.md)
-- [ADR-0004: In-process worker topology for V1](ADR-0004-in-process-worker-topology.md)

docs/architecture.md

@@ -1,294 +0,0 @@
-# Architecture
-
-This document describes the production architecture of the personal historical-document transcription system. The system is intentionally optimized for single-user operation, low operational overhead, and clean internal boundaries that support future growth without rewrites.
-
-## Architecture Objectives
-
-The production architecture is designed to:
-
-- preserve verbatim family-history source material as searchable text
-- keep operational complexity low for a personal deployment
-- support asynchronous transcription without requiring distributed infrastructure
-- maintain clear module boundaries so extensions can be added incrementally
-
-## Production Scope And Scale
-
-The deployed system targets personal use and a corpus of several thousand documents processed over time. The architecture favors simple, composable building blocks over distributed orchestration.
-
-Current scope includes:
-
-- document upload and metadata capture
-- asynchronous transcription jobs
-- prompt-library driven transcription behavior, with one Markdown file per prompt
-- transcript review and revision history
-- full-text search over accepted transcripts
-- export of transcript data
-
-## Deployment Topology
-
-The production deployment uses [Docker Compose](https://docs.docker.com/compose/) and treats containerized databases as extremely lightweight operational dependencies.
-
-Running [PostgreSQL](https://www.postgresql.org/docs/) in its own container is considered simple by default for this system.
-
-Running [MongoDB](https://www.mongodb.com/docs/) in its own container is also considered simple when document-centric storage is enabled.
-
-Container count is not a hard architectural limit; a three-container deployment (app, PostgreSQL, MongoDB) is an acceptable baseline.
-
-### Baseline Topology (Two Containers)
-
-- one application container
-- one PostgreSQL container
-- embedded background worker execution inside the app process
-
-### Expanded Topology (Three Containers)
-
-- application container
-- PostgreSQL container
-- MongoDB container
-
-No additional queue, scheduler, or search-engine containers are required in the baseline production setup.
-
-## Runtime Architecture
-
-```mermaid
-flowchart LR
-    User[Browser User] --> App[FastAPI + NiceGUI Service]
-    App --> Worker[In-process Background Worker]
-    App --> PG[(PostgreSQL)]
-    App --> MG[(MongoDB Document Store)]
-    Worker --> AI[Transcription Provider]
-    Worker --> PG
-    Worker --> MG
-```
-
-## Runtime Ownership And Startup Policy (V1 Step 1)
-
-The current implementation now uses explicit lifespan-owned runtime resources.
-
-- application lifespan initializes and disposes database runtime resources
-- worker lifecycle is owned by application lifespan startup/shutdown
-- worker receives lifespan-owned database engine dependency explicitly
-- schema bootstrap policy is environment-aware and explicit:
-  - development/test default to bootstrap enabled
-  - production defaults to bootstrap disabled
-  - explicit override is available via configuration
-
-This aligns implementation toward REQ-7 and REQ-10 while preserving personal-scale operational simplicity.
-
-## Layered Module Structure
-
-### Interface Layer
-
-Responsibility:
-
-- HTTP API and UI routes
-- request/response validation
-- status and result presentation
-
-Out of scope:
-
-- business-rule enforcement
-- data-access implementation
-
-### Application Layer
-
-Responsibility:
-
-- upload and job orchestration
-- state transitions and retry policy
-- coordination across domain and infrastructure ports
-
-Out of scope:
-
-- provider-specific protocol details
-- ORM or storage-specific logic
-
-### Domain Layer
-
-Responsibility:
-
-- verbatim transcription policy
-- revision and provenance invariants
-- confidence and annotation semantics
-
-Out of scope:
-
-- web framework concerns
-- database and network I/O
-
-### Infrastructure Layer
-
-Responsibility:
-
-- persistence adapters (PostgreSQL and MongoDB)
-- transcription-provider adapter
-
-Out of scope:
-
-- business policy decisions
-
-## Processing Workflow
-
-Production transcription flow:
-
-1. A user uploads an image or PDF through the UI or API.
-2. The application validates payloads and creates document and job records.
-3. The in-process worker dequeues the job and calls the transcription provider.
-4. The application persists transcript output, confidence metadata, and provenance events.
-5. Job status transitions from queued to processing to transcribed or failed.
-6. The UI and API expose status, revision history, and searchable transcript text.
-
-## Data Model Ownership
-
-System-of-record entities:
-
-- documents and pages
-- transcription jobs and status events
-- transcript revisions
-- provenance metadata
-
-Storage strategy:
-
-- PostgreSQL for relational system-of-record entities
-- MongoDB for document-oriented payloads and large transcription artifacts
-- versioned prompt artifacts stored as individual Markdown files for human editing and refinement
-- in-memory execution state treated as ephemeral
-
-## Transcription Prompt Asset Policy
-
-The production system treats transcription prompts as maintainable content assets.
-
-- each transcription prompt is stored in its own Markdown file
-- prompt files are designed for direct human editing and iterative refinement
-- prompt updates are independent and do not require bundling unrelated prompt changes
-- prompt file identity and revision history are tracked through normal repository version control
-
-## Simplicity Guardrails
-
-The production system enforces these constraints to prevent accidental over-engineering:
-
-- PostgreSQL in a container is treated as a lightweight default dependency
-- MongoDB in a container is treated as a lightweight optional dependency
-- three containers (app, PostgreSQL, MongoDB) is an acceptable simple deployment
-- no dedicated queue or search cluster is introduced without measured need
-- external infrastructure is added only behind existing ports/adapters
-
-## Extension Path
-
-The architecture supports additive growth without changing domain contracts.
-
-### Stage 1: Foundation (Current)
-
-- upload, transcription, review, search, export
-- in-process worker execution
-- single provider adapter
-- app plus PostgreSQL deployment
-
-### Stage 2: Throughput Hardening
-
-- optional MongoDB document-store enablement
-- optional external worker/queue process
-- stronger retry and dead-letter handling
-
-### Stage 3: Intelligence Features
-
-- entity extraction and cross-document linking
-- timeline and narrative assembly
-- optional multi-provider routing
-
-Each stage preserves existing module boundaries and keeps migration risk low.
-
-## Test Strategy
-
-The test strategy is aligned to personal-scale operation with fast, deterministic feedback.
-
-### Unit Tests
-
-- domain transcription rules and annotation behavior
-- revision-history invariants
-- job state-transition logic
-
-### Integration Tests
-
-- repository behavior and transaction boundaries
-- persistence-adapter and provider adapter contract mapping
-- upload-to-persistence roundtrip
-
-### End-to-End Tests
-
-- happy path: upload, transcribe, review, search, export
-- failure path: provider error, retry, surfaced failed status
-
-### CI Execution Model
-
-- fast suite on each push
-- optional slower provider-sandbox checks on scheduled runs
-
-## Risks And Controls
-
-### Runtime Responsiveness
-
-Risk:
-
-- long jobs can reduce responsiveness in a single-process deployment
-
-Control:
-
-- bounded concurrency and visible job status in the UI
-
-### Database Concurrency Limits
-
-Risk:
-
-- contention can appear under sustained concurrent writes in personal-scale infrastructure
-
-Control:
-
-- tuned connection pooling and phased use of MongoDB for document-heavy workloads
-
-### Provider Output Variance
-
-Risk:
-
-- transcription quality varies by document type, handwriting legibility, and image quality
-
-Control:
-
-- first-class human review and immutable revision history
-
-## Technology References
-
-- [FastAPI documentation](https://fastapi.tiangolo.com/)
-- [NiceGUI documentation](https://nicegui.io/documentation)
-- [Docker Compose documentation](https://docs.docker.com/compose/)
-- [PostgreSQL documentation](https://www.postgresql.org/docs/)
-- [MongoDB documentation](https://www.mongodb.com/docs/)
-
-## Related Pages
-
-- [System overview](index.md)
-- [Version 1 plan](ver1/ver1.md)
-- [Version 1 Step 1 plan](ver1/ver1-step1.md)
-- [Version 1 Step 1 results](ver1/ver1-step1-results.md)
-- [Architecture decision records index](adr/README.md)
-
-## Glossary
-
-- Adapter: A component that translates between internal interfaces and external systems such as databases or AI services.
-- Background job: Work executed outside the request/response path so the UI remains responsive.
-- Boundary: A strict separation between modules with different responsibilities.
-- CI (Continuous Integration): Automated test execution for code changes.
-- Contract test: A test that verifies an adapter follows expected input/output behavior at a boundary.
-- Domain layer: The module that contains core business rules and invariants.
-- End-to-end test: A test that validates a full user flow across the running system.
-- Full-text search: Text indexing and querying optimized for natural-language search.
-- In-process worker: A background executor that runs within the same application process.
-- Integration test: A test that verifies interactions between real modules and infrastructure components.
-- MongoDB: A document-oriented database used for flexible, high-variance data structures.
-- Modular monolith: A single deployable application with strongly separated internal modules.
-- Port/Interface: A stable contract used by application/domain code to call infrastructure implementations.
-- Prompt artifact: A single Markdown file that defines one transcription prompt and can be revised independently.
-- Provenance: Metadata that records where generated data came from and how it was produced.
-- Revision history: Versioned record of transcript edits over time.
-- System of record: The authoritative persistent store for canonical data.
-- Vertical slice: A minimal end-to-end feature path spanning UI/API, application logic, and persistence.

docs/error_handling.md

@@ -1,282 +0,0 @@
-# Error Handling
-
-This document defines the canonical error-handling policy for the document transcription system. It is the single source of truth for how errors are classified, surfaced to users, logged for diagnosis, and handled across UI, API, service, worker, and provider boundaries.
-
-## Error Handling Objectives
-
-The production error-handling model is designed to:
-
-- make failures visible to the user in clear, actionable language
-- preserve enough diagnostic detail for fast troubleshooting
-- keep module behavior consistent across all boundaries
-- distinguish expected domain failures from unexpected defects
-- support safe retries for transient failures without hiding persistent faults
-
-## Scope And Authority
-
-This page governs error-handling behavior for:
-
-- UI interactions (NiceGUI pages)
-- API endpoints (FastAPI routes)
-- application services and orchestration logic
-- in-process background worker execution
-- external provider adapters and persistence adapters
-
-If implementation behavior conflicts with this document, this document is authoritative and implementation should be updated.
-
-## Core Principles
-
-- **Clarity first:** user-facing messages should explain what failed in plain language.
-- **Actionability required:** each surfaced error should include a suggested next step.
-- **Safety by default:** internal details are logged; sensitive details are not exposed by default in UI/API.
-- **Consistency across boundaries:** category and structure should remain stable from source to surface.
-- **Fail explicitly:** silent failure is prohibited.
-- **Traceability:** every non-trivial error should be traceable with an error reference ID.
-
-## Error Taxonomy
-
-The system uses stable, implementation-independent categories:
-
-| Category | Definition | Typical Source | Retriable |
-| --- | --- | --- | --- |
-| `validation_error` | Payload or parameter shape/content is invalid | UI/API input validation, service guards | no |
-| `user_input_error` | User-provided artifact is unacceptable though structurally valid | unsupported file type, empty file, oversized upload | sometimes |
-| `not_found_error` | Requested resource does not exist | missing job/document/transcript | no |
-| `conflict_error` | Requested operation violates current state constraints | invalid state transition | no |
-| `external_provider_error` | External AI/provider call fails | upstream HTTP/API/provider failures | sometimes |
-| `infrastructure_transient_error` | Temporary environment issue | network timeout, DB connection reset | yes |
-| `infrastructure_persistent_error` | Non-transient environment issue | missing permissions, misconfiguration | no |
-| `internal_unexpected_error` | Unhandled defect or unknown failure | uncaught exceptions, logic errors | unknown (default no) |
-
-### Classification Rules
-
-- Classification occurs as close as possible to the origin boundary.
-- Provider-specific exceptions must be normalized into taxonomy categories before crossing service boundaries.
-- Unknown exceptions are classified as `internal_unexpected_error` and logged with traceback.
-- Category names are stable contracts and must not be changed casually.
-
-## User-Facing Error Experience Contract
-
-When an error is shown in the GUI, it must include:
-
-1. **Title** (short context, e.g., “Upload failed”)
-2. **Message** (plain-language explanation)
-3. **Suggested action** (explicit next step)
-4. **Error reference ID** (for support/debug traceability)
-5. **Technical details** (optional/collapsible for advanced users)
-
-### UI Message Rules
-
-- Do not expose raw stack traces by default.
-- Do not expose secrets, credentials, connection strings, or filesystem internals unless explicitly in debug tooling.
-- Prefer domain language over implementation language.
-- Use persistent visibility for important failures (dialog/card), not only transient toasts.
-
-### Suggested Action Requirements
-
-Every user-visible error must include a suggested course of action, such as:
-
-- retry the operation
-- check file type/size constraints
-- refresh the jobs page
-- verify environment configuration
-- contact operator with error ID and timestamp
-
-## API Error Response Contract
-
-API errors should return a structured envelope with stable fields:
-
-- `error_id`: short unique reference ID
-- `category`: taxonomy category
-- `message`: safe human-readable summary
-- `suggestion`: recommended next step
-- `details`: optional, only when safe and appropriate
-- `timestamp`: UTC ISO-8601
-
-HTTP status mapping guidance:
-
-- `validation_error`, `user_input_error` -> `400`
-- `not_found_error` -> `404`
-- `conflict_error` -> `409`
-- `external_provider_error` -> `502` or `503` (depending on failure mode)
-- `infrastructure_transient_error` -> `503`
-- `infrastructure_persistent_error` -> `500`
-- `internal_unexpected_error` -> `500`
-
-## Logging And Observability Contract
-
-All logged errors must include, where available:
-
-- `error_id`
-- `category`
-- `operation` (e.g., `upload.submit`, `worker.process_job`, `jobs.refresh`)
-- `exception_type`
-- `job_id`, `document_id` (when relevant)
-- UTC timestamp
-
-Rules:
-
-- Use structured logging fields where practical.
-- Use full traceback for unexpected errors (`internal_unexpected_error`).
-- Log at boundary handoff points to preserve causal trail.
-- Avoid duplicate noisy logging for the same exception at every layer.
-
-## Recovery And Retry Policy
-
-### Retriable Conditions
-
-Retriable failures include:
-
-- transient network/provider timeouts
-- intermittent provider unavailability
-- temporary DB/network interruptions
-
-### Non-Retriable Conditions
-
-Non-retriable failures include:
-
-- invalid file formats
-- missing required data
-- permission/configuration failures
-- deterministic domain conflicts
-
-### Worker Behavior
-
-- The worker must classify and persist failure details consistently.
-- Retries should be bounded by configured limits.
-- Exhausted retries must end in explicit failed status with recorded reason.
-- No infinite retry loops are allowed.
-
-## Boundary-Specific Responsibilities
-
-### UI Layer
-
-Responsibility:
-
-- display user-safe error summaries and suggested actions
-- show persistent error visibility for critical failures
-- include error reference IDs in visible output
-
-Out of scope:
-
-- low-level exception parsing
-- provider-specific protocol interpretation
-
-### API Layer
-
-Responsibility:
-
-- map application exceptions into stable error envelopes and HTTP statuses
-- preserve category and error_id continuity
-
-Out of scope:
-
-- domain-specific remediation logic
-
-### Service Layer
-
-Responsibility:
-
-- classify domain and infrastructure exceptions
-- convert adapter-specific failures into taxonomy categories
-- return deterministic error types to callers
-
-Out of scope:
-
-- presentation formatting for UI
-
-### Worker Layer
-
-Responsibility:
-
-- execute retry policy for retriable failures
-- persist terminal failure details for jobs
-- emit operational logs with category and identifiers
-
-Out of scope:
-
-- direct UI messaging
-
-### Provider Adapter Layer
-
-Responsibility:
-
-- normalize provider SDK/HTTP failures into domain-neutral exceptions
-- preserve raw provider context for logs (safely)
-
-Out of scope:
-
-- choosing user-facing wording
-
-## Error Lifecycle Workflow
-
-Standard lifecycle:
-
-1. Failure occurs at a boundary or operation.
-2. Exception is classified into taxonomy category.
-3. `error_id` is created (or propagated).
-4. Error is logged with required structured fields.
-5. User/API receives safe message + suggested action.
-6. Persistent job/resource state is updated when applicable.
-7. Tests verify contract behavior for the pathway.
-
-## Test Strategy For Error Handling
-
-### Unit Tests
-
-- category classification behavior
-- retry eligibility decisions
-- exception-to-message mapping safety
-
-### Integration Tests
-
-- UI pathways show clear message + suggested action for known failures
-- API returns structured error envelope with expected status/category
-- worker persists failed status and failure detail as required
-
-### Regression Tests
-
-- each previously observed production issue should have a guarding test
-- contract tests must cover adapter error normalization behavior
-
-## Known Failure Patterns And Prescribed Responses
-
-| Pattern | Category | User Message | Suggested Action |
-| --- | --- | --- | --- |
-| Upload payload cannot be parsed by UI handler | `internal_unexpected_error` (until narrowed) | Upload failed due to unexpected processing error | Retry once; if repeated, report error ID and check runtime version compatibility |
-| Unsupported extension | `user_input_error` | File type is not supported | Upload JPG, PNG, TIFF, or PDF |
-| Empty file upload | `validation_error` | Uploaded file is empty | Choose a valid non-empty file and retry |
-| Provider timeout | `external_provider_error` or `infrastructure_transient_error` | Transcription provider timed out | Retry from jobs page; if repeated, check provider status |
-| Job lookup missing | `not_found_error` | Requested job was not found | Refresh jobs list and open a valid job |
-
-## Governance And Update Process
-
-This document is a living policy artifact.
-
-Update this document when:
-
-- new error categories are introduced
-- handling behavior changes at any boundary
-- a production incident reveals missing guidance
-- API/UI error contracts change
-
-Change requirements:
-
-- update this document and associated tests in the same change set
-- preserve taxonomy stability; if changed, document migration impact
-- record noteworthy policy changes in project release notes or changelog
-
-## Related Pages
-
-- [System overview](index.md)
-- [Architecture](architecture.md)
-- [Requirements](requirements.md)
-- [Intent](intent.md)
-
-## Glossary
-
-- Error category: Stable classification used to drive handling, messaging, and status mapping.
-- Error envelope: Structured API payload describing a failure.
-- Error reference ID: Short identifier used to correlate user-visible failure with logs.
-- Retriable error: Failure likely to succeed on a later attempt without code changes.
-- Terminal failure: Failure state after retries are exhausted or retry is not allowed.

docs/index.md

@@ -1,55 +0,0 @@
-## Document Transcription System
-
-This project is a production application for transcribing and preserving historical family documents. It is intentionally designed for personal-scale use, with a simplicity-first architecture that is easy to operate and easy to extend.
-
-## Start Here
-
-Read [architecture.md](architecture.md) first.
-
-Then review [ver1/ver1.md](ver1/ver1.md) for completion scope.
-
-The architecture page is the primary technical reference and defines:
-
-- deployed topology and infrastructure limits
-- module boundaries and dependency flow
-- processing life cycle and data ownership
-- test strategy, risk controls, and extension path
-
-## What The Application Does
-
-At a high level, users upload images of handwritten, typed, or typeset documents, run asynchronous transcription jobs, review and edit transcript revisions, and search across accepted text.
-
-Core capabilities:
-
-- document upload and metadata capture
-- asynchronous transcription with visible job status
-- transcription prompt management with one Markdown file per prompt for human refinement over time
-- revision history for transcript edits
-- full-text search over accepted transcripts
-- export of transcript data
-
-## Production Operating Model
-
-The system runs with minimal operational overhead:
-
-- PostgreSQL in a dedicated Docker container is considered extremely lightweight and simple for this system
-- MongoDB in a dedicated Docker container is also considered extremely lightweight and simple for document-centric persistence
-- a three-container deployment (app, PostgreSQL, MongoDB) is a simple and acceptable baseline
-- no required queue or search-engine containers in the baseline setup
-
-This operating model keeps deployment and maintenance simple while preserving clean boundaries for future scale.
-
-## Documentation Map
-
-- Version 1 implementation plan: [ver1/ver1.md](ver1/ver1.md)
-- Architecture and technical design: [architecture.md](architecture.md)
-- Architecture decision records (ADR index): [adr/README.md](adr/README.md)
-- Runtime and deployment requirements: [requirements.md](requirements.md)
-- Error handling policy and operational guidance: [error_handling.md](error_handling.md)
-- Domain context and transcription policy: [intent.md](intent.md)
-
-## Glossary
-
-- Document-oriented persistence: Storing data as flexible records instead of fixed relational rows.
-- Prompt artifact: A single Markdown file that defines one transcription prompt and is edited independently.
-- System of record: The authoritative persistent store for canonical data.

docs/invariant/ai_evidence_and_provenance.md

@@ -0,0 +1,141 @@
+# Digital Evidence and AI Processing Provenance (Invariant)
+
+## 1. Purpose
+
+This document defines non-negotiable evidence and provenance rules for the transcription application.
+
+The application exists to preserve historical source material and produce useful transcriptions without losing the ability to inspect, reinterpret, or reprocess the evidence later. Provider integrations, model names, schemas, and user interfaces may change; the principles below must remain true.
+
+## 2. Evidence Model
+
+The application distinguishes five kinds of information:
+
+1. **Source evidence**: the original uploaded media and the facts needed to identify and verify it.
+2. **Execution specification**: the frozen instructions, parameters, source identity, and software context for one processing attempt.
+3. **Transport evidence**: the response received at the application/provider boundary, including safe protocol metadata.
+4. **Normalized data**: selected fields extracted for search, display, accounting, and workflow behavior.
+5. **Derived artifacts**: outputs produced from source evidence, such as transcription text, OCR geometry, confidence data, layout analysis, or entity extraction.
+
+Normalized data and derived artifacts never replace source or transport evidence.
+
+## 3. Core Invariants
+
+### 3.1 Original Source Preservation
+
+1. The original uploaded bytes are the primary evidence and must be preserved without transformation.
+2. Each source must have a cryptographic content digest, byte size, and stable identity.
+3. Processing may use transformed derivatives, but those derivatives must not overwrite the original.
+4. A derivative used for processing must record its relationship to the original, its transformation, and its own digest.
+5. Moving or renaming a stored file must not change its evidence identity.
+
+### 3.2 Append-Only Processing History
+
+1. Every processing attempt must have a distinct execution record, whether it succeeds, partially succeeds, times out, or fails.
+2. A later attempt must not overwrite the evidence from an earlier attempt.
+3. A convenient “latest transcription” value may be maintained as a cache or projection, but it is not the authoritative execution history.
+4. Human revisions must remain distinguishable from all machine-generated outputs.
+5. Reprocessing a source must create new evidence rather than rewriting historical evidence.
+
+### 3.3 Frozen Execution Specification
+
+Each execution must preserve enough information to understand what the application asked the processor to do:
+
+1. Requested provider, model, and provider-routing constraints.
+2. Full effective system and user instructions.
+3. Prompt asset name and content digest when a prompt asset is used.
+4. Every explicitly supplied generation or processing parameter.
+5. Whether an optional parameter was explicitly set or omitted.
+6. Source and derivative digests, media type, dimensions or page geometry when known, and page identity.
+7. A secret-safe representation of the request structure.
+8. Application, provider-adapter, and client-library versions sufficient to interpret the execution.
+
+The execution specification must not contain credentials, authorization headers, secret query values, or unnecessary duplicate source binaries.
+
+### 3.4 Evidence-Layer Terminology
+
+The following terms are not interchangeable:
+
+- **Transport response**: the status, safe headers, and exact response body received by the application at its HTTP boundary.
+- **Router-normalized response**: a response transformed by an intermediary into its common schema.
+- **SDK-parsed response**: an object created when a client library validates or filters a response.
+- **Normalized metadata**: application-selected fields derived from a response.
+- **Native provider response**: the upstream provider's own response before any intermediary transformation.
+
+The application and its documentation must identify which layer is stored. A response must not be described as “raw,” “complete,” or “native” without naming the boundary at which that claim is true.
+
+### 3.5 Transport Evidence
+
+1. Preserve the exact successful response body received at the application's transport boundary before SDK model parsing can discard unknown fields.
+2. Preserve the response status and an allowlisted set of non-secret headers needed for correlation, content interpretation, rate-limit diagnosis, or audit.
+3. Preserve provider/router request and generation identifiers when available.
+4. Preserve safe response evidence for unsuccessful calls when a response was received.
+5. Record explicitly when no response was received, such as a local timeout or connection failure.
+6. Retain parsed and normalized forms only as additional representations of the preserved response.
+
+Wire-level packet capture, TLS session data, credentials, and unrestricted headers are neither required nor permitted.
+
+These requirements apply to executions performed after transport capture is implemented. For earlier executions, the absence of transport evidence must be represented explicitly. An SDK snapshot or normalized record must never be relabeled or backfilled as transport evidence.
+
+### 3.6 Derived Artifact Provenance
+
+1. Every derived artifact must identify its source evidence and producing execution.
+2. Each artifact must declare its semantic type, media/serialization format, schema name and version, producer, producer version, and creation time.
+3. Artifact content must be stored directly or referenced by a stable path or object identifier and protected by a cryptographic digest.
+4. Coordinates must declare their coordinate system, units, origin, page/image dimensions, and transformation history.
+5. Confidence values must identify the producer and scope to which they apply; values from different producers must not be treated as directly comparable without validation.
+6. Provider-specific payloads may be retained, but durable application behavior must not depend on undocumented provider fields.
+
+This model must accommodate future OCR text, word or line polygons, layout regions, confidence data, alternate transcriptions, and structured extraction without adding a dedicated column for every possible feature.
+
+### 3.7 Integrity and Auditability
+
+1. Stored evidence must be exportable with enough identifiers and metadata to verify relationships and digests outside the application.
+2. Evidence mutation, deletion, and retention behavior must be explicit and testable.
+3. Schema upgrades must preserve existing evidence and its original meaning.
+4. Backfills must be identified as backfills; they must not imply that previously uncaptured evidence existed.
+5. Integrity verification must distinguish a missing file, digest mismatch, unavailable external artifact, and malformed metadata.
+
+### 3.8 Security and Privacy
+
+1. API keys, authorization headers, cookies, and credentials must never be persisted as provenance.
+2. Persist only headers and metadata fields that appear on an explicit allowlist of known-safe fields. Discard all other fields before storage; never persist an unrestricted capture and attempt to redact it afterward.
+3. Request manifests should reference source content by identity instead of duplicating base64 source data.
+4. Diagnostic displays and exports must avoid exposing secrets or machine-local details that are not necessary for evidence interpretation.
+
+## 4. Reproducibility Limits
+
+Provenance supports explanation, comparison, and best-effort reproduction; it does not guarantee identical output.
+
+Identical requests may produce different results because of model updates, provider routing, nondeterministic computation, undocumented defaults, safety systems, or retired endpoints. The application must preserve whether a parameter was omitted rather than pretending to know the provider default used at that time.
+
+Likewise, preserving a general vision-model response does not create OCR coordinates that were never returned. Future coordinate extraction remains possible because the original source evidence is preserved and can be processed again by a suitable system.
+
+## 5. Model Evaluation Policy
+
+Model selection must be based on a representative sample of the actual archive rather than vendor claims alone.
+
+Evaluation should:
+
+1. Use manually reviewed reference transcriptions following the project's [Transcription Methodology](transcription_methodology.md).
+2. Represent printed, typed, handwritten, degraded, tabular, multilingual, and spatially complex material present in the archive.
+3. Measure character and word error rates where appropriate.
+4. Separately record silent corrections, invented text, omitted text, uncertainty handling, layout fidelity, cost, and latency.
+5. Preserve the exact model, endpoint or route, parameters, prompt, source digest, and scoring method for every comparison.
+6. Treat model rankings as corpus- and version-specific, not permanent declarations of a universal “best” model.
+
+Benchmark material containing family records remains private application data unless explicitly approved for publication.
+
+## 6. Ownership and Change Policy
+
+1. Versioned architecture, schema, scope, and implementation documents define how a release satisfies this invariant.
+2. Provider adapters own the capture of provider-boundary evidence.
+3. Services own validation, persistence, retention, and export behavior.
+4. UI pages may inspect evidence through service contracts but do not define evidence semantics.
+5. If implementation conflicts with this invariant, either correct the implementation or explicitly revise this document before accepting the behavior.
+6. Revisions to this document require deliberate review because they change the long-term preservation contract.
+
+## 7. Related Invariants
+
+- [Historical Document Transcription Design Intent](intent.md)
+- [Transcription Methodology & Style Guide](transcription_methodology.md)
+- [UI Style Guide](ui_style_guide.md)

docs/invariant/error_handling.md

@@ -0,0 +1,101 @@
+# Error Handling (Invariant)
+
+## 1. Purpose
+
+This document defines the non-negotiable failure-handling principles for the transcription application.
+
+Error categories, API envelopes, status codes, framework integrations, and persistence fields may change between versions. Failures must nevertheless remain visible, safe, diagnosable, and consistent across every application boundary.
+
+## 2. Core Invariants
+
+### 2.1 Failures Are Visible
+
+1. An operation must not report success when all or part of the requested work failed.
+2. Invalid input, unavailable dependencies, persistence failures, provider failures, and unexpected defects must be surfaced through the application's established error path.
+3. Code must not silently discard an exception, provider response, invalid value, or failed state transition.
+4. When work can partially succeed, the successful and failed portions must be identified separately.
+
+### 2.2 Messages Are Actionable
+
+1. Operator-facing errors must explain what failed in concise language.
+2. When a safe corrective action is known, the error must state it.
+3. Expected validation or conflict failures must not be presented as unexplained internal defects.
+4. Internal diagnostics must not replace a usable operator-facing message.
+
+### 2.3 Errors Have Stable Identity and Classification
+
+1. Every surfaced failure must have a stable correlation identifier or equivalent trace identity.
+2. Failures must be classified into a documented, machine-readable category.
+3. Boundary-specific representations must preserve the original category and correlation identity.
+4. Unknown exceptions must be converted at an explicit boundary, retain their causal chain for diagnostics, and be classified as unexpected rather than disguised as an expected failure.
+
+### 2.4 Boundary Translation Is Consistent
+
+1. UI, API, service, worker, persistence, and provider boundaries must use one shared error model or deterministic translations between documented models.
+2. A boundary may simplify presentation, but it must not change the meaning, retryability, or identity of a failure.
+3. Domain and service code must not depend on UI notifications or HTTP response types.
+4. UI and API layers must not infer error categories by parsing message text.
+
+### 2.5 State Changes Are Safe
+
+1. A failed atomic operation must leave persisted state unchanged.
+2. Batch operations may preserve successful independent items only when partial success is an explicit part of the workflow contract.
+3. A failed item must retain enough state to identify what was attempted and whether retry is safe.
+4. Error handling must not overwrite earlier successful results or historical execution evidence.
+
+### 2.6 Retry Is Explicit and Bounded
+
+1. Validation, authorization, policy, conflict, and other deterministic failures must not be retried automatically without a relevant input or state change.
+2. Automatic retry is permitted only for failures classified as transient and only when the operation is idempotent or otherwise protected from duplicate effects.
+3. Retry count, delay, and terminal behavior must be bounded and observable.
+4. Exhausted retries must end in a visible terminal failure rather than an indefinitely pending state.
+
+### 2.7 Diagnostics Are Preserved Safely
+
+1. Logs and persisted diagnostic evidence must retain enough context to correlate the failure with the affected operation and record.
+2. Provider and infrastructure failures must preserve safe diagnostic evidence at the boundary where it is available.
+3. Credentials, authorization headers, cookies, secret values, and unnecessary personal data must not appear in errors, logs, notifications, or exports.
+4. Diagnostic metadata capture must use explicit safe-field allowlists where unrestricted content could contain secrets.
+5. User-facing messages must not expose stack traces, local filesystem details, database credentials, or raw internal exceptions.
+
+AI execution failures also follow the evidence rules in [Digital Evidence and AI Processing Provenance](ai_evidence_and_provenance.md).
+
+### 2.8 Cancellation and Timeout Are Distinct Outcomes
+
+1. User cancellation, application shutdown, local timeout, remote timeout, and provider rejection must remain distinguishable.
+2. Cancellation must not be converted into success or a generic unexpected error.
+3. Timeout handling must identify whether a provider response was received when that fact is known.
+4. Cleanup after cancellation or timeout must preserve consistency and must not conceal a completed side effect.
+
+### 2.9 Logging Must Support Audit Without Becoming the Record
+
+1. Structured logs must include correlation identity, operation, category, and relevant non-secret record identifiers.
+2. Expected operator errors may be logged less severely than unexpected defects, but they must remain observable.
+3. Logs are operational diagnostics and do not replace required database state or archival evidence.
+4. Duplicate logging of the same failure at every layer should be avoided; ownership of the authoritative log event must be clear.
+
+## 3. Verification Policy
+
+Each version must verify:
+
+1. Every documented error category reaches the intended UI and API representation.
+2. Failed atomic writes roll back completely.
+3. Partial-success workflows preserve successful independent results and identify failed items.
+4. Retry behavior is bounded and restricted to eligible failures.
+5. Unexpected exceptions retain correlation and causal information without exposing sensitive details.
+6. Logs, persisted evidence, UI messages, and exports contain no credentials.
+7. Cancellation, timeout, provider response failure, and no-response failure remain distinguishable.
+
+## 4. Versioned Ownership
+
+1. Version-specific error taxonomies, envelopes, HTTP mappings, model fields, and framework behavior belong in the applicable version documentation.
+2. Each versioned error-handling document must state how it satisfies this invariant.
+3. A version may add stricter safeguards but must not weaken these principles without first revising this invariant deliberately.
+4. Implementation and tests must be updated together when a versioned error contract changes.
+
+## 5. Related Invariants
+
+- [Historical Document Transcription Design Intent](intent.md)
+- [Digital Evidence and AI Processing Provenance](ai_evidence_and_provenance.md)
+- [UI Style Guide](ui_style_guide.md)
+

docs/invariant/intent.md

@@ -0,0 +1,25 @@
+# Historical Document Transcription Design Intent
+I have several thousand pages of family history told through letters, postcards, books, and other documents that I want to transcribe to text. 
+
+---
+
+## Goals
+1. Preserve our family history
+2. Unburden my family (and descendants) from having to store and care for the physical media. Once the documents have been transcribed and organized, they can be donated (or kept by a family member that wants to retain and preserve them).
+3. Make the document text easily available and easily searchable.
+4. Ability create timelines for individuals and/or families through document dates or the data contained in them. Perhaps even use AI to generate biographies or family histories.
+
+---
+
+## Source material
+1. **letters, cards, diaries** - handwritten; mostly stored in boxes and tubs with little organization
+2. **books** - typed or typeset; mostly self-published books 50-100 pages in length. This may be expanded to include selected pages from other publications.
+3. **photos** - notes written on the backs of photos and the pages of photo albums
+4. **other ephemera** - newspaper clippings, event programs, invitations, military records, immigration records, etc
+
+---
+
+## Methodology
+
+1. Follow current best practices per **A Guide to Documentary Editing** by Mary-Jo Kline. (See [Transcription Methodology](transcription_methodology.md))
+

docs/invariant/transcription_methodology.md

@@ -0,0 +1,54 @@
+# Transcription Methodology & Style Guide
+
+## 1. Overview & Core Philosophy
+
+This document defines the formal transcription standard for processing historical manuscripts, letters, diaries, and printed ephemera.
+
+Following the principles established by Mary-Jo Kline in A Guide to Documentary Editing, this project adheres to a Strict Literal Transcription (Verbatim) model as its foundational layer. The primary goal is total textual fidelity—capturing what the author wrote, not what they intended to write—while ensuring the output remains machine-readable and indexable for downstream digital query and search systems.
+
+## 2. Textual Policy
+
+Transcribers (human or AI) must record the exact text of the source document without silent corrections, modernizations, or stylistic smoothing except where explicitly instructed in this guide.
+
+* **Substantives:** Words, letter forms, structural layout, and semantic content must be recorded strictly as presented in the original document.
+  
+* **Accidentals:** Punctuation, capitalization, misspellings, and archaic character representations must be preserved unless an explicit rule below allows for standardization.
+
+## 3. Standard Transcription Rules & Markup
+
+The following rules map directly to editorial conventions for handling common manuscript anomalies and physical document features.
+
+### 3.1 Textual Anomalies & Corrections
+
+| Document Feature | Rule | Standard Markup Format | Output Example |
+| --- | --- | --- | --- |
+| **Misspellings & Errors** | Retain original spelling verbatim. Insert an italicized [sic] immediately following the error. Do not correct spelling silently. | [sic] | The weather was very cold and publick [sic] business delayed. |
+| **Missing Words / Omissions** | Insert necessary words required to restore basic grammatical sense inside square brackets. | [word] | We went [to] the store to buy supplies. |
+| **Uncertain / Conjectural** | Place best hypothesis followed by a question mark inside square brackets when handwriting is doubtful. | [word?] | He went to [Boston?] yesterday to meet the governor. |
+| **Completely Illegible** | Use [illegible] for unreadable script. Use explicit damage descriptors when physical impairment prevents reading. | [illegible] or [reason] | The total cost was [illegible] dollars. or The letter ends here [remainder of page torn]. |
+| **Canceled / Struck-through** | Wrap text removed by the author inside a [deleted: ...] tag to preserve authorial revisions. | [deleted: text] | We left at [deleted: noon] one o'clock instead. |
+| **Interlineations / Additions** | Wrap text inserted above, below, or in margins into the narrative flow inside an [inserted: ...] tag. | [inserted: text] | The [inserted: red] house on the hill was abandoned. |
+
+### 3.2 Typography, Characters & Layout
+
+| Document Feature | Rule | Standard Markup Format | Output Example |
+| --- | --- | --- | --- |
+| **Superscripts & Abbreviations** | Bring raised letters down to the main line. Optionally expand abbreviations within square brackets based on project configuration. | [expanded] | Gen^l becomes Genl or Gen[era]l. |
+| **Line-End Hyphenation** | Rejoin words split across a page or line boundary silently, dropping the soft hyphen. | Silently rejoin | Original: "estab- / lishment" becomes establishment |
+| **Capitalization** | Preserve explicit capitalization. Default to modern capitalization rules only when authorial intent is ambiguous or archaic forms confuse sentence structure. | Literal / Contextual | If a standard noun like 'Farm' is clearly capitalized, record 'Farm'. If ambiguous, default to 'farm'. |
+| **Hierarchical Outlines** | Preserve exact numbering characters (including lowercase Roman numerals or terminal 'j'). Replicate indentation levels using standard spacing. Do not correct sequence or mathematical errors. | Preserve syntax | I. Main Topic  a. Sub-point  b. Next pointIII. [sic] Third Topic |
+
+### 3.3 Visual & Spatial Elements
+
+| Document Feature | Rule | Standard Markup Format | Output Example |
+| --- | --- | --- | --- |
+| **Non-Textual Artifacts** | Record non-textual elements (seals, stamps, sketches, physical damage) using brief descriptive text inside square brackets. | [description] | [wax notary seal attached here] or [sketch of a fort layout] |
+| **Marginalia & Addenda** | Explicitly indicate spatial transitions before transcribing content located in margins or non-standard orientations. | [location:] | [written in left margin:] Do not share this with anyone. |
+
+## 4. Prompt Asset Integration
+
+When executing programmatic transcriptions via LLM APIs or local models, processing instructions must be packaged into single-purpose system prompts aligned with these rules.
+
+1. **Isolation:** Each transcription prompt file exists as an independent Markdown asset in the repository.
+2. **Deterministic Output:** Prompts must explicitly instruct models to follow the markup standards in Section 3 without introducing conversational wrappers, extra prose, or structural markdown outside the source document's native layout.
+3. **Iterative Scoping:** Rule modifications or edge-case additions must be submitted as isolated delta commits to individual prompt files to maintain clean revision tracking.

docs/invariant/ui_style_guide.md

@@ -0,0 +1,110 @@
+# UI Style Guide (Invariant)
+
+## 1. Purpose
+This guide defines non-negotiable UI styling rules for the transcription application.
+
+The design system is token-first and class-driven:
+1. Theme tokens are defined in [src/transcription/ui/static/theme.css](src/transcription/ui/static/theme.css).
+2. Python UI code composes semantic classes instead of inline color values.
+3. Pages and components should share a single visual language across Documents, Jobs, People, and Sources flows.
+
+## 2. Source of Truth
+Use these files as the style authority:
+1. [src/transcription/ui/static/theme.css](src/transcription/ui/static/theme.css) for color tokens, semantic utility classes, table styles, and viewer surfaces.
+2. [src/transcription/ui/theme.py](src/transcription/ui/theme.py) for runtime NiceGUI theme bridge and shared UI helpers.
+
+If this document conflicts with implementation, update this document to match the code immediately after intentional style changes.
+
+## 3. Core Design Invariants
+1. Flat, high-density surfaces over decorative depth.
+2. Strong content hierarchy with subdued backgrounds and border-based separation.
+3. Viewer area remains the highest contrast region in image/transcription workflows.
+4. Primary actions are consistent and visually recognizable.
+5. Accessible focus rings are always visible for keyboard users.
+
+## 4. Token System
+
+### 4.1 Palette Tokens
+Base palette variables live under :root in [src/transcription/ui/static/theme.css](src/transcription/ui/static/theme.css):
+1. --palette-carbon-black: #1c2321
+2. --palette-cool-steel: #7d98a1
+3. --palette-blue-slate: #5e6572
+4. --palette-powder-blue: #a9b4c2
+5. --palette-platinum: #eef1ef
+
+### 4.2 Semantic Theme Tokens
+Do not style components directly with palette tokens when a semantic token exists.
+
+Semantic tokens currently include:
+1. --theme-text and --theme-text-muted
+2. --theme-page, --theme-surface, --theme-surface-raised, --theme-surface-muted
+3. --theme-border
+4. --theme-primary and --theme-primary-hover
+5. --theme-secondary and --theme-focus
+6. --theme-inverse-text
+7. --theme-viewer, --theme-viewer-border, --theme-viewer-muted
+
+## 5. Approved Semantic Classes
+
+### 5.1 Text and Background
+1. ui-text-primary
+2. ui-text-muted
+3. ui-text-inverse
+4. ui-bg-page
+5. ui-bg-surface
+6. ui-bg-surface-raised
+7. ui-bg-surface-muted
+8. ui-bg-viewer
+9. ui-bg-viewer-overlay
+10. ui-bg-viewer-overlay-soft
+
+### 5.2 Borders and Surfaces
+1. ui-border-subtle
+2. ui-border-viewer
+3. ui-header-divider
+4. ui-card-surface
+5. ui-row-surface
+6. ui-note-box
+7. ui-card-error
+
+### 5.3 Interactive Elements
+1. ui-btn-primary
+2. ui-btn-secondary
+3. ui-link-primary
+4. ui-text-accent
+5. ui-chip-primary
+6. ui-badge-secondary
+7. ui-status and ui-status--<status>
+
+### 5.4 Table Patterns
+1. ui-table
+2. ui-table-header
+3. ui-table-body
+
+Use existing class combinations from [src/transcription/ui/components](src/transcription/ui/components) and [src/transcription/ui/pages](src/transcription/ui/pages) as reference implementations.
+
+## 6. Legacy Class Policy
+Legacy `vibe-` presentation classes are prohibited. Use `ui-` semantic classes from `theme.css`.
+
+## 7. Prohibited Patterns
+1. Inline hex colors in Python UI class strings or style blocks, except in isolated bridge code explicitly marked for migration.
+2. Ad-hoc one-off class names that duplicate existing semantic class intent.
+3. Page-specific palette forks that bypass theme tokens.
+4. Hidden or low-contrast focus states on interactive controls.
+5. Embedded `<style>` blocks or NiceGUI `.style(...)` calls in Python UI code.
+6. Additional page- or component-specific stylesheets; `theme.css` is the single CSS source.
+
+## 8. Implementation Rules For Contributors
+1. Prefer composing existing semantic classes before creating new ones.
+2. If a new class is required, add it to [src/transcription/ui/static/theme.css](src/transcription/ui/static/theme.css) with a semantic name, then reuse it.
+3. Keep behavior ownership in Python and appearance ownership in CSS.
+4. Update UI tests that assert exact text or labels when intentional copy changes are made.
+5. Avoid introducing class churn unrelated to the feature being changed.
+
+## 9. Verification Checklist
+Before merging UI changes, verify:
+1. No new inline hex colors were introduced in UI pages/components.
+2. New styles are token-backed and added to [src/transcription/ui/static/theme.css](src/transcription/ui/static/theme.css).
+3. Primary buttons, links, cards, and tables still render with consistent semantics.
+4. Keyboard focus ring visibility is preserved.
+5. Relevant UI and integration tests pass.

docs/mvp/mvp-step1.md

@@ -1,572 +0,0 @@
-# Step 1 Implementation Plan: `config.py` + `models.py` + `db.py`
-
-## Purpose
-
-Establish the foundational data layer and configuration system that every subsequent MVP step builds on. At the end of this step, the project has a runnable Python package with a validated schema, typed configuration, and a test suite proving the data layer works — before any UI, worker, or AI provider code exists.
-
----
-
-## 1. Prerequisite: Project Structure Scaffolding
-
-Before writing any logic, create the package skeleton so imports work correctly.
-
-### Files to create (empty `__init__.py` stubs)
-
-```
-src/
-└── transcription/
-    ├── __init__.py
-    ├── providers/
-    │   └── __init__.py
-    ├── services/
-    │   └── __init__.py
-    └── ui/
-        └── __init__.py
-```
-
-### Files to create (with logic — the Step 1 deliverables)
-
-```
-src/transcription/config.py
-src/transcription/models.py
-src/transcription/db.py
-```
-
-### Test files to create
-
-```
-tests/
-├── __init__.py
-├── conftest.py
-├── test_config.py
-├── test_models.py
-└── test_db.py
-```
-
-### Update `pyproject.toml`
-
-Add the dependencies that Step 1 requires and won't change later:
-
-```toml pyproject.toml
-[project]
-name = "transcription"
-version = "0.1.0"
-description = "Historical document transcription system"
-readme = "README.md"
-requires-python = ">=3.12"
-dependencies = [
-    "openrouter>=0.7.0",
-    "pydantic>=2.13.4",
-    "pydantic-settings>=2.9.1",
-    "sqlmodel>=0.0.25",
-]
-
-[project.optional-dependencies]
-dev = [
-    "pytest>=8.0",
-    "pytest-asyncio>=0.25",
-]
-
-[tool.pytest.ini_options]
-addopts = "--strict-markers -q"
-markers = [
-    "unit: pure logic tests with no external dependencies",
-    "integration: tests that touch framework or database contracts",
-    "external: tests that call external services (slow, requires credentials)",
-]
-```
-
-Key additions:
-- **`openrouter`** — official OpenRouter Python SDK used for model calls
-- **`pydantic-settings`** — for `BaseSettings` with env-var loading (this was split out of `pydantic` core in v2)
-- **`sqlmodel`** — provides SQLModel (which bundles SQLAlchemy + Pydantic model integration) and the SQLite driver
-- **`pytest` + `pytest-asyncio`** — in `dev` extras for test execution
-- **`[tool.pytest.ini_options]`** — strict marker checking enabled from the start; markers registered upfront per pytesting skill conventions
-
-### Delete `hello.py`
-
-The placeholder file is no longer needed.
-
----
-
-## 2. `config.py` — Centralized Configuration
-
-**Satisfies:** REQ-8 (centralized config and logging at startup)
-
-### Design Decisions
-
-| Decision | Rationale |
-|----------|-----------|
-| Use `pydantic-settings` `BaseSettings` | Type-safe, validates on construction, loads from env vars and `.env` files automatically |
-| `PROVIDER` constrained to `openrouter` for MVP | Keeps configuration explicit while avoiding premature multi-provider complexity |
-| `OPENROUTER_API_KEY` required | Matches official SDK docs and avoids ambiguous provider-agnostic naming |
-| `PROVIDER_MODEL` defaults to `None` | OpenRouter adapter (Step 3) supplies a sensible default when `None` |
-| `OPENROUTER_HTTP_REFERER` and `OPENROUTER_APP_TITLE` optional | Matches SDK optional app-attribution fields |
-| `DATABASE_URL` defaults to SQLite | Zero-setup local development; PostgreSQL swap is a single env-var change post-MVP |
-| `UPLOAD_DIR` and `PROMPT_DIR` as `Path` objects | Enables `.mkdir(parents=True, exist_ok=True)` and path validation at startup |
-| Logging configured via `logging.config.dictConfig` in `setup_logging()` | Centralized, explicit formatter/handler/root logger topology; called once at startup with `disable_existing_loggers=False` |
-
-### Proposed Implementation
-
-```python src/transcription/config.py
-"""Centralized application configuration.
-
-All settings are loaded from environment variables (or a .env file)
-once at startup. Provider-specific defaults (model names, base URLs)
-are resolved by the provider adapters, not here.
-"""
-
-from enum import StrEnum
-from functools import lru_cache
-from pathlib import Path
-import logging
-import logging.config
-
-from pydantic_settings import BaseSettings, SettingsConfigDict
-
-
-class Provider(StrEnum):
-    OPENROUTER = "openrouter"
-
-
-class Settings(BaseSettings):
-    model_config = SettingsConfigDict(
-        env_file=".env",
-        env_file_encoding="utf-8",
-        extra="ignore",
-    )
-
-    # --- AI provider ---
-    provider: Provider = Provider.OPENROUTER
-    openrouter_api_key: str
-    provider_model: str | None = None
-    openrouter_http_referer: str | None = None
-    openrouter_app_title: str | None = None
-
-    # --- persistence ---
-    database_url: str = "sqlite:///./transcription.db"
-
-    # --- filesystem paths ---
-    upload_dir: Path = Path("./uploads")
-    prompt_dir: Path = Path("./prompts")
-
-
-LOGGING_CONFIG: dict[str, object] = {
-    "version": 1,
-    "disable_existing_loggers": False,
-    "formatters": {
-        "standard": {
-            "format": "%(asctime)s | %(levelname)-8s | %(name)s | %(message)s",
-            "datefmt": "%Y-%m-%d %H:%M:%S",
-        }
-    },
-    "handlers": {
-        "console": {
-            "class": "logging.StreamHandler",
-            "formatter": "standard",
-            "stream": "ext://sys.stdout",
-        }
-    },
-    "root": {
-        "level": "INFO",
-        "handlers": ["console"],
-    },
-}
-
-
-@lru_cache(maxsize=1)
-def get_settings() -> Settings:
-    """Return the singleton Settings instance.
-
-    Cached so the entire application shares one validated config.
-    """
-    return Settings()
-
-
-def setup_logging() -> None:
-    """Configure root logging once at startup."""
-    logging.config.dictConfig(LOGGING_CONFIG)
-```
-
-### Key Behaviors
-
-- **Startup validation**: If `OPENROUTER_API_KEY` is missing from the environment, `Settings()` raises a `ValidationError` immediately — the app won't start with a missing key.
-- **`.env` support**: Developers can create a `.env` file in the project root for local keys; it's never committed (already covered by the existing `.gitignore` pattern or a new entry).
-- **`extra="ignore"`**: Unknown env vars don't cause errors, keeping the config resilient to unrelated environment variables.
-- **`lru_cache`**: `get_settings()` is the single access point. All modules import and call this function rather than constructing `Settings` directly.
-- **Centralized logging**: `setup_logging()` calls `dictConfig` exactly once at startup; all modules should use `logging.getLogger(__name__)` and avoid `basicConfig`.
-
-### `.env` template (not committed — add to `.gitignore`)
-
-```bash .env.example
-PROVIDER=openrouter
-OPENROUTER_API_KEY=sk-or-...
-# PROVIDER_MODEL=          # optional: OpenRouter adapter supplies default
-# OPENROUTER_HTTP_REFERER=https://example.com
-# OPENROUTER_APP_TITLE=Historical Transcription MVP
-# DATABASE_URL=sqlite:///./transcription.db
-# UPLOAD_DIR=./uploads
-# PROMPT_DIR=./prompts
-```
-
-### `.gitignore` addition
-
-```gitignore .gitignore
-# ... existing entries ...
-
-# Environment secrets
-.env
-```
-
----
-
-## 3. `models.py` — SQLModel Domain Models
-
-**Satisfies:** REQ-3 (persist and expose job states), REQ-4 (persist transcription output and failure details)
-
-### Design Decisions
-
-| Decision | Rationale |
-|----------|-----------|
-| Three models: `Document`, `Job`, `Transcript` | Minimal set from MVP Feature 5. One-to-many from Document→Job and one-to-one from Job→Transcript |
-| `JobStatus` as a `StrEnum` | Readable in the database (`"queued"` not `1`), type-safe in Python, trivially serializable to JSON for the UI |
-| Status values: `queued`, `processing`, `transcribed`, `failed` | Matches MVP Feature 2 lifecycle. REQ-3 also lists `upload` and `completed` — these are deferred to post-MVP when revision/review workflows exist |
-| UUIDs for primary keys | Avoids auto-increment collision concerns if we later move to PostgreSQL; safe for distributed ID generation; `uuid4` is simple |
-| `uploaded_at`, `created_at`, `updated_at` as UTC `datetime` | Timezone-naive UTC by convention for MVP. Sufficient for single-user, single-timezone operation |
-| `Transcript.text` is nullable | A failed job creates a Transcript with `text=None` and `error_detail` populated, keeping the query model uniform |
-| Relationships via SQLModel `Relationship` | Enables `document.jobs` and `job.transcript` navigation in service code without manual joins |
-
-### Proposed Implementation
-
-- `resource://skills/fastapi-async-sqlalchemy-modernization/document`
-
-```python src/transcription/models.py
-"""SQLModel domain models for the transcription system.
-
-Three models capture the MVP lifecycle:
-  Document  →  one-to-many  →  Job  →  one-to-one  →  Transcript
-"""
-
-from datetime import datetime, timezone
-from enum import StrEnum
-from uuid import UUID, uuid4
-
-from sqlmodel import Field, Relationship, SQLModel
-
-
-class JobStatus(StrEnum):
-    QUEUED = "queued"
-    PROCESSING = "processing"
-    TRANSCRIBED = "transcribed"
-    FAILED = "failed"
-
-
-class Document(SQLModel, table=True):
-    """An uploaded document image."""
-
-    id: UUID = Field(default_factory=uuid4, primary_key=True)
-    filename: str
-    file_path: str
-    uploaded_at: datetime = Field(
-        default_factory=lambda: datetime.now(timezone.utc),
-    )
-
-    # --- relationships ---
-    jobs: list["Job"] = Relationship(back_populates="document")
-
-
-class Job(SQLModel, table=True):
-    """A transcription job tied to a single document."""
-
-    id: UUID = Field(default_factory=uuid4, primary_key=True)
-    document_id: UUID = Field(foreign_key="document.id")
-    status: JobStatus = Field(default=JobStatus.QUEUED)
-    created_at: datetime = Field(
-        default_factory=lambda: datetime.now(timezone.utc),
-    )
-    updated_at: datetime = Field(
-        default_factory=lambda: datetime.now(timezone.utc),
-    )
-
-    # --- relationships ---
-    document: Document = Relationship(back_populates="jobs")
-    transcript: "Transcript | None" = Relationship(back_populates="job")
-
-
-class Transcript(SQLModel, table=True):
-    """The output of a transcription job."""
-
-    id: UUID = Field(default_factory=uuid4, primary_key=True)
-    job_id: UUID = Field(foreign_key="job.id", unique=True)
-    text: str | None = None
-    error_detail: str | None = None
-    created_at: datetime = Field(
-        default_factory=lambda: datetime.now(timezone.utc),
-    )
-
-    # --- relationships ---
-    job: Job = Relationship(back_populates="transcript")
-```
-
-### Entity-Relationship Summary
-
-```
-┌──────────┐       ┌──────────┐       ┌─────────────┐
-│ Document │ 1───* │   Job    │ 1───1 │ Transcript  │
-├──────────┤       ├──────────┤       ├─────────────┤
-│ id (PK)  │       │ id (PK)  │       │ id (PK)     │
-│ filename │       │ doc_id   │──FK──▶│ job_id (FK) │
-│ file_path│       │ status   │       │ text        │
-│ uploaded │       │ created  │       │ error_detail│
-│          │       │ updated  │       │ created     │
-└──────────┘       └──────────┘       └─────────────┘
-```
-
-### Why Only Four Status Values
-
-REQ-3 lists six states: `upload`, `queued`, `processing`, `transcribed`, `failed`, `completed`. The MVP simplifies this:
-
-| REQ-3 State | MVP Treatment |
-|-------------|---------------|
-| `upload` | Implicit — the Document record exists before a Job is created. No separate job state needed. |
-| `queued` | ✅ Included — job created, waiting for worker pickup |
-| `processing` | ✅ Included — worker is actively transcribing |
-| `transcribed` | ✅ Included — AI output received and stored |
-| `failed` | ✅ Included — error captured |
-| `completed` | Deferred — implies human review/acceptance. In MVP, `transcribed` is the terminal success state. |
-
----
-
-## 4. `db.py` — Database Engine and Session Management
-
-**Satisfies:** MVP Feature 5 (SQLite auto-created on first startup)
-
-### Design Decisions
-
-| Decision | Rationale |
-|----------|-----------|
-| Module-level `create_engine` + `Session` factory | REQ-7 (lifespan-owned resources) is deferred. A module-level engine is adequate for MVP's single-process, single-user operation |
-| `create_all()` as an explicit function | Called at app startup. MVP auto-creates tables (REQ-10 deferred), but the function is isolated so it's easy to gate behind a flag later |
-| `get_session()` as a generator | Standard FastAPI/SQLModel pattern — yields a session, ensures cleanup. Compatible with `Depends()` when the API layer arrives in Step 5 |
-| `echo=False` default | Keeps logs clean. Can be toggled for debugging |
-
-### Proposed Implementation
-
-```python src/transcription/db.py
-"""Database engine, session factory, and schema bootstrap.
-
-MVP uses SQLite with auto-create-tables at startup.
-PostgreSQL migration is a post-MVP configuration change.
-"""
-import contextlib
-from collections.abc import Generator
-
-from sqlmodel import Session, SQLModel, create_engine
-
-from transcription.config import get_settings
-
-
-def _build_engine():
-    settings = get_settings()
-    connect_args = {}
-    if settings.database_url.startswith("sqlite"):
-        connect_args["check_same_thread"] = False
-    return create_engine(
-        settings.database_url,
-        echo=False,
-        connect_args=connect_args,
-    )
-
-
-engine = _build_engine()
-
-
-def create_all() -> None:
-    """Create all tables. Called once at application startup."""
-    SQLModel.metadata.create_all(engine)
-
-
-@contextlib.contextmanager
-def get_session() -> Generator[Session]:
-    """Yield a database session and ensure cleanup."""
-    with Session(engine) as session:
-        yield session
-```
-
-### SQLite-Specific Note
-
-`check_same_thread=False` is required for SQLite when the session may be accessed from different threads (e.g., a background worker on a different thread than the request handler). This setting is harmless and ignored for PostgreSQL connection strings.
-
----
-
-## 5. Test Plan
-
-Refer to these resources for rules and guidelines about structure:
-
-- `resource://skills/pytesting/document`
-- `resource://catalog/prompts/pytest-scaffold`
-- `resource://catalog/prompts/pytest-fill-scaffold`
-
-Hierarchy pattern used in this step:
-
-```text
-tests/
-    conftest.py
-    test_config.py
-        TestSettingsLoading
-            test_loads_from_env
-            test_requires_api_key
-        TestProviderSettings
-            test_defaults_to_openrouter
-            test_rejects_invalid_value
-            test_optional_fields_default_to_none
-        TestPathSettings
-            test_path_fields_are_path_objects
-    test_models.py
-        TestDocumentModel
-            test_can_be_persisted
-            test_defaults_are_populated
-        TestJobModel
-            test_can_be_created_for_document
-            test_defaults_are_populated
-            test_transitions_to_transcribed
-            test_transitions_to_failed
-        TestTranscriptModel
-            test_success_record_persists
-            test_failure_record_persists
-            test_job_id_is_unique
-        TestRelationships
-            test_document_exposes_jobs
-            test_job_exposes_transcript
-    test_db.py
-        TestSchemaBootstrap
-            test_create_all_creates_expected_tables
-        TestSessionFactory
-            test_get_session_yields_session
-            test_session_is_closed_after_generator_exit
-```
-
-### `tests/conftest.py` — Shared Fixtures
-
-```python tests/conftest.py
-"""Shared test fixtures.
-
-Every test gets a fresh in-memory SQLite database so tests are
-isolated, fast, and leave no artifacts on disk.
-"""
-
-import pytest
-from sqlmodel import Session, SQLModel, create_engine
-from sqlmodel.pool import StaticPool
-
-
-@pytest.fixture
-def session():
-    """Provide a clean database session for each test."""
-    engine = create_engine(
-        "sqlite://",
-        connect_args={"check_same_thread": False},
-        poolclass=StaticPool,
-    )
-    SQLModel.metadata.create_all(engine)
-    with Session(engine) as session:
-        yield session
-```
-
-`StaticPool` ensures a single in-memory SQLite connection is shared across threads, which is required when `TestClient` (Step 5) spawns threads that would otherwise get separate in-memory databases. Establishing it now keeps the fixture stable across all future steps.
-
-### `tests/test_config.py` — Configuration Hierarchy
-
-| Class | Method | What It Verifies |
-|------|--------|------------------|
-| `TestSettingsLoading` | `test_loads_from_env` | `Settings` constructs successfully when `OPENROUTER_API_KEY` is set via env var |
-| `TestSettingsLoading` | `test_requires_api_key` | `Settings()` raises `ValidationError` when `OPENROUTER_API_KEY` is missing |
-| `TestProviderSettings` | `test_defaults_to_openrouter` | Default provider is `openrouter` when not explicitly set |
-| `TestProviderSettings` | `test_rejects_invalid_value` | Setting `PROVIDER=invalid` raises `ValidationError` |
-| `TestProviderSettings` | `test_optional_fields_default_to_none` | `provider_model`, `openrouter_http_referer`, and `openrouter_app_title` are `None` when unset |
-| `TestPathSettings` | `test_path_fields_are_path_objects` | `upload_dir` and `prompt_dir` are `Path` instances |
-
-### `tests/test_models.py` — Model & Relationship Hierarchy
-
-| Class | Method | What It Verifies |
-|------|--------|------------------|
-| `TestDocumentModel` | `test_can_be_persisted` | A `Document` can be persisted and read back with correct fields |
-| `TestDocumentModel` | `test_defaults_are_populated` | `id` is auto-generated UUID, `uploaded_at` is populated |
-| `TestJobModel` | `test_can_be_created_for_document` | A `Job` linked to a `Document` via FK persists correctly |
-| `TestJobModel` | `test_defaults_are_populated` | Default status is `queued`, `created_at` and `updated_at` are populated |
-| `TestJobModel` | `test_transitions_to_transcribed` | Status can be updated from `queued` → `processing` → `transcribed` |
-| `TestJobModel` | `test_transitions_to_failed` | Status can be updated from `processing` → `failed` |
-| `TestTranscriptModel` | `test_success_record_persists` | A `Transcript` with `text` set and `error_detail=None` persists correctly |
-| `TestTranscriptModel` | `test_failure_record_persists` | A `Transcript` with `text=None` and `error_detail` set persists correctly |
-| `TestRelationships` | `test_document_exposes_jobs` | `document.jobs` returns the linked `Job` list |
-| `TestRelationships` | `test_job_exposes_transcript` | `job.transcript` returns the linked `Transcript` |
-| `TestTranscriptModel` | `test_job_id_is_unique` | Inserting two transcripts with the same `job_id` raises an integrity error |
-
-### `tests/test_db.py` — Database Bootstrap Hierarchy
-
-| Class | Method | What It Verifies |
-|------|--------|------------------|
-| `TestSchemaBootstrap` | `test_create_all_creates_expected_tables` | After `create_all()`, the expected tables (`document`, `job`, `transcript`) exist in the database |
-| `TestSessionFactory` | `test_get_session_yields_session` | `get_session()` yields a usable `Session` object |
-| `TestSessionFactory` | `test_session_is_closed_after_generator_exit` | After the generator is exhausted, the session is closed |
-
-### Marker Strategy (Step 1)
-
-- Markers (`unit`, `integration`, `external`) are registered upfront in `pyproject.toml` with `--strict-markers` enabled, per pytesting skill conventions.
-- All Step 1 tests are unmarked — they run in the default lane since they are fast, deterministic, and have no external dependencies.
-- When slower integration or external tests are introduced in later steps, apply explicit markers and keep test names unchanged.
-
-### Test Workflow
-
-Follow the two-phase approach from `resource://catalog/prompts/pytest-scaffold` and `resource://catalog/prompts/pytest-fill-scaffold`:
-
-1. **Scaffold phase**: Create test files with class hierarchy, method names, and one-line docstrings only. Validate collection:
-   - `uv run pytest --collect-only -q`
-2. **Fill phase**: Implement assertions, fixtures, and minimal test data. Treat scaffolded names and docstrings as locked. Validate execution:
-   - `uv run pytest -q`
-
-Scaffolded structure is treated as a stable baseline — do not rename, move, merge, split, or re-nest tests once the scaffold is reviewed.
-
----
-
-## 6. Step 1 Completion Checklist
-
-When all of the following are true, Step 1 is done and Step 2 can begin:
-
-| # | Criterion | How to Verify |
-|---|-----------|---------------|
-| 1 | `src/transcription/` package exists with `config.py`, `models.py`, `db.py` | `ls` / file inspection |
-| 2 | Empty `__init__.py` stubs exist for `providers/`, `services/`, `ui/` | `ls` / file inspection |
-| 3 | `Settings` loads from environment and validates `OPENROUTER_API_KEY` is present | `test_config.py` passes |
-| 4 | `Document`, `Job`, `Transcript` models create tables in SQLite | `test_models.py` passes |
-| 5 | `JobStatus` enum has exactly four values: `queued`, `processing`, `transcribed`, `failed` | `test_models.py` passes |
-| 6 | Foreign key relationships work: Document→Job→Transcript | `test_models.py` passes |
-| 7 | `create_all()` bootstraps the schema; `get_session()` yields a working session | `test_db.py` passes |
-| 8 | All tests pass: `uv run pytest -q` | CI / local run |
-| 9 | `hello.py` is deleted | File inspection |
-| 10 | `pyproject.toml` includes `openrouter`, `sqlmodel`, `pydantic-settings`, `pytest`, `pytest-asyncio` | File inspection |
-| 10a | `pyproject.toml` has `[tool.pytest.ini_options]` with `--strict-markers` and registered markers | File inspection |
-| 11 | `.env.example` documents all config vars; `.env` is in `.gitignore` | File inspection |
-| 12 | `setup_logging()` uses `logging.config.dictConfig` with centralized formatter/handler/root config | File inspection |
-| 13 | `uv run pytest --collect-only -q` shows expected test hierarchy | Local run |
-| 14 | `uv run pytest -q` passes all tests | Local run |
-
----
-
-## 7. What This Step Does NOT Include
-
-Explicitly out of scope to prevent scope creep:
-
-| Excluded | Reason |
-|----------|--------|
-| FastAPI / NiceGUI app entrypoint | Step 5 |
-| Additional provider adapters beyond OpenRouter | Post-MVP |
-| Upload service logic | Step 4 |
-| Worker / background processing | Step 4 |
-| Transcription prompt files | Step 2 |
-| Alembic or migration tooling | Post-MVP (REQ-10 deferred) |
-| Async session factory | Post-MVP (REQ-7 deferred) |
-
----
-
-This plan produces a fully tested, importable data foundation. Every subsequent step imports from `transcription.config`, `transcription.models`, and `transcription.db` without modification.

docs/mvp/mvp-step2.md

@@ -1,278 +0,0 @@
-## Step 2: prompts/transcribe_document.md
-
-### Goal
-
-Implement the MVP prompt artifact system by creating a curated transcription prompt file:
-
-- `prompts/transcribe_document.md`
-
-This step primarily satisfies:
-
-- **REQ-12**: prompts stored as individual Markdown artifacts
-- MVP Feature 3: prompt-driven verbatim transcription behavior grounded in `docs/intent.md`
-
----
-
-## Scope for Step 2
-
-### In scope
-1. Create prompt artifact directory and first prompt file.
-2. Encode transcription rules from `docs/intent.md` into a model-facing prompt.
-3. Define stable prompt structure so future revisions are easy to diff/review.
-4. Add lightweight tests that validate artifact presence and baseline quality constraints.
-5. Update docs/README references so Step 3 can consume prompt file directly.
-
-### Out of scope
-- Provider integration logic (Step 3)
-- Worker/job orchestration (Step 4)
-- UI behavior (Step 5)
-
----
-
-## Proposed Deliverables
-
-1. **`prompts/transcribe_document.md`**
-   - production prompt text for historical document transcription
-
-2. **`prompts/README.md`** (recommended)
-   - conventions for prompt files, revision policy, naming
-
-3. **`tests/test_prompts.py`** (recommended)
-   - artifact existence + structure checks
-
-4. **Small docs update** (README or docs reference)
-   - indicate that prompts are file-based and loaded from `PROMPT_DIR`
-
----
-
-## Detailed Work Breakdown
-
-### 1) Create prompt artifact folder and canonical file
-- Add `prompts/` at repo root.
-- Add `transcribe_document.md` as the first curated artifact.
-- Keep filename stable; this becomes the default in Step 3 unless overridden.
-
-### 2) Author prompt content using a strict, sectioned format
-Use section headers so future diffs are clean and policy changes are isolated.
-
-Suggested sections:
-
-1. **Purpose**
-   - verbatim scholarly transcription of historical documents
-
-2. **Output requirements**
-   - plain text only
-   - no summaries, no paraphrasing
-   - preserve reading order and meaningful structure
-
-3. **Core fidelity rules**
-   - preserve original wording and punctuation
-   - don’t silently normalize grammar/spelling
-   - no invented content
-
-4. **Issue-handling rules (mapped from Intent table)**
-   - misspellings with `[sic]`
-   - missing words with `[word]`
-   - uncertainty with `[guess?]`
-   - illegible with `[illegible]` / reason tags
-   - crossed-out text as `[deleted: ...]`
-   - inserted text as `[inserted: ...]`
-   - superscripts handling guidance
-   - non-text elements as `[description]`
-   - marginalia format `[written in left margin: ...]`
-   - line-break hyphen rejoin behavior
-   - capitalization policy
-   - hierarchical outline preservation (including unusual numbering)
-
-5. **Confidence/ambiguity policy**
-   - prefer explicit uncertainty markers over hallucination
-
-6. **Final self-checklist for model**
-   - did I preserve structure?
-   - did I mark uncertain text?
-   - did I avoid silent corrections?
-
-### 3) Add prompt-library conventions (`prompts/README.md`)
-Recommended conventions:
-- one prompt per file
-- snake_case names
-- each file starts with purpose + behavior contract
-- iterative edits, one prompt per PR where possible
-- no secrets in prompt files
-
-### 4) Add tests for prompt assets (`tests/test_prompts.py`)
-Keep tests robust but not brittle.
-
-Recommended tests:
-1. `test_prompt_file_exists`
-2. `test_prompt_file_is_not_empty`
-3. `test_prompt_mentions_verbatim_behavior`
-4. `test_prompt_includes_uncertainty_and_illegible_markers`
-5. `test_prompt_includes_deleted_and_inserted_conventions`
-
-Avoid exact full-text matching; verify key semantic anchors only.
-
-### 5) Optional config alignment check
-Current config already has:
-- `prompt_dir: Path = Path("./prompts")`
-
-In Step 2, ensure docs reflect this and that Step 3 will resolve:
-- `PROMPT_DIR / "transcribe_document.md"`
-
----
-
-## Task-by-Task Execution Checklist
-
-## Phase A — Scaffold files
-
-- [ ] **A1. Create prompt directory**
-  - Path: `prompts/`
-  - Verify: directory exists at repo root
-
-- [ ] **A2. Create canonical prompt file**
-  - Path: `prompts/transcribe_document.md`
-  - Verify: file exists and is non-empty
-
-- [ ] **A3. (Recommended) Create prompt library README**
-  - Path: `prompts/README.md`
-  - Verify: includes naming + revision conventions
-
----
-
-## Phase B — Author prompt content (core work)
-
-- [ ] **B1. Add Purpose section**
-  - States verbatim historical transcription objective
-  - Explicitly disallows summarization/paraphrase
-
-- [ ] **B2. Add Output Contract section**
-  - Plain text output expectation
-  - Preserve meaningful structure and reading order
-  - No fabricated text
-
-- [ ] **B3. Add Rule Set from `docs/intent.md`**
-  - Misspellings/errors: `[sic]`
-  - Missing words: `[word]`
-  - Uncertain readings: `[guess?]`
-  - Illegible regions: `[illegible]` / reason labels
-  - Crossed-out text: `[deleted: ...]`
-  - Squeezed-in text: `[inserted: ...]`
-  - Superscripts/abbrev handling guidance
-  - Non-text visuals: bracketed descriptive labels
-  - Marginalia formatting cue
-  - Rejoin line-break hyphenated words silently
-  - Ambiguous capitalization policy
-  - Hierarchical outline numbering preservation
-
-- [ ] **B4. Add Ambiguity and Confidence policy**
-  - “Mark uncertainty instead of guessing”
-  - “Never silently normalize uncertain passages”
-
-- [ ] **B5. Add Final Self-Check section**
-  - Checklist for fidelity, uncertainty labeling, and format compliance
-
----
-
-## Phase C — Add validations (tests)
-
-- [ ] **C1. Create prompt tests file**
-  - Path: `tests/test_prompts.py`
-
-- [ ] **C2. Add existence/health checks**
-  - Prompt file exists
-  - Prompt file has content (non-whitespace)
-
-- [ ] **C3. Add semantic anchor checks**
-  - Mentions verbatim behavior
-  - Mentions uncertainty marker pattern (`?` in brackets conceptually)
-  - Mentions illegible handling
-  - Mentions deleted/inserted conventions
-
-- [ ] **C4. Keep tests resilient**
-  - Avoid exact full-file snapshot assertions
-  - Assert required concepts, not precise phrasing
-
----
-
-## Phase D — Documentation alignment
-
-- [ ] **D1. Update top-level docs/README reference**
-  - Mention that prompts live in `prompts/`
-  - Mention Step 3 loads from `PROMPT_DIR`
-
-- [ ] **D2. Confirm config compatibility**
-  - `src/transcription/config.py` already uses `prompt_dir = Path("./prompts")`
-  - No code change needed unless naming/path mismatch appears
-
----
-
-## Phase E — Verification
-
-- [ ] **E1. Run targeted test file**
-  - `uv run pytest tests/test_prompts.py -q`
-
-- [ ] **E2. Run full suite**
-  - `uv run pytest -q`
-
-- [ ] **E3. Confirm no regressions**
-  - All existing tests still green (expected: previous 20 + new prompt tests)
-
----
-
-## Phase F — Commit plan (recommended granularity)
-
-- [ ] **F1. Commit 1: scaffold**
-  - `prompts/transcribe_document.md` (initial structure)
-  - `prompts/README.md` (if included)
-
-- [ ] **F2. Commit 2: finalized prompt content**
-  - full rule-complete prompt text
-
-- [ ] **F3. Commit 3: tests + docs alignment**
-  - `tests/test_prompts.py`
-  - README/docs mention of prompt artifact pattern
-
----
-
-## Done Criteria (quick gate)
-
-- [ ] Canonical prompt exists and is curated for verbatim transcription.
-- [ ] Prompt encodes all high-value handling rules from `docs/intent.md`.
-- [ ] Prompt tests pass.
-- [ ] Full project tests pass with `uv`.
-- [ ] Ready for Step 3 provider integration.
-
----
-
-## Acceptance Criteria (Definition of Done)
-
-Step 2 is complete when all are true:
-
-1. `prompts/transcribe_document.md` exists and is committed.
-2. Prompt includes all critical handling rules from `docs/intent.md`.
-3. Prompt is structured with stable section headings for future curation.
-4. Prompt tests pass under `uv run pytest -q`.
-5. Existing tests remain green (total suite still passes).
-6. Docs indicate prompt artifact location and curation policy.
-
----
-
-## Risks and Mitigations
-
-1. **Risk: prompt too vague → hallucinated reconstructions**
-   - Mitigation: explicit uncertainty/illegible conventions and “no invention” rule.
-
-2. **Risk: prompt too rigid for mixed document types**
-   - Mitigation: include neutral defaults + clear annotation formats.
-
-3. **Risk: brittle tests block iterative prompt tuning**
-   - Mitigation: test semantic anchors, not exact wording.
-
----
-
-## Handoff to Step 3
-
-After Step 2, Step 3 can immediately:
-1. Load `transcribe_document.md` from `PROMPT_DIR`
-2. Inject prompt into OpenRouter request
-3. Start validating real transcription behavior with minimal glue code

docs/mvp/mvp-step3.md

@@ -1,236 +0,0 @@
-## Step 3: services/transcription.py + providers/ 
-
-### Objective
-
-Implement the **AI transcription integration layer** so the app can:
-
-1. Read the curated prompt from `PROMPT_DIR`
-2. Send prompt + image to the configured provider (OpenRouter)
-3. Return normalized transcription output (or structured failure)
-
-This corresponds to MVP Step 3 from `docs/mvp.md`:
-- `services/transcription.py`
-- `providers/` adapter(s)
-
----
-
-## Scope for Step 3
-
-### In scope
-- Provider abstraction and OpenRouter adapter
-- Prompt file loading utility in service layer
-- Image payload preparation
-- One high-level transcription service function usable by Step 4 worker
-- Unit tests (mocked provider SDK, no external calls)
-
-### Out of scope
-- Job polling/background loop (Step 4)
-- DB status transition orchestration in worker loop (Step 4)
-- UI invocation/wiring (Step 5)
-
----
-
-## Planned Deliverables
-
-### Source files
-- `src/transcription/providers/base.py`
-- `src/transcription/providers/openrouter.py`
-- `src/transcription/providers/__init__.py` (exports + factory)
-- `src/transcription/services/transcription.py`
-- `src/transcription/services/__init__.py` (optional export)
-
-### Tests
-- `tests/providers/test_openrouter.py`
-- `tests/services/test_transcription.py`
-
-### Test directory convention
-- Mirror source domains under `tests/`.
-- Provider adapter tests live under `tests/providers/`.
-- Service-layer tests live under `tests/services/`.
-- Prefer one focused test module per production module (for Step 3: `test_openrouter.py`, `test_transcription.py`).
-
----
-
-## Design Decisions (before coding)
-
-1. **Provider interface first**
-   - Define a stable contract independent of SDK specifics.
-   - Prevent Step 4 from depending on raw SDK response shapes.
-
-2. **Service returns normalized result object**
-   - Include: `text`, `provider`, `model`, `raw_error`/exception metadata.
-   - Worker can map this cleanly to `Transcript` and `JobStatus`.
-
-3. **Prompt loaded from file at call time**
-   - Uses `get_settings().prompt_dir / "transcribe_document.md"`.
-   - Keeps prompt edits hot-swappable without code changes.
-
-4. **Clear exception boundary**
-   - SDK/network/model failures become predictable domain exceptions:
-     - `ProviderError`
-     - `PromptLoadError`
-     - `TranscriptionError` (optional top-level wrapper)
-
-5. **Model resolution policy**
-   - Use `settings.provider_model` if set
-   - Otherwise use adapter default constant (e.g., vision-capable model slug)
-
----
-
-## Task-by-Task Execution Checklist
-
-## Phase A — Provider contract
-
-- [ ] Create `src/transcription/providers/base.py`
-- [ ] Define protocol/ABC for transcription providers:
-  - [ ] method signature accepts prompt text + image bytes (or data URL) + mime type
-  - [ ] returns normalized text result (and optional metadata)
-- [ ] Define shared provider exceptions:
-  - [ ] `ProviderError`
-  - [ ] optional subclasses (`ProviderAuthError`, `ProviderResponseError`)
-
----
-
-## Phase B — OpenRouter adapter
-
-- [ ] Create `src/transcription/providers/openrouter.py`
-- [ ] Implement `OpenRouterTranscriptionProvider` with:
-  - [ ] config-driven API key usage
-  - [ ] optional referer/title attribution headers
-  - [ ] model resolution fallback when `provider_model` is unset
-- [ ] Implement request building:
-  - [ ] prompt included as instruction content
-  - [ ] image included in supported format for vision call
-- [ ] Implement response parsing:
-  - [ ] extract final transcript text from SDK response
-  - [ ] validate non-empty text
-- [ ] Wrap SDK failures into `ProviderError` with clean message
-
----
-
-## Phase C — Provider factory
-
-- [ ] Update `src/transcription/providers/__init__.py`
-- [ ] Add `get_transcription_provider()` factory:
-  - [ ] reads `settings.provider`
-  - [ ] returns OpenRouter adapter for `openrouter`
-  - [ ] raises explicit error for unsupported provider values
-
----
-
-## Phase D — Transcription service (Step 3 core)
-
-- [ ] Create `src/transcription/services/transcription.py`
-- [ ] Add prompt loader function:
-  - [ ] default file: `transcribe_document.md`
-  - [ ] raises `PromptLoadError` on missing/empty file
-- [ ] Add image loader/validator:
-  - [ ] path existence check
-  - [ ] allowed mime detection (`.jpg/.jpeg/.png/.tiff/.pdf` policy aligned to MVP)
-- [ ] Add high-level function (name example):
-  - [ ] `transcribe_document_image(image_path, prompt_name="transcribe_document.md")`
-  - [ ] loads prompt + image
-  - [ ] calls provider from factory
-  - [ ] returns normalized transcription result object
-- [ ] Add structured logging at key boundaries:
-  - [ ] prompt loaded
-  - [ ] provider invoked
-  - [ ] success/failure outcome (no sensitive data in logs)
-
----
-
-## Phase E — Tests (two-phase scaffold -> fill)
-
-### Required execution resources
-
-Load and reference these directly during test planning/implementation so the two-phase flow is enforced:
-
-- [ ] `resource://catalog/prompts/pytest-scaffold`
-- [ ] `resource://prompts/pytest-scaffold/document`
-- [ ] `resource://catalog/prompts/pytest-fill-scaffold`
-- [ ] `resource://prompts/pytest-fill-scaffold/document`
-
-### Phase E1 — Scaffold test structure first
-
-Prompt: `resource://catalog/prompts/pytest-scaffold`
-
-Suggested arguments:
-- [ ] `target_modules` = `src/transcription/providers/openrouter.py`, `src/transcription/services/transcription.py`
-- [ ] `mode` = `scaffold`
-- [ ] `path_strategy` = `src-to-tests-mirror`
-- [ ] `naming_style` = `concise-behavior`
-
-Expected scaffold outcomes:
-- [ ] `tests/providers/test_openrouter.py` exists with class/method skeletons and one-line docstrings
-- [ ] `tests/services/test_transcription.py` exists with class/method skeletons and one-line docstrings
-- [ ] collection succeeds on scaffold-only tests
-
-Scaffold coverage targets:
-- [ ] adapter initializes from settings
-- [ ] model fallback when `provider_model is None`
-- [ ] referer/title options included when set
-- [ ] successful SDK response parses transcript text
-- [ ] SDK exception maps to `ProviderError`
-- [ ] empty/invalid response maps to `ProviderError`
-- [ ] prompt loader reads canonical prompt file
-- [ ] missing prompt raises `PromptLoadError`
-- [ ] transcription function loads file and calls provider once
-- [ ] image path missing raises clear error
-- [ ] provider error is propagated/wrapped predictably
-- [ ] returned result includes transcript text and metadata
-
-### Phase E2 — Fill scaffolded tests with assertions
-
-Prompt: `resource://catalog/prompts/pytest-fill-scaffold`
-
-Suggested arguments:
-- [ ] `target_files` = `tests/providers/test_openrouter.py`, `tests/services/test_transcription.py`
-- [ ] `stack` = `pure-python`
-- [ ] `strategy` = `minimal`
-- [ ] `marker_lane` = `unit`
-
-Fill constraints:
-- [ ] preserve scaffold class/method names and one-line docstrings
-- [ ] keep mocks to an absolute minimum; mock only network boundaries and non-deterministic failures
-- [ ] keep one behavior target per test method
-
-> Default suite should remain deterministic and fast, but mocking should be minimal and intentional.
-
-### Optional real-endpoint validation lane
-
-- [ ] Add an opt-in integration lane for real provider calls (for example `@pytest.mark.integration` and `@pytest.mark.live_api`).
-- [ ] Gate live tests behind explicit env vars (for example `OPENROUTER_API_KEY`, optional `RUN_LIVE_API_TESTS=1`).
-- [ ] Exclude live tests from default CI/local runs unless explicitly requested.
-- [ ] Keep at least one thin smoke path that can validate request/response compatibility against the real endpoint.
-
----
-
-## Phase F — Verification commands
-
-- [ ] E1 scaffold validation: `uv run pytest --collect-only -q`
-- [ ] E2 fill validation (unit lane): `uv run pytest -m unit -q`
-- [ ] E2 targeted provider file: `uv run pytest tests/providers/test_openrouter.py -q`
-- [ ] E2 targeted service file: `uv run pytest tests/services/test_transcription.py -q`
-- [ ] E2 final full-suite check: `uv run pytest -q`
-
----
-
-## Implementation Notes / Guardrails
-
-- Avoid coupling Step 3 service to DB models directly (that belongs in Step 4 orchestration).
-- Do not silently swallow provider errors.
-- Keep prompt filename stable (`transcribe_document.md`) unless explicitly parameterized.
-- Keep request/response normalization inside provider adapter, not worker/UI layers.
-
----
-
-## Definition of Done (Step 3)
-
-Step 3 is done when:
-
-1. Provider abstraction exists and OpenRouter adapter is implemented.
-2. Service can transcribe a local image using prompt file content.
-3. Failures are returned as structured exceptions, not raw SDK traceback noise.
-4. Unit tests for provider and service pass.
-5. Full suite remains green under `uv run pytest -q`.
-6. Step 4 can call a single service function to process queued jobs.

docs/mvp/mvp-step4.md

@@ -1,262 +0,0 @@
-## Step 4: `services/upload.py` + `worker.py`
-
-### Objective
-
-Implement the MVP upload and background-processing pipeline so the system can:
-
-1. Save uploaded files into `UPLOAD_DIR`
-2. Create `Document` + `Job(status="queued")`
-3. Process queued jobs in a worker loop:
-   - `queued -> processing`
-   - call Step 3 transcription service
-   - persist `Transcript`
-   - finalize as `transcribed` or `failed`
-
-This step advances MVP Feature 1 + Feature 2 and supports REQ-1, REQ-2, REQ-3, REQ-4, REQ-6.
-
----
-
-## Scope
-
-### In scope
-- `src/transcription/services/upload.py`
-- `src/transcription/worker.py`
-- Upload persistence logic and initial job creation
-- Worker polling and single-job lifecycle execution
-- Deterministic test coverage for upload + worker (default suite)
-
-### Out of scope
-- UI integration and pages (Step 5)
-- Queue infrastructure beyond in-process loop
-- Async DB/session architecture refactor
-- Broad production hardening beyond MVP needs
-
----
-
-## Planned Deliverables
-
-### Source files
-- `src/transcription/services/upload.py`
-- `src/transcription/worker.py`
-- `src/transcription/services/__init__.py` (export updates as needed)
-
-### Test files
-- `tests/services/test_upload.py`
-- `tests/services/test_worker.py`
-
-### Optional external lane (already present pattern)
-- reuse `external` marker for live-provider checks where appropriate
-- keep external out of default lane
-
----
-
-## Required MCP Prompt References (for test workflow)
-
-Apply these resources directly during Step 4 test creation:
-
-1. `resource://catalog/prompts/pytest-scaffold`
-2. `resource://prompts/pytest-scaffold/document`
-3. `resource://catalog/prompts/pytest-fill-scaffold`
-4. `resource://prompts/pytest-fill-scaffold/document`
-
-And (as referenced by those prompts) apply relevant pytest skill references for:
-- naming/hierarchy
-- marker defaults
-- SQLAlchemy sync testing behavior where applicable
-
----
-
-## Design Decisions
-
-1. **Upload service owns initial file + record creation**
-   - Writes file, creates `Document`, creates queued `Job`, returns IDs/path.
-
-2. **Worker owns lifecycle transitions**
-   - Worker is the single owner of `queued -> processing -> terminal` job state changes.
-
-3. **Worker uses Step 3 service boundary**
-   - Worker calls `transcribe_document_image(...)`; no provider-specific SDK logic in worker.
-
-4. **Failure information is always persisted**
-   - On failure: store `Transcript(text=None, error_detail=...)` and set `Job.status=failed`.
-
-5. **Loop remains simple and stoppable**
-   - In-process polling loop with stop event and poll interval for MVP simplicity and testability.
-
----
-
-## Task-by-Task Execution Checklist
-
-## Phase A — Implement upload service (`src/transcription/services/upload.py`)
-
-- [ ] Create `UploadError` exception
-- [ ] Create `UploadJobResult` dataclass with:
-  - [ ] `document_id`
-  - [ ] `job_id`
-  - [ ] `stored_path`
-  - [ ] `original_filename`
-- [ ] Add filename safety handling:
-  - [ ] normalize to basename
-  - [ ] avoid path traversal
-  - [ ] collision-safe stored name (e.g., UUID prefix/suffix)
-- [ ] Validate upload payload:
-  - [ ] non-empty bytes required
-  - [ ] extension in supported set (`.jpg/.jpeg/.png/.tif/.tiff/.pdf`)
-- [ ] Ensure upload directory exists (`mkdir(parents=True, exist_ok=True)`)
-- [ ] Write file bytes to `UPLOAD_DIR`
-- [ ] Persist DB records in one transaction:
-  - [ ] `Document(filename, file_path)`
-  - [ ] `Job(document_id=..., status=queued)`
-- [ ] Return `UploadJobResult`
-- [ ] Add logging for success/failure boundaries
-
----
-
-## Phase B — Implement worker core (`src/transcription/worker.py`)
-
-- [ ] Add `process_next_queued_job(...) -> bool`
-- [ ] Fetch oldest queued job
-- [ ] Return `False` when no queued jobs exist
-- [ ] Transition picked job to `processing` and update timestamp
-- [ ] Resolve associated `Document.file_path`
-- [ ] Call `transcribe_document_image(image_path=...)`
-- [ ] On success:
-  - [ ] insert/update transcript text
-  - [ ] clear error detail
-  - [ ] mark job `transcribed`
-  - [ ] update timestamp
-- [ ] On failure:
-  - [ ] insert/update transcript with `text=None`, `error_detail=...`
-  - [ ] mark job `failed`
-  - [ ] update timestamp
-- [ ] Commit terminal state and return `True`
-- [ ] Add logs around job pickup, transition, and terminal outcome
-
----
-
-## Phase C — Implement worker loop (`src/transcription/worker.py`)
-
-- [ ] Add `run_worker_loop(...)`
-- [ ] Accept configurable stop event/signal
-- [ ] Accept configurable poll interval
-- [ ] Repeatedly call `process_next_queued_job`
-- [ ] Sleep only when queue is empty
-- [ ] Exit cleanly when stop event is set
-
----
-
-## Phase D — Exports
-
-- [ ] Update `src/transcription/services/__init__.py` to expose upload APIs
-- [ ] Keep existing transcription exports intact
-
----
-
-## Phase E — Tests via MCP scaffold -> fill flow
-
-## E1 Scaffold (structure only)
-
-Use scaffold prompt workflow first for:
-- `src/transcription/services/upload.py`
-- `src/transcription/worker.py`
-
-Expected scaffold targets:
-- `tests/services/test_upload.py`
-- `tests/services/test_worker.py`
-
-Scaffold rules:
-- [ ] Class hierarchy + method names + one-line docstrings only
-- [ ] No assertions or implementation details in scaffold phase
-- [ ] Keep method names concise and behavior-focused
-
-Validation:
-- [ ] `uv run pytest --collect-only -q`
-
-## E2 Fill scaffold (implementation)
-
-Use fill prompt workflow for:
-- `tests/services/test_upload.py`
-- `tests/services/test_worker.py`
-- stack: `sqlalchemy-sync` (or `mixed` if combining pure + DB behaviors)
-- marker lane preference: `unit` and `integration` as appropriate
-- strategy: minimal deterministic implementation
-
-Fill rules (invariants):
-- [ ] Preserve scaffold class names, method names, and one-line docstrings
-- [ ] Do not rename/re-nest scaffolded tests unless explicitly approved
-- [ ] One behavior target per test
-- [ ] Minimal mocking; mock only network/nondeterministic boundaries
-
-Suggested test coverage:
-
-### `tests/services/test_upload.py`
-- [ ] creates file + document + queued job (`integration`)
-- [ ] rejects empty bytes (`unit`)
-- [ ] rejects unsupported extension (`unit`)
-- [ ] writes collision-safe unique filename (`integration`)
-- [ ] persisted job status is `queued` (`integration`)
-
-### `tests/services/test_worker.py`
-- [ ] returns `False` when queue empty (`integration`)
-- [ ] transitions `queued -> processing -> transcribed` on success (`integration`)
-- [ ] stores transcript text on success (`integration`)
-- [ ] transitions to `failed` and stores `error_detail` on failure (`integration`)
-- [ ] updates existing transcript instead of duplicate create (`integration`)
-- [ ] worker loop exits when stop event set (`unit`)
-
----
-
-## Marker Strategy
-
-- `unit`: pure logic tests (filename handling, loop stop behavior, validation logic)
-- `integration`: DB + service orchestration tests (SQLite/session/contracts)
-- `external`: opt-in live provider tests only (not part of default Step 4 lane)
-
-No new marker needed; reuse existing marker registration.
-
----
-
-## Validation Sequence (strict order)
-
-- [ ] `uv run pytest --collect-only -q`
-- [ ] `uv run pytest -m unit -q` *(if unit tests touched)*
-- [ ] `uv run pytest tests/services/test_upload.py -q`
-- [ ] `uv run pytest tests/services/test_worker.py -q`
-- [ ] `uv run pytest -q`
-
----
-
-## Reporting Requirements (after implementation)
-
-Implementation report must include:
-
-1. Files created/updated
-2. Fixture and marker decisions
-3. MCP references used and why
-4. Validation command results
-5. Remaining risks/open questions (only blockers)
-
----
-
-## Guardrails
-
-- Keep Step 4 independent from UI concerns.
-- Do not call provider SDK directly from worker.
-- Do not silently swallow exceptions.
-- Always persist terminal job outcome.
-- Keep default suite deterministic and fast.
-- Preserve scaffold invariants during fill phase.
-
----
-
-## Definition of Done (Step 4)
-
-Step 4 is complete when:
-
-- [ ] Upload service writes file and creates `Document` + queued `Job`
-- [ ] Worker processes queued jobs end-to-end using Step 3 transcription service
-- [ ] Success path persists transcript text and sets `transcribed`
-- [ ] Failure path persists error detail and sets `failed`
-- [ ] Queue-empty path returns cleanly
-- [ ] New tests pass and full suite is green (`uv run pytest -q`)
-- [ ] Output report includes MCP reference usage + validation evidence

docs/mvp/mvp-step5-results.md

@@ -1,70 +0,0 @@
-Step 5 is implemented and passing ✅
-
-### What I implemented
-
-#### App/bootstrap
-- Added `src/transcription/app.py`:
-  - `create_app()` factory
-  - FastAPI lifespan startup/shutdown:
-    - `setup_logging()`
-    - `create_all()`
-    - ensure `upload_dir` and `prompt_dir`
-    - start/stop worker thread (`run_worker_loop`)
-  - includes health router
-  - registers NiceGUI pages
-
-#### API
-- Added `src/transcription/api/__init__.py`
-- Added `src/transcription/api/health.py`:
-  - `GET /healthz` returns `{"status": "ok"}`
-
-#### UI
-- Added `src/transcription/ui/upload_page.py`:
-  - upload page route
-  - accepted extensions helper
-  - upload submit helper to Step 4 service (`create_upload_job`)
-  - success/error state messaging
-- Added `src/transcription/ui/jobs_page.py`:
-  - jobs list page
-  - job detail page
-  - `fetch_jobs()` and `fetch_job_detail()` helpers
-- Updated `src/transcription/ui/__init__.py`:
-  - explicit page registration
-  - NiceGUI mounted via `ui.run_with(app, mount_path="/ui", ...)`
-
-#### Dependencies
-- Added runtime dependencies:
-  - `fastapi`
-  - `nicegui`
-
----
-
-### Tests created and filled (scaffold → fill)
-
-- `tests/test_app.py`
-- `tests/api/test_health.py`
-- `tests/ui/test_pages_registration.py`
-- `tests/ui/test_upload_page.py`
-- `tests/ui/test_jobs_page.py`
-
-All scaffolded method names/docstrings were preserved and filled with executable assertions.
-
----
-
-### Validation results (strict sequence)
-
-- `uv run pytest --collect-only -q` ✅
-- `uv run pytest -m unit -q` ✅
-- `uv run pytest tests/api/test_health.py -q` ✅
-- `uv run pytest tests/ui/test_pages_registration.py -q` ✅
-- `uv run pytest tests/test_app.py -q` ✅
-- `uv run pytest tests/ui/test_upload_page.py -q` ✅
-- `uv run pytest tests/ui/test_jobs_page.py -q` ✅
-- `uv run pytest -q` ✅
-
-Full suite is green.
-
----
-
-### Note
-You’ll see one warning from FastAPI/Starlette test client about `httpx` deprecation; it does not affect correctness and all tests pass.

docs/mvp/mvp-step5.md

@@ -1,310 +0,0 @@
-## Step 5: `app.py` + UI Pages (NiceGUI + FastAPI composition)
-
-## Objective
-
-Implement the MVP user-facing application layer so users can:
-
-1. Upload a document from the UI
-2. Trigger Step 4 upload/job creation flow
-3. See live job lifecycle status (`queued`, `processing`, `transcribed`, `failed`)
-4. Open a job detail view to read transcript text or failure details
-
-This step composes Steps 1–4 into a usable UI.
-
----
-
-## Architecture Summary (NiceGUI-aligned)
-
-Step 5 uses a **FastAPI app factory + lifespan orchestration** and mounts/registers NiceGUI pages via explicit page modules.
-
-Reference baseline: `resource://skills/nicegui/document`
-
-### Core architecture decisions
-
-- **App factory:** `create_app()`
-- **Lifespan-managed resources:** worker start/stop managed in startup/shutdown
-- **Modular pages:** upload and jobs pages in separate modules (no monolithic UI file)
-- **Health endpoint:** FastAPI-side `/healthz`
-- **UI composition:** route pages stay modular and reusable shared shell/components live under `ui/components` as needed
-- **Styling architecture:** shared CSS loaded once at startup; avoid ad-hoc per-page styling drift
-- **Dependency direction (one-way):**
-  - `app` -> `config/logging/db/worker/ui/api`
-  - `ui/pages` -> `ui/components` + `services`
-  - `services` -> `db/models/providers`
-  - no reverse imports from services into UI/API
-
-### DB and AI stance (explicit)
-
-- **DB:** already enabled (SQLModel + SQLite), session lifecycle remains request/service-scoped as built in prior steps.
-- **AI workflow:** already in place via Step 3 transcription service + Step 4 worker; UI does not call provider SDK directly.
-- **Mounted docs:** not in Step 5 scope; docs mounting remains disabled for MVP.
-
-### Async and responsiveness stance
-
-- Prefer `async def` for page handlers and service boundaries when I/O is involved.
-- Keep UI handlers non-blocking (no blocking sleeps or synchronous long I/O calls).
-- For long-running user actions, always provide explicit loading/progress/error states.
-- Keep cancellation/timeout behavior explicit for refresh/poll operations where applicable.
-
----
-
-## Scope
-
-### In scope
-- `src/transcription/app.py`
-- `src/transcription/ui/upload_page.py`
-- `src/transcription/ui/jobs_page.py`
-- `src/transcription/ui/__init__.py`
-- `src/transcription/api/health.py` (or equivalent FastAPI health route module)
-- UI/app tests with MCP scaffold->fill flow
-
-### Out of scope
-- Auth
-- advanced filtering/search UX
-- batch upload UX beyond MVP
-- deployment/container hardening
-
----
-
-## Planned Deliverables
-
-### Source files
-- `src/transcription/app.py` (app factory + lifespan wiring)
-- `src/transcription/api/health.py` (GET `/healthz`)
-- `src/transcription/ui/upload_page.py` (upload flow)
-- `src/transcription/ui/jobs_page.py` (status list + detail)
-- `src/transcription/ui/__init__.py` (explicit `register_pages(...)` export)
-- `src/transcription/ui/components/*` (shared shell/navigation/status components if introduced)
-- `src/transcription/ui/static/*.css` (optional shared CSS loaded once at startup)
-
-### Test files
-- `tests/test_app.py`
-- `tests/api/test_health.py`
-- `tests/ui/test_pages_registration.py`
-- `tests/ui/test_upload_page.py`
-- `tests/ui/test_jobs_page.py`
-
----
-
-## Implementation Plan + Checklist
-
-Plan baseline and guardrails source: `resource://skills/nicegui/document`
-
-## Phase A — App factory and lifespan orchestration
-
-- [ ] Create `create_app()` in `src/transcription/app.py`
-- [ ] Add FastAPI lifespan startup/shutdown handlers
-- [ ] Startup responsibilities:
-  - [ ] `setup_logging()`
-  - [ ] `create_all()`
-  - [ ] ensure directories exist (`upload_dir`, `prompt_dir`)
-  - [ ] create worker stop event
-  - [ ] start worker background thread/task
-- [ ] Shutdown responsibilities:
-  - [ ] signal stop event
-  - [ ] join/cleanup worker thread/task cleanly
-- [ ] Register API router(s), including health route
-- [ ] Register NiceGUI pages via explicit page registration function
-- [ ] Load shared CSS once at startup (if present)
-
-## Phase B — FastAPI health endpoint
-
-- [ ] Create `src/transcription/api/health.py`
-- [ ] Add `GET /healthz` returning simple healthy payload
-- [ ] Wire route into app factory
-
-## Phase C — Upload page (`ui/upload_page.py`)
-
-- [ ] Add upload route/page registration function
-- [ ] Render file input accepting supported extensions
-- [ ] On submit:
-  - [ ] show loading/progress state
-  - [ ] call `create_upload_job(filename, file_bytes, ...)`
-  - [ ] show success state with job reference/link
-- [ ] On error:
-  - [ ] show user-safe error message
-  - [ ] restore ready UI state
-- [ ] Ensure non-blocking I/O in UI event handlers; offload CPU-heavy work to worker path
-- [ ] Make timeout/cancellation behavior explicit for any long-running action
-
-## Phase D — Jobs page (`ui/jobs_page.py`)
-
-- [ ] Add jobs list route/page registration function
-- [ ] Display jobs with status + timestamps
-- [ ] Add job detail route/view
-- [ ] Show transcript on success, error detail on failure
-- [ ] Include explicit refresh action and loading state
-- [ ] Ensure error states are surfaced to user and logged
-- [ ] Keep refresh path async and bounded to avoid UI freeze
-
-## Phase E — UI registration module
-
-- [ ] Update `src/transcription/ui/__init__.py`
-- [ ] Export `register_pages(...)`
-- [ ] Ensure each page module exports `register_page(...)`
-- [ ] Keep page registration explicit and modular
-
-## Phase F — Shared components and style consistency
-
-- [ ] Add `ui/components` module only for reusable shell elements (header/nav/status chips), not page-local logic
-- [ ] Keep structural layout in Python; keep visual polish in shared CSS
-- [ ] Avoid one-off styling duplication across upload/jobs pages
-
----
-
-## MCP Testing Workflow (Required)
-
-Use these resources directly:
-
-- `resource://catalog/prompts/pytest-scaffold`
-- `resource://prompts/pytest-scaffold/document`
-- `resource://catalog/prompts/pytest-fill-scaffold`
-- `resource://prompts/pytest-fill-scaffold/document`
-
-## E1 — Scaffold tests first (structure only)
-
-Target modules:
-- `src/transcription/app.py`
-- `src/transcription/api/health.py`
-- `src/transcription/ui/upload_page.py`
-- `src/transcription/ui/jobs_page.py`
-
-Scaffold test files:
-- `tests/test_app.py`
-- `tests/api/test_health.py`
-- `tests/ui/test_pages_registration.py`
-- `tests/ui/test_upload_page.py`
-- `tests/ui/test_jobs_page.py`
-
-Scaffold constraints:
-- [ ] class/method skeletons only
-- [ ] one-line docstrings
-- [ ] concise behavior-focused names
-- [ ] no implementation assertions yet
-
-Validation:
-- [ ] `uv run pytest --collect-only -q`
-
-## E2 — Fill scaffold tests
-
-Fill constraints from MCP guidance:
-- [ ] preserve scaffold class/method names and docstrings (locked baseline)
-- [ ] one behavior target per method
-- [ ] deterministic tests preferred
-- [ ] minimal mocking; only nondeterministic boundaries
-
-Stack:
-- [ ] `fastapi` (or `mixed` if needed for UI+DB fixture combination)
-
-Suggested coverage:
-
-### `tests/api/test_health.py`
-- [ ] `/healthz` returns success status and expected payload shape
-
-### `tests/ui/test_pages_registration.py`
-- [ ] page registration wiring succeeds
-- [ ] expected routes are present
-
-### `tests/test_app.py`
-- [ ] startup path initializes runtime dependencies
-- [ ] worker start is invoked on startup
-- [ ] worker shutdown signal/cleanup is invoked on shutdown
-
-### `tests/ui/test_upload_page.py`
-- [ ] upload action calls upload service
-- [ ] success feedback displayed
-- [ ] error feedback displayed for `UploadError`
-- [ ] loading/progress state behavior covered
-- [ ] timeout/cancellation behavior covered (if implemented)
-
-### `tests/ui/test_jobs_page.py`
-- [ ] list renders job statuses
-- [ ] detail shows transcript text for successful job
-- [ ] detail shows error detail for failed job
-- [ ] refresh/loading state behavior covered
-
-Marker strategy:
-- [ ] `unit` for pure helpers/state formatting
-- [ ] `integration` for app/page/service+DB contracts
-- [ ] `external` not required for default Step 5 lane
-
-Async behavior assertions:
-- [ ] long-running actions keep button/inputs in expected disabled state
-- [ ] completion/failure returns controls to ready state
-
----
-
-## Validation Sequence (strict)
-
-- [ ] `uv run pytest --collect-only -q`
-- [ ] `uv run pytest -m unit -q` *(if unit tests touched)*
-- [ ] `uv run pytest tests/api/test_health.py -q`
-- [ ] `uv run pytest tests/ui/test_pages_registration.py -q`
-- [ ] `uv run pytest tests/test_app.py -q`
-- [ ] `uv run pytest tests/ui/test_upload_page.py -q`
-- [ ] `uv run pytest tests/ui/test_jobs_page.py -q`
-- [ ] `uv run pytest -q`
-
----
-
-## Guardrails (NiceGUI + MVP)
-
-- [ ] Do not collapse pages into one file.
-- [ ] Do not use implicit global side effects for runtime wiring.
-- [ ] Keep UI responsive with explicit loading/progress/error states.
-- [ ] Do not block UI handlers with synchronous long I/O.
-- [ ] Do not place provider SDK calls in UI handlers.
-- [ ] Keep dependency direction one-way and maintainable.
-- [ ] Keep shared UI in `ui/components`; keep service logic out of page modules.
-
----
-
-## Definition of Done
-
-- [ ] App factory + lifespan are in place
-- [ ] Health endpoint exists and is tested
-- [ ] Upload page creates queued jobs through service boundary
-- [ ] Jobs list/detail pages render status/transcript/failure data
-- [ ] Worker lifecycle is started/stopped by app lifespan
-- [ ] Async UI states (loading/success/error) are deterministic and tested
-- [ ] Scaffold->fill testing flow completed and validated
-- [ ] Full suite passes: `uv run pytest -q`
-
-## Completion Checks (NiceGUI skill aligned)
-
-- [ ] Uses app factory and FastAPI lifespan
-- [ ] Pages are modularized (not single-file UI)
-- [ ] Health endpoint exists on FastAPI side
-- [ ] Dependency direction is clean and one-way
-- [ ] Async-first guidance is applied where I/O exists, with explicit non-blocking UX states
-- [ ] DB/AI/docs decisions are explicit and reflected in structure
-- [ ] Plan references baseline URI: `resource://skills/nicegui/document`
-
----
-
-## PR Checklist (Integrated)
-
-### Implementation
-- [ ] `app.py` app factory + lifespan implemented
-- [ ] FastAPI health route (`/healthz`) implemented
-- [ ] `ui/upload_page.py` implemented
-- [ ] `ui/jobs_page.py` implemented
-- [ ] `ui/__init__.py` explicit page registration implemented
-- [ ] Worker startup/shutdown managed by lifespan
-
-### Testing (MCP-compliant)
-- [ ] Scaffold phase completed first for all Step 5 tests
-- [ ] `--collect-only` passed on scaffolds
-- [ ] Fill phase completed without renaming/re-nesting scaffolded tests
-- [ ] Marker decisions documented (`unit` vs `integration`)
-- [ ] Targeted tests passed
-- [ ] Full suite passed
-
-### Evidence
-- [ ] Validation command outputs captured
-- [ ] Files created/updated listed
-- [ ] MCP prompt resources referenced in implementation notes
-- [ ] Any residual risks/questions documented
-
----
-

docs/mvp/mvp-step6-results.md

@@ -1,50 +0,0 @@
-Step 6 implemented ✅
-
-### Files added
-- `tests/integration/test_pipeline_flow.py`
-- `tests/test_traceability.py`
-
-### What was implemented
-
-#### 1) End-to-end pipeline integration coverage
-`tests/integration/test_pipeline_flow.py` now verifies:
-
-- **Success path**
-  - upload creates queued job
-  - worker processes job
-  - job becomes `transcribed`
-  - transcript text is persisted
-  - error detail remains `None`
-
-- **Failure path**
-  - upload creates queued job
-  - worker processing failure is handled
-  - job becomes `failed`
-  - transcript has `text=None`
-  - `error_detail` contains provider failure reason
-
-#### 2) MVP requirement traceability check
-`tests/test_traceability.py` adds a concrete map:
-
-- REQ-0, REQ-1, REQ-2, REQ-3, REQ-4, REQ-5, REQ-6, REQ-8, REQ-12
-- each REQ maps to one or more existing test files
-- test asserts each mapped path exists (guards against drift)
-
----
-
-### Validation run results
-
-Executed and passed:
-
-1. `uv run pytest --collect-only -q` ✅  
-2. `uv run pytest -m unit -q` ✅  
-3. `uv run pytest -m integration -q` ✅  
-4. `uv run pytest -m "not external" -q` ✅  
-5. `uv run pytest tests/integration/test_pipeline_flow.py -q` ✅  
-6. `uv run pytest tests/ui/test_upload_page.py -q` ✅  
-7. `uv run pytest tests/ui/test_jobs_page.py -q` ✅  
-8. `uv run pytest -q` ✅  
-
-All green.  
-(Only existing non-blocking FastAPI TestClient deprecation warning remains.)
-

docs/mvp/mvp-step6.md

@@ -1,229 +0,0 @@
-## Step 6: Test and Verification Hardening (MVP closeout)
-
-## Objective
-
-Complete MVP verification by building a **requirements-traceable, deterministic test strategy** across unit/integration/external lanes, then enforcing stable validation commands and reporting.
-
-This step finalizes the MVP implementation sequence from `docs/mvp.md` (Step 6 in the build order: tests and automated verification).
-
----
-
-## MCP Resource Integration (what was applied)
-
-I reviewed all top-level skills/prompts from `john-stream-mcp` and integrated the relevant guidance into this plan:
-
-### Directly applied
-- `resource://skills/pytesting/document`
-- `resource://catalog/prompts/pytest-scaffold`
-- `resource://prompts/pytest-scaffold/document`
-- `resource://catalog/prompts/pytest-fill-scaffold`
-- `resource://prompts/pytest-fill-scaffold/document`
-- `resource://skills/nicegui/document`
-- `resource://skills/nicegui-ui-customization/document`
-- `resource://skills/fastapi-uv-docker/document`
-- `resource://skills/python-logging-dictconfig/document`
-- `resource://skills/python-typing/document`
-- `resource://skills/ruff-linting-formating/document`
-
-### Reviewed but informational/non-blocking for Step 6
-- `copilot-customization`, `mcp-details`, `vscode-configuration`, `zensical-docs`, and authoring/shim prompts.
-  - These are primarily customization/documentation tooling resources, not core MVP test-lane blockers.
-  - Step 6 includes optional workflow follow-ups where relevant (e.g., VS Code task conveniences).
-
----
-
-## Scope
-
-### In scope
-- Strengthen and complete test coverage for the shipped MVP slice (Steps 1–5)
-- Add requirement-to-test traceability for REQ-0..REQ-12 (MVP subset emphasized)
-- Enforce deterministic default lanes (`unit`, `integration`)
-- Keep `external` lane opt-in and isolated
-- Validate app/UI/service/worker contracts end-to-end at test level
-
-### Out of scope
-- Major architecture rewrites (async SQLAlchemy migration, queue system, etc.)
-- Full production deployment rollout
-- Post-MVP feature expansion (revision history, search, export)
-
----
-
-## Planned Deliverables
-
-### Test files (new/updated)
-- `tests/test_traceability.py` *(or docs-based traceability matrix if preferred)*
-- `tests/integration/test_pipeline_flow.py` *(upload -> queued -> worker -> transcript/failed)*
-- `tests/ui/test_upload_page.py` (augment loading/error/ready-state checks as practical)
-- `tests/ui/test_jobs_page.py` (augment refresh/error behavior checks as practical)
-- Existing tests touched only when needed; preserve naming/hierarchy unless explicitly approved.
-
-### Optional docs output
-- `docs/tests.md` or `docs/verification.md` with lane definitions and command matrix
-- REQ-to-test mapping table
-
----
-
-## Design and Policy Decisions (MCP-aligned)
-
-1. **Scaffold-first, fill-second workflow is mandatory**
-   - First create/adjust skeletons and collect.
-   - Then fill test bodies.
-   - Preserve scaffold names/docstrings during fill.
-
-2. **Deterministic-first default lanes**
-   - `unit` and `integration` run by default.
-   - `external` remains explicit opt-in.
-
-3. **One behavior target per test**
-   - Short, behavior-focused names.
-   - Precise assertions on observable outcomes.
-
-4. **Test double discipline (from pytesting skill)**
-   - Prefer real-input/real-object paths first.
-   - If monkeypatch/mocks/fakes are needed for a boundary, keep narrowly scoped.
-   - Avoid call-only assertions.
-
-5. **NiceGUI responsiveness expectations**
-   - Verify loading/success/error state transitions where testable.
-   - Ensure user-facing feedback behavior is covered.
-
-6. **FastAPI/ops baseline checks**
-   - Keep `/healthz` route validation in default lanes.
-   - Keep startup/shutdown lifecycle assertions present.
-
----
-
-## Implementation Plan + Checklist
-
-## Phase A — Coverage and traceability audit
-
-- [ ] Build a REQ-to-test matrix for MVP requirements:
-  - [ ] REQ-0, REQ-1, REQ-2, REQ-3, REQ-4, REQ-5, REQ-6, REQ-8, REQ-12
-- [ ] Identify weak spots:
-  - [ ] full pipeline integration (service + worker + persistence)
-  - [ ] UI state transition assertions (loading/error/ready)
-  - [ ] failure-path persistence verification robustness
-- [ ] Record current baseline command results before edits
-
-## Phase B — Scaffold phase (pytest-scaffold resources)
-
-Target modules/areas:
-- pipeline integration flow
-- UI behavior augmentations
-- traceability checks/document validators (if test-backed)
-
-- [ ] Scaffold new/adjusted test files/classes/methods only
-- [ ] Keep one-line intent docstrings
-- [ ] Keep behavior-focused names
-- [ ] Run: `uv run pytest --collect-only -q`
-
-## Phase C — Fill phase (pytest-fill-scaffold resources)
-
-- [ ] Fill scaffolded methods with deterministic setup/assertions
-- [ ] Preserve scaffold names/hierarchy/docstrings
-- [ ] Add/adjust fixtures at nearest useful scope
-- [ ] Keep DB tests in `integration`; pure helper tests in `unit`
-
-### Required coverage additions
-
-#### Pipeline integration
-- [ ] Upload service creates document/job and file path persists
-- [ ] Worker success path creates transcript and terminal status
-- [ ] Worker failure path persists error detail and terminal failed status
-- [ ] Queue-empty behavior remains stable (`False` return / no side effects)
-
-#### UI behavior (practical, testable boundaries)
-- [ ] Upload helper flow success and UploadError surfacing
-- [ ] Jobs data helpers return stable normalized view models
-- [ ] Refresh/detail fallback behavior for missing/invalid job IDs
-
-#### Traceability
-- [ ] Every in-scope MVP REQ has at least one mapped test/assertion point
-- [ ] Document and/or enforce mapping consistency
-
-## Phase D — External lane stability
-
-- [ ] Keep real-image external tests isolated under `@pytest.mark.external`
-- [ ] Ensure no external test leaks into default runs
-- [ ] Confirm artifact capture behavior remains stable
-
-## Phase E — Quality gates and workflow
-
-- [ ] Confirm logging/lifecycle startup tests still pass after changes
-- [ ] (If enabled) add/update lint/type check commands in docs:
-  - [ ] Ruff lane (if configured)
-  - [ ] typing lane (if configured)
-- [ ] Optionally add VS Code task aliases for test lanes (non-blocking)
-
----
-
-## Marker and Fixture Strategy
-
-- `unit`: pure logic, helper behavior, formatting/normalization
-- `integration`: DB + service + app lifecycle contracts
-- `external`: live provider/real image checks only
-
-Fixture policy:
-- Prefer reusable fixtures in `tests/conftest.py` only when broadly shared
-- Use subtree/local fixtures for domain-specific setup
-- Keep setup explicit and readable
-
----
-
-## Validation Sequence (strict)
-
-- [ ] `uv run pytest --collect-only -q`
-- [ ] `uv run pytest -m unit -q`
-- [ ] `uv run pytest -m integration -q`
-- [ ] `uv run pytest -m "not external" -q`
-- [ ] `uv run pytest tests/integration/test_pipeline_flow.py -q` *(if added)*
-- [ ] `uv run pytest tests/ui/test_upload_page.py -q`
-- [ ] `uv run pytest tests/ui/test_jobs_page.py -q`
-- [ ] `uv run pytest -q`
-
-Optional external verification:
-- [ ] `uv run pytest -m external -q`
-
----
-
-## Guardrails
-
-- Do not rename/re-nest scaffolded tests during fill unless explicitly requested.
-- Do not broaden external dependencies in default lane.
-- Do not add flaky timing-based assertions; keep deterministic boundaries.
-- Keep business logic out of UI tests; test through service/helper boundaries.
-- Preserve one-way dependency direction in test setup patterns.
-
----
-
-## Definition of Done (Step 6)
-
-- [ ] MVP requirement coverage is explicitly traceable
-- [ ] Deterministic lanes (`unit` + `integration`) are stable and green
-- [ ] External lane remains opt-in and green when enabled
-- [ ] Pipeline success/failure lifecycle paths are verified end-to-end
-- [ ] UI helper/state behavior has explicit success/error assertions
-- [ ] Full suite passes with `uv run pytest -q`
-- [ ] Verification evidence is captured in implementation report
-
----
-
-## PR Checklist (Step 6)
-
-### Implementation
-- [ ] Added/updated test files per scoped gaps
-- [ ] Added REQ traceability mapping
-- [ ] Kept default lanes deterministic
-- [ ] Preserved scaffold invariants during fill
-
-### Testing (MCP-compliant)
-- [ ] Used scaffold prompt flow first
-- [ ] Used fill prompt flow second
-- [ ] Preserved naming/docstrings/hierarchy
-- [ ] Marker usage documented (`unit`, `integration`, `external`)
-
-### Evidence
-- [ ] Collected command outputs in strict order
-- [ ] Listed files changed
-- [ ] Listed MCP resources used and why
-- [ ] Noted residual risks/open questions (if any)

docs/mvp/mvp-step7-results.md

@@ -1,134 +0,0 @@
-## Step 7 Results: Error Handling Standardization and Operational Visibility
-
-## Summary
-
-Step 7 was implemented across the MVP runtime boundaries with a shared error taxonomy, actionable UI error surfacing, worker failure normalization, and API error envelope handling.
-
-All required validation gates in `docs/step7.md` were executed and passed.
-
----
-
-## Scope Delivered
-
-### Implemented
-- Shared application error contract and taxonomy
-- Service-layer error normalization (upload + transcription)
-- UI error presentation helpers with suggested actions and error references
-- Worker failure persistence format with category/suggestion/error_id markers
-- API exception handlers for structured error responses
-- Targeted tests for new error contract behavior
-
-### Not implemented in this step
-- External lane execution (`-m external`) was not required for Step 7 completion and was not run in this pass.
-
----
-
-## Files Added
-
-- `src/transcription/errors.py`
-- `src/transcription/api/errors.py`
-- `src/transcription/ui/error_presenter.py`
-- `tests/test_errors.py`
-- `tests/api/test_error_responses.py`
-- `docs/step7.md`
-
-## Files Updated
-
-- `src/transcription/app.py`
-- `src/transcription/services/upload.py`
-- `src/transcription/services/transcription.py`
-- `src/transcription/ui/upload_page.py`
-- `src/transcription/ui/jobs_page.py`
-- `src/transcription/worker.py`
-- `tests/services/test_upload.py`
-- `tests/services/test_transcription.py`
-- `tests/services/test_worker.py`
-- `tests/integration/test_pipeline_flow.py`
-- `uv.lock`
-
----
-
-## Implementation Notes by Phase
-
-### Phase A/B (Foundation)
-- Added `ErrorCategory` enum and `AppError` base type in `src/transcription/errors.py`.
-- Added helper utilities:
-  - `new_error_id()`
-  - `build_error_envelope(...)`
-  - `classify_unexpected_error(...)`
-  - `format_error_detail(...)`
-
-### Phase C (Service/Provider normalization)
-- `UploadError` now extends `AppError` and includes category/suggestion/retriable metadata.
-- `PromptLoadError` and `TranscriptionError` now extend `AppError`.
-- Provider failures are mapped with deterministic category semantics (auth/payload/provider-failure cases).
-
-### Phase D (UI visibility)
-- Added `src/transcription/ui/error_presenter.py`.
-- Upload and jobs pages now use centralized UI error rendering and summary helpers.
-- UI error paths now include more visible/actionable guidance and reference IDs.
-
-### Phase E (Worker failure handling)
-- Worker now normalizes exception handling into structured persisted `error_detail` strings with:
-  - category marker
-  - suggestion marker
-  - error_id marker
-- Logging now includes category/error_id context in failure paths.
-
-### Phase F (API envelope)
-- Added `src/transcription/api/errors.py` and registered handlers in app factory.
-- AppError and unexpected exceptions now serialize to stable API envelopes with mapped status codes.
-
----
-
-## Validation Commands and Outcomes
-
-All commands were executed with `uv run python -m pytest ...` and completed successfully.
-
-1. `uv run python -m pytest tests/test_errors.py -q` ✅
-2. `uv run python -m pytest tests/services/test_upload.py -q` ✅
-3. `uv run python -m pytest tests/services/test_transcription.py -q` ✅
-4. `uv run python -m pytest tests/providers/test_openrouter.py -q` ✅
-5. `uv run python -m pytest tests/services/test_worker.py -q` ✅
-6. `uv run python -m pytest tests/integration/test_pipeline_flow.py -q` ✅
-7. `uv run python -m pytest tests/api/test_error_responses.py -q` ✅
-8. `uv run python -m pytest tests/ui/test_upload_page.py -q` ✅
-9. `uv run python -m pytest tests/ui/test_jobs_page.py -q` ✅
-10. `uv run python -m pytest -m "not external" -q` ✅
-11. `uv run python -m pytest --collect-only -q` ✅
-12. `uv run python -m pytest -m unit -q` ✅
-13. `uv run python -m pytest -m integration -q` ✅
-14. `uv run python -m pytest tests/integration/test_pipeline_flow.py -q` ✅
-15. `uv run python -m pytest tests/ui/test_upload_page.py -q` ✅
-16. `uv run python -m pytest tests/ui/test_jobs_page.py -q` ✅
-17. `uv run python -m pytest -q` ✅
-
-Observed warning (non-blocking): Starlette/FastAPI TestClient deprecation warning related to `httpx` package naming.
-
----
-
-## Policy Alignment Check (`docs/error_handling.md`)
-
-Aligned items:
-- Stable taxonomy categories are implemented.
-- Unexpected errors are normalized.
-- User-facing UI paths include actionable guidance and references.
-- Worker persistence includes trace-friendly failure detail.
-- API error responses are structured and category-aware.
-
-Follow-up candidates:
-- Add richer UI tests that validate rendered suggested-action content end-to-end (current tests focus helper/service contracts).
-- Consider typed storage fields for error metadata instead of packed `error_detail` strings in a future schema revision.
-
----
-
-## Step 7 Definition of Done Status
-
-- [x] Shared error taxonomy implemented across MVP layers
-- [x] GUI error paths upgraded for visibility/actionability
-- [x] Worker failure persistence and log context standardized
-- [x] API error envelope handling added and tested
-- [x] Phase-level and full-suite validation gates passed
-- [x] Results documented in this report
-
-Step 7 is complete.

docs/mvp/mvp-step7.md

@@ -1,267 +0,0 @@
-## Step 7: Error Handling Standardization and Operational Visibility
-
-## Objective
-
-Apply the canonical error policy from `docs/error_handling.md` to the MVP implementation so failures are:
-
-- consistently classified
-- visibly surfaced in the GUI
-- paired with suggested corrective actions
-- traceable through logs via error reference IDs
-- validated through deterministic tests after each phase
-
-This step extends MVP hardening by converting current ad hoc exception behavior into a stable cross-layer contract.
-
----
-
-## Scope
-
-### In scope
-- Introduce a shared application error contract and taxonomy implementation
-- Normalize service/provider exceptions into taxonomy categories
-- Improve GUI error visibility and suggested-action UX
-- Standardize worker failure persistence and logging context
-- Add API error-envelope policy hooks for current/future endpoints
-- Add targeted tests and phase-level/full-suite validation gates
-
-### Out of scope
-- Major architecture rewrites (distributed queue, multi-service decomposition)
-- Post-MVP feature expansion unrelated to error handling
-- Full observability platform rollout (tracing backends, APM)
-
----
-
-## Policy Source of Truth
-
-- Canonical policy document: `docs/error_handling.md`
-- If implementation and policy diverge, policy is authoritative and code/tests must be updated.
-
----
-
-## Planned Deliverables
-
-### Runtime code
-- `src/transcription/errors.py` *(new shared contract module)*
-- `src/transcription/ui/error_presenter.py` *(new UI error rendering helper)*
-- Updates to:
-  - `src/transcription/services/upload.py`
-  - `src/transcription/services/transcription.py`
-  - `src/transcription/providers/openrouter.py`
-  - `src/transcription/worker.py`
-  - `src/transcription/ui/upload_page.py`
-  - `src/transcription/ui/jobs_page.py`
-  - `src/transcription/api/*` *(as needed for envelope/handlers)*
-
-### Tests
-- `tests/test_errors.py` *(new shared error contract tests)*
-- updates/additions in:
-  - `tests/services/test_upload.py`
-  - `tests/services/test_transcription.py` *(add if missing)*
-  - `tests/providers/test_openrouter.py`
-  - `tests/services/test_worker.py`
-  - `tests/ui/test_upload_page.py`
-  - `tests/ui/test_jobs_page.py`
-  - `tests/api/test_error_responses.py` *(new, if API handlers added)*
-
-### Documentation
-- Update `docs/error_handling.md` only if implementation reveals policy gaps
-- Capture validation evidence in a Step 7 results artifact (`docs/step7-results.md`)
-
----
-
-## Design and Policy Decisions
-
-1. **Stable taxonomy contract**
-   - Use policy categories as stable identifiers (`validation_error`, `user_input_error`, etc.).
-
-2. **Actionable UX is mandatory**
-   - User-visible errors must include a suggested course of action.
-
-3. **Traceability by default**
-   - Non-trivial errors include an `error_id` in both logs and user-facing output.
-
-4. **Safe surface / rich logs**
-   - UI/API show safe summaries; logs retain diagnostic detail and traceback.
-
-5. **Deterministic verification cadence**
-   - Targeted tests after each change batch, then phase-level regression gates.
-
----
-
-## Implementation Plan + Checklist
-
-## Phase A — Baseline Validation and Gap Confirmation
-
-- [ ] Run baseline tests before changes
-- [ ] Record baseline outputs and any known flaky behavior
-- [ ] Confirm current behavior against `docs/error_handling.md` requirements
-
-### Validation gate
-- [ ] `uv run pytest -m "not external" -q`
-- [ ] `uv run pytest -q`
-
-## Phase B — Shared Error Contract Foundation
-
-- [ ] Add `src/transcription/errors.py` with:
-  - [ ] stable category enum
-  - [ ] base `AppError` (category/message/suggestion/error_id/retriable)
-  - [ ] helpers for error-id generation and fallback classification
-- [ ] Keep category names aligned with `docs/error_handling.md`
-
-### Tests
-- [ ] Add `tests/test_errors.py`
-  - [ ] category stability assertions
-  - [ ] error_id creation behavior
-  - [ ] fallback classification for unexpected exceptions
-
-### Validation gate
-- [ ] `uv run pytest tests/test_errors.py -q`
-- [ ] `uv run pytest -m "not external" -q`
-
-## Phase C — Service and Provider Normalization
-
-- [ ] Refactor upload service exceptions to shared taxonomy
-- [ ] Refactor transcription service exceptions to shared taxonomy
-- [ ] Normalize provider adapter failures into deterministic categories
-- [ ] Preserve causal chaining (`raise ... from exc`)
-
-### Tests
-- [ ] Extend `tests/services/test_upload.py`:
-  - [ ] empty payload category/suggestion
-  - [ ] unsupported extension category/suggestion
-  - [ ] persistence failure category mapping
-- [ ] Add/extend `tests/services/test_transcription.py`:
-  - [ ] missing/empty prompt behavior
-  - [ ] unsupported file type behavior
-  - [ ] provider failure mapping behavior
-- [ ] Extend `tests/providers/test_openrouter.py`:
-  - [ ] auth error mapping
-  - [ ] malformed response mapping
-
-### Validation gate
-- [ ] `uv run pytest tests/services/test_upload.py -q`
-- [ ] `uv run pytest tests/services/test_transcription.py -q`
-- [ ] `uv run pytest tests/providers/test_openrouter.py -q`
-- [ ] `uv run pytest -m "not external" -q`
-
-## Phase D — GUI Visibility and Suggested Actions
-
-- [ ] Add `src/transcription/ui/error_presenter.py`
-- [ ] Update upload/jobs pages to use centralized error presentation
-- [ ] Ensure GUI surfaces:
-  - [ ] user-safe message
-  - [ ] suggested action
-  - [ ] error reference ID
-  - [ ] optional technical details panel
-- [ ] Replace raw `str(exc)` UX where policy requires safer messaging
-
-### Tests
-- [ ] Extend `tests/ui/test_upload_page.py` for actionable error UX paths
-- [ ] Extend `tests/ui/test_jobs_page.py` for refresh/detail error guidance
-- [ ] Add `tests/ui/test_error_presenter.py` *(optional but recommended)*
-
-### Validation gate
-- [ ] `uv run pytest tests/ui/test_upload_page.py -q`
-- [ ] `uv run pytest tests/ui/test_jobs_page.py -q`
-- [ ] `uv run pytest -m "not external" -q`
-
-## Phase E — Worker Failure Persistence and Logging Context
-
-- [ ] Update worker failure handling to classify errors before persistence
-- [ ] Ensure failed jobs persist actionable, structured error detail
-- [ ] Add log context fields where available (`error_id`, `category`, `operation`, `job_id`)
-- [ ] Ensure retry semantics are explicit and bounded (or clearly documented as deferred)
-
-### Tests
-- [ ] Extend `tests/services/test_worker.py`:
-  - [ ] missing document failure contract
-  - [ ] provider/transcription failure contract
-  - [ ] persisted error detail includes category/suggestion/error_id markers
-- [ ] Validate integration failure flow in `tests/integration/test_pipeline_flow.py`
-
-### Validation gate
-- [ ] `uv run pytest tests/services/test_worker.py -q`
-- [ ] `uv run pytest tests/integration/test_pipeline_flow.py -q`
-- [ ] `uv run pytest -m "not external" -q`
-
-## Phase F — API Error Envelope Alignment (Current + Future Routes)
-
-- [ ] Add shared API error serialization utilities/handlers (as needed)
-- [ ] Ensure API responses can include:
-  - [ ] `error_id`
-  - [ ] `category`
-  - [ ] `message`
-  - [ ] `suggestion`
-  - [ ] `timestamp`
-- [ ] Map categories to HTTP status guidance from `docs/error_handling.md`
-
-### Tests
-- [ ] Add `tests/api/test_error_responses.py` *(if handlers added)*
-- [ ] Keep `tests/api/test_health.py` passing
-
-### Validation gate
-- [ ] `uv run pytest tests/api/test_error_responses.py -q` *(if added)*
-- [ ] `uv run pytest tests/api/test_health.py -q`
-- [ ] `uv run pytest -m "not external" -q`
-
-## Phase G — Final Regression and Documentation Closure
-
-- [ ] Reconcile implementation details with `docs/error_handling.md`
-- [ ] Update policy doc only where required by confirmed implementation learning
-- [ ] Capture execution evidence in `docs/step7-results.md`
-
-### Final validation sequence (strict)
-- [ ] `uv run pytest --collect-only -q`
-- [ ] `uv run pytest -m unit -q`
-- [ ] `uv run pytest -m integration -q`
-- [ ] `uv run pytest -m "not external" -q`
-- [ ] `uv run pytest tests/integration/test_pipeline_flow.py -q`
-- [ ] `uv run pytest tests/ui/test_upload_page.py -q`
-- [ ] `uv run pytest tests/ui/test_jobs_page.py -q`
-- [ ] `uv run pytest -q`
-
-Optional:
-- [ ] `uv run pytest -m external -q`
-
----
-
-## Guardrails
-
-- Do not weaken user-facing clarity to expose raw internals.
-- Do not introduce silent exception swallowing.
-- Do not break category-name stability without policy update.
-- Do not merge phase changes without passing that phase validation gate.
-- Keep targeted tests fast and deterministic; isolate external-provider tests under `external`.
-
----
-
-## Definition of Done (Step 7)
-
-- [ ] Shared error taxonomy is implemented and used across MVP layers
-- [ ] GUI error experiences are visible, actionable, and traceable
-- [ ] Worker persists and logs failure context consistently
-- [ ] API error contract path is aligned for current/future endpoints
-- [ ] Phase-by-phase test gates pass
-- [ ] Full suite remains green (`uv run pytest -q`)
-- [ ] Step 7 results are documented with evidence
-
----
-
-## PR Checklist (Step 7)
-
-### Implementation
-- [ ] Added shared error contract module
-- [ ] Updated service/provider/worker/UI error handling paths
-- [ ] Added actionable GUI guidance for user-visible failures
-- [ ] Added error reference IDs for traceability
-
-### Testing
-- [ ] Added/updated tests per phase scope
-- [ ] Ran targeted phase tests after each change batch
-- [ ] Ran `not external` regression at each phase boundary
-- [ ] Ran full suite before closeout
-
-### Documentation and Evidence
-- [ ] `docs/error_handling.md` reviewed for alignment
-- [ ] `docs/step7-results.md` includes executed command outputs
-- [ ] Residual risks and deferred items explicitly recorded

docs/mvp/mvp.md

@@ -1,209 +0,0 @@
-## MVP Definition: Historical Document Transcription System
-
-### 1. MVP Objective
-Deliver the thinnest possible end-to-end vertical slice — a user uploads an image of a document, the system transcribes it via the OpenRouter Python SDK, and the user reads the resulting transcript — with just enough persistence and structure to validate the core value proposition: *can AI-driven transcription, guided by curated prompts, produce useful verbatim transcripts of historical family documents?*  
-
-The MVP deliberately defers full-text search, export, revision history, MongoDB, and timeline assembly. These are additive features that don't need validation before the core transcription loop is proven.
-
----
-
-### 2. Core User Story
-*As a family historian, I can upload a photo of a historical document, wait for it to be transcribed, and read the verbatim transcript — so I can evaluate whether this system will work for my thousands of documents.*
-
----
-
-### 3. In-Scope Requirements (from ```requirements.md```)  
-
-| Requirement | ID | MVP Rationale |
-| --- |  --- |  --- |
-| End-to-end transcription with lifecycle state | REQ-0 | This is the MVP. |
-| Upload one or more images from the web UI | REQ-1 | Core entry point. MVP supports single-image upload (multi-image is a stretch goal). |
-| Asynchronous processing → transcription or failure | REQ-2 | Validates the AI transcription pipeline. |
-| Persist and expose job states (queued → processing → transcribed/failed) | 	REQ-3 | Minimum feedback loop for the user. |
-| Persist transcription output and failure details | REQ-4 | User must be able to read the result. |
-| UI views for status and transcript reading | REQ-5 | The user needs to see what happened. |
-| Background processing to keep UI responsive | REQ-6 | Essential for usability during long AI calls. |
-| Centralized config and logging at startup | REQ-8 | Small effort, high payoff for debugging. |
-| Store transcription prompts as Markdown files | REQ-12 | Core to the Prompt Curation Policy in intent.md. Start with a single prompt file. |
-
-
-### Deferred to Post-MVP
-| Requirement | ID | Why Deferred |
-| ---  | --- | --- |
-| Lifespan-owned runtime resources (engine, session factory, etc.) | REQ-7 | Important for production robustness, but a simple global or module-level setup is adequate for MVP validation. |
-| Docker Compose (app + PostgreSQL + optional MongoDB) | REQ-9 | MVP runs locally with SQLite to eliminate container overhead during rapid iteration. PostgreSQL migration is Stage 1 hardening. |
-| Explicit, opt-in schema bootstrap | REQ-10 | MVP uses auto-create-tables at startup (SQLModel create_all). Production schema discipline comes after the model stabilizes. |
-| Service-backed persistence for core data | REQ-11 | MVP uses a thin repository layer over SQLite. Full service abstraction follows once the domain model is proven. |
-
----
-
-### 4. MVP Feature Set
-#### Feature 1: Document Upload (UI)
-* A single NiceGUI page with a file-upload widget (accepts .jpg, .png, .tiff, .pdf).
-* On upload: save the file to a local uploads/ directory, create a Document record, create a Job record with status queued.
-* Minimal metadata capture: original filename, upload timestamp.
-
-#### Feature 2: Asynchronous Transcription Worker
-* An in-process background worker (Python asyncio task or BackgroundTasks) that:
-    1. Picks up queued jobs.
-    2. Transitions status to processing.
-    3. Sends the image + the curated Markdown prompt to an AI vision model via OpenRouter.
-    4. On success: saves the transcript text, transitions to transcribed.
-    5. On failure: saves the error detail, transitions to failed.
-
-#### Feature 3: Transcription Prompt (Markdown Asset)
-* A single Markdown file (prompts/transcribe_document.md) encoding the verbatim transcription rules from intent.md (the Document Issues table, scholarly guidelines, etc.).
-* The worker reads this file at invocation time and injects it as the system/user prompt.
-
-#### Feature 4: Job Status & Transcript Viewer (UI)
-* A job list page showing all jobs with their current status (queued / processing / transcribed / failed).
-* A transcript detail page showing:
-    * The original uploaded image (rendered inline).
-    * The transcription text (or the failure reason).
-    * Timestamp metadata.
-
-#### Feature 5: Minimal Persistence (SQLite + SQLModel)
-* Three tables/models:
-    * Document: id, filename, file_path, uploaded_at.
-    * Job: id, document_id (FK), status, created_at, updated_at.
-    * Transcript: id, job_id (FK), text, error_detail, created_at.
-* SQLite database file stored locally. Auto-created on first startup.
-
-#### Feature 6: Centralized Configuration
-* A single config.py (or Pydantic BaseSettings) loading:
-    * PROVIDER (fixed to openrouter for MVP)
-    * OPENROUTER_API_KEY (required)
-    * PROVIDER_MODEL (default: OpenRouter model slug for vision transcription)
-    * OPENROUTER_HTTP_REFERER (optional; app attribution)
-    * OPENROUTER_APP_TITLE (optional; app attribution)
-    * DATABASE_URL (default: sqlite:///./transcription.db)
-    * UPLOAD_DIR (default: ./uploads)
-    * PROMPT_DIR (default: ./prompts)
-
-#### Feature 7: MVP Dependency Baseline (OpenRouter-Centric)
-* Runtime dependencies:
-    * openrouter (official OpenRouter Python SDK)
-    * pydantic
-    * pydantic-settings
-    * sqlmodel
-* Explicitly out of MVP runtime dependencies:
-    * google-genai (deferred until/if Gemini is introduced post-MVP)
-
----
-
-### 5. MVP Architecture (Simplified)
-
-```Apply
-┌─────────────────────────────────────────────┐
-│              NiceGUI Web UI                 │
-│  ┌──────────────┐   ┌───────────────────┐   │
-│  │ Upload Page  │   │ Jobs / Transcript │   │
-│  └──────┬───────┘   └───────┬───────────┘   │
-│         │                   │               │
-│         ▼                   ▼               │
-│     ┌───────────────────────────┐           │
-│     │   Application Service     │           │
-│     │  (upload, job lifecycle)  │           │
-│     └─────┬─────────────┬───────┘           │
-│           │             │                   │
-│     ┌─────▼─────┐ ┌─────▼───────────────┐   │
-│     │ SQLite DB │ │ Background Worker   │   │
-│     │ (SQLModel)│ │ → AI Vision Provider│   │
-│     └───────────┘ └─────────────────────┘   │
-│                          │                  │
-│                    ┌─────▼──────┐           │
-│                    │ prompts/   │           │
-│                    │ *.md files │           │
-│                    └────────────┘           │
-└─────────────────────────────────────────────┘
-```
-
----
-
-#### 6. Proposed File Structure
-
-```Apply
-project-root/
-├── docs/                          # (existing)
-├── prompts/
-│   └── transcribe_document.md     # curated transcription prompt
-├── src/
-│   └── transcription/
-│       ├── __init__.py
-│       ├── app.py                 # FastAPI + NiceGUI app entrypoint
-│       ├── config.py              # Pydantic BaseSettings
-│       ├── models.py              # SQLModel: Document, Job, Transcript
-│       ├── db.py                  # engine, session, create_all
-│       ├── providers/
-│       │   ├── __init__.py
-│       │   ├── base.py            # provider interface (transcribe contract)
-│       │   ├── openrouter.py      # OpenRouter via official Python SDK
-│       ├── services/
-│       │   ├── __init__.py
-│       │   ├── upload.py          # save file + create records
-│       │   └── transcription.py   # call provider, update job
-│       ├── worker.py              # background job loop
-│       └── ui/
-│           ├── __init__.py
-│           ├── upload_page.py     # NiceGUI upload page
-│           └── jobs_page.py       # NiceGUI job list + detail
-├── tests/
-│   ├── test_models.py
-│   ├── test_upload.py
-│   └── test_transcription.py
-├── pyproject.toml
-└── README.md
-```
-
----
-
-#### 7. MVP Validation Criteria
-The MVP is considered validated when:
-
-1. ✅ A user can upload an image of a document through the browser.
-2. ✅ The system asynchronously sends the image to the configured AI vision model with the curated prompt.
-3. ✅ The transcript (or failure reason) is persisted and visible in the UI.
-4. ✅ The transcription follows verbatim scholarly rules defined in intent.md (spot-checked by the user on real family documents).
-5. ✅ The transcription prompt is stored as a standalone Markdown file and can be edited without code changes.
-6. ✅ Job status transitions are visible: queued → processing → transcribed/failed.
-
----
-
-### 8. Key Feedback Questions the MVP Should Answer
-These are the real unknowns this MVP exists to resolve:
-
-| #	| Question | How We Learn |
-| --- | --- | --- |
-| 1	| Is AI transcription quality good enough for this document corpus?	| User reviews 20–50 real transcriptions against originals. |
-| 2	| Does the verbatim prompt produce scholarly-quality output, or does it need major rework?	| Compare output to the Document Issues table rules in intent.md. |
-| 3	| What document types are hardest (old cursive, faded ink, pencil, postcards)?	| Track which uploads produce failed or low-quality results. |
-| 4	| Is single-image upload sufficient, or is batch upload needed early?	| User friction during real scanning sessions. |
-| 5	| What metadata is missing that the user wishes they could capture at upload time?	| User feedback after processing real batches. |
-
----
-
-#### 9. What Comes After MVP (Immediate Post-MVP)
-Once the core transcription loop is validated, the next priorities (aligned to Architecture Stage 1) are:
-
-1. **Multi-image upload** — process a batch from a scanning session.
-2. **PostgreSQL migration** — swap SQLite for containerized PostgreSQL (REQ-9, REQ-10).
-3. **Revision history** — allow the user to edit/correct transcripts with immutable version tracking.
-4. **Full-text search** — search across all accepted transcripts.
-5. **Repository/service layer formalization** — proper ports/adapters as the domain model stabilizes.
-6. **Docker Compose deployment** — containerize the app for reproducible operation.
-
----
-
-#### 10. Implementation Approach
-Recommended build order for the MVP (each step produces a testable increment):
-
-| Step | Deliverable | Validates |
-| --- | --- | --- |
-| 1 | config.py + models.py + db.py — data layer with SQLite | Schema and config foundation |
-| 2 | prompts/transcribe_document.md — curated prompt from intent.md | Prompt asset pattern |
-| 3 | services/transcription.py + providers/ — call AI vision provider with prompt + image | Core AI integration |
-| 4 | services/upload.py + worker.py — upload handling + background job loop | End-to-end pipeline (CLI-testable) |
-| 5 | ui/upload_page.py + ui/jobs_page.py — NiceGUI pages | User-facing interface |
-| 6 | tests/ — unit + integration tests	Automated verification |
-
-This MVP is deliberately narrow: **one prompt, one provider (OpenRouter), one user, one image at a time, SQLite, no containers**. Every omission is intentional — the goal is to get real family documents through the transcription pipeline as fast as possible and let the quality of the output guide every subsequent decision.

docs/requirements.md

@@ -1,84 +0,0 @@
-## Document Transcription System Requirements
-
-This page captures a SysML v1.6-style requirements baseline for the production system described in [index.md](index.md). The model is represented as concise tables and traceability lists that preserve SysML-style IDs and relationship semantics.
-
-## Scope
-
-- System of interest: the single Python application service (NiceGUI + FastAPI) with PostgreSQL as the relational system of record and optional MongoDB for document-oriented persistence.
-- Operational context: local-first execution with Docker Compose and an intentionally lightweight production trajectory.
-- Primary concern: end-to-end transcription job lifecycle from upload through completion or failure.
-
-## Requirements Model (Concise Text Form)
-
-### Requirements
-
-| ID | Category | Requirement | Risk | Verify Method |
-| --- | --- | --- | --- | --- |
-| REQ-0 | System | Provide end-to-end document transcription with persistent, inspectable lifecycle state. | medium | demonstration |
-| REQ-1 | Functional | Allow users to upload one or more document images from the web UI. | low | test |
-| REQ-2 | Functional | Run each upload through asynchronous processing that returns a transcription or explicit failure. | high | test |
-| REQ-3 | Functional | Persist and expose job states: upload, queued, processing, transcribed, failed, completed. | high | inspection |
-| REQ-4 | Functional | Persist transcription output, processing history, and failure details. | medium | test |
-| REQ-5 | Interface | Expose API and UI views for status inspection and completed transcription reading. | medium | demonstration |
-| REQ-6 | Performance | Trigger background processing on upload to preserve UI responsiveness. | medium | analysis |
-| REQ-7 | Design Constraint | Keep lifespan-owned runtime resources: SQLAlchemy engine, async session factory, worker resources, provider clients. | medium | inspection |
-| REQ-8 | Design Constraint | Initialize configuration and logging once at startup through centralized mechanisms. | low | inspection |
-| REQ-9 | Design Constraint | Use Docker Compose baseline of app plus PostgreSQL; allow optional MongoDB container when enabled. | medium | demonstration |
-| REQ-10 | Design Constraint | Keep schema bootstrap explicit and opt-in; normal startup does not mutate production schema. | high | inspection |
-| REQ-11 | Design Constraint | Use service-backed persistence for core document and job data. | medium | inspection |
-| REQ-12 | Design Constraint | Store transcription prompts as individual Markdown artifacts for iterative refinement. | medium | inspection |
-
-### Requirement Relationships
-
-- Contains: REQ-0 contains REQ-1 through REQ-12.
-- Derives: REQ-2 -> REQ-3, REQ-3 -> REQ-4.
-- Traces: REQ-5 -> REQ-3.
-- Refines: REQ-6 -> REQ-2.
-
-### Architecture Elements
-
-| Element | Type | Doc Reference |
-| --- | --- | --- |
-| UI | NiceGUI pages | src/transcription/ui/pages |
-| API | FastAPI routes | src/transcription/api/routes.py |
-| GRAPH | Async processing workflow | src/transcription/services, src/transcription/ai |
-| DBREL | PostgreSQL + SQLModel relational persistence | src/transcription/db |
-| DBDOC | MongoDB document persistence | src/transcription/db, src/transcription/services |
-| OPS | Docker Compose runtime | docker-compose.yml |
-| PROMPTS | Transcription prompt artifact library (Markdown files) | .github/prompts, docs |
-| TESTS | Pytest verification suite | tests |
-
-### Satisfaction Mapping
-
-- UI satisfies REQ-1, REQ-5.
-- API satisfies REQ-5.
-- GRAPH satisfies REQ-2, REQ-6.
-- DBREL satisfies REQ-3, REQ-10.
-- DBDOC satisfies REQ-4, REQ-11.
-- OPS satisfies REQ-9.
-- PROMPTS satisfies REQ-12.
-
-### Verification Mapping
-
-- TESTS verifies REQ-1, REQ-2, REQ-3, REQ-4, REQ-5, REQ-10, REQ-11, REQ-12.
-
-## Requirement Notes
-
-- Requirement IDs (`REQ-*`) are stable references for planning, implementation, and test traceability.
-- The model uses compact tables and traceability lists for renderer compatibility while preserving SysML-style requirement IDs and relationship semantics.
-- Requirement categories (functional, interface, performance, and design constraints) are preserved as explicit REQ entries and relationship labels to keep change impact visible.
-- PostgreSQL containerization and optional MongoDB containerization are both treated as extremely lightweight and simple operational choices in this architecture.
-
-## Verification Intent
-
-- Demonstration: validate end-to-end behavior via running system flows and operator-visible outcomes.
-- Inspection: verify architecture and startup/runtime policies in code and configuration.
-- Analysis: evaluate asynchronous execution behavior and design sufficiency.
-- Test: automate behavioral checks through pytest suites and service-level tests.
-
-## Glossary
-
-- Document-oriented persistence: A storage approach that uses flexible document structures for variable data shapes.
-- Prompt artifact: A single Markdown file that defines one transcription prompt and is revised independently.
-- SysML: Systems Modeling Language used to express structured requirements and traceability.
-- System of record: The authoritative persistent store for canonical business data.

docs/ui/README.md

@@ -0,0 +1,61 @@
+# UI Behavioral Contracts
+
+## Purpose
+
+This directory defines the current user-facing behavior of the NiceGUI application. It records what each page is for, which routes and actions it exposes, what information it presents, and how success, empty, validation, and failure states behave.
+
+These documents are written for maintainers and AI contributors. They are behavioral contracts, not historical implementation notes and not substitutes for the database schema.
+
+## Current Page Contracts
+
+- [Home](pages/home.md)
+- [Documents](pages/documents.md)
+- [People](pages/people.md)
+- [Jobs](pages/jobs.md)
+- [Sources](pages/sources.md)
+
+NiceGUI registers the routes shown in each contract without the `/ui` prefix. The application mounts NiceGUI under `/ui`, so `/documents` in page code is served to a browser as `/ui/documents`.
+
+## Authority Hierarchy
+
+When documents disagree, use this order:
+
+1. User-facing page intent and accepted behavior: the page contracts in this directory.
+2. Visual and interaction styling: [UI Style Guide](../invariant/ui_style_guide.md).
+3. UI dependency and ownership boundaries: [UI contributor instructions](../../.github/instructions/ui.instructions.md).
+4. Durable failure behavior: [Error Handling invariant](../invariant/error_handling.md).
+5. Durable AI evidence behavior: [Digital Evidence and AI Processing Provenance](../invariant/ai_evidence_and_provenance.md).
+6. Data definitions and relationships: current models plus the [V4 schema](../ver4/schema_v4.md).
+7. Planned behavior changes: the applicable V4.x scope and implementation documents.
+8. Implementation truth: current code and tests.
+
+If code intentionally changes accepted page behavior, update the corresponding page contract in the same change. If code accidentally differs, correct the implementation rather than rewriting intent to match a defect.
+
+## Contract Contents
+
+Each page contract contains:
+
+1. Purpose and user goals.
+2. Registered routes and navigation context.
+3. List, detail, and form behavior.
+4. Editable and system-managed information.
+5. Validation, empty, loading, and failure states.
+6. A concise acceptance checklist.
+7. Current implementation and test anchors.
+8. Known limitations and deferred work.
+
+## Maintenance Rules
+
+- Describe current accepted behavior in present tense.
+- Do not mix an obsolete “first release” design with current behavior.
+- Keep future changes in versioned scope documents and link to them from a Deferred Work section.
+- Do not reproduce the complete database field inventory here; include only fields that affect page behavior.
+- Keep service, file, and test anchors current.
+- Do not create separate current-state, target-state, and traceability copies of the same contract.
+- Keep cross-page visual rules in the UI Style Guide instead of repeating them on each page.
+- Keep database joins such as `DocumentPerson` and `JobSource` in schema/architecture documentation unless they directly affect a page interaction.
+
+## Current Baseline
+
+These contracts describe the V4 baseline with completed V4.1 behavior and V4.2 evidence/provenance behavior.
+Draft V4.3 Settings changes are not described as current behavior.

docs/ui/pages/documents.md

@@ -0,0 +1,105 @@
+# Documents Page Contract
+
+## Purpose
+
+Documents manages the archival record for each historical artifact independently of its source files and transcription jobs. A Document can be created first, linked to people in one or more roles, and used later as the parent for Sources and Jobs.
+
+## Routes
+
+| Route | Purpose |
+| --- | --- |
+| `/documents` | Searchable archival Document list. |
+| `/documents/new` | Create a Document. |
+| `/documents/{document_id}` | View one Document and its related records. |
+| `/documents/{document_id}/edit` | Edit metadata and people-by-role links. |
+| `/documents/{document_id}/delete` | Confirm or block deletion. |
+| `/documents/{document_id}/jobs` | Show Jobs belonging to the Document. |
+| `/documents/{document_id}/sources` | Redirect to the Document-filtered Sources list. |
+
+## List Behavior
+
+- The title is **Archival Documents**.
+- **Create new document** opens the create route.
+- The table defaults to Document Title order and supports search and column sorting.
+- Columns are Document Title, Type, Author, Document Date, and Archive Ref.
+- Document Title is left-aligned; the remaining columns are centered.
+- Author lists all linked people in the `author` role.
+- Date display prefers exact date, then approximate date, then `Unknown`.
+- Selecting a row opens Document Detail.
+- No records displays `No documents found in repository.`
+
+## Create and Edit Behavior
+
+Required:
+
+- Document name.
+- Document type selected from the Document Type registry.
+
+Optional:
+
+- Exact date.
+- Approximate date.
+- Document location.
+- Archive identifier.
+- Notes.
+- Multiple people for every configured Person Role.
+
+Rules:
+
+- Exact date must parse as `YYYY-MM-DD`; browser presentation may follow locale.
+- Existing people appear with disambiguating labels.
+- **Create new person** opens Person creation.
+- `person_id` may preselect that Person in the author role on Document creation.
+- An invalid requested Person produces a warning rather than a broken form.
+- `return_to=jobs_new` returns a successful create to Job creation with the new Document selected.
+- Edit includes active and inactive Document Types so historical values remain maintainable.
+- Save success returns to Document Detail.
+
+## Detail Behavior
+
+- The heading shows name, type, and internal ID.
+- The first Source, when present, appears in the dark-room viewer.
+- Archival Metadata shows authors, compact Document date, location, and archive identifier. Notes appear in a separate archival-notes block within the same card.
+- System Logistics shows created and updated timestamps.
+- Related People are grouped by role and link to Person Detail.
+- **Sources & Pipeline Jobs** shows counts and actions for filtered Sources, Document Jobs, and adding a Job.
+- **Edit Document** and **Delete** are available from the header.
+- Invalid IDs and missing Documents produce explicit states without rendering a partial page.
+
+## Document Jobs Behavior
+
+- The page lists the Document's Jobs newest first with status and Job ID.
+- **Open Job** navigates to Job Detail.
+- **Create Job** opens Job creation with the Document selected.
+- No jobs displays an explicit empty state.
+
+## Delete Behavior
+
+- Deletion is blocked while any Source or Job belongs to the Document.
+- The blocked state names the dependency categories and provides navigation back and to Jobs.
+- An unlinked Document requires an explicit permanent-delete action.
+- Success returns to the Documents list.
+
+## Acceptance Checklist
+
+- List columns, alignment, search, sorting, date fallback, and row navigation match this contract.
+- Create/edit enforce name, registered type, and valid exact-date input.
+- Multiple people can be selected independently for each configured role.
+- Person-first Document creation preselects the requested Person as author.
+- Detail links people, Sources, and Jobs to the correct records.
+- Delete never removes a Document with Source or Job dependencies.
+- Service failures use the shared error presenter and never report false success.
+
+## Implementation Anchors
+
+- `src/transcription/ui/pages/documents_page.py`
+- `src/transcription/ui/components/table/documents.py`
+- `src/transcription/services/documents.py`
+- `src/transcription/services/people.py`
+- `tests/ui/test_documents_page.py`
+- `tests/services/test_document_service.py`
+
+## Known Limitations and Deferred Work
+
+- Document creation persists the Document before adding relationship links; a later link failure is surfaced but is not currently one atomic write.
+- Source ordering controls are deferred to the [draft V4.3 scope](../../ver4.3/scope_boundary_v4_3.md).

docs/ui/pages/home.md

@@ -0,0 +1,63 @@
+# Home Page Contract
+
+## Purpose
+
+Home provides a user-maintained landing page for the local archive. It combines one current image with Markdown text and lets the operator edit both without changing application source or prompt assets.
+
+## Routes
+
+| Route | Browser path | Purpose |
+| --- | --- | --- |
+| `/homepage` | `/ui/homepage` | View current homepage image and Markdown. |
+| `/homepage/edit` | `/ui/homepage/edit` | Upload an image and edit Markdown. |
+
+The application root and `/ui` redirect to `/ui/homepage`.
+
+## View Behavior
+
+- The visible page heading is **Home**; the browser tab title is **VibeScribe Home**.
+- The latest homepage image appears in the shared dark-room viewer.
+- Saved Markdown is rendered in the **Home Text** card.
+- Missing text displays `No homepage text saved yet.`
+- Missing image displays the viewer's empty state.
+- **Edit Home Page** opens the edit route.
+
+## Edit Behavior
+
+- The image upload accepts JPEG, PNG, GIF, WebP, BMP, and TIFF files.
+- A successful upload immediately stores the file, updates the preview to that image, and displays a positive notification.
+- The Markdown textarea is initialized from the currently stored homepage text.
+- **Save** writes the textarea content, displays `Homepage saved`, and returns to Home.
+- **Cancel** returns to Home without saving textarea changes. An image already uploaded during the edit session remains stored.
+
+## Storage Contract
+
+- Homepage content is mutable application data under `data/homepage`.
+- Markdown is stored in `homepage.md`.
+- Uploaded images keep a sanitized basename.
+- The view selects the supported image with the most recent modification time.
+- Homepage files are not transcription prompts and are not database records.
+
+## Acceptance Checklist
+
+- `/`, `/ui`, and the application brand reach Home.
+- Home renders with or without stored Markdown and image content.
+- Edit loads existing Markdown.
+- A supported image upload updates the preview and becomes the latest homepage image.
+- Save persists Markdown and returns to Home.
+- Cancel does not save changed Markdown.
+
+## Implementation Anchors
+
+- `src/transcription/ui/pages/home_page.py`
+- `src/transcription/ui/homepage_store.py`
+- `src/transcription/ui/components/app_shell.py`
+- `tests/ui/test_upload_page.py`
+- `tests/ui/test_navigation_and_mounts.py`
+- `tests/ui/test_pages_registration.py`
+
+## Known Limitations
+
+- Homepage storage is fixed under the repository/application `data` directory rather than a configured application-data root.
+- Uploading an image is immediate and is not rolled back by Cancel.
+- The editor does not currently delete or select among previously uploaded images.

docs/ui/pages/jobs.md

@@ -0,0 +1,94 @@
+# Jobs Page Contract
+
+## Purpose
+
+Jobs manages transcription processing runs. A Job belongs to one Document, links one or more Source pages, records processing provenance, and exposes lifecycle actions without making lifecycle fields directly editable.
+
+## Routes
+
+| Route | Purpose |
+| --- | --- |
+| `/jobs` | Searchable processing Job list. |
+| `/jobs/new` | Create and queue a Job. |
+| `/jobs/{job_id}` | View status, execution logistics, and related records. |
+| `/jobs/{job_id}/cancel` | Confirm cancellation. |
+| `/jobs/{job_id}/resubmit` | Confirm resubmission of failed Sources. |
+| `/jobs/{job_id}/delete` | Confirm or block deletion. |
+
+## List Behavior
+
+- The title is **Transcription Pipeline Jobs**.
+- **Create job** opens Job creation and **Refresh** reloads the table.
+- Columns are Job ID, Status, Source Filename, Retries, Created, and Updated.
+- Search covers Job ID, filename, and status.
+- Status is displayed as a semantic status chip.
+- Selecting a row opens Job Detail.
+- No records displays `No job records found in repository.`
+
+## Create Behavior
+
+- A Target Document and at least one source file are required.
+- `document_id` may preselect a Target Document.
+- If no Documents exist, the page explains the prerequisite and links to Document creation with a return path.
+- Provider and Model are optional request overrides.
+- Upload accepts JPEG, PNG, TIFF, and PDF files and supports multiple/folder selection.
+- The visible upload queue is sorted alphabetically by original filename.
+- Files can be removed individually or cleared before submission.
+- Helper text explains numeric filename prefixes for page ordering.
+- Submission creates the Job, Source records, and JobSource links, notifies the worker, and opens Job Detail.
+
+## Detail and Lifecycle Behavior
+
+- The heading shows Job ID and a status badge.
+- Execution Logistics shows provider, model, prompt, retry count, and last update.
+- Document Links open the parent Document and Job-filtered Sources.
+- Queued and processing Jobs show an auto-refresh notice and reload every four seconds.
+- Polling stops when the Job becomes terminal or a refresh fails.
+- Queued and processing Jobs expose **Cancel**.
+- Jobs other than `transcribed` expose **Resubmit** under the current UI rule. The service blocks resubmission while processing is active or when no failed Sources exist.
+- All Jobs expose **Delete Job**, subject to explicit evidence-deletion guardrails.
+- Invalid and missing IDs produce explicit states.
+
+## Cancel Behavior
+
+- The confirmation explains that processing stops and remaining non-transcribed Sources become failed.
+- The service decides whether the current state permits cancellation.
+- Success updates the Job, notifies the worker, and returns to Job Detail.
+
+## Resubmit Behavior
+
+- The page shows current status and failed Source count.
+- The page explains that resubmission queues failed linked Sources while preserving immutable prior attempt evidence.
+- The service blocks submission while processing is active or when no failed Sources exist.
+- `JobSource` remains the latest compatibility projection, while every provider call appends an `ExecutionAttempt`.
+- The latest successful `Source.raw_transcription` projection remains available while a retry is pending or fails.
+- Success reports the number of resubmitted Sources and returns to Job Detail.
+
+## Delete Behavior
+
+- Deletion is blocked while status is `processing`.
+- Allowed deletion explicitly warns that related `JobSource` projections,
+  immutable execution attempts, captured transport responses, and attempt-owned
+  artifacts are permanently removed.
+- Source records and source files remain available for separate deletion.
+- Success returns to the Jobs list.
+
+## Acceptance Checklist
+
+- Job creation cannot proceed without a valid Document and at least one Source.
+- Upload ordering and removal controls match the displayed queue.
+- Detail shows current status and provenance summary with correct related links.
+- Active Jobs refresh without overlapping permanent polling after terminal state.
+- Cancel, resubmit, and delete honor service guardrails and show actionable failures.
+- Lifecycle fields cannot be edited directly.
+
+## Implementation Anchors
+
+- `src/transcription/ui/pages/jobs_page.py`
+- `src/transcription/ui/components/table/jobs.py`
+- `src/transcription/services/jobs.py`
+- `src/transcription/services/store.py`
+- `src/transcription/services/workflows.py`
+- `tests/ui/test_jobs_page.py`
+- `tests/services/test_job_service.py`
+- `tests/services/test_store.py`

docs/ui/pages/people.md

@@ -0,0 +1,90 @@
+# People Page Contract
+
+## Purpose
+
+People manages reusable historical-person records. A Person may appear in many Documents under different relationship roles and may optionally carry a portrait and FamilySearch identifier.
+
+## Routes
+
+| Route | Purpose |
+| --- | --- |
+| `/people` | Searchable People list. |
+| `/people/new` | Create a Person. |
+| `/people/{person_id}` | View one Person and linked Documents. |
+| `/people/{person_id}/edit` | Edit the Person. |
+| `/people/{person_id}/delete` | Confirm permanent deletion. |
+
+## List Behavior
+
+- The title is **Archival Entities: People**.
+- **Create new person** opens the create route.
+- The table defaults to Full Name order and supports search and column sorting.
+- Columns are Full Name, Display Name, Maiden Name, Birth Date, and Death Date.
+- Full Name is left-aligned; Display Name, Maiden Name, and date columns are centered.
+- Birth and death values independently prefer exact date, then approximate date, then `Unknown`.
+- Selecting a row opens Person Detail.
+- No records displays `No person records found in repository.`
+
+## Create and Edit Behavior
+
+Required:
+
+- Full name.
+
+Optional:
+
+- Display name and maiden name.
+- Exact and approximate birth/death dates.
+- Birth/death places.
+- Biography.
+- Portrait path or uploaded portrait.
+- FamilySearch ID.
+
+Rules:
+
+- Missing Full name blocks save with a warning.
+- Exact date inputs are native browser date inputs.
+- FamilySearch IDs are normalized and validated by `PeopleService`.
+- Portrait uploads are stored under the configured upload root in a Person-specific directory and update Portrait path.
+- Metadata JSON remains hidden.
+- Save success returns to Person Detail.
+
+## Detail Behavior
+
+- The header provides **New Document**, **Edit Person**, and **Delete**.
+- **New Document** opens Document creation with this Person requested for author preselection.
+- The portrait viewer resolves supported relative upload paths and absolute HTTP/data URLs.
+- Biographical Record shows names, compact birth/death dates, places, and an **Open in FamilySearch** link when an ID exists.
+- Biography has an explicit empty value.
+- Linked Documents show Document name, relationship role, and an action to open Document Detail.
+- No links shows both an empty state and guidance to link from a Document workflow.
+- System Logistics shows created and updated timestamps.
+
+## Delete Behavior
+
+- The page warns when linked Document relationships exist.
+- Confirmed deletion removes the Person and its relationship links; it does not delete Documents.
+- Success returns to the People list.
+- Missing or already-deleted records return to a safe list state.
+
+## Acceptance Checklist
+
+- List fields, alignment, date fallback, search, sorting, and navigation match this contract.
+- Full name is enforced on create and edit.
+- FamilySearch ID validation and link generation use the fixed supported identifier format.
+- Portrait upload and rendering remain constrained to supported media paths.
+- New Document carries the Person context.
+- Linked Documents show the correct role and target.
+- Delete wording distinguishes removal of relationship links from deletion of Documents.
+
+## Implementation Anchors
+
+- `src/transcription/ui/pages/people_page.py`
+- `src/transcription/ui/components/table/people.py`
+- `src/transcription/services/people.py`
+- `tests/ui/test_people_page.py`
+- `tests/services/test_v2_crud.py`
+
+## Deferred Work
+
+- Structured name fields, merge/deduplication, advanced metadata editing, and Person-side relationship editing are not current behavior.

docs/ui/pages/sources.md

@@ -0,0 +1,89 @@
+# Sources Page Contract
+
+## Purpose
+
+Sources manages individual archived page/file records. It provides source-media viewing, current processing context, provider evidence inspection, previous/next page navigation, and human revision without allowing machine output to be edited.
+
+## Routes
+
+| Route | Purpose |
+| --- | --- |
+| `/sources` | Global or filtered Source list. |
+| `/sources/{source_id}` | View media, transcription, revision, metadata, and evidence. |
+| `/sources/{source_id}/delete` | Confirm or block deletion. |
+
+The list accepts optional `document_id` and `job_id` query parameters. Document context takes precedence if both parse successfully.
+
+## List Behavior
+
+- The title is **Source Asset Records**, **Sources for Document**, or **Sources for Job** according to context.
+- Global context provides **Create Job**.
+- Filtered context provides **Back to Document** or **Back to Job**.
+- Rows are ordered by page number and then upload name.
+- Columns are Document Name, Page Number, Upload Title, Status, and Error Detail.
+- Document Name, Upload Title, and Error Detail are left-aligned; Status is centered.
+- Stored Filename is intentionally absent from the list.
+- Selecting a row opens Source Detail.
+- No records displays `No source asset records found in repository.`
+
+## Detail Behavior
+
+- The heading shows page number, upload name, and Source ID.
+- **Back to Sources** returns to the global list.
+- **Delete Source** opens the guarded delete route.
+- Previous and Next navigate only among Sources belonging to the same Document in page order; unavailable boundary actions are disabled.
+- The media viewer resolves the stored Source path through the configured upload root.
+- Transcription Text is read-only and prefers the latest JobSource transcription, then the Source projection.
+- Editable Revision is seeded from an existing revision or the machine transcription.
+- Source Metadata shows upload name, stored filename, page number, Document Name, Document ID, and stored path. Source ID appears in the page-header subtitle.
+- SourceJob Metadata shows latest status, Job ID, execution time, provider, model, prompt, and failure detail.
+- Revision Logistics shows revised state, last-revised time, and upload time.
+
+## Provider Evidence
+
+- Provider Evidence is associated with the latest JobSource execution.
+- New attempts display separate expandable Request Manifest, Transport Response, OpenRouter SDK Response Snapshot,
+  Normalized Metadata, Software Context, and Derived Artifacts sections.
+- Historical `raw_api_response` values are labeled as OpenRouter SDK response snapshots.
+- Missing evidence has an explicit empty state.
+- Historical executions explicitly state that exact transport evidence was not captured.
+- **Export Evidence** downloads a versioned package containing source identity, attempts, artifacts, relationships,
+  schema versions, and integrity digests without source binaries, credentials, or machine-local source paths.
+
+## Revision Behavior
+
+- Machine transcription is never edited directly.
+- A revision must contain non-whitespace text.
+- Save persists revised text and updates the saved timestamp without leaving the page.
+- Reset restores the in-memory revision from page load or the most recent successful save. When no revision exists, it restores the machine transcription; it does not re-read the database.
+- A failed latest execution displays guidance that a human revision can preserve corrected text.
+
+## Delete Behavior
+
+- Deletion is allowed only when the Source has no JobSource links.
+- A linked Source shows cleanup guidance and navigation to Jobs.
+- An unlinked Source requires explicit permanent deletion.
+- Success returns to the Sources list.
+
+## Acceptance Checklist
+
+- Global, Document-filtered, and Job-filtered lists show the correct context and return action.
+- List columns and alignments match this contract and omit Stored Filename.
+- Previous/next navigation never crosses Document boundaries.
+- Detail keeps machine output read-only and human revision separately editable.
+- Empty, failed, and missing-evidence states remain explicit.
+- JSON evidence is readable without being mislabeled as native transport evidence.
+- Delete cannot remove a Source with processing-history links.
+
+## Implementation Anchors
+
+- `src/transcription/ui/pages/sources_page.py`
+- `src/transcription/ui/components/table/sources.py`
+- `src/transcription/services/sources.py`
+- `tests/ui/test_sources_page.py`
+- `tests/services/test_transcription_service.py`
+- `tests/services/test_v2_crud.py`
+
+## Planned Changes
+
+- Source page reordering is deferred beyond V4.3 and may be reconsidered if a demonstrated workflow need emerges.

docs/ver1/ver1-step1-2-carry-forward-checklist.md

@@ -1,73 +0,0 @@
-# Ver1 Step 1/2 Carry-Forward Checklist
-
-## Purpose
-
-Track open Step 1 and Step 2 follow-ups through later V1 steps, with lightweight verification evidence and requirement traceability.
-
-This artifact implements the carry-forward approach defined in:
-- `docs/ver1/ver1-step1-2_revised.md`
-
-Historical records remain unchanged:
-- `docs/ver1/ver1-step1.md`
-- `docs/ver1/ver1-step1-results.md`
-- `docs/ver1/ver1-step2.md`
-- `docs/ver1/ver1-step2-results.md`
-
----
-
-## Status Legend
-
-- `not started`
-- `in progress`
-- `done`
-- `deferred`
-
----
-
-## Carry-Forward Mapping Matrix
-
-| ID | Carry-Forward Task | Source | Related REQ | Owning V1 Step(s) | Validation Method | Status | Evidence Link/Note |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| CF-A1 | Confirm remaining implicit/global runtime ownership and lift only high-impact resources to lifespan ownership | Step 1 residual follow-up | REQ-7 | Step 3, Step 9 | Inspection + test | in progress | Step 3 added `services/library.py` and `api/routes.py` using existing service/session access patterns; no new module-global runtime resource ownership introduced. Reconfirm in Step 9 release readiness. |
-| CF-A2 | Finalize migration + rollback runbook usage and rehearse on representative local data | Step 1 residual follow-up | REQ-10 | Step 4, Step 9 | Demonstration + test | not started | |
-| CF-A3 | Maintain lightweight boundary enforcement (review checklist and/or simple import checks) | Step 1 residual follow-up | REQ-7, REQ-11 | Step 3, Step 7 | Inspection | in progress | Step 3 implementation keeps UI/API composition thin and pushes revision/search/export logic to `services/library.py`; continue with Step 7 checks. |
-| CF-B1 | Build compact error-path inventory for major failure paths and category mapping | Step 2 governance follow-up | REQ-2, REQ-3, REQ-4, REQ-5 | Step 6, Step 7 | Inspection | not started | Use `docs/ver1/ver1-step2-error-path-inventory.md` |
-| CF-B2 | Standardize required logging fields at critical boundary handoffs | Step 2 residual follow-up | REQ-3, REQ-4, REQ-8 | Step 6 | Inspection + test | not started | |
-| CF-B3 | Revisit retry backoff strategy only if observed runtime behavior justifies extra complexity | Step 2 residual follow-up | REQ-2, REQ-6 | Step 6, Step 8 | Analysis + test | deferred | Keep fixed backoff unless evidence suggests change |
-| CF-C1 | Integrate Step 1/2 completed outcomes and open follow-ups into V1 traceability tracking | Revision-plan workstream | REQ-0..REQ-12 (traceability) | Step 3, Step 10 | Inspection | done | Step 3 artifacts added: `docs/ver1/ver1-step3.md`, `docs/ver1/ver1-step3-results.md`, and this checklist updated with Step 3 evidence and routing. |
-| CF-C2 | Keep carry-forward routing aligned with revised V1 plan (architecture via 3/4/9, reliability via 6/7) | Revision-plan workstream | REQ-0..REQ-12 (execution alignment) | Step 3+ | Inspection | in progress | Step 3 execution followed routing: functional features implemented in Step 3; migration/rollback items remain in Step 4/9; logging/error-path standardization remains Step 6/7. |
-
----
-
-## Execution Notes
-
-### Step 3 (Functional Completion)
-- Use CF-A1 and CF-A3 during requirement-slice implementation reviews.
-- Record any discovered boundary/runtime ownership gaps in this checklist.
-
-### Step 4 (Data Model and Migration Safety)
-- Execute CF-A2 rehearsal and link evidence (commands, runbook notes, outcomes).
-
-### Step 6 (Minimal Observability & Operability)
-- Execute CF-B1 and CF-B2 with focused artifacts and log-field verification.
-
-### Step 7 (Test Coverage and Practical Quality Gates)
-- Add/verify tests supporting CF-A3 and CF-B1/B2 where meaningful.
-
-### Step 8 (Performance Validation)
-- Reassess CF-B3 only if retries/backoff are observed to cause practical issues.
-
-### Step 9 (Release Readiness)
-- Reconfirm CF-A1/A2 readiness in release checklist and rollback drill.
-
-### Step 10 (Documentation Completion)
-- Ensure final V1 docs reference outcomes from this checklist where relevant.
-
----
-
-## Acceptance Check for Carry-Forward Completion
-
-- [ ] Historical Step 1/2 documents remain unchanged.
-- [ ] Every open Step 1/2 follow-up has an owning V1 step and validation method.
-- [ ] Evidence links are recorded for each completed carry-forward item.
-- [ ] No carry-forward item introduces unnecessary complexity for personal-scale operation.

docs/ver1/ver1-step1-2_revised.md

@@ -1,166 +0,0 @@
-# Ver1 Step 1 & Step 2 Revision Plan (Additive)
-
-## Purpose
-
-Define a **targeted implementation follow-through plan** for Step 1 and Step 2 outcomes so remaining V1 work stays aligned with `docs/ver1/ver1.md`:
-
-- personal-scale operation
-- single operator
-- private-network assumptions
-- low operational overhead
-- practical, testable controls
-
-This document is additive and does **not** replace or revise historical Step 1/Step 2 records.
-
----
-
-## Source Documents Reviewed
-
-- `docs/ver1/ver1.md`
-- `docs/ver1/ver1-step1.md`
-- `docs/ver1/ver1-step1-results.md`
-- `docs/ver1/ver1-step2.md`
-- `docs/ver1/ver1-step2-results.md`
-- `docs/architecture.md`
-- `docs/error_handling.md`
-- `docs/requirements.md`
-- `docs/index.md`
-- `docs/intent.md`
-
----
-
-## Revision Goals
-
-1. Preserve all completed Step 1/Step 2 technical hardening work.
-2. Keep historical Step 1/Step 2 documents unchanged.
-3. Convert residual risks/follow-ups into concrete implementation tasks for subsequent V1 steps.
-4. Preserve traceability to requirements and implemented evidence.
-5. Maintain alignment with personal-scale architecture and operating model.
-
----
-
-## Scope
-
-### In Scope
-- Define carry-forward implementation tasks based on Step 1/2 residual risks and open items.
-- Map carry-forward tasks to later V1 steps (especially Steps 3, 4, 6, 7, and 9).
-- Define lightweight verification evidence expected for each carry-forward task.
-- Update V1 traceability references to include completed Step 1/2 outcomes and deferred follow-ups.
-
-### Out of Scope
-- Simplifying tone/structure of existing Step 1/2 documents
-- Clarifying or rewriting historical Step 1/2 plan/results content
-- Editing `docs/ver1/ver1-step1.md`
-- Editing `docs/ver1/ver1-step1-results.md`
-- Editing `docs/ver1/ver1-step2.md`
-- Editing `docs/ver1/ver1-step2-results.md`
-- Re-implementing Step 1/2 code changes
-- Rewriting `docs/ver1/ver1.md`
-- Deleting historical sections/results
-- Altering requirements IDs or architecture principles
-
----
-
-## Carry-Forward Implementation Plan
-
-## Workstream A — Close Step 1 follow-ups through later V1 steps
-
-### A1) Runtime ownership completion (REQ-7 continuity)
-- Confirm whether any remaining runtime resources still use implicit/global ownership.
-- Move only high-impact remaining resources to explicit lifespan ownership when needed.
-- Keep ownership model simple and documented.
-
-### A2) Schema/migration operations readiness (REQ-10 continuity)
-- Finalize practical migration + rollback runbook usage in Step 4 execution.
-- Rehearse upgrade and rollback on representative local data.
-- Keep production startup free from implicit schema mutation.
-
-### A3) Boundary enforcement (lightweight only)
-- Keep architecture boundary checks lightweight (review checklist and/or simple import checks).
-- Avoid heavy governance tooling unless clear recurring drift appears.
-
-### Expected Outcome
-Step 1 architecture hardening remains intact and is completed pragmatically where open items remain.
-
----
-
-## Workstream B — Close Step 2 follow-ups through later V1 steps
-
-### B1) Error-path inventory and coverage visibility
-- Create a compact error-path inventory artifact (or equivalent matrix section) covering major failure paths.
-- Ensure each critical path maps to category, retriable policy, and surfaced behavior.
-
-### B2) Logging field consistency at key boundaries
-- Standardize required fields at critical failure handoffs (`error_id`, `category`, `operation`, identifiers when available).
-- Prioritize worker/API/service boundaries first.
-
-### B3) Retry policy refinement (only if needed)
-- Keep current bounded retry baseline.
-- Revisit richer backoff strategy only if observed behavior justifies added complexity.
-
-### Expected Outcome
-Step 2 reliability behavior stays stable, diagnosable, and right-sized for personal-scale operation.
-
----
-
-## Workstream C — Integrate Step 1/2 outputs into ongoing V1 governance
-
-### C1) Traceability integration
-- Link completed Step 1/2 outcomes and deferred follow-ups to the V1 traceability matrix.
-- Ensure open follow-ups have owning step and validation method.
-
-### C2) Execution alignment with revised V1 plan
-- Route architecture follow-ups primarily through Steps 3/4/9.
-- Route reliability/diagnostics follow-ups primarily through Steps 6/7.
-
-### Expected Outcome
-Step 1/2 work is fully carried forward without revising historical documents.
-
-## Deliverables
-
-1. This document (`docs/ver1/ver1-step1-2_revised.md`) as the carry-forward implementation plan.
-2. A compact Step 1/2 carry-forward checklist linked to V1 steps and validation methods.
-3. Traceability updates showing where each open Step 1/2 follow-up will be closed.
-4. Optional new artifact for error-path inventory (if created during Step 6/7 execution).
-
----
-
-## Acceptance Criteria
-
-- Historical Step 1/Step 2 documents remain unchanged.
-- Open Step 1/2 follow-ups are explicitly mapped to later V1 steps with validation expectations.
-- No loss of core technical intent (REQ-7, REQ-10, error taxonomy, retry safety, traceability).
-- No conflicts introduced with `docs/architecture.md`, `docs/error_handling.md`, or `docs/ver1/ver1.md`.
-- Carry-forward tasks remain right-sized for personal-scale operation.
-
----
-
-## Implementation Order
-
-1. Keep existing Step 1/Step 2 docs unchanged as historical records.
-2. Define carry-forward tasks and owning V1 steps in this document.
-3. Create and maintain carry-forward traceability artifacts:
-   - `docs/ver1/ver1-step1-2-carry-forward-checklist.md`
-   - `docs/ver1/ver1-step2-error-path-inventory.md`
-4. Execute carry-forward tasks during Steps 3+ and capture evidence in step results docs.
-5. Perform final consistency pass across `docs/ver1/*` references.
-
----
-
-## Risks and Mitigations
-
-1. **Risk:** Open Step 1/2 items are forgotten as Step 3+ work proceeds.  
-   **Mitigation:** Track each follow-up in the V1 traceability matrix with owning step and evidence expectation.
-
-2. **Risk:** Carry-forward work expands beyond personal-scale needs.  
-   **Mitigation:** Apply simplicity guardrails from `docs/architecture.md` before accepting additional hardening tasks.
-
-3. **Risk:** Reliability follow-ups become fragmented across multiple steps.  
-   **Mitigation:** Keep one consolidated carry-forward checklist and update it at milestone check-ins.
-
----
-
-## Notes
-
-This revision effort is scope-alignment and implementation-follow-through focused.  
-Historical Step 1/Step 2 documents are intentionally preserved as-is.

docs/ver1/ver1-step1-results.md

@@ -1,86 +0,0 @@
-# Ver1 Step 1 Results: Architecture Consolidation
-
-## Summary
-
-Step 1 implementation has been completed for the primary architecture-consolidation objectives:
-
-1. Lifespan-owned runtime resource model introduced for DB runtime ownership.
-2. Schema bootstrap policy changed from implicit-always to explicit/environment-aware.
-3. Worker startup now receives lifespan-owned DB engine dependency.
-4. ADR set established for key V1 architectural decisions.
-
-## Implemented Changes
-
-### 1) Runtime ownership
-
-- Updated `src/transcription/db.py`:
-  - Added `DatabaseRuntime` resource model.
-  - Added explicit runtime lifecycle methods:
-    - `initialize_database_runtime(...)`
-    - `get_database_runtime()`
-    - `dispose_database_runtime()`
-- Updated `src/transcription/app.py`:
-  - Lifespan initializes DB runtime and stores it on `app.state`.
-  - Lifespan disposes DB runtime on shutdown.
-
-### 2) Schema bootstrap policy (REQ-10 alignment)
-
-- Updated `src/transcription/config.py`:
-  - Added `environment` setting (`development`, `test`, `production`).
-  - Added `bootstrap_schema_on_startup` explicit override setting.
-- Updated `src/transcription/db.py`:
-  - Added `should_bootstrap_schema(settings)` policy function.
-- Updated `src/transcription/app.py`:
-  - Startup now calls `create_all(...)` only when policy allows.
-
-### 3) Worker dependency ownership
-
-- Updated `src/transcription/worker.py`:
-  - `process_next_queued_job(..., engine=None)` now supports explicit engine injection.
-  - `run_worker_loop(..., engine=None, ...)` now supports explicit engine injection.
-- Updated `src/transcription/app.py`:
-  - Worker thread is started with lifespan-owned engine.
-
-### 4) ADR governance
-
-Created:
-- `docs/adr/README.md`
-- `docs/adr/ADR-0001-lifespan-owned-runtime-resources.md`
-- `docs/adr/ADR-0002-explicit-schema-bootstrap-policy.md`
-- `docs/adr/ADR-0003-persistence-baseline-and-transition-path.md`
-- `docs/adr/ADR-0004-in-process-worker-topology.md`
-
-## Test Evidence
-
-Targeted regression checks executed successfully:
-
-- `uv run pytest tests/test_app.py tests/test_db.py tests/services/test_worker.py -q`
-- Result: pass
-
-## Residual Risks / Follow-ups
-
-1. Full REQ-7 completion may still require broader runtime ownership coverage for additional resources as V1 expands.
-2. Production schema management workflow (migrations/runbook tooling) should be finalized in subsequent V1 steps.
-3. Additional boundary enforcement automation (import-lint style checks) can be added in later hardening.
-
-## Step 1 Exit Assessment
-
-- Architecture ownership clarity: **met**
-- Schema bootstrap policy hardening: **met**
-- Worker lifecycle dependency clarity: **met**
-- ADR baseline established: **met**
-
-## Completion Checklist With Evidence
-
-| Criterion | Status | Evidence |
-| --- | --- | --- |
-| Architecture conformance matrix approved | partial | Consolidation implemented and documented in `docs/ver1/ver1-step1.md` + this results doc; formal matrix artifact can be added as a follow-up appendix. |
-| REQ-7 ownership gaps resolved or explicitly deferred | met | Lifespan-owned DB runtime and explicit worker engine wiring implemented in `src/transcription/app.py`, `src/transcription/db.py`, `src/transcription/worker.py`. Residual scope documented under follow-ups. |
-| REQ-10 explicit bootstrap policy implemented and verified | met | Policy implemented via `environment` + `bootstrap_schema_on_startup` in `src/transcription/config.py`, `should_bootstrap_schema(...)` in `src/transcription/db.py`, startup gate in `src/transcription/app.py`, tested in `tests/test_db.py`. |
-| Dependency direction rules documented and enforced | partial | Layering and runtime ownership documented in `docs/architecture.md`. Lightweight enforcement exists via review and test discipline; automated import-lint remains a follow-up. |
-| ADR set created for major Step 1 decisions | met | `docs/adr/README.md` and ADR-0001 through ADR-0004 created. |
-| Architecture/index docs updated to match implementation | met | `docs/architecture.md` and `docs/index.md` updated with V1 Step 1 runtime policy and links to V1/ADR artifacts. |
-| Regression and full test suites pass | met | Targeted: `uv run pytest tests/test_app.py tests/test_db.py tests/services/test_worker.py -q`; full suite: `uv run pytest -q`. |
-| Step 1 results artifact published | met | This document (`docs/ver1/ver1-step1-results.md`) created and updated with summary, evidence, risks, and checklist. |
-
-Step 1 is complete and ready to hand off to Ver1 Step 2.

docs/ver1/ver1-step1.md

@@ -1,309 +0,0 @@
-# Step 1 Implementation Plan: Architecture Consolidation
-
-## Purpose
-
-Align the implemented MVP codebase with the production architecture and V1 constraints documented in:
-
-- `docs/architecture.md`
-- `docs/requirements.md`
-- `docs/error_handling.md`
-- `docs/index.md`
-- `docs/intent.md`
-- `docs/ver1/ver1.md` (Step 1)
-
-This step hardens architecture boundaries and ownership without expanding product scope.
-
----
-
-## MCP Skill and Guide Inputs Incorporated
-
-This plan explicitly incorporates patterns and guardrails from john-stream-mcp resources:
-
-1. `resource://skills/fastapi-uv-docker/document`
-   - App factory and lifespan ownership
-   - Health endpoint and cloud-native baseline expectations
-   - Environment-driven configuration and startup discipline
-
-2. `resource://skills/fastapi-async-sqlalchemy-modernization/document`
-   - Current-state gap audit first
-   - Target runtime model before refactor
-   - Explicit resource lifecycle ownership
-   - Transaction/session boundary clarity
-   - Phased migration with rollback points
-
-3. `resource://skills/nicegui/document`
-   - Clear dependency direction
-   - UI/page registration as composition, not business logic container
-   - Async responsiveness and boundary separation
-
-4. `resource://prompts/greenfield-architecture/document`
-   - Pattern-comparison-first planning
-   - Explicit tradeoffs and staged implementation
-   - Output contract with risks, open questions, and next steps
-
----
-
-## Current-State Gap Summary (Architecture vs Implementation)
-
-Based on docs and current `src/transcription` code:
-
-1. **REQ-7 gap (lifespan-owned resources)**  
-   - DB engine/session factory are module globals in `db.py`, not app lifespan-owned.
-   - Worker thread lifecycle is owned by lifespan (good), but DB/provider resource ownership is mixed.
-
-2. **REQ-10 gap (explicit opt-in schema bootstrap)**  
-   - `create_all()` is executed unconditionally on startup in `app.py`.
-
-3. **Data store target gap (REQ-9 + architecture baseline)**  
-   - Runtime still defaults to SQLite MVP setup; production architecture targets PostgreSQL baseline with optional MongoDB.
-
-4. **Layering clarity gap (architecture layer model)**  
-   - Boundaries exist but are not yet formally enforced (interface/app/domain/infra dependency rules are implicit, not codified).
-
-5. **Decision record gap**  
-   - No ADR set documenting key V1 architectural decisions and deviations from MVP.
-
----
-
-## Scope for Step 1
-
-### In scope
-1. Produce architecture conformance audit and decision records.
-2. Define and implement target runtime ownership model for core resources.
-3. Establish explicit schema bootstrap policy (opt-in in production paths).
-4. Consolidate module boundaries and dependency direction rules.
-5. Update architecture docs to reflect implemented reality and V1 trajectory.
-
-### Out of scope
-- Full async SQLAlchemy rewrite (plan and seams only if deferred)
-- MongoDB feature implementation
-- New user-facing features
-- Major worker architecture replacement (in-process worker remains baseline)
-
----
-
-## Target Architecture Decisions for V1
-
-1. **Keep modular monolith topology** (FastAPI + NiceGUI + in-process worker).
-2. **Preserve container-light simplicity guardrails** from `architecture.md`.
-3. **Move runtime ownership to lifespan** for:
-   - DB engine/session factory lifecycle
-   - Worker runtime resources
-   - Provider client factory/config lifecycle
-4. **Adopt explicit schema bootstrap policy**:
-   - Dev/test: opt-in auto-bootstrap allowed
-   - Production: startup must not mutate schema implicitly
-5. **Formalize boundary map**:
-   - Interface (`api`, `ui`) -> Application (`services`) -> Domain (`models/rules`) -> Infrastructure (`db`, `providers`)
-   - No reverse imports
-
----
-
-## Detailed Work Breakdown
-
-## Phase A — Architecture Audit and Baseline Freeze
-
-- [ ] **A1. Produce architecture conformance matrix**
-  - Map each architecture section to current modules/files.
-  - Classify each row: `aligned`, `partial`, `not aligned`.
-
-- [ ] **A2. Produce REQ-7/REQ-9/REQ-10 focused gap report**
-  - Explicitly capture current vs required state.
-  - Include operational risk if left unresolved.
-
-- [ ] **A3. Freeze MVP architecture baseline**
-  - Record current baseline behavior and known temporary shortcuts.
-  - Link this baseline from `docs/ver1/ver1.md`.
-
-### Deliverables
-- `docs/ver1/ver1-step1-audit.md` (or equivalent section in this doc)
-- Architecture conformance table
-
-### Exit Criteria
-- No architecture changes begin before gap matrix and baseline are approved.
-
----
-
-## Phase B — Resource Ownership Consolidation (Lifespan-Centric)
-
-- [ ] **B1. Define runtime resource ownership contract**
-  - `app.py` lifespan owns resource initialization and cleanup order.
-  - `app.state` carries resource handles/factories.
-  - No hidden module-global side-effect initialization for runtime resources.
-
-- [ ] **B2. Refactor DB ownership model**
-  - Replace module-global engine singleton pattern with lifespan-initialized resource model.
-  - Define one canonical session-factory access path for app/worker/services.
-
-- [ ] **B3. Normalize worker dependencies**
-  - Ensure worker uses lifespan-owned resources/factories rather than implicit globals.
-  - Preserve deterministic startup/shutdown behavior.
-
-- [ ] **B4. Define provider adapter ownership**
-  - Provider client creation strategy is centralized and lifecycle-aware.
-  - Avoid per-call hidden client construction when unnecessary.
-
-### MCP-Guided Guardrails
-- Use explicit lifecycle composition patterns from `fastapi-async-sqlalchemy-modernization`.
-- Maintain app-factory + lifespan structure per `fastapi-uv-docker`.
-- Keep UI registration as composition only per `nicegui`.
-
-### Exit Criteria
-- Core runtime resources have one owner and one cleanup path.
-- No critical resource has ambiguous ownership.
-
----
-
-## Phase C — Schema Bootstrap Policy (REQ-10 Alignment)
-
-- [ ] **C1. Define environment-aware bootstrap policy**
-  - `auto_create_schema` (or equivalent) disabled in production by default.
-  - Startup schema mutation is explicit and intentional.
-
-- [ ] **C2. Split startup responsibilities**
-  - App startup performs health-critical initialization only.
-  - Schema bootstrap path is moved to explicit command/flag workflow.
-
-- [ ] **C3. Update deployment/runbook docs**
-  - Document migration/bootstrap flow for dev, staging, prod.
-  - Ensure policy is testable and auditable.
-
-### Exit Criteria
-- Normal production startup path does not call schema auto-create implicitly.
-- Bootstrap behavior is explicit and documented.
-
----
-
-## Phase D — Module Boundary Enforcement
-
-- [ ] **D1. Publish dependency direction rules**
-  - Allowed import directions across `api`, `ui`, `services`, `models/domain`, `db/providers`.
-  - Explicitly disallow reverse dependencies.
-
-- [ ] **D2. Reconcile package map with docs**
-  - Ensure docs’ architecture elements match real package layout and naming.
-  - Update docs where intentional deviations remain.
-
-- [ ] **D3. Isolate cross-layer responsibilities**
-  - Keep API/UI presentation concerns out of services.
-  - Keep provider/DB specifics out of interface layer.
-
-- [ ] **D4. Add lightweight architecture checks**
-  - Add static/import checks and/or review checklist in CI/review process.
-
-### Exit Criteria
-- Boundary rules are documented and applied.
-- Architectural drift can be detected during review/CI.
-
----
-
-## Phase E — Architecture Decision Records (ADRs)
-
-- [ ] **E1. Create ADR index**
-  - Add `docs/adr/README.md` with template and status model.
-
-- [ ] **E2. Record minimum V1 ADR set**
-  1. Runtime ownership model (lifespan-owned resources)
-  2. Schema bootstrap policy (explicit vs implicit)
-  3. Persistence baseline (PostgreSQL target; SQLite transition strategy)
-  4. Worker topology (in-process for V1, extension path preserved)
-
-- [ ] **E3. Cross-link ADRs**
-  - Link from architecture and V1 docs.
-
-### Exit Criteria
-- Major architecture decisions are explicit, versioned, and discoverable.
-
----
-
-## Phase F — Documentation Consolidation
-
-- [ ] **F1. Update `docs/architecture.md`**
-  - Reflect real implementation and V1 target state separately.
-  - Mark transitional choices clearly.
-
-- [ ] **F2. Update `docs/index.md` navigation consistency**
-  - Ensure architecture/readme references match actual docs/files.
-
-- [ ] **F3. Update `docs/requirements.md` traceability notes**
-  - Mark REQ-7/REQ-10 status and verification approach after consolidation.
-
-- [ ] **F4. Add Step 1 result summary**
-  - Create `docs/ver1/ver1-step1-results.md` after implementation.
-
-### Exit Criteria
-- Docs are internally consistent and match runtime architecture reality.
-
----
-
-## Verification Plan
-
-## Architecture Verification Matrix (Step 1)
-
-1. **Inspection**
-   - Resource ownership map exists and matches code.
-   - Schema bootstrap policy is explicit and environment-aware.
-   - ADRs exist for each key architecture decision.
-
-2. **Automated checks**
-   - Existing test suite remains green.
-   - New/updated tests validate startup policy (no implicit schema mutation in production mode).
-   - Import/dependency-direction checks pass (if introduced).
-
-3. **Demonstration**
-   - App starts in dev mode with explicit expected behavior.
-   - App starts in production mode without mutating schema implicitly.
-   - Worker lifecycle starts/stops cleanly with app lifespan.
-
----
-
-## Risks and Mitigations
-
-1. **Risk:** Refactor destabilizes MVP behavior  
-   **Mitigation:** Phase changes with small PRs and regression checks after each phase.
-
-2. **Risk:** Over-rotation into premature async rewrite  
-   **Mitigation:** Keep this step focused on lifecycle ownership and boundaries; defer full async migration unless required.
-
-3. **Risk:** Schema policy changes break local DX  
-   **Mitigation:** Keep explicit dev bootstrap path simple and documented.
-
-4. **Risk:** Boundary rules become “doc only”  
-   **Mitigation:** Add CI/review enforcement and architecture checklist.
-
----
-
-## Recommended Implementation Order
-
-1. Phase A — Audit and baseline freeze  
-2. Phase B — Resource ownership consolidation  
-3. Phase C — Schema bootstrap policy  
-4. Phase D — Boundary enforcement  
-5. Phase E — ADR authoring  
-6. Phase F — Documentation consolidation
-
-This order minimizes risk: diagnose first, then refactor ownership, then lock policy, then enforce boundaries, and finally finalize docs.
-
----
-
-## Step 1 Completion Checklist
-
-- [ ] Architecture conformance matrix approved.
-- [ ] REQ-7 ownership gaps resolved or explicitly deferred with owner/date.
-- [ ] REQ-10 explicit bootstrap policy implemented and verified.
-- [ ] Dependency direction rules documented and enforced.
-- [ ] ADR set created for all major Step 1 decisions.
-- [ ] Architecture and index docs updated to match implementation.
-- [ ] Full test suite passes after consolidation.
-- [ ] `docs/ver1/ver1-step1-results.md` created with evidence and residual risks.
-
----
-
-## Handoff to Step 2
-
-Once Step 1 completes, Step 2 (Error Handling & Reliability Hardening) can proceed on stable architecture seams:
-
-- consistent lifecycle ownership,
-- explicit startup policy,
-- clear module boundaries,
-- documented architecture decisions.

docs/ver1/ver1-step2-error-path-inventory.md

@@ -1,42 +0,0 @@
-# Ver1 Step 2 Error-Path Inventory (Carry-Forward)
-
-## Purpose
-
-Provide a compact inventory of major failure paths with taxonomy mapping and retry behavior, aligned with:
-- `docs/error_handling.md`
-- `docs/ver1/ver1-step2-results.md`
-- `docs/ver1/ver1-step1-2-carry-forward-checklist.md` (CF-B1)
-
-This is a lightweight operational artifact for Step 6/7 follow-through.
-
----
-
-## Inventory Table
-
-| Path ID | Boundary/Operation | Typical Failure Source | Category | Retriable | Surface Behavior | Current Coverage | Notes |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| EP-API-001 | API upload request validation | invalid payload / empty file metadata | `validation_error` | no | structured API error envelope (400) | partial | confirm all upload variants |
-| EP-API-002 | API resource lookup | missing job/document | `not_found_error` | no | structured API error envelope (404) | partial | verify consistency for all lookup routes |
-| EP-SVC-001 | Service provider-call mapping | provider SDK/HTTP failure | `external_provider_error` | sometimes | normalized AppError and safe message | partial | ensure consistent mapping in service boundary tests |
-| EP-WKR-001 | Worker provider timeout | timeout/unavailable upstream | `external_provider_error` or `infrastructure_transient_error` | yes | retry or terminal failed with persisted reason | partial | validate category mapping remains deterministic |
-| EP-WKR-002 | Worker non-retriable domain/input failure | deterministic invalid input/state | `user_input_error` or `conflict_error` | no | immediate terminal failed with persisted reason | partial | ensure no retry on non-retriable categories |
-| EP-WKR-003 | Worker retry exhaustion | repeated retriable failure | category from source; terminal state | capped then no | explicit failed status + error detail | met | implemented in Step 2; keep regression coverage |
-| EP-UI-001 | UI upload action failure | surfaced AppError or fallback exception | category-based safe user message | category-driven | title + message + suggestion + error id | partial | verify consistency on all primary UI actions |
-| EP-LOG-001 | Cross-boundary error logging | missing/uneven fields | n/a | n/a | logs include `error_id`, `category`, `operation`, ids when available | partial | complete in Step 6 (CF-B2) |
-
----
-
-## Verification Targets (Step 6/7)
-
-1. Every critical path has category + retriable policy defined.
-2. API/UI behavior remains safe and actionable.
-3. Worker terminal failures are explicit and persisted.
-4. Logging fields are consistent at critical handoffs.
-
----
-
-## Evidence Links
-
-- Step 2 implementation results: `docs/ver1/ver1-step2-results.md`
-- Carry-forward tracking: `docs/ver1/ver1-step1-2-carry-forward-checklist.md`
-- Canonical contract: `docs/error_handling.md`

docs/ver1/ver1-step2-results.md

@@ -1,80 +0,0 @@
-# Ver1 Step 2 Results: Error Handling & Reliability Hardening
-
-## Summary
-
-Step 2 implementation is complete for the planned reliability and error-handling hardening scope:
-
-1. Worker retries are now explicit, bounded, and category-driven.
-2. Error behavior is more consistent across worker/API/UI boundaries.
-3. Logging now includes stronger boundary context in key failure paths.
-4. Test coverage was expanded for retry policy and new reliability settings.
-
-## Implemented Changes
-
-### 1) Worker retry policy and terminal behavior
-
-- Updated `src/transcription/models.py`:
-  - Added `Job.retry_count` with default `0`.
-- Updated `src/transcription/config.py`:
-  - Added `worker_max_retries`.
-  - Added `worker_retry_backoff_seconds`.
-- Updated `src/transcription/worker.py`:
-  - Added bounded retry decision path (`_should_retry`).
-  - Added requeue behavior (`_requeue_for_retry`) for retriable errors.
-  - Added deterministic terminal failure behavior (`_finalize_failed_job`).
-  - Preserved transcript failure detail persistence (`error_id`, `category`, suggestion).
-
-### 2) API fallback normalization hardening
-
-- Updated `src/transcription/api/errors.py`:
-  - Fallback handler now emits safe generic internal message for unhandled exceptions.
-  - Added structured boundary logging fields including operation and exception type.
-
-### 3) UI interaction reliability guard
-
-- Updated `src/transcription/ui/upload_page.py`:
-  - Added duplicate in-flight submission guard to prevent repeated upload handling while busy.
-
-### 4) Observability/logging improvements
-
-- Updated worker logs in `src/transcription/worker.py` to include operation and domain identifiers in key transitions:
-  - pick
-  - retry
-  - transcribed
-  - failed
-
-## Test Coverage Added/Updated
-
-- Updated `tests/test_models.py`:
-  - Assert `retry_count` default.
-- Updated `tests/test_config.py`:
-  - Added worker retry settings default test.
-- Updated `tests/services/test_worker.py`:
-  - Added retriable requeue test.
-  - Added retry-exhaustion terminal failure test.
-  - Updated existing tests for settings-driven worker behavior.
-- Existing API error tests remained green with fallback behavior updates:
-  - `tests/api/test_error_responses.py`
-
-## Verification Evidence
-
-Executed and passing:
-
-- `uv run pytest tests/services/test_worker.py tests/test_models.py tests/test_config.py tests/api/test_error_responses.py -q`
-- `uv run pytest -q`
-
-## Residual Risks / Follow-ups
-
-1. Retry policy currently uses simple fixed backoff; richer strategy (exponential/jitter) can be added in later hardening.
-2. Full cross-layer structured logging standardization can be expanded in Step 6 observability work.
-3. A formal Step 2 error-path inventory artifact (`ver1-step2-audit.md`) is still recommended for governance completeness.
-
-## Step 2 Exit Assessment
-
-- Error taxonomy and envelope stability: **met**
-- Bounded retry and terminal failure behavior: **met**
-- Worker reliability controls: **met**
-- UI interaction hardening for duplicate actions: **met**
-- Test coverage expansion and full-suite regression safety: **met**
-
-Step 2 is complete and ready to hand off to Ver1 Step 3.

docs/ver1/ver1-step2.md

@@ -1,302 +0,0 @@
-# Step 2 Implementation Plan: Error Handling & Reliability Hardening
-
-## Purpose
-
-Implement **Ver1 Step 2** from `docs/ver1/ver1.md` by standardizing failure behavior and reliability controls so the system fails safely, predictably, and transparently across UI, API, services, worker, and provider boundaries.
-
-Primary governing docs:
-
-- `docs/error_handling.md` (authoritative contract)
-- `docs/requirements.md` (REQ-2, REQ-3, REQ-4, REQ-5, REQ-6)
-- `docs/architecture.md` (boundary ownership and worker lifecycle)
-- `docs/ver1/ver1.md` (Step 2 objective)
-
----
-
-## MCP Skill and Guide Inputs Incorporated
-
-This plan integrates guidance from john-stream-mcp resources:
-
-1. `resource://skills/python-logging-dictconfig/document`
-   - centralized `dictConfig` logging
-   - startup-only configuration
-   - stable named loggers and boundary-level logging discipline
-
-2. `resource://skills/pytesting/document`
-   - deterministic, behavior-first tests
-   - explicit marker usage and fast/slow lane discipline
-   - integration checks for boundary behavior and error contracts
-
-3. `resource://skills/fastapi-async-sqlalchemy-modernization/document`
-   - classify at source boundary
-   - explicit transaction/session behavior under failure
-   - phased rollout with quality gates and rollback awareness
-
-4. `resource://skills/nicegui-ui-customization/document`
-   - explicit user-facing error feedback for each interaction
-   - prevent duplicate actions during in-flight operations
-   - preserve one-way dependency boundaries from UI -> services
-
-5. `resource://skills/fastapi-uv-docker/document` (applied selectively)
-   - lifespan-safe startup/shutdown behavior
-   - health/readiness posture and cloud-native operational checks
-
----
-
-## Current-State Gap Summary
-
-The project already has a strong baseline (`AppError`, taxonomy enum, API envelope, worker persistence), but Step 2 needs completion-level hardening:
-
-1. **Error contract consistency**
-   - API envelope exists, but consistency must be verified for all error pathways.
-2. **Cross-boundary category normalization**
-   - Provider/service/worker mappings exist, but require stricter policy checks and tests.
-3. **Retry policy implementation depth**
-   - Step 2 requires bounded retry policy and clear terminal behavior for retriable failures.
-4. **Operational traceability**
-   - Logging exists; Step 2 requires consistent structured fields at critical boundaries.
-5. **UI failure UX consistency**
-   - UI error handling exists; Step 2 requires explicit contract coverage and anti-duplication safeguards.
-
----
-
-## Scope for Step 2
-
-### In scope
-1. Enforce canonical error taxonomy and envelope across all boundaries.
-2. Standardize logging fields and boundary-level error traceability.
-3. Implement/complete bounded retry and terminal failure behavior in worker paths.
-4. Improve UI/API error presentation consistency and actionable guidance.
-5. Add comprehensive Step 2 test coverage and verification matrix.
-6. Update documentation to reflect final Step 2 policies and behavior.
-
-### Out of scope
-- Major architecture/topology changes (external queue, distributed worker)
-- New end-user feature expansion outside reliability/error handling
-- Full async ORM migration (unless required by bug fix)
-
----
-
-## Target Decisions for Step 2
-
-1. **Taxonomy stability is mandatory**
-   - `ErrorCategory` values remain stable contract identifiers.
-2. **Classification occurs at source boundary**
-   - adapters/services normalize early; UI/API only present safely.
-3. **User safety over internal detail leakage**
-   - expose safe message + suggestion + error_id; keep sensitive detail in logs.
-4. **Retry is explicit and bounded**
-   - only retriable categories may retry; retries are capped; terminal failures persist reason.
-5. **Boundary logs carry correlation fields**
-   - include `error_id`, `category`, `operation`, and domain identifiers where available.
-
----
-
-## Detailed Work Breakdown
-
-## Phase A — Error Contract Audit and Policy Lock
-
-- [ ] **A1. Build error-path inventory**
-  - Enumerate all failure entry points across:
-    - `api/`
-    - `ui/`
-    - `services/`
-    - `worker.py`
-    - `providers/`
-
-- [ ] **A2. Produce taxonomy mapping table**
-  - For each known exception path, map:
-    - source exception type
-    - target `ErrorCategory`
-    - retriable flag
-    - API status (if exposed)
-
-- [ ] **A3. Reconcile with `docs/error_handling.md`**
-  - Resolve any mismatch in category semantics, status codes, or suggested actions.
-
-### Deliverables
-- `docs/ver1/ver1-step2-audit.md` (recommended)
-- taxonomy mapping table
-
-### Exit Criteria
-- Every known failure path has explicit category + retriable policy.
-
----
-
-## Phase B — API and Service Contract Hardening
-
-- [ ] **B1. Enforce API envelope completeness**
-  - Ensure all API errors return:
-    - `error_id`, `category`, `message`, `suggestion`, `timestamp`
-
-- [ ] **B2. Verify category-to-status mapping consistency**
-  - Confirm `api/errors.py` matches `docs/error_handling.md` mapping guidance.
-
-- [ ] **B3. Normalize service exceptions at boundary**
-  - Services should raise `AppError` subclasses for known failures.
-  - Unknown exceptions must become `internal_unexpected_error` with traceable `error_id`.
-
-- [ ] **B4. Ensure safe detail handling**
-  - API/UI messages remain safe.
-  - Diagnostic context remains in logs/persisted failure detail where appropriate.
-
-### Exit Criteria
-- No unstructured/unclassified exception escapes core boundaries.
-- API responses are contract-stable for all tested failure modes.
-
----
-
-## Phase C — Worker Retry and Terminal Failure Policy
-
-- [ ] **C1. Define bounded retry policy**
-  - Add configurable retry settings (attempt limit/backoff policy).
-  - Limit retries to retriable categories.
-
-- [ ] **C2. Implement terminal failure persistence**
-  - On retry exhaustion, persist clear terminal reason and `error_id`.
-  - Ensure job status transitions end deterministically at `failed`.
-
-- [ ] **C3. Add duplicate-processing safety checks**
-  - Prevent duplicate terminal updates when job already resolved.
-
-- [ ] **C4. Validate worker lifecycle under repeated transient failures**
-  - Ensure loop remains stable and responsive.
-
-### Exit Criteria
-- Retries are bounded and policy-driven.
-- Exhausted retries produce deterministic failed state with evidence.
-
----
-
-## Phase D — Logging and Observability Contract Enforcement
-
-- [ ] **D1. Central logging conformance check**
-  - Confirm startup-only `dictConfig` use remains canonical.
-  - No module-level `basicConfig` use.
-
-- [ ] **D2. Standardize error log fields**
-  - Require at minimum when available:
-    - `error_id`, `category`, `operation`, `exception_type`, `job_id`, `document_id`
-
-- [ ] **D3. Boundary handoff logging**
-  - Add/normalize logs at transitions:
-    - UI action -> service
-    - service -> provider/db
-    - worker pickup -> terminal state
-
-- [ ] **D4. Log noise control**
-  - Avoid duplicate stack-trace logging across layers for same exception.
-
-### Exit Criteria
-- Critical failure events are traceable end-to-end via logs and `error_id`.
-
----
-
-## Phase E — UI Error UX Consistency and Interaction Hardening
-
-- [ ] **E1. Standardize user error presentation**
-  - For upload/jobs interactions, ensure:
-    - clear title
-    - plain-language message
-    - suggested action
-    - visible error reference id
-
-- [ ] **E2. Add in-flight interaction guards**
-  - Prevent duplicate submits/click storms during pending operations.
-
-- [ ] **E3. Ensure deterministic UI state recovery**
-  - controls re-enable after failure
-  - status text remains actionable
-
-- [ ] **E4. Keep UI boundary clean**
-  - no provider/protocol details leaked into page modules
-
-### Exit Criteria
-- All primary UI actions have consistent success/failure interaction behavior.
-
----
-
-## Phase F — Test Expansion and Verification
-
-Apply pytesting guidance: behavior-first assertions, deterministic fixtures, strict markers.
-
-- [ ] **F1. API error contract tests**
-  - verify envelope fields and status mapping for each category class.
-
-- [ ] **F2. Service classification tests**
-  - verify known failures map to expected `AppError` subclasses/categories.
-
-- [ ] **F3. Worker retry policy tests**
-  - retriable failure retries and eventual success
-  - retriable failure exhaustion -> terminal failed
-  - non-retriable failure -> immediate failed
-
-- [ ] **F4. UI error behavior tests**
-  - upload/jobs actions show actionable feedback on failures
-  - duplicate action guard behavior
-
-- [ ] **F5. Regression guard tests**
-  - at least one test per previously observed production/real-world failure mode
-
-### Validation Commands
-- `uv run pytest --collect-only -q`
-- `uv run pytest -m unit -q`
-- `uv run pytest -m "not external" -q`
-- `uv run pytest -q`
-
-### Exit Criteria
-- All Step 2 reliability/error contract tests pass.
-- Existing suite remains green.
-
----
-
-## Recommended Implementation Order
-
-1. Phase A — audit and policy lock  
-2. Phase B — API/service contract hardening  
-3. Phase C — worker retry and terminal policy  
-4. Phase D — logging/traceability normalization  
-5. Phase E — UI consistency hardening  
-6. Phase F — test expansion and full verification
-
-This order reduces risk by locking policy first, then applying behavior changes at core boundaries before UI polish.
-
----
-
-## Risks and Mitigations
-
-1. **Risk:** Overly broad retry policy causes hidden failure loops  
-   **Mitigation:** strict category-based retry eligibility + hard cap + terminal persistence.
-
-2. **Risk:** User-facing messages become too technical  
-   **Mitigation:** enforce safe message + suggestion contract in tests.
-
-3. **Risk:** Logging becomes noisy/redundant  
-   **Mitigation:** boundary logging rules and single-trace ownership.
-
-4. **Risk:** Reliability work introduces regressions in happy path  
-   **Mitigation:** run full suite continuously; preserve integration pipeline tests.
-
----
-
-## Step 2 Completion Checklist
-
-- [ ] Error taxonomy mapping table completed and approved.
-- [ ] API envelope and HTTP status behavior verified for all relevant failure categories.
-- [ ] Service/provider exception normalization is consistent and tested.
-- [ ] Worker retry behavior is bounded, explicit, and terminal-state safe.
-- [ ] Structured error logging fields are present at boundary handoffs.
-- [ ] UI failure flows provide clear, actionable, and traceable feedback.
-- [ ] Full test suite passes with new Step 2 coverage included.
-- [ ] `docs/ver1/ver1-step2-results.md` created with evidence and residual risks.
-
----
-
-## Handoff to Step 3
-
-After Step 2 completion, Step 3 (Functional Completion by Requirement Domain) proceeds on a hardened foundation:
-
-- stable failure contracts,
-- predictable retries and terminal behavior,
-- actionable user/API error semantics,
-- improved diagnostic traceability.

docs/ver1/ver1-step3-results.md

@@ -1,160 +0,0 @@
-# Ver1 Step 3 Results: Functional Completion by Requirement Domain
-
-## Summary
-
-Step 3 implementation has been completed for the planned functional-completion scope in a practical personal-scale form.
-
-Implemented in this step:
-
-1. Revision history and acceptance workflows for transcripts.
-2. Search over accepted transcript revisions.
-3. Export of accepted transcript data.
-4. API routes for jobs, revisions, search, and export.
-5. UI pathways for revision management, search, and export.
-6. Carry-forward integration updates for Step 1/2 follow-ups owned by Step 3.
-
----
-
-## Implemented Changes
-
-### 1) Data model expansion (functional domain)
-
-Updated `src/transcription/models.py`:
-
-- Added `JobStatus.COMPLETED`.
-- Added `TranscriptRevision` table/model:
-  - `job_id`
-  - `revision_number`
-  - `text`
-  - `source`
-  - `accepted`
-  - `created_at`
-- Added `Job.revisions` relationship.
-
-This supports immutable revision history and accepted-transcript semantics for search/export.
-
-### 2) Step 3 service layer
-
-Created `src/transcription/services/library.py` with service-backed functional operations:
-
-- `list_jobs(...)`
-- `get_job_detail(...)`
-- `add_revision(...)`
-- `accept_revision(...)`
-- `list_revisions(...)`
-- `search_accepted_transcripts(...)`
-- `export_transcripts(...)`
-
-Key behavior:
-
-- revisions are append-only and incrementing
-- accepted revision is unique per job
-- accepting a revision syncs canonical transcript and sets job to `completed`
-- search scope is accepted revisions only
-- export emits deterministic record payloads for archive workflows
-
-### 3) Worker integration for revision provenance
-
-Updated `src/transcription/worker.py`:
-
-- Success path now calls `add_revision(..., source="worker", accepted=False)`.
-- Worker still persists canonical transcript and `transcribed` job state.
-- Initial machine transcription now appears in revision history.
-
-### 4) API functional completion
-
-Created `src/transcription/api/routes.py` and wired in `src/transcription/app.py`.
-
-New endpoints:
-
-- `GET /api/jobs`
-- `GET /api/jobs/{job_id}`
-- `GET /api/jobs/{job_id}/revisions`
-- `POST /api/jobs/{job_id}/revisions`
-- `POST /api/revisions/{revision_id}/accept`
-- `GET /api/search?query=...`
-- `GET /api/export?accepted_only=true|false`
-
-### 5) UI functional completion
-
-Updated `src/transcription/ui/jobs_page.py`:
-
-- Job detail now includes revision history panel.
-- Added user revision submission.
-- Added revision accept action.
-- Added `/search` page for accepted transcript search.
-- Added `/export` page for accepted transcript export preview.
-
----
-
-## Test Evidence
-
-### Added/Updated Tests
-
-1. `tests/services/test_library.py`
-   - revision append/accept behavior
-   - accepted-only search behavior
-   - export payload behavior
-
-2. `tests/api/test_routes.py`
-   - jobs/revisions/search/export API serialization and contract behavior
-
-3. `tests/test_models.py`
-   - `completed` status transition coverage
-   - `TranscriptRevision` persistence and relationship coverage
-
-4. `tests/services/test_worker.py`
-   - success-path now verifies initial worker-generated revision persistence
-
-### Full Validation Run
-
-Executed and passing:
-
-- `uv run pytest -q`
-
----
-
-## Requirement Slice Coverage (Step 3)
-
-| Slice | REQ Coverage | Status | Evidence |
-| --- | --- | --- | --- |
-| Core lifecycle completion and visibility | REQ-0, REQ-2, REQ-3, REQ-5, REQ-6 | met | worker integration + API/UI jobs routes + tests |
-| Revision history and acceptance | REQ-3, REQ-4, REQ-5, REQ-11 | met | `TranscriptRevision`, `services/library.py`, UI revision panel, tests |
-| Search over accepted transcripts | REQ-5, REQ-11 | met | `search_accepted_transcripts`, `/api/search`, `/ui/search`, tests |
-| Export transcript data | REQ-4, REQ-5, REQ-11 | met | `export_transcripts`, `/api/export`, `/ui/export`, tests |
-| Prompt and verbatim flow continuity | REQ-12 | met (continued) | worker transcription flow unchanged in prompt-loading contract |
-
----
-
-## Carry-Forward Integration Updates
-
-Updated:
-
-- `docs/ver1/ver1-step1-2-carry-forward-checklist.md`
-
-Step 3 updates recorded for:
-
-- CF-A1: in progress with Step 3 inspection evidence
-- CF-A3: in progress with boundary-discipline evidence
-- CF-C1: done (Step 3 traceability artifacts integrated)
-- CF-C2: in progress (routing preserved for later steps)
-
----
-
-## Residual Follow-ups
-
-1. Step 4: migration rehearsal and rollback runbook execution for schema changes.
-2. Step 6/7: broader error-path inventory closure and logging field normalization.
-3. Step 9: release readiness reconfirmation for runtime ownership and migration behavior.
-
----
-
-## Step 3 Exit Assessment
-
-- Requirement-domain functional completion: **met**
-- Data integrity and state consistency for new flows: **met**
-- API/UI parity for new Step 3 features: **met**
-- Test and regression safety: **met**
-- Carry-forward integration obligations (Step 3-owned): **met/in progress as routed**
-
-Step 3 is complete and ready to hand off to Step 4.

docs/ver1/ver1-step3.md

@@ -1,433 +0,0 @@
-# Step 3 Implementation Plan: Functional Completion by Requirement Domain
-
-## Purpose
-
-Implement **Ver1 Step 3** from `docs/ver1/ver1.md` by completing all in-scope V1 functional requirements in a practical, user-first order while preserving:
-
-- personal-scale operation
-- single-operator workflow
-- private-network deployment assumptions
-- low operational overhead
-- clean architecture boundaries
-
-Primary governing docs:
-
-- `docs/ver1/ver1.md` (Step 3 objective and sequencing)
-- `docs/architecture.md` (module boundaries, workflow, simplicity guardrails)
-- `docs/requirements.md` (REQ-0 through REQ-12 traceability)
-- `docs/error_handling.md` (error contract across boundaries)
-- `docs/intent.md` (verbatim transcription policy and prompt curation)
-- `docs/ver1/ver1-step1-2-carry-forward-checklist.md` (Step 1/2 carry-forward integration)
-- `docs/ver1/ver1-step2-error-path-inventory.md` (failure-path coverage visibility)
-
----
-
-## MCP Resources Reviewed and Applied
-
-All resources on `john-stream-mcp` were reviewed. Step 3 applies the following guidance directly:
-
-1. `resource://skills/nicegui/document`
-   - modular page registration
-   - one-way dependency flow (`ui/api -> services -> infra`)
-   - async-first UI responsiveness expectations
-
-2. `resource://skills/nicegui-ui-customization/document`
-   - reusable UI component extraction for repeated patterns
-   - in-flight guards and explicit success/failure user feedback
-   - event-driven updates over ad-hoc polling
-
-3. `resource://skills/fastapi-async-sqlalchemy-modernization/document`
-   - explicit transaction/session boundaries
-   - deterministic resource ownership and cleanup continuity from Step 1
-   - incremental migration strategy with rollback-aware checkpoints
-
-4. `resource://skills/pydantic-settings/document`
-   - typed configuration as single source of runtime truth
-   - explicit source precedence and environment-safe defaults
-
-5. `resource://skills/python-logging-dictconfig/document`
-   - centralized startup-only logging configuration
-   - named logger discipline and boundary-level structured fields
-
-6. `resource://skills/pytesting/document`
-   - deterministic test structure and marker discipline
-   - behavior-first tests with clear fast-path and full-suite validation
-
-7. `resource://skills/fastapi-uv-docker/document`
-   - health endpoint and runtime startup/shutdown hygiene
-   - compose/deployment readiness constraints relevant to functional completion
-
-8. `resource://skills/python-typing/document`
-   - modern typing updates where touched by Step 3 work
-
-9. `resource://skills/ruff-linting-formating/document`
-   - maintain lint/format consistency in all modified modules
-
-10. `resource://prompts/greenfield-architecture/document`
-   - explicit staged delivery with tradeoff-aware sequencing and test strategy
-
-11. `resource://prompts/pytest-scaffold/document`
-12. `resource://prompts/pytest-fill-scaffold/document`
-   - structure-first test planning, then deterministic implementation fill-in
-
-Resources reviewed but not directly in Step 3 execution scope (no changes required now):
-
-- `copilot-customization`, `mcp-details`, `vscode-configuration`, `zensical-docs`
-- prompts: `authoring`, `mcp-consumer-repo-shim`
-
----
-
-## Step 3 Success Criteria
-
-Step 3 is complete when:
-
-1. All Step 3-targeted requirement slices are implemented and verified.
-2. Functional behavior is available through UI/API where required.
-3. Core data integrity and state transitions are deterministic.
-4. Error behavior follows `docs/error_handling.md` contracts.
-5. Carry-forward Step 1/2 items mapped to Step 3 are updated with evidence.
-
----
-
-## Requirement-Slice Execution Model (Applied to Every Slice)
-
-For each slice, execute this sequence:
-
-1. Confirm contract/schema and boundary ownership.
-2. Implement service/domain logic.
-3. Implement persistence/state transitions.
-4. Integrate API and/or UI behavior.
-5. Add/update unit + integration + targeted end-to-end tests.
-6. Update docs and traceability artifacts.
-
-Definition of done per slice:
-
-- behavior is functional
-- tests pass in intended marker lanes
-- error pathways are classified and surfaced correctly
-- requirement traceability is updated with evidence
-
----
-
-## Detailed Workstreams
-
-## Workstream A — Functional Baseline Audit and Slice Backlog Lock
-
-### Goals
-
-- establish exact Step 3 functional delta from current implementation
-- lock a practical slice backlog before coding
-
-### Tasks
-
-1. Build Step 3 requirement matrix (REQ -> current status -> gap -> target slice).
-2. Map each gap to one of these domains:
-   - Upload and lifecycle integrity
-   - Review and revision history
-   - Search over accepted transcripts
-   - Export workflows
-   - Prompt asset management behavior
-   - API/UI parity and status visibility
-3. Align each slice with architecture boundary ownership and persistence strategy.
-4. Link open carry-forward items from checklist:
-   - CF-A1, CF-A3 (architecture continuity in Step 3)
-   - CF-C1, CF-C2 (traceability/execution continuity)
-
-### Deliverables
-
-- Step 3 requirement-slice matrix (appendix in this doc or separate artifact)
-- prioritized slice backlog with owner and validation method
-
-### Exit Criteria
-
-- every Step 3 slice maps to REQ IDs and a validation method
-- no ambiguous ownership remains for in-scope slices
-
----
-
-## Workstream B — Core End-User Flows (Upload -> Transcribe -> Review)
-
-### Related Requirements
-
-- REQ-0, REQ-1, REQ-2, REQ-3, REQ-4, REQ-5, REQ-6, REQ-12
-
-### Goals
-
-- guarantee end-to-end reliability and usability of the primary user flow
-- ensure review experience supports transcript acceptance and correction
-
-### Tasks
-
-1. Validate and close any lifecycle-state gaps:
-   - enforce valid transitions (`queued -> processing -> transcribed/failed/completed`)
-   - ensure transition visibility in UI/API
-2. Review experience completion:
-   - transcript detail display stability
-   - failure detail readability and actionability
-   - acceptance/edit path for human review
-3. Ensure prompt-asset integration remains file-based and auditable:
-   - one prompt per Markdown file
-   - prompt selection/usage traceability in job outcomes (if available in model)
-4. Confirm worker/UI interactions remain responsive under long-running jobs:
-   - in-flight guards
-   - clear status refresh behavior
-
-### Deliverables
-
-- complete end-user flow behavior with stable lifecycle visibility
-- test coverage for happy path and failure path
-
-### Exit Criteria
-
-- user can run upload -> process -> review reliably
-- failed and successful outcomes are both actionable and traceable
-
----
-
-## Workstream C — Revision History and Provenance Completion
-
-### Related Requirements
-
-- REQ-3, REQ-4, REQ-5, REQ-11
-
-### Goals
-
-- finalize immutable transcript revision behavior and provenance consistency
-
-### Tasks
-
-1. Define/confirm revision invariants:
-   - append-only revision history
-   - clear current/accepted revision indicator
-2. Persist revision events consistently through service layer boundaries.
-3. Ensure UI/API expose revision timeline and selected revision details.
-4. Align error handling for revision conflicts and missing resources.
-
-### Deliverables
-
-- revision-history feature completeness
-- provenance and history read-path coverage
-
-### Exit Criteria
-
-- transcript edits produce deterministic revision records
-- previous revisions remain inspectable
-
----
-
-## Workstream D — Search Completion (Accepted Transcript Scope)
-
-### Related Requirements
-
-- REQ-0, REQ-5, REQ-11
-
-### Goals
-
-- provide practical search over accepted transcripts for personal corpus usage
-
-### Tasks
-
-1. Finalize searchable scope and indexing rules (accepted/current text only).
-2. Implement service-backed search query behavior.
-3. Expose search in UI/API with clear result metadata (document/job/revision context).
-4. Add guardrails for empty/no-result/error scenarios with actionable messaging.
-
-### Deliverables
-
-- functional search pathway with deterministic results for accepted text
-
-### Exit Criteria
-
-- operator can find transcripts reliably by text queries
-- no-result and error states are clear and non-silent
-
----
-
-## Workstream E — Export Completion
-
-### Related Requirements
-
-- REQ-0, REQ-4, REQ-5, REQ-11
-
-### Goals
-
-- deliver practical export of transcript data for personal archive use
-
-### Tasks
-
-1. Finalize export contract (format, included fields, scope filters).
-2. Implement export service with deterministic data mapping.
-3. Add UI/API trigger path and user-visible completion/failure feedback.
-4. Validate export integrity against persisted source-of-record entities.
-
-### Deliverables
-
-- end-to-end export capability with operator-visible outcomes
-
-### Exit Criteria
-
-- export output is complete, consistent, and usable for downstream personal archive workflows
-
----
-
-## Workstream F — API/UI Parity and Interaction Hardening
-
-### Related Requirements
-
-- REQ-5 plus cross-cutting REQ-2/3/4
-
-### Goals
-
-- ensure UI and API expose coherent feature behavior and error contracts
-
-### Tasks
-
-1. Verify API/UI parity matrix for each Step 3 slice.
-2. Standardize interaction behavior:
-   - loading and in-flight states
-   - success/failure notifications
-   - stable error_id visibility where user-facing
-3. Ensure route/page modules remain composition-focused (business logic in services).
-
-### Deliverables
-
-- API/UI parity checklist with resolved gaps
-
-### Exit Criteria
-
-- no major flow exists in one interface with conflicting semantics in the other
-
----
-
-## Workstream G — Carry-Forward Integration During Step 3
-
-### Goals
-
-- close Step 1/2 follow-ups that are Step 3-owned
-
-### Tasks
-
-1. Update checklist item CF-A1 as Step 3 slices touch runtime resources.
-2. Update checklist item CF-A3 with lightweight boundary enforcement evidence.
-3. Update CF-C1/CF-C2 traceability mapping with Step 3 outcomes.
-
-### Deliverables
-
-- updated `docs/ver1/ver1-step1-2-carry-forward-checklist.md` evidence entries
-
-### Exit Criteria
-
-- Step 3-owned carry-forward items are either completed or explicitly routed with evidence
-
----
-
-## Test and Validation Plan
-
-Apply `pytesting` guidance with deterministic, behavior-focused coverage.
-
-### Validation Lanes
-
-1. Structure/collection:
-   - `uv run pytest --collect-only -q`
-2. Fast feedback lane:
-   - `uv run pytest -m unit -q`
-3. Main verification lane:
-   - `uv run pytest -m "not external" -q`
-4. Full suite:
-   - `uv run pytest -q`
-
-### Required Coverage Areas
-
-- lifecycle transition invariants
-- revision history invariants
-- search query behavior and result mapping
-- export integrity and failure handling
-- UI interaction guards and actionable failure feedback
-- API envelope and status consistency for new/changed flows
-
-### Test Design Rules
-
-- one behavior target per test
-- minimize heavy mocking; prefer real-path behavior checks where practical
-- keep markers explicit and strict
-
----
-
-## Logging, Error, and Config Guardrails for Step 3 Changes
-
-1. Logging
-   - keep centralized startup logging config (`dictConfig`) as canonical
-   - include required error fields at boundary failures (`error_id`, `category`, `operation`, identifiers where available)
-
-2. Error handling
-   - preserve taxonomy stability from `docs/error_handling.md`
-   - map any new failure pathways into existing categories
-   - surface actionable suggestions in UI/API
-
-3. Configuration
-   - use typed settings and avoid ad-hoc env reads in business modules
-   - keep environment behavior explicit and documented
-
----
-
-## Implementation Order (Detailed)
-
-1. Workstream A: audit and backlog lock
-2. Workstream B: core flow completion
-3. Workstream C: revision/provenance completion
-4. Workstream D: search completion
-5. Workstream E: export completion
-6. Workstream F: API/UI parity hardening
-7. Workstream G: carry-forward integration updates
-8. Full validation pass + docs/traceability updates
-
----
-
-## Deliverables
-
-1. Step 3 requirement-slice matrix with REQ mapping and evidence links
-2. implemented Step 3 functional slices across service/persistence/API/UI
-3. updated tests and passing validation lanes
-4. updated carry-forward checklist entries (`CF-A1`, `CF-A3`, `CF-C1`, `CF-C2` as applicable)
-5. Step 3 results document (`docs/ver1/ver1-step3-results.md`)
-
----
-
-## Risks and Mitigations
-
-1. **Risk:** Scope creep from optional enhancements during feature completion
-   - **Mitigation:** enforce REQ-mapped slice backlog and defer non-REQ enhancements
-
-2. **Risk:** Functional parity drift between UI and API
-   - **Mitigation:** maintain parity matrix and verify both surfaces per slice
-
-3. **Risk:** Data-model changes introduce migration surprises
-   - **Mitigation:** coordinate with Step 4 runbook expectations early and test on representative data
-
-4. **Risk:** Reliability regressions while adding functionality
-   - **Mitigation:** run full error-path regression checks and keep Step 2 contracts intact
-
----
-
-## Step 3 Completion Checklist
-
-- [ ] Step 3 requirement-slice matrix completed and linked to REQ IDs.
-- [ ] Core end-user flow is functionally complete and verified.
-- [ ] Revision history/provenance behavior is complete and test-covered.
-- [ ] Search over accepted transcripts is complete and test-covered.
-- [ ] Export flow is complete and test-covered.
-- [ ] API/UI parity checklist has no unresolved high-impact gaps.
-- [ ] Step 3-owned carry-forward items are updated with evidence.
-- [ ] Validation lanes pass (`collect-only`, unit, non-external, full).
-- [ ] `docs/ver1/ver1-step3-results.md` is created with evidence and residual follow-ups.
-
----
-
-## Handoff to Step 4
-
-Step 3 completion enables Step 4 (Data Model and Migration Safety) with:
-
-- finalized functional domain behavior
-- stable persistence expectations
-- traceable requirement evidence
-- clarified migration-impact surface

docs/ver1/ver1-step4-migration-runbook.md

@@ -1,113 +0,0 @@
-# Ver1 Step 4 Migration and Rollback Runbook
-
-## Purpose
-
-Provide a concise, operator-safe procedure for schema migration execution,
-compatibility validation, and rollback/mitigation for personal-scale deployments.
-
-This runbook supports `docs/ver1/ver1-step4.md` and REQ-10 by keeping normal
-production startup non-mutating unless explicitly configured otherwise.
-
----
-
-## Preconditions
-
-1. Application version to deploy is known and checked out.
-2. `.env` values are configured for target environment.
-3. Database backup path is prepared.
-4. Application process is stopped before migration on production-like systems.
-
----
-
-## Commands
-
-Use explicit migration runner operations:
-
-1. List pending migrations:
-   - `uv run python -m transcription.migration_runner --list`
-2. Apply pending migrations:
-   - `uv run python -m transcription.migration_runner --apply`
-3. Validate schema compatibility:
-   - `uv run python -m transcription.migration_runner --check`
-
-Recommended execution order:
-
-1. `--list`
-2. backup database
-3. `--apply`
-4. `--check`
-5. start application
-
----
-
-## Backup Procedure (SQLite Baseline)
-
-For SQLite deployments, copy the DB file before migration:
-
-- Example DB path default: `./transcription.db`
-- Keep timestamped backup copy in a safe location.
-
-If the file is in active use, stop the app first.
-
----
-
-## Verification Checklist
-
-After migration apply:
-
-1. `--check` exits successfully.
-2. `schema_migration_history` includes applied revisions.
-3. Application starts successfully.
-4. Health endpoint responds: `/healthz`.
-5. Critical flows smoke-check:
-   - upload
-   - job processing
-   - revision listing/acceptance
-
----
-
-## Rollback and Mitigation Decision Tree
-
-1. If migration fails before changes commit:
-   - fix issue
-   - re-run apply
-2. If migration partially applied or compatibility check fails:
-   - stop app
-   - restore from backup
-   - investigate and produce forward-fix migration if needed
-3. If app starts but functional invariants fail:
-   - stop app
-   - restore backup
-   - add corrective migration/backfill and rehearse before retry
-
-For this Step 4 baseline, backup restore is the primary rollback mechanism.
-
----
-
-## Failure Classification Guidance
-
-Classify migration failures using `docs/error_handling.md` categories:
-
-- transient connection issues -> `infrastructure_transient_error`
-- permissions/misconfiguration -> `infrastructure_persistent_error`
-- unexpected migration logic defects -> `internal_unexpected_error`
-
-Record failure details with operation context and timestamp.
-
----
-
-## Operational Notes
-
-- `migration_auto_apply_on_startup` defaults to `False`.
-- `validate_schema_on_startup` defaults to `True`.
-- Startup schema validation fails fast on incompatibility.
-
-This protects production from accidental schema drift.
-
----
-
-## Post-Step-4 Follow-Up
-
-If migration complexity grows beyond lightweight revision scripts,
-introduce a dedicated migration framework in a future step while preserving
-this runbook structure and operator-first workflow.

docs/ver1/ver1-step4-results.md

@@ -1,153 +0,0 @@
-# Ver1 Step 4 Results: Data Model and Migration Safety
-
-## Summary
-
-Step 4 implementation status: **complete (baseline scope)**.
-
-This document records completed migration-safety work, validation evidence, and remaining follow-ups for Ver1 Step 4.
-
-Implemented in this step:
-
-1. Added explicit migration framework module with revision history tracking.
-2. Added schema compatibility validation and startup guardrails.
-3. Added migration runner CLI for list/apply/check operations.
-4. Added migration tests and Step 4 validation evidence.
-5. Added Step 4 migration/rollback runbook.
----
-
-## Implemented Changes
-
-### 1) Schema audit and invariant lock
-
-Implemented read-only compatibility checks in `src/transcription/db.py`:
-
-- `validate_schema_compatibility(...)` verifies required V1 tables:
-  - `document`
-  - `job`
-  - `transcript`
-  - `transcriptrevision`
-- verifies required `job.retry_count` column
-- returns explicit issue identifiers (non-mutating check)
-
-### 2) Migration policy/tooling lock
-
-Added explicit migration revision model in `src/transcription/migrations.py`:
-
-- `MigrationRevision` dataclass
-- ordered `MIGRATIONS` registry
-- migration history table: `schema_migration_history`
-- explicit pending-list and apply operations
-
-### 3) Forward migration implementation
-
-Implemented two baseline forward migrations:
-
-1. `0001_add_retry_count_to_job`
-2. `0002_create_transcriptrevision_table`
-
-Each migration is idempotent and recorded in migration history.
-
-### 4) Rollback and mitigation runbook
-
-Created `docs/ver1/ver1-step4-migration-runbook.md` with:
-
-- preconditions
-- list/apply/check command sequence
-- backup-first procedure
-- verification checklist
-- rollback/mitigation decision tree
-- error classification guidance aligned to `docs/error_handling.md`
-
-### 5) Backfill implementation or explicit no-backfill decision
-
-No backfill required for this baseline Step 4 scope.
-
-Rationale:
-
-- additive migration operations only
-- default values and new-table creation do not require historical row rewrites for current V1 invariants
-- residual advanced backfill scenarios deferred unless future schema evolution introduces incompatible transforms
----
-
-## Test and Verification Evidence
-
-### Added/Updated Tests
-
-1. `tests/test_migrations.py`
-   - pending migration discovery
-   - migration apply + history recording
-   - idempotent re-apply behavior
-2. `tests/test_db.py`
-   - compatibility-check behavior on fresh schema
-   - table expectation updates for `transcriptrevision`
-3. `tests/test_config.py`
-   - migration safety setting defaults
-4. `tests/test_app.py`
-   - lifespan test compatibility with migration/validation startup hooks
-### Validation Runs
-
-Run and record outcomes:
-
-- `uv run pytest --collect-only -q` -> passed
-- `uv run pytest -m unit -q` -> passed
-- `uv run pytest -m "not external" -q` -> passed
-- `uv run pytest -q` -> passed
-### Migration Rehearsal Evidence
-
-Migration rehearsal details (test-based):
-
-- baseline data set used: in-memory SQLite legacy-shaped schema fixture (`job` table missing Step 4 additions)
-- forward migration result: pending revisions applied successfully (`0001`, `0002`)
-- post-migration verification result: schema checks pass and migration history recorded
-- rollback/mitigation rehearsal result: runbook defined backup-restore primary rollback class for personal-scale SQLite deployment
----
-
-## Requirement Traceability (Step 4)
-
-| Step 4 Area | REQ Coverage | Status | Evidence |
-| --- | --- | --- | --- |
-| Schema lifecycle and state persistence safety | REQ-3, REQ-4, REQ-11 | met | `src/transcription/migrations.py`, `tests/test_migrations.py`, `tests/test_db.py` |
-| Lifespan/runtime ownership continuity | REQ-7 | met | `src/transcription/app.py` startup checks + existing lifespan ownership model |
-| Explicit non-mutating production startup policy | REQ-10 | met | `migration_auto_apply_on_startup=False` default + explicit runner workflow + startup validation gate |
-| Prompt/data continuity constraints | REQ-12 | met (continued) | no prompt-contract mutation in Step 4 changes |
----
-
-## Operational Artifacts Produced
-
-- `docs/ver1/ver1-step4.md`
-- `docs/ver1/ver1-step4-migration-runbook.md`
-- `src/transcription/migrations.py`
-- `src/transcription/migration_runner.py`
-- README migration workflow updates
----
-
-## Risks, Exceptions, and Follow-Ups
-
-1. This lightweight migration system is appropriate for current personal-scale scope but may require a dedicated framework as schema complexity grows.
-2. Rollback remains backup-restore primary; reversible down-migration coverage is intentionally limited in this baseline.
-3. Startup compatibility checks currently fail fast with generic runtime error text and can be further normalized under API/operator error envelopes in later hardening.
-
-Open follow-ups to carry forward:
-
-- Evaluate migration framework escalation criteria in Step 9/10 readiness updates.
-- Add optional richer structured migration logging fields if observability scope expands.
----
-
-## Step 4 Exit Assessment
-
-- Schema validation against finalized V1 domain: **met**
-- Forward migration path safety and repeatability: **met (baseline scope)**
-- Rollback/mitigation readiness: **met (backup-restore primary path)**
-- Backfill risk closure: **met (no backfill required for current deltas)**
-- Test and regression safety: **met**
-
-Step 4 completion status: **complete (baseline scope)**
----
-
-## Handoff to Step 5
-
-Once Step 4 is marked complete, Step 5 can proceed with:
-
-- verified migration safety baseline
-- explicit rollback and recovery procedures
-- reduced data-integrity risk entering private-network safety hardening

docs/ver1/ver1-step4.md

@@ -1,378 +0,0 @@
-# Step 4 Implementation Plan: Data Model and Migration Safety
-
-## Purpose
-
-Implement **Ver1 Step 4** from `docs/ver1/ver1.md` by making data-model evolution safe, explicit, and repeatable for personal-scale deployment.
-
-Step 4 ensures schema changes are handled through deterministic migration workflows rather than implicit startup mutation, while preserving:
-
-- personal-scale operational simplicity
-- single-operator deployment model
-- lifecycle-owned runtime resource boundaries
-- stable requirement traceability and low rollback risk
-
-Primary governing docs:
-
-- `docs/ver1/ver1.md` (Step 4 objective and sequencing)
-- `docs/architecture.md` (runtime ownership, persistence boundaries, simplicity guardrails)
-- `docs/requirements.md` (REQ-3, REQ-4, REQ-7, REQ-10, REQ-11, REQ-12 emphasis)
-- `docs/error_handling.md` (failure classification and safe error surfacing)
-- `docs/intent.md` (verbatim/transcription/revision domain behavior)
-
----
-
-## MCP Resources Reviewed and Applied
-
-All currently available resources on `john-stream-mcp` were reviewed. Step 4 applies the following guidance directly:
-
-1. `resource://skills/fastapi-async-sqlalchemy-modernization/document`
-   - explicit engine/session lifecycle ownership
-   - transaction boundary clarity for schema transitions and backfills
-   - phased rollout with rollback-aware checkpoints
-
-2. `resource://skills/pydantic-settings/document`
-   - typed migration/runtime safety settings
-   - explicit source-precedence behavior for operational toggles
-   - fail-fast config semantics for unsafe startup paths
-
-3. `resource://skills/pytesting/document`
-   - deterministic migration verification lanes
-   - strict marker discipline
-   - behavior-first test coverage for migration outcomes
-
-4. `resource://skills/python-logging-dictconfig/document`
-   - startup-centralized logging configuration
-   - structured migration and rollback event traceability
-
-5. `resource://skills/fastapi-uv-docker/document`
-   - deployment and rehearsal discipline
-   - startup/health posture validation during migration windows
-
-6. `resource://skills/python-typing/document`
-   - modern typing hygiene for touched migration/persistence modules
-
-7. `resource://skills/ruff-linting-formating/document`
-   - lint/format consistency for migration scripts and database modules
-
-Planning methodology inputs also applied:
-
-8. `resource://prompts/greenfield-architecture/document`
-   - staged execution with explicit risk and extension handling
-
-9. `resource://prompts/pytest-scaffold/document`
-10. `resource://prompts/pytest-fill-scaffold/document`
-   - test-structure-first and deterministic fill-in sequencing
-
-Reviewed but not directly Step 4 execution-critical:
-
-- skills: `copilot-customization`, `mcp-details`, `nicegui`, `nicegui-ui-customization`, `vscode-configuration`, `zensical-docs`
-- prompts: `authoring`, `mcp-consumer-repo-shim`
-
----
-
-## Current-State Gap Summary (Step 4 Scope)
-
-Based on Step 1–3 outcomes and current docs/tests:
-
-1. **Bootstrap policy baseline is present**
-   - Environment-aware schema bootstrap policy exists and aligns with REQ-10 intent.
-2. **Functional model expanded in Step 3**
-   - Revision/acceptance features introduce schema evolution requirements that need formal migration safety rehearsal.
-3. **Runbook maturity required**
-   - Step 4 requires explicit migration + rollback procedures and evidence.
-4. **Backfill risk must be evaluated**
-   - New/changed fields and semantics must be checked for historical data reconciliation needs.
-5. **Release-path integration needed**
-   - Step 4 artifacts must feed Step 9 release readiness and Step 10 docs completion.
-
----
-
-## Scope for Step 4
-
-### In scope
-
-1. Validate final V1 schema against implemented domain behavior (post-Step 3 reality).
-2. Define and implement forward-safe migration path for expected upgrades.
-3. Define and document rollback/mitigation strategy for migration failures.
-4. Implement backfill scripts only if required, with idempotent behavior.
-5. Rehearse migration + rollback locally using representative sample data.
-6. Add Step 4-specific verification tests and operational checks.
-7. Produce operator-facing migration/rollback runbook and Step 4 results evidence.
-
-### Out of scope
-
-- Distributed/externally orchestrated migration systems
-- Major persistence-architecture rewrites beyond V1 scope
-- Non-V1 enhancement migrations unrelated to implemented requirement slices
-
----
-
-## Target Decisions for Step 4
-
-1. **Production startup remains non-mutating by default**
-   - Preserve REQ-10 posture and avoid implicit schema mutation at normal startup.
-
-2. **Schema changes are explicit operator workflows**
-   - Migrations run as deliberate operational actions, not hidden side effects.
-
-3. **Migration safety beats migration speed**
-   - Additive and reversible-first patterns are preferred where possible.
-
-4. **Rollback policy is explicit per change**
-   - Each migration must declare rollback class:
-     - direct rollback supported
-     - forward-fix required
-     - backup restore required
-
-5. **Backfills are optional and minimal**
-   - Introduce only when required by correctness/invariants, never by convenience.
-
-6. **Migration observability is mandatory**
-   - Structured logs include operation, migration identifier, status, and failure classification.
-
----
-
-## Detailed Work Breakdown
-
-## Phase A — Schema and Domain Invariant Audit
-
-- [ ] **A1. Build canonical V1 schema inventory**
-  - Enumerate all persisted entities and key fields:
-    - document records
-    - jobs and statuses
-    - transcripts
-    - transcript revisions
-    - failure/provenance fields
-- [ ] **A2. Validate invariants against implemented behavior**
-  - Cross-check Step 3 functionality and current domain expectations:
-    - append-only revision history
-    - accepted revision semantics
-    - canonical transcript synchronization behavior
-- [ ] **A3. Classify required schema deltas**
-  - Categorize deltas:
-    - additive and safe
-    - compatibility-sensitive
-    - potentially destructive (must be staged or deferred)
-
-### Deliverables
-
-- `docs/ver1/ver1-step4-schema-audit.md` (recommended)
-- schema-delta matrix with risk class and owning module
-
-### Exit Criteria
-
-- all required schema changes have explicit rationale and risk classification
-- no ambiguous domain invariant remains
-
----
-
-## Phase B — Migration Policy and Tooling Lock
-
-- [ ] **B1. Lock migration workflow policy**
-  - Define canonical migration execution path and artifact conventions.
-- [ ] **B2. Define migration authoring checklist**
-  - Include:
-    - preconditions
-    - forward steps
-    - rollback class
-    - post-verification checks
-- [ ] **B3. Align policy with runtime startup safeguards**
-  - Ensure production startup remains explicit/non-mutating by default.
-- [ ] **B4. Define operator invocation standard**
-  - One documented command path for local and production-like workflows.
-
-### Deliverables
-
-- migration policy section (this doc + runbook)
-- migration authoring/review checklist
-
-### Exit Criteria
-
-- one unambiguous migration process exists and is documented
-- startup policy and migration policy are consistent and non-conflicting
-
----
-
-## Phase C — Forward Migration Implementation
-
-- [ ] **C1. Implement required migration set**
-  - Build migration artifacts for all approved Step 4 deltas.
-- [ ] **C2. Preserve compatibility where needed**
-  - Use staged expand/contract strategy when direct cutover is unsafe.
-- [ ] **C3. Add migration logging checkpoints**
-  - Log start, phase boundaries, completion, and failure details.
-- [ ] **C4. Verify post-migration schema state**
-  - Confirm expected tables/columns/constraints/indexes are present.
-
-### Deliverables
-
-- migration artifacts/scripts for V1 target schema
-- schema verification checklist outputs
-
-### Exit Criteria
-
-- baseline-to-target forward migration executes successfully
-- post-migration checks pass deterministically
-
----
-
-## Phase D — Rollback and Mitigation Strategy
-
-- [ ] **D1. Define rollback classes per migration**
-  - direct downgrade vs forward-fix vs backup-restore.
-- [ ] **D2. Create rollback decision tree**
-  - trigger conditions, safe stop points, and recovery path.
-- [ ] **D3. Align failure classification with `error_handling.md`**
-  - normalize migration failures into canonical categories:
-    - `infrastructure_transient_error`
-    - `infrastructure_persistent_error`
-    - `internal_unexpected_error` (as needed)
-- [ ] **D4. Rehearse rollback flow**
-  - run at least one migration failure simulation and execute chosen recovery path.
-
-### Deliverables
-
-- rollback/mitigation decision tree
-- rehearsal evidence notes
-
-### Exit Criteria
-
-- operator can execute rollback/mitigation without undocumented steps
-- migration failure paths are diagnosable and classified
-
----
-
-## Phase E — Backfill Decision and Execution (Conditional)
-
-- [ ] **E1. Determine backfill necessity**
-  - inspect whether existing records violate new invariants.
-- [ ] **E2. If required, implement idempotent backfill**
-  - resumable, batch-safe, and deterministic update semantics.
-- [ ] **E3. Add post-backfill verification**
-  - validate:
-    - revision sequencing integrity
-    - accepted/current transcript consistency
-    - job lifecycle consistency
-- [ ] **E4. If not required, record explicit “no backfill needed” evidence**
-
-### Deliverables
-
-- backfill script(s) and checklist (if applicable)
-- no-backfill rationale artifact (if not applicable)
-
-### Exit Criteria
-
-- required backfills completed and verified OR formally ruled out with evidence
-
----
-
-## Phase F — Verification and Test Expansion
-
-Apply `pytesting` guidance (deterministic, behavior-first, strict markers).
-
-- [ ] **F1. Migration application tests**
-  - verify forward migration from representative baseline.
-- [ ] **F2. Post-migration schema contract tests**
-  - verify expected schema shape and key constraints.
-- [ ] **F3. Rollback/mitigation tests**
-  - verify chosen rollback class behavior where practical.
-- [ ] **F4. Startup policy regression tests**
-  - confirm production-mode startup does not mutate schema implicitly.
-- [ ] **F5. Backfill behavior tests (if applicable)**
-  - idempotency and invariants after repeated execution.
-
-### Validation Commands
-
-- `uv run pytest --collect-only -q`
-- `uv run pytest -m unit -q`
-- `uv run pytest -m "not external" -q`
-- `uv run pytest -q`
-
-### Exit Criteria
-
-- all Step 4 migration-safety checks pass
-- no REQ-10 regression introduced
-
----
-
-## Phase G — Runbook and Documentation Closure
-
-- [ ] **G1. Create migration and rollback runbook**
-  - include:
-    - prerequisites
-    - backup step
-    - migration execution
-    - verification
-    - rollback/mitigation
-- [ ] **G2. Update traceability artifacts**
-  - map Step 4 outcomes to REQ IDs and evidence.
-- [ ] **G3. Prepare Step 4 handoff artifacts**
-  - ensure outputs feed Step 9 release readiness and Step 10 docs completion.
-
-### Deliverables
-
-- `docs/ver1/ver1-step4-migration-runbook.md` (recommended)
-- `docs/ver1/ver1-step4-results.md`
-- updated traceability references where needed
-
-### Exit Criteria
-
-- migration operations are executable using docs alone
-- Step 4 evidence is complete and auditable
-
----
-
-## Recommended Implementation Order
-
-1. Phase A — schema/invariant audit
-2. Phase B — migration policy and tooling lock
-3. Phase C — forward migration implementation
-4. Phase D — rollback/mitigation strategy + rehearsal
-5. Phase E — backfill decision and execution (conditional)
-6. Phase F — test and verification expansion
-7. Phase G — runbook + traceability closure
-
-This sequence minimizes risk by locking policy and scope before irreversible data changes.
-
----
-
-## Risks and Mitigations
-
-1. **Risk:** Data loss from unsafe schema transitions
-   - **Mitigation:** backup-first gate, staged migration strategies, post-check verification.
-
-2. **Risk:** Startup policy drift reintroduces implicit schema mutation
-   - **Mitigation:** explicit regression tests for production startup behavior (REQ-10 guard).
-
-3. **Risk:** Rollback path is incomplete or untested
-   - **Mitigation:** mandatory rollback class declaration + rehearsal evidence.
-
-4. **Risk:** Backfill scripts cause partial/inconsistent state
-   - **Mitigation:** idempotent design, batching, and invariant-focused verification.
-
-5. **Risk:** Migration failure diagnostics are unclear
-   - **Mitigation:** structured logging + error category mapping per `error_handling.md`.
-
----
-
-## Step 4 Completion Checklist
-
-- [ ] V1 schema audit completed and approved.
-- [ ] Migration workflow policy is locked and documented.
-- [ ] Required forward migrations are implemented and validated.
-- [ ] Rollback/mitigation decision tree is documented and rehearsed.
-- [ ] Backfill required/not-required decision is evidenced.
-- [ ] Migration-safety test coverage is added and passing.
-- [ ] Startup non-mutation policy remains verified in production mode.
-- [ ] Step 4 runbook and results artifacts are completed.
-
----
-
-## Handoff to Step 5
-
-Step 4 completion enables Step 5 (Private-Network Safety Baseline) with:
-
-- stable, explicit schema evolution mechanics
-- reduced upgrade risk for single-operator deployments
-- migration/rollback procedures suitable for personal-scale production
-- traceable evidence for release-readiness gates

docs/ver1/ver1-step5-results.md

@@ -1,178 +0,0 @@
-# Ver1 Step 5 Results: Private-Network Safety Baseline
-
-## Summary
-
-Step 5 implementation status: **complete**.
-
-This document records completed private-network safety controls, validation evidence, and residual risks for Ver1 Step 5.
-
-Implemented in this step:
-
-1. Added private-network security assumptions and control matrix (`docs/ver1/ver1-step5-security-assumptions.md`).
-2. Implemented optional single-operator access control for `/ui*` and `/api*` via HTTP Basic auth.
-3. Added upload-size guardrails (`MAX_UPLOAD_BYTES`) and config fail-fast validation for operator credential requirements.
-4. Hardened unexpected-error user-facing messaging to reduce sensitive detail leakage.
-5. Added Step 5 tests for access control, security settings, and upload size boundaries.
-6. Executed dependency/security scans (`pip-audit`, `bandit`) with no critical/high findings.
-
----
-
-## Implemented Changes
-
-### 1) Security assumptions and threat model
-
-Completed.
-
-- Added `docs/ver1/ver1-step5-security-assumptions.md` defining:
-  - trusted private-network deployment assumptions
-  - single-operator usage model
-  - explicit out-of-scope classes (enterprise IAM, internet-facing zero-trust, multi-tenant controls)
-- Added Step 5 control/ownership matrix and residual-risk notes.
-
-### 2) Single-operator access control baseline
-
-Completed.
-
-- New module: `src/transcription/security.py`
-  - `is_protected_path(...)` protects `/ui*` and `/api*`
-  - `enforce_request_access(...)` enforces optional operator auth
-  - robust Basic auth parsing and safe denial responses via `AccessDeniedError`
-- App middleware added in `src/transcription/app.py`:
-  - enforces auth on protected paths
-  - returns consistent `401` envelope and `WWW-Authenticate: Basic` for denied requests
-- Health endpoint `/healthz` remains intentionally unauthenticated.
-
-### 3) Input validation and safe-output hardening
-
-Completed baseline.
-
-- `src/transcription/services/upload.py`
-  - added size-based validation guard (`max_upload_bytes`)
-  - emits `user_input_error` with actionable guidance on over-limit uploads
-- `src/transcription/errors.py`
-  - `classify_unexpected_error(...)` now returns operation-only message without embedding raw exception text
-  - preserves traceability via existing `error_id` and taxonomy while reducing accidental sensitive leak risk
-
-### 4) Secret handling and configuration safety
-
-Completed baseline.
-
-- `src/transcription/config.py` additions:
-  - `max_upload_bytes` (default `15 * 1024 * 1024`)
-  - `operator_access_enabled` (default `False`)
-  - `operator_username` (default `operator`)
-  - `operator_password` (optional, required when auth enabled)
-- Added settings validator enforcing fail-fast config safety:
-  - raises validation error if `OPERATOR_ACCESS_ENABLED=true` and `OPERATOR_PASSWORD` unset
-- `README.md` updated with Step 5 security env settings and explicit secret-handling guidance.
-
-### 5) Dependency/security scanning baseline
-
-Completed.
-
-- Dependency vulnerability scan:
-  - `uvx pip-audit`
-  - Result: **No known vulnerabilities found**
-- Static security scan:
-  - `uvx bandit -r src/transcription`
-  - Result: **No issues identified** (0 low/medium/high)
-
----
-
-## Test and Verification Evidence
-
-### Added/Updated Tests
-
-1. `tests/api/test_access_control.py`
-   - unauthorized protected API denied (`401` + challenge)
-   - invalid credentials denied
-   - valid credentials accepted
-   - `/ui` protected when auth enabled
-   - `/healthz` remains unprotected
-2. `tests/services/test_upload.py`
-   - added rejection test for payloads above `MAX_UPLOAD_BYTES`
-3. `tests/test_config.py`
-   - added security defaults assertions
-   - added fail-fast assertion for missing `OPERATOR_PASSWORD` when auth enabled
-4. `tests/test_errors.py`
-   - updated expectations for sanitized unexpected-error message behavior
-5. Updated integration expectations where failure detail should no longer include raw exception text:
-   - `tests/services/test_worker.py`
-   - `tests/integration/test_pipeline_flow.py`
-6. `tests/test_app.py` updated for new middleware wiring.
-
-### Validation Runs
-
-Run and record outcomes:
-
-- `uv run pytest --collect-only -q` -> passed
-- `uv run pytest -m unit -q` -> passed
-- `uv run pytest -m "not external" -q` -> passed
-- `uv run pytest -q` -> passed
-
-### Security Scan Evidence
-
-Record scan commands and outcomes:
-
-- dependency scan command(s): `uvx pip-audit`
-- static/security lint command(s): `uvx bandit -r src/transcription`
-- critical/high findings: none
-- remediation/defer decisions: no remediations required for Step 5 baseline
-
----
-
-## Requirement Traceability (Step 5)
-
-| Step 5 Area | REQ Coverage | Status | Evidence |
-| --- | --- | --- | --- |
-| Private-network and single-operator safety posture | REQ-9 | met | `docs/ver1/ver1-step5-security-assumptions.md`, README security section |
-| Access control behavior at UI/API boundaries | REQ-5, REQ-7 | met | `src/transcription/security.py`, `src/transcription/app.py`, `tests/api/test_access_control.py` |
-| Input validation and safe user-facing error behavior | REQ-1, REQ-2, REQ-5 | met | `src/transcription/services/upload.py`, `src/transcription/errors.py`, updated tests |
-| Config and startup safety controls | REQ-8, REQ-10 | met | `src/transcription/config.py`, `tests/test_config.py`, `README.md` |
-| Persistence and domain integrity continuity | REQ-11, REQ-12 | met (no regressions) | full test lane pass including integration and worker flows |
-
----
-
-## Operational Artifacts Produced
-
-- `docs/ver1/ver1-step5.md`
-- `docs/ver1/ver1-step5-results.md`
-- `docs/ver1/ver1-step5-security-assumptions.md`
-- `src/transcription/security.py`
-- `tests/api/test_access_control.py`
-
----
-
-## Risks, Exceptions, and Follow-Ups
-
-1. Basic auth is intentionally right-sized for trusted private-network use; if deployment posture changes, stronger identity controls are required.
-2. Current model remains single shared operator credential (no per-user audit identity).
-3. No built-in brute-force/rate-limit controls in Step 5 scope; evaluate in future hardening if threat model expands.
-
-Open follow-ups to carry forward:
-
-- Consider stronger auth/session model if system becomes multi-user or internet-accessible.
-- Consider request throttling/rate limiting if threat model changes.
-
----
-
-## Step 5 Exit Assessment
-
-- Private-network assumptions and controls: **met**
-- Access-control baseline effectiveness: **met**
-- Validation and safe-output safety: **met (baseline)**
-- Secret handling and config safety: **met**
-- Dependency/security risk closure: **met (no critical/high findings)**
-- Test and regression safety: **met**
-
-Step 5 completion status: **complete**
-
----
-
-## Handoff to Step 6
-
-Once Step 5 is marked complete, Step 6 can proceed with:
-
-- clearer operational security assumptions for logs/runbooks
-- hardened boundary behavior for diagnosis and support
-- reduced risk posture for personal-scale ongoing operations

docs/ver1/ver1-step5-security-assumptions.md

@@ -1,51 +0,0 @@
-# Ver1 Step 5 Security Assumptions (Private-Network Baseline)
-
-## Operating Model
-
-This system is operated as:
-
-1. single operator
-2. trusted private network
-3. non-public deployment (no direct internet exposure for UI/API)
-
-Out of scope for Step 5:
-
-- enterprise IAM/SSO/RBAC
-- internet-facing zero-trust edge controls
-- multi-tenant user isolation
-
-## Step 5 Controls and Ownership
-
-| Control | Boundary Owner | Verification |
-| --- | --- | --- |
-| Optional operator authentication for `/ui*` and `/api*` routes | `src/transcription/security.py`, `src/transcription/app.py` | `tests/api/test_access_control.py` |
-| Unauthorized contract (`401` + safe envelope + `WWW-Authenticate`) | `src/transcription/api/errors.py` | `tests/api/test_access_control.py` |
-| Upload size guard (`MAX_UPLOAD_BYTES`) | `src/transcription/services/upload.py`, `src/transcription/config.py` | `tests/services/test_upload.py` |
-| Fail-fast auth config when enabled | `src/transcription/config.py` | `tests/test_config.py` |
-| Safe unexpected error messaging (reduced leak surface) | `src/transcription/errors.py` | `tests/test_errors.py`, worker/integration failure tests |
-
-## Access-Control Policy (Step 5)
-
-- Health endpoint (`/healthz`) remains unauthenticated for operability checks.
-- When `OPERATOR_ACCESS_ENABLED=true`, protected paths require HTTP Basic auth:
-  - `/ui`
-  - `/ui/...`
-  - `/api/...`
-- Credentials are runtime-configured:
-  - `OPERATOR_USERNAME` (default `operator`)
-  - `OPERATOR_PASSWORD` (required when access is enabled)
-
-## Secrets Policy
-
-- Secrets must be provided via runtime environment variables.
-- Secrets must not be committed to source control.
-- Secrets must not be logged.
-- Example secret values in docs must always be placeholders.
-
-## Residual Risks (Accepted for Step 5)
-
-1. HTTP Basic credentials are suitable only for trusted private-network deployment.
-2. No per-user identity model (single shared operator credential).
-3. No advanced brute-force/rate-limit controls in Step 5 scope.
-
-These are carried forward for future hardening only if deployment posture changes.

docs/ver1/ver1-step5.md

@@ -1,459 +0,0 @@
-# Step 5 Implementation Plan: Private-Network Safety Baseline
-
-## Purpose
-
-Implement **Ver1 Step 5** from `docs/ver1/ver1.md` by applying right-sized security controls for a single-user system running on a trusted private network.
-
-Step 5 focuses on practical risk reduction without introducing unnecessary complexity, while preserving:
-
-- personal-scale operational simplicity
-- single-operator workflow
-- explicit boundary ownership from `docs/architecture.md`
-- safety and diagnostics behavior defined in `docs/error_handling.md`
-
-Primary governing docs:
-
-- `docs/ver1/ver1.md` (Step 5 objective and sequencing)
-- `docs/architecture.md` (deployment model and module boundaries)
-- `docs/error_handling.md` (safe user output and diagnostic boundaries)
-- `docs/requirements.md` (REQ-1, REQ-2, REQ-5, REQ-7, REQ-8, REQ-9, REQ-10, REQ-11, REQ-12)
-- `docs/intent.md` (domain integrity priorities)
-
----
-
-## MCP Resources Reviewed and Applied
-
-All currently available resources on `john-stream-mcp` were reviewed. Step 5 applies the following guidance directly:
-
-1. `resource://skills/pydantic-settings/document`
-   - typed security-related runtime settings
-   - explicit env/source precedence
-   - fail-fast handling for missing/invalid required values
-
-2. `resource://skills/fastapi-uv-docker/document`
-   - environment and deployment safety defaults
-   - startup/health posture and container hygiene assumptions
-   - local secret handling expectations
-
-3. `resource://skills/pytesting/document`
-   - deterministic security-behavior test lanes
-   - marker discipline and behavior-first assertions
-
-4. `resource://skills/python-logging-dictconfig/document`
-   - centralized logging discipline
-   - avoid leaking sensitive values in logs
-
-5. `resource://skills/nicegui-ui-customization/document`
-   - user-safe failure messaging in UI
-   - resilient interaction behavior and clear error feedback
-
-6. `resource://skills/ruff-linting-formating/document`
-   - keep lint quality baseline stable during safety changes
-
-Planning methodology input:
-
-7. `resource://prompts/greenfield-architecture/document`
-   - explicit tradeoff-oriented staging
-   - scope discipline for minimally sufficient security controls
-
-Reviewed but not directly Step 5 execution-critical:
-
-- skills: `copilot-customization`, `fastapi-async-sqlalchemy-modernization`, `mcp-details`, `nicegui`, `python-typing`, `vscode-configuration`, `zensical-docs`
-- prompts: `authoring`, `mcp-consumer-repo-shim`, `pytest-scaffold`, `pytest-fill-scaffold`
-
----
-
-## Current-State Gap Summary (Step 5 Scope)
-
-Based on current implementation and prior Step outputs:
-
-1. **Private-network assumptions are implicit, not fully codified**
-   - Need explicit, documented security posture and operator constraints.
-
-2. **Access control for UI/API is minimal or absent**
-   - Step 5 requires basic single-operator gating appropriate for private-network use.
-
-3. **Input validation baseline exists but needs security-oriented audit closure**
-   - Upload and API validation should be verified for abuse-resistant boundaries.
-
-4. **Safe error output baseline exists (Step 2), but needs security confirmation pass**
-   - Must ensure no sensitive internals leak through API/UI error payloads.
-
-5. **Secret handling documentation needs formalization in Step 5 artifacts**
-   - Local workflow should clearly prohibit secrets in repo-tracked files and logs.
-
-6. **Dependency/security scanning is not yet formalized as a recurring gate**
-   - Step 5 requires lightweight scanning and triage of high-risk findings.
-
----
-
-## Scope for Step 5
-
-### In scope
-
-1. Codify private-network and single-operator security assumptions in docs and config.
-2. Add basic access control for UI/API actions (right-sized for trusted network model).
-3. Audit and harden input-validation boundaries (upload, API params/payloads, operational flags).
-4. Verify safe error surface behavior (UI/API) and prevent sensitive leak paths.
-5. Formalize local secret handling policy and usage examples.
-6. Add lightweight dependency/security scan workflow and triage policy.
-7. Add Step 5 verification tests and results artifact.
-
-### Out of scope
-
-- Internet-facing zero-trust security architecture
-- Enterprise IAM/SSO/role systems
-- Full cryptographic key-management infrastructure
-- Major security product integrations beyond lightweight V1 needs
-
----
-
-## Target Decisions for Step 5
-
-1. **Threat model is explicitly private-network + single operator**
-   - Security controls are right-sized to this posture and documented as assumptions.
-
-2. **Access control is required, even in private network mode**
-   - Basic gate (single shared operator credential/token) protects UI/API mutation paths.
-
-3. **Validation and output safety are strict defaults**
-   - Reject invalid inputs early; never expose sensitive internals in user-facing outputs.
-
-4. **Secrets are runtime-only**
-   - No secrets committed to source control; no plaintext secret logging.
-
-5. **Security scanning is lightweight but mandatory**
-   - Add recurring dependency/security checks with high-risk triage and closure workflow.
-
-6. **No security control may violate Step 1–4 operational simplicity guardrails**
-   - Preserve deployability and maintainability for personal-scale use.
-
----
-
-## Detailed Work Breakdown
-
-## Phase A — Security Posture Definition and Gap Lock
-
-- [ ] **A1. Define Step 5 threat model**
-  - trusted private network
-  - single operator
-  - local deployment assumptions
-  - explicit out-of-scope threat classes
-
-- [ ] **A2. Produce security baseline checklist**
-  - access control
-  - validation boundaries
-  - safe error behavior
-  - secret handling
-  - dependency risk checks
-
-- [ ] **A3. Map controls to architecture boundaries**
-  - UI
-  - API
-  - service
-  - config/runtime
-  - operator runbooks
-
-### Deliverables
-
-- `docs/ver1/ver1-step5-security-assumptions.md` (recommended)
-- Step 5 control matrix (control -> owner -> validation method)
-
-### Exit Criteria
-
-- private-network safety posture is explicit and approved
-- each in-scope control has boundary ownership and verification path
-
----
-
-## Phase B — Basic Single-Operator Access Control
-
-- [ ] **B1. Select access mechanism**
-  - minimal approach suitable for private-network model
-  - explicitly document tradeoffs and operator ergonomics
-
-- [ ] **B2. Protect mutating operations first**
-  - upload/create/accept/export-trigger endpoints
-  - UI actions that trigger persistence changes
-
-- [ ] **B3. Protect read operations as policy requires**
-  - determine read-path gating expectations and apply consistently
-
-- [ ] **B4. Add clear unauthorized behavior contract**
-  - stable API status and safe message
-  - UI feedback with actionable operator guidance
-
-### Deliverables
-
-- access-control policy and implementation notes
-- unauthorized behavior matrix (UI/API)
-
-### Exit Criteria
-
-- unauthorized actions are blocked consistently
-- authorized operator flows remain usable and deterministic
-
----
-
-## Phase C — Input Validation and Safe Output Hardening
-
-- [ ] **C1. Validation audit for all entry points**
-  - file uploads (type/size/content guards)
-  - route/query/body constraints
-  - service-layer invariants
-
-- [ ] **C2. Normalize validation failures to canonical taxonomy**
-  - `validation_error` vs `user_input_error` consistency
-
-- [ ] **C3. Confirm safe error output policy under security lens**
-  - no stack traces/secrets/internal paths in UI/API default outputs
-  - preserve error reference IDs for traceability
-
-- [ ] **C4. Add abuse-resistant guardrails where practical**
-  - basic request-size and payload-shape constraints
-  - anti-duplication interaction safeguards (where missing)
-
-### Deliverables
-
-- validation-path inventory and hardening checklist
-- safe-output verification notes
-
-### Exit Criteria
-
-- input boundaries are deterministic and tested
-- user-facing error outputs remain safe and actionable
-
----
-
-## Phase D — Secrets Handling and Configuration Safety
-
-- [ ] **D1. Define secret handling policy**
-  - where secrets are allowed (runtime env only)
-  - where secrets are prohibited (source files, docs examples beyond placeholders)
-
-- [ ] **D2. Enforce settings expectations**
-  - required secret fields fail fast
-  - avoid fallback defaults that silently weaken safety
-
-- [ ] **D3. Add operator documentation for local secret workflow**
-  - how to set environment values safely
-  - how to rotate/update credentials locally
-
-- [ ] **D4. Validate logging does not leak secret values**
-  - startup/config logs
-  - error logs for provider/config failures
-
-### Deliverables
-
-- secret-handling section in runbook/README/docs
-- settings and logging safety verification notes
-
-### Exit Criteria
-
-- no secret leakage paths remain in normal operations
-- operator can configure secrets safely using docs only
-
----
-
-## Phase E — Dependency and Security Scanning Baseline
-
-- [ ] **E1. Select lightweight scanning commands for V1**
-  - dependency vulnerability scan
-  - optional static security scan if practical
-
-- [ ] **E2. Define triage policy for findings**
-  - severity classification
-  - required closure criteria for Step 5 completion
-
-- [ ] **E3. Run scans and capture evidence**
-  - record command outputs/summaries
-  - remediate or formally defer with risk notes
-
-- [ ] **E4. Add recurring execution guidance**
-  - local pre-release checklist integration
-  - future CI gate handoff for Step 7/9
-
-### Deliverables
-
-- Step 5 scan report artifact (recommended)
-- triage log of resolved/deferred findings
-
-### Exit Criteria
-
-- no unresolved critical vulnerabilities in Step 5 scope
-- high-risk findings are resolved or explicitly risk-accepted with rationale
-
----
-
-## Phase F — Verification and Test Expansion
-
-Apply `pytesting` guidance (deterministic, behavior-first, strict markers).
-
-- [ ] **F1. Access-control tests**
-  - unauthorized requests are rejected as expected
-  - authorized operator requests succeed
-
-- [ ] **F2. Validation and abuse-boundary tests**
-  - invalid payloads rejected with stable category/status
-  - file-type/size constraints enforced
-
-- [ ] **F3. Safe-output tests**
-  - API/UI error responses avoid sensitive details
-  - error IDs and suggestions remain present
-
-- [ ] **F4. Config/secret safety tests**
-  - required secrets fail fast when missing
-  - no unsafe fallback behavior introduced
-
-### Validation Commands
-
-- `uv run pytest --collect-only -q`
-- `uv run pytest -m unit -q`
-- `uv run pytest -m "not external" -q`
-- `uv run pytest -q`
-
-### Exit Criteria
-
-- Step 5 safety behavior is test-covered and passing
-- no regression in core upload/transcribe/review workflows
-
----
-
-## Phase G — Documentation and Risk Closure
-
-- [ ] **G1. Create Step 5 results artifact**
-  - `docs/ver1/ver1-step5-results.md`
-
-- [ ] **G2. Update operator-facing docs**
-  - security assumptions and local deployment cautions
-  - credential handling and recovery basics
-
-- [ ] **G3. Update traceability and carry-forward notes**
-  - map Step 5 controls to REQ and evidence
-
-### Deliverables
-
-- `docs/ver1/ver1-step5-results.md`
-- updated security assumptions checklist and risk summary
-
-### Exit Criteria
-
-- Step 5 controls and residual risks are fully documented
-- handoff is ready for Step 6 observability and Step 7 quality gates
-
----
-
-## Recommended Implementation Order
-
-1. Phase A — posture definition and gap lock
-2. Phase B — access control baseline
-3. Phase C — validation/output hardening
-4. Phase D — secrets and config safety
-5. Phase E — dependency/security scan baseline
-6. Phase F — test expansion and verification
-7. Phase G — docs and risk closure
-
-This order reduces risk by locking assumptions first, then applying controls at highest-impact boundaries before final verification and documentation.
-
----
-
-## Step 5 Execution Checklist (Phase-by-Phase)
-
-Use this checklist to execute Step 5 in implementation order and record progress/evidence.
-
-### Phase A — Security Posture Definition and Gap Lock
-
-- [ ] Publish `docs/ver1/ver1-step5-security-assumptions.md`.
-- [ ] Record explicit in-scope and out-of-scope threat classes.
-- [ ] Produce Step 5 control matrix (control, owner, validation method).
-- [ ] Confirm boundary ownership for each control (UI/API/service/config/docs).
-
-### Phase B — Basic Single-Operator Access Control
-
-- [ ] Choose and document access mechanism (with rationale and tradeoffs).
-- [ ] Implement enforcement for mutating API operations.
-- [ ] Implement corresponding UI-side access behavior for protected actions.
-- [ ] Decide and enforce read-path protection policy.
-- [ ] Add unauthorized API/UI contract tests.
-
-### Phase C — Input Validation and Safe Output Hardening
-
-- [ ] Complete input-validation inventory for upload/API/service boundaries.
-- [ ] Tighten payload/file constraints where gaps are found.
-- [ ] Ensure validation failure categories match `docs/error_handling.md`.
-- [ ] Verify user-facing errors remain safe, actionable, and traceable.
-- [ ] Add regression tests for invalid/boundary inputs.
-
-### Phase D — Secrets Handling and Configuration Safety
-
-- [ ] Document secrets policy (runtime-only, no repo storage).
-- [ ] Verify required secret settings fail fast when missing.
-- [ ] Audit logs for accidental secret leakage risk paths.
-- [ ] Update operator docs for local secret setup/rotation workflow.
-- [ ] Add tests for config safety expectations where practical.
-
-### Phase E — Dependency and Security Scanning Baseline
-
-- [ ] Select scanning commands and record tool versions.
-- [ ] Run baseline scans and capture outputs.
-- [ ] Triage findings by severity and exploitability in private-network context.
-- [ ] Resolve/mitigate critical findings; document accepted residual risk.
-- [ ] Add recurring scan guidance for release workflow handoff.
-
-### Phase F — Verification and Test Expansion
-
-- [ ] Run `uv run pytest --collect-only -q`.
-- [ ] Run `uv run pytest -m unit -q`.
-- [ ] Run `uv run pytest -m "not external" -q`.
-- [ ] Run `uv run pytest -q`.
-- [ ] Confirm no regressions in upload/transcribe/review core flows.
-
-### Phase G — Documentation and Risk Closure
-
-- [ ] Complete `docs/ver1/ver1-step5-results.md` with evidence.
-- [ ] Update docs/README/runbooks with final Step 5 security posture.
-- [ ] Record REQ traceability updates and residual risks.
-- [ ] Confirm Step 5 completion checklist items are all closed.
-
----
-
-## Risks and Mitigations
-
-1. **Risk:** Over-engineering beyond private-network needs
-   - **Mitigation:** enforce Step 5 scope discipline and threat-model constraints.
-
-2. **Risk:** Access controls disrupt operator usability
-   - **Mitigation:** keep mechanism minimal and test primary workflows thoroughly.
-
-3. **Risk:** Sensitive details leak through errors/logging
-   - **Mitigation:** apply safe-output and log-sanitization checks with tests.
-
-4. **Risk:** Unpatched dependency vulnerabilities remain invisible
-   - **Mitigation:** formalize scan + triage + evidence capture workflow.
-
-5. **Risk:** Secret handling remains ad hoc
-   - **Mitigation:** fail-fast settings + explicit operator documentation + review checks.
-
----
-
-## Step 5 Completion Checklist
-
-- [ ] Private-network and single-operator security assumptions are documented.
-- [ ] Basic single-operator access control is implemented and verified.
-- [ ] Input-validation boundaries are audited, hardened, and test-covered.
-- [ ] UI/API error output safety is confirmed under security tests.
-- [ ] Secret handling policy and local workflow docs are complete.
-- [ ] Dependency/security scans are run; critical findings are resolved.
-- [ ] Step 5 tests pass across all validation lanes.
-- [ ] `docs/ver1/ver1-step5-results.md` is completed with evidence and residual risks.
-
----
-
-## Handoff to Step 6
-
-Step 5 completion enables Step 6 (Minimal Observability & Operability) with:
-
-- explicit security assumptions for operator context
-- access and validation controls suitable for private-network operation
-- safer runtime/configuration handling for ongoing operations
-- dependency-risk visibility feeding release-readiness gates

docs/ver1/ver1-step6.md

@@ -1,206 +0,0 @@
-## Step 6 Goal (from `docs/ver1/ver1.md`)
-Implement **minimal observability & operability** so a single operator can quickly diagnose and recover from common failures.
-
----
-
-## 1) Current-State Assessment (what already exists)
-
-### Already in place
-- Central startup logging initialization via `setup_logging()` and `dictConfig` (`src/transcription/config.py`, `src/transcription/app.py`).
-- Error taxonomy and `error_id` envelope contract (`src/transcription/errors.py`) aligned with `docs/error_handling.md`.
-- Error handling for API and worker includes category + error IDs in some paths (`src/transcription/api/errors.py`, `src/transcription/worker.py`).
-- Basic health endpoint `/healthz` (`src/transcription/api/health.py`).
-- UI error display already shows actionable message + error reference (`src/transcription/ui/error_presenter.py`).
-
-### Gaps to close for Step 6
-1. **Structured logging is inconsistent** (many logs are free-form text with embedded key/value; no enforced schema).
-2. **Boundary coverage is incomplete** (UI/service/API/worker don’t all emit consistent operation logs).
-3. `/healthz` is very basic; no lightweight readiness/startup diagnostics endpoint/reporting.
-4. No concise **operator runbook** yet (start/stop, log interpretation, recovery playbooks).
-5. Minimal counters/timings are not yet standardized.
-
----
-
-## 2) MCP Guidance Incorporated (relevant items)
-
-From `john-stream-mcp`, these are directly applied:
-
-- **`python-logging-dictconfig`**: keep one centralized `dictConfig`, configure once at startup, named loggers in modules.
-- **`fastapi-async-sqlalchemy-modernization`**: include observability + health/readiness checks; explicit lifecycle and deterministic startup/shutdown checks.
-- **`fastapi-uv-docker`**: keep `/healthz`; add practical readiness/ops checks for deployment clarity.
-- **`pytesting`**: deterministic tests, concise structure, validation lanes (`collect-only`, `unit`, `not external`, full).
-- **`pydantic-settings`**: keep typed settings as single source for logging/health behavior flags.
-- **`nicegui` + `nicegui-ui-customization`**: preserve clear, actionable user-facing error feedback and non-blocking UI flows.
-- **`zensical-docs`**: produce focused, navigable operator docs.
-
-(Other MCP resources were reviewed but are not core to Step 6 implementation scope.)
-
----
-
-## 3) Detailed Implementation Plan for Step 6
-
-## Workstream A — Structured Logging Contract
-
-### A1. Define a canonical log event schema
-Create a project log schema (doc + code-level constants) with required keys:
-- `timestamp` (UTC)
-- `level`
-- `logger`
-- `operation`
-- `event`
-- `error_id` (when error)
-- `category` (when error)
-- `exception_type` (when error)
-- `job_id`, `document_id` (when relevant)
-- optional: `duration_ms`, `retry_count`, `status`
-
-### A2. Standardize log emission helpers
-Add small logging helpers (or adapter utilities) to reduce drift:
-- `log_operation_start(...)`
-- `log_operation_success(...)`
-- `log_operation_error(...)`
-
-Keep this minimal and avoid heavy observability frameworks.
-
-### A3. Update formatter to structured output
-Use `dictConfig` to emit either:
-- JSON lines (preferred for structure), or
-- strict key-value line format with fixed fields.
-
-**Recommendation:** JSON lines to satisfy “structured logging” unambiguously while still simple.
-
----
-
-## Workstream B — Boundary-by-Boundary Instrumentation
-
-### B1. API boundary (`src/transcription/api/*`)
-- Add request-level operation logs for key routes (`upload.submit`, `jobs.list`, `jobs.get`, etc.).
-- Ensure API exception handler logs always include `error_id`, `category`, `operation`, `exception_type`.
-
-### B2. Service boundary (`src/transcription/services/*`)
-- Add operation logs around:
-  - upload validation/persist,
-  - transcription orchestration,
-  - revision add/accept,
-  - search/export.
-- Add timing (`duration_ms`) for high-value operations only.
-
-### B3. Worker boundary (`src/transcription/worker.py`)
-- Standardize all worker log events to schema.
-- Ensure retry logs include: `retriable`, `retry_count`, `max_retries`, `backoff_seconds`.
-- Ensure terminal failure logs include error contract fields.
-
-### B4. UI boundary (`src/transcription/ui/*`)
-- Keep user-safe UI messages as-is.
-- Add backend/UI logger events for user-triggered failures (operation + error_id + category) so UI-visible errors correlate to server logs.
-
----
-
-## Workstream C — Health, Readiness, Startup Operability
-
-### C1. Keep `/healthz` lightweight
-- Return “process is running” status quickly.
-
-### C2. Add lightweight `/readyz`
-Include small checks:
-- DB connectivity ping.
-- Worker thread alive check.
-- Optional prompt directory existence check.
-
-Return structured status payload with per-check pass/fail.
-
-### C3. Startup self-check summary log
-At startup, emit one concise ops summary event:
-- environment
-- schema validation result
-- worker started
-- directories checked
-- bootstrap/migration mode flags
-
----
-
-## Workstream D — Minimal Counters & Timings
-
-Add only high-value diagnostics:
-1. `worker_jobs_processed_total`
-2. `worker_jobs_failed_total`
-3. `worker_retries_total`
-4. `transcription_duration_ms` (per job)
-5. `upload_persist_duration_ms` (per upload path)
-
-Implementation can be log-derived counters (no external metrics backend required).
-
----
-
-## Workstream E — Operator Runbook
-
-Create concise runbook doc (recommended: `docs/ver1/ver1-step6-operator-runbook.md`) with:
-
-1. **Start/Stop**
-   - local `uv` run mode
-   - docker compose mode (if applicable)
-
-2. **Where logs are**
-   - stdout, docker logs commands, filtering by `error_id` / `operation`.
-
-3. **Common failure patterns → recovery**
-   - provider timeout
-   - auth denied
-   - missing prompt dir
-   - DB unavailable
-   - job stuck/failed with retry exhausted
-
-4. **Recovery procedures**
-   - restart sequence
-   - verify health/readiness
-   - when to requeue/re-upload
-
-5. **Escalation artifacts**
-   - capture timestamp + error_id + operation + job_id/document_id
-
-Also update `README.md` with short links to the runbook.
-
----
-
-## Workstream F — Verification & Quality Gates
-
-### Tests to add/update
-- `tests/api/test_health.py`
-  - `/healthz` baseline
-  - `/readyz` pass/fail behavior
-- `tests/api/test_error_responses.py` / `tests/api/test_routes.py`
-  - logs include `error_id/category/operation` on failures
-- `tests/services/test_worker.py`
-  - retry/failure log fields + timing presence
-- `tests/ui/*`
-  - ensure UI error correlation path includes operation/ref id behavior
-
-### Validation commands (per MCP pytest guidance)
-- `uv run pytest --collect-only -q`
-- `uv run pytest -m unit -q`
-- `uv run pytest -m "not external" -q`
-- `uv run pytest -q`
-
----
-
-## 4) Traceability to Governing Docs
-
-- **`docs/ver1/ver1.md` Step 6:** all 5 implementation bullets covered.
-- **`docs/error_handling.md`:** logging contract fields and error taxonomy continuity enforced.
-- **`docs/architecture.md`:** respects modular boundaries, in-process worker model, low-complexity ops.
-- **`docs/requirements.md`:**
-  - REQ-8 (startup logging/config centralization) strengthened,
-  - REQ-5 (status visibility) improved operationally,
-  - REQ-7 lifecycle ownership observability improved.
-- **`docs/intent.md`:** keeps operation simple for personal-scale archival workflow.
-
----
-
-## 5) Suggested Execution Order (low risk)
-
-1. Logging schema + formatter + helpers  
-2. Worker/API instrumentation (highest value)  
-3. Service/UI instrumentation  
-4. `/readyz` + startup summary check  
-5. Runbook + README links  
-6. Tests + Step 6 results artifact (`docs/ver1/ver1-step6-results.md`)

docs/ver1/ver1.md

@@ -1,322 +0,0 @@
-# Version 1 Implementation Plan
-
-This plan defines the path from MVP to **Version 1 complete**.  
-The objective is to deliver the full scoped product with readiness for reliable personal-scale operation, while explicitly separating refinements/enhancements into a future document.
-
----
-
-## 0) Plan Governance & Scope Control (Foundation)
-
-**Goal:** Keep execution focused on V1 completion and avoid unnecessary process overhead.
-
-### Implementation Steps
-1. Create and maintain a **V1 Traceability Matrix**:
-   - Requirement ID
-   - Current status (`done`, `partial`, `not started`)
-   - Validation method
-2. Define V1 completion gates:
-   - Functional complete
-   - Operationally complete
-   - Personal-deployment ready
-3. Snapshot the MVP baseline (tag/changelog reference).
-4. Keep a standing rule: non-V1 ideas go to a separate enhancements backlog, and enter V1 only by explicit approval.
-
-### Deliverables
-- `docs/ver1/ver1.md` (this plan)
-- V1 traceability artifact:
-  - `docs/ver1/ver1-step1-2-carry-forward-checklist.md`
-  - `docs/ver1/ver1-step2-error-path-inventory.md` (supporting artifact)
-
-### Exit Criteria
-- Every in-scope requirement has explicit status and validation evidence.
-- Scope-change discipline is followed consistently.
-
----
-
-## 1) Architecture Consolidation
-
-**Goal:** Align implementation with intended architecture while preserving simplicity.
-
-### Implementation Steps
-1. Compare implemented modules/components with architecture documentation.
-2. Identify and classify architectural debt:
-   - Temporary coupling
-   - Missing interfaces
-   - Placeholder services/components
-3. Resolve architecture gaps that threaten reliability, maintainability, or clear boundaries.
-4. Record material decisions and tradeoffs in ADRs.
-
-### Deliverables
-- Updated architecture diagrams and boundaries
-- ADR entries for material decisions
-
-### Exit Criteria
-- Architecture documentation reflects system reality.
-- High-impact architecture risks are addressed or explicitly scheduled.
-
----
-
-## 2) Error Handling & Reliability Hardening
-
-**Goal:** Ensure predictable, diagnosable behavior under expected failure conditions.
-
-### Implementation Steps
-1. Apply the canonical taxonomy and response model from `docs/error_handling.md` across UI/API/service/worker boundaries.
-2. Ensure clear distinction between:
-   - User-facing safe messages
-   - Internal diagnostic detail
-   - Retryable vs non-retryable failures
-3. Implement practical resilience controls where needed:
-   - Timeouts
-   - Bounded retries with backoff
-   - Explicit terminal failure states
-4. Add failure-path tests for critical workflows.
-
-### Deliverables
-- Error handling reference aligned with `docs/error_handling.md`
-- Failure-mode test coverage for critical paths
-
-### Exit Criteria
-- Error behavior is consistent across major flows.
-- Known failure scenarios are tested and pass.
-- Failed jobs include actionable, traceable failure detail.
-
----
-
-## 3) Functional Completion by Requirement Domain
-
-**Goal:** Complete all V1 requirements in a practical, user-first order.
-
-### Recommended Order
-1. End-user core flows (upload → transcribe → review)
-2. Data integrity and persistence behavior
-3. Minimal operator controls needed for personal use
-4. In-scope UX quality improvements
-
-### Implementation Steps
-For each requirement slice:
-1. Confirm contract/schema
-2. Implement service/domain logic
-3. Implement persistence/state transitions
-4. Integrate API/UI behavior
-5. Add or update automated tests
-6. Update relevant docs
-
-### Deliverables
-- Requirement completion report with validation evidence linked to REQ IDs
-
-### Exit Criteria
-- All V1 must-have requirements are complete and verified.
-
----
-
-## 4) Data Model and Migration Safety
-
-**Goal:** Keep schema evolution safe and simple for personal-scale deployment.
-
-### Implementation Steps
-1. Validate schema against finalized V1 domain needs.
-2. Implement forward-safe migrations for expected upgrades.
-3. Define a simple rollback/mitigation path for migration failures.
-4. Add backfill scripts only where truly required.
-5. Rehearse migration + rollback locally using representative sample data.
-
-### Deliverables
-- Migration and rollback runbook
-- Backfill checklist (if applicable)
-
-### Exit Criteria
-- Migration path is tested and documented.
-- No unresolved data-loss risk for V1 upgrade.
-
----
-
-## 5) Private-Network Safety Baseline
-
-**Goal:** Apply right-sized security controls for a single-user system on a trusted private network.
-
-### Implementation Steps
-1. Enforce private-network deployment assumptions in docs and configuration.
-2. Ensure basic single-operator access control for UI/API actions.
-3. Enforce input validation and safe error output behavior.
-4. Keep secrets out of source control; document local secret handling.
-5. Run lightweight dependency/security scanning and resolve high-risk findings.
-
-### Deliverables
-- Security assumptions checklist (private network, single operator)
-- Basic risk update for V1 scope
-
-### Exit Criteria
-- No unresolved critical vulnerabilities.
-- Access behavior and validation rules are verified for intended operating model.
-
----
-
-## 6) Minimal Observability & Operability
-
-**Goal:** Keep operation and troubleshooting simple, clear, and reliable.
-
-### Implementation Steps
-1. Standardize structured logging across UI/API/service/worker boundaries.
-2. Ensure logged errors include category and error reference IDs per `error_handling.md`.
-3. Add lightweight health/startup checks.
-4. Document a concise operator runbook:
-   - start/stop
-   - log locations
-   - common failure patterns and recovery steps
-5. Add minimal counters/timings only where they clearly improve diagnosis.
-
-### Deliverables
-- Logging and error-traceability baseline
-- Operator runbook
-
-### Exit Criteria
-- Operator can diagnose common failures using logs + runbook.
-- System recovery procedures are documented and repeatable.
-
----
-
-## 7) Test Coverage and Practical Quality Gates
-
-**Goal:** Prevent regressions in critical flows without overbuilding test infrastructure.
-
-### Implementation Steps
-1. Expand unit and integration tests for all V1 requirement slices.
-2. Add end-to-end tests for critical journeys:
-   - upload
-   - process/transcribe
-   - view result
-   - failure visibility
-3. Add targeted contract tests where adapter boundaries are error-prone.
-4. Keep CI gates focused on high-value checks (tests, lint, type checks, dependency scan).
-
-### Deliverables
-- V1 test matrix mapped to requirements and critical flows
-- CI quality-gate checklist
-
-### Exit Criteria
-- Critical-path regressions are automatically detected.
-- Test suite gives consistent release confidence for personal-scale operation.
-
----
-
-## 8) Performance Validation for Personal Scale
-
-**Goal:** Confirm acceptable responsiveness for expected personal-use workload.
-
-### Implementation Steps
-1. Define practical performance expectations for key flows.
-2. Run representative tests using real document samples.
-3. Address obvious bottlenecks in queries, file handling, or worker concurrency.
-4. Document known limits and expected operating bounds.
-
-### Deliverables
-- Short performance validation note
-- Known-limits summary
-
-### Exit Criteria
-- Core flows remain responsive for expected corpus size and usage patterns.
-
----
-
-## 9) Release Readiness and Environment Simplicity
-
-**Goal:** Make deployment and rollback repeatable for a single-operator Docker Compose setup.
-
-### Implementation Steps
-1. Define a simple release checklist:
-   - run tests
-   - run one end-to-end transcription check
-   - verify migration compatibility
-2. Document environment configuration requirements clearly.
-3. Validate deployment and rollback steps in a local rehearsal.
-4. Add backup/restore verification for core persisted data.
-
-### Deliverables
-- Release checklist
-- Environment and rollback guide
-
-### Exit Criteria
-- Deployment/rollback is rehearsed and documented.
-- Operator can release safely without hidden steps.
-
----
-
-## 10) Documentation Completion
-
-**Goal:** Ensure V1 can be built, operated, and supported from documentation.
-
-### Implementation Steps
-1. Update core project docs to match final V1 behavior:
-   - Architecture
-   - Error handling
-   - Requirements status
-   - Index/navigation
-   - Intent alignment summary
-2. Add operator troubleshooting guides.
-3. Add integration/API examples for the operator and future maintainers.
-4. Publish changelog/version notes for V1.
-
-### Deliverables
-- Updated documentation set for V1
-- V1 release notes
-
-### Exit Criteria
-- A future maintainer can run and support the system using docs alone.
-
----
-
-## 11) Final Validation and Launch
-
-**Goal:** Confirm V1 readiness and launch with low operational risk.
-
-### Implementation Steps
-1. Run end-to-end acceptance validation against the V1 traceability matrix.
-2. Complete operator acceptance checks on representative real documents.
-3. Execute launch checklist (including backup, migration, and rollback readiness).
-4. Launch and monitor logs/status closely during initial use.
-
-### Deliverables
-- Acceptance validation record
-- Launch checklist completion record
-
-### Exit Criteria
-- V1 requirements are validated.
-- Initial launch behavior is stable and recoverable.
-
----
-
-## 12) Post-Launch Stabilization
-
-**Goal:** Address early issues quickly and lock in a reliable V1 baseline.
-
-### Implementation Steps
-1. Track defects and operational pain points observed after launch.
-2. Prioritize short-cycle stabilization fixes.
-3. Remove temporary launch-only workarounds when safe.
-4. Capture a brief retrospective and update the next-phase backlog.
-
-### Deliverables
-- Stabilization summary
-- Updated backlog for post-V1 enhancements
-
-### Exit Criteria
-- Major launch issues are resolved.
-- System transitions to steady personal-use operation.
-
----
-
-## Recommended Execution Rhythm
-
-- **Weekly:** Requirement closure + risk review
-- **As needed (small batch releases):** Run release checklist and deploy
-- **Milestone check-ins:** After phases 2, 6, 9, and 11
-
----
-
-## Scope Discipline Rule (V1 Focus)
-
-To preserve delivery focus:
-- V1 execution prioritizes completion of scoped requirements.
-- Refinements/enhancements are captured in a separate future document and backlog.
-- Only explicitly approved scope changes may enter this plan.

docs/ver4.1/implementation_plan_v4_1.md

@@ -0,0 +1,146 @@
+# Implementation Plan (Version 4.1)
+
+## Goal
+
+Deliver the V4.1 usability revision as a small, behavior-safe increment over the V4 baseline.
+
+## Implementation Principles
+
+- Keep presentation formatting in UI components and route orchestration in pages.
+- Keep persistence and cross-record queries behind service boundaries.
+- Reuse shared table and date-label helpers instead of duplicating fallback logic.
+- Make the FamilySearch schema change additive and nullable.
+- Add focused tests for changed behavior before broad regression verification.
+
+## Current Project Impact
+
+| Area | Expected impact |
+| --- | --- |
+| Persistence | Add nullable `Person.family_search_id`; provide the repository's supported schema-upgrade path for existing databases. |
+| People service | Normalize and validate FamilySearch IDs at the domain/service boundary if model validation does not fully cover writes. |
+| Documents UI | Add table data, improve relationship labels/links, compact date display, and combine processing navigation. |
+| People UI | Add table date fields, Person-first Document creation, compact date display, and FamilySearch controls. |
+| Sources service/UI | Query adjacent document Sources and add bounded navigation; revise list columns and wrapping. |
+| Jobs UI | Refresh the active detail read model on a timer until terminal status. |
+| Shared UI | Add reusable constrained/wrapped table presentation and compact date formatting where appropriate. |
+| Tests | Update model/service and UI coverage for all affected workflows. |
+
+## Implementation Phases
+
+### 1. Add Shared Presentation Rules
+
+- Review `ui/components/table/common.py` and packaged theme CSS for the narrowest reusable table-width solution.
+- Add reusable styles or column slots for constrained, wrapping, left-aligned text.
+- Add a shared formatter for exact/approximate/unknown dates if it can be reused without coupling components to persistence.
+- Preserve sorting and search behavior for rendered display values.
+
+### 2. Update Archival List Tables
+
+- Extend the Document table read model with author names and the compact document date.
+- Build author display from eagerly loaded document-person links using the `author` role.
+- Apply title/type alignment and constrained title wrapping.
+- Extend the Person table read model with compact birth and death date values.
+- Apply Display Name and Maiden Name alignment.
+- Remove Stored Filename from the Source table read model only if no other list behavior consumes it; always remove its rendered column.
+- Constrain and left-align the requested Source columns.
+- Add or update UI component tests for serialized rows, columns, and fallback formatting.
+
+### 3. Improve Document Relationship Workflows
+
+- Introduce one person-label formatter that combines preferred Display Name, Full Name context, and known birth year without implying uniqueness.
+- Use Person UUIDs as selector values.
+- Apply the formatter to every relationship role selector.
+- Change Related People rows into actions that navigate to `/people/{person_id}`.
+- Replace separate exact/approximate rows in view mode with one conditional Document Date row.
+- Combine Pipeline Jobs and Sources into one related-processing card beneath Related People.
+- Preserve existing job/source counts and navigation actions.
+
+### 4. Add the Person-First Document Workflow
+
+- Add a New Document action on Person Detail.
+- Pass the Person UUID through a narrowly defined query parameter to `/documents/new`.
+- Validate the requested UUID against the loaded people list.
+- Preselect that person in the intended default relationship role. Use `author` unless a different role is explicitly encoded later.
+- Ignore invalid or unavailable preselection values with the application's normal visible error/notification behavior.
+- Confirm ordinary `/documents/new` behavior remains unchanged.
+
+### 5. Add FamilySearch Person References
+
+- Add nullable, unique `family_search_id` to the `Person` model and schema.
+- Implement a non-destructive upgrade for existing SQLite and PostgreSQL databases using the repository's established schema-management approach.
+- Normalize values by trimming and uppercasing.
+- Validate the `XXXX-XXX` alphanumeric identifier shape and return a clear validation error for malformed input.
+- Report duplicate identifiers as a deterministic conflict rather than a generic persistence failure.
+- Add the field to Person create/edit forms and preserve it during updates.
+- Add a URL builder that safely inserts only a validated identifier into the fixed FamilySearch details URL.
+- Render a FamilySearch action on Person Detail only when an identifier is present.
+- Add persistence, normalization, validation, form, and link-generation tests.
+
+### 6. Add Source Page Navigation
+
+- Add a Sources service query that returns previous/current/next context for a Source within its Document.
+- Define ordering by `page_number`, with a stable secondary key such as Source UUID for defensive determinism.
+- Keep navigation bounded to the current `document_id`.
+- Render previous and next actions adjacent to the source viewer or detail header.
+- Disable or omit unavailable boundary actions.
+- Test first, middle, last, single-page, and cross-document cases.
+
+### 7. Add Job Detail Auto-Refresh
+
+- Make Job Detail content refreshable without rebuilding unrelated global navigation.
+- Start a NiceGUI timer only for queued or processing jobs.
+- On each tick, re-read the Job through `JobService` and refresh the detail content.
+- Use a 4-second default interval.
+- Stop or deactivate the timer when status becomes completed, partial success, failed, or cancelled, according to the model's actual terminal states.
+- Prevent overlapping refresh callbacks.
+- Retain existing error presentation if a refresh read fails.
+- Add UI tests for timer creation, refresh, and terminal-state stopping.
+
+### 8. Simplify View-Mode Date Rows
+
+- On Document Detail, show exact date, else approximate date, else one not-set value.
+- On Person Detail, apply the same independent rule to birth and death.
+- Do not hide either input in create/edit mode.
+- Test each exact, approximate, and absent state.
+
+### 9. Verification and Documentation Alignment
+
+- Run the focused model/service/UI tests covering changed surfaces.
+- Run the existing regression suite appropriate to persistence and UI changes.
+- Confirm SQLite and PostgreSQL model compatibility at the schema-definition level.
+- Update V4.1 documentation if implementation reveals a necessary boundary change; do not silently expand scope.
+
+## Recommended Delivery Order
+
+1. Shared formatters and table presentation.
+2. Additive Person schema change and FamilySearch validation.
+3. Document and Person list/detail changes.
+4. Person-first Document workflow.
+5. Source navigation.
+6. Job polling.
+7. Focused and regression verification.
+
+## Done When
+
+- Every V4.1 acceptance criterion is demonstrated or covered by a focused test.
+- Existing Person rows remain valid after the nullable schema addition.
+- Duplicate FamilySearch references cannot be assigned to multiple local Person records.
+- FamilySearch links are generated only from normalized, validated IDs.
+- Auto-refresh performs no polling after a terminal job state.
+- Adjacent Source navigation never crosses Document boundaries.
+- The existing V4 workflows remain operational.
+
+## Out of Scope
+
+- Page reordering.
+- Settings management.
+- External genealogy API integration.
+- Raw `.env` editing.
+- Theme editing.
+
+## Related Local References
+
+- [V4.1 Scope Boundary](scope_boundary_v4_1.md)
+- [V4 Implementation Plan](../ver4/implementation_plan_v4.md)
+- [V4 Requirements](../ver4/requirements_v4.md)
+- [V4 Error Handling Policy](../ver4/error_handling_v4.md)

docs/ver4.1/scope_boundary_v4_1.md

@@ -0,0 +1,142 @@
+# V4.1 Scope Boundary
+
+This document defines the scope of the first incremental revision to Version 4. V4 remains the product and architecture baseline; V4.1 adds focused usability improvements and one additive Person field.
+
+## Purpose
+
+- Improve common archival record workflows without redesigning the application.
+- Resolve table overflow, ambiguous person selection, and unnecessary navigation.
+- Add a manually maintained FamilySearch person reference without introducing external API integration.
+
+## In Scope
+
+### 1. Archival Documents List
+
+- Keep every table column within the available page width.
+- Limit and wrap long Document Title values.
+- Left-align Document Title and Type.
+- Add Author and Document Date columns.
+- Display all people linked through the `author` role in the Author column.
+- Display exact document date when present, otherwise approximate date when present, otherwise `Unknown`.
+
+### 2. Document Detail and Editing
+
+- Use an unambiguous label in person selectors. The label should prefer Display Name, retain Full Name for context, and include the birth year when known.
+- Do not require Display Name to be unique.
+- Link each Related People entry to its Person Detail page.
+- In view mode, display only the populated exact or approximate document date row. Display a single unknown/not-set state when neither exists.
+- Keep both exact and approximate inputs available in create/edit mode.
+- Move source navigation out from beneath the media viewer.
+- Present Pipeline Jobs and Sources together in one related-processing card with counts and actions.
+
+### 3. People List
+
+- Left-align Display Name and Maiden Name.
+- Display exact birth date when present, otherwise approximate birth date when present, otherwise `Unknown`.
+- Add a Death Date column with the same fallback rule.
+
+### 4. Person Detail and Editing
+
+- Add a New Document action that opens Document creation with the current person preselected.
+- Preserve the existing Document-first workflow.
+- In view mode, display only the populated exact or approximate row for each of birth and death date. Display a single unknown/not-set state when neither value exists.
+- Keep both exact and approximate inputs available in create/edit mode.
+
+### 5. FamilySearch Reference
+
+- Add a nullable, unique `family_search_id` field to `Person`.
+- Allow the field to be entered and changed in Person create/edit flows.
+- Trim whitespace, normalize the identifier to uppercase, and validate it against the supported
+  `XXXX-XXX` alphanumeric shape before persistence.
+- When an identifier exists, show a FamilySearch action on Person Detail linking to:
+  `https://www.familysearch.org/tree/person/details/{family_search_id}`
+- Construct the URL in application code; do not persist the full URL.
+
+### 6. Source List and Detail
+
+- Keep every Source Asset Records table column within the available page width.
+- Limit and wrap long Document Name, Upload Title, and Error Detail values.
+- Left-align Document Name, Upload Title, and Error Detail.
+- Remove Stored Filename only from the Source Asset Records table. Continue storing it and showing it on Source Detail.
+- On Source Detail, add previous and next navigation for Sources belonging to the same Document, ordered by `page_number`.
+- Disable or omit the previous/next action at the first/last page.
+
+### 7. Job Detail
+
+- Automatically refresh Job Detail while the job is in a non-terminal state.
+- Use a modest interval in the 3-5 second range.
+- Stop polling when the job reaches a terminal state or the page is no longer active.
+- Preserve manual navigation and existing job actions.
+
+### 8. Homepage Storage Decision
+
+- Continue treating homepage markdown and images as mutable application data, not prompt artifacts or packaged source assets.
+- Keep homepage content separate from `prompts`.
+- Defer relocation to a configurable application-data root unless the existing location prevents normal installed or deployed operation.
+
+## Out of Scope
+
+- Source page renumbering or reordering.
+- A Settings page.
+- Editing `.env` or secrets through the UI.
+- Runtime theme editing.
+- FamilySearch authentication, API calls, search, import, synchronization, or conflict resolution.
+- Ancestry references or other genealogy providers.
+- Google Maps links from place fields.
+- Enforcing unique Display Name values.
+- Changes to transcription execution or provider behavior.
+- Changes to the V4 API solely to expose the V4.1 presentation enhancements.
+
+## Locked Design Decisions
+
+### A. Person Selector Identity
+
+- Selection values remain internal Person UUIDs.
+- Display labels provide disambiguating context but are not identity keys.
+- Duplicate Full Name and Display Name values remain valid.
+
+### B. Date Presentation
+
+- Exact dates take precedence over approximate/raw dates for compact list and view presentation.
+- Create/edit forms retain both fields so either representation can be maintained.
+- V4.1 does not introduce a new mutual-exclusion database constraint.
+
+### C. FamilySearch Storage
+
+- Store only the FamilySearch person identifier.
+- Treat a FamilySearch person identifier as unique across local Person records.
+- Use one dedicated nullable Person field while FamilySearch is the only supported external genealogy reference.
+- Reconsider a generic external-reference model only when a second provider or multiple references per person are required.
+
+### D. Stored Filename
+
+- Stored Filename remains part of the Source model and Source Detail diagnostics.
+- Only the list-table column is removed.
+
+## Data and Compatibility Policy
+
+- The `family_search_id` addition must be nullable and non-destructive for existing Person rows.
+- Existing records, routes, relationships, jobs, Sources, prompt provenance, and uploaded media remain valid.
+- UI changes must preserve both Document-first and Person-first workflows.
+- V4.1 must remain portable across SQLite and PostgreSQL.
+
+## Acceptance Criteria
+
+1. Document, Person, and Source tables fit their page containers at supported desktop widths without losing requested columns.
+2. Long table text wraps or is constrained without forcing important columns outside the table container.
+3. Duplicate-named people can be distinguished in every document relationship selector.
+4. Related People entries navigate to the correct Person Detail page.
+5. Compact date displays consistently use exact, then approximate, then unknown fallback behavior.
+6. Starting from Person Detail can create a Document with that person preselected without breaking normal Document creation.
+7. A valid FamilySearch ID is persisted and produces the correct Person Detail hyperlink; absent IDs produce no action.
+8. Source previous/next actions remain within the same Document and follow `page_number`.
+9. Active Job Detail pages update without manual refresh and stop polling after terminal status.
+10. Stored Filename is absent from the Source list table but remains available on Source Detail.
+11. Focused automated tests pass and unaffected V4 behavior remains intact.
+
+## Related Local References
+
+- [V4.1 Implementation Plan](implementation_plan_v4_1.md)
+- [V4 Scope Boundary](../ver4/scope_boundary_v4.md)
+- [V4 Architecture](../ver4/architecture_v4.md)
+- [V4 Schema](../ver4/schema_v4.md)

docs/ver4.2/implementation_plan_v4_2.md

@@ -0,0 +1,258 @@
+# Implementation Plan (Version 4.2)
+
+## Goal
+
+Make processing evidence precise, append-only, secret-safe, and exportable while preserving every existing record and creating a provider-neutral home for future OCR/layout artifacts.
+
+## Implementation Principles
+
+- Implement the [Digital Evidence and AI Processing Provenance invariant](../invariant/ai_evidence_and_provenance.md), not a provider-specific approximation of it.
+- Capture transport evidence before SDK parsing.
+- Keep exact evidence separate from parsed and normalized representations.
+- Prefer additive schema evolution and explicit compatibility behavior.
+- Reference source content by digest rather than duplicating it in request JSON.
+- Use allowlists for safe metadata capture.
+- Keep persistence and evidence semantics behind service boundaries.
+- Do not change the default model until a representative benchmark supports that decision.
+
+## Current-State Gaps
+
+| Current behavior | Gap to close |
+| --- | --- |
+| `Source` stores original file path, digest, and size. | Media type and image/page geometry used for an execution are not frozen with that execution. |
+| `Job` stores prompt text/hash, requested model after resolution, temperature, and `top_p`. | The complete effective request structure, omitted-versus-explicit parameter state, routing constraints, and software versions are not frozen. |
+| `JobSource.raw_api_response` stores `model_dump()` output from the OpenRouter SDK. | The exact HTTP body can be normalized by OpenRouter and filtered again by the SDK before persistence. |
+| `JobSource.ai_metadata` stores finish reason and basic token counts. | Detailed accounting remains only in the SDK snapshot and is not a substitute for exact evidence. |
+| Provider exceptions become application errors. | Safe HTTP error bodies, statuses, headers, and no-response distinctions are not persisted. |
+| Worker logs elapsed time. | Execution duration is not stored on `JobSource`. |
+| Source Detail displays AI metadata and the SDK snapshot. | The UI does not identify evidence layers or expose request/transport/software provenance. |
+| No generic processing-artifact model exists. | Future OCR geometry would require ad hoc provider fields or an unrelated schema. |
+
+## Expected Project Impact
+
+| Area | Expected impact |
+| --- | --- |
+| Database models and upgrades | Add execution-specification, transport-evidence, timing, software-context, and generic artifact storage without removing existing columns. |
+| OpenRouter adapter | Introduce a transport boundary that can capture exact body/status/safe headers before typed SDK parsing, or use supported SDK hooks that expose the unparsed response reliably. |
+| Provider contract | Return structured evidence for success and failure without leaking provider-specific transport concerns into workflow orchestration. |
+| Source and workflow services | Persist one append-only execution outcome and its artifacts transactionally; retain compatibility projections. |
+| UI | Label and inspect evidence layers; export safe evidence packages through service operations. |
+| Benchmarking | Add a private manifest and repeatable evaluator using the literal-transcription methodology. |
+| Tests and documentation | Add compatibility, capture, security, integrity, export, and benchmark-scoring coverage; correct overstated V4 evidence language. |
+
+## Proposed Data Design
+
+Exact names should be confirmed against existing conventions before migration code is written. The design should provide the following logical records.
+
+### 1. Execution Evidence
+
+Extend `JobSource` or associate it one-to-one with a new execution-evidence record containing:
+
+- Request manifest JSON and manifest schema version.
+- Transport status, body bytes or exact decoded body plus encoding/content type, and safe headers.
+- Parsed SDK snapshot retained separately from transport content.
+- Application, adapter, SDK, and runtime version metadata.
+- Start, finish, and duration values.
+- Router/provider request and generation identifiers when available.
+- Failure phase and whether an HTTP response was received.
+
+The implementation should evaluate a companion table rather than continuing to widen `JobSource`. A companion record better isolates large/optional evidence and permits clear one-to-one compatibility semantics.
+
+### 2. Generic Processing Artifact
+
+Add a one-to-many artifact model associated with a source and, when applicable, a producing execution:
+
+- Stable artifact UUID.
+- `source_id` and optional execution/`job_source_id`.
+- Semantic artifact type.
+- Media/serialization format.
+- Schema name and version.
+- Producer and producer version.
+- Inline JSON payload or external location.
+- Payload digest and byte size.
+- Coordinate-system metadata when relevant.
+- Creation timestamp.
+
+Enforce exactly one content location: inline payload or external reference. An external artifact must be written durably and hashed before its database record commits.
+
+### 3. Compatibility Projections
+
+- Keep `JobSource.raw_api_response` unchanged for existing and new compatibility reads until a later deprecation decision.
+- Keep `JobSource.ai_metadata` for indexed/display-ready normalized values.
+- Keep `Source.raw_transcription` as the latest successful machine-output projection while treating per-execution `JobSource.raw_transcription` as history.
+- Document that older rows have an SDK snapshot but no exact transport capture.
+
+## Implementation Phases
+
+### 1. Correct Terminology and Define Typed Contracts
+
+- Add typed domain models for request manifests, software context, transport metadata, failure phase, and artifact descriptors.
+- Version every persisted JSON contract from its first release.
+- Define the safe response-header allowlist. Begin with correlation, content type/encoding, date, retry/rate-limit, and router-specific generation identifiers only when documented and non-secret.
+- Define size limits and external-storage thresholds for exact bodies and artifacts.
+- Correct `docs/ver4/schema_v4.md` under “Page-Level Execution and AI Outputs” so the existing column is described as an SDK-serialized OpenRouter response snapshot, not a complete provider envelope, exact HTTP body, or native upstream-provider response. Apply the same terminology to architecture and UI schema references.
+- Add serialization and secret-rejection unit tests before provider changes.
+
+### 2. Add Additive Persistence and Upgrade Behavior
+
+- Add the selected execution-evidence and artifact models.
+- Add foreign keys, uniqueness constraints, and indexes for source/execution lookup.
+- Implement idempotent upgrades following the repository's existing schema-upgrade policy.
+- Do not populate exact response fields for historical rows.
+- Do not write a capture-time classification onto historical rows during migration. Compatibility reads may describe a populated legacy `raw_api_response` as an SDK snapshot, but exports must identify that description as a later compatibility interpretation rather than execution-time metadata.
+- Verify JSON portability and large-payload behavior for SQLite and PostgreSQL.
+- Add upgrade tests starting from a representative pre-V4.2 schema.
+
+### 3. Build Secret-Safe Request Manifests
+
+- Build the manifest from the concrete outgoing request body immediately before transport, not from a narrower typed projection that may discard unrecognized request fields.
+- Replace each image payload in that concrete representation with a source reference containing source UUID, digest, byte size, media type, dimensions, and transformation identity.
+- Store exact prompt content and preserve omitted-versus-explicit parameter state.
+- Include requested model, routing preferences, response-format requirements, and timeout/retry policy.
+- Record application version/commit when available, adapter contract version, SDK package/version, and request-manifest schema version.
+- Hash the canonical manifest representation for integrity checks.
+- Test that credentials and embedded image data cannot enter the persisted manifest.
+- Test that every field actually sent to the provider, including routing and future provider options, is represented or explicitly excluded by the manifest transform.
+
+### 4. Capture OpenRouter Transport Evidence
+
+- Evaluate the installed OpenRouter SDK hooks/client injection first.
+- If hooks cannot expose an exact stable response before typed parsing, implement the non-streaming OpenRouter call through the existing async HTTP client boundary while retaining typed validation in the adapter.
+- Read the response body once, preserve it exactly, then parse and normalize it.
+- Store status, content type/encoding, allowlisted headers, request/generation ID, and timing.
+- Maintain current authentication, referer/title headers, timeout behavior, and error classification.
+- Explicitly document that the captured body is the OpenRouter-normalized transport response, not Gemini/Anthropic/OpenAI native upstream JSON.
+- Add fixture-based tests proving unknown response fields survive transport capture even if a typed parser ignores them.
+
+### 5. Preserve Failure Evidence
+
+- Return or raise a typed provider failure that carries safe evidence separately from its user-facing error.
+- Persist non-success status/body/allowlisted headers before marking an execution failed.
+- Represent DNS/connect/TLS/local timeout failures as no-response outcomes with a failure phase and safe diagnostic category.
+- Preserve response-validation failures with both the exact body and validation details.
+- Keep transcription-quality rejection distinct from provider failure because a valid provider response was received.
+- Ensure error strings and logs do not contain authorization data or embedded image payloads.
+- Add tests for 4xx, 5xx, malformed JSON, schema mismatch, timeout, connection failure, and quality rejection.
+
+### 6. Make Execution History Reliably Append-Only
+
+- Confirm retry behavior creates a distinct execution attempt rather than reusing and overwriting a completed evidence record.
+- Separate queue linkage from execution-attempt identity; the current update-in-place behavior cannot serve as append-only execution history.
+- Assign each attempt a deterministic, monotonically increasing attempt number scoped to its Job and Source, enforced by a database uniqueness constraint.
+- Update the latest-transcription projection only after a successful attempt.
+- Never update prior response bodies, manifests, timings, or artifacts during a retry.
+- Select the latest attempt and latest successful attempt by the persisted attempt number with a stable identifier as a defensive secondary key, never by timestamp alone.
+- Add service/workflow tests covering retries, partial success, interrupted jobs, and historical projection behavior.
+
+### 7. Add Generic Artifact Persistence
+
+- Implement service operations to create, read, list, verify, export, and, only under explicit retention policy, delete artifacts.
+- Validate semantic type, schema/version, digest, media type, and coordinate metadata.
+- Support JSON artifacts inline initially when within the agreed size threshold.
+- Support external artifacts through a constrained application-data root with atomic write, digest verification, and explicit missing-file errors.
+- Add a provider-neutral example fixture representing OCR words/lines with polygons and confidence values.
+- Do not integrate a live OCR vendor in this phase.
+
+### 8. Add Evidence Inspection and Export
+
+- Rename the current Source Detail label to identify historical values as an OpenRouter SDK Response Snapshot.
+- Add separate sections for Request Manifest, Transport Response, Normalized Metadata, Software Context, and Derived Artifacts.
+- Show an explicit “not captured for this historical execution” state instead of an empty object.
+- Keep large bodies collapsed by default and avoid rendering embedded source data.
+- Add a service-owned export that packages a versioned manifest, evidence JSON/body files, artifact content or references, and digest inventory.
+- Exclude secrets and machine-local paths that are not required to interpret the evidence.
+- Add UI and export tests for new, historical, failed, and large-evidence records.
+
+### 9. Establish the Private Benchmark
+
+- Select a small initial corpus, then expand only when it exposes meaningful differences.
+- Stratify examples by printed/typed text, handwriting style, degradation, layout complexity, language, and editorial anomaly.
+- Reference existing Source UUIDs and digests in a private manifest; do not copy family documents into public test fixtures.
+- Create manually reviewed reference transcriptions following the invariant methodology.
+- Implement or adopt existing project-compatible CER/WER calculations without changing dependencies unless justified.
+- Score omissions, inventions, silent modernization, uncertainty markup, and layout fidelity separately from CER/WER.
+- Record cost and latency from preserved execution evidence.
+- Run the current `google/gemini-2.5-flash` configuration as the baseline before testing alternatives.
+- Treat results as model-version/route/corpus specific and preserve each comparison run.
+
+### 10. Verify, Migrate, and Align Documentation
+
+- Run the smallest focused model, provider, service, workflow, UI, upgrade, and export test groups first.
+- Run broader regression tests only after focused validation passes.
+- Execute all destructive tests through `tools/run_destructive_tests.py`.
+- Verify backup creation and required restoration behavior before any test touching real application data.
+- Confirm existing Source Detail records remain readable after upgrade.
+- Update V4 architecture, schema, requirements, and UI schema mappings to point to V4.2 semantics.
+- Record any deliberate deviation from this plan in the V4.2 scope before release.
+
+## Recommended Delivery Order
+
+1. Typed/versioned evidence contracts and terminology.
+2. Additive execution-evidence persistence.
+3. Secret-safe request manifests.
+4. Exact OpenRouter transport capture.
+5. Failure evidence and append-only retry semantics.
+6. Generic artifact persistence.
+7. Inspection and export.
+8. Private benchmark tooling and baseline run.
+9. Migration, regression verification, and documentation alignment.
+
+## Key Implementation Decisions to Resolve
+
+1. Whether execution evidence is a one-to-one companion to `JobSource` or part of a new execution-attempt model required for append-only retries.
+2. Whether exact response bodies remain database values at expected sizes or move to hashed external files above a threshold.
+3. The canonical JSON algorithm used to hash request manifests.
+4. The safe-header allowlist supported by OpenRouter and future adapters.
+5. The application version identity available in local, packaged, and uncommitted development builds.
+6. The initial inline/external artifact size threshold and application-data root.
+7. Whether evidence exports include original source binaries by default, optionally, or only by reference.
+8. The minimum private benchmark corpus size and review process before model comparisons influence defaults.
+
+These decisions must be settled before their corresponding implementation phase; they do not weaken the invariant or expand V4.2 into live OCR integration.
+
+## Resolved Implementation Decisions
+
+1. `JobSource` remains queue linkage and a compatibility projection; immutable retries use a one-to-many
+   `ExecutionAttempt` model with a unique `(job_id, source_id, attempt_number)` constraint.
+2. Exact OpenRouter response bytes remain database values for V4.2. Generic artifacts use inline canonical JSON up
+   to 1 MiB by default and constrained, atomically written external files above that threshold.
+3. Request manifests use `transcription-canonical-json-v1`: UTF-8 JSON with sorted keys, compact separators,
+   preserved Unicode, and non-finite numbers rejected.
+4. Safe response headers are explicitly allowlisted in the evidence contract; all others are discarded before
+   persistence.
+5. Software identity records the package version, optional `TRANSCRIPTION_COMMIT`, adapter contract version,
+   OpenRouter SDK version, and Python version.
+6. The artifact root defaults to `data/artifacts` and stores source-scoped relative references.
+7. Evidence exports include source identity and digest by reference, not original source binaries.
+8. The benchmark manifest is private and digest-referenced. Corpus size remains archive-dependent, but every run
+   uses preserved execution-attempt identity and the fixed literal scoring contract.
+
+## Done When
+
+- Every V4.2 acceptance criterion is satisfied by focused tests or an explicit demonstration.
+- Existing SDK snapshots retain their content and are labeled accurately.
+- New successful and failed calls preserve secret-safe provider-boundary evidence.
+- Unknown transport fields survive even when the typed SDK/parser does not recognize them.
+- Retries cannot overwrite prior execution evidence.
+- A generic versioned artifact can represent OCR geometry and pass integrity verification.
+- Evidence can be safely inspected and exported with schema identities and digests.
+- The current model has a reproducible private benchmark baseline.
+- No credential or embedded source payload appears in persisted manifests, safe headers, logs, or exports.
+- Existing V4.1 behavior remains compatible.
+
+## Out of Scope
+
+- Live OCR/document-AI provider integration.
+- Automatic model switching.
+- Archive-wide reprocessing.
+- Native upstream-provider response capture through OpenRouter when OpenRouter does not expose it.
+- Guarantees of deterministic hosted-model output.
+
+## Related Local References
+
+- [V4.2 Scope Boundary](scope_boundary_v4_2.md)
+- [Digital Evidence and AI Processing Provenance](../invariant/ai_evidence_and_provenance.md)
+- [V4 Architecture](../ver4/architecture_v4.md)
+- [V4 Schema](../ver4/schema_v4.md)
+- [V4 Requirements](../ver4/requirements_v4.md)
+- [Draft V4.3 Implementation Plan](../ver4.3/implementation_plan_v4_3.md)

docs/ver4.2/scope_boundary_v4_2.md

@@ -0,0 +1,163 @@
+# V4.2 Scope Boundary
+
+This document defines the boundary for the digital-evidence and AI-provenance revision that follows V4.1 and precedes the planned V4.3 settings work. V4 remains the architecture baseline; V4.2 makes the existing evidence claims precise and adds a provider-neutral foundation for future processing artifacts.
+
+## Purpose
+
+- Align the application with the [Digital Evidence and AI Processing Provenance invariant](../invariant/ai_evidence_and_provenance.md).
+- Preserve provider-boundary evidence before SDK parsing can remove unknown fields.
+- Make successful and failed processing attempts inspectable without storing secrets.
+- Support future OCR and layout outputs without coupling the database to one vendor.
+- Establish a repeatable method for comparing transcription models against this archive.
+
+## In Scope
+
+### 1. Evidence Terminology and Existing-Data Compatibility
+
+- Define transport response, router-normalized response, SDK response, normalized metadata, and derived artifact consistently in code, schema documentation, and UI labels.
+- Treat existing `JobSource.raw_api_response` values as historical SDK response snapshots.
+- Preserve every existing `Job`, `Source`, and `JobSource` row.
+- Use additive migrations and compatibility reads; do not reinterpret previously stored values as exact transport captures.
+- Correct the “Page-Level Execution and AI Outputs” rule in `docs/ver4/schema_v4.md` that currently describes `JOB_SOURCE` as storing a complete provider response envelope. The corrected rule must identify `raw_api_response` as an SDK-serialized OpenRouter response snapshot and state that it is neither the exact HTTP body nor the native upstream-provider response.
+
+### 2. Secret-Safe Request Manifests
+
+- Persist the effective request specification for each page execution without storing credentials or duplicate base64 media.
+- Include requested provider/model, routing constraints, prompt content and hash, explicitly supplied parameters, source digest, media type, dimensions when known, and page identity.
+- Distinguish an omitted optional parameter from an explicitly supplied null or value.
+- Record application, provider-adapter, Python client, and relevant schema versions.
+- Use source or derivative references in place of embedded media bytes.
+
+### 3. Provider-Boundary Response Capture
+
+- Capture the exact HTTP response body before OpenRouter SDK parsing for non-streaming transcription calls.
+- Store HTTP status and an explicit allowlist of safe response headers.
+- Store router request/generation identifiers and resolved model/provider-routing metadata when exposed.
+- Preserve the current parsed SDK snapshot and normalized metadata where useful.
+- Keep exact body, parsed representation, and normalized fields distinguishable.
+
+### 4. Failure Evidence and Timing
+
+- Create or update a page execution record for every attempted provider call.
+- Persist safe response evidence for non-success HTTP responses.
+- Distinguish HTTP response failures, connection failures, local timeouts, response-validation failures, and transcription-quality failures.
+- Store execution start/end times or duration using a clearly defined clock policy.
+- Do not collapse a provider error body into only a generic user-facing message.
+
+### 5. Generic Processing Artifacts
+
+- Add a provider-neutral representation for versioned derived artifacts.
+- Support inline JSON and externally stored payloads with a digest and stable reference.
+- Record artifact type, format, schema/version, producer/version, source, producing execution, and creation time.
+- Define coordinate-system metadata sufficient for word, line, block, or page geometry.
+- Permit future OCR/layout/confidence results without implementing a vendor-specific table for each provider.
+
+### 6. Evidence Inspection and Export
+
+- Expand Source Detail and/or Job Detail to identify the evidence layer being displayed.
+- Provide readable JSON inspection for request manifests, transport metadata, parsed responses, normalized metadata, and derived artifacts.
+- Provide a safe export containing evidence content or references, relationships, schema versions, and digests.
+- Clearly label evidence that was not captured for historical records.
+- Do not display or export credentials, unrestricted headers, or embedded base64 source media.
+
+### 7. Representative-Corpus Benchmark Protocol
+
+- Define a private benchmark manifest referencing source digests rather than duplicating archival media.
+- Include representative printed, typed, handwritten, degraded, tabular, and spatially complex pages.
+- Pair each benchmark item with a manually reviewed literal transcription.
+- Score character error rate, word error rate, omissions, inventions, silent normalization, uncertainty handling, layout fidelity, cost, and latency.
+- Preserve the complete execution provenance for every benchmark run.
+- Keep the current model as a baseline; do not change the application default solely from vendor benchmarks.
+
+### 8. Migration, Integrity, and Verification
+
+- Provide non-destructive upgrade behavior for supported SQLite and PostgreSQL deployments.
+- Backfill only facts that can be derived reliably from existing records.
+- Mark unavailable historical evidence as unavailable rather than fabricating it.
+- Add digest, serialization, header-allowlist, failure-path, compatibility, artifact, export, and UI inspection tests.
+- Run destructive tests only through the repository's required backup-and-restore wrapper.
+
+## Out of Scope
+
+- Selecting or declaring a permanent best transcription model.
+- Changing the default transcription model without benchmark evidence and a separate decision.
+- Integrating Azure Document Intelligence, Google Document AI, Transkribus, Mistral OCR, or another OCR provider in V4.2.
+- Generating bounding boxes retroactively for existing transcriptions.
+- Bulk reprocessing the archive.
+- Packet capture, TLS evidence, full unrestricted request/response headers, or credential retention.
+- Storing duplicate base64 source images in request manifests.
+- Guaranteeing byte-identical reproduction from nondeterministic or updated hosted models.
+- Automatic entity extraction, biography generation, or genealogical inference.
+- Replacing the relational database with an event store or content-addressed object store.
+- Destructive renaming or removal of `raw_api_response`.
+
+## Locked Design Decisions
+
+### A. The Original Source Is Primary Evidence
+
+- Original uploaded bytes and their digest remain authoritative.
+- Processing derivatives and outputs are independently identified derived evidence.
+- Future OCR/layout work reuses the original or a documented derivative.
+
+### B. Evidence Is Layered
+
+- Exact transport evidence, SDK-parsed objects, normalized metadata, and transcription text serve different purposes.
+- One representation must not silently stand in for another.
+- UI and export labels name the stored evidence layer.
+
+### C. History Is Append-Only
+
+- A retry or reprocessing attempt creates new execution evidence.
+- Convenience caches may change, but historical execution output does not.
+- Human revisions remain separate from machine output.
+
+### D. Capture Is Secret-Safe by Construction
+
+- Safe headers are allowlisted.
+- Authorization, cookies, API keys, and unrestricted headers are never persisted.
+- Request manifests reference source digests instead of embedding source bytes.
+
+### E. Derived Artifacts Are Generic and Versioned
+
+- Artifact storage is not limited to bounding boxes.
+- Coordinate metadata declares units, origin, dimensions, and transformations.
+- Provider-specific payloads may be retained without making provider-specific fields the durable application contract.
+
+### F. Existing Evidence Keeps Its Original Meaning
+
+- Existing `raw_api_response` data remains an SDK response snapshot.
+- A migration may label or classify it but may not claim that missing transport data was captured.
+- Historical nulls and absent fields remain distinguishable from new explicitly captured values.
+
+## Data and Compatibility Policy
+
+- All schema changes are additive in V4.2.
+- Existing source files, hashes, transcriptions, revisions, prompts, jobs, and relationships remain valid.
+- Compatibility reads continue to display historical SDK snapshots.
+- Large derived artifacts may be stored outside the database when the database retains a stable reference, digest, media type, and schema identity.
+- JSON evidence must remain portable across SQLite and PostgreSQL.
+- Exports use explicit schema versions so later releases can interpret older packages.
+
+## Acceptance Criteria
+
+1. A new execution can be traced from its source digest through its frozen request manifest, transport response, parsed/normalized data, and derived outputs.
+2. Exact response content is captured before SDK parsing and is clearly distinguished from the existing SDK snapshot.
+3. Failed HTTP calls retain safe provider evidence; calls with no response record that fact explicitly.
+4. Omitted parameters remain distinguishable from explicit values.
+5. No persisted request, header set, UI display, log, or export contains API credentials.
+6. Retrying or reprocessing does not overwrite prior execution evidence.
+7. Historical records remain readable and are not mislabeled as exact transport captures.
+8. A versioned generic artifact can represent OCR/layout JSON and its coordinate system without a provider-specific schema change.
+9. Evidence exports include relationships, schema identities, and digests sufficient for independent integrity checks.
+10. The benchmark protocol can compare the current baseline with another model on the same private corpus and scoring rules.
+11. Additive migrations and focused tests work across the supported persistence model.
+12. All destructive-test runs comply with the backup-and-restore protocol.
+
+## Related Local References
+
+- [V4.2 Implementation Plan](implementation_plan_v4_2.md)
+- [Digital Evidence and AI Processing Provenance](../invariant/ai_evidence_and_provenance.md)
+- [V4 Architecture](../ver4/architecture_v4.md)
+- [V4 Schema](../ver4/schema_v4.md)
+- [V4 Requirements](../ver4/requirements_v4.md)
+- [Transcription Methodology](../invariant/transcription_methodology.md)

docs/ver4.3/implementation_plan_v4_3.md

@@ -0,0 +1,121 @@
+# Implementation Plan (Version 4.3)
+
+## Goal
+
+Deliver constrained, installation-local application settings while preserving the completed V4.2 behavioral baseline and historical provenance.
+
+## Planning Constraints
+
+- V4, V4.1, and V4.2 remain the behavioral baseline.
+- Settings must use explicit domain operations rather than direct database, environment-file, or arbitrary filesystem access from UI pages.
+- Prompt changes must preserve historical Job provenance and use a defined safe-write policy.
+- Source Page Reordering is excluded.
+- Database, integration, and UI tests must use confirmed isolated test data and must never modify `data/transcription.db`.
+- Potentially destructive tests must run only through `tools/run_destructive_tests.py`.
+
+## Expected Project Impact
+
+| Area | Expected impact |
+| --- | --- |
+| Documents service | Expand controlled Document Type maintenance operations. |
+| People service | Expand controlled Person Role maintenance operations. |
+| Prompt adapter/service | Add constrained listing, reading, validation, atomic writing, backup, and explicit recovery of existing prompt artifacts. |
+| UI composition/navigation | Register Settings routes and navigation without moving persistence into UI code. |
+| Tests | Add isolated registry lifecycle, prompt safety, and UI workflow coverage. |
+
+## Implementation Phases
+
+### 1. Define Service Contracts
+
+- Define Document Type maintenance commands for create, relabel, activate, deactivate, and delete-if-unreferenced.
+- Define Person Role maintenance commands for create, relabel, activate, deactivate, and delete-if-unreferenced.
+- Define a Prompt Store interface for constrained list, read, write, backup-status, and explicit recovery behavior.
+- Map validation, conflict, not-found, dependency, and filesystem failures to existing `AppError` categories.
+
+### 2. Expand Registry Maintenance Services
+
+- Reuse existing Document and People service ownership.
+- Add explicit write methods rather than passing UI-mutated ORM objects directly where practical.
+- Normalize Document Type labels and reject case-insensitive duplicates deterministically.
+- Keep Person Role stable-code validation and duplicate rejection.
+- Permit deletion only after a service-owned reference check proves the entry is unreferenced.
+- Reject deletion of referenced entries deterministically without partial mutation.
+- Permit label changes whether or not an entry is referenced.
+- Preserve inactive entries for historical reads.
+- Order Document Types alphabetically by normalized label.
+- Order Person Roles deterministically by label and then code without adding a schema field.
+- Add service tests for create, relabel, activation, deactivation, duplicates, immutable codes, ordering, allowed deletion, and blocked referenced deletion.
+
+### 3. Add Constrained Prompt Storage
+
+- Place filesystem access behind a dedicated Prompt Store/service boundary.
+- Resolve all filenames directly beneath the configured prompt root and reject traversal.
+- Permit only existing files with the agreed Markdown extension and reject empty content.
+- Exclude prompt creation and deletion.
+- Write new content to a sibling temporary file, flush and sync it, preserve the active file as the sole previous-version backup, and atomically replace the active file.
+- Expose explicit backup recovery through the same filename validation and safe-write path; never perform automatic rollback.
+- Clean up temporary files after failed writes while preserving the active prompt and any valid backup.
+- Preserve file encoding and provide explicit failures for read-only or unavailable storage.
+- Do not modify any Job row when prompt defaults change.
+- Add unit tests for valid reads/writes, traversal, invalid names, nonexistent-file creation attempts, empty content, atomic replacement failures, single-backup rotation, explicit recovery, filesystem failures, and unchanged Job provenance.
+
+### 4. Build the Settings UI
+
+- Register a Settings landing page and navigation entry.
+- Add separate pages or panels for Document Types, Person Roles, and Prompts.
+- Keep pages responsible for orchestration and notifications only.
+- Use service callbacks for all mutations.
+- Explain inactive historical entries and future-only prompt effects in the UI.
+- Present deletion only for unreferenced registry entries and preserve clear conflict feedback if references appear before submission.
+- Present prompt backup availability and recovery as an explicit operator action.
+- Do not render raw environment values or secrets.
+- Add no settings API routes.
+
+### 5. Verification and Rollout
+
+- Confirm every database, integration, and UI test is configured for an isolated test database before execution.
+- Never run those tests against live data and never modify or replace `data/transcription.db`.
+- Invoke potentially destructive tests only through `tools/run_destructive_tests.py`.
+- Run focused service tests before UI integration tests.
+- Verify inactive registry behavior in both historical display and create/edit selectors.
+- Verify referenced entries can be relabeled or deactivated but not deleted.
+- Verify unreferenced entries can be deleted.
+- Verify prompt changes are picked up by newly created Jobs while historical Jobs retain frozen content/hash.
+- Run the relevant regression suite.
+
+## Migration and Compatibility Notes
+
+- Existing registry records remain valid.
+- Prompt editing changes mutable application files, not database provenance already captured on Jobs.
+- V4.3 must not require users to recreate existing Sources, Documents, People, roles, or types.
+- Person Role ordering requires no schema migration.
+- Registry deletion introduces no cascade behavior; references always block deletion.
+
+## Delivery Order
+
+1. Implement registry maintenance service operations.
+2. Implement the Prompt Store and safety policy.
+3. Build Settings pages.
+4. Run isolated integration and regression verification.
+
+## Done Criteria
+
+- All V4.3 acceptance criteria are testable and satisfied.
+- Settings mutations cross explicit service or adapter boundaries.
+- Document Types use UUID-only identity and unique labels; Person Role codes cannot be accidentally changed.
+- Referenced registry entries can be relabeled or deactivated but cannot be deleted.
+- Unreferenced registry entries can be deleted without cascade behavior.
+- Prompt writes cannot escape the configured directory or rewrite historical provenance.
+- Prompt writes are atomic, retain one backup, and support explicit recovery.
+- No secret or raw environment editor exists.
+- No settings API surface exists.
+- V4.1 and V4.2 workflows remain intact.
+- Verification does not touch live data or `data/transcription.db`.
+
+## Related Local References
+
+- [V4.3 Scope Boundary](scope_boundary_v4_3.md)
+- [V4.2 Implementation Plan](../ver4.2/implementation_plan_v4_2.md)
+- [V4.1 Implementation Plan](../ver4.1/implementation_plan_v4_1.md)
+- [V4 Implementation Plan](../ver4/implementation_plan_v4.md)
+- [V4 Error Handling Policy](../ver4/error_handling_v4.md)

docs/ver4.3/scope_boundary_v4_3.md

@@ -0,0 +1,154 @@
+# V4.3 Scope Boundary
+
+This document defines the frozen boundary for the constrained-settings revision that follows the completed V4.2 evidence-and-provenance work. V4, V4.1, and V4.2 remain the behavioral and architecture baseline.
+
+## Purpose
+
+- Provide a constrained Settings area for safe maintenance of selected application-managed configuration.
+- Avoid exposing secrets, restart-sensitive settings, or unrestricted filesystem editing through the UI.
+
+## In Scope
+
+### 1. Settings Navigation
+
+- Add a Settings entry to application navigation.
+- Provide separate, clearly described settings areas rather than a raw configuration editor.
+- Restrict V4.3 settings to application-managed values that can be validated and safely changed at runtime.
+
+### 2. Document Type Maintenance
+
+- List active and inactive Document Types.
+- Add new types with a unique user-facing label.
+- Edit labels and active state.
+- Activate or deactivate types without invalidating historical Documents.
+- Allow deletion only when no Document references the type.
+- Allow label changes regardless of whether the type is referenced.
+- Display types alphabetically by label.
+
+### 3. Person Role Maintenance
+
+- List active and inactive Person Roles.
+- Add new roles with a stable unique code and user-facing label.
+- Edit mutable labels.
+- Activate or deactivate roles without invalidating historical links.
+- Do not allow changing a stable code after creation.
+- Order roles deterministically by label and then code; do not add persisted role sort order.
+- Allow deletion only when no document-person link references the role.
+- Allow label changes regardless of whether the role is referenced.
+
+### 4. Prompt Maintenance
+
+- List prompt markdown files from the configured prompt directory.
+- View a prompt with a concise explanation of its purpose and use.
+- Edit an existing prompt as plain markdown text.
+- Validate the filename boundary and reject empty prompt content.
+- Save changes explicitly and report filesystem failures.
+- Preserve submission-time prompt text and hash already frozen on existing Jobs.
+- Edit existing prompt files only; prompt creation and deletion are excluded.
+- Save through a sibling temporary file, flush and sync file content, retain one previous-version backup, and atomically replace the active file.
+- Provide an explicit recovery operation that restores the retained backup through the same safe-write path; do not silently roll back a failed or unwanted edit.
+
+### 5. Deployment Boundary
+
+- Settings changes apply only to the current installation.
+- V4.3 adds no settings API endpoints.
+- Service contracts must remain independent of the UI so a separately authorized API can be considered later.
+
+## Out of Scope
+
+- Viewing or editing raw `.env` files.
+- Displaying or changing provider API keys and other secrets.
+- Editing host, port, database connection, upload paths, or other restart-sensitive runtime settings.
+- Arbitrary file browsing or arbitrary prompt paths.
+- Runtime theme/CSS editing.
+- Installing themes or plugins.
+- Source page renumbering or reordering.
+- Source movement between Documents.
+- Automatic ordering based on filenames, OCR, or image content.
+- Prompt creation, deletion, and multi-version history.
+- Persisted sort-order maintenance for Person Roles.
+- Settings read or write API endpoints.
+- FamilySearch API synchronization.
+- A generic external-reference registry.
+- Ancestry references and Google Maps links.
+
+## Locked Design Decisions
+
+### A. Registry Identity and Lifecycle
+
+- Document Types use UUID identity and case-insensitively unique labels; no separate code is exposed or stored.
+- Person Role codes remain stable identifiers.
+- Labels and active state remain mutable.
+- Historical references remain valid when a registry entry is inactive.
+- Labels may be updated for referenced and unreferenced entries.
+- Unreferenced entries may be deleted; referenced entries may only be deactivated.
+
+### B. No Raw Environment Editor
+
+- `.env` may contain secrets and values that are not safely reloadable.
+- V4.3 exposes only purpose-built forms backed by explicit validation and service methods.
+
+### C. Prompt Editing Is Constrained
+
+- Prompt maintenance is limited to direct children of the configured prompt directory.
+- Existing Job provenance is never rewritten when a prompt file changes.
+- The UI must distinguish editing the default for future submissions from inspecting historical Job prompts.
+
+### D. Prompt Writes Are Atomic and Recoverable
+
+- Writes use a sibling temporary file and atomic replacement so readers observe either the old or new complete prompt.
+- The immediately previous prompt version is retained as the sole backup.
+- Recovery is an explicit operator action and uses the same validated safe-write path.
+- Prompt creation and deletion are not available in V4.3.
+
+### E. Person Role Ordering Is Deterministic, Not Persisted
+
+- Person Roles are ordered by label and then stable code.
+- V4.3 does not add a `sort_order` field to Person Roles.
+- Document Types use alphabetical label ordering and have no persisted sort order.
+
+### F. Settings Are Installation-Local
+
+- V4.3 provides Settings through the local application UI and domain services only.
+- No settings API surface is introduced.
+
+## Data and Compatibility Policy
+
+- V4.3 does not rewrite existing Documents, document-person links, Jobs, Sources, execution evidence, or prompt provenance.
+- Deactivation preserves referenced registry entries for historical display while excluding them from default create selectors.
+- Deletion checks are performed at the service boundary and must fail deterministically when references exist.
+- Prompt files are constrained to existing Markdown files that are direct children of the configured prompt root.
+- Settings UI code performs no direct database, environment-file, or arbitrary filesystem mutations.
+- Source page numbering and ordering behavior is unchanged.
+
+## Acceptance Criteria
+
+1. Document Type UUID identity and Person Role stable codes preserve historical references.
+2. Inactive registry entries remain visible on historical records but are excluded from default create selectors.
+3. Labels can be changed for referenced or unreferenced registry entries.
+4. An unreferenced Document Type or Person Role can be deleted, while deletion of a referenced entry fails without partial mutation.
+5. Document Types use alphabetical label ordering; Person Roles use deterministic label/code ordering.
+6. Prompt edits are restricted to existing Markdown files directly beneath the configured prompt directory.
+7. Prompt saves use atomic replacement, retain exactly one previous-version backup, and support explicit recovery.
+8. A prompt edit affects future Jobs only and leaves stored Job provenance unchanged.
+9. No Settings page exposes secrets, unrestricted filesystem access, or a settings API.
+10. Focused service and UI tests pass without regressing V4.1 or V4.2 workflows.
+11. Database, integration, and UI tests use confirmed isolated test data and never modify `data/transcription.db`; potentially destructive tests run only through `tools/run_destructive_tests.py`.
+
+## Scope Freeze Gate
+
+V4.3 is sufficiently frozen to begin implementation:
+
+- V4.2 is the completed behavioral baseline.
+- Registry lifecycle and ordering behavior are resolved.
+- Prompt lifecycle, atomic-write, backup, and recovery behavior are resolved.
+- The installation-local deployment boundary is resolved.
+- The implementation plan is a committed delivery plan.
+
+## Related Local References
+
+- [V4.3 Implementation Plan](implementation_plan_v4_3.md)
+- [V4.2 Scope Boundary](../ver4.2/scope_boundary_v4_2.md)
+- [V4.1 Scope Boundary](../ver4.1/scope_boundary_v4_1.md)
+- [V4 Architecture](../ver4/architecture_v4.md)
+- [V4 Schema](../ver4/schema_v4.md)

docs/ver4.4/implementation_plan_v4_4.md

@@ -0,0 +1,188 @@
+# Implementation Plan (Version 4.4)
+
+## Goal
+
+Deliver hidden semantic identity for built-in registries, a single atomic Linked People workflow, and safe browser-native printing of archival Documents and their current transcriptions.
+
+## Planning Constraints
+
+- V4.3 is the completed implementation baseline.
+- V4.4 may replace V4/V4.3 registry and document-person contracts only as specified by the V4.4 scope.
+- Semantic keys are internal and immutable; UI and public API contracts use UUIDs and labels.
+- Document and link edits must not partially commit.
+- Print output must not execute stored text or expose machine-local source paths.
+- Source page reordering remains excluded.
+- Database, integration, and UI tests must use confirmed isolated data and never modify `data/transcription.db`.
+- Potentially destructive tests must run only through `tools/run_destructive_tests.py`.
+
+## Expected Project Impact
+
+| Area | Expected impact |
+| --- | --- |
+| Models and schema bootstrap | Add nullable unique semantic keys, simplify document-person identity, and seed frozen built-ins. |
+| Document service | Maintain built-in Document Types, usage summaries, UUID assignment, and atomic Document/link writes. |
+| People service | Maintain built-in Person Roles, link summaries, UUID-only role assignment, and one-person-per-document enforcement. |
+| V4 document API | Remove role-code selectors and compatibility role fields; enforce UUID-only relationship writes. |
+| Settings UI | Use matching table workflows for Document Types and Person Roles. |
+| Document Create/Edit | Replace role-specific multiselects with one staged Linked People table and inline editor. |
+| Document Detail/printing | Add format selection, print preview, safe Source media rendering, print CSS, and job metadata. |
+| Tests and documentation | Replace superseded cardinality/identity assertions and add isolated registry, editor, transaction, and print coverage. |
+
+## Implementation Phases
+
+### 1. Align Durable Registry Contracts
+
+- Add nullable, unique `semantic_key` fields to `DocumentType` and `PersonRole`.
+- Keep UUIDs as primary and foreign-key identity.
+- Add normalized-label storage and uniqueness to Person Roles using the same trim and case-normalization policy as Document Types.
+- Remove the user-created Person Role code contract.
+- Define built-in detection as `semantic_key is not null`.
+- Centralize the frozen built-in definitions in one domain-owned location.
+- Seed six Document Types and three Person Roles idempotently.
+- Ensure label edits never change semantic keys.
+- Reject deletion of every built-in before checking references.
+- Continue blocking deletion of referenced custom entries.
+- Return deterministic validation, conflict, dependency, and not-found errors through existing error categories.
+
+### 2. Establish the Clean Schema
+
+- Remove legacy `DocumentPerson.role` compatibility storage and the fixed `DocumentPersonRole` enum.
+- Make `DocumentPerson.role_id` required.
+- Replace role-specific uniqueness with a unique `(document_id, person_id)` constraint.
+- Remove obsolete Document Type and Person Role migration paths that exist only for disposable development data.
+- Keep fresh schema creation and built-in seeding portable across SQLite and PostgreSQL.
+- Make configured development-database recreation a separate operator-confirmed step that displays the resolved target path rather than assuming `app.db` or `data/transcription.db`.
+- Never invoke recreation from application startup or test setup.
+- Add isolated schema tests for fresh creation, seed idempotence, semantic-key uniqueness, normalized-label uniqueness, required roles, and link uniqueness.
+
+### 3. Refine Registry Services and API Contracts
+
+- Add summary queries for Document counts and Person Role link counts without per-row queries.
+- Order both registries by normalized label with UUID as a deterministic tie-breaker.
+- Expose built-in status as a derived read value where the Settings UI needs it.
+- Keep semantic-key lookup behind service methods for application-owned behavior such as resolving authors.
+- Ensure create operations always produce custom entries with null semantic keys.
+- Ensure update operations accept only label and active state.
+- Remove `role_code` request alternatives and compatibility role responses from the V4 document API.
+- Require `role_id` for document-person creation and updates.
+- Add service and API tests for hidden semantic identity, relabeling, activation, built-in protection, custom deletion, counts, ordering, UUID-only writes, and conflicts.
+
+### 4. Build Matching Settings Tables
+
+- Retain the existing Document Types table workflow and add the Built-in column.
+- Replace the current per-row Person Role controls with the same selection-based table pattern.
+- Render the agreed columns and usage counts.
+- Keep labels as the only registry text shown in selectors.
+- Add creates custom entries only.
+- Edit dialogs expose label and active state only.
+- Delete reports protected-built-in and referenced-custom conflicts clearly.
+- Avoid direct persistence queries from the Settings page.
+- Add component-level UI assertions for columns, actions, label-only selectors, and immutable built-in presentation.
+
+### 5. Add a Staged Linked People Editor
+
+- Introduce a small typed UI-state model for staged `(person_id, role_id)` rows rather than storing raw widget values.
+- Share the editor component between Create Document and Edit Document.
+- Render a multi-selection table with Person and Role labels.
+- Add an inline editor whose mode is explicitly Add or Edit.
+- Disable already-linked People when adding; retain the edited Person as an option during Edit.
+- Require exactly one row for Edit and allow one or more rows for Delete.
+- Save and Delete mutate only staged UI state.
+- Cancel discards only the active inline edit.
+- Preserve inactive-role historical rows in Edit while restricting new assignments and changes to active roles.
+- Preserve `person_id` preselection by staging that Person with the active built-in `author` role, with warning behavior for invalid or unavailable selections.
+- Preserve the `return_to=jobs_new` success path.
+- Keep navigation to Person creation separate; V4.4 does not add an embedded Person editor.
+- Add UI tests for staging, duplicate prevention, selection rules, inactive roles, cancel behavior, and both Document forms.
+
+### 6. Persist Document and Links Atomically
+
+- Add service commands for Create Document with complete links and Update Document with complete links.
+- Validate Document Type, every Person, every Person Role, active assignment rules, and duplicate People before mutation.
+- Compute deterministic add, update, and remove deltas for Edit.
+- Apply Document and link mutations in one database transaction and commit once.
+- Roll back the complete operation on any validation, conflict, or persistence failure.
+- Return the persisted Document detail required by the UI after success.
+- Reuse these commands from UI orchestration rather than sequencing independent service commits.
+- Add failure-injection tests proving no partial Document or link mutation survives.
+
+### 7. Define a Print Projection
+
+- Add a read-only service projection containing:
+  - Document title and selected archival metadata.
+  - Authors resolved by the `author` semantic key.
+  - Notes.
+  - Ordered Sources with application media URLs and current transcription text.
+  - Ordered Job metadata.
+- Load the projection with bounded queries and deterministic ordering.
+- Use non-null `revised_text`, including an intentionally empty revision; otherwise fall back to `raw_transcription`.
+- Map empty or whitespace-only current text to the explicit unavailable state without falling back past an intentional revision.
+- Represent unavailable text and optional metadata explicitly.
+- Do not expose semantic keys, direct file paths, full prompts, provider evidence, or raw API responses.
+- Keep the projection independent of NiceGUI rendering so formatting tests can use plain typed values.
+
+### 8. Build Print Preview and Styles
+
+- Add a Print action to Document Detail.
+- Open a dedicated persisted-Document print route with a Facsimile/Text-only format choice.
+- Render the exact content order frozen in the scope.
+- Render stored Notes and transcription as escaped text.
+- For Text-only mode, normalize whitespace by joining single line breaks inside paragraphs while preserving blank-line paragraph boundaries.
+- For Facsimile mode, preserve line breaks and use a two-column Source layout.
+- Start each Facsimile Source on a new printed sheet with CSS page breaks.
+- Allow long transcription content to continue rather than clipping it.
+- Fetch images through an application-controlled Source media route.
+- Add print-only CSS that hides navigation, controls, and non-document chrome.
+- Invoke the browser print dialog only from an explicit user action.
+- Add rendering tests for both modes, missing data, long text, special characters, image URLs, and page ordering.
+
+### 9. Align Documentation and Verification
+
+- Update V4 architecture, requirements, schema, and Document UI contracts to reflect:
+  - UUID plus hidden semantic-key registries.
+  - Built-in protection.
+  - One Person per Document.
+  - UUID-only role API writes.
+  - Atomic Document/link synchronization.
+  - Browser-native print projection and formats.
+- Confirm every database, integration, and UI test target is isolated before execution.
+- Run focused registry and service tests first.
+- Run schema tests only through the destructive-test wrapper when they are potentially destructive.
+- Run Linked People UI and print rendering tests against isolated fixtures.
+- Run the broader non-external regression suite after focused coverage passes.
+- Verify that `data/transcription.db` was not changed by test execution.
+
+## Delivery Order
+
+1. Registry and clean-schema contracts.
+2. Registry services, API changes, and Settings tables.
+3. Atomic Document/link service commands.
+4. Shared staged Linked People editor.
+5. Print projection.
+6. Print preview and styles.
+7. Documentation alignment and regression verification.
+
+## Done Criteria
+
+- All V4.4 acceptance criteria are implemented and testable.
+- UI and API contracts use UUID identity and never expose semantic keys.
+- Built-in registries retain meaning after relabeling and cannot be deleted.
+- Custom registries retain reference-aware deletion.
+- Both Document forms use one Linked People table.
+- One Person cannot be linked twice to the same Document.
+- Main Document saves are atomic across fields and relationships.
+- Print preview provides both frozen formats and content sections.
+- Print output uses current human-preferred text, deterministic ordering, escaped content, and application media URLs.
+- Job metadata lists every Job oldest-to-newest and ends with Status.
+- Source page reordering and server-generated PDFs are not introduced.
+- Verification uses isolated data and does not modify `data/transcription.db`.
+
+## Related Local References
+
+- [V4.4 Scope Boundary](scope_boundary_v4_4.md)
+- [V4.3 Scope Boundary](../ver4.3/scope_boundary_v4_3.md)
+- [V4.3 Implementation Plan](../ver4.3/implementation_plan_v4_3.md)
+- [V4 Architecture](../ver4/architecture_v4.md)
+- [V4 Schema](../ver4/schema_v4.md)
+- [V4 Requirements](../ver4/requirements_v4.md)
+- [V4 Error Handling Policy](../ver4/error_handling_v4.md)

docs/ver4.4/scope_boundary_v4_4.md

@@ -0,0 +1,232 @@
+# V4.4 Scope Boundary
+
+This document defines the frozen boundary for the semantic-registry, linked-people, and document-printing revision that follows the completed V4.3 Settings work. V4 through V4.3 remain the architecture and behavioral baseline except where this document explicitly replaces a registry or document-person contract.
+
+## Purpose
+
+- Keep registry identifiers stable without exposing duplicate machine codes in Settings tables or selectors.
+- Replace role-specific person selectors with one coherent Linked People editor.
+- Provide an archival print view containing document metadata, source pages, current transcription text, and transcription-job metadata.
+
+## In Scope
+
+### 1. Semantic Registry Identity
+
+- `DocumentType` and `PersonRole` use UUIDs as their canonical record and relationship identity.
+- Both registries may carry a nullable, unique, immutable `semantic_key` used only for application-defined built-ins.
+- Semantic keys are internal implementation details. Settings tables, selectors, and public API payloads do not display or accept them.
+- Labels are trimmed, case-insensitively unique, editable, and used for all user-facing display.
+- Active state remains editable. Inactive entries remain valid for historical records and are excluded from default assignment selectors.
+- Built-in status is derived from the presence of a semantic key and is displayed as a read-only Yes/No value.
+- Built-in entries cannot be deleted or converted to custom entries.
+- Custom entries have no semantic key and may be deleted only when unreferenced.
+- Users may create custom entries but cannot create, change, or assign semantic keys through the UI or API.
+
+### 2. Built-In Document Types
+
+- Seed these built-in semantic keys and initial labels:
+
+| Semantic key | Initial label |
+| --- | --- |
+| `book` | Book |
+| `letter` | Letter |
+| `postcard` | Postcard |
+| `photo` | Photo |
+| `journal` | Journal |
+| `form` | Form |
+
+- The Document Types Settings table contains Select, Label, Documents, Active, and Built-in columns.
+- Document Types are ordered alphabetically by normalized label.
+- Add, Edit, and Delete actions operate on table selection.
+- Add creates a custom type. Edit changes only label and active state.
+- The Documents count is the number of Documents referencing the type.
+- Document Type selectors display labels only and submit UUIDs.
+
+### 3. Built-In Person Roles
+
+- Seed these built-in semantic keys and initial labels:
+
+| Semantic key | Initial label |
+| --- | --- |
+| `author` | Author |
+| `recipient` | Recipient |
+| `mentioned` | Mentioned |
+
+- Application behavior that requires authorship resolves the built-in `author` semantic key rather than matching a mutable label.
+- The Person Roles Settings table contains Select, Label, Links, Active, and Built-in columns.
+- Person Roles are ordered alphabetically by normalized label.
+- Add, Edit, and Delete actions operate on table selection.
+- Add creates a custom role. Edit changes only label and active state.
+- The Links count is the number of document-person relationships referencing the role.
+- Person Role selectors display labels only and submit UUIDs.
+
+### 4. Linked People Editor
+
+- Replace the separate role-specific person selectors on both Create Document and Edit Document with one Linked People table.
+- The table contains Select, Person, and Role columns.
+- Add opens an inline editor beneath the table with Person and Person Role selectors.
+- Edit requires exactly one selected row and loads it into the inline editor.
+- Save stages the inline addition or edit in the table.
+- Cancel exits the inline editor without changing the staged link set.
+- Delete stages removal of one or more selected rows.
+- A Person may be linked to a Document only once, regardless of role.
+- Every link has exactly one Person Role.
+- Already-linked People are unavailable when adding another row.
+- Existing links using inactive roles remain visible and unchanged unless explicitly edited.
+- Only active roles are available for new links or role changes.
+- Create Document preserves the existing `person_id` preselection workflow by staging that Person with the active built-in `author` role. An invalid Person or unavailable Author role produces a warning rather than an invalid link.
+- Create Document preserves the existing `return_to=jobs_new` success path.
+- Linked People changes remain staged until the main Create Document or Save Changes action.
+- The Document and its complete staged link set are persisted atomically. A conflict or validation failure leaves both unchanged.
+- The API and service contracts identify roles by `role_id`; role-code selectors and compatibility role strings are removed.
+- Persistence enforces uniqueness on `(document_id, person_id)`.
+
+### 5. Document Print View
+
+- Add a Print action to Document Detail.
+- The action opens a dedicated print-preview page for the persisted Document.
+- The preview offers two formats:
+  - **Facsimile:** source image on the left and current transcription on the right. Original transcription line breaks are preserved, and each Source begins on a new printed sheet.
+  - **Text only:** no source images. Single line breaks inside a paragraph are reflowed as spaces, while blank-line paragraph boundaries remain.
+- Both formats use browser printing through a dedicated print stylesheet and the browser print dialog.
+- Server-generated PDF files are not part of V4.4; users may select the browser's Save as PDF destination.
+- Sources are ordered by existing `page_number`, with UUID as a deterministic tie-breaker.
+- The current transcription for each Source is the non-null `revised_text`, including an intentionally empty revision, otherwise the latest successful machine-output projection in `raw_transcription`.
+- Empty or whitespace-only current text displays the explicit unavailable message rather than falling back past an intentional revision.
+- A Source with no current transcription displays an explicit unavailable message.
+- Transcription and Notes content is treated as text and escaped; model output is not executed as arbitrary HTML.
+- Facsimile images use an application-controlled Source media route. Generated markup does not expose direct machine-local file paths.
+
+### 6. Printed Content Contract
+
+The print view contains, in this order:
+
+1. Document title using the Document name.
+2. Archival Metadata table:
+   - Author, containing People linked through the built-in `author` role.
+   - Date.
+   - Location Created.
+   - Archival Identifier.
+3. Notes.
+4. Document section containing one numbered section per Source.
+5. Transcription Job Metadata table.
+
+Empty metadata values remain visible as `Not set`. Empty Notes display `No notes recorded`.
+
+The job metadata table:
+
+- Lists field names in the first column and adds one column for every Job associated with the Document.
+- Orders Job columns from oldest to newest by creation date, then UUID.
+- Includes every Job status: `queued`, `processing`, `transcribed`, `completed`, `partial_success`, and `failed`.
+- Contains these rows in order:
+  - Job ID.
+  - Date, using the Job creation/submission timestamp with timezone.
+  - Provider.
+  - Model.
+  - Prompt, using the frozen prompt filename/name rather than full prompt content.
+  - Retry Count.
+  - Status as the final row.
+- Displays `Not set` for unavailable optional metadata.
+
+### 7. Clean Development Schema
+
+- V4.4 does not require preservation or migration of rows in the operator-configured development database.
+- Implementation may recreate the configured development database, including `data/transcription.db` when it is the explicitly selected target, only through a separate operator-confirmed action that identifies the resolved path. Startup and test execution never delete it automatically.
+- Fresh schema creation seeds the agreed built-in Document Types and Person Roles idempotently.
+- No test may use, modify, replace, or restore `data/transcription.db`.
+- Database, integration, and UI tests use confirmed isolated databases.
+- Potentially destructive tests run only through `tools/run_destructive_tests.py`.
+
+## Out of Scope
+
+- User creation, editing, deletion, or direct display of semantic keys.
+- Treating custom registry entries as built-ins.
+- Additional built-in Document Types or Person Roles beyond the frozen lists.
+- Assigning more than one role to the same Person on the same Document.
+- Preserving multiple historical links that violate the new one-person-per-document constraint.
+- Source page renumbering or reordering.
+- Printing unsaved Create/Edit Document state.
+- Print actions on Job Detail or other pages.
+- Batch printing multiple Documents.
+- Server-side PDF generation or PDF file storage.
+- Markdown, DOCX, or evidence-package export through the print feature.
+- User-editable print templates, fonts, margins, headers, or footers.
+- Full frozen prompt content, prompt hashes, transport evidence, API responses, or execution-attempt details in the print footer.
+- Rendering transcription text as unrestricted Markdown or HTML.
+- Pixel-identical pagination across browsers and printer drivers.
+
+## Locked Design Decisions
+
+### A. UUID Identifies the Row; Semantic Key Identifies Built-In Meaning
+
+- UUIDs remain the only relationship and API identity.
+- A hidden semantic key permits reliable built-in behavior after a label is renamed.
+- Mutable labels are never used to infer built-in meaning.
+
+### B. Built-Ins Are Protected but Mutable in Presentation
+
+- Built-in labels and active state may change.
+- Built-in semantic identity cannot change, and built-ins cannot be deleted.
+- Custom entries remain reference-aware and deletable when unreferenced.
+
+### C. Linked People Is a Single-Role Relationship
+
+- One `(document_id, person_id)` row represents the complete relationship.
+- Changing a role updates that row rather than adding another relationship.
+- The main Document save owns one atomic Document-and-links transaction.
+
+### D. Printing Uses the Current Human-Preferred Text
+
+- Human-revised text takes precedence over the latest successful machine-output projection.
+- Job metadata provides processing context but does not claim that a later human revision is raw output from a listed Job.
+
+### E. Printing Is Browser-Native
+
+- A print-specific HTML view and CSS support physical printing and browser Save as PDF.
+- Source media is served through application-controlled routes, and all textual content is escaped.
+
+### F. Source Order Is Read-Only in V4.4
+
+- Print order follows existing page numbers.
+- Source page reordering remains explicitly excluded.
+
+## Acceptance Criteria
+
+1. Registry selectors and Settings forms never display a machine code or semantic key.
+2. Document Types and Person Roles use UUID relationship identity and case-insensitively unique labels.
+3. The six Document Type and three Person Role built-ins are seeded with immutable internal semantic keys.
+4. Built-ins may be relabeled or disabled but cannot be deleted.
+5. Unreferenced custom entries may be deleted; referenced custom entries may only be relabeled or disabled.
+6. Settings tables show the agreed columns, alphabetical label order, usage counts, and selection-based actions.
+7. Create and Edit Document use one Linked People table with inline staged Add/Edit/Save/Cancel and multi-row Delete.
+8. The same Person cannot be staged or persisted twice for one Document, even under different roles.
+9. Document fields and Linked People changes commit atomically.
+10. Historical inactive roles remain displayable, while only active roles are assignable.
+11. Document Detail opens a print preview with Facsimile and Text-only formats.
+12. Print pages use current revised text when available and deterministic Source ordering.
+13. Printed archival metadata resolves authors through the hidden `author` semantic key after any label change.
+14. The job table contains one oldest-to-newest column per Job and ends with the Status row.
+15. Print output escapes stored text and does not disclose direct local source paths.
+16. Source reordering, server PDF generation, and print-template editing are absent.
+17. Database, integration, and UI verification uses isolated test data and never modifies `data/transcription.db`.
+
+## Scope Freeze Gate
+
+V4.4 is sufficiently frozen to begin implementation:
+
+- Built-in registry identity, membership, lifecycle, display, and selector behavior are resolved.
+- Linked People selection, editing, uniqueness, inactive-role, staging, and transaction behavior are resolved.
+- Print entry point, formats, content order, transcription precedence, page order, job metadata, and output mechanism are resolved.
+- Clean development-schema and destructive-test boundaries are resolved.
+- Source page reordering remains excluded.
+
+Any expansion of the built-in catalogs, relationship cardinality, print formats, export formats, or print customization requires an explicit V4.4 scope amendment or a later revision.
+
+## Related Local References
+
+- [V4.4 Implementation Plan](implementation_plan_v4_4.md)
+- [V4.3 Scope Boundary](../ver4.3/scope_boundary_v4_3.md)
+- [V4.3 Implementation Plan](../ver4.3/implementation_plan_v4_3.md)
+- [V4 Architecture](../ver4/architecture_v4.md)
+- [V4 Schema](../ver4/schema_v4.md)
+- [V4 Requirements](../ver4/requirements_v4.md)

docs/ver4/architecture_v4.md

@@ -0,0 +1,197 @@
+# System Architecture (Version 4)
+
+This document describes the production architecture of the document transcription system.
+
+## Architecture Objectives
+
+- Preserve original source material, per-execution machine output, and separate human revision.
+- Support batching one or more images into ordered multi-page documents.
+- Capture submission-time prompt provenance and a per-page OpenRouter SDK response snapshot.
+- Execute page transcription concurrently with bounded `asyncio` workers.
+- Maintain relational portability across SQLite and PostgreSQL.
+- Keep operator workflows cross-platform and Python-driven.
+- Support many-to-many document-person relationships with extensible roles.
+- Support registry-driven document type classification.
+
+## Core Capabilities
+
+- Ingest one or more images into sequential `Source` pages under a `Document`.
+- Execute asynchronous vision transcription with bounded worker concurrency.
+- Preserve original source files with SHA-256 digests and byte sizes.
+- Freeze prompt text, prompt hash, model, and explicitly configured sampling parameters on each `Job`.
+- Preserve page-level machine output, normalized metadata, and an SDK-serialized OpenRouter response snapshot on `JobSource`.
+- Organize historical `Person` records through many-to-many Document relationships and extensible roles.
+- Classify Documents through a UUID-identified registry with unique labels.
+- Maintain human revision separately from machine-generated text.
+- Isolate page failures so multi-page jobs can complete with partial success.
+- Operate across supported platforms through Python-based application and maintenance tooling.
+
+V4.2 extends this baseline with immutable execution attempts, exact OpenRouter transport evidence, safe
+versioned exports, and provider-neutral derived-artifact provenance. `JobSource` remains the mutable queue and
+compatibility projection; `ExecutionAttempt` is the authoritative append-only processing history. See the
+[V4.2 Scope Boundary](../ver4.2/scope_boundary_v4_2.md).
+
+## Technical Stack
+
+- **Runtime:** Python 3.12 or later.
+- **Web application:** FastAPI and NiceGUI.
+- **Persistence:** SQLModel and SQLAlchemy, with SQLite and PostgreSQL support.
+- **Validation and settings:** Pydantic V2 and pydantic-settings.
+- **Concurrency:** Python `asyncio` workers.
+- **Vision integration:** OpenRouter through the application's provider adapter.
+- **Testing and quality:** pytest, pytest-asyncio, Ruff, and ty.
+
+## Runtime Topology
+
+The runtime operates as an asynchronous Python application:
+
+- FastAPI + NiceGUI web application process.
+- In-process `asyncio` worker engine for transcription execution.
+- Relational persistence via SQLModel / SQLAlchemy.
+- Pydantic V2 validation across API payloads, prompt configuration, and structured metadata.
+
+^^^mermaid
+flowchart LR
+U[Browser User] --> A[FastAPI + NiceGUI App]
+A --> W[Asyncio Worker Engine]
+A --> DB[(Relational DB)]
+W --> P[Vision Provider APIs]
+W --> DB
+^^^
+
+## Lifecycle Ownership
+
+Application lifespan owns runtime setup and teardown:
+
+- Initialize logging, settings, directories, and prompt configuration.
+- Manage asynchronous database engine connection pools.
+- Execute database bootstrap or migrations.
+- Recover stale or interrupted jobs on startup.
+- Manage graceful shutdown of active background tasks.
+
+## Layered Module Structure
+
+### Interface Layer
+
+- `src/transcription/ui/**`
+- `src/transcription/api/**`
+
+Responsibilities:
+
+- Render document, source, person, job, and classification views.
+- Accept user input for uploads, editing, linking, and revisions.
+- Present structured validation and conflict feedback.
+
+### Application and Async Worker Layer
+
+- `src/transcription/services/workflows.py`
+- `src/transcription/worker.py`
+
+Responsibilities:
+
+- Orchestrate uploads, job creation, and status transitions.
+- Execute per-page provider calls through bounded concurrency.
+- Persist page-level outcomes and update aggregate job state.
+
+### Domain and Service Layer
+
+- `src/transcription/db/models.py`
+- `src/transcription/services/documents.py`
+- `src/transcription/services/sources.py`
+- `src/transcription/services/jobs.py`
+- `src/transcription/services/people.py`
+- `src/transcription/services/workflows.py`
+
+Responsibilities:
+
+- Keep one primary service boundary per aggregate: Documents, Sources, Jobs, and People.
+- Documents own document records and the document-type registry.
+- Sources own source records, revisions, source media formats, MIME resolution, and page execution evidence.
+- Jobs own job lifecycle state and transitions.
+- People own person records, relationship roles, document-person links, and portrait media.
+- Apply deterministic conflict handling for relationship-role writes.
+- Use set-based synchronization for many-to-many relationship updates.
+- Resolve and validate registry-backed document types by UUID.
+
+### Source Media Policy
+
+- `services/sources.py` is the single authority for accepted Source extensions and canonical MIME types.
+- Storage and provider payload loading must call the same Source validation functions.
+- Supported Source formats are JPEG, PNG, TIFF, and PDF.
+- Upload is an interface action, not a domain aggregate. Service names, errors, and workflow variables use
+  `Source` terminology; compatibility aliases may remain temporarily at old import boundaries.
+
+### Infrastructure Layer
+
+- `src/transcription/db/**`
+- `src/transcription/providers/**`
+
+Responsibilities:
+
+- Provide async database sessions and engine configuration.
+- Provide provider adapters for vision model execution.
+
+## Core Workflows
+
+### 1. Multi-Page Transcription
+
+1. User uploads one or more images for a `Document`.
+2. System stores files, hashes them, creates ordered `Source` rows, and creates a `Job`.
+3. Worker claims the job, marks it `processing`, and executes page calls concurrently.
+4. Each provider call appends an `ExecutionAttempt` with its request manifest, transport evidence, SDK snapshot,
+   normalized metadata, timing, and outcome.
+5. The linked `JobSource` is updated as a compatibility projection, and a successful attempt updates the
+   `Source.raw_transcription` latest-success projection.
+6. Aggregate status becomes `completed`, `partial_success`, or `failed`.
+
+### 2. Document-Person Relationship Management
+
+1. User opens a document or person edit flow.
+2. UI loads existing links grouped by role.
+3. User adds or removes people within one or more roles.
+4. Service computes add/remove deltas rather than replacing all links blindly.
+5. Conflict checks enforce uniqueness and deterministic write semantics before persistence commits.
+
+### 3. Document Type Management
+
+1. User selects a registry-backed document type for a document.
+2. Service resolves the Document Type UUID.
+3. Persistence stores the `document_type_id` reference.
+4. Inactive types remain valid for historical rows but are excluded from default selectors.
+
+## V4 Domain Rules
+
+- `JobSource.raw_transcription` preserves page output for its Job execution.
+- `Source.raw_transcription` is the latest-success machine-output projection for a page.
+- Human corrections occur only in `Source.revised_text`.
+- Prompt and parameter provenance is frozen on `Job` at submission time.
+- The SDK-serialized OpenRouter response snapshot is stored on `JobSource` for each successful page execution.
+- Every V4.2 provider call appends a distinct `ExecutionAttempt`; retries never rewrite earlier attempts.
+- Exact response bytes identify the OpenRouter HTTP boundary and are not labeled as native upstream-provider JSON.
+- Generic `ProcessingArtifact` records use versioned schemas, digests, and one inline or external content location.
+- `DocumentPerson` links are unique for `(document_id, person_id, role_id)`.
+- Relationship mutations are deterministic and set-based.
+- `DocumentType.id` is canonical identity; its unique label may evolve.
+
+## Data Model Summary
+
+- `Document` has one `DocumentType`, many `Source` pages, many `Job` runs, and many `Person` records through `DocumentPerson`.
+- `Source` belongs to one `Document` and may participate in many `JobSource` executions.
+- `Job` has many `JobSource` rows.
+- `PersonRole` defines available relationship roles.
+
+## Test Strategy
+
+- Unit tests for models, validation, hashing, and registry resolution.
+- Service tests for CRUD, set-based sync, uniqueness conflicts, and deterministic relationship writes.
+- Async workflow tests for page isolation, partial failure handling, and stored evidence.
+- UI integration tests for multi-page rendering, role grouping, and document type selection.
+
+## Related Local References
+
+- [System Overview](index_v4.md)
+- [System Requirements](requirements_v4.md)
+- [Data Model](schema_v4.md)
+- [Error Handling Policy](error_handling_v4.md)
+- [Error Handling Invariant](../invariant/error_handling.md)
+- [Digital Evidence and AI Processing Provenance](../invariant/ai_evidence_and_provenance.md)

docs/ver4/error_handling_v4.md

@@ -0,0 +1,115 @@
+# Error Handling Policy (Version 4)
+
+This document defines the Version 4 taxonomy, contracts, and framework behavior used to satisfy the cross-version [Error Handling invariant](../invariant/error_handling.md).
+
+## Invariant Alignment
+
+Version 4 implements the invariant through:
+
+- The shared error taxonomy below.
+- Structured error envelopes with correlation IDs.
+- Page-level failure isolation and explicit aggregate job status.
+- Atomic relationship and classification writes.
+- Consistent translation across API, UI, service, worker, persistence, and provider boundaries.
+- Bounded retry guidance based on category and idempotency.
+
+## Scope and Authority
+
+This policy governs error behavior across:
+
+- NiceGUI pages
+- FastAPI routes
+- Service-layer orchestration
+- `asyncio` worker tasks
+- Database interactions
+- Provider adapters
+
+## Error Taxonomy
+
+| Category | Definition | Retriable |
+| --- | --- | --- |
+| `validation_error` | Payload, parameter, or schema validation failure | no |
+| `user_input_error` | Unacceptable file, invalid selection, or malformed request from the operator | no |
+| `not_found_error` | Requested `Document`, `Source`, `Person`, `Job`, role, or type does not exist | no |
+| `conflict_error` | Operation violates uniqueness or relationship-write policy | no |
+| `external_provider_error` | Provider API failure, rate limit, or execution problem | yes |
+| `infrastructure_transient_error` | Temporary DB, file-system, or network instability | yes |
+| `infrastructure_persistent_error` | Persistent configuration, credential, or database availability failure | no |
+| `internal_unexpected_error` | Uncaught exception or logic defect | no |
+
+## Async Batch and Page-Level Error Behavior
+
+In multi-page `asyncio` processing:
+
+1. Exceptions from individual page calls are trapped within the page task wrapper.
+2. Failed page detail is written to `JobSource.error_detail` and the page state becomes `failed`.
+3. Aggregate job status is derived from page outcomes:
+   - all pages succeed -> `completed`
+   - some succeed and some fail -> `partial_success`
+   - all fail -> `failed`
+4. Successful pages remain valid even when sister pages fail.
+
+## Relationship and Classification Conflict Behavior
+
+When relationship or document-type writes fail policy checks:
+
+1. Reject the full write operation.
+2. Return structured conflict detail including target identifiers and the violated rule.
+3. Preserve existing persisted relationships unchanged.
+
+## API Error Response Contract
+
+API error responses return a structured envelope:
+
+^^^json
+{
+  "error_id": "err_uuid_12345",
+  "category": "conflict_error",
+  "message": "Relationship write conflicts with existing links.",
+  "suggestion": "Adjust the requested relationship links and retry.",
+  "details": {
+    "document_id": "...",
+    "person_id": "...",
+    "attempted_role": "recipient",
+    "operation": "add_link",
+    "conflict_reason": "duplicate document-person-role link"
+  },
+  "timestamp": "2026-08-10T15:00:00Z"
+}
+^^^
+
+HTTP status mappings:
+
+- `validation_error`, `user_input_error` -> `400`
+- `not_found_error` -> `404`
+- `conflict_error` -> `409`
+- `external_provider_error` -> `502` or `503`
+- `infrastructure_transient_error` -> `503`
+- `infrastructure_persistent_error`, `internal_unexpected_error` -> `500`
+
+## UI Error Presentation Rules
+
+- Display concise failure summaries with the next action the operator can take.
+- Keep form state in context when feasible.
+- Distinguish validation issues, conflict issues, provider failures, and infrastructure failures.
+- For bulk relationship updates, identify the specific role or person that caused a conflict.
+
+## Logging and Audit Expectations
+
+- Log worker failures with correlation IDs and provider context.
+- Log relationship and classification conflicts with machine-readable detail.
+- Log persisted provider errors and page-level execution failures.
+
+## Retry Guidance
+
+- Do not auto-retry validation or conflict failures.
+- Permit user-driven retry after the input or selection changes.
+- Allow bounded retry for transient provider or infrastructure failures when the operation is idempotent.
+
+## Related Local References
+
+- [Error Handling Invariant](../invariant/error_handling.md)
+- [System Overview](index_v4.md)
+- [System Requirements](requirements_v4.md)
+- [Data Model](schema_v4.md)
+- [System Architecture](architecture_v4.md)

docs/ver4/implementation_plan_v4.md

@@ -0,0 +1,102 @@
+# Implementation Plan (Version 4)
+
+## Goal
+
+Implement the Version 4 project definition from the current repository state while preserving existing data by default.
+
+## Migration Policy
+
+- Database changes are non-destructive by default.
+- Exception: the legacy `document_type` text field may be replaced by a `document_type_id` reference without migrating existing text values.
+- Exception: `document_person` links may be recreated manually.
+
+## Current Project Impact
+
+- `src/transcription/db/models.py` requires full schema alignment with the V4 core documents.
+- `src/transcription/services/documents.py` requires set-based document-person sync and document-type resolution.
+- API modules require additive role-aware relationship behavior and document-type selection behavior.
+- UI pages require grouped role displays, multi-role editing, and registry-backed document-type selection.
+- Existing tests require updates for role enforcement, document-type selection, and regression safety.
+
+## Implementation Phases
+
+### 1. Finalize the Transition Documents
+
+- Confirm the reset scope.
+- Confirm the database exception policy.
+- Keep core V4 documents as the only authoritative product definition.
+
+### 2. Align the Persistence Layer
+
+- Update SQLModel definitions to match the final V4 schema.
+- Add `person_role` and `document_type` support.
+- Replace legacy document-type storage with `document_type_id`.
+- Apply the accepted manual exception strategy for `document_type` and `document_person` data.
+- Preserve all other data structures non-destructively.
+
+### 3. Update Services and Write Semantics
+
+- Organize service ownership around Documents, Sources, Jobs, and People.
+- Centralize Source extension and MIME policy in the Sources service.
+- Treat upload as an interface action and remove it from domain service naming where compatibility permits.
+- Implement set-based synchronization for document-person updates.
+- Implement deterministic uniqueness and relationship-write conflict checks.
+- Remove suggestion-related service behavior.
+- Add document-type resolution and validation by UUID.
+
+### 4. Update API Contracts
+
+- Keep API evolution additive.
+- Add role-aware relationship retrieval and write behavior.
+- Add document-type catalog retrieval and UUID-based selection for document writes.
+- Remove suggestion-related API surfaces from the V4 target state.
+
+### 5. Update UI Workflows
+
+- Replace single-person link editing with grouped multi-role editing.
+- Render grouped role links on document and person detail views.
+- Replace free-text document type entry with registry-backed selection.
+- Preserve clear validation and conflict messaging.
+
+### 6. Verification and Hardening
+
+- Add or update service tests for many-per-role behavior, uniqueness conflict handling, and set-based sync correctness.
+- Add API tests for relationship behavior and document-type selection.
+- Add UI tests or walkthrough coverage for grouped roles and type selection.
+- Add regression coverage for delete and cleanup semantics.
+- Enforce backup-first test execution for AI-run unit tests: backup `./data` before tests, then always prompt for restore after successful tests.
+- Keep restore confirmation-gated by default so code and test outcomes can be reviewed before data is reverted.
+
+## Done When
+
+- Core V4 documents and code paths agree on the final project definition.
+- Relationship-role writes are deterministic and non-destructive.
+- Relationship-write conflict rules are enforced consistently.
+- Document type selection is registry-backed.
+- The accepted manual exceptions for `document_type` and `document_person` are completed.
+- The focused test coverage passes.
+
+## Out of Scope
+
+- Suggested/asserted relationship state.
+- Suggestion review or extraction workflows.
+- Global person entity-resolution engine.
+- Automated semantic document-type classification.
+
+## Delivery Order Recommendation
+
+1. Freeze scope boundary and implementation plan.
+2. Freeze core V4 documents.
+3. Align persistence models.
+4. Align services and API behavior.
+5. Align UI behavior.
+6. Run focused verification and regression checks.
+
+## Related Local References
+
+- [V4 Scope Boundary](scope_boundary_v4.md)
+- [System Overview](index_v4.md)
+- [System Requirements](requirements_v4.md)
+- [Data Model](schema_v4.md)
+- [System Architecture](architecture_v4.md)
+- [Error Handling Policy](error_handling_v4.md)

docs/ver4/index_v4.md

@@ -0,0 +1,30 @@
+# Document Transcription System Overview (Version 4)
+
+Version 4 is the architecture baseline for the personal-scale application used to transcribe, organize, and preserve historical documents, source images, and related people records.
+
+## Recommended Reading Order
+
+1. [System Architecture](architecture_v4.md) for capabilities, technical stack, runtime structure, workflows, and component ownership.
+2. [System Requirements](requirements_v4.md) for the verifiable V4 contract.
+3. [Data Model](schema_v4.md) for entities, relationships, constraints, and persistence rules.
+4. [Error Handling Policy](error_handling_v4.md) for the V4 taxonomy and boundary contracts.
+
+## Cross-Version Invariants
+
+- [Historical Document Transcription Design Intent](../invariant/intent.md)
+- [Transcription Methodology](../invariant/transcription_methodology.md)
+- [Error Handling](../invariant/error_handling.md)
+- [Digital Evidence and AI Processing Provenance](../invariant/ai_evidence_and_provenance.md)
+- [UI Style Guide](../invariant/ui_style_guide.md)
+
+## V4 Transition Documents
+
+- [Scope Boundary](scope_boundary_v4.md)
+- [Implementation Plan](implementation_plan_v4.md)
+
+## Incremental Revisions
+
+- [V4.1 Scope](../ver4.1/scope_boundary_v4_1.md) and [Implementation Plan](../ver4.1/implementation_plan_v4_1.md)
+- [V4.2 Evidence and Provenance Scope](../ver4.2/scope_boundary_v4_2.md) and [Implementation Plan](../ver4.2/implementation_plan_v4_2.md)
+- [V4.3 Settings Scope](../ver4.3/scope_boundary_v4_3.md) and [Implementation Plan](../ver4.3/implementation_plan_v4_3.md)
+- [V4.4 Semantic Registries, Linked People, and Printing Scope](../ver4.4/scope_boundary_v4_4.md) and [Implementation Plan](../ver4.4/implementation_plan_v4_4.md)

docs/ver4/requirements_v4.md

@@ -0,0 +1,51 @@
+# Document Transcription System Requirements (Version 4)
+
+This document defines the baseline requirements for the document transcription system.
+
+## Requirements Model
+
+| ID | Category | Requirement | Verify Method |
+| --- | --- | --- | --- |
+| REQ-0 | System | Provide end-to-end multi-page document transcription with persistent, inspectable async job states. | demonstration |
+| REQ-1 | Functional | Allow users to upload one or more images as ordered `Source` pages under a `Document`. | test |
+| REQ-2 | Functional | Process page transcription asynchronously using an `asyncio` worker pool bounded by rate limits. | test |
+| REQ-3 | Functional | Persist submission-time request provenance and accurately labeled page-level SDK evidence; V4.2 adds exact OpenRouter-boundary transport evidence for new attempts. | test |
+| REQ-4 | Functional | Support job states `queued`, `processing`, `completed`, `partial_success`, and `failed`, plus page states `pending`, `transcribed`, and `failed`. | inspection |
+| REQ-5 | Functional | Allow users to manage historical `Person` records and link multiple people per role to a `Document`. | test |
+| REQ-6 | Functional | Support an extensible role taxonomy for document-person relationships. | inspection |
+| REQ-7 | Policy Constraint | Enforce deterministic relationship-role writes with uniqueness on `(document_id, person_id, role_id)` and explicit conflict responses for invalid duplicate link attempts. | test |
+| REQ-8 | Functional | Use set-based synchronization for document-person mutations so updates add and remove only the intended links. | test |
+| REQ-9 | Functional | Maintain immutable machine output on `Source.raw_transcription` while permitting inline human edits on `Source.revised_text`. | test |
+| REQ-10 | Functional | Support a UUID-identified `DocumentType` taxonomy with unique user-facing labels and active/inactive lifecycle control. | test |
+| REQ-11 | Data Constraint | Store `Document` type as a controlled reference to `DocumentType`. | test |
+| REQ-12 | Interface | Render multi-page transcriptions sequentially by `page_number` with document, people, and document-type metadata. | demonstration |
+| REQ-13 | Interface | Document create/edit UI must support selecting multiple people per role and selecting an active document type from the registry. | demonstration |
+| REQ-14 | API Constraint | Expose additive, role-aware retrieval and write behavior for document-person links and UUID-based selection for document types. | test |
+| REQ-15 | Data Constraint | Calculate and store cryptographic file hashes (SHA-256) and file sizes for uploaded source images. | test |
+| REQ-16 | Data Constraint | Preserve a portable relational model across supported backends using SQLModel, SQLAlchemy, SQLite, and PostgreSQL. | inspection |
+| REQ-17 | Reliability | Ensure delete and update flows for documents, people, and relationship links remain deterministic and safe. | test |
+| REQ-18 | Operations Constraint | Keep canonical development, testing, restore, and recovery workflows OS-independent; for AI-run unit tests, require a pre-test backup of `./data` and an always-shown post-success confirmation prompt before any restore action. | inspection |
+| REQ-19 | Quality | Provide automated coverage for async transcription workflows, relationship-role enforcement, document-type selection, and regression behavior. | test |
+
+## Clarifying Constraints
+
+1. `DocumentType.id` is its sole identity; labels are unique ignoring case and surrounding whitespace.
+2. `PersonRole.code` is a stable machine identifier; `PersonRole.label` may evolve.
+3. Relationship-write policy and conflict handling must be consistent across UI, API, services, and persistence.
+4. Many-per-role behavior is required for document-person links.
+5. Relationship conflicts must fail deterministically without partial mutation.
+
+## Element Satisfaction Mapping
+
+- UI (NiceGUI): Satisfies REQ-0, REQ-1, REQ-5, REQ-9, REQ-12, REQ-13.
+- API (FastAPI): Satisfies REQ-1, REQ-4, REQ-5, REQ-7, REQ-8, REQ-14.
+- Worker (`asyncio`): Satisfies REQ-2, REQ-3, REQ-4.
+- Persistence (SQLModel / SQLAlchemy): Satisfies REQ-3, REQ-9, REQ-10, REQ-11, REQ-15, REQ-16, REQ-17.
+- Test Suite: Verifies all test-marked requirements and satisfies REQ-19.
+
+## Related Local References
+
+- [System Overview](index_v4.md)
+- [System Architecture](architecture_v4.md)
+- [Data Model](schema_v4.md)
+- [Error Handling Policy](error_handling_v4.md)

docs/ver4/schema_v4.md

@@ -0,0 +1,236 @@
+# Database Schema (Version 4)
+
+This document defines the relational schema for the document transcription system.
+
+## Entity Relationship Diagram
+
+```mermaid
+erDiagram
+DOCUMENT_TYPE {
+UUID id PK
+TEXT label
+TEXT normalized_label
+BOOLEAN is_active
+TIMESTAMPTZ created_at
+TIMESTAMPTZ updated_at
+}
+
+PERSON_ROLE {
+UUID id PK
+TEXT code
+TEXT label
+BOOLEAN is_active
+TIMESTAMPTZ created_at
+TIMESTAMPTZ updated_at
+}
+
+PERSON {
+UUID id PK
+TEXT full_name
+TEXT display_name
+TEXT maiden_name
+DATE birth_date
+TEXT birth_date_raw
+TEXT birth_place
+DATE death_date
+TEXT death_date_raw
+TEXT death_place
+TEXT biography
+TEXT portrait_path
+JSONB metadata
+TIMESTAMPTZ created_at
+TIMESTAMPTZ updated_at
+}
+
+DOCUMENT {
+UUID id PK
+UUID document_type_id FK
+TEXT name
+DATE document_date
+TEXT document_date_raw
+TEXT location_created
+TEXT notes
+TEXT archive_identifier
+TIMESTAMPTZ created_at
+TIMESTAMPTZ updated_at
+}
+
+DOCUMENT_PERSON {
+UUID id PK
+UUID document_id FK
+UUID person_id FK
+UUID role_id FK
+TIMESTAMPTZ created_at
+TIMESTAMPTZ updated_at
+}
+
+JOB {
+UUID id PK
+UUID document_id FK
+VARCHAR status
+INTEGER retry_count
+TEXT provider
+TEXT model
+TEXT prompt_name
+TEXT prompt_hash
+TEXT system_prompt
+TEXT user_prompt
+FLOAT temperature
+FLOAT top_p
+TIMESTAMPTZ date_created
+TIMESTAMPTZ date_updated
+}
+
+SOURCE {
+UUID id PK
+UUID document_id FK
+INTEGER page_number
+TEXT upload_name
+TEXT filename
+TEXT file_path
+TEXT file_hash
+BIGINT file_size_bytes
+TEXT raw_transcription
+TEXT revised_text
+TIMESTAMPTZ date_uploaded
+TIMESTAMPTZ date_revised
+}
+
+JOB_SOURCE {
+UUID id PK
+UUID job_id FK
+UUID source_id FK
+VARCHAR status
+TEXT raw_transcription
+JSONB ai_metadata
+JSONB raw_api_response
+TEXT error_detail
+TIMESTAMPTZ executed_at
+}
+
+EXECUTION_ATTEMPT {
+UUID id PK
+UUID job_source_id FK
+UUID job_id FK
+UUID source_id FK
+INTEGER attempt_number
+VARCHAR status
+JSONB request_manifest
+TEXT request_manifest_sha256
+INTEGER transport_status_code
+BINARY transport_body
+JSONB transport_safe_headers
+JSONB sdk_response_snapshot
+JSONB normalized_metadata
+JSONB software_context
+TEXT raw_transcription
+TEXT failure_phase
+TIMESTAMPTZ started_at
+TIMESTAMPTZ finished_at
+INTEGER duration_ms
+}
+
+PROCESSING_ARTIFACT {
+UUID id PK
+UUID source_id FK
+UUID execution_attempt_id FK
+TEXT artifact_type
+TEXT media_type
+TEXT schema_name
+TEXT schema_version
+TEXT producer
+TEXT producer_version
+JSONB inline_payload
+TEXT external_reference
+TEXT payload_sha256
+BIGINT byte_size
+JSONB coordinate_metadata
+TIMESTAMPTZ created_at
+}
+
+DOCUMENT_TYPE ||--o{ DOCUMENT : classifies
+DOCUMENT ||--o{ DOCUMENT_PERSON : has_people
+PERSON ||--o{ DOCUMENT_PERSON : appears_in
+PERSON_ROLE ||--o{ DOCUMENT_PERSON : labels
+DOCUMENT ||--o{ JOB : has_jobs
+DOCUMENT ||--o{ SOURCE : contains_pages
+JOB ||--o{ JOB_SOURCE : executes
+SOURCE ||--o{ JOB_SOURCE : processed_in
+JOB_SOURCE ||--o{ EXECUTION_ATTEMPT : projects
+SOURCE ||--o{ PROCESSING_ARTIFACT : derives
+EXECUTION_ATTEMPT ||--o{ PROCESSING_ARTIFACT : produces
+```
+
+## Domain Invariants and Provenance Rules
+
+### Page-Level Execution and AI Outputs
+
+- Every single page execution by an AI model produces a dedicated `JOB_SOURCE` record.
+- Every `JOB` stores the frozen prompt identifier, prompt text, and hyperparameters used at submission time.
+- `JOB_SOURCE.raw_api_response` is a compatibility projection containing an SDK-serialized OpenRouter response
+  snapshot. It is neither the exact HTTP body nor the native upstream-provider response.
+- Every new provider call creates an immutable `EXECUTION_ATTEMPT` containing the frozen request manifest,
+  exact OpenRouter-boundary response bytes when received, safe transport metadata, SDK snapshot, normalized
+  metadata, timing, and outcome.
+- `EXECUTION_ATTEMPT(job_id, source_id, attempt_number)` is unique; retries increment the persisted attempt number.
+- Historical `JOB_SOURCE` rows without an `EXECUTION_ATTEMPT` remain SDK snapshots and are explicitly labeled as
+  lacking transport evidence.
+- `SOURCE.raw_transcription` caches the latest successful machine output for that page.
+
+### Generic Processing Artifacts
+
+- `PROCESSING_ARTIFACT` stores provider-neutral versioned derived outputs.
+- Exactly one of `inline_payload` and `external_reference` is populated.
+- Externally stored artifacts use application-managed relative references and are verified by SHA-256 and byte size.
+- Coordinate metadata declares units, origin, dimensions, and transformations when geometry is present.
+
+### Image Storage and Integrity
+
+- Binary images are stored on disk; `SOURCE.file_path` stores the persisted path.
+- `SOURCE.file_hash` stores a SHA-256 digest.
+- `SOURCE.file_size_bytes` stores the original file size.
+
+### Page Ordering and Revisions
+
+- `SOURCE.page_number` dictates page ordering within a document.
+- `SOURCE.raw_transcription` remains immutable machine output.
+- `SOURCE.revised_text` stores human edits and is the preferred display value when present.
+
+### Document-Person Role Governance
+
+- Documents support zero, one, or many people per relationship role.
+- Relationship roles are defined by `PERSON_ROLE` rather than hardcoded columns.
+- `DOCUMENT_PERSON` must be unique for `(document_id, person_id, role_id)`.
+- Relationship writes must be deterministic and use explicit add/remove link intent.
+
+### Document Type Governance
+
+- Every document type is defined by `DOCUMENT_TYPE`.
+- `DOCUMENT_TYPE.id` is the sole machine identity.
+- `DOCUMENT_TYPE.label` is mutable display text and is unique after trimming and case normalization.
+- `DOCUMENT_TYPE.normalized_label` stores the normalized uniqueness key.
+- Inactive types remain valid for historical rows but should be excluded from default selection UIs.
+
+## Constraint Summary
+
+- `DOCUMENT_TYPE.normalized_label` is unique.
+- `PERSON_ROLE.code` is unique.
+- `DOCUMENT_PERSON(document_id, person_id, role_id)` is unique.
+
+## Indexing Guidance
+
+- `document(document_type_id)`
+- `document_person(document_id)`
+- `document_person(person_id)`
+- `document_person(role_id)`
+- `source(document_id, page_number)`
+- `job(document_id, status)`
+- `job_source(job_id)`
+- `job_source(source_id)`
+
+## Related Local References
+
+- [System Overview](index_v4.md)
+- [System Architecture](architecture_v4.md)
+- [System Requirements](requirements_v4.md)
+- [Error Handling Policy](error_handling_v4.md)

docs/ver4/scope_boundary_v4.md

@@ -0,0 +1,89 @@
+# V4 Scope Boundary
+
+This document defines the scope for the transition from the current repository state to the Version 4 project definition.
+
+## Purpose
+
+Define what this revision includes, what it intentionally excludes, and what migration rules govern the transition work.
+
+## In Scope
+
+### 1. Relationship Model
+
+- Extensible role taxonomy for document-person relationships.
+- Many-to-many document-person links with many people per role.
+- Set-based add/remove synchronization for document-person updates.
+
+### 2. Document Type Governance
+
+- Registry-driven `DocumentType` model with UUID identity, unique labels, and controlled selection.
+- Minimal rollout for the current corpus with no alias helper table.
+
+### 3. UI and API Behavior
+
+- Grouped role links on document and person views.
+- Multi-role relationship editing on document create/edit flows.
+- Role-aware API retrieval and write behavior.
+- Additive API evolution with explicit deprecations.
+
+### 4. Verification
+
+- Tests for many-per-role behavior.
+- Tests for set-based relationship mutation behavior.
+- Tests for document and person delete/link cleanup regressions.
+
+## Out of Scope
+
+- Suggested versus asserted relationship states.
+- Suggestion storage, review, acceptance, or rejection workflows.
+- Automatic relationship extraction or recommendation features.
+- Full entity resolution or identity merge across all people.
+- Automated semantic document type classification.
+- Redesign of the core transcription execution model.
+
+## Locked Design Decisions
+
+### A. Role Extensibility Mechanism
+
+- Use registry tables for relationship roles.
+
+### B. API Compatibility Strategy
+
+- Use additive API evolution.
+- In development mode, the current revision is authoritative.
+- Deprecations should be explicit and short-lived.
+
+### C. Document Type Rollout Strategy
+
+- Use a minimal registry rollout for the current corpus.
+- Do not introduce a `document_type_alias` helper table.
+
+### D. Database Change Policy
+
+- Future schema changes are non-destructive by default.
+- Exception: `document_type` text may be replaced by `document_type_id` without migrating the legacy text values.
+- Exception: `document_person` links may be recreated manually.
+
+## Compatibility and Rollout
+
+- Preserve existing repository behavior where unaffected by the V4 scope.
+- Treat scope boundary and implementation plan as the only transition documents.
+- Treat core V4 documents as the authoritative project definition once rewritten.
+
+## Exit Criteria for Scope Freeze
+
+V4 scope is considered frozen when:
+
+- Relationship model and document-type governance are approved.
+- Relationship model and document-type governance are approved.
+- Additive API change list and deprecation schedule are approved.
+- Migration exceptions are explicitly acknowledged.
+
+## Core V4 Documents
+
+1. `docs/ver4/index_v4.md`
+2. `docs/ver4/requirements_v4.md`
+3. `docs/ver4/schema_v4.md`
+4. `docs/ver4/architecture_v4.md`
+5. `docs/ver4/error_handling_v4.md`
+6. `docs/ver4/implementation_plan_v4.md`

prompts/README.md

@@ -5,9 +5,11 @@ This directory stores transcription prompts as individual Markdown artifacts.
 ## Conventions
 - Keep one prompt per file.
 - Use stable, descriptive snake_case file names.
+- Store prompt files directly in this directory; nested paths are rejected.
 - Prefer incremental edits to a single prompt per change for clean history.
 - Keep prompts human-readable and policy-focused.
 - Do not store secrets in prompt files.
+- Runtime jobs snapshot prompt text, SHA-256 provenance, and sampling configuration.
 
 ## Current Prompt
 - `transcribe_document.md`: baseline verbatim transcription policy for historical documents.

prompts/system.txt

@@ -1,10 +0,0 @@
-You are an assistant that may call tools.
-
-Tool safety rules:
-1) Tool arguments MUST be strict JSON matching the schema exactly.
-2) Never place disallowed, sensitive, explicit, or policy-violating text directly into tool arguments.
-3) If user content may be unsafe, first produce a brief neutral summary and pass only that summary.
-4) Prefer IDs, enums, booleans, and short fields over raw free-form text.
-5) Keep all string arguments <= 300 chars unless schema says otherwise.
-6) If you cannot safely provide valid tool args, do not call the tool; respond with "NO_TOOL_CALL" and explain briefly.
-7) Never include markdown/code fences in tool arguments.

prompts/transcribe_document.md

@@ -46,6 +46,16 @@ Do not summarize. Do not paraphrase. Do not modernize style.
 - Signal location before the note text.
 - Example form: `[written in left margin: ...]`
 
+### Printed and handwritten text
+- Preserve printed and handwritten text together in their original reading context.
+- On mixed documents such as completed forms, leave printed labels and instructions unmarked.
+- Wrap handwritten entries in `[handwritten: ...]`.
+- Mark handwritten signatures as `[handwritten signature: ...]`.
+- If the main body is entirely handwritten, add `[document body handwritten]` once at the beginning rather than marking every line.
+- Mark later notes or uncertain additions as `[handwritten annotation: ...]`.
+- When authorship is unclear, use `[handwritten annotation, author uncertain: ...]`.
+- Do not infer authorship, writing date, or whether different handwriting belongs to different people unless explicitly evident.
+
 ### Line-break hyphenation
 - Rejoin words split across line breaks when they are clearly one word.
 - Remove only line-break hyphens used for wrapping.
@@ -70,3 +80,4 @@ Before finalizing, ensure:
 2. Uncertain/illegible areas are explicitly marked.
 3. Crossed-out and inserted text are preserved with required tags.
 4. Structure/ordering is preserved as faithfully as possible.
+5. Handwriting is identified using the mixed-text conventions without separating it from its printed context.

pyproject.toml

@@ -12,22 +12,37 @@ description = "Historical document transcription system"
 readme = "README.md"
 requires-python = ">=3.12"
 dependencies = [
+    "aiosqlite>=0.21.0",
+    "asyncpg>=0.31.0",
     "fastapi>=0.138.0",
     "nicegui==3.13.0",
     "openrouter>=0.7.0",
+    "psycopg2-binary>=2.9.12",
     "pydantic>=2.13.4",
     "pydantic-settings>=2.9.1",
     "sqlmodel>=0.0.25",
 ]
 
-[project.optional-dependencies]
+
+[dependency-groups]
 dev = [
     "pytest>=8.0",
     "pytest-asyncio>=0.25",
+    "httpx2>=2.5.0",
+    "ipykernel>=7.3.0",
+    "ipywidgets>=8.1.8",
+    "pre-commit>=4.6.0",
+    "rich>=15.0.0",
+    "ruff>=0.15.20",
+    "ty>=0.0.54",
 ]
 
 [tool.pytest.ini_options]
 addopts = "--strict-markers -q"
+asyncio_mode = "strict"
+filterwarnings = [
+    "error:coroutine .* was never awaited:RuntimeWarning",
+]
 markers = [
     "unit: pure logic tests with no external dependencies",
     "integration: tests that touch framework or database contracts",

ruff.toml

@@ -0,0 +1,62 @@
+line-length = 120
+indent-width = 4
+target-version = "py313"
+
+exclude = [
+    ".venv",
+    ".devenv",
+    ".git",
+    ".vscode",
+    "build",
+    "site",
+    "__pycache__",
+]
+
+[lint]
+preview = true
+
+extend-select = [
+    "ARG",      # https://docs.astral.sh/ruff/rules/#flake8-unused-arguments-arg
+	"B",        # https://docs.astral.sh/ruff/rules/#flake8-bugbear-b
+	"C4",       # https://docs.astral.sh/ruff/rules/#flake8-comprehensions-c4
+    "DOC102",   # https://docs.astral.sh/ruff/rules/docstring-extraneous-parameter/
+    "DOC202",   # https://docs.astral.sh/ruff/rules/docstring-extraneous-returns/
+    "DOC403",   # https://docs.astral.sh/ruff/rules/docstring-extraneous-yields/
+    "DOC502",   # https://docs.astral.sh/ruff/rules/docstring-extraneous-exception/
+	"E", "W",   # https://docs.astral.sh/ruff/rules/#pycodestyle-e-w
+	"F",        # https://docs.astral.sh/ruff/rules/#pyflakes-f
+    "FURB",     # https://docs.astral.sh/ruff/rules/#refurb-furb
+	"I",        # https://docs.astral.sh/ruff/rules/#isort-i
+    "N",        # https://docs.astral.sh/ruff/rules/#pep8-naming-n
+    "PD",       # https://docs.astral.sh/ruff/rules/#pandas-vet-pd
+    "PTH",      # https://docs.astral.sh/ruff/rules/#flake8-use-pathlib-pth
+	"UP",       # https://docs.astral.sh/ruff/rules/#pyupgrade-up
+	"SIM",      # https://docs.astral.sh/ruff/rules/#flake8-simplify-sim
+    "PLR0202",  # https://docs.astral.sh/ruff/rules/no-classmethod-decorator/
+    "PLR0203",  # https://docs.astral.sh/ruff/rules/no-staticmethod-decorator/
+    "PLR0206",  # https://docs.astral.sh/ruff/rules/property-with-parameters/
+    "PLR0915",  # https://docs.astral.sh/ruff/rules/too-many-statements/
+    "PLR1702",  # https://docs.astral.sh/ruff/rules/too-many-nested-blocks/
+    "TRY002",
+]
+extend-fixable = ["ALL"]
+ignore = [
+    "UP046",
+    "UP047",
+]
+
+[lint.extend-per-file-ignores]
+"*.ipynb" = [
+    "F401", # unused imports
+    "F841", # unused local variable
+    "F821", # undefined name in exploratory notebook cells
+]
+
+[lint.isort]
+force-single-line = true
+
+[format]
+quote-style = "double"
+indent-style = "space"
+skip-magic-trailing-comma = false
+line-ending = "auto"

src/transcription/__main__.py

@@ -0,0 +1,27 @@
+import uvicorn
+from fastapi import FastAPI
+
+from .app import create_app
+from .config import parse_cli_settings
+
+
+def create_cli_app() -> FastAPI:
+    """Create an app from CLI settings for Uvicorn's reload process."""
+    return create_app(settings=parse_cli_settings())
+
+
+def main() -> None:
+    settings = parse_cli_settings()
+    application = "transcription.__main__:create_cli_app" if settings.reload else create_app(settings=settings)
+    uvicorn.run(
+        application,
+        factory=settings.reload,
+        host=settings.host,
+        port=settings.port,
+        log_level=settings.log_level,
+        reload=settings.reload,
+    )
+
+
+if __name__ == "__main__":
+    main()

src/transcription/api/errors.py

@@ -34,12 +34,6 @@ def _status_for(error: AppError) -> int:
 def register_error_handlers(app: FastAPI) -> None:
     """Register API exception handlers on the app."""
 
-    @app.exception_handler(AccessDeniedError)
-    async def access_denied_handler(_request: Request, exc: AccessDeniedError) -> JSONResponse:
-        envelope = build_error_envelope(exc)
-        headers = {"WWW-Authenticate": "Basic"} if exc.should_challenge else None
-        return JSONResponse(status_code=401, content=envelope.__dict__, headers=headers)
-
     @app.exception_handler(AppError)
     async def app_error_handler(_request: Request, exc: AppError) -> JSONResponse:
         envelope = build_error_envelope(exc)

src/transcription/api/routes.py

@@ -1,161 +0,0 @@
-"""Functional API routes for jobs, revisions, search, and export."""
-
-from __future__ import annotations
-
-from uuid import UUID
-
-from fastapi import APIRouter
-from pydantic import BaseModel
-from pydantic import Field
-
-from transcription.services.library import accept_revision
-from transcription.services.library import add_revision
-from transcription.services.library import export_transcripts
-from transcription.services.library import get_job_detail
-from transcription.services.library import list_jobs
-from transcription.services.library import list_revisions
-from transcription.services.library import search_accepted_transcripts
-
-router = APIRouter(prefix="/api", tags=["transcription"])
-
-
-class CreateRevisionRequest(BaseModel):
-    text: str = Field(min_length=1)
-    source: str = "user"
-    accepted: bool = False
-
-
-@router.get("/jobs")
-def get_jobs() -> list[dict[str, str]]:
-    jobs = list_jobs()
-    return [
-        {
-            "id": str(job.id),
-            "document_id": str(job.document_id),
-            "status": job.status.value,
-            "created_at": job.created_at.isoformat(),
-            "updated_at": job.updated_at.isoformat(),
-        }
-        for job in jobs
-    ]
-
-
-@router.get("/jobs/{job_id}")
-def get_job(job_id: UUID) -> dict[str, object | None]:
-    detail = get_job_detail(job_id=job_id)
-    return {
-        "job": {
-            "id": str(detail.job.id),
-            "document_id": str(detail.job.document_id),
-            "status": detail.job.status.value,
-            "created_at": detail.job.created_at.isoformat(),
-            "updated_at": detail.job.updated_at.isoformat(),
-        },
-        "document": (
-            {
-                "id": str(detail.document.id),
-                "filename": detail.document.filename,
-                "file_path": detail.document.file_path,
-            }
-            if detail.document is not None
-            else None
-        ),
-        "transcript": (
-            {
-                "id": str(detail.transcript.id),
-                "text": detail.transcript.text,
-                "error_detail": detail.transcript.error_detail,
-                "created_at": detail.transcript.created_at.isoformat(),
-            }
-            if detail.transcript is not None
-            else None
-        ),
-        "accepted_revision": (
-            {
-                "id": str(detail.accepted_revision.id),
-                "revision_number": detail.accepted_revision.revision_number,
-                "text": detail.accepted_revision.text,
-                "source": detail.accepted_revision.source,
-                "created_at": detail.accepted_revision.created_at.isoformat(),
-            }
-            if detail.accepted_revision is not None
-            else None
-        ),
-    }
-
-
-@router.get("/jobs/{job_id}/revisions")
-def get_job_revisions(job_id: UUID) -> list[dict[str, object]]:
-    revisions = list_revisions(job_id=job_id)
-    return [
-        {
-            "id": str(revision.id),
-            "job_id": str(revision.job_id),
-            "revision_number": revision.revision_number,
-            "text": revision.text,
-            "source": revision.source,
-            "accepted": revision.accepted,
-            "created_at": revision.created_at.isoformat(),
-        }
-        for revision in revisions
-    ]
-
-
-@router.post("/jobs/{job_id}/revisions")
-def create_job_revision(job_id: UUID, payload: CreateRevisionRequest) -> dict[str, object]:
-    revision = add_revision(
-        job_id=job_id,
-        text=payload.text,
-        source=payload.source,
-        accepted=payload.accepted,
-    )
-    return {
-        "id": str(revision.id),
-        "job_id": str(revision.job_id),
-        "revision_number": revision.revision_number,
-        "text": revision.text,
-        "source": revision.source,
-        "accepted": revision.accepted,
-        "created_at": revision.created_at.isoformat(),
-    }
-
-
-@router.post("/revisions/{revision_id}/accept")
-def accept_job_revision(revision_id: UUID) -> dict[str, object]:
-    revision = accept_revision(revision_id=revision_id)
-    return {
-        "id": str(revision.id),
-        "job_id": str(revision.job_id),
-        "revision_number": revision.revision_number,
-        "text": revision.text,
-        "source": revision.source,
-        "accepted": revision.accepted,
-        "created_at": revision.created_at.isoformat(),
-    }
-
-
-@router.get("/search")
-def search(query: str) -> list[dict[str, object]]:
-    results = search_accepted_transcripts(query=query)
-    return [
-        {
-            "revision_id": str(revision.id),
-            "job_id": str(revision.job_id),
-            "revision_number": revision.revision_number,
-            "text": revision.text,
-            "source": revision.source,
-            "accepted": revision.accepted,
-            "created_at": revision.created_at.isoformat(),
-        }
-        for revision in results
-    ]
-
-
-@router.get("/export")
-def export(accepted_only: bool = True) -> dict[str, object]:
-    records = export_transcripts(accepted_only=accepted_only)
-    return {
-        "count": len(records),
-        "accepted_only": accepted_only,
-        "records": records,
-    }

src/transcription/api/v4_documents.py

@@ -0,0 +1,252 @@
+"""Additive V4 API routes for relationship and classification registries."""
+
+from __future__ import annotations
+
+from typing import Annotated
+from uuid import UUID
+
+from fastapi import APIRouter
+from fastapi import Depends
+from fastapi import Request
+from fastapi import Response
+from pydantic import BaseModel
+from pydantic import ConfigDict
+from pydantic import Field
+from pydantic import model_validator
+
+from transcription.db.models import Document
+from transcription.db.models import DocumentPerson
+from transcription.db.models import DocumentType
+from transcription.db.models import PersonRole
+from transcription.services import DocumentService
+from transcription.services import PeopleService
+
+router = APIRouter(prefix="/api/v4", tags=["v4-documents"])
+
+
+class ApiModel(BaseModel):
+    model_config = ConfigDict(extra="forbid", frozen=True, str_strip_whitespace=True)
+
+
+class SelectorRequest(ApiModel):
+    @model_validator(mode="after")
+    def require_exactly_one_selector(self):
+        values = (self.selector_id, self.selector_code)
+        if sum(value is not None for value in values) != 1:
+            raise ValueError(f"Provide exactly one of {self.selector_names[0]} or {self.selector_names[1]}")
+        return self
+
+    @property
+    def selector_id(self) -> UUID | None:
+        raise NotImplementedError
+
+    @property
+    def selector_code(self) -> str | None:
+        raise NotImplementedError
+
+    @property
+    def selector_names(self) -> tuple[str, str]:
+        raise NotImplementedError
+
+
+class DocumentTypeRead(ApiModel):
+    id: UUID
+    label: str
+    is_active: bool
+
+
+class PersonRoleRead(ApiModel):
+    id: UUID
+    code: str
+    label: str
+    is_active: bool
+
+
+class DocumentTypeWriteRequest(ApiModel):
+    document_type_id: UUID
+
+
+class DocumentTypeWriteResponse(ApiModel):
+    document_id: UUID
+    document_type_id: UUID
+
+
+class DocumentPersonWriteRequest(ApiModel):
+    person_id: UUID
+    role_id: UUID | None = None
+    role_code: str | None = Field(default=None, min_length=1, pattern=r"^[a-z0-9_]+$")
+
+    @model_validator(mode="after")
+    def reject_conflicting_role_selectors(self):
+        if self.role_id is not None and self.role_code is not None:
+            raise ValueError("Provide role_id or role_code, not both")
+        return self
+
+
+class DocumentPersonRoleUpdateRequest(SelectorRequest):
+    role_id: UUID | None = None
+    role_code: str | None = Field(default=None, min_length=1, pattern=r"^[a-z0-9_]+$")
+
+    @property
+    def selector_id(self) -> UUID | None:
+        return self.role_id
+
+    @property
+    def selector_code(self) -> str | None:
+        return self.role_code
+
+    @property
+    def selector_names(self) -> tuple[str, str]:
+        return "role_id", "role_code"
+
+
+class DocumentPersonRead(ApiModel):
+    id: UUID
+    document_id: UUID
+    person_id: UUID
+    role_id: UUID | None
+    role_code: str
+    person_name: str | None = None
+
+
+class DocumentPeopleResponse(ApiModel):
+    document_id: UUID
+    links: list[DocumentPersonRead] = Field(default_factory=list)
+
+
+def _document_type_to_read(item: DocumentType) -> DocumentTypeRead:
+    return DocumentTypeRead(
+        id=item.id,
+        label=item.label,
+        is_active=item.is_active,
+    )
+
+
+def _person_role_to_read(item: PersonRole) -> PersonRoleRead:
+    return PersonRoleRead(
+        id=item.id,
+        code=item.code,
+        label=item.label,
+        is_active=item.is_active,
+    )
+
+
+def _document_person_to_read(item: DocumentPerson) -> DocumentPersonRead:
+    role_code = item.role_ref.code if item.role_ref is not None else str(item.role)
+
+    person_name = item.person.full_name if item.person is not None else None
+    return DocumentPersonRead(
+        id=item.id,
+        document_id=item.document_id,
+        person_id=item.person_id,
+        role_id=item.role_id,
+        role_code=role_code,
+        person_name=person_name,
+    )
+
+
+def _document_to_type_response(item: Document) -> DocumentTypeWriteResponse:
+    if item.document_type_id is None:
+        raise ValueError("Document Type assignment did not persist")
+    return DocumentTypeWriteResponse(
+        document_id=item.id,
+        document_type_id=item.document_type_id,
+    )
+
+
+def get_document_service(request: Request) -> DocumentService:
+    """Resolve the document service from app lifespan state when available."""
+    services = getattr(request.app.state, "services", None)
+    if services is not None:
+        return services.documents
+    return DocumentService()
+
+
+def get_people_service(request: Request) -> PeopleService:
+    """Resolve the People service from app lifespan state when available."""
+    services = getattr(request.app.state, "services", None)
+    if services is not None:
+        return services.people
+    return PeopleService()
+
+
+DocumentServiceDependency = Annotated[DocumentService, Depends(get_document_service)]
+PeopleServiceDependency = Annotated[PeopleService, Depends(get_people_service)]
+
+
+@router.get("/document-types", response_model=list[DocumentTypeRead])
+async def list_document_types(
+    service: DocumentServiceDependency,
+    active_only: bool = True,
+) -> list[DocumentTypeRead]:
+    items = await service.list_document_types(active_only=active_only)
+    return [_document_type_to_read(item) for item in items]
+
+
+@router.get("/person-roles", response_model=list[PersonRoleRead])
+async def list_person_roles(
+    service: PeopleServiceDependency,
+    active_only: bool = True,
+) -> list[PersonRoleRead]:
+    items = await service.list_person_roles(active_only=active_only)
+    return [_person_role_to_read(item) for item in items]
+
+
+@router.put("/documents/{document_id}/type", response_model=DocumentTypeWriteResponse)
+async def set_document_type(
+    document_id: UUID,
+    payload: DocumentTypeWriteRequest,
+    service: DocumentServiceDependency,
+) -> DocumentTypeWriteResponse:
+    document = await service.set_document_type(
+        document_id=document_id,
+        document_type_id=payload.document_type_id,
+    )
+    return _document_to_type_response(document)
+
+
+@router.get("/documents/{document_id}/people", response_model=DocumentPeopleResponse)
+async def list_document_people(
+    document_id: UUID,
+    service: PeopleServiceDependency,
+) -> DocumentPeopleResponse:
+    links = await service.list_document_people(document_id=document_id)
+    return DocumentPeopleResponse(document_id=document_id, links=[_document_person_to_read(item) for item in links])
+
+
+@router.post("/documents/{document_id}/people", response_model=DocumentPersonRead)
+async def add_document_person_link(
+    document_id: UUID,
+    payload: DocumentPersonWriteRequest,
+    service: PeopleServiceDependency,
+) -> DocumentPersonRead:
+    link = await service.add_document_person_link(
+        document_id=document_id,
+        person_id=payload.person_id,
+        role_id=payload.role_id,
+        role_code=payload.role_code,
+    )
+    return _document_person_to_read(link)
+
+
+@router.patch("/document-people/{document_person_id}", response_model=DocumentPersonRead)
+async def set_document_person_role(
+    document_person_id: UUID,
+    payload: DocumentPersonRoleUpdateRequest,
+    service: PeopleServiceDependency,
+) -> DocumentPersonRead:
+    link = await service.set_document_person_role(
+        document_person_id=document_person_id,
+        role_id=payload.role_id,
+        role_code=payload.role_code,
+    )
+    return _document_person_to_read(link)
+
+
+@router.delete("/document-people/{document_person_id}", status_code=204)
+async def delete_document_person_link(
+    document_person_id: UUID,
+    service: PeopleServiceDependency,
+) -> Response:
+    await service.remove_document_person_link(document_person_id=document_person_id)
+    return Response(status_code=204)

src/transcription/app.py

@@ -2,94 +2,108 @@
 
 from __future__ import annotations
 
+import logging
+from contextlib import AsyncExitStack
 from contextlib import asynccontextmanager
-from threading import Event
-from threading import Thread
+from datetime import UTC
+from datetime import datetime
+from datetime import timedelta
 
 from fastapi import FastAPI
-from sqlalchemy.ext.asyncio import async_sessionmaker
-from sqlmodel.ext.asyncio.session import AsyncSession
+from fastapi import status
+from fastapi.responses import RedirectResponse
+from fastapi.staticfiles import StaticFiles
 
 from .api.errors import register_error_handlers
 from .api.health import router as health_router
+from .api.v4_documents import router as v4_documents_router
+from .config import Settings
 from .config import configure_logging
 from .config import get_settings
-from .db import cleanup_database
 from .db import create_all
+from .db import dispose_database_runtime
 from .db import initialize_database_runtime
+from .services import ServiceBundle
+from .services.documents import DocumentService
+from .services.jobs import JobService
+from .services.people import PeopleService
+from .services.sources import SourceService
 from .ui import register_pages
-from .worker import run_worker_loop
+from .worker import worker_consumer_lifespan
 
-
-def _start_worker(app: FastAPI) -> None:
-    session_factory: async_sessionmaker[AsyncSession] = app.state.db_session_factory
-    stop_event = Event()
-    worker_thread = Thread(
-        target=run_worker_loop,
-        kwargs={
-            "session_factory": session_factory,
-            "stop_event": stop_event,
-            "poll_interval_seconds": 1.0,
-        },
-        daemon=True,
-    )
-    worker_thread.start()
-    app.state.worker_stop_event = stop_event
-    app.state.worker_thread = worker_thread
-
-
-def _stop_worker(app: FastAPI) -> None:
-    stop_event = getattr(app.state, "worker_stop_event", None)
-    worker_thread = getattr(app.state, "worker_thread", None)
-
-    if stop_event is not None:
-        stop_event.set()
-    if worker_thread is not None:
-        worker_thread.join(timeout=2.0)
+logger = logging.getLogger(__name__)
 
 
 @asynccontextmanager
 async def _lifespan(app: FastAPI):
-    configure_logging()
-
-    settings = get_settings()
+    settings = getattr(app.state, "settings", None) or get_settings()
+    configure_logging(settings)
     app.state.settings = settings
-    runtime = initialize_database_runtime(settings=settings)
-    app.state.db_engine = runtime.engine
-    app.state.db_session_factory = runtime.session_factory
+    app.state.runtime = initialize_database_runtime(settings=settings)
+    session_factory = app.state.runtime.session_factory
+    app.state.services = ServiceBundle(
+        documents=DocumentService(session_factory=session_factory, settings=settings),
+        sources=SourceService(session_factory=session_factory, settings=settings),
+        jobs=JobService(session_factory=session_factory, settings=settings),
+        people=PeopleService(session_factory=session_factory, settings=settings),
+    )
 
     if settings.should_bootstrap_schema:
-        await create_all(engine=runtime.engine)
+        await create_all(engine=app.state.runtime.engine)
 
     settings.upload_dir.mkdir(parents=True, exist_ok=True)
     settings.prompt_dir.mkdir(parents=True, exist_ok=True)
 
-    _start_worker(app)
-    try:
+    await _recover_stale_processing_jobs(app)
+
+    async with AsyncExitStack() as stack:
+        stack.push_async_callback(dispose_database_runtime)
+        stop_event, worker_notifier = await stack.enter_async_context(
+            worker_consumer_lifespan(
+                session_factory=app.state.runtime.session_factory,
+                poll_interval_seconds=1.0,
+            )
+        )
+        app.state.worker_stop_event = stop_event
+        app.state.worker_notifier = worker_notifier
         yield
-    finally:
-        _stop_worker(app)
-        await cleanup_database()
 
 
-def create_app() -> FastAPI:
+async def _recover_stale_processing_jobs(app: FastAPI) -> None:
+    """Re-queue stale processing jobs at startup.
+
+    Any job left in PROCESSING longer than the configured provider timeout is
+    assumed orphaned and moved back to QUEUED before the worker starts.
+    """
+    settings = app.state.settings
+    stale_before = datetime.now(UTC) - timedelta(seconds=settings.worker_provider_timeout_seconds)
+    job_service = JobService(session_factory=app.state.runtime.session_factory)
+    recovered = await job_service.requeue_stale_processing_jobs(stale_before=stale_before)
+    if recovered > 0:
+        logger.warning("Recovered %s stale processing job(s) at startup", recovered)
+
+
+def create_app(settings: Settings | None = None) -> FastAPI:
     """Create and configure the FastAPI application."""
     app = FastAPI(title="Transcription", lifespan=_lifespan)
+    active_settings = settings or get_settings()
+    app.state.settings = active_settings
+    app.mount(
+        "/uploads",
+        StaticFiles(directory=active_settings.upload_dir, check_dir=False),
+        name="uploads",
+    )
 
-    @app.middleware("http")
-    async def operator_access_middleware(request: Request, call_next):
-        settings = get_settings()
-        try:
-            enforce_request_access(request=request, settings=settings)
-        except AccessDeniedError as exc:
-            envelope = build_error_envelope(exc)
-            headers = {"WWW-Authenticate": "Basic"} if exc.should_challenge else None
-            return JSONResponse(status_code=401, content=envelope.__dict__, headers=headers)
+    @app.get("/", include_in_schema=False)
+    async def root_redirect() -> RedirectResponse:
+        return RedirectResponse(url="/ui/homepage", status_code=status.HTTP_307_TEMPORARY_REDIRECT)
 
-        return await call_next(request)
+    @app.get("/ui", include_in_schema=False)
+    async def ui_redirect() -> RedirectResponse:
+        return RedirectResponse(url="/ui/homepage", status_code=status.HTTP_307_TEMPORARY_REDIRECT)
 
     register_error_handlers(app)
-    register_pages(app)
     app.include_router(health_router)
-    app.include_router(transcription_router)
+    app.include_router(v4_documents_router)
+    register_pages(app)
     return app

src/transcription/app_state.py

@@ -0,0 +1,39 @@
+"""Helpers for accessing lifespan-owned application state resources."""
+
+from __future__ import annotations
+
+from fastapi import FastAPI
+from sqlalchemy.ext.asyncio import async_sessionmaker
+from sqlmodel.ext.asyncio.session import AsyncSession
+
+from transcription.db.runtime import DatabaseRuntime
+from transcription.db.session import get_session_factory
+from transcription.worker import WorkerNotifier
+from transcription.worker import resolve_worker_notifier
+
+
+def resolve_database_runtime(state: object) -> DatabaseRuntime | None:
+    """Return database runtime from app-like state objects when available."""
+    runtime = getattr(state, "runtime", None)
+    return runtime if isinstance(runtime, DatabaseRuntime) else None
+
+
+def require_database_runtime(state: object) -> DatabaseRuntime:
+    """Return database runtime or raise when app lifespan has not initialized it."""
+    runtime = resolve_database_runtime(state)
+    if runtime is None:
+        raise RuntimeError("Database runtime is not initialized on application state")
+    return runtime
+
+
+def resolve_session_factory(state: object) -> async_sessionmaker[AsyncSession]:
+    """Return DB session factory from state when available, otherwise shared runtime."""
+    runtime = resolve_database_runtime(state)
+    if runtime is not None:
+        return runtime.session_factory
+    return get_session_factory()
+
+
+def get_worker_notifier(app: FastAPI) -> WorkerNotifier:
+    """Return app worker notifier, or a no-op fallback when unavailable."""
+    return resolve_worker_notifier(app.state)

src/transcription/benchmarking.py

@@ -0,0 +1,102 @@
+"""Private-corpus benchmark contracts and deterministic text scoring."""
+
+from __future__ import annotations
+
+from uuid import UUID
+
+from pydantic import BaseModel
+from pydantic import ConfigDict
+from pydantic import Field
+
+
+class BenchmarkModel(BaseModel):
+    model_config = ConfigDict(extra="forbid", frozen=True)
+
+
+class BenchmarkItem(BenchmarkModel):
+    """One private benchmark item referenced by archival identity."""
+
+    source_id: UUID
+    source_digest_sha256: str = Field(pattern=r"^[0-9a-f]{64}$")
+    categories: frozenset[str] = Field(min_length=1)
+    reference_transcription: str = Field(min_length=1)
+
+
+class BenchmarkManifest(BenchmarkModel):
+    """Versioned private benchmark definition without copied source media."""
+
+    schema_name: str = "transcription.private-benchmark"
+    schema_version: str = "1"
+    name: str = Field(min_length=1)
+    items: tuple[BenchmarkItem, ...] = Field(min_length=1)
+
+
+class EditorialAssessment(BenchmarkModel):
+    """Manually reviewed errors not represented adequately by CER or WER."""
+
+    omissions: int = Field(default=0, ge=0)
+    inventions: int = Field(default=0, ge=0)
+    silent_normalizations: int = Field(default=0, ge=0)
+    uncertainty_errors: int = Field(default=0, ge=0)
+    layout_errors: int = Field(default=0, ge=0)
+
+
+class BenchmarkScore(BenchmarkModel):
+    """Measured score for one preserved execution attempt."""
+
+    execution_attempt_id: UUID
+    character_error_rate: float = Field(ge=0)
+    word_error_rate: float = Field(ge=0)
+    character_edits: int = Field(ge=0)
+    word_edits: int = Field(ge=0)
+    reference_characters: int = Field(ge=0)
+    reference_words: int = Field(ge=0)
+    assessment: EditorialAssessment
+    latency_ms: int = Field(ge=0)
+    cost_usd: float | None = Field(default=None, ge=0)
+
+
+def score_transcription(
+    *,
+    execution_attempt_id: UUID,
+    reference: str,
+    candidate: str,
+    assessment: EditorialAssessment,
+    latency_ms: int,
+    cost_usd: float | None = None,
+) -> BenchmarkScore:
+    """Score literal text without case-folding or silent normalization."""
+    reference_words = reference.split()
+    candidate_words = candidate.split()
+    character_edits = _levenshtein(list(reference), list(candidate))
+    word_edits = _levenshtein(reference_words, candidate_words)
+    return BenchmarkScore(
+        execution_attempt_id=execution_attempt_id,
+        character_error_rate=character_edits / max(1, len(reference)),
+        word_error_rate=word_edits / max(1, len(reference_words)),
+        character_edits=character_edits,
+        word_edits=word_edits,
+        reference_characters=len(reference),
+        reference_words=len(reference_words),
+        assessment=assessment,
+        latency_ms=latency_ms,
+        cost_usd=cost_usd,
+    )
+
+
+def _levenshtein(reference: list[str], candidate: list[str]) -> int:
+    if len(reference) < len(candidate):
+        reference, candidate = candidate, reference
+    previous = list(range(len(candidate) + 1))
+    for reference_index, reference_value in enumerate(reference, start=1):
+        current = [reference_index]
+        for candidate_index, candidate_value in enumerate(candidate, start=1):
+            current.append(
+                min(
+                    current[-1] + 1,
+                    previous[candidate_index] + 1,
+                    previous[candidate_index - 1] + (reference_value != candidate_value),
+                )
+            )
+        previous = current
+    return previous[-1]

src/transcription/config.py

@@ -6,11 +6,19 @@ are resolved by the provider adapters, not here.
 """
 
 import logging.config
-from contextvars import ContextVar
+from collections.abc import Sequence
 from enum import StrEnum
+from functools import cache
 from pathlib import Path
+from typing import Annotated
+from typing import Any
 from typing import Literal
 
+from pydantic import BaseModel
+from pydantic import ConfigDict
+from pydantic import Field
+from pydantic import SecretStr
+from pydantic import StringConstraints
 from pydantic_settings import BaseSettings
 from pydantic_settings import SettingsConfigDict
 
@@ -21,70 +29,111 @@ class Provider(StrEnum):
     OPENROUTER = "openrouter"
 
 
+NonEmptyStr = Annotated[str, StringConstraints(strip_whitespace=True, min_length=1)]
+PromptFilename = Annotated[str, StringConstraints(strip_whitespace=True, min_length=1, pattern=r"^[^/\\]+$")]
+Probability = Annotated[float, Field(ge=0.0, le=1.0)]
+Temperature = Annotated[float, Field(ge=0.0, le=2.0)]
+
+
+class SqliteSettings(BaseModel):
+    model_config = ConfigDict(extra="forbid", frozen=True)
+
+    driver: Literal["sqlite"] = "sqlite"
+    path: NonEmptyStr = "app.db"
+
+
+class PostgresSettings(BaseModel):
+    model_config = ConfigDict(extra="forbid", frozen=True)
+
+    driver: Literal["postgres"] = "postgres"
+    host: NonEmptyStr
+    port: int = Field(default=5432, ge=1, le=65535)
+    database: NonEmptyStr
+    user: NonEmptyStr
+    password: SecretStr
+
+
+DatabaseSettings = Annotated[
+    SqliteSettings | PostgresSettings,
+    Field(discriminator="driver"),
+]
+
+
 class Settings(BaseSettings):
     model_config = SettingsConfigDict(
         env_file=".env",
         env_file_encoding="utf-8",
         extra="ignore",
+        env_nested_delimiter="__",
+        cli_implicit_flags=True,
+        cli_kebab_case=True,
+        frozen=True,
     )
 
+    # --- NiceGUI Server ---
+    host: str = "0.0.0.0"
+    port: int = 8000
+    log_level: Literal["critical", "error", "warning", "info", "debug", "trace"] = "info"
+    reload: bool = False
+
     # --- AI provider ---
     provider: Provider = Provider.OPENROUTER
-    openrouter_api_key: str
-    provider_model: str | None = None
-    openrouter_http_referer: str | None = None
-    openrouter_app_title: str | None = None
+    openrouter_api_key: SecretStr
+    provider_model: NonEmptyStr | None = None
+    openrouter_http_referer: NonEmptyStr | None = None
+    openrouter_app_title: NonEmptyStr | None = None
+    default_prompt_name: PromptFilename = "transcribe_document.md"
+    transcription_temperature: Temperature | None = None
+    transcription_top_p: Probability | None = None
 
     # --- runtime environment ---
     environment: Literal["development", "test", "production"] = "development"
 
     # --- persistence ---
-    database_url: str = "sqlite:///./transcription.db"
-    bootstrap_schema_on_startup: bool | None = None
-    migration_auto_apply_on_startup: bool = False
-    validate_schema_on_startup: bool = True
+    database: DatabaseSettings = Field(default_factory=SqliteSettings)
+    bootstrap_schema_on_startup: bool = False
+    sqlite_check_same_thread: bool = False
 
     # --- filesystem paths ---
     upload_dir: Path = Path("./uploads")
     prompt_dir: Path = Path("./prompts")
-
-    # --- upload safety ---
-    max_upload_bytes: int = 15 * 1024 * 1024
-
-    # --- single-operator access control ---
-    operator_access_enabled: bool = False
-    operator_username: str = "operator"
-    operator_password: str | None = None
+    artifact_dir: Path = Path("./data/artifacts")
+    artifact_inline_threshold_bytes: int = Field(default=1_048_576, ge=1)
 
     # --- worker reliability ---
-    worker_max_retries: int = 0
-    worker_retry_backoff_seconds: float = 0.0
+    worker_max_retries: int = Field(default=0, ge=0)
+    worker_retry_backoff_seconds: float = Field(default=0.0, ge=0.0)
+    worker_provider_timeout_seconds: float = Field(default=20.0, gt=0.0, le=20.0)
+    worker_min_transcription_chars: int = Field(default=0, ge=0)
+    worker_min_transcription_lines: int = Field(default=0, ge=0)
+    worker_fail_on_finish_reason_length: bool = False
 
     @property
     def should_bootstrap_schema(self) -> bool:
         """Return whether startup should auto-create schema for this environment."""
-        if self.bootstrap_schema_on_startup is not None:
+        if "bootstrap_schema_on_startup" in self.model_fields_set:
             return self.bootstrap_schema_on_startup
         return self.environment in {"development", "test"}
 
 
-_settings: ContextVar[Settings | None] = ContextVar("settings", default=None)
+@cache
+def get_settings(**kwargs: Any) -> Settings:
+    """Load cached settings without reading process CLI arguments."""
+    return Settings(_cli_parse_args=False, **kwargs)  # pyright: ignore[reportCallIssue]
 
 
-def get_settings() -> Settings:
-    settings = _settings.get()
-    if settings is None:
-        settings = Settings()  # pyright: ignore[reportCallIssue]
-        _settings.set(settings)
-    return settings
+def parse_cli_settings(args: Sequence[str] | None = None) -> Settings:
+    """Load settings with CLI arguments at the executable boundary."""
+    cli_args = True if args is None else list(args)
+    return Settings(_cli_parse_args=cli_args)  # pyright: ignore[reportCallIssue]
 
 
-LOGGING_CONFIG: dict[str, object] = {
+LOGGING_CONFIG: dict[str, Any] = {
     "version": 1,
     "disable_existing_loggers": False,
     "formatters": {
         "standard": {
-            "format": "%(asctime)s | %(levelname)-8s | %(name)s | %(message)s",
+            "format": "%(asctime)s %(levelname)-8s | %(message)s",
             "datefmt": "%Y-%m-%d %H:%M:%S",
         }
     },
@@ -109,7 +158,10 @@ LOGGING_CONFIG: dict[str, object] = {
 }
 
 
-def configure_logging() -> None:
+def configure_logging(settings: Settings | None = None) -> None:
     """Configure root logging once at startup."""
-    logging.config.dictConfig(LOGGING_CONFIG)
+    cfg = LOGGING_CONFIG.copy()
+    active_settings = settings or get_settings()
+    cfg["loggers"]["transcription"]["level"] = active_settings.log_level.upper()
+    logging.config.dictConfig(cfg)
     logger.debug("Logging configured")

src/transcription/db.py

@@ -1,149 +0,0 @@
-"""Database runtime ownership, schema bootstrap, and session access.
-
-V1 moves database resource ownership to explicit runtime initialization so
-startup/shutdown behavior is predictable and lifespan-managed.
-"""
-
-from __future__ import annotations
-
-import contextlib
-import logging
-from collections.abc import AsyncGenerator
-from dataclasses import dataclass
-
-from sqlalchemy import inspect
-from sqlalchemy import text
-from sqlalchemy.engine import Connection
-from sqlalchemy.ext.asyncio import AsyncEngine
-from sqlalchemy.ext.asyncio import async_sessionmaker
-from sqlalchemy.ext.asyncio import create_async_engine
-from sqlmodel import SQLModel
-from sqlmodel.ext.asyncio.session import AsyncSession
-
-from .config import Settings
-from .config import get_settings
-
-logger = logging.getLogger(__name__)
-
-
-@dataclass(frozen=True)
-class DatabaseRuntime:
-    """Database runtime resources owned by app lifespan."""
-
-    engine: AsyncEngine
-    session_factory: async_sessionmaker[AsyncSession]
-
-
-_runtime: DatabaseRuntime | None = None
-
-
-def _to_async_database_url(database_url: str) -> str:
-    """Normalize configured database URL to an async SQLAlchemy driver URL."""
-    if database_url.startswith("sqlite://") and not database_url.startswith("sqlite+aiosqlite://"):
-        return database_url.replace("sqlite://", "sqlite+aiosqlite://", 1)
-    if database_url.startswith("postgresql://") and not database_url.startswith("postgresql+asyncpg://"):
-        return database_url.replace("postgresql://", "postgresql+asyncpg://", 1)
-    return database_url
-
-
-def _build_engine(settings: Settings) -> AsyncEngine:
-    database_url = _to_async_database_url(settings.database_url)
-    connect_args: dict[str, object] = {}
-    if database_url.startswith("sqlite"):
-        connect_args["check_same_thread"] = False
-    return create_async_engine(
-        url=database_url,
-        echo=False,
-        pool_pre_ping=True,
-        connect_args=connect_args,
-    )
-
-
-def initialize_database_runtime(*, settings: Settings | None = None) -> DatabaseRuntime:
-    """Initialize lifespan-owned async DB resources once per process."""
-    global _runtime
-    if _runtime is not None:
-        return _runtime
-
-    active_settings = settings or get_settings()
-    engine = _build_engine(active_settings)
-    session_factory = async_sessionmaker(engine, class_=AsyncSession, expire_on_commit=False)
-    _runtime = DatabaseRuntime(engine=engine, session_factory=session_factory)
-    logger.debug("Initialized async database runtime for database_url=%s", engine.url)
-    return _runtime
-
-
-def get_engine() -> AsyncEngine:
-    """Return the current async SQLAlchemy engine."""
-    runtime = _runtime or initialize_database_runtime()
-    return runtime.engine
-
-
-def get_session_factory() -> async_sessionmaker[AsyncSession]:
-    """Return the shared async session factory."""
-    runtime = _runtime or initialize_database_runtime()
-    return runtime.session_factory
-
-
-async def cleanup_database() -> None:
-    """Cleanup database runtime resources."""
-    await dispose_database_runtime()
-
-
-async def dispose_database_runtime() -> None:
-    """Dispose lifespan-owned async database resources."""
-    global _runtime
-    if _runtime is None:
-        return
-    await _runtime.engine.dispose()
-    _runtime = None
-
-
-async def create_all(*, engine: AsyncEngine | None = None) -> None:
-    """Create all tables on the selected engine."""
-    # Import models so SQLModel metadata is fully registered before bootstrap.
-    from transcription import models as _models  # noqa: F401
-
-    active_engine = engine or get_engine()
-    async with active_engine.begin() as connection:
-        await connection.run_sync(SQLModel.metadata.create_all)
-        await connection.run_sync(_ensure_sqlite_compat_columns)
-    logger.debug("Database schema bootstrap complete for database_url=%s", active_engine.url)
-
-
-def _ensure_sqlite_compat_columns(connection: Connection) -> None:
-    """Apply lightweight dev/test SQLite compatibility column patches.
-
-    This performs read-only validation and never mutates schema.
-    """
-    if connection.engine.url.get_backend_name() != "sqlite":
-        return
-
-    inspector = inspect(connection)
-    table_names = set(inspector.get_table_names())
-
-    required_tables = {"document", "job", "transcript", "transcriptrevision"}
-    missing_tables = sorted(required_tables - table_names)
-    for table_name in missing_tables:
-        issues.append(f"missing_table:{table_name}")
-
-    columns = {column["name"] for column in inspector.get_columns("job")}
-    if "retry_count" not in columns:
-        connection.execute(text("ALTER TABLE job ADD COLUMN retry_count INTEGER NOT NULL DEFAULT 0"))
-        logger.warning("Applied SQLite compatibility schema patch table=job column=retry_count default=0")
-
-
-@contextlib.asynccontextmanager
-async def get_session(
-    *,
-    session_factory: async_sessionmaker[AsyncSession] | None = None,
-) -> AsyncGenerator[AsyncSession]:
-    """Yield a database session and ensure cleanup."""
-    active_session_factory = session_factory or get_session_factory()
-    async with active_session_factory() as session:
-        yield session
-
-
-def should_bootstrap_schema(settings: Settings) -> bool:
-    """Compatibility helper for explicit bootstrap checks."""
-    return settings.should_bootstrap_schema

src/transcription/db/__init__.py

@@ -0,0 +1,15 @@
+from .operations import create_all
+from .operations import upgrade_schema
+from .runtime import dispose_database_runtime
+from .runtime import initialize_database_runtime
+from .session import session_scope
+from .session import transaction_scope
+
+__all__ = [
+    "create_all",
+    "dispose_database_runtime",
+    "initialize_database_runtime",
+    "session_scope",
+    "transaction_scope",
+    "upgrade_schema",
+]

src/transcription/db/engine.py

@@ -0,0 +1,60 @@
+from functools import cache
+from typing import Any
+
+from sqlalchemy import URL
+from sqlalchemy import StaticPool
+from sqlalchemy.ext.asyncio import AsyncEngine
+from sqlalchemy.ext.asyncio import create_async_engine
+
+from ..config import PostgresSettings
+from ..config import Settings
+from ..config import SqliteSettings
+from ..config import get_settings
+
+
+def get_database_url(settings: Settings) -> str:
+    match settings.database:
+        case SqliteSettings(path=path):
+            url = URL.create(
+                drivername="sqlite+aiosqlite",
+                database=path,
+            )
+        case PostgresSettings() as database:
+            url = URL.create(
+                drivername="postgresql+asyncpg",
+                host=database.host,
+                port=database.port,
+                database=database.database,
+                username=database.user,
+                password=database.password.get_secret_value(),
+            )
+    return url.render_as_string(hide_password=False)
+
+
+def resolve_engine(settings: Settings | None = None) -> AsyncEngine:
+    active_settings = settings or get_settings()
+    return get_engine(get_database_url(active_settings))
+
+
+@cache
+def get_engine(database_url: str) -> AsyncEngine:
+    kwargs: dict[str, Any] = {"echo": False, "pool_pre_ping": True}
+    if database_url.startswith("sqlite"):
+        kwargs["connect_args"] = {"check_same_thread": False}
+        if ":memory:" in database_url:
+            kwargs["poolclass"] = StaticPool
+
+    return create_async_engine(database_url, **kwargs)
+
+
+async def dispose_engine(database_url: str) -> None:
+    engine = get_engine(database_url)
+    try:
+        await engine.dispose()
+    finally:
+        get_engine.cache_clear()
+
+
+async def refresh_engine(database_url: str) -> AsyncEngine:
+    await dispose_engine(database_url)
+    return get_engine(database_url)

src/transcription/db/models.py

@@ -0,0 +1,406 @@
+"""SQLModel domain models for the V3 transcription system."""
+
+from datetime import UTC
+from datetime import date
+from datetime import datetime
+from enum import StrEnum
+from typing import Optional
+from uuid import UUID
+from uuid import uuid4
+
+from pydantic import JsonValue
+from sqlalchemy import JSON
+from sqlalchemy import BigInteger
+from sqlalchemy import CheckConstraint
+from sqlalchemy import Column
+from sqlalchemy import Enum as SAEnum
+from sqlalchemy import LargeBinary
+from sqlalchemy import UniqueConstraint
+from sqlalchemy.dialects.postgresql import JSONB
+from sqlalchemy.orm.exc import DetachedInstanceError
+from sqlalchemy.types import TypeDecorator
+from sqlmodel import Field
+from sqlmodel import Relationship
+from sqlmodel import SQLModel
+
+
+class JSONBCompat(TypeDecorator):
+    """JSONB for PostgreSQL and JSON for SQLite/testing backends."""
+
+    impl = JSON(none_as_null=True)
+
+    def load_dialect_impl(self, dialect):
+        if dialect.name == "postgresql":
+            return dialect.type_descriptor(JSONB(none_as_null=True))
+        return dialect.type_descriptor(JSON(none_as_null=True))
+
+
+class JobStatus(StrEnum):
+    QUEUED = "queued"
+    PROCESSING = "processing"
+    TRANSCRIBED = "transcribed"
+    COMPLETED = "completed"
+    PARTIAL_SUCCESS = "partial_success"
+    FAILED = "failed"
+
+
+class DocumentPersonRole(StrEnum):
+    AUTHOR = "author"
+    RECIPIENT = "recipient"
+    MENTIONED = "mentioned"
+
+
+class JobSourceStatus(StrEnum):
+    PENDING = "pending"
+    TRANSCRIBED = "transcribed"
+    FAILED = "failed"
+
+
+class DocumentType(SQLModel, table=True):
+    """Registry of allowed document types."""
+
+    __tablename__ = "document_type"
+
+    id: UUID = Field(default_factory=uuid4, primary_key=True)
+    label: str
+    normalized_label: str = Field(index=True, unique=True)
+    is_active: bool = True
+    created_at: datetime = Field(default_factory=lambda: datetime.now(UTC))
+    updated_at: datetime = Field(default_factory=lambda: datetime.now(UTC))
+
+    documents: list["Document"] = Relationship(
+        back_populates="document_type_ref", sa_relationship_kwargs={"lazy": "selectin"}
+    )
+
+
+class PersonRole(SQLModel, table=True):
+    """Registry of allowed document-person relationship roles."""
+
+    __tablename__ = "person_role"
+
+    id: UUID = Field(default_factory=uuid4, primary_key=True)
+    code: str = Field(index=True, unique=True)
+    label: str
+    is_active: bool = True
+    created_at: datetime = Field(default_factory=lambda: datetime.now(UTC))
+    updated_at: datetime = Field(default_factory=lambda: datetime.now(UTC))
+
+    document_people: list["DocumentPerson"] = Relationship(
+        back_populates="role_ref", sa_relationship_kwargs={"lazy": "selectin"}
+    )
+
+
+class Document(SQLModel, table=True):
+    """An historical document."""
+
+    id: UUID = Field(default_factory=uuid4, primary_key=True)
+    name: str
+    document_type_id: UUID | None = Field(default=None, foreign_key="document_type.id")
+    document_date: date | None = None
+    document_date_raw: str | None = None
+    location_created: str | None = None
+    notes: str | None = None
+    archive_identifier: str | None = None
+    created_at: datetime = Field(default_factory=lambda: datetime.now(UTC))
+    updated_at: datetime = Field(default_factory=lambda: datetime.now(UTC))
+
+    jobs: list["Job"] = Relationship(back_populates="document", sa_relationship_kwargs={"lazy": "selectin"})
+    sources: list["Source"] = Relationship(back_populates="document", sa_relationship_kwargs={"lazy": "selectin"})
+    document_people: list["DocumentPerson"] = Relationship(
+        back_populates="document", sa_relationship_kwargs={"lazy": "selectin"}
+    )
+    document_type_ref: Optional["DocumentType"] = Relationship(
+        back_populates="documents", sa_relationship_kwargs={"lazy": "selectin"}
+    )
+
+
+class Person(SQLModel, table=True):
+    """A historical person linked to one or more documents."""
+
+    id: UUID = Field(default_factory=uuid4, primary_key=True)
+    full_name: str
+    display_name: str | None = None
+    maiden_name: str | None = None
+    birth_date: date | None = None
+    birth_date_raw: str | None = None
+    birth_place: str | None = None
+    death_date: date | None = None
+    death_date_raw: str | None = None
+    death_place: str | None = None
+    biography: str | None = None
+    portrait_path: str | None = None
+    family_search_id: str | None = Field(default=None, unique=True)
+    metadata_: dict[str, JsonValue] | None = Field(
+        default=None,
+        sa_column=Column("metadata", JSONBCompat(), nullable=True),
+    )
+    created_at: datetime = Field(default_factory=lambda: datetime.now(UTC))
+    updated_at: datetime = Field(default_factory=lambda: datetime.now(UTC))
+
+    document_people: list["DocumentPerson"] = Relationship(
+        back_populates="person", sa_relationship_kwargs={"lazy": "selectin"}
+    )
+
+
+class DocumentPerson(SQLModel, table=True):
+    """Associates documents with people in a given role."""
+
+    __tablename__ = "document_person"
+
+    id: UUID = Field(default_factory=uuid4, primary_key=True)
+    document_id: UUID = Field(foreign_key="document.id")
+    person_id: UUID = Field(foreign_key="person.id")
+    role_id: UUID | None = Field(default=None, foreign_key="person_role.id")
+    role: str = Field(default=DocumentPersonRole.AUTHOR.value, nullable=False)
+    created_at: datetime = Field(default_factory=lambda: datetime.now(UTC))
+    updated_at: datetime = Field(default_factory=lambda: datetime.now(UTC))
+
+    __table_args__ = (
+        UniqueConstraint("document_id", "person_id", "role_id", name="uq_document_person_role_id"),
+        UniqueConstraint("document_id", "person_id", "role", name="uq_document_person_role"),
+    )
+
+    document: Optional["Document"] = Relationship(
+        back_populates="document_people", sa_relationship_kwargs={"lazy": "selectin"}
+    )
+    person: Optional["Person"] = Relationship(
+        back_populates="document_people", sa_relationship_kwargs={"lazy": "selectin"}
+    )
+    role_ref: Optional["PersonRole"] = Relationship(
+        back_populates="document_people", sa_relationship_kwargs={"lazy": "selectin"}
+    )
+
+
+class Job(SQLModel, table=True):
+    """A transcription job tied to a single document."""
+
+    id: UUID = Field(default_factory=uuid4, primary_key=True)
+    document_id: UUID = Field(foreign_key="document.id")
+    status: JobStatus = Field(
+        default=JobStatus.QUEUED,
+        sa_column=Column(
+            SAEnum(
+                JobStatus,
+                values_callable=lambda enum_cls: [item.value for item in enum_cls],
+                native_enum=False,
+            ),
+            nullable=False,
+        ),
+    )
+    retry_count: int = Field(default=0, ge=0)
+    date_created: datetime = Field(default_factory=lambda: datetime.now(UTC))
+    date_updated: datetime = Field(default_factory=lambda: datetime.now(UTC))
+    provider: str | None = None
+    model: str | None = None
+    prompt_name: str | None = None
+    prompt_hash: str | None = None
+    system_prompt: str | None = None
+    user_prompt: str | None = None
+    temperature: float | None = None
+    top_p: float | None = None
+
+    document: Optional["Document"] = Relationship(back_populates="jobs", sa_relationship_kwargs={"lazy": "selectin"})
+    job_sources: list["JobSource"] = Relationship(back_populates="job", sa_relationship_kwargs={"lazy": "selectin"})
+
+    @property
+    def filename(self) -> str:
+        """Return the filename of the associated source, when available."""
+        if not self.job_sources:
+            return "unknown"
+
+        for job_source in self.job_sources:
+            source = job_source.__dict__.get("source")
+            if source is None:
+                try:
+                    source = job_source.source
+                except DetachedInstanceError:
+                    source = None
+                except Exception:  # noqa: BLE001
+                    source = None
+
+            if source is not None:
+                return source.filename
+
+        return "unknown"
+
+    @property
+    def error_detail(self) -> str | None:
+        """Return the first available source-level error detail for the job."""
+        if not self.job_sources:
+            return None
+
+        for job_source in self.job_sources:
+            if job_source.error_detail:
+                return job_source.error_detail
+
+        return None
+
+
+class Source(SQLModel, table=True):
+    """A document source image or PDF page."""
+
+    id: UUID = Field(default_factory=uuid4, primary_key=True)
+    document_id: UUID = Field(foreign_key="document.id")
+    page_number: int = Field(default=1, ge=1)
+    upload_name: str
+    filename: str
+    file_path: str
+    file_hash: str
+    file_size_bytes: int = Field(sa_column=Column(BigInteger(), nullable=False))
+    raw_transcription: str | None = None
+    revised_text: str | None = None
+    date_uploaded: datetime = Field(default_factory=lambda: datetime.now(UTC))
+    date_revised: datetime | None = None
+
+    document: Optional["Document"] = Relationship(
+        back_populates="sources",
+        sa_relationship_kwargs={"lazy": "selectin"},
+    )
+    job_sources: list["JobSource"] = Relationship(
+        back_populates="source",
+        sa_relationship_kwargs={"lazy": "selectin"},
+    )
+    processing_artifacts: list["ProcessingArtifact"] = Relationship(
+        back_populates="source",
+        sa_relationship_kwargs={"lazy": "noload"},
+    )
+
+    @property
+    def latest_job_source(self) -> Optional["JobSource"]:
+        """Return the most recent job execution record for this source."""
+        if not self.job_sources:
+            return None
+        return max(self.job_sources, key=lambda js: js.executed_at)
+
+    @property
+    def latest_status(self) -> JobSourceStatus | None:
+        """Return the execution status of the latest job run."""
+        latest = self.latest_job_source
+        return latest.status if latest else None
+
+    @property
+    def latest_error_detail(self) -> str | None:
+        """Return the error detail from the latest job run, if present."""
+        latest = self.latest_job_source
+        return latest.error_detail if latest else None
+
+    @property
+    def document_name(self) -> str | None:
+        """Return the parent document name if loaded."""
+        return self.document.name if self.document else None
+
+
+class JobSource(SQLModel, table=True):
+    """A single AI execution record for one source page."""
+
+    __tablename__ = "job_source"
+
+    id: UUID = Field(default_factory=uuid4, primary_key=True)
+    job_id: UUID = Field(foreign_key="job.id")
+    source_id: UUID = Field(foreign_key="source.id")
+    status: JobSourceStatus = Field(
+        default=JobSourceStatus.PENDING,
+        sa_column=Column(
+            SAEnum(
+                JobSourceStatus,
+                values_callable=lambda enum_cls: [item.value for item in enum_cls],
+                native_enum=False,
+            ),
+            nullable=False,
+        ),
+    )
+    raw_transcription: str | None = None
+    ai_metadata: dict[str, JsonValue] | None = Field(default=None, sa_column=Column(JSONBCompat(), nullable=True))
+    raw_api_response: dict[str, JsonValue] | None = Field(default=None, sa_column=Column(JSONBCompat(), nullable=True))
+    error_detail: str | None = None
+    executed_at: datetime = Field(default_factory=lambda: datetime.now(UTC))
+
+    job: Optional["Job"] = Relationship(back_populates="job_sources", sa_relationship_kwargs={"lazy": "selectin"})
+    source: Optional["Source"] = Relationship(back_populates="job_sources", sa_relationship_kwargs={"lazy": "selectin"})
+    execution_attempts: list["ExecutionAttempt"] = Relationship(
+        back_populates="job_source",
+        sa_relationship_kwargs={"lazy": "noload", "order_by": "ExecutionAttempt.attempt_number"},
+    )
+
+
+class ExecutionAttempt(SQLModel, table=True):
+    """Immutable evidence for one provider call attempt."""
+
+    __tablename__ = "execution_attempt"
+    __table_args__ = (UniqueConstraint("job_id", "source_id", "attempt_number", name="uq_execution_attempt_number"),)
+
+    id: UUID = Field(default_factory=uuid4, primary_key=True)
+    job_source_id: UUID = Field(foreign_key="job_source.id", index=True)
+    job_id: UUID = Field(foreign_key="job.id", index=True)
+    source_id: UUID = Field(foreign_key="source.id", index=True)
+    attempt_number: int = Field(ge=1)
+    status: JobSourceStatus
+    provider: str
+    model: str | None = None
+    request_manifest: dict[str, JsonValue] | None = Field(default=None, sa_column=Column(JSONBCompat(), nullable=True))
+    request_manifest_sha256: str | None = None
+    request_manifest_schema_version: str | None = None
+    response_received: bool = False
+    transport_status_code: int | None = None
+    transport_body: bytes | None = Field(default=None, sa_column=Column(LargeBinary(), nullable=True))
+    transport_content_type: str | None = None
+    transport_content_encoding: str | None = None
+    transport_safe_headers: dict[str, JsonValue] | None = Field(
+        default=None, sa_column=Column(JSONBCompat(), nullable=True)
+    )
+    router_request_id: str | None = None
+    router_generation_id: str | None = None
+    sdk_response_snapshot: dict[str, JsonValue] | None = Field(
+        default=None, sa_column=Column(JSONBCompat(), nullable=True)
+    )
+    normalized_metadata: dict[str, JsonValue] | None = Field(
+        default=None, sa_column=Column(JSONBCompat(), nullable=True)
+    )
+    software_context: dict[str, JsonValue] | None = Field(default=None, sa_column=Column(JSONBCompat(), nullable=True))
+    raw_transcription: str | None = None
+    error_category: str | None = None
+    error_detail: str | None = None
+    failure_phase: str | None = None
+    started_at: datetime
+    finished_at: datetime
+    duration_ms: int = Field(ge=0)
+    created_at: datetime = Field(default_factory=lambda: datetime.now(UTC))
+
+    job_source: Optional["JobSource"] = Relationship(back_populates="execution_attempts")
+    artifacts: list["ProcessingArtifact"] = Relationship(
+        back_populates="execution_attempt", sa_relationship_kwargs={"lazy": "noload"}
+    )
+
+
+class ProcessingArtifact(SQLModel, table=True):
+    """Provider-neutral, versioned output derived from a Source."""
+
+    __tablename__ = "processing_artifact"
+    __table_args__ = (
+        CheckConstraint(
+            "(inline_payload IS NOT NULL AND external_reference IS NULL) OR "
+            "(inline_payload IS NULL AND external_reference IS NOT NULL)",
+            name="ck_processing_artifact_one_content_location",
+        ),
+    )
+
+    id: UUID = Field(default_factory=uuid4, primary_key=True)
+    source_id: UUID = Field(foreign_key="source.id", index=True)
+    execution_attempt_id: UUID | None = Field(default=None, foreign_key="execution_attempt.id", index=True)
+    artifact_type: str
+    media_type: str
+    schema_name: str
+    schema_version: str
+    producer: str
+    producer_version: str
+    inline_payload: dict[str, JsonValue] | None = Field(default=None, sa_column=Column(JSONBCompat(), nullable=True))
+    external_reference: str | None = None
+    payload_sha256: str = Field(index=True)
+    byte_size: int = Field(sa_column=Column(BigInteger(), nullable=False))
+    coordinate_metadata: dict[str, JsonValue] | None = Field(
+        default=None, sa_column=Column(JSONBCompat(), nullable=True)
+    )
+    created_at: datetime = Field(default_factory=lambda: datetime.now(UTC))
+
+    execution_attempt: Optional["ExecutionAttempt"] = Relationship(back_populates="artifacts")
+    source: Optional["Source"] = Relationship(back_populates="processing_artifacts")

src/transcription/db/operations.py

@@ -0,0 +1,194 @@
+from __future__ import annotations
+
+import logging
+
+from sqlalchemy import inspect
+from sqlalchemy import text
+from sqlalchemy.ext.asyncio import AsyncConnection
+from sqlalchemy.ext.asyncio import AsyncEngine
+from sqlalchemy.ext.asyncio import async_sessionmaker
+from sqlmodel import SQLModel
+from sqlmodel import select
+from sqlmodel.ext.asyncio.session import AsyncSession
+
+from .engine import resolve_engine
+from .models import DocumentType
+from .models import Job
+from .models import JobStatus
+from .models import PersonRole
+
+logger = logging.getLogger(__name__)
+
+
+DEFAULT_PERSON_ROLES: tuple[tuple[str, str], ...] = (
+    ("author", "Author"),
+    ("recipient", "Recipient"),
+    ("mentioned", "Mentioned"),
+)
+
+DEFAULT_DOCUMENT_TYPES: tuple[str, ...] = (
+    "Letter",
+    "Record",
+    "Memo",
+    "Postcard",
+    "Journal",
+    "Note",
+)
+
+
+async def create_all(*, engine: AsyncEngine | None = None) -> None:
+    """Create any missing tables on the selected engine."""
+    # Import models so SQLModel metadata is fully registered before bootstrap.
+    from transcription.db import models as _models  # noqa: F401
+
+    active_engine = engine or resolve_engine()
+    async with active_engine.begin() as connection:
+        await connection.run_sync(SQLModel.metadata.create_all)
+        await _upgrade_document_type_uuid_identity(connection)
+        await _upgrade_person_family_search_id(connection)
+        await _upgrade_v42_evidence_tables(connection)
+    await seed_registry_defaults(engine=active_engine)
+    logger.debug("Database schema bootstrap complete for database_url=%s", active_engine.url)
+
+
+async def upgrade_schema(*, engine: AsyncEngine | None = None) -> None:
+    """Apply non-destructive additive upgrades to an existing schema."""
+    active_engine = engine or resolve_engine()
+    async with active_engine.begin() as connection:
+        await _upgrade_document_type_uuid_identity(connection)
+        await _upgrade_person_family_search_id(connection)
+        await _upgrade_v42_evidence_tables(connection)
+
+
+async def _upgrade_v42_evidence_tables(connection: AsyncConnection) -> None:
+    """Create the additive V4.2 evidence tables without rewriting historical rows."""
+
+    def create_tables(sync_connection) -> None:
+        SQLModel.metadata.tables["execution_attempt"].create(sync_connection, checkfirst=True)
+        SQLModel.metadata.tables["processing_artifact"].create(sync_connection, checkfirst=True)
+
+    await connection.run_sync(create_tables)
+
+
+async def _upgrade_document_type_uuid_identity(connection: AsyncConnection) -> None:
+    """Backfill UUID references and retire legacy Document Type code/order columns."""
+
+    def inspect_schema(sync_connection) -> tuple[set[str], set[str]]:
+        database = inspect(sync_connection)
+        tables = set(database.get_table_names())
+        type_columns = (
+            {column["name"] for column in database.get_columns("document_type")} if "document_type" in tables else set()
+        )
+        document_columns = (
+            {column["name"] for column in database.get_columns("document")} if "document" in tables else set()
+        )
+        return type_columns, document_columns
+
+    type_columns, document_columns = await connection.run_sync(inspect_schema)
+    if not type_columns:
+        return
+
+    if "normalized_label" not in type_columns:
+        await connection.execute(text("ALTER TABLE document_type ADD COLUMN normalized_label VARCHAR"))
+    await connection.execute(
+        text("UPDATE document_type SET normalized_label = lower(trim(label)) WHERE normalized_label IS NULL")
+    )
+
+    duplicates = (
+        await connection.execute(
+            text("SELECT normalized_label FROM document_type GROUP BY normalized_label HAVING count(*) > 1")
+        )
+    ).first()
+    if duplicates is not None:
+        raise RuntimeError(
+            "Document Type migration requires unique labels ignoring case and whitespace; "
+            f"duplicate normalized label: {duplicates[0]!r}"
+        )
+
+    if "code" in type_columns and {"document_type", "document_type_id"}.issubset(document_columns):
+        await connection.execute(
+            text(
+                "UPDATE document SET document_type_id = ("
+                "SELECT id FROM document_type WHERE "
+                "lower(trim(document_type.code)) = lower(trim(document.document_type))"
+                ") WHERE document_type_id IS NULL AND document_type IS NOT NULL"
+            )
+        )
+
+    if connection.dialect.name == "postgresql":
+        await connection.execute(text("ALTER TABLE document_type ALTER COLUMN normalized_label SET NOT NULL"))
+        if "code" in type_columns:
+            await connection.execute(text("ALTER TABLE document_type DROP COLUMN code CASCADE"))
+        if "sort_order" in type_columns:
+            await connection.execute(text("ALTER TABLE document_type DROP COLUMN sort_order"))
+        if "document_type" in document_columns:
+            await connection.execute(text("ALTER TABLE document DROP COLUMN document_type"))
+    elif connection.dialect.name == "sqlite":
+        await connection.execute(text("DROP INDEX IF EXISTS ix_document_type_code"))
+        if "code" in type_columns:
+            await connection.execute(text("ALTER TABLE document_type DROP COLUMN code"))
+        if "sort_order" in type_columns:
+            await connection.execute(text("ALTER TABLE document_type DROP COLUMN sort_order"))
+        if "document_type" in document_columns:
+            await connection.execute(text("ALTER TABLE document DROP COLUMN document_type"))
+
+    await connection.execute(
+        text("CREATE UNIQUE INDEX IF NOT EXISTS ix_document_type_normalized_label ON document_type (normalized_label)")
+    )
+
+
+async def _upgrade_person_family_search_id(connection: AsyncConnection) -> None:
+    """Add the nullable V4.1 FamilySearch field to an existing database."""
+
+    def inspect_person(sync_connection) -> tuple[bool, bool]:
+        database = inspect(sync_connection)
+        if "person" not in database.get_table_names():
+            return False, False
+        columns = {column["name"] for column in database.get_columns("person")}
+        indexes = database.get_indexes("person")
+        constraints = database.get_unique_constraints("person")
+        has_unique_id = any(entry.get("column_names") == ["family_search_id"] for entry in [*indexes, *constraints])
+        return "family_search_id" in columns, has_unique_id
+
+    has_column, has_unique_id = await connection.run_sync(inspect_person)
+    if not has_column and not await connection.run_sync(
+        lambda sync_connection: "person" in inspect(sync_connection).get_table_names()
+    ):
+        return
+    if not has_column:
+        await connection.execute(text("ALTER TABLE person ADD COLUMN family_search_id VARCHAR"))
+    if not has_unique_id:
+        await connection.execute(
+            text("CREATE UNIQUE INDEX IF NOT EXISTS ix_person_family_search_id ON person (family_search_id)")
+        )
+
+
+async def seed_registry_defaults(*, engine: AsyncEngine | None = None) -> None:
+    """Seed default registry rows for role and document type taxonomies."""
+    active_engine = engine or resolve_engine()
+    session_factory = async_sessionmaker(active_engine, class_=AsyncSession, expire_on_commit=False)
+
+    async with session_factory() as session:
+        role_codes = set((await session.exec(select(PersonRole.code))).all())
+        for code, label in DEFAULT_PERSON_ROLES:
+            if code not in role_codes:
+                session.add(PersonRole(code=code, label=label))
+
+        type_labels = set((await session.exec(select(DocumentType.normalized_label))).all())
+        for label in DEFAULT_DOCUMENT_TYPES:
+            normalized_label = label.casefold()
+            if normalized_label not in type_labels:
+                session.add(DocumentType(label=label, normalized_label=normalized_label))
+
+        await session.commit()
+
+
+async def get_next_queued_job(*, session: AsyncSession) -> Job | None:
+    """Get the next queued job, if any."""
+    result = await session.exec(
+        select(Job)
+        .where(Job.status == JobStatus.QUEUED)
+        .order_by(Job.date_created)  # pyright: ignore[reportArgumentType]
+        .limit(1)
+    )  # fmt: skip
+    return result.first()

src/transcription/db/runtime.py

@@ -0,0 +1,63 @@
+import logging
+from dataclasses import dataclass
+
+from sqlalchemy.ext.asyncio import AsyncEngine
+from sqlalchemy.ext.asyncio import async_sessionmaker
+from sqlmodel.ext.asyncio.session import AsyncSession
+
+from ..config import Settings
+from ..config import get_settings
+from .engine import get_database_url
+from .engine import get_engine
+from .session import get_session_factory
+
+logger = logging.getLogger(__name__)
+
+
+@dataclass(frozen=True)
+class DatabaseRuntime:
+    """Database runtime resources owned by app lifespan."""
+
+    engine: AsyncEngine
+    session_factory: async_sessionmaker[AsyncSession]
+
+
+_runtime: DatabaseRuntime | None = None
+
+
+def get_database_runtime() -> DatabaseRuntime | None:
+    """Return the process-owned database runtime."""
+    return _runtime
+
+
+async def dispose_database_runtime() -> None:
+    """Dispose lifespan-owned async database resources."""
+    global _runtime
+    runtime = _runtime
+    if runtime is None:
+        return
+    await runtime.engine.dispose()
+    _runtime = None
+
+
+def initialize_database_runtime(*, settings: Settings | None = None) -> DatabaseRuntime:
+    """Initialize lifespan-owned async DB resources once per process."""
+    global _runtime
+    active_settings = settings or get_settings()
+    database_url = get_database_url(active_settings)
+    runtime = _runtime
+    if runtime is not None:
+        runtime_url = runtime.engine.url.render_as_string(hide_password=False)
+        if runtime_url != database_url:
+            raise RuntimeError(
+                "Database runtime is already initialized for a different database: "
+                f"{runtime_url!r} != {database_url!r}"
+            )
+        return runtime
+
+    engine = get_engine(database_url)
+    session_factory = get_session_factory(database_url)
+    runtime = DatabaseRuntime(engine=engine, session_factory=session_factory)
+    _runtime = runtime
+    logger.debug("Initialized async database runtime for database_url=%s", engine.url)
+    return runtime

src/transcription/db/session.py

@@ -0,0 +1,105 @@
+from collections.abc import AsyncGenerator
+from contextlib import asynccontextmanager
+from functools import cache
+from typing import Annotated
+
+from fastapi import Depends
+from sqlalchemy.ext.asyncio import AsyncSessionTransaction
+from sqlalchemy.ext.asyncio import async_sessionmaker
+from sqlmodel.ext.asyncio.session import AsyncSession
+
+from ..config import Settings
+from ..config import get_settings
+from .engine import dispose_engine
+from .engine import get_database_url
+from .engine import get_engine
+
+type SessionFactory = async_sessionmaker[AsyncSession]
+
+
+@cache
+def get_session_factory(database_url: str) -> SessionFactory:
+    return async_sessionmaker(
+        bind=get_engine(database_url),
+        class_=AsyncSession,
+        expire_on_commit=False,
+    )
+
+
+def resolve_session_factory(
+    database_url: str | None = None,
+    *,
+    settings: Settings | None = None,
+) -> SessionFactory:
+    if database_url is not None:
+        return get_session_factory(database_url)
+    if settings is None:
+        from .runtime import get_database_runtime
+
+        runtime = get_database_runtime()
+        if runtime is not None:
+            return runtime.session_factory
+    return get_session_factory(get_database_url(settings or get_settings()))
+
+
+type SessionFactoryDep = Annotated[SessionFactory, Depends(resolve_session_factory)]
+
+
+async def dispose_session_factory(database_url: str) -> None:
+    get_session_factory.cache_clear()
+    await dispose_engine(database_url)
+
+
+@asynccontextmanager
+async def session_scope(
+    *,
+    settings: Settings | None = None,
+    database_url: str | None = None,
+    session_factory: SessionFactory | None = None,
+    session: AsyncSession | None = None,
+) -> AsyncGenerator[AsyncSession]:
+    if session is not None:
+        yield session
+        return
+
+    active_session_factory = session_factory or resolve_session_factory(
+        database_url,
+        settings=settings,
+    )
+    async with active_session_factory() as owned_session:
+        yield owned_session
+
+
+type SessionScopeDep = Annotated[AsyncSession, Depends(session_scope)]
+
+
+@asynccontextmanager
+async def transaction_scope(
+    *,
+    settings: Settings | None = None,
+    database_url: str | None = None,
+    session_factory: SessionFactory | None = None,
+    session: AsyncSession | AsyncSessionTransaction | None = None,
+) -> AsyncGenerator[AsyncSession | AsyncSessionTransaction]:
+    match session:
+        case AsyncSession() as async_session:
+            if not async_session.in_transaction():
+                raise RuntimeError("A supplied session must have an active transaction")
+            yield async_session
+            return
+        case AsyncSessionTransaction() as async_transaction:
+            yield async_transaction
+            return
+
+    active_session_factory = session_factory or resolve_session_factory(
+        database_url,
+        settings=settings,
+    )
+    async with active_session_factory.begin() as owned_session:
+        yield owned_session
+
+
+type TransactionScopeDep = Annotated[
+    AsyncSession | AsyncSessionTransaction,
+    Depends(transaction_scope),
+]

src/transcription/errors.py

@@ -17,6 +17,7 @@ class ErrorCategory(StrEnum):
     NOT_FOUND = "not_found_error"
     CONFLICT = "conflict_error"
     EXTERNAL_PROVIDER = "external_provider_error"
+    PROCESSING = "processing_error"
     INFRA_TRANSIENT = "infrastructure_transient_error"
     INFRA_PERSISTENT = "infrastructure_persistent_error"
     INTERNAL_UNEXPECTED = "internal_unexpected_error"
@@ -71,9 +72,8 @@ def build_error_envelope(error: AppError) -> ErrorEnvelope:
 
 def classify_unexpected_error(exc: Exception, *, operation: str) -> AppError:
     """Normalize unknown exceptions into internal_unexpected_error."""
-    _ = exc
     return AppError(
-        f"Unexpected error during {operation}",
+        f"Unexpected error during {operation}: {exc}",
         category=ErrorCategory.INTERNAL_UNEXPECTED,
         suggestion="Retry once. If it persists, review logs and report the error reference id.",
         retriable=False,
@@ -82,7 +82,4 @@ def classify_unexpected_error(exc: Exception, *, operation: str) -> AppError:
 
 def format_error_detail(error: AppError) -> str:
     """Return a compact persisted failure string for transcript.error_detail."""
-    return (
-        f"[{error.category.value}] {error.message} | "
-        f"suggestion={error.suggestion} | error_id={error.error_id}"
-    )
+    return f"[{error.category.value}] {error.message} | suggestion={error.suggestion} | error_id={error.error_id}"

src/transcription/migration_runner.py

@@ -1,75 +0,0 @@
-"""CLI entrypoint for explicit schema migration and compatibility checks."""
-
-from __future__ import annotations
-
-import argparse
-
-from transcription.config import get_settings
-from transcription.db import initialize_database_runtime
-from transcription.db import validate_schema_compatibility
-from transcription.migrations import apply_pending_migrations
-from transcription.migrations import list_pending_migrations
-
-
-def _build_parser() -> argparse.ArgumentParser:
-    parser = argparse.ArgumentParser(description="Transcription schema migration runner")
-    parser.add_argument(
-        "--apply",
-        action="store_true",
-        help="Apply all pending migrations.",
-    )
-    parser.add_argument(
-        "--list",
-        action="store_true",
-        help="List pending migrations.",
-    )
-    parser.add_argument(
-        "--check",
-        action="store_true",
-        help="Run schema compatibility check.",
-    )
-    return parser
-
-
-def main() -> int:
-    parser = _build_parser()
-    args = parser.parse_args()
-
-    if not (args.apply or args.list or args.check):
-        parser.error("Specify at least one action: --list, --apply, or --check")
-
-    runtime = initialize_database_runtime(settings=get_settings())
-    engine = runtime.engine
-
-    if args.list:
-        pending = list_pending_migrations(engine=engine)
-        if not pending:
-            print("No pending migrations.")
-        else:
-            print("Pending migrations:")
-            for migration in pending:
-                print(f"- {migration.revision_id}: {migration.description}")
-
-    if args.apply:
-        applied = apply_pending_migrations(engine=engine)
-        if not applied:
-            print("No migrations applied.")
-        else:
-            print("Applied migrations:")
-            for revision_id in applied:
-                print(f"- {revision_id}")
-
-    if args.check:
-        issues = validate_schema_compatibility(engine=engine)
-        if issues:
-            print("Schema compatibility check failed:")
-            for issue in issues:
-                print(f"- {issue}")
-            return 1
-        print("Schema compatibility check passed.")
-
-    return 0
-
-
-if __name__ == "__main__":
-    raise SystemExit(main())

src/transcription/migrations.py

@@ -1,132 +0,0 @@
-"""Lightweight schema migration helpers for V1 Step 4.
-
-This module provides explicit, operator-invoked migration execution for
-personal-scale deployments without introducing heavyweight migration tooling.
-"""
-
-from __future__ import annotations
-
-import logging
-from collections.abc import Callable
-from dataclasses import dataclass
-from datetime import UTC
-from datetime import datetime
-
-from sqlalchemy import inspect
-from sqlalchemy import text
-from sqlalchemy.engine import Connection
-from sqlalchemy.engine import Engine
-
-logger = logging.getLogger(__name__)
-
-
-@dataclass(frozen=True)
-class MigrationRevision:
-    """Represents one ordered schema migration revision."""
-
-    revision_id: str
-    description: str
-    apply: Callable[[Connection], None]
-
-
-def _ensure_history_table(connection: Connection) -> None:
-    """Create migration history table when missing."""
-    connection.execute(
-        text(
-            """
-            CREATE TABLE IF NOT EXISTS schema_migration_history (
-                revision_id VARCHAR(64) PRIMARY KEY,
-                description VARCHAR(255) NOT NULL,
-                applied_at VARCHAR(64) NOT NULL
-            )
-            """
-        )
-    )
-
-
-def _get_applied_revisions(connection: Connection) -> set[str]:
-    """Return applied migration revision IDs."""
-    _ensure_history_table(connection)
-    rows = connection.execute(text("SELECT revision_id FROM schema_migration_history")).fetchall()
-    return {row[0] for row in rows}
-
-
-def _record_revision(connection: Connection, revision: MigrationRevision) -> None:
-    """Persist one applied migration revision record."""
-    connection.execute(
-        text(
-            """
-            INSERT INTO schema_migration_history (revision_id, description, applied_at)
-            VALUES (:revision_id, :description, :applied_at)
-            """
-        ),
-        {
-            "revision_id": revision.revision_id,
-            "description": revision.description,
-            "applied_at": datetime.now(UTC).isoformat(),
-        },
-    )
-
-
-def _apply_0001_add_retry_count(connection: Connection) -> None:
-    """Ensure job.retry_count exists for legacy databases."""
-    inspector = inspect(connection)
-    table_names = set(inspector.get_table_names())
-    if "job" not in table_names:
-        return
-
-    columns = {column["name"] for column in inspector.get_columns("job")}
-    if "retry_count" in columns:
-        return
-
-    # Compatible with SQLite and PostgreSQL for this additive integer column.
-    connection.execute(text("ALTER TABLE job ADD COLUMN retry_count INTEGER NOT NULL DEFAULT 0"))
-
-
-def _apply_0002_create_transcriptrevision(connection: Connection) -> None:
-    """Ensure transcriptrevision table exists."""
-    # Import models lazily so metadata is fully populated.
-    from sqlmodel import SQLModel
-
-    from transcription.models import TranscriptRevision  # noqa: F401
-
-    table = SQLModel.metadata.tables["transcriptrevision"]
-    table.create(bind=connection, checkfirst=True)
-
-
-MIGRATIONS: tuple[MigrationRevision, ...] = (
-    MigrationRevision(
-        revision_id="0001_add_retry_count_to_job",
-        description="Add retry_count column to job table with default 0",
-        apply=_apply_0001_add_retry_count,
-    ),
-    MigrationRevision(
-        revision_id="0002_create_transcriptrevision_table",
-        description="Create transcriptrevision table for immutable transcript history",
-        apply=_apply_0002_create_transcriptrevision,
-    ),
-)
-
-
-def list_pending_migrations(*, engine: Engine) -> list[MigrationRevision]:
-    """Return pending migrations ordered by revision."""
-    with engine.begin() as connection:
-        applied = _get_applied_revisions(connection)
-    return [revision for revision in MIGRATIONS if revision.revision_id not in applied]
-
-
-def apply_pending_migrations(*, engine: Engine) -> list[str]:
-    """Apply all pending migrations and return applied revision IDs."""
-    pending = list_pending_migrations(engine=engine)
-    applied_ids: list[str] = []
-
-    for revision in pending:
-        logger.info("Applying migration revision=%s", revision.revision_id)
-        with engine.begin() as connection:
-            _ensure_history_table(connection)
-            revision.apply(connection)
-            _record_revision(connection, revision)
-        applied_ids.append(revision.revision_id)
-        logger.info("Applied migration revision=%s", revision.revision_id)
-
-    return applied_ids

src/transcription/models.py

@@ -1,76 +0,0 @@
-"""SQLModel domain models for the transcription system."""
-
-from datetime import UTC
-from datetime import datetime
-from enum import StrEnum
-from typing import Optional
-from uuid import UUID
-from uuid import uuid4
-
-from sqlmodel import Field
-from sqlmodel import Relationship
-from sqlmodel import SQLModel
-
-
-class JobStatus(StrEnum):
-    QUEUED = "queued"
-    PROCESSING = "processing"
-    TRANSCRIBED = "transcribed"
-    COMPLETED = "completed"
-    FAILED = "failed"
-
-
-class Document(SQLModel, table=True):
-    """An uploaded document image."""
-
-    id: UUID = Field(default_factory=uuid4, primary_key=True)
-    filename: str
-    file_path: str
-    uploaded_at: datetime = Field(default_factory=lambda: datetime.now(UTC))
-
-    # --- relationships ---
-    jobs: list["Job"] = Relationship(back_populates="document")
-
-
-class Job(SQLModel, table=True):
-    """A transcription job tied to a single document."""
-
-    id: UUID = Field(default_factory=uuid4, primary_key=True)
-    document_id: UUID = Field(foreign_key="document.id")
-    status: JobStatus = Field(default=JobStatus.QUEUED)
-    retry_count: int = Field(default=0, ge=0)
-    created_at: datetime = Field(default_factory=lambda: datetime.now(UTC))
-    updated_at: datetime = Field(default_factory=lambda: datetime.now(UTC))
-
-    # --- relationships ---
-    document: Document = Relationship(back_populates="jobs")
-    transcript: Optional["Transcript"] = Relationship(back_populates="job")
-    revisions: list["TranscriptRevision"] = Relationship(back_populates="job")
-
-
-class Transcript(SQLModel, table=True):
-    """Canonical transcript state for a job (latest text or failure detail)."""
-
-    id: UUID = Field(default_factory=uuid4, primary_key=True)
-    job_id: UUID = Field(foreign_key="job.id", unique=True)
-    text: str | None = None
-    error_detail: str | None = None
-    created_at: datetime = Field(default_factory=lambda: datetime.now(UTC))
-
-    # --- relationships ---
-    job: Job = Relationship(back_populates="transcript")
-
-
-class TranscriptRevision(SQLModel, table=True):
-    """Immutable transcript revision history for review/acceptance workflows."""
-
-    id: UUID = Field(default_factory=uuid4, primary_key=True)
-    job_id: UUID = Field(foreign_key="job.id", index=True)
-    revision_number: int = Field(ge=1)
-    text: str
-    source: str = Field(default="worker")
-    accepted: bool = Field(default=False)
-    created_at: datetime = Field(default_factory=lambda: datetime.now(UTC))
-
-    # --- relationships ---
-    job: Job = Relationship(back_populates="revisions")

src/transcription/providers/__init__.py

@@ -6,8 +6,12 @@ from transcription.config import get_settings
 from transcription.providers.base import ProviderAuthError
 from transcription.providers.base import ProviderError
 from transcription.providers.base import ProviderResponseError
+from transcription.providers.base import TranscriptionMetadata
 from transcription.providers.base import TranscriptionProvider
 from transcription.providers.base import TranscriptionResult
+from transcription.providers.evidence import RequestManifest
+from transcription.providers.evidence import SourceEvidenceReference
+from transcription.providers.evidence import TransportEvidence
 from transcription.providers.openrouter import OpenRouterTranscriptionProvider
 
 
@@ -25,7 +29,11 @@ __all__ = [
     "ProviderAuthError",
     "ProviderError",
     "ProviderResponseError",
+    "RequestManifest",
+    "SourceEvidenceReference",
+    "TranscriptionMetadata",
     "TranscriptionProvider",
     "TranscriptionResult",
+    "TransportEvidence",
     "get_transcription_provider",
 ]