generated from john/python-template
Compare commits
10
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 Jim Lancaster
|
939b0e46e9 | ||
|
Jim Lancaster
|
15af11ecb5 | ||
 John Lancaster
|
6dc58a8d50 | ||
|
Jim Lancaster
|
e90dbe4958 | ||
|
Jim Lancaster
|
c9682b0399 | ||
|
Jim Lancaster
|
dd80cd60cf | ||
|
Jim Lancaster
|
754a273ead | ||
|
Jim Lancaster
|
06bb4290be | ||
|
Jim Lancaster
|
21478a904c | ||
|
Jim Lancaster
|
b94d5d2863 |
@@ -1,13 +0,0 @@
|
||||
.git
|
||||
.gitignore
|
||||
.vscode
|
||||
.venv
|
||||
.pytest_cache
|
||||
.ruff_cache
|
||||
__pycache__/
|
||||
*.py[cod]
|
||||
*.db
|
||||
.env
|
||||
tests/
|
||||
docs/
|
||||
uploads/
|
||||
@@ -0,0 +1,8 @@
|
||||
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
|
||||
@@ -1,67 +0,0 @@
|
||||
# Production environment example for docker-compose.production.yml
|
||||
|
||||
# --- NiceGUI Server ---
|
||||
HOST=0.0.0.0
|
||||
PORT=8000
|
||||
LOG_LEVEL=info
|
||||
RELOAD=false
|
||||
ENVIRONMENT=production
|
||||
# TRANSCRIPTION_COMMIT=
|
||||
RUN_EMBEDDED_WORKER=false
|
||||
LOG_DIR=/app/data/logs
|
||||
LOG_FILE_NAME=transcription.log
|
||||
LOG_FILE_MAX_BYTES=10485760
|
||||
LOG_FILE_BACKUP_COUNT=5
|
||||
|
||||
# --- AI provider ---
|
||||
PROVIDER=openrouter
|
||||
OPENROUTER_API_KEY=replace-with-real-key
|
||||
PROVIDER_MODEL=google/gemini-2.5-flash
|
||||
# PROVIDER_MODELS=["google/gemini-2.5-flash","anthropic/claude-sonnet-4"]
|
||||
# OPENROUTER_HTTP_REFERER=
|
||||
# OPENROUTER_APP_TITLE=
|
||||
DEFAULT_PROMPT_NAME=transcribe_document.md
|
||||
# TRANSCRIPTION_TEMPERATURE=
|
||||
# TRANSCRIPTION_TOP_P=
|
||||
|
||||
# --- persistence ---
|
||||
# Common database settings:
|
||||
DATABASE__DRIVER=postgres
|
||||
DATABASE__DATABASE=transcription
|
||||
DATABASE__USER=transcription
|
||||
DATABASE__PASSWORD=replace-with-strong-password
|
||||
BOOTSTRAP_SCHEMA_ON_STARTUP=false
|
||||
|
||||
# SQLite-specific settings:
|
||||
# DATABASE__PATH=./data/transcription.db
|
||||
# SQLITE_CHECK_SAME_THREAD=false
|
||||
|
||||
# Postgres-specific settings:
|
||||
DATABASE__HOST=postgres
|
||||
DATABASE__PORT=5432
|
||||
|
||||
# --- filesystem paths ---
|
||||
UPLOAD_DIR=/app/uploads
|
||||
PROMPT_DIR=/app/prompts
|
||||
# --- backup workflow helpers (not Runtime Settings model fields) ---
|
||||
BACKUP_DIR=/backup
|
||||
BACKUP_RETENTION_DAYS=14
|
||||
|
||||
# --- worker reliability ---
|
||||
WORKER_MAX_RETRIES=0
|
||||
WORKER_PROVIDER_TIMEOUT_SECONDS=30.0
|
||||
WORKER_STALE_JOB_SECONDS=90.0
|
||||
WORKER_RETRY_BACKOFF_SECONDS=1.0
|
||||
WORKER_SHUTDOWN_GRACE_SECONDS=5.0
|
||||
WORKER_POLL_INTERVAL_SECONDS=1.0
|
||||
WORKER_MIN_TRANSCRIPTION_CHARS=0
|
||||
WORKER_MIN_TRANSCRIPTION_LINES=0
|
||||
WORKER_FAIL_ON_FINISH_REASON_LENGTH=false
|
||||
|
||||
# --- cloudflare tunnel ---
|
||||
# Required for token-based tunnel startup.
|
||||
CLOUDFLARE_TUNNEL_TOKEN=replace-with-cloudflare-tunnel-token
|
||||
|
||||
# --- deployment wiring helpers ---
|
||||
# Runtime Settings writes target this file path inside the app container.
|
||||
RUNTIME_SETTINGS_ENV_FILE=/app/.env.production
|
||||
@@ -1,67 +0,0 @@
|
||||
# Production environment
|
||||
|
||||
# --- NiceGUI Server ---
|
||||
HOST=0.0.0.0
|
||||
PORT=8000
|
||||
LOG_LEVEL=info
|
||||
RELOAD=false
|
||||
ENVIRONMENT=production
|
||||
# TRANSCRIPTION_COMMIT=
|
||||
RUN_EMBEDDED_WORKER=false
|
||||
LOG_DIR=/app/data/logs
|
||||
LOG_FILE_NAME=transcription.log
|
||||
LOG_FILE_MAX_BYTES=10485760
|
||||
LOG_FILE_BACKUP_COUNT=5
|
||||
|
||||
# --- AI provider ---
|
||||
PROVIDER=openrouter
|
||||
OPENROUTER_API_KEY=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
|
||||
PROVIDER_MODEL=google/gemini-2.5-flash
|
||||
PROVIDER_MODELS=["google/gemini-2.5-pro","google/gemini-2.5-flash","anthropic/claude-opus-5","anthropic/claude-sonnet-4","openai/gpt-5.6","openai/gpt-4o"]
|
||||
# OPENROUTER_HTTP_REFERER=
|
||||
# OPENROUTER_APP_TITLE=
|
||||
DEFAULT_PROMPT_NAME=transcribe_document.md
|
||||
# TRANSCRIPTION_TEMPERATURE=
|
||||
# TRANSCRIPTION_TOP_P=
|
||||
|
||||
# --- persistence ---
|
||||
# Common database settings:
|
||||
DATABASE__DRIVER=postgres
|
||||
DATABASE__DATABASE=transcription
|
||||
DATABASE__USER=transcription
|
||||
DATABASE__PASSWORD=<password>
|
||||
BOOTSTRAP_SCHEMA_ON_STARTUP=false
|
||||
|
||||
# SQLite-specific settings:
|
||||
# DATABASE__PATH=./data/transcription.db
|
||||
# SQLITE_CHECK_SAME_THREAD=false
|
||||
|
||||
# Postgres-specific settings:
|
||||
DATABASE__HOST=postgres
|
||||
DATABASE__PORT=5432
|
||||
|
||||
# --- filesystem paths ---
|
||||
UPLOAD_DIR=/app/uploads
|
||||
PROMPT_DIR=/app/prompts
|
||||
# --- backup workflow helpers (not Runtime Settings model fields) ---
|
||||
BACKUP_DIR=/backup
|
||||
BACKUP_RETENTION_DAYS=14
|
||||
|
||||
# --- worker reliability ---
|
||||
WORKER_MAX_RETRIES=0
|
||||
WORKER_PROVIDER_TIMEOUT_SECONDS=30.0
|
||||
WORKER_STALE_JOB_SECONDS=30.0
|
||||
WORKER_RETRY_BACKOFF_SECONDS=1.0
|
||||
WORKER_SHUTDOWN_GRACE_SECONDS=5.0
|
||||
WORKER_POLL_INTERVAL_SECONDS=1.0
|
||||
WORKER_MIN_TRANSCRIPTION_CHARS=0
|
||||
WORKER_MIN_TRANSCRIPTION_LINES=0
|
||||
WORKER_FAIL_ON_FINISH_REASON_LENGTH=false
|
||||
|
||||
# --- cloudflare tunnel ---
|
||||
# Required for token-based tunnel startup.
|
||||
CLOUDFLARE_TUNNEL_TOKEN=CLOUDFLARE_TUNNEL_TOKEN=eyJhIjoiYTRhNjM0NzNhNzBiZjhhYmY3OWUyNjE4ZTcyNjgwZmMiLCJ0IjoiZWY1MjFkNWItYzY1ZS00ZGFmLTlmYTMtMzQyOGYzMGUyMDY4IiwicyI6IlpHWm1NVGRsTVRVdFpEYzNaaTAwWkRJeUxXRmhPRFV0TmpKallXRmhPRFJrWXpSaSJ9
|
||||
|
||||
# --- deployment wiring helpers ---
|
||||
# Runtime Settings writes target this file path inside the app container.
|
||||
RUNTIME_SETTINGS_ENV_FILE=/app/.env.production
|
||||
@@ -1,67 +0,0 @@
|
||||
# Production environment
|
||||
|
||||
# --- NiceGUI Server ---
|
||||
HOST=0.0.0.0
|
||||
PORT=8000
|
||||
LOG_LEVEL=info
|
||||
RELOAD=false
|
||||
ENVIRONMENT=production
|
||||
# TRANSCRIPTION_COMMIT=
|
||||
RUN_EMBEDDED_WORKER=false
|
||||
LOG_DIR=/app/data/logs
|
||||
LOG_FILE_NAME=transcription.log
|
||||
LOG_FILE_MAX_BYTES=10485760
|
||||
LOG_FILE_BACKUP_COUNT=5
|
||||
|
||||
# --- AI provider ---
|
||||
PROVIDER=openrouter
|
||||
OPENROUTER_API_KEY=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
|
||||
PROVIDER_MODEL=google/gemini-2.5-flash
|
||||
PROVIDER_MODELS=["google/gemini-2.5-pro","google/gemini-2.5-flash","anthropic/claude-opus-5","anthropic/claude-sonnet-4","openai/gpt-5.6","openai/gpt-4o"]
|
||||
# OPENROUTER_HTTP_REFERER=
|
||||
# OPENROUTER_APP_TITLE=
|
||||
DEFAULT_PROMPT_NAME=transcribe_document.md
|
||||
# TRANSCRIPTION_TEMPERATURE=
|
||||
# TRANSCRIPTION_TOP_P=
|
||||
|
||||
# --- persistence ---
|
||||
# Common database settings:
|
||||
DATABASE__DRIVER=sqlite
|
||||
# DATABASE__DATABASE=transcription
|
||||
# DATABASE__USER=transcription-local
|
||||
# DATABASE__PASSWORD=My!3sons
|
||||
# BOOTSTRAP_SCHEMA_ON_STARTUP=false
|
||||
|
||||
# SQLite-specific settings:
|
||||
DATABASE__PATH=./data-local/transcription-local.db
|
||||
SQLITE_CHECK_SAME_THREAD=false
|
||||
|
||||
# Postgres-specific settings:
|
||||
# DATABASE__HOST=postgres
|
||||
# DATABASE__PORT=5432
|
||||
|
||||
# --- filesystem paths ---
|
||||
UPLOAD_DIR=./data-local
|
||||
PROMPT_DIR=/data/prompts
|
||||
# --- backup workflow helpers (not Runtime Settings model fields) ---
|
||||
BACKUP_DIR=/backup
|
||||
BACKUP_RETENTION_DAYS=14
|
||||
|
||||
# --- worker reliability ---
|
||||
WORKER_MAX_RETRIES=0
|
||||
WORKER_PROVIDER_TIMEOUT_SECONDS=30.0
|
||||
WORKER_STALE_JOB_SECONDS=30.0
|
||||
WORKER_RETRY_BACKOFF_SECONDS=1.0
|
||||
WORKER_SHUTDOWN_GRACE_SECONDS=5.0
|
||||
WORKER_POLL_INTERVAL_SECONDS=1.0
|
||||
WORKER_MIN_TRANSCRIPTION_CHARS=0
|
||||
WORKER_MIN_TRANSCRIPTION_LINES=0
|
||||
WORKER_FAIL_ON_FINISH_REASON_LENGTH=false
|
||||
|
||||
# --- cloudflare tunnel ---
|
||||
# Required for token-based tunnel startup.
|
||||
CLOUDFLARE_TUNNEL_TOKEN=CLOUDFLARE_TUNNEL_TOKEN=eyJhIjoiYTRhNjM0NzNhNzBiZjhhYmY3OWUyNjE4ZTcyNjgwZmMiLCJ0IjoiZWY1MjFkNWItYzY1ZS00ZGFmLTlmYTMtMzQyOGYzMGUyMDY4IiwicyI6IlpHWm1NVGRsTVRVdFpEYzNaaTAwWkRJeUxXRmhPRFV0TmpKallXRmhPRFJrWXpSaSJ9
|
||||
|
||||
# --- deployment wiring helpers ---
|
||||
# Runtime Settings writes target this file path inside the app container.
|
||||
RUNTIME_SETTINGS_ENV_FILE=/app/.env.production
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
name: Python Architect Reviewer
|
||||
description: Evidence-based senior architect reviewer for FastAPI, NiceGUI, and SQLModel codebases.
|
||||
skills:
|
||||
- python-code-reviewer
|
||||
---
|
||||
|
||||
# Python Architect Reviewer
|
||||
|
||||
You are a Senior Python Architect performing an evidence-based, read-only code review.
|
||||
|
||||
> No `tools:` allowlist is declared here on purpose. Tool identifiers differ between the runtimes
|
||||
> this agent is invoked from, so a hard-coded list silently under-tools the agent in one of them.
|
||||
> Read-only discipline is enforced by the **Read-Only Scope** rule below, not by the frontmatter.
|
||||
|
||||
## Operating Principles
|
||||
|
||||
- **Stack Context:** Python 3.12+, FastAPI, NiceGUI, SQLModel, SQLAlchemy (SQLite/PostgreSQL), Pydantic V2, asyncio workers, and OpenRouter adapters.
|
||||
- **Evidence-Based:** Always inspect real files. Every finding must reference concrete file paths and line numbers (e.g., `app/services/worker.py:45-78`). Do not speculate.
|
||||
- **Tool Verification:** This is a `uv` project; the toolchain is not on `PATH`. Verify with `uv run ruff check .`, `uv run ty check`, and `uv run pytest -q -m "not external"`, and record the exact commands and outcomes. Never report a lint, type, or test claim you did not run.
|
||||
- **Verify Recommendations, Not Just Findings:** Before recommending a change to a shared symbol, enumerate its consumers and confirm the fix is safe for each. See the skill's consumer-tracing step and `Blast Radius` field.
|
||||
- **Skill Is Canonical:** The `python-code-reviewer` skill defines the review workflow, deterministic checks, severity and reachability rubrics, report location, and report template. Follow it exactly. Where this file and the skill disagree, the skill wins — do not restate its specifics here.
|
||||
- **Read-Only Scope:** Do not modify source, tests, docs, instructions, or configuration. The review report is the only artifact you produce.
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
description: Require documentation updates whenever code changes alter contracts, behavior, or scope.
|
||||
applyTo: 'src/transcription/**/*.py'
|
||||
---
|
||||
|
||||
# Documentation Sync Requirements
|
||||
|
||||
Keep docs in sync in the same change whenever implementation alters a documented contract, behavior, or roadmap decision.
|
||||
|
||||
Documentation targets below always refer to the **current** baseline. `docs/index.md` states which
|
||||
baseline that is; resolve any version-specific document from there. Never cite a superseded version
|
||||
tree by name in this file or in the docs you update — retired revision trees are not authority, and
|
||||
`tests/test_meta_contract_guards.py` fails active contract files that route authority through them.
|
||||
|
||||
## Update documentation when any of these change
|
||||
|
||||
1. **Schema/Data contract**
|
||||
- Models, fields, enums, constraints, indexes, relationships, loading semantics.
|
||||
- **Required doc update:** `docs/schema.md`.
|
||||
|
||||
2. **Configuration contract**
|
||||
- `Settings` keys, defaults, required/optional environment values.
|
||||
- **Required doc update:** `.env.production.example` and any directly related setup docs.
|
||||
|
||||
3. **User-visible UI behavior**
|
||||
- Page flow, routes, button/action behavior, labels, status wording, empty/error states.
|
||||
- **Required doc update:** relevant `docs/ui/pages/*.md` docs and feature docs when applicable.
|
||||
|
||||
4. **Error handling semantics**
|
||||
- Error categories, retry behavior, envelope structure, translation boundaries.
|
||||
- **Required doc update:** `docs/error_handling.md` and `docs/invariant/error_handling.md`.
|
||||
|
||||
5. **Roadmap/scope decisions**
|
||||
- Version targets, sequencing, deferrals, and accepted alternatives.
|
||||
- **Required doc update:** `docs/roadmap_plan.md`, plus any backlog or feature document for the
|
||||
current baseline. Locate it through `docs/index.md` rather than assuming a version-named path.
|
||||
|
||||
## Working rule
|
||||
|
||||
If none of the categories above changed, documentation edits are optional.
|
||||
If any category changed, update docs in the same PR/change set rather than deferring.
|
||||
@@ -1,121 +0,0 @@
|
||||
---
|
||||
description: Cross-cutting error handling rules for services, API, and UI.
|
||||
applyTo: 'src/transcription/**/*.py'
|
||||
---
|
||||
|
||||
# Error Handling (Cross-cutting)
|
||||
|
||||
Primary references:
|
||||
|
||||
- `docs/error_handling.md`
|
||||
- `docs/invariant/error_handling.md`
|
||||
- `docs/requirements.md`
|
||||
|
||||
## Taxonomy and Categories
|
||||
|
||||
Use category-driven semantics aligned to canonical policy:
|
||||
|
||||
- `validation`
|
||||
- `not_found`
|
||||
- `conflict`
|
||||
- `external`
|
||||
- `timeout`
|
||||
- `internal`
|
||||
|
||||
Do not invent ad hoc categories in user/API-facing envelopes unless canonical docs are updated.
|
||||
|
||||
Runtime/internal categories may be more specific for diagnostics and persistence, but they must map
|
||||
deterministically to the canonical envelope categories through the centralized mapper in
|
||||
`transcription.errors.canonical_error_category`.
|
||||
|
||||
Current internal categories:
|
||||
|
||||
- `validation_error`
|
||||
- `user_input_error`
|
||||
- `not_found_error`
|
||||
- `conflict_error`
|
||||
- `external_provider_error`
|
||||
- `external_timeout_error`
|
||||
- `processing_error`
|
||||
- `infrastructure_transient_error`
|
||||
- `infrastructure_persistent_error`
|
||||
- `internal_unexpected_error`
|
||||
|
||||
Required internal -> canonical mapping:
|
||||
|
||||
- `validation_error`, `user_input_error` -> `validation`
|
||||
- `not_found_error` -> `not_found`
|
||||
- `conflict_error` -> `conflict`
|
||||
- `external_provider_error` -> `external`
|
||||
- `external_timeout_error`, `infrastructure_transient_error` -> `timeout`
|
||||
- `processing_error`, `infrastructure_persistent_error`, `internal_unexpected_error` -> `internal`
|
||||
|
||||
## Translation Boundaries
|
||||
|
||||
- **Provider/adapters:** raise provider/domain exceptions; do not emit UI text.
|
||||
- **Services:** map raw exceptions into internal categories and preserve causal chain (`raise ... from ...`).
|
||||
- **UI/API:** map internal category -> canonical envelope category and emit user-safe, actionable messages.
|
||||
|
||||
## Retry Rules
|
||||
|
||||
- No auto-retry for `validation`, `not_found`, `conflict`.
|
||||
- `external`/`timeout` may be retried when operation semantics are safe.
|
||||
- Preserve each retry as new evidence where applicable (no history rewrite).
|
||||
|
||||
## Job/Page Failure Semantics
|
||||
|
||||
- Page-level (`JobSource`): `pending`, `transcribed`, `failed`, `cancelled`.
|
||||
- Job terminals: `transcribed`, `partial_success`, `failed`.
|
||||
- Cancellation must keep job-level and page-level semantics explicit and consistent.
|
||||
- Do not emit legacy terminal state language such as `completed` in active user/API lifecycle contracts.
|
||||
|
||||
## User-Safe Messaging
|
||||
|
||||
- Never leak stack traces, credentials, auth headers, or local filesystem paths in user-facing output.
|
||||
- Include actionable remediation guidance aligned to category.
|
||||
- Keep envelope structure consistent across API endpoints.
|
||||
|
||||
### `AppError.message` vs `AppError.detail`
|
||||
|
||||
`AppError` carries two texts with different audiences, and they must not be collapsed. Getting this
|
||||
wrong has already caused a real defect in this repository, in both directions.
|
||||
|
||||
| Attribute | Audience | Reaches | Rule |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| `message` | User and API clients | `ErrorEnvelope.message`, UI notifications | Stays generic. Never embed exception text, provider payloads, or filesystem paths. |
|
||||
| `detail` | Internal only | Logs, and `format_error_detail` -> `ExecutionAttempt.error_detail` and `MaintenanceRun.error_detail` | Carries the root cause. Never rendered to users or serialized into an envelope without a sanitizing projection. |
|
||||
|
||||
- Putting root-cause data in `message` leaks infrastructure detail to users.
|
||||
- Omitting it from `detail` silently degrades the provenance record this system exists to preserve —
|
||||
a failed attempt whose `error_detail` says nothing is an attempt that cannot be diagnosed later.
|
||||
- Any render boundary that displays persisted `error_detail` must apply the same no-local-path rule
|
||||
as `message`: sanitize machine-local absolute paths before the text becomes user-visible.
|
||||
- When you raise from a caught exception, populate **both**: a generic `message` and a `detail`
|
||||
carrying `type(exc).__name__` and the exception text, with `raise ... from exc`.
|
||||
- `detail` is optional (`None`). A read path that assumes it is populated must handle its absence.
|
||||
- Before changing either attribute, or any helper that formats them, enumerate every consumer —
|
||||
evidence writes, maintenance runs, logging, API envelopes, and UI presentation all read these
|
||||
fields, and tests assert on the persisted text.
|
||||
|
||||
Canonical definitions live in `src/transcription/errors.py`; see also `docs/error_handling.md`.
|
||||
|
||||
## Logging and Diagnostics
|
||||
|
||||
- Log operation identifiers and error IDs where available.
|
||||
- Preserve category + cause-chain context.
|
||||
- Distinguish no-response timeout/network failures from returned provider error responses.
|
||||
|
||||
## Guardrails
|
||||
|
||||
- No broad catch-and-swallow patterns.
|
||||
- No success-shaped fallback values after exceptions.
|
||||
- Category mapping must remain deterministic and testable.
|
||||
|
||||
## Contract Sync Rule
|
||||
|
||||
If taxonomy, retries, or envelope semantics change:
|
||||
|
||||
1. Update canonical docs (`docs/error_handling.md`, and invariant docs if needed).
|
||||
2. Update tests in the same change.
|
||||
3. Update related instruction/skill references.
|
||||
4. If change affects persisted status/category fields, update `docs/schema.md` when applicable.
|
||||
@@ -1,122 +0,0 @@
|
||||
---
|
||||
description: Provider adapter rules for evidence capture, secret safety, and client lifecycle.
|
||||
applyTo: 'src/transcription/providers/**/*.py'
|
||||
---
|
||||
|
||||
# Provider Adapters
|
||||
|
||||
Primary references:
|
||||
|
||||
- `docs/invariant/ai_evidence_and_provenance.md` (canonical; provider adapters own provider-boundary evidence capture)
|
||||
- `docs/architecture.md`
|
||||
- `docs/schema.md`
|
||||
|
||||
The provider layer is where an external API becomes application data. It is also the only place
|
||||
that can capture what actually crossed the wire — once a response reaches a service, the evidence
|
||||
it did not preserve is gone permanently. Treat capture correctness as the primary job of this
|
||||
layer and text extraction as secondary.
|
||||
|
||||
## Layer Boundary
|
||||
|
||||
- Adapters may depend on `transcription.config`, `transcription.providers.*`, the HTTP client, and
|
||||
the provider SDK. They must not import `services`, `db`, `ui`, or `api`.
|
||||
- Provider specifics — headers, model slugs, payload shapes, SDK types, error classes — stop here.
|
||||
Callers receive `TranscriptionResult` and `ProviderError` subclasses only.
|
||||
- Adapters raise provider/domain exceptions. They must not emit user-facing text, notifications,
|
||||
or remediation wording; that translation belongs to services and UI. See
|
||||
[error-handling instructions](./error-handling.instructions.md).
|
||||
- Adapters do not persist. They return evidence; services decide what is written and when.
|
||||
|
||||
Enforced by `tests/test_provider_boundaries.py`.
|
||||
|
||||
## Contract Surface
|
||||
|
||||
- Every adapter satisfies the `TranscriptionProvider` protocol in `base.py`. Failed-call evidence is
|
||||
returned through the caller-owned `ProviderCallEvidence` sink passed to `transcribe()`, so
|
||||
evidence stays scoped to one invocation instead of living on mutable adapter instance state.
|
||||
- `TranscriptionResult`, `RequestManifest`, and `TransportEvidence` are `extra="forbid"` and frozen.
|
||||
Add a field to the contract rather than smuggling data through an untyped dict.
|
||||
- Evidence contracts in `evidence.py` are versioned (`schema_name` + `schema_version`). A change to
|
||||
the meaning or shape of a captured field requires a version bump, not a silent redefinition —
|
||||
stored evidence must keep its original meaning.
|
||||
|
||||
## Transport Evidence
|
||||
|
||||
The rules below implement `docs/invariant/ai_evidence_and_provenance.md` §3.4-3.5. That document
|
||||
wins if this file drifts from it.
|
||||
|
||||
- Capture the response body **at the HTTP boundary, before SDK parsing**, so fields the SDK does
|
||||
not model are not lost. `_CapturingAsyncClient` exists for this; do not replace it with a
|
||||
post-parse `model_dump()` and call the result transport evidence.
|
||||
- Reset per-call capture state at the start of every call. Without it, a connection failure can
|
||||
attach the *previous* call's response as evidence for this one. Guarded by
|
||||
`tests/test_evidence_provenance.py::test_openrouter_does_not_reuse_prior_response_on_connection_failure`.
|
||||
- Keep transport capture scoped to the call, not the adapter instance. Concurrent `transcribe()`
|
||||
calls on one adapter must not be able to overwrite each other's response evidence.
|
||||
- Handle the streamed-body case (`httpx.ResponseNotRead`) rather than assuming `response.content`
|
||||
is always available.
|
||||
- When no response arrives — timeout, DNS, connection reset — emit
|
||||
`TransportEvidence(response_received=False)`. Absence of a response is itself evidence and must
|
||||
be explicit, never an empty body or a missing record.
|
||||
- Preserve safe response evidence for **unsuccessful** calls too, whenever a response was received.
|
||||
- Never relabel an SDK snapshot or normalized metadata as transport evidence, and never backfill
|
||||
it into an execution that predates capture.
|
||||
|
||||
## Secret Safety
|
||||
|
||||
- Persist response headers only through `filter_safe_response_headers` and the
|
||||
`SAFE_RESPONSE_HEADERS` allowlist. Allowlist, never denylist: capture-then-redact is prohibited,
|
||||
because an unknown header is unsafe by default.
|
||||
- Adding a header to the allowlist is a deliberate evidence decision. Confirm it carries no
|
||||
credential, cookie, or session material, and state why it is needed for correlation, content
|
||||
interpretation, rate-limit diagnosis, or audit.
|
||||
- API keys, `Authorization`, and cookies must never appear in a manifest, evidence record, log
|
||||
line, or exception message.
|
||||
- The request manifest references source content by identity (digest, size, media type, page).
|
||||
Do not duplicate base64 source bytes into it — `_replace_embedded_media` exists for this.
|
||||
|
||||
## Execution Specification
|
||||
|
||||
The manifest must let a reader reconstruct what was asked, per invariant §3.3:
|
||||
|
||||
- Provider, requested model, full effective prompt text, and prompt digest.
|
||||
- Every explicitly supplied parameter, and — separately — which optional parameters were
|
||||
**omitted**. Omission is not the same as a null value or an assumed provider default; the
|
||||
`optional_parameter_states` distinction between `omitted`, `null`, and `value` is deliberate.
|
||||
- Timeout budget, retry policy, source reference, and `SoftwareContext` versions.
|
||||
- Manifest digests use `canonical_json_bytes`. Do not hash a plain `json.dumps()`; key order and
|
||||
separators must stay deterministic or digests become uncomparable.
|
||||
|
||||
## Client Lifecycle and Async Safety
|
||||
|
||||
- Reuse one pooled `AsyncClient` per adapter instance; do not construct a client per request.
|
||||
- Accept an injected client so tests can drive the adapter without network access.
|
||||
- Derive timeouts from `Settings` (`worker_provider_timeout_seconds`) rather than hard-coding, and
|
||||
keep the client timeout aligned with the configured budget so the SDK cannot expire first and
|
||||
hide the real failure.
|
||||
- Implement `aclose()` and release pooled resources. An adapter that creates a client owns closing
|
||||
it; one given a client must not close a caller-owned resource it did not create.
|
||||
- Never block the event loop. Offload CPU-bound work (hashing large payloads, image encoding) with
|
||||
`asyncio.to_thread`.
|
||||
- Propagate `asyncio.CancelledError` untouched — do not convert cancellation into a provider error.
|
||||
|
||||
## Failure Handling
|
||||
|
||||
- Raise `ProviderAuthError` for authentication, `ProviderResponseError` for malformed or unusable
|
||||
responses, and `ProviderError` otherwise.
|
||||
- Always attach `request_manifest`, `transport_evidence`, and an accurate `failure_phase` to raised
|
||||
errors. `failure_phase` must distinguish a received-but-failed response from a call that never
|
||||
reached the provider.
|
||||
- Validate responses with Pydantic rather than indexing into raw dicts.
|
||||
- Invalid *optional* metadata (for example unparsable token counts) must not discard an otherwise
|
||||
valid transcript. Degrade the metadata, not the result.
|
||||
|
||||
## Contract Sync Rule
|
||||
|
||||
If capture behavior, evidence schema, or the header allowlist changes:
|
||||
|
||||
1. Update `docs/invariant/ai_evidence_and_provenance.md` only if the durable preservation contract
|
||||
itself is changing — that revision is deliberate and reviewed, not incidental.
|
||||
2. Update `docs/schema.md` when persisted evidence fields change.
|
||||
3. Update or add tests in the same change (`tests/providers/`, `tests/test_evidence_provenance.py`).
|
||||
4. Bump the affected evidence `schema_version` when a field's meaning changes.
|
||||
@@ -1,215 +0,0 @@
|
||||
---
|
||||
description: Follow these guidelines when editing the services
|
||||
applyTo: 'src/transcription/services/*.py'
|
||||
---
|
||||
|
||||
# Services
|
||||
|
||||
## Structure
|
||||
|
||||
- Project core data models are defined in [models](../../src/transcription/db/models.py)
|
||||
- One service class per **aggregate**, not per table. An aggregate is a root model plus
|
||||
the models that have no independent lifecycle of their own. `DocumentType` has no
|
||||
meaning without `Document`, so it belongs to `DocumentService`; it does not get its
|
||||
own service. Splitting per table produces services that must reach across each other
|
||||
for every real operation, which is what line 13 forbids.
|
||||
- Only services interact with the database, and only through async methods.
|
||||
- **A service module must not import another service module.** This is enforced by
|
||||
[test_service_boundaries](../../tests/test_service_boundaries.py). Shared types go in a
|
||||
neutral module that defines no service class (see [errors](../../src/transcription/services/errors.py)).
|
||||
- Not every module in this package is a service. Modules fall into three kinds:
|
||||
- **Aggregate services** own models and define a `*Service` class: `documents.py`, `sources.py`,
|
||||
`jobs.py`, `people.py`, `photos.py`, `maintenance.py`, and `evidence.py` (read/projection only,
|
||||
owns nothing).
|
||||
- **Orchestration modules** define no service class and compose writes across aggregates:
|
||||
`store.py`, `workflows.py`. They are the sanctioned place to create or delete rows owned by more
|
||||
than one service — see [Service Composition](#service-composition).
|
||||
- **Shared infrastructure and free-function helpers** are exempt from the service rules below:
|
||||
`base.py` (`ServiceBase`), `registry.py` (`RegistryService`, a generic base for lookup tables —
|
||||
not an aggregate owner itself), `unit_of_work.py`, `errors.py`, `normalization.py`, `prompts.py`,
|
||||
`quality.py`, `media_storage.py`, `source_media.py`. `__init__.py` exposes `ServiceBundle`.
|
||||
- Cross-cutting error behavior must follow
|
||||
[error-handling instructions](./error-handling.instructions.md).
|
||||
|
||||
## Model Ownership
|
||||
|
||||
Every model has exactly one owning service. The owner defines that model's invariants and
|
||||
is the only service that may **create or delete** its rows.
|
||||
|
||||
| Model | Owner |
|
||||
| --- | --- |
|
||||
| `Document`, `DocumentType`, `DocumentTag` | `DocumentService` |
|
||||
| `Source`, `JobSource` | `SourceService` |
|
||||
| `Job` | `JobService` |
|
||||
| `Person`, `PersonRole`, `DocumentPerson`, `PersonTag` | `PeopleService` |
|
||||
| `GenealogyPerson`, `GenealogyFamily`, `GenealogyFamilyChild`, `GenealogyCitation` | `MaintenanceService` |
|
||||
| `Photo` | `PhotosService` |
|
||||
| `MaintenanceRun` | `MaintenanceService` |
|
||||
| `ExecutionAttempt` | `SourceService` |
|
||||
| `Tag` | shared — see below |
|
||||
|
||||
Keep this table complete: every table in `src/transcription/db/models.py` appears exactly once,
|
||||
except `Tag`. When you add a model, add its owner here in the same change.
|
||||
|
||||
### `Tag` is deliberately shared
|
||||
|
||||
`Tag` is one table reached through two `RegistryService[Tag]` facades that differ only in the
|
||||
reference model they count usage through: `TagRegistry` (`documents.py`, via `DocumentTag`) and
|
||||
`PersonTagRegistry` (`people.py`, via `PersonTag`). Both create and delete `Tag` rows through the
|
||||
generic registry. This is the single sanctioned exception to one-owner-per-model — do not "fix" it by
|
||||
assigning `Tag` to one service, because the other facade would then be creating rows it does not own.
|
||||
Any change to `Tag` semantics, labels, or normalization must be validated against **both** facades
|
||||
and the junction table each one counts.
|
||||
|
||||
`DocumentTag` and `PersonTag` follow the junction rule below: each is created and deleted only by the
|
||||
service on its own side.
|
||||
|
||||
### Registries
|
||||
|
||||
`DocumentTypeRegistry`, `TagRegistry`, `PersonRoleRegistry`, and `PersonTagRegistry` are
|
||||
`RegistryService` subclasses, not independent services. A registry belongs to the aggregate service
|
||||
whose module declares it and shares that service's ownership. Registry CRUD uses `<operation>_entry`
|
||||
naming (see [CRUD Methods](#crud-methods)).
|
||||
|
||||
### Junction tables
|
||||
|
||||
A junction table is owned by the service that **creates and deletes its rows** — its
|
||||
lifecycle owner. The service on the other side may read through the junction (via
|
||||
`selectinload`) but must not create rows in it.
|
||||
|
||||
- `document_person` -> `PeopleService`. Every write is there; `DocumentService` only
|
||||
eager-loads through it.
|
||||
- `job_source` -> `SourceService`, which creates the row, records each page's outcome,
|
||||
and deletes it.
|
||||
|
||||
Two consequences follow, and both are deliberate:
|
||||
|
||||
- **Cascade deletion is not a violation.** A service deleting the aggregate root it owns
|
||||
may delete rows referencing that root which cannot outlive it
|
||||
(`JobService.delete_job_with_guardrails` deletes the job's `job_source` rows).
|
||||
- **Evidence deletion is an explicit workflow, not a runtime path.** `JobService.delete_job_and_evidence`
|
||||
deletes `ExecutionAttempt` rows owned by `SourceService`. That is sanctioned because it is the
|
||||
named retention workflow that `delete_job_with_guardrails` refuses to perform implicitly — that
|
||||
method *blocks* deletion when attempts exist. Append-only means runtime code never rewrites or
|
||||
removes history to represent a new outcome; it does not forbid a deliberate, operator-invoked
|
||||
retention operation. Do not add a second path that deletes attempts.
|
||||
- **Ownership governs creation and deletion, not every state transition.** `job_source` is
|
||||
both a link and the transcription work queue. `JobService.cancel_job` and
|
||||
`resubmit_failed_sources` transition `job_source.status` across a whole job, because that
|
||||
transition is a Job lifecycle event, not a per-page outcome. They create and delete
|
||||
nothing.
|
||||
|
||||
`EvidenceService` is read-focused and projection-focused. It may coordinate selection
|
||||
flows, but append-only attempt creation remains in `SourceService` write paths.
|
||||
|
||||
If a new operation cannot be expressed within one owner, it belongs in an orchestration
|
||||
module, not in a cross-service import.
|
||||
|
||||
## Error Handling
|
||||
|
||||
- Errors used by a single service are defined at the top of that module and inherit from `AppError`.
|
||||
- Errors shared by more than one service go in [errors](../../src/transcription/services/errors.py),
|
||||
which defines no service class and is therefore importable by any of them.
|
||||
- Use a context manager for large `try/except` blocks, like `handle_transcription_errors` in
|
||||
[sources](../../src/transcription/services/sources.py).
|
||||
- Category mapping, retry behavior, and translation boundaries are defined in
|
||||
[error-handling instructions](./error-handling.instructions.md).
|
||||
- Service-edge exception translation must be deterministic: map to canonical categories and preserve clear provider->service->API/UI boundaries.
|
||||
|
||||
## Checklist
|
||||
|
||||
- [ ] Uses `ServiceBase` for common logic
|
||||
- [ ] Session kwarg for `AsyncSession` to pass a session object into each method
|
||||
- [ ] Services use `self._session_scope` in their methods to pass the session through
|
||||
- Multiple operations on the same object(s) require sharing a session between all the methods used
|
||||
- [ ] Every model the module touches is either owned by it or reached read-only
|
||||
- [ ] Evidence writes preserve append-only semantics
|
||||
|
||||
## CRUD Methods
|
||||
|
||||
- Name format `<operation>_<model>`, for example `create_document` or `update_job`.
|
||||
- Where a service exposes create/read/update/delete for its root model, define them at the
|
||||
top of the class in that order, before derived reads and workflow helpers.
|
||||
- Not every aggregate needs all four. `ExecutionAttempt` is append-only evidence written by
|
||||
`SourceService` workflow-facing methods, so `EvidenceService` deliberately exposes reads and
|
||||
no create or delete.
|
||||
Do not add unused CRUD methods to satisfy symmetry.
|
||||
- `RegistryService` is generic across small lookup models and uses `<operation>_entry`
|
||||
naming instead.
|
||||
|
||||
## 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).
|
||||
|
||||
## Workflow Transaction Boundaries
|
||||
|
||||
For multi-step job lifecycles, orchestration functions must use explicit transaction phases.
|
||||
|
||||
- **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.
|
||||
|
||||
### Multi-page batches
|
||||
|
||||
These two requirements are in tension for multi-page jobs: each page should be durable as
|
||||
soon as its provider call returns, but the last page must commit together with the terminal
|
||||
status. `process_queued_job` resolves it by committing every page except the last one
|
||||
individually, then deferring the final page's write into `_finalize_batch_outcome` so it
|
||||
shares the terminal transaction.
|
||||
|
||||
Both paths are shielded against cancellation, so the final page is no less durable than the
|
||||
pages before it. Enforced by `tests/integration/test_pipeline_atomicity.py`; per-page
|
||||
durability is separately enforced by
|
||||
`tests/services/test_workflows_reliability.py::TestWorkflowReliability::test_transcribed_page_is_committed_before_next_provider_call_finishes`.
|
||||
|
||||
### Stale-reclaim safety
|
||||
|
||||
- `WORKER_STALE_JOB_SECONDS` must remain **greater than** `WORKER_PROVIDER_TIMEOUT_SECONDS`; stale
|
||||
recovery must not be able to fire before one provider call can legitimately finish.
|
||||
- Long-running multi-page orchestration must refresh job liveness explicitly between intermediate
|
||||
page commits. Do not rely on incidental row updates or provider metadata writes to keep
|
||||
`Job.date_updated` fresh.
|
||||
- Enforced by `tests/test_config.py` and
|
||||
`tests/services/test_workflows_reliability.py::TestWorkflowReliability::test_intermediate_page_commit_advances_job_liveness_timestamp`.
|
||||
|
||||
## Contract Alignment
|
||||
|
||||
- Treat `docs/` as the active architecture and requirements baseline.
|
||||
- Legacy revision trees are out of scope for active implementation decisions and must not be referenced as authoritative service guidance.
|
||||
- Treat `src/transcription/db/models.py` as runtime schema ground truth and `docs/schema.md` as the field-accurate contract mirror.
|
||||
- `Job.status` success path is `TRANSCRIBED`.
|
||||
- `JobSource.status` is queue/projection state only (`PENDING`, `TRANSCRIBED`, `FAILED`, `CANCELLED`).
|
||||
- Source ingest may normalize media before persistence; persisted bytes/hash are canonical for processing and provenance.
|
||||
- `ExecutionAttempt` is append-only evidence history; do not mutate historical attempt rows in runtime code.
|
||||
- `Source.raw_transcription` is a projection, not authoritative history.
|
||||
- Service/UI read paths that touch relationships must be eager-loaded for `lazy="raise"` compatibility.
|
||||
- If model fields, enums, constraints, indexes, or relationship-loading semantics change, update `docs/schema.md` in the same change.
|
||||
- If `Settings` fields or defaults change in `src/transcription/config.py`, update `.env.production.example` in the same change so keys/defaults remain synchronized and no stale settings remain documented.
|
||||
|
||||
## Schema Drift and Legacy Compatibility Policy
|
||||
|
||||
- Prefer schema migration over startup reconciliation or runtime compatibility paths in service writes.
|
||||
- Do not add legacy read/write compatibility code in service workflows by default.
|
||||
- If drift is discovered and a migration decision is ambiguous (for example, one-way destructive DDL, uncertain data retention impact, or unknown deployment sequence), pause and ask the user to choose migration vs compatibility before coding.
|
||||
- If a temporary compatibility path is explicitly approved, document an expiration/removal plan in the same change.
|
||||
|
||||
# Service Composition
|
||||
|
||||
A service method may read across models it does not own, using eager loads from its own
|
||||
aggregate root. What it may not do is import another service.
|
||||
|
||||
Operations that must **write** models owned by more than one service are composed in an orchestration module
|
||||
([store](../../src/transcription/services/store.py),
|
||||
[workflows](../../src/transcription/services/workflows.py)).
|
||||
@@ -1,119 +0,0 @@
|
||||
---
|
||||
description: Authoring rules for the test suite, including markers, async discipline, and guard-test design.
|
||||
applyTo: 'tests/**/*.py'
|
||||
---
|
||||
|
||||
# Tests
|
||||
|
||||
Primary references:
|
||||
|
||||
- `AGENTS.md` (Change Protocol — failing test first)
|
||||
- `docs/index.md` and `docs/invariant/*`
|
||||
- `.github/skills/test-effectiveness-auditor/skill.md` (periodic audit of this suite)
|
||||
|
||||
The suite is not only regression protection here — it is where several architectural rules are
|
||||
*defined*. `tests/test_service_boundaries.py`, `tests/test_ui_boundaries.py`,
|
||||
`tests/test_provider_boundaries.py`, `tests/test_model_contract_guards.py`, and
|
||||
`tests/test_meta_contract_guards.py` are the enforcement layer named in the `AGENTS.md` authority
|
||||
order. A weak test in this repository does not merely fail to catch a bug; it can silently repeal a
|
||||
documented invariant.
|
||||
|
||||
The baseline is green. `uv run pytest -q -m "not external"` must report zero failures and zero
|
||||
errors, and there is no tolerated set of known-failing tests.
|
||||
|
||||
## Write the Failing Test First
|
||||
|
||||
For any behavioral fix, write the test before the fix and confirm it fails *for the reason you
|
||||
expect*. A test that passes against the broken code proves nothing, and several defects in this
|
||||
repository were subtle enough that a test written afterward would have done exactly that. If the
|
||||
new test passes immediately, you have not reproduced the defect yet.
|
||||
|
||||
## Runner Configuration
|
||||
|
||||
Configured in `pyproject.toml`; do not work around these:
|
||||
|
||||
- `--strict-markers` — an unregistered marker is an error. Register new markers in
|
||||
`[tool.pytest.ini_options] markers` with a description rather than inventing one at the call site.
|
||||
- `asyncio_mode = "strict"` — every async test needs an explicit `@pytest.mark.asyncio`, and async
|
||||
fixtures use `@pytest_asyncio.fixture`. There is no implicit promotion.
|
||||
- `filterwarnings = ["error:coroutine .* was never awaited:RuntimeWarning"]` — an un-awaited
|
||||
coroutine is an error, not a warning. This usually means a mock replaced an async callable with a
|
||||
sync one, or an `await` was dropped. Fix the call; never silence the warning.
|
||||
|
||||
## Markers and Layout
|
||||
|
||||
- `unit` — pure logic, no framework or database.
|
||||
- `integration` — touches framework, database, or multi-component contracts.
|
||||
- `external` — calls live services; slow and credential-dependent.
|
||||
|
||||
`external` tests must also carry their own `skipif` so the suite stays green without credentials
|
||||
(see `tests/services/test_transcription_external.py`). Local and documented runs use
|
||||
`-m "not external"`; CI intentionally runs unfiltered, which is equivalent because those tests skip
|
||||
themselves. Never let an unmarked test reach the network.
|
||||
|
||||
Place tests by the layer under test: `tests/services/`, `tests/ui/`, `tests/api/`,
|
||||
`tests/providers/`, `tests/integration/`, with cross-cutting guards at the top level.
|
||||
|
||||
## Fixtures and Isolation
|
||||
|
||||
- Prefer the shared fixtures in `tests/conftest.py` (`default_settings`, `async_session`,
|
||||
`default_session_factory`, and the per-aggregate service fixtures) over building settings or
|
||||
engines by hand.
|
||||
- `Settings` is isolated suite-wide by the session-scoped autouse fixture in `conftest.py`, because
|
||||
`env_file` resolves against the working directory. Tests that need env-file loading pass
|
||||
`_env_file=` explicitly; tests asserting declared defaults need nothing. Do not reintroduce
|
||||
reliance on a developer's local env file. Guarded by `tests/test_config_isolation.py`.
|
||||
- Database fixtures refuse to run against anything but the per-test path, and that refusal is
|
||||
deliberate. Never relax it to point a destructive fixture at a real database.
|
||||
- Tests must not leave artifacts outside `tmp_path`.
|
||||
|
||||
## Assertion Strength
|
||||
|
||||
Assert on the domain effect, not on the fact that code ran.
|
||||
|
||||
- Prefer persisted state, status transitions, error categories, and evidence records over
|
||||
"no exception raised", "not None", or a bare status code.
|
||||
- **Read committed state through a separate session.** Asserting against the same session that
|
||||
performed the write can pass on unflushed in-memory state and prove nothing about durability.
|
||||
This is how the atomicity guarantees in `tests/services/test_workflows_reliability.py` and
|
||||
`tests/integration/test_pipeline_atomicity.py` are made real.
|
||||
- Critical paths need negative-path coverage — timeouts, provider failures, validation errors,
|
||||
cancellation. Happy-path-only coverage of a critical module is a gap, not a suite.
|
||||
- Avoid count-threshold assertions as a proxy for correctness. A test asserting "at least N items
|
||||
were discovered" passes indefinitely while the thing it was meant to protect rots; assert on a
|
||||
specific known member instead.
|
||||
|
||||
## Guard Tests
|
||||
|
||||
Structural guards carry extra obligations, because they are cited as proof that a rule holds.
|
||||
|
||||
- **Guard the guard.** Every scanning guard needs a companion assertion that the scan actually found
|
||||
something, following the existing `test_*_are_discovered` pattern. A guard that silently scans an
|
||||
empty set passes forever.
|
||||
- **Scope must match the claim.** A guard's name and docstring must describe only what it actually
|
||||
verifies. A test covering one function while appearing to enforce a repo-wide rule is worse than
|
||||
no test, because it stops anyone from writing the real one.
|
||||
- **Prove non-vacuity by injected fault.** Temporarily introduce the violation, confirm the guard
|
||||
fails with a comprehensible message, then revert. Do this whenever you add or materially change a
|
||||
guard. Revert with an explicit edit if the file has uncommitted changes — `git checkout --` will
|
||||
discard them.
|
||||
- **Prefer structural analysis to substring matching.** AST inspection of imports and definitions is
|
||||
resistant to false negatives; a bare-name search across the repository is not, since an unrelated
|
||||
mention anywhere makes dead code look reachable.
|
||||
- Failure messages should name the offending file, symbol, and the remedy. These fire for people who
|
||||
did not write the guard.
|
||||
- Any new file under `.github/**` must be added to `ACTIVE_CONTRACT_FILES` in
|
||||
`tests/test_meta_contract_guards.py`, or the completeness guard fails by design.
|
||||
|
||||
## Redundancy
|
||||
|
||||
Duplicate coverage across layers costs runtime and dilutes signal. Pick the canonical layer for a
|
||||
behavior — unit for logic, integration for wiring — and let the other layer assert only what is
|
||||
unique to it. Retire tests superseded by a stronger guard instead of accumulating both, and record
|
||||
deliberate retentions with a rationale rather than leaving them unexplained.
|
||||
|
||||
## Contract Sync Rule
|
||||
|
||||
When a test encodes or relaxes a documented rule, update the corresponding instruction file or
|
||||
`docs/*` page in the same change. When a guard test is the enforcement for a rule stated in
|
||||
`AGENTS.md` or an instruction file, cite the test by name there so the link survives refactoring.
|
||||
@@ -1,78 +0,0 @@
|
||||
---
|
||||
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.
|
||||
|
||||
Cross-cutting error behavior must follow
|
||||
[error-handling instructions](./error-handling.instructions.md).
|
||||
|
||||
## 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.
|
||||
- Use `components/media_urls.py` for media URL generation; do not hand-build upload/static paths in page code.
|
||||
|
||||
## 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.
|
||||
- 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.
|
||||
- Keep filesystem, network, provider, and worker orchestration behind application services or dedicated adapters.
|
||||
|
||||
## Media Route Safety Rules
|
||||
|
||||
Two patterns are approved:
|
||||
|
||||
1. **Record-validated API routes** for print/export contexts.
|
||||
2. **Controlled upload URL resolver** (`components/media_urls.py`) for general UI media.
|
||||
|
||||
Prohibited patterns:
|
||||
|
||||
- Direct `file://` links or exposing local filesystem paths.
|
||||
- Manual URL construction from raw `Path` values in pages/components.
|
||||
- User-facing payloads containing local absolute paths.
|
||||
|
||||
## Contract Alignment
|
||||
|
||||
- Treat `docs/` as the active baseline.
|
||||
- Resolve lifecycle and status semantics against `src/transcription/db/models.py` and `docs/schema.md`; do not introduce alternate status labels or implied legacy states in UI behavior.
|
||||
- Use status vocabulary exactly as modeled (`queued`, `processing`, `transcribed`, `partial_success`, `failed`; and `pending`, `transcribed`, `failed`, `cancelled`).
|
||||
- Print/export media flows must use record-validated routes; direct local filesystem paths are prohibited.
|
||||
- If lifecycle wording/behavior changes, update corresponding `docs/ui/pages/*.md` contracts in the same change.
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
name: Review Python Architecture
|
||||
description: Run an evidence-based architectural code review using the Python Architect Reviewer agent and python-code-reviewer skill.
|
||||
agent: Python Architect Reviewer
|
||||
---
|
||||
|
||||
# Instructions
|
||||
|
||||
Execute a comprehensive, evidence-based code review of the target codebase.
|
||||
|
||||
## Target Scope
|
||||
- **Review Target:** the repository root, unless the invoker names a narrower path; review that path instead.
|
||||
- **Source Root:** `src/`
|
||||
- **Docs Root:** `docs/`
|
||||
- **Focus Areas:** FastAPI endpoints, NiceGUI components, SQLModel persistence, asyncio workers, Pydantic V2 models, and OpenRouter provider adapters.
|
||||
|
||||
## Execution Rules
|
||||
1. Map repository layout, dependency manifests, and configuration files from the project root before inspecting modules.
|
||||
2. Read real code modules under `src/` (or the specified target path); cite exact file paths and line ranges for every finding.
|
||||
3. Validate issues by running `uv run ruff check .`, `uv run ty check`, and `uv run pytest -q -m "not external"`. Nothing is on `PATH` in this `uv` project, so bare `ruff`/`ty`/`pytest` will fail.
|
||||
4. Check for duplication, divergent implementations, and extractable helpers.
|
||||
5. Format the entire review following the standardized 10-section template defined in the `python-code-reviewer` skill.
|
||||
6. Write the final report to `./docs/reviews/<YYYY-MM-DD>-code-review.md`, using today's date. This path is defined by the skill; do not write the report anywhere else.
|
||||
@@ -1,80 +0,0 @@
|
||||
---
|
||||
name: evidence-provenance-auditor
|
||||
description: Deterministic reviewer for transcription evidence/provenance guarantees. Use when changes touch execution attempts, source storage, retries, transport evidence, artifact provenance, or evidence exports.
|
||||
---
|
||||
|
||||
# Evidence & Provenance Auditor
|
||||
|
||||
Perform focused, deterministic audits of evidence integrity and provenance behavior.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Reviewing changes in:
|
||||
- `src/transcription/services/sources.py`
|
||||
- `src/transcription/services/store.py`
|
||||
- `src/transcription/services/workflows.py`
|
||||
- `src/transcription/services/evidence.py`
|
||||
- `src/transcription/db/models.py`
|
||||
- Auditing evidence exports/imports or evidence-display behavior.
|
||||
- Verifying no drift from canonical provenance invariants.
|
||||
|
||||
## Normative References (must be used)
|
||||
|
||||
1. `docs/invariant/ai_evidence_and_provenance.md`
|
||||
2. `docs/schema.md`
|
||||
3. `docs/requirements.md`
|
||||
4. `docs/error_handling.md`
|
||||
|
||||
## Deterministic Pass/Fail Checks
|
||||
|
||||
### A. Append-only history
|
||||
- Every provider call results in a new `ExecutionAttempt`.
|
||||
- Runtime paths do not mutate historical attempts to represent new outcomes.
|
||||
- Retry behavior appends attempts rather than rewriting prior rows.
|
||||
|
||||
### B. Projection vs authority separation
|
||||
- `Source.raw_transcription` and preferred pointers are mutable projection surfaces.
|
||||
- Attempt rows remain authoritative historical evidence.
|
||||
- Candidate promotion updates projection pointers without rewriting history.
|
||||
|
||||
### C. Transport evidence semantics
|
||||
- Transport evidence is correctly labeled as application-boundary capture.
|
||||
- SDK snapshots/normalized metadata are not mislabeled as native upstream payload.
|
||||
- No-response timeout/network states are explicit.
|
||||
|
||||
### D. Canonical source identity
|
||||
- Canonical stored bytes/hash/size are internally consistent.
|
||||
- If ingest normalization is applied, code/docs consistently represent resulting canonical identity.
|
||||
- Post-ingest derivatives do not overwrite canonical source bytes.
|
||||
|
||||
### E. Secret safety
|
||||
- No credentials/auth headers/cookies/unrestricted headers persisted.
|
||||
- Header persistence uses explicit allowlist semantics.
|
||||
|
||||
### F. Route/path safety
|
||||
- Print/export source access is record-validated.
|
||||
- UI/media path construction does not expose local filesystem paths.
|
||||
|
||||
### G. Schema/docs alignment
|
||||
- Evidence-related model fields and semantics align with canonical docs.
|
||||
- Evidence model changes require same-change doc updates.
|
||||
|
||||
### H. Canonical authority boundaries
|
||||
- Active guidance resolves against `docs/*` and current instruction files.
|
||||
|
||||
## Review Workflow
|
||||
|
||||
1. Read normative references first.
|
||||
2. Inspect model + service + workflow write paths.
|
||||
3. Inspect evidence read/display/export paths.
|
||||
4. Report high-confidence findings with concrete path/line evidence.
|
||||
5. Classify each finding by invariant family (A-H).
|
||||
|
||||
## Output Format
|
||||
|
||||
Use this structure:
|
||||
|
||||
- Verdict by invariant family (A-H)
|
||||
- Findings with `Location`, `Observed Behavior`, `Risk`, `Recommended Fix`
|
||||
- Drift table (`Doc claim` vs `Code reality` vs `Action`)
|
||||
- Regression guards needed
|
||||
@@ -1,276 +0,0 @@
|
||||
---
|
||||
name: python-code-reviewer
|
||||
description: Perform an evidence-based, senior architect code review for Python codebases using FastAPI, NiceGUI, SQLModel, SQLAlchemy, Pydantic V2, asyncio, and OpenRouter. Use when asked to review Python repositories, perform architectural or code audits, or evaluate code against Python 3.12+ best practices.
|
||||
---
|
||||
|
||||
# Python Code Reviewer
|
||||
|
||||
Perform thorough, evidence-based code reviews for Python projects. Every finding must cite concrete file paths and line ranges, avoid speculation, and include recommended fixes.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Performing an architectural or code quality review of a Python codebase.
|
||||
- Auditing applications using FastAPI, NiceGUI, SQLModel/SQLAlchemy, Pydantic V2, or asyncio workers.
|
||||
- Generating structured Markdown review reports in `./docs/reviews`.
|
||||
|
||||
## Technical Stack Scope
|
||||
|
||||
- **Runtime:** Python 3.12+
|
||||
- **Web Application:** FastAPI and NiceGUI
|
||||
- **Persistence:** SQLModel, SQLAlchemy (SQLite and PostgreSQL support)
|
||||
- **Validation & Settings:** Pydantic V2 and pydantic-settings
|
||||
- **Concurrency:** Python asyncio workers
|
||||
- **Vision/LLM Integration:** OpenRouter / provider adapters
|
||||
- **Image & Print Pipeline:** Pillow-backed media handling and print/export rendering
|
||||
- **Quality & Testing:** pytest, pytest-asyncio, Ruff, and ty
|
||||
|
||||
NiceGUI is pinned to an exact version (`nicegui==3.13.0` in `pyproject.toml`); API guidance
|
||||
must be correct for that release rather than for the latest published version. The exact pin is
|
||||
a deliberate release-stability decision recorded in `docs/production-runbook.md` ("Dependency
|
||||
upgrade policy") — do not report it as a defect or recommend widening it.
|
||||
|
||||
## Review Workflow
|
||||
|
||||
1. **Map the Repository First:** Inspect entry points, package layout, configurations, dependency manifests, and any project-specific rule files (`AGENTS.md`, `.github/instructions/`, `.github/skills/`). Project-specific conventions override generic advice.
|
||||
2. **Establish Canonical Authority First:** Read architecture/contracts (`docs/*`, `docs/invariant/*`, UI docs) and active instructions/skills before evaluating source behavior.
|
||||
3. **Read Representative Modules:** Sample across all layers (routes/pages, UI components, services, workers, persistence, provider adapters, settings, tests) before drawing conclusions.
|
||||
4. **Run Drift Analysis:** Compare documented intended behavior versus repository ground truth; identify both implementation drift and undocumented-but-repeatable conventions that should be formalized.
|
||||
5. **Run Dead-Code/Orphan Sweep:** Identify candidate orphan modules/functions/classes with zero inbound references, then verify expected exceptions (entrypoints, framework/plugin registration, dynamic imports/reflection, CLI hooks, test-only utilities) before marking as orphaned.
|
||||
6. **Assess Boundary and Coupling Health:** Evaluate UI/service/persistence/provider dependency flow, identify circular dependencies, leaky abstractions, and transaction ownership ambiguity.
|
||||
7. **Assess Invariant Placement:** For each hard rule, decide whether it belongs in docs (rationale), instructions (active steering), skills (periodic audit procedure), or deterministic tests (enforcement).
|
||||
8. **Verify Claims:** This is a `uv` project (`uv.lock`, root `ruff.toml`). Run `uv run ruff check .`, `uv run ty check`, and `uv run pytest -q -m "not external"` rather than guessing, and record the exact commands and their outcomes in the report.
|
||||
9. **Validate Recommendations Against Consumers:** A recommendation is a claim about the future and must be verified like any other. Before recommending a change to a shared symbol — a model field, an exception attribute, a helper's return value, a function signature — enumerate **every** consumer of that symbol (`grep` the whole repo, including tests) and confirm the fix is safe for each one. Record the consumers in the finding's **Blast Radius**. A fix that is correct for the path that produced the finding can silently break a second consumer, and evidence/provenance and logging paths are the usual casualties because they read the same fields the UI does.
|
||||
10. **Prioritize Hot Paths:** Focus deeply on request handling, database sessions, background workers, and external API calls.
|
||||
11. **Enforce Read-Only Safety:** Do not modify code unless explicitly instructed.
|
||||
12. **Escalate Provenance Audits:** For evidence/provenance-heavy changes, apply invariant checks from `.github/skills/evidence-provenance-auditor/skill.md` and include pass/fail outcomes in the report.
|
||||
13. **Escalate Test-Suite Audits:** When findings touch test coverage, redundancy, or assertion strength, apply `.github/skills/test-effectiveness-auditor/skill.md` and include its outcomes alongside the provenance results.
|
||||
|
||||
### Worked example: why step 9 exists
|
||||
|
||||
The 2026-08-23 review recommended fixing a filesystem-path leak in
|
||||
`classify_unexpected_error` by making `AppError.message` generic and logging the exception
|
||||
detail instead. The analysis of the leak was correct, and the fix was implemented as written.
|
||||
|
||||
It was wrong. `AppError.message` had a second consumer the review never traced:
|
||||
`format_error_detail`, which writes `ExecutionAttempt.error_detail` — a **provenance record**.
|
||||
The recommended fix closed a privacy leak by silently stripping root-cause data from the
|
||||
evidence history this system exists to preserve. It was caught only because an unrelated
|
||||
integration test asserted on the persisted error text.
|
||||
|
||||
The correct fix separated the audiences — a user-safe `message` and an internal-only `detail`
|
||||
that still reaches evidence and logs. One `grep` for consumers of `.message` during the review
|
||||
would have found this. Treat any recommendation that changes a widely-read field as unverified
|
||||
until its consumers are enumerated.
|
||||
|
||||
## Repo-Specific Deterministic Checks (Transcription)
|
||||
When reviewing this repository, always include explicit pass/fail checks for the following.
|
||||
Where **Enforced by** reads *unenforced*, recommending a deterministic test is itself a finding.
|
||||
|
||||
| # | Check | Enforced by |
|
||||
| :-- | :--- | :--- |
|
||||
| 1 | **Service boundary rule:** no service-to-service imports | `tests/test_service_boundaries.py` |
|
||||
| 2 | **UI boundary rule:** pages/components do not perform persistence access | `tests/test_ui_boundaries.py` |
|
||||
| 3 | **Status vocabulary conformance:** `JobStatus`/`JobSourceStatus`/`JobPurpose` usage matches current enums in `src/transcription/db/models.py`; no stringly-typed status literals | `tests/test_model_contract_guards.py` |
|
||||
| 4 | **Evidence ownership conformance:** append-only attempt history is preserved and projection writes are not mistaken for history mutation (`src/transcription/services/sources.py`, `src/transcription/services/evidence.py`) | `tests/test_evidence_provenance.py::test_attempts_are_append_only_and_exported_with_integrity` |
|
||||
| 5 | **Canonical authority:** findings must resolve against `docs/*` first | `tests/test_meta_contract_guards.py::test_canonical_authority_references_are_present` |
|
||||
| 6 | **Schema contract fidelity:** when model/persistence behavior changes, `docs/schema.md` remains field-accurate with `src/transcription/db/models.py` | `tests/test_model_contract_guards.py` (field names, ordering, enum members, table coverage), `tests/test_meta_contract_guards.py` (presence and references) |
|
||||
| 7 | **Media boundary conformance:** print/export media is record-validated and UI media URL generation uses controlled resolver paths | `tests/test_media_path_safety.py`, `tests/ui/test_media_urls.py` |
|
||||
| 8 | **Eager-loading conformance:** service/UI read paths satisfy `lazy="raise"` expectations | `tests/test_model_contract_guards.py` (declaration-side; documented `noload` exceptions must match `docs/schema.md`) |
|
||||
| 9 | **Cross-cutting error conformance:** service/API/UI translation and retry behavior align with `.github/instructions/error-handling.instructions.md` | `tests/test_errors.py`, `tests/api/test_error_responses.py`, `tests/ui/test_error_presenter.py` |
|
||||
| 10 | **Orphaned/dead-code conformance:** include a deterministic orphan sweep and report confirmed orphans removed/retained with rationale | `tests/test_orphan_sweep.py` (`KNOWN_ORPHANS` records each retained orphan and its rationale) |
|
||||
|
||||
## Core Review Areas
|
||||
|
||||
### 1. Python Best Practices (3.12+)
|
||||
- **Type Annotations:** Ensure completeness, modern syntax (`X | None`, builtin generics, `Self`, `type` statements), and avoid unparameterized containers or bare `Any`.
|
||||
- **Error Handling:** Identify bare/broad `except`, swallowed exceptions, missing `raise ... from`, and exceptions used for control flow.
|
||||
- **Resource Management:** Verify context managers for files, DB sessions, HTTP clients, and locks. Check for leaked tasks or connections.
|
||||
- **Data Modeling:** Check proper use of dataclasses vs. Pydantic models vs. dictionaries. Eliminate mutable default arguments and stringly-typed payloads.
|
||||
- **Idioms & Clean Code:** Verify `pathlib` usage over `os.path`, comprehensions vs manual loops, removal of dead code, and elimination of magic numbers.
|
||||
|
||||
### 2. FastAPI
|
||||
- **Dependency Injection:** Verify `Depends` is used for shared resources (DB sessions, settings, clients) rather than global singletons.
|
||||
- **Route Design:** Validate HTTP verbs, status codes, path/query/body typing, `response_model`, and domain-based router organization.
|
||||
- **Lifecycle & Concurrency:** Ensure lifespan handlers are used instead of deprecated `@app.on_event`. Flag blocking synchronous calls in `async def` endpoints.
|
||||
|
||||
### 3. NiceGUI
|
||||
- **Separation of Concerns:** Ensure UI components delegate business logic and persistence to service layers.
|
||||
- **Client State Handling:** Verify correct use of client-scoped state vs global state to avoid state leaks across sessions.
|
||||
- **Async Execution:** Check for blocking operations on the UI event loop and unbounded timers/pollers.
|
||||
|
||||
### 4. Persistence (SQLModel / SQLAlchemy)
|
||||
- **Session Lifecycle:** Enforce one session per request/unit of work with explicit commit/rollback/close boundaries.
|
||||
- **Query Optimization:** Detect N+1 patterns, missing eager loads (`selectinload`/`joinedload`), queries inside loops, and unindexed filters.
|
||||
- **Cross-Dialect Portability:** Check compatibility for both SQLite (WAL mode, pragmas) and PostgreSQL (JSONB, locking, autoincrement).
|
||||
|
||||
### 5. Pydantic V2 & Settings
|
||||
- **V2 Migration:** Flag legacy V1 patterns (`@validator`, `Config` class, `.dict()`, `parse_obj`) and use V2 equivalents (`@field_validator`, `model_config = ConfigDict(...)`, `model_dump()`).
|
||||
- **Settings Management:** Ensure `BaseSettings` is the single source of truth without scattered `os.getenv` calls or committed secrets.
|
||||
|
||||
### 6. Concurrency & Asyncio Workers
|
||||
- **Task Lifecycle:** Flag unreferenced `create_task` calls that risk garbage collection, missing cancellation handling, and lack of graceful shutdown.
|
||||
- **Backpressure & Synchronization:** Check for appropriate use of `asyncio.Queue`, `TaskGroup`, `Lock`, and backoff retries.
|
||||
|
||||
### 7. Provider Adapters (OpenRouter / APIs)
|
||||
- **Adapter Encapsulation:** Verify provider-specific details (headers, model names, payload formats) do not leak into UI or business logic.
|
||||
- **Client Lifecycle:** Reuse shared `AsyncClient` instances with proper connection pooling and timeouts. Validate API responses using Pydantic schemas.
|
||||
|
||||
### 8. Testing & Quality Tooling
|
||||
- **Test Isolation:** Verify tests do not rely on live external services, real clocks, or shared global state.
|
||||
- **Async Test Setup:** Check `pytest-asyncio` configuration and fixture lifecycle.
|
||||
- **Project Test Contract (`pyproject.toml`):** `--strict-markers` is enabled, so every marker must be declared; `asyncio_mode = "strict"` requires explicit `@pytest.mark.asyncio`; declared markers are `unit`, `integration`, and `external`, and `external` must be excluded from default verification runs. `filterwarnings` promotes `coroutine ... was never awaited` to an **error** — treat any unawaited coroutine as a hard failure and a Critical/High finding, never a warning.
|
||||
- **Suite Signal Quality:** For low-value, redundant, or tautological tests, escalate to `.github/skills/test-effectiveness-auditor/skill.md` and fold its outcomes into the report.
|
||||
|
||||
### 9. Duplication & Consolidation
|
||||
- Identify repeated code blocks, candidate helper abstractions, divergent patterns for identical operations, and duplicated domain constants.
|
||||
|
||||
### 10. Orphaned/Dead Code Audit
|
||||
- Find candidate orphan modules/functions/classes with no inbound references.
|
||||
- Validate each candidate against dynamic wiring exceptions (entrypoints, plugin registration, reflection/dynamic imports, CLI hooks, test utilities).
|
||||
- Report outcomes as: removed orphan, retained-with-justification, or uncertain-follow-up.
|
||||
|
||||
### 11. Architecture & Governance
|
||||
- **Architectural Drift:** Compare intended architecture rules against implementation behavior and cite concrete drift points.
|
||||
- **Systemic Health:** Evaluate domain cohesion, dependency direction, lifecycle consistency, and operational reliability seams.
|
||||
- **Invariant Routing:** Recommend the correct enforcement layer per rule (docs vs instructions vs skills vs tests).
|
||||
- **Meta-Tooling Alignment:** Recommend updates for instruction files and skills when repository patterns or contracts evolve.
|
||||
|
||||
## Severity Rubric
|
||||
|
||||
Severity reflects concrete consequence, never style preference or effort to fix.
|
||||
|
||||
- **Critical:** Data or evidence loss/corruption; provenance or append-only history violated; secret leakage; silent wrong output presented as authoritative.
|
||||
- **High:** Architectural boundary violated (service/UI/persistence/provider); runtime failure or unhandled exception on a hot path (request handling, DB sessions, worker loop, external API calls); documented invariant contradicted by implementation.
|
||||
- **Medium:** Correctness risk under load or edge conditions (N+1, missing eager load, leaked task, missing timeout); drift between docs and code with no immediate runtime impact.
|
||||
- **Low:** Maintainability, typing completeness, duplication, naming, or dead code with no behavioral risk.
|
||||
|
||||
### Reachability
|
||||
|
||||
Severity states how bad the consequence is; **Reachability** states whether it can happen today.
|
||||
They are independent, and a finding is not complete without both. Record one of:
|
||||
|
||||
- **Live:** reachable in the current configuration and deployment.
|
||||
- **Latent:** the defective code is present but unreachable because of a current setting, single-
|
||||
instance deployment, or absent caller. **State the exact condition that unblocks it.**
|
||||
- **Theoretical:** requires a combination the project has explicitly ruled out.
|
||||
|
||||
Latent findings carry a scheduling constraint that severity alone cannot express: a latent defect
|
||||
must usually be fixed *before* the change that makes it live, not after. Say so explicitly in the
|
||||
finding and reflect the ordering in the §9 action plan — for example, "fix the retry-category gate
|
||||
before raising `worker_max_retries` above 0," or "handle this `IntegrityError` before deploying a
|
||||
second worker replica." Do not downgrade severity merely because a finding is latent.
|
||||
|
||||
### Conflicting invariants
|
||||
|
||||
When a fix sits between two invariants that pull in opposite directions, say so in the
|
||||
**Recommendation** and name both, along with the test that guards each. Flag explicitly what the
|
||||
over-correction would be, because the simplest-looking fix usually satisfies one invariant by
|
||||
silently destroying the other. A recommendation that resolves one side without naming the other is
|
||||
incomplete and will be implemented incorrectly.
|
||||
|
||||
## Output Report Structure & Template
|
||||
|
||||
Generate Markdown reports at `./docs/reviews/<YYYY-MM-DD>-code-review.md` following this exact
|
||||
template structure. Reports are dated, non-canonical artifacts: `docs/reviews/**` is explicitly
|
||||
**not** part of the canonical authority set that the canonical-authority check resolves against.
|
||||
|
||||
```markdown
|
||||
# Architecture & Code Review Report
|
||||
|
||||
**Repository Target:** `project-root/`
|
||||
**Target Stack:** Python 3.12+ | FastAPI | NiceGUI | SQLModel/SQLAlchemy | Pydantic V2 | asyncio | OpenRouter
|
||||
|
||||
---
|
||||
|
||||
## 1. Executive Summary
|
||||
- 5-10 bullets on overall health, top risks, and high-leverage refactors.
|
||||
|
||||
---
|
||||
|
||||
## 2. Executive Architecture Assessment
|
||||
- High-level verdict on domain cohesion, boundary clarity, and architecture fitness.
|
||||
- Top 3-5 systemic risks or bottlenecks.
|
||||
|
||||
---
|
||||
|
||||
## 3. Findings by Severity
|
||||
|
||||
### Critical Severity
|
||||
#### [CRIT-01] Title
|
||||
- **Location:** `path/to/file.py:lines`
|
||||
- **Reachability:** Live / Latent (state the exact condition that unblocks it) / Theoretical
|
||||
- **Problem & Consequence:** Concrete consequence, not a style opinion.
|
||||
- **Blast Radius:** Every consumer of the symbols the recommendation changes, each confirmed
|
||||
safe. Write `None — change is local` only after actually searching. If the fix touches a
|
||||
shared field or helper, list the call sites (including tests and evidence/logging paths).
|
||||
- **Recommendation:** Fix with before/after sketch. If two invariants conflict here, name both,
|
||||
name the test guarding each, and state what the over-correction would be.
|
||||
- **Effort:** S / M / L
|
||||
|
||||
### High Severity
|
||||
#### [HIGH-01] Title
|
||||
...
|
||||
|
||||
### Medium Severity
|
||||
#### [MED-01] Title
|
||||
...
|
||||
|
||||
### Low Severity
|
||||
#### [LOW-01] Title
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
## 4. Architectural Drift & Gap Analysis
|
||||
|
||||
`Direction` is `doc->code` (implementation must change to match documented intent) or
|
||||
`code->doc` (an undocumented but repeatable convention that should be formalized).
|
||||
|
||||
| Area / Component | Direction | Documented / Intended Rule | Actual Implementation State | Severity | Recommended Resolution |
|
||||
| :--- | :--- | :--- | :--- | :--- | :--- |
|
||||
|
||||
---
|
||||
|
||||
## 5. Invariant Inventory & Routing Recommendations
|
||||
| Invariant / Constraint | Current Location | Recommended Target Layer | Rationale |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
|
||||
---
|
||||
|
||||
## 6. Stack-Specific Analysis
|
||||
- Python 3.12+ Best Practices
|
||||
- FastAPI
|
||||
- NiceGUI
|
||||
- SQLModel & SQLAlchemy
|
||||
- Pydantic V2 & Settings
|
||||
- Asyncio Workers
|
||||
- OpenRouter / Adapter Boundary
|
||||
- Testing & Quality Tooling
|
||||
|
||||
---
|
||||
|
||||
## 7. Duplication & Consolidation Report
|
||||
| Pattern / Duplication | Locations | Proposed Canonical Home | Estimated Lines Removed |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
|
||||
### Proposed Canonical Abstractions
|
||||
- Code signatures and implementation homes.
|
||||
|
||||
---
|
||||
|
||||
## 8. Meta-Tooling & Instruction Update Recommendations
|
||||
- Required updates to docs, instructions, skills, or tests to keep enforcement current.
|
||||
|
||||
---
|
||||
|
||||
## 9. Prioritized Dependency-Ordered Action Plan
|
||||
1. **Phase 1: Blocking fixes**
|
||||
2. **Phase 2: Enforcement hardening**
|
||||
3. **Phase 3: Reliability & concurrency**
|
||||
4. **Phase 4: Consolidation & refactoring**
|
||||
5. **Phase 5: Non-blocking governance/documentation depth**
|
||||
|
||||
---
|
||||
|
||||
## 10. Preserved Strengths
|
||||
- Existing patterns worth maintaining.
|
||||
@@ -1,98 +0,0 @@
|
||||
---
|
||||
name: test-effectiveness-auditor
|
||||
description: Periodic reviewer for test-suite signal quality. Detects low-value or redundant tests, validates contract coverage, and recommends pruning or strengthening actions.
|
||||
---
|
||||
|
||||
# Test Effectiveness Auditor
|
||||
|
||||
Run a deterministic audit of test usefulness. Focus on whether tests catch real regressions, not whether they merely execute code.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Monthly/quarterly test-health review.
|
||||
- Pre-release hardening when test count grows quickly.
|
||||
- After major AI-assisted test generation.
|
||||
- When suite runtime is increasing without clear quality gains.
|
||||
|
||||
## Primary Objectives
|
||||
|
||||
1. Identify tests that are weak, redundant, or non-diagnostic.
|
||||
2. Confirm critical contracts are guarded by meaningful assertions.
|
||||
3. Produce a prune/strengthen backlog with explicit risk and effort.
|
||||
|
||||
## Normative References (Transcription Repo)
|
||||
|
||||
1. `docs/*`
|
||||
2. `docs/invariant/*`
|
||||
3. `.github/instructions/*.instructions.md`
|
||||
4. `tests/test_meta_contract_guards.py`
|
||||
5. Contract-specific guards (`tests/test_service_boundaries.py`, `tests/test_ui_boundaries.py`, worker/evidence/media/error suites)
|
||||
|
||||
## Deterministic Audit Checks
|
||||
|
||||
### A. Contract Traceability
|
||||
- Each high-risk contract maps to at least one focused regression test file.
|
||||
- Missing mapping is a gap.
|
||||
|
||||
### B. Assertion Strength
|
||||
- Flag tests that only assert status code, non-null, or “no exception” without validating state transitions or persisted outcomes.
|
||||
- Prefer assertions on domain effects: DB rows, status changes, error categories, evidence writes, or emitted payload shape.
|
||||
|
||||
### C. Failure-Path Coverage
|
||||
- Critical paths must include negative-path tests (timeouts, provider errors, validation failures, cancellation paths, retries).
|
||||
- Happy-path-only coverage on critical modules is a gap.
|
||||
|
||||
### D. Redundancy and Noise
|
||||
- Detect near-duplicate tests asserting the same behavior at multiple layers with no extra signal.
|
||||
- Recommend canonical location (unit/integration) and prune overlaps.
|
||||
|
||||
### E. Mutation/Change Sensitivity
|
||||
- Prefer mutation testing for high-risk modules when practical.
|
||||
- If not run, identify tests likely to survive meaningful code mutations (low sensitivity).
|
||||
|
||||
### F. Drift Guards
|
||||
- Verify config/doc/instruction contracts have deterministic guards and are current.
|
||||
- Ensure settings/docs synchronization checks remain active.
|
||||
|
||||
## Evidence Standards
|
||||
|
||||
- Every finding must include concrete file paths and line ranges.
|
||||
- No speculative claims.
|
||||
- Distinguish clearly between:
|
||||
- **Confirmed ineffective tests**
|
||||
- **Likely weak tests (needs mutation/probe confirmation)**
|
||||
|
||||
## Output Format
|
||||
|
||||
Produce a Markdown report at `docs/reviews/<YYYY-MM-DD>-test-effectiveness.md`, using today's date.
|
||||
Like code review reports, it is a dated, non-canonical artifact: `docs/reviews/**` is not part of the
|
||||
canonical authority set.
|
||||
|
||||
```markdown
|
||||
# Test Effectiveness Audit Report
|
||||
|
||||
## 1. Executive Verdict
|
||||
- Effective / Effective with Conditions / Needs Remediation
|
||||
- Top risks to confidence
|
||||
|
||||
## 2. Contract Coverage Matrix
|
||||
| Contract | Guarding Tests | Signal Quality | Gap | Action |
|
||||
| :--- | :--- | :--- | :--- | :--- |
|
||||
|
||||
## 3. Weak/Redundant Test Findings
|
||||
| Finding ID | Location | Why Low-Signal | Risk | Recommendation |
|
||||
| :--- | :--- | :--- | :--- | :--- |
|
||||
|
||||
## 4. Prune/Strengthen Backlog
|
||||
| Task ID | Goal | Files | Acceptance Criteria | Validation |
|
||||
| :--- | :--- | :--- | :--- | :--- |
|
||||
|
||||
## 5. Confidence Recommendation
|
||||
- Go / Go with Conditions / No-Go for release confidence
|
||||
```
|
||||
|
||||
## Decision Rules
|
||||
|
||||
- Do not recommend deleting a test unless equivalent or stronger coverage is identified.
|
||||
- Prefer strengthening assertions before adding more tests.
|
||||
- Prioritize deterministic contract guards over broad snapshot-style tests.
|
||||
@@ -1,50 +0,0 @@
|
||||
name: Quality Gate
|
||||
|
||||
# Repository quality gate. Before this workflow existed, ruff, ty, and pytest were
|
||||
# enforced only by .pre-commit-config.yaml for developers who had run
|
||||
# `pre-commit install`.
|
||||
|
||||
on:
|
||||
push:
|
||||
pull_request:
|
||||
|
||||
jobs:
|
||||
gate:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Check out the commit under test
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Install uv
|
||||
run: |
|
||||
curl -LsSf https://astral.sh/uv/install.sh | sh
|
||||
echo "$HOME/.local/bin" >> "$GITHUB_PATH"
|
||||
|
||||
- name: Install dependencies from the lockfile
|
||||
# --locked fails if uv.lock has drifted from pyproject.toml, so a stale
|
||||
# lockfile is caught here rather than producing an untested dependency set.
|
||||
run: uv sync --locked
|
||||
|
||||
- name: Write placeholder configuration
|
||||
# Settings requires openrouter_api_key and 115 tests cannot construct
|
||||
# Settings without it. This is written to .env.production rather than exported
|
||||
# as an environment variable on purpose: the external tests guard on
|
||||
# os.getenv("OPENROUTER_API_KEY"), which reads the process environment and
|
||||
# not the file, so writing the file reproduces the local result exactly -
|
||||
# the 4 external tests skip instead of running against a fake key and
|
||||
# failing. Exporting it instead produces 3 failures.
|
||||
run: echo "OPENROUTER_API_KEY=ci-placeholder-not-a-real-key" > .env.production
|
||||
|
||||
- name: Lint and type check
|
||||
# Runs the hooks defined in .pre-commit-config.yaml instead of repeating
|
||||
# "ruff check" and "ty check" here. The commands then have one definition,
|
||||
# so the local and CI gates cannot drift apart.
|
||||
run: uv run pre-commit run --all-files --show-diff-on-failure
|
||||
|
||||
- name: Tests
|
||||
# Deliberately unfiltered, unlike the "-m 'not external'" form the guidance files
|
||||
# use for local runs. Tests marked "external" skip themselves when live-service
|
||||
# credentials are absent, so CI gets the same effective set plus a real run of any
|
||||
# external test whose credentials are configured. Not drift -- do not "fix" this to
|
||||
# match the local command without also giving those tests a way to run.
|
||||
run: uv run pytest
|
||||
-19
@@ -11,25 +11,6 @@ wheels/
|
||||
|
||||
# Environment secrets
|
||||
.env
|
||||
.env.production
|
||||
|
||||
# SQLite database
|
||||
*.db
|
||||
|
||||
# All data including db, backups, document images, photos, and logs:
|
||||
data/*
|
||||
data/backups/*
|
||||
data/documents/*
|
||||
data/logs/*
|
||||
data/photos/*
|
||||
data-local/*
|
||||
|
||||
|
||||
# Migration tests
|
||||
data-migration-test/*
|
||||
.migration-bundle/*
|
||||
|
||||
# Cloudflare tunnel local runtime files
|
||||
deploy/cloudflared/config.yml
|
||||
deploy/cloudflared/config.yaml
|
||||
deploy/cloudflared/credentials.json
|
||||
|
||||
@@ -1,29 +0,0 @@
|
||||
# Quality gate: `ruff check`, `ruff format --check`, and `ty check`
|
||||
# are blocking once known `ty` false positives are suppressed inline with rationale.
|
||||
#
|
||||
# Both tools are uv-managed dev dependencies and are not on PATH, so each entry must
|
||||
# go through `uv run`.
|
||||
repos:
|
||||
- repo: local
|
||||
hooks:
|
||||
- id: ruff
|
||||
name: ruff check
|
||||
entry: uv run ruff check
|
||||
language: system
|
||||
types_or: [python, pyi]
|
||||
require_serial: true
|
||||
- id: ruff-format
|
||||
name: ruff format check
|
||||
entry: uv run ruff format --check .
|
||||
language: system
|
||||
types_or: [python, pyi]
|
||||
pass_filenames: false
|
||||
require_serial: true
|
||||
- id: ty
|
||||
name: ty check
|
||||
entry: uv run ty check
|
||||
language: system
|
||||
types_or: [python, pyi]
|
||||
pass_filenames: false
|
||||
require_serial: true
|
||||
verbose: true
|
||||
Vendored
-23
@@ -1,23 +0,0 @@
|
||||
{
|
||||
"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"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
Vendored
-3
@@ -1,3 +0,0 @@
|
||||
{
|
||||
"chat.sessionSync.enabled": true
|
||||
}
|
||||
@@ -1,117 +0,0 @@
|
||||
# AGENTS.md
|
||||
|
||||
Orientation for AI agents working in this repository. This file is a **router**, not a spec:
|
||||
it points at canonical authority and flags the traps that are expensive to discover by trial.
|
||||
Where this file and `docs/*` disagree, `docs/*` wins.
|
||||
|
||||
## What This Is
|
||||
|
||||
A document transcription system that preserves durable archival records (Documents, Sources,
|
||||
People) and executes page transcription asynchronously through vision/LLM providers. Its
|
||||
defining constraint is **evidence**: every machine attempt is recorded append-only with
|
||||
request/response provenance. Features that would lose, mutate, or obscure that history are
|
||||
wrong regardless of how convenient they are.
|
||||
|
||||
Stack: Python 3.12+ · FastAPI + NiceGUI · SQLModel/SQLAlchemy (SQLite-first, PostgreSQL-
|
||||
compatible) · Pydantic V2 · asyncio worker · OpenRouter adapter.
|
||||
|
||||
## Commands
|
||||
|
||||
This is a `uv` project. **Nothing is on `PATH`** — `ruff`, `ty`, and `pytest` all require
|
||||
`uv run`. Bare invocations fail with command-not-found.
|
||||
|
||||
```bash
|
||||
uv run ruff check . # lint (blocking in pre-commit)
|
||||
uv run ruff format --check . # format (blocking in pre-commit)
|
||||
uv run ty check # types (blocking in pre-commit)
|
||||
uv run pytest -q -m "not external" # default verification run
|
||||
```
|
||||
|
||||
`external` marks tests that hit live services; always exclude it unless explicitly asked.
|
||||
All four commands are expected to pass clean — there is no tolerated baseline of failures.
|
||||
If `ty` reports something, fix it or suppress it inline *with a rationale comment*; a bare
|
||||
`ignore` will not survive review.
|
||||
|
||||
## Authority Order
|
||||
|
||||
Resolve every question in this order, and stop at the first that answers it:
|
||||
|
||||
1. **`docs/*`** — canonical. Start at [`docs/index.md`](docs/index.md), which defines the
|
||||
reading order. `docs/invariant/*` holds cross-version rules that outlive any release.
|
||||
2. **`.github/instructions/*.md`** — active steering, auto-attached when you edit matching
|
||||
paths. Covers services, UI, providers, tests, error handling, and documentation sync.
|
||||
3. **`.github/skills/*`** — periodic audit procedures (code review, provenance, test
|
||||
effectiveness).
|
||||
4. **`tests/`** — deterministic enforcement. A guard test is the ground truth for whatever
|
||||
rule it encodes.
|
||||
|
||||
`.github/agents/` and `.github/prompts/` hold named workflows that are loaded only when
|
||||
invoked explicitly, so they never override the order above. They are how a review or audit
|
||||
is *started*, not a source of rules.
|
||||
|
||||
`docs/reviews/**` is **not** canonical. Those are dated, opinionated snapshots that were
|
||||
accurate when written and may since have been fixed, superseded, or found wrong.
|
||||
|
||||
## Layout
|
||||
|
||||
| Path | Role |
|
||||
| :--- | :--- |
|
||||
| `src/transcription/ui/**`, `api/**` | Interface. No direct persistence access. |
|
||||
| `src/transcription/services/**` | Domain logic and transaction ownership. |
|
||||
| `src/transcription/db/**` | Models and persistence. |
|
||||
| `src/transcription/providers/**` | Provider adapters; provider details stop here. |
|
||||
| `src/transcription/worker.py` | Asyncio worker loop. |
|
||||
| `tests/` | Includes boundary/contract guards, not just behavior tests. |
|
||||
|
||||
## Enforced Boundaries
|
||||
|
||||
These are not conventions — a test fails if you break them:
|
||||
|
||||
- **No service-to-service imports** (`test_service_boundaries.py`). Compose in the caller.
|
||||
- **No persistence access from pages/components** (`test_ui_boundaries.py`, allowlist-based).
|
||||
- **No hand-rolled error notifications in UI** — use the shared error presenter.
|
||||
- **No stringly-typed status literals** — use the enums (`test_model_contract_guards.py`).
|
||||
- **Attempt history is append-only** (`test_evidence_provenance.py`).
|
||||
- **`docs/schema.md` stays field-accurate** with `db/models.py`.
|
||||
- **Orphans are tracked, not tolerated** — `test_orphan_sweep.py` records each retained
|
||||
orphan with rationale in `KNOWN_ORPHANS`.
|
||||
|
||||
## Traps
|
||||
|
||||
Non-obvious things that have already caused real bugs here:
|
||||
|
||||
- **`AppError.message` vs `AppError.detail`.** `message` is user/API-facing and must stay
|
||||
generic — never put exception text or filesystem paths in it. `detail` is internal-only and
|
||||
is what reaches logs and `ExecutionAttempt.error_detail`. Putting root-cause data in
|
||||
`message` leaks; removing it from `detail` silently degrades provenance. See
|
||||
`docs/error_handling.md`.
|
||||
- **Two competing atomicity invariants in `services/workflows.py`.** Intermediate pages must
|
||||
commit individually (durability across a long multi-page job); the *final* page must commit
|
||||
atomically with the terminal job status. Collapsing the batch into one transaction satisfies
|
||||
the second and destroys the first. Both are guarded — `test_workflows_reliability.py` and
|
||||
`tests/integration/test_pipeline_atomicity.py`.
|
||||
- **Shared symbols have more consumers than the obvious one.** Before changing a model field,
|
||||
exception attribute, or helper return value, grep for every consumer including tests.
|
||||
Evidence and logging paths frequently read the same fields the UI does.
|
||||
- **`Tag` is owned by two services, on purpose.** Every other model has exactly one owning
|
||||
service, so the ownership rule reads as absolute — it isn't. `Tag` is a single table reached
|
||||
through two `RegistryService[Tag]` facades, `TagRegistry` (documents) and `PersonTagRegistry`
|
||||
(people), which count usage through `DocumentTag` and `PersonTag` respectively. Changing tag
|
||||
semantics through one facade silently changes the other. Consolidating them under one service
|
||||
is not a cleanup; it makes the other side a cross-aggregate writer.
|
||||
- **Import style:** ruff `isort` runs with `force-single-line = true`. One import per line.
|
||||
- **Latent defects have ordering constraints.** Some code is unreachable only because of a
|
||||
current setting or single-instance deployment. Fix it *before* the change that unblocks it,
|
||||
not after.
|
||||
|
||||
## Change Protocol
|
||||
|
||||
- **Write the failing test first** for behavioral fixes, and confirm it actually fails for the
|
||||
reason you think. Several bugs here were subtle enough that a test written afterward would
|
||||
have passed against the broken code.
|
||||
- **Update docs in the same change** when you alter a contract, behavior, or scope — see
|
||||
`.github/instructions/documentation-sync.instructions.md`.
|
||||
- **Do not commit unless asked.** Making a requested change is not consent to commit it.
|
||||
- **Do not push or open PRs on your own initiative.**
|
||||
- **Scope discipline:** fix what was asked plus what your change genuinely breaks. Pre-existing
|
||||
unrelated issues are a separate conversation.
|
||||
-55
@@ -1,55 +0,0 @@
|
||||
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
|
||||
COPY tools ./tools
|
||||
COPY deploy ./deploy
|
||||
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 apt-get update \
|
||||
&& apt-get install -y --no-install-recommends postgresql-client \
|
||||
&& rm -rf /var/lib/apt/lists/*
|
||||
|
||||
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
|
||||
COPY --from=builder /app/tools /app/tools
|
||||
COPY --from=builder /app/deploy /app/deploy
|
||||
|
||||
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"]
|
||||
@@ -22,133 +22,73 @@ uv sync
|
||||
|
||||
### 2) Configure environment
|
||||
|
||||
Create a `.env.production` file in the project root with the required OpenRouter API key:
|
||||
Create a `.env` file in the project root (minimum required setting shown):
|
||||
|
||||
```env
|
||||
OPENROUTER_API_KEY=your_openrouter_api_key
|
||||
```
|
||||
|
||||
Settings are read from CLI arguments first, then environment variables, then `.env.production`, 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 8000`)
|
||||
2. Settings constructor arguments (used mainly in tests)
|
||||
3. Environment variables
|
||||
4. `.env.production` file values
|
||||
5. Model defaults in code
|
||||
|
||||
Practical examples:
|
||||
|
||||
- `--port 8000` overrides both `PORT=8000` in the shell and `PORT=7000` in `.env.production`.
|
||||
- `DATABASE__PATH=prod.db` in the shell overrides `DATABASE__PATH=dev.db` in `.env.production`.
|
||||
|
||||
#### 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`. |
|
||||
| `RUN_EMBEDDED_WORKER` | `true` | Run worker loop inside web app process. Set `false` when using a dedicated worker service. |
|
||||
|
||||
#### 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):
|
||||
Optional settings (defaults shown):
|
||||
|
||||
```env
|
||||
DATABASE__DRIVER=sqlite
|
||||
DATABASE__PATH=app.db
|
||||
# BOOTSTRAP_SCHEMA_ON_STARTUP=true
|
||||
SQLITE_CHECK_SAME_THREAD=false
|
||||
DATABASE_URL=sqlite:///./transcription.db
|
||||
UPLOAD_DIR=./uploads
|
||||
PROMPT_DIR=./prompts
|
||||
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
|
||||
MAX_UPLOAD_BYTES=15728640
|
||||
OPERATOR_ACCESS_ENABLED=false
|
||||
OPERATOR_USERNAME=operator
|
||||
# OPERATOR_PASSWORD=replace_with_secure_value
|
||||
```
|
||||
|
||||
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 files. 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 python -m transcription --port 8000 --reload --database.driver sqlite --bootstrap-schema-on-startup
|
||||
uv run uvicorn transcription.app:create_app --factory --reload
|
||||
```
|
||||
|
||||
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`.
|
||||
### 4) (Optional) Run explicit migrations/checks
|
||||
|
||||
### 4) Open in browser
|
||||
|
||||
- GUI: [http://localhost:8000/ui](http://localhost:8000/ui)
|
||||
- Health check: [http://localhost:8000/healthz](http://localhost:8000/healthz)
|
||||
|
||||
Replace `localhost` with the server's hostname or IP address when connecting from another machine.
|
||||
|
||||
## Production stack (Phase 1)
|
||||
|
||||
Use the production compose profile for split app/worker deployment with PostgreSQL and Cloudflare Tunnel:
|
||||
Use the migration runner for Step 4 schema safety workflows:
|
||||
|
||||
```bash
|
||||
copy .env.production.example .env.production
|
||||
docker compose -f docker-compose.production.yml up -d --build
|
||||
uv run python -m transcription.migration_runner --list
|
||||
uv run python -m transcription.migration_runner --apply
|
||||
uv run python -m transcription.migration_runner --check
|
||||
```
|
||||
|
||||
Services:
|
||||
### 5) Open in browser
|
||||
|
||||
- `app`: FastAPI + NiceGUI runtime (`RUN_EMBEDDED_WORKER=false`)
|
||||
- `worker`: standalone queue processor (`python -m transcription.worker_service`)
|
||||
- `postgres`: primary datastore
|
||||
- `cloudflared`: tunnel client using mounted ingress config + `CLOUDFLARE_TUNNEL_TOKEN`
|
||||
|
||||
Operational defaults in the production compose file:
|
||||
- GUI: [http://[IP_ADDRESS]:8000/ui](http://[IP_ADDRESS]:8000/ui)
|
||||
- Health check: [http://[IP_ADDRESS]:8000/healthz](http://[IP_ADDRESS]:8000/healthz)
|
||||
|
||||
- worker healthcheck is disabled (the worker process has no HTTP `/healthz` endpoint)
|
||||
- cloudflared is pinned to HTTP/2 with explicit DNS resolvers (`1.1.1.1`, `1.0.0.1`) for restricted LXC/container DNS environments
|
||||
### 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).
|
||||
|
||||
Cloudflare setup files:
|
||||
|
||||
1. `copy deploy\cloudflared\config.yml.example deploy\cloudflared\config.yml`
|
||||
2. set `CLOUDFLARE_TUNNEL_TOKEN` in `.env.production`
|
||||
3. update ingress hostnames in `deploy\cloudflared\config.yml`
|
||||
|
||||
## How to navigate the GUI
|
||||
|
||||
@@ -169,74 +109,7 @@ Cloudflare setup files:
|
||||
|
||||
## Prompt artifacts
|
||||
|
||||
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.
|
||||
Prompt files are stored in `prompts/` and loaded from `PROMPT_DIR` (default: `./prompts`).
|
||||
|
||||
The canonical MVP prompt is:
|
||||
- `prompts/transcribe_document.md`
|
||||
|
||||
## Database migration workflow
|
||||
|
||||
Schema upgrades use an explicit export/import rebuild flow (no runtime legacy write compatibility).
|
||||
See `docs/data_migration.md` for commands and cutover steps.
|
||||
|
||||
## Backup and restore workflow
|
||||
|
||||
Production backup/restore (PostgreSQL + uploads + deployment config) steps are documented in `docs/backup_restore.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.
|
||||
|
||||
@@ -1,69 +0,0 @@
|
||||
#!/usr/bin/env sh
|
||||
set -eu
|
||||
|
||||
BACKUP_DIR="${BACKUP_DIR:-./data/backups}"
|
||||
RETENTION_DAYS="${BACKUP_RETENTION_DAYS:-14}"
|
||||
UPLOAD_DIR="${UPLOAD_DIR:-/app/uploads}"
|
||||
PROMPT_DIR="${PROMPT_DIR:-/app/prompts}"
|
||||
DATABASE_DRIVER="${DATABASE__DRIVER:-postgres}"
|
||||
DATABASE_HOST="${DATABASE__HOST:-postgres}"
|
||||
DATABASE_PORT="${DATABASE__PORT:-5432}"
|
||||
DATABASE_NAME="${DATABASE__DATABASE:-}"
|
||||
DATABASE_USER="${DATABASE__USER:-}"
|
||||
DATABASE_PASSWORD="${DATABASE__PASSWORD:-}"
|
||||
|
||||
timestamp="$(date -u +%Y%m%d-%H%M%S)"
|
||||
postgres_file="postgres-${timestamp}.dump"
|
||||
manifest_file="backup-${timestamp}.manifest"
|
||||
|
||||
mkdir -p "${BACKUP_DIR}"
|
||||
if [ "${DATABASE_DRIVER}" != "postgres" ]; then
|
||||
echo "create_postgres_backup.sh requires DATABASE__DRIVER=postgres." >&2
|
||||
exit 1
|
||||
fi
|
||||
if [ -z "${DATABASE_NAME}" ] || [ -z "${DATABASE_USER}" ] || [ -z "${DATABASE_PASSWORD}" ]; then
|
||||
echo "DATABASE__DATABASE, DATABASE__USER, and DATABASE__PASSWORD must be set." >&2
|
||||
exit 1
|
||||
fi
|
||||
if ! command -v pg_dump >/dev/null 2>&1; then
|
||||
echo "pg_dump is not installed in this environment." >&2
|
||||
exit 1
|
||||
fi
|
||||
PGPASSWORD="${DATABASE_PASSWORD}" pg_dump \
|
||||
-h "${DATABASE_HOST}" \
|
||||
-p "${DATABASE_PORT}" \
|
||||
-U "${DATABASE_USER}" \
|
||||
-d "${DATABASE_NAME}" \
|
||||
-Fc \
|
||||
> "${BACKUP_DIR}/${postgres_file}"
|
||||
|
||||
cat > "${BACKUP_DIR}/${manifest_file}" <<EOF
|
||||
created_at_utc=${timestamp}
|
||||
postgres_dump=${postgres_file}
|
||||
backup_dir=${BACKUP_DIR}
|
||||
uploads_backup_dir=${BACKUP_DIR}/uploads
|
||||
prompts_backup_dir=${BACKUP_DIR}/prompts
|
||||
EOF
|
||||
|
||||
find "${BACKUP_DIR}" -type f \( \
|
||||
-name 'postgres-*.dump' -o \
|
||||
-name 'backup-*.manifest' \
|
||||
\) -mtime +"${RETENTION_DAYS}" -delete
|
||||
|
||||
uploads_backup_dir="${BACKUP_DIR}/uploads"
|
||||
mkdir -p "${uploads_backup_dir}"
|
||||
if [ -d "${UPLOAD_DIR}" ]; then
|
||||
cp -an "${UPLOAD_DIR}/." "${uploads_backup_dir}/"
|
||||
fi
|
||||
|
||||
prompts_backup_dir="${BACKUP_DIR}/prompts"
|
||||
mkdir -p "${prompts_backup_dir}"
|
||||
if [ -d "${PROMPT_DIR}" ]; then
|
||||
cp -a "${PROMPT_DIR}/." "${prompts_backup_dir}/"
|
||||
fi
|
||||
|
||||
echo "Created backup set:"
|
||||
echo " ${BACKUP_DIR}/${postgres_file}"
|
||||
echo " ${BACKUP_DIR}/${manifest_file}"
|
||||
echo " ${uploads_backup_dir}/ (incremental uploads mirror)"
|
||||
echo " ${prompts_backup_dir}/ (prompts mirror)"
|
||||
@@ -1,36 +0,0 @@
|
||||
#!/usr/bin/env sh
|
||||
set -eu
|
||||
|
||||
# Example only. Copy to a local script and replace placeholder values.
|
||||
# Do NOT commit secrets.
|
||||
|
||||
SHARE="//nas-host-or-ip/share-name"
|
||||
MOUNT_POINT="/mnt/nas-backups"
|
||||
CREDENTIALS_FILE="/etc/samba/credentials/nas-share-credentials"
|
||||
USERNAME="replace-with-nas-user"
|
||||
PASSWORD="replace-with-nas-password"
|
||||
|
||||
if [ "${USERNAME}" = "replace-with-nas-user" ] || [ "${PASSWORD}" = "replace-with-nas-password" ]; then
|
||||
echo "Edit USERNAME and PASSWORD placeholders before running this script."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
mkdir -p "${MOUNT_POINT}"
|
||||
mkdir -p "$(dirname "${CREDENTIALS_FILE}")"
|
||||
|
||||
cat > "${CREDENTIALS_FILE}" <<'EOF'
|
||||
username=__USERNAME__
|
||||
password=__PASSWORD__
|
||||
EOF
|
||||
sed -i "s|__USERNAME__|${USERNAME}|g" "${CREDENTIALS_FILE}"
|
||||
sed -i "s|__PASSWORD__|${PASSWORD}|g" "${CREDENTIALS_FILE}"
|
||||
chmod 600 "${CREDENTIALS_FILE}"
|
||||
|
||||
mount -t cifs "${SHARE}" "${MOUNT_POINT}" \
|
||||
-o "credentials=${CREDENTIALS_FILE},vers=3.0,iocharset=utf8,uid=0,gid=0,file_mode=0600,dir_mode=0700"
|
||||
|
||||
echo ""
|
||||
echo "Mounted ${SHARE} at ${MOUNT_POINT}"
|
||||
echo ""
|
||||
echo "To persist across reboot, add this line to /etc/fstab:"
|
||||
echo "${SHARE} ${MOUNT_POINT} cifs credentials=${CREDENTIALS_FILE},vers=3.0,iocharset=utf8,uid=0,gid=0,file_mode=0600,dir_mode=0700,_netdev,nofail,x-systemd.automount 0 0"
|
||||
@@ -1,86 +0,0 @@
|
||||
#!/usr/bin/env sh
|
||||
set -eu
|
||||
|
||||
if [ "$#" -lt 1 ]; then
|
||||
echo "Usage: $0 <path-to-postgres-dump>"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
dump_file="$1"
|
||||
COMPOSE_FILE="${COMPOSE_FILE:-docker-compose.production.yml}"
|
||||
ENV_FILE="${ENV_FILE:-.env.production}"
|
||||
SYNOLOGY_BACKUP_DIR="${SYNOLOGY_BACKUP_DIR:-}"
|
||||
|
||||
if [ ! -f "${dump_file}" ]; then
|
||||
echo "Backup file not found: ${dump_file}"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
backup_dir="$(dirname "${dump_file}")"
|
||||
backup_name="$(basename "${dump_file}")"
|
||||
timestamp="$(printf '%s' "${backup_name}" | sed -n 's/^postgres-\([0-9]\{8\}-[0-9]\{6\}\)\.dump$/\1/p')"
|
||||
uploads_file=""
|
||||
config_file=""
|
||||
|
||||
# If SYNOLOGY_BACKUP_DIR wasn't exported in the shell, read it from ENV_FILE.
|
||||
if [ -z "${SYNOLOGY_BACKUP_DIR}" ] && [ -f "${ENV_FILE}" ]; then
|
||||
SYNOLOGY_BACKUP_DIR="$(
|
||||
sed -n 's/^SYNOLOGY_BACKUP_DIR=//p' "${ENV_FILE}" | tail -n 1
|
||||
)"
|
||||
fi
|
||||
|
||||
if [ -n "${timestamp}" ]; then
|
||||
# Legacy local full-archive naming.
|
||||
candidate_uploads="${backup_dir}/uploads-${timestamp}.tar.gz"
|
||||
candidate_config="${backup_dir}/config-${timestamp}.tar.gz"
|
||||
if [ -f "${candidate_uploads}" ]; then
|
||||
uploads_file="${candidate_uploads}"
|
||||
fi
|
||||
if [ -f "${candidate_config}" ]; then
|
||||
config_file="${candidate_config}"
|
||||
fi
|
||||
fi
|
||||
|
||||
docker compose --env-file "${ENV_FILE}" -f "${COMPOSE_FILE}" exec -T postgres sh -lc \
|
||||
"PGPASSWORD=\"\$POSTGRES_PASSWORD\" psql -U \"\$POSTGRES_USER\" -d postgres -c \"DROP DATABASE IF EXISTS \\\"\$POSTGRES_DB\\\";\""
|
||||
|
||||
docker compose --env-file "${ENV_FILE}" -f "${COMPOSE_FILE}" exec -T postgres sh -lc \
|
||||
"PGPASSWORD=\"\$POSTGRES_PASSWORD\" psql -U \"\$POSTGRES_USER\" -d postgres -c \"CREATE DATABASE \\\"\$POSTGRES_DB\\\";\""
|
||||
|
||||
cat "${dump_file}" | docker compose --env-file "${ENV_FILE}" -f "${COMPOSE_FILE}" exec -T postgres sh -lc \
|
||||
"PGPASSWORD=\"\$POSTGRES_PASSWORD\" pg_restore -U \"\$POSTGRES_USER\" -d \"\$POSTGRES_DB\" --clean --if-exists --no-owner --no-privileges"
|
||||
|
||||
if [ -n "${SYNOLOGY_BACKUP_DIR}" ] && [ -d "${SYNOLOGY_BACKUP_DIR}/uploads" ]; then
|
||||
docker compose --env-file "${ENV_FILE}" -f "${COMPOSE_FILE}" run --rm --no-deps \
|
||||
-v "${SYNOLOGY_BACKUP_DIR}:/backup" \
|
||||
--entrypoint sh app -lc \
|
||||
"mkdir -p /app/uploads/documents /app/uploads/photos && \
|
||||
find /app/uploads/documents -mindepth 1 -delete && \
|
||||
find /app/uploads/photos -mindepth 1 -delete && \
|
||||
if [ -d /backup/uploads/documents ]; then cp -a /backup/uploads/documents/. /app/uploads/documents/; fi && \
|
||||
if [ -d /backup/uploads/photos ]; then cp -a /backup/uploads/photos/. /app/uploads/photos/; fi && \
|
||||
if [ -f /backup/uploads/homepage.md ]; then cp /backup/uploads/homepage.md /app/uploads/homepage.md; else rm -f /app/uploads/homepage.md; fi"
|
||||
elif [ -n "${uploads_file}" ]; then
|
||||
# Legacy local full-archive restore.
|
||||
cat "${uploads_file}" | docker compose --env-file "${ENV_FILE}" -f "${COMPOSE_FILE}" run --rm --no-deps --entrypoint sh app -lc \
|
||||
"mkdir -p /app/uploads && find /app/uploads -mindepth 1 -delete && tar -xzf - -C /app/uploads"
|
||||
fi
|
||||
|
||||
if [ -n "${SYNOLOGY_BACKUP_DIR}" ] && [ -n "${timestamp}" ] && [ -f "${SYNOLOGY_BACKUP_DIR}/config-${timestamp}.tar.gz" ]; then
|
||||
tar -xzf "${SYNOLOGY_BACKUP_DIR}/config-${timestamp}.tar.gz" -C .
|
||||
elif [ -n "${config_file}" ]; then
|
||||
# Legacy local full-archive restore.
|
||||
tar -xzf "${config_file}" -C .
|
||||
fi
|
||||
|
||||
echo "Restore complete from: ${dump_file}"
|
||||
if [ -n "${SYNOLOGY_BACKUP_DIR}" ] && [ -d "${SYNOLOGY_BACKUP_DIR}/uploads" ]; then
|
||||
echo "Restored uploads mirror from: ${SYNOLOGY_BACKUP_DIR}/uploads"
|
||||
elif [ -n "${uploads_file}" ]; then
|
||||
echo "Restored uploads archive: ${uploads_file}"
|
||||
fi
|
||||
if [ -n "${SYNOLOGY_BACKUP_DIR}" ] && [ -n "${timestamp}" ] && [ -f "${SYNOLOGY_BACKUP_DIR}/config-${timestamp}.tar.gz" ]; then
|
||||
echo "Restored config archive: ${SYNOLOGY_BACKUP_DIR}/config-${timestamp}.tar.gz"
|
||||
elif [ -n "${config_file}" ]; then
|
||||
echo "Restored config archive: ${config_file}"
|
||||
fi
|
||||
@@ -1,14 +0,0 @@
|
||||
ingress:
|
||||
# Primary transcription app endpoint.
|
||||
- hostname: transcription.example.com
|
||||
service: http://app:8000
|
||||
|
||||
# Optional: generic remote access endpoints for other internal services.
|
||||
# Replace hostnames and targets for your LAN.
|
||||
- hostname: homeassistant.example.com
|
||||
service: http://192.168.1.50:8123
|
||||
- hostname: pihole.example.com
|
||||
service: http://192.168.1.60:80
|
||||
|
||||
# Required catch-all.
|
||||
- service: http_status:404
|
||||
@@ -1,70 +0,0 @@
|
||||
services:
|
||||
app:
|
||||
build:
|
||||
context: .
|
||||
dockerfile: Dockerfile
|
||||
image: transcription:prod
|
||||
env_file:
|
||||
- .env.production
|
||||
environment:
|
||||
RUN_EMBEDDED_WORKER: "false"
|
||||
RUNTIME_SETTINGS_ENV_FILE: "/app/.env.production"
|
||||
depends_on:
|
||||
postgres:
|
||||
condition: service_healthy
|
||||
ports:
|
||||
- "8000:8000"
|
||||
volumes:
|
||||
- app_uploads:/app/uploads
|
||||
- app_data:/app/data
|
||||
- ./backup:/backup
|
||||
- ./.env.production:/app/.env.production
|
||||
- ./prompts:/app/prompts:ro
|
||||
restart: unless-stopped
|
||||
healthcheck:
|
||||
test: ["CMD", "python", "-c", "import urllib.request; urllib.request.urlopen('http://localhost:8000/healthz')"]
|
||||
interval: 30s
|
||||
timeout: 5s
|
||||
retries: 5
|
||||
start_period: 20s
|
||||
|
||||
worker:
|
||||
image: transcription:prod
|
||||
env_file:
|
||||
- .env.production
|
||||
command: ["python", "-m", "transcription.worker_service"]
|
||||
depends_on:
|
||||
postgres:
|
||||
condition: service_healthy
|
||||
volumes:
|
||||
- app_uploads:/app/uploads
|
||||
- app_data:/app/data
|
||||
- ./backup:/backup
|
||||
- ./.env.production:/app/.env.production:ro
|
||||
- ./prompts:/app/prompts:ro
|
||||
healthcheck:
|
||||
disable: true
|
||||
restart: unless-stopped
|
||||
|
||||
postgres:
|
||||
image: postgres:16-alpine
|
||||
env_file:
|
||||
- .env.production
|
||||
environment:
|
||||
POSTGRES_DB: ${DATABASE__DATABASE}
|
||||
POSTGRES_USER: ${DATABASE__USER}
|
||||
POSTGRES_PASSWORD: ${DATABASE__PASSWORD}
|
||||
volumes:
|
||||
- postgres_data:/var/lib/postgresql/data
|
||||
restart: unless-stopped
|
||||
healthcheck:
|
||||
test: ["CMD-SHELL", "pg_isready -U $$POSTGRES_USER -d $$POSTGRES_DB"]
|
||||
interval: 10s
|
||||
timeout: 5s
|
||||
retries: 10
|
||||
start_period: 10s
|
||||
|
||||
volumes:
|
||||
postgres_data:
|
||||
app_uploads:
|
||||
app_data:
|
||||
@@ -1,24 +0,0 @@
|
||||
services:
|
||||
transcription:
|
||||
build:
|
||||
context: .
|
||||
dockerfile: Dockerfile
|
||||
container_name: transcription-app
|
||||
env_file:
|
||||
- .env.production
|
||||
environment:
|
||||
# Database configuration uses nested settings names (env_nested_delimiter="__").
|
||||
# DATABASE_URL is NOT read by the application and must not be used here.
|
||||
DATABASE__DRIVER: sqlite
|
||||
DATABASE__PATH: /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:
|
||||
@@ -0,0 +1,40 @@
|
||||
# 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>` a. Sub-point`<br>` b. Next point`<br>`III. [sic] Third Topic` |
|
||||
@@ -0,0 +1,35 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,36 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,31 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,32 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,20 @@
|
||||
# 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)
|
||||
+226
-162
@@ -1,230 +1,294 @@
|
||||
# System Architecture (Current Baseline: V6.1)
|
||||
# Architecture
|
||||
|
||||
This document defines the current V6.1 architecture baseline.
|
||||
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
|
||||
|
||||
- Preserve durable archival records for Documents, Sources, People, and processing runs.
|
||||
- Execute page transcription asynchronously with bounded worker behavior.
|
||||
- Preserve append-only machine-attempt evidence with request/response provenance.
|
||||
- Keep UI, API, service, persistence, and provider boundaries explicit and testable.
|
||||
The production architecture is designed to:
|
||||
|
||||
## Technical Stack
|
||||
- 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
|
||||
|
||||
- **Runtime:** Python 3.12+
|
||||
- **Web application:** FastAPI + NiceGUI
|
||||
- **Persistence:** SQLModel / SQLAlchemy — PostgreSQL in production, SQLite for local development and tests
|
||||
- **Validation and settings:** Pydantic V2 + pydantic-settings
|
||||
- **Concurrency:** asyncio worker loop
|
||||
- **Provider integration:** OpenRouter adapter behind provider interface
|
||||
- **Deployment:** Docker Compose (app, worker, PostgreSQL, Cloudflare Tunnel)
|
||||
- **Quality and tests:** Ruff, ty, pytest, pytest-asyncio
|
||||
## Production Scope And Scale
|
||||
|
||||
## Runtime Topology
|
||||
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
|
||||
U[Browser User] --> A[FastAPI + NiceGUI App]
|
||||
A --> W[Asyncio Worker]
|
||||
A --> DB[(PostgreSQL / SQLite)]
|
||||
W --> P[Provider Adapter]
|
||||
W --> DB
|
||||
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
|
||||
```
|
||||
|
||||
The worker loop drains two queues in the same pass: queued transcription Jobs and queued
|
||||
`MaintenanceRun` records. When neither has work, it idles.
|
||||
## Runtime Ownership And Startup Policy (V1 Step 1)
|
||||
|
||||
### Production deployment
|
||||
The current implementation now uses explicit lifespan-owned runtime resources.
|
||||
|
||||
Production runs as a Docker Compose stack with the app and worker as separate services, so the app
|
||||
process runs with `RUN_EMBEDDED_WORKER=false` and the worker process owns queue draining. Local
|
||||
development runs a single process with the worker embedded.
|
||||
- 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
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
I[Internet] --> CF[cloudflared tunnel + Access]
|
||||
CF --> APP[app service]
|
||||
APP --> PG[(postgres service)]
|
||||
WK[worker service] --> PG
|
||||
WK --> PROV[OpenRouter]
|
||||
```
|
||||
This aligns implementation toward REQ-7 and REQ-10 while preserving personal-scale operational simplicity.
|
||||
|
||||
Deployment, rollback, and recovery procedures are in [Production Runbook](production-runbook.md);
|
||||
backup configuration and restore are in [Backup and Restore](backup_restore.md).
|
||||
|
||||
## Layered Boundaries
|
||||
## Layered Module Structure
|
||||
|
||||
### Interface Layer
|
||||
|
||||
- `src/transcription/ui/**`
|
||||
- `src/transcription/api/**`
|
||||
Responsibility:
|
||||
|
||||
Responsibilities:
|
||||
- HTTP API and UI routes
|
||||
- request/response validation
|
||||
- status and result presentation
|
||||
|
||||
- Route registration, page orchestration, presentation adapters.
|
||||
- Structured user messaging through shared error presenter.
|
||||
- No direct persistence access from pages/components.
|
||||
Out of scope:
|
||||
|
||||
### Service and Orchestration Layer
|
||||
- business-rule enforcement
|
||||
- data-access implementation
|
||||
|
||||
Aggregate services:
|
||||
### Application Layer
|
||||
|
||||
- `src/transcription/services/documents.py`
|
||||
- `src/transcription/services/people.py`
|
||||
- `src/transcription/services/jobs.py`
|
||||
- `src/transcription/services/sources.py`
|
||||
- `src/transcription/services/photos.py`
|
||||
- `src/transcription/services/maintenance.py`
|
||||
- `src/transcription/services/evidence.py` (read/projection only)
|
||||
Responsibility:
|
||||
|
||||
Orchestration modules:
|
||||
- upload and job orchestration
|
||||
- state transitions and retry policy
|
||||
- coordination across domain and infrastructure ports
|
||||
|
||||
- `src/transcription/services/store.py`
|
||||
- `src/transcription/services/workflows.py`
|
||||
Out of scope:
|
||||
|
||||
Responsibilities:
|
||||
- provider-specific protocol details
|
||||
- ORM or storage-specific logic
|
||||
|
||||
- Aggregate ownership and invariants.
|
||||
- Transaction-aware write helpers.
|
||||
- Cross-service workflows in orchestration modules (`store.py`, `workflows.py`).
|
||||
- Lookup-table CRUD through the generic `RegistryService` base (`registry.py`), which is not an
|
||||
aggregate owner itself.
|
||||
### Domain Layer
|
||||
|
||||
Module classification and per-model ownership are defined in
|
||||
[services instructions](../.github/instructions/services.instructions.md).
|
||||
Responsibility:
|
||||
|
||||
### Persistence Layer
|
||||
- verbatim transcription policy
|
||||
- revision and provenance invariants
|
||||
- confidence and annotation semantics
|
||||
|
||||
- `src/transcription/db/**`
|
||||
Out of scope:
|
||||
|
||||
Responsibilities:
|
||||
- web framework concerns
|
||||
- database and network I/O
|
||||
|
||||
- SQLModel definitions, async session/engine runtime, registry bootstrap.
|
||||
- Loader helpers that enforce explicit eager loading with `lazy="raise"` relationships.
|
||||
### Infrastructure Layer
|
||||
|
||||
### Provider Layer
|
||||
Responsibility:
|
||||
|
||||
- `src/transcription/providers/**`
|
||||
- persistence adapters (PostgreSQL and MongoDB)
|
||||
- transcription-provider adapter
|
||||
|
||||
Responsibilities:
|
||||
Out of scope:
|
||||
|
||||
- Provider API encapsulation.
|
||||
- Request manifest and transport evidence capture.
|
||||
- Normalized transcription result contract.
|
||||
- business policy decisions
|
||||
|
||||
## Core Domain Model
|
||||
## Processing Workflow
|
||||
|
||||
- `Document` owns archival metadata and links to `Source`, `Job`, and `DocumentPerson`.
|
||||
- `Source` is a document page/file record with selected machine projection and human revision.
|
||||
- `Job` is an aggregate processing run with status and frozen prompt/runtime settings.
|
||||
- `JobSource` is queue/membership state for one `(job, source)` pair.
|
||||
- `ExecutionAttempt` is append-only evidence for each provider call.
|
||||
- `Photo` is person imagery owned by `PhotosService`.
|
||||
- `MaintenanceRun` is one queued or executed operational maintenance run.
|
||||
- `GenealogyPerson`, `GenealogyFamily`, `GenealogyFamilyChild`, and `GenealogyCitation` store
|
||||
imported GEDCOM genealogy data and citation provenance.
|
||||
- `DocumentType` and `PersonRole` are UUID-backed registries with optional protected `semantic_key`.
|
||||
- `Tag` is a shared registry reached through both document and person tagging, linked by
|
||||
`DocumentTag` and `PersonTag`.
|
||||
Production transcription flow:
|
||||
|
||||
## Processing and Evidence Workflow
|
||||
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.
|
||||
|
||||
1. User creates/updates Document metadata and linked People atomically through workflow orchestration.
|
||||
2. User creates a Job by uploading one or more Source files or by retranscribing an existing Source.
|
||||
3. Source files are validated and stored; orientation normalization may be applied at ingest, and stored bytes become the canonical processing bytes.
|
||||
4. Worker claims queued Job, transitions to `processing`, and processes pending pages in deterministic order.
|
||||
5. Each provider call writes one immutable `ExecutionAttempt` with:
|
||||
- request manifest + hash
|
||||
- transport evidence (when response exists)
|
||||
- SDK snapshot and normalized metadata
|
||||
- outcome, timing, and error details when applicable
|
||||
6. `JobSource` status is updated as queue/projection state; `Source.raw_transcription` is set on first successful attempt and can be explicitly re-pointed by candidate promotion.
|
||||
7. Job terminal status resolves to `transcribed`, `partial_success`, or `failed`.
|
||||
## Data Model Ownership
|
||||
|
||||
## Status Semantics
|
||||
System-of-record entities:
|
||||
|
||||
- **Job statuses:** `queued`, `processing`, `transcribed`, `partial_success`, `failed`
|
||||
- Operational success path resolves to `transcribed`.
|
||||
- **JobSource statuses:** `pending`, `transcribed`, `failed`, `cancelled`
|
||||
- **MaintenanceRun statuses:** `queued`, `processing`, `succeeded`, `failed`
|
||||
- Maintenance uses `succeeded` rather than `transcribed`; the transcription vocabulary does not
|
||||
apply to operational runs.
|
||||
- **Maintenance job types:** `backup`, `storage_reconciliation`, `gedcom_import`
|
||||
- documents and pages
|
||||
- transcription jobs and status events
|
||||
- transcript revisions
|
||||
- provenance metadata
|
||||
|
||||
## Maintenance Execution
|
||||
Storage strategy:
|
||||
|
||||
Operational maintenance is queue-backed rather than run inline from the UI, so it survives request
|
||||
lifetime and is recorded:
|
||||
- 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
|
||||
|
||||
1. Settings enqueues a `MaintenanceRun` with `status=queued` and a `triggered_by` marker.
|
||||
2. The worker claims the oldest queued run with a conditional update, moving it to `processing`.
|
||||
3. `backup` runs the deploy backup script; `storage_reconciliation` compares stored media against
|
||||
`Document`/`Source` records; `gedcom_import` parses the latest uploaded `.ged` file and upserts
|
||||
genealogy records.
|
||||
4. The run finalizes to `succeeded` or `failed` with summary, timing, log path, and `error_detail`.
|
||||
## Transcription Prompt Asset Policy
|
||||
|
||||
`MaintenanceRun` records operational history and is not evidence in the `ExecutionAttempt` sense;
|
||||
append-only guarantees apply to transcription attempts.
|
||||
The production system treats transcription prompts as maintainable content assets.
|
||||
|
||||
## Security and Path Handling Boundaries
|
||||
- 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
|
||||
|
||||
- Print media delivery uses record-validated API route:
|
||||
- `src/transcription/api/print_api.py`
|
||||
- General UI media links resolve through:
|
||||
- `src/transcription/ui/components/media_urls.py`
|
||||
- Local filesystem paths must never be accepted from user input as trusted media routes.
|
||||
## Simplicity Guardrails
|
||||
|
||||
## Concurrency and Reliability Principles
|
||||
The production system enforces these constraints to prevent accidental over-engineering:
|
||||
|
||||
- Worker loop reuses service bundle/provider resources for pooled calls.
|
||||
- Provider-call timeout is explicit and bounded.
|
||||
- Non-retriable worker-loop faults are surfaced and stop loop spin.
|
||||
- Per-page outcomes are durably persisted before processing next page.
|
||||
- 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
|
||||
|
||||
## Design Decisions and Rationale
|
||||
## Extension Path
|
||||
|
||||
### Why `transcribed` is the success terminal state
|
||||
The architecture supports additive growth without changing domain contracts.
|
||||
|
||||
- The worker and job orchestration resolve successful completion to `JobStatus.TRANSCRIBED`, with mixed and failure outcomes represented by `partial_success` and `failed`.
|
||||
- This keeps terminal status vocabulary aligned with what the pipeline actually produces: transcribed page content and evidence, not a generic completion marker.
|
||||
### Stage 1: Foundation (Current)
|
||||
|
||||
### Why evidence history is append-only while page text is a projection
|
||||
- upload, transcription, review, search, export
|
||||
- in-process worker execution
|
||||
- single provider adapter
|
||||
- app plus PostgreSQL deployment
|
||||
|
||||
- `ExecutionAttempt` stores immutable per-call evidence and preserves full attempt history across retries.
|
||||
- `Source.raw_transcription` is intentionally a mutable projection so UI and exports can show a selected current machine text without mutating historical evidence.
|
||||
- This split keeps auditability and UX both first-class: history is durable, presentation is editable.
|
||||
### Stage 2: Throughput Hardening
|
||||
|
||||
### Why orchestration modules own cross-service workflows
|
||||
- optional MongoDB document-store enablement
|
||||
- optional external worker/queue process
|
||||
- stronger retry and dead-letter handling
|
||||
|
||||
- Service modules do not import each other; aggregate ownership remains local to each service.
|
||||
- Multi-aggregate writes are coordinated in orchestration modules (`store.py`, `workflows.py`) so transaction boundaries are explicit and testable.
|
||||
- This avoids circular dependencies and keeps cross-cutting workflow logic centralized.
|
||||
### Stage 3: Intelligence Features
|
||||
|
||||
### Why explicit eager loading is required
|
||||
- entity extraction and cross-document linking
|
||||
- timeline and narrative assembly
|
||||
- optional multi-provider routing
|
||||
|
||||
- ORM relationships are configured with `lazy="raise"` in key paths, so code must request needed relationships up front.
|
||||
- This prevents hidden query behavior in UI/service code and makes read shape deterministic and reviewable.
|
||||
Each stage preserves existing module boundaries and keeps migration risk low.
|
||||
|
||||
### Why canonical source bytes may be ingest-normalized
|
||||
## Test Strategy
|
||||
|
||||
- Ingest normalization can correct orientation before persistence so provider calls, evidence hashes, and rendered processing source are consistent.
|
||||
- The canonical stored bytes, digest, and size become the durable processing identity for that source.
|
||||
The test strategy is aligned to personal-scale operation with fast, deterministic feedback.
|
||||
|
||||
### Why media access uses controlled routes/helpers
|
||||
### Unit Tests
|
||||
|
||||
- Print/export media uses record-validated API endpoints to avoid direct filesystem path exposure.
|
||||
- General UI media URLs are generated through shared resolver helpers to keep path handling consistent and centralized.
|
||||
- domain transcription rules and annotation behavior
|
||||
- revision-history invariants
|
||||
- job state-transition logic
|
||||
|
||||
## Scope Boundary
|
||||
### Integration Tests
|
||||
|
||||
Current architecture rules live in `docs/*`.
|
||||
- repository behavior and transaction boundaries
|
||||
- persistence-adapter and provider adapter contract mapping
|
||||
- upload-to-persistence roundtrip
|
||||
|
||||
## Related References
|
||||
### End-to-End Tests
|
||||
|
||||
- [System Requirements](requirements.md)
|
||||
- [Data Model](schema.md)
|
||||
- [Error Handling Policy](error_handling.md)
|
||||
- [Production Runbook](production-runbook.md)
|
||||
- [Backup and Restore](backup_restore.md)
|
||||
- [Error Handling invariant](./invariant/error_handling.md)
|
||||
- [AI evidence invariant](./invariant/ai_evidence_and_provenance.md)
|
||||
- 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.
|
||||
|
||||
@@ -1,60 +0,0 @@
|
||||
# Backup and Restore (V6.1)
|
||||
|
||||
This guide defines operational backup/restore for clean-slate recovery of the Docker runtime using a host-visible backup folder.
|
||||
|
||||
## 1. Backup artifacts
|
||||
|
||||
- Backup target root: `BACKUP_DIR` (recommended production value: `/backup`)
|
||||
- Database artifact per run:
|
||||
- `postgres-YYYYMMDD-HHMMSS.dump` (PostgreSQL custom dump via `pg_dump -Fc`)
|
||||
- `backup-YYYYMMDD-HHMMSS.manifest` (run manifest)
|
||||
- Media/config mirrors under `BACKUP_DIR`:
|
||||
- `uploads/**` (incremental copy: new files only)
|
||||
- `prompts/**` (prompt directory mirror)
|
||||
|
||||
Retention:
|
||||
|
||||
- `BACKUP_RETENTION_DAYS` applies to `postgres-*.dump` and `backup-*.manifest` files.
|
||||
|
||||
## 2. Creating backups
|
||||
|
||||
Run from repository root:
|
||||
|
||||
```bash
|
||||
sh deploy/backup/create_postgres_backup.sh
|
||||
```
|
||||
|
||||
Environment variables used by the backup script:
|
||||
|
||||
- `BACKUP_DIR` (default `./data/backups`)
|
||||
- `BACKUP_RETENTION_DAYS` (default `14`)
|
||||
- `UPLOAD_DIR` (default `/app/uploads`)
|
||||
- `PROMPT_DIR` (default `/app/prompts`)
|
||||
- `DATABASE__DRIVER` (must be `postgres`)
|
||||
- `DATABASE__HOST` (default `postgres`)
|
||||
- `DATABASE__PORT` (default `5432`)
|
||||
- `DATABASE__DATABASE` (required)
|
||||
- `DATABASE__USER` (required)
|
||||
- `DATABASE__PASSWORD` (required)
|
||||
|
||||
Recommended production setup:
|
||||
|
||||
- Mount a host-visible folder into `/backup` for both `app` and `worker`.
|
||||
- Set `BACKUP_DIR=/backup` in `.env.production`.
|
||||
- Use host-level tooling (for example Synology Drive Client on the host) to replicate that folder externally.
|
||||
|
||||
## 3. Restoring from backup
|
||||
|
||||
Restore requires downtime for app + worker writes.
|
||||
|
||||
1. Stop app and worker:
|
||||
- `docker compose --env-file .env.production -f docker-compose.production.yml stop app worker`
|
||||
2. Restore database:
|
||||
- `sh deploy/backup/restore_postgres_backup.sh /backup/postgres-YYYYMMDD-HHMMSS.dump`
|
||||
3. Start app and worker:
|
||||
- `docker compose --env-file .env.production -f docker-compose.production.yml start app worker`
|
||||
4. Validate `/healthz` and run one smoke workflow.
|
||||
|
||||
Notes:
|
||||
|
||||
- `restore_postgres_backup.sh` still supports legacy archive restore paths for older backup sets.
|
||||
@@ -1,66 +0,0 @@
|
||||
# Cloudflare Tunnel and Access Setup
|
||||
|
||||
This guide defines the repository-supported setup for exposing app and selected LAN services through Cloudflare Tunnel with Cloudflare Access protection.
|
||||
|
||||
## 1. Files used by this deployment
|
||||
|
||||
1. `deploy/cloudflared/config.yml` (local copy from `config.yml.example`)
|
||||
2. `.env.production` (`CLOUDFLARE_TUNNEL_TOKEN`)
|
||||
3. `docker-compose.production.yml` (`cloudflared` service reads token + mounts config)
|
||||
|
||||
Do not commit `config.yml` or `.env.production`.
|
||||
|
||||
## 2. Configure cloudflared
|
||||
|
||||
1. Copy `deploy/cloudflared/config.yml.example` to `deploy/cloudflared/config.yml`.
|
||||
2. Update hostname -> service mappings in `ingress`.
|
||||
3. Keep the final catch-all ingress `http_status:404`.
|
||||
4. Set `CLOUDFLARE_TUNNEL_TOKEN` in `.env.production`.
|
||||
|
||||
Example app route:
|
||||
|
||||
- `transcription.example.com` -> `http://app:8000`
|
||||
|
||||
Optional generic remote-access routes:
|
||||
|
||||
- `homeassistant.example.com` -> `http://<home-assistant-lan-ip>:8123`
|
||||
- `pihole.example.com` -> `http://<pihole-lan-ip>:80`
|
||||
|
||||
## 3. Cloudflare Access policy baseline
|
||||
|
||||
Create one Access app policy per exposed hostname:
|
||||
|
||||
1. Include: your allowed identities/groups only.
|
||||
2. Exclude: none by default.
|
||||
3. Require: identity provider login (and MFA if available).
|
||||
|
||||
Recommended baseline:
|
||||
|
||||
- App endpoint (`transcription.*`): your admin identity set.
|
||||
- Other internal endpoints (`homeassistant.*`, `pihole.*`, etc.): explicit least-privilege groups.
|
||||
|
||||
## 4. Startup
|
||||
|
||||
Start production stack:
|
||||
|
||||
```bash
|
||||
docker compose --env-file .env.production -f docker-compose.production.yml up -d --build
|
||||
```
|
||||
|
||||
Validate tunnel container:
|
||||
|
||||
```bash
|
||||
docker compose --env-file .env.production -f docker-compose.production.yml logs cloudflared
|
||||
```
|
||||
|
||||
LXC/proxied-network note:
|
||||
|
||||
- The `cloudflared` service is pinned to `--protocol http2` with explicit DNS resolvers (`1.1.1.1`, `1.0.0.1`) in `docker-compose.production.yml`.
|
||||
- This avoids environments where Docker's embedded resolver (`127.0.0.11`) cannot resolve `region*.v2.argotunnel.com`, which causes connector precheck failure and tunnel shutdown.
|
||||
- If tunnel status is still down, verify host/container egress for DNS and TCP 443 to `api.cloudflare.com` and `*.argotunnel.com`.
|
||||
|
||||
## 5. Security notes
|
||||
|
||||
- Keep `postgres` and other internal-only services off public hostnames unless required.
|
||||
- Use distinct hostnames per service; avoid path-based multiplexing for unrelated admin surfaces.
|
||||
- Rotate `CLOUDFLARE_TUNNEL_TOKEN` and Access policy memberships on a regular schedule.
|
||||
@@ -1,94 +0,0 @@
|
||||
# Database Rebuild Migration Workflow
|
||||
|
||||
This project uses an explicit **export/import rebuild workflow** for schema migration.
|
||||
|
||||
Policy:
|
||||
- Do not add runtime legacy-compatibility write paths.
|
||||
- Rebuild a fresh target database from current models.
|
||||
- Export current data/media, then import into the fresh target.
|
||||
|
||||
## Commands
|
||||
|
||||
### 1) Export current DB + uploads into a bundle
|
||||
|
||||
```bash
|
||||
uv run python tools/export_import_migration.py export --bundle-dir .migration-bundle
|
||||
```
|
||||
|
||||
Optional source overrides:
|
||||
- `--source-db <path-or-sqlalchemy-url>`
|
||||
- `--source-upload-dir <path>`
|
||||
|
||||
### 2) Import bundle into a fresh target (SQLite or PostgreSQL)
|
||||
|
||||
```bash
|
||||
uv run python tools/export_import_migration.py import --bundle-dir .migration-bundle --target-db .\data\transcription-new.db --target-upload-dir .\data-new
|
||||
```
|
||||
|
||||
PostgreSQL target example:
|
||||
|
||||
```bash
|
||||
uv run python tools/export_import_migration.py import --bundle-dir .migration-bundle --target-db postgresql://transcription:change-me@localhost:5432/transcription --target-upload-dir .\data-new
|
||||
```
|
||||
|
||||
### 3) Verify migration parity and integrity
|
||||
|
||||
```bash
|
||||
uv run python tools/export_import_migration.py verify --source-db .\data\transcription.db --target-db postgresql://transcription:change-me@localhost:5432/transcription
|
||||
```
|
||||
|
||||
The verify command checks:
|
||||
|
||||
- row-count parity across migration tables
|
||||
- orphan-reference checks for `source`, `job`, `job_source`, and `execution_attempt`
|
||||
- duplicate `(job_id, source_id, attempt_number)` in `execution_attempt`
|
||||
|
||||
Exit code:
|
||||
|
||||
- `0` when counts and integrity checks pass
|
||||
- `1` when mismatches or integrity violations are detected
|
||||
|
||||
### 4) One-shot export+import
|
||||
|
||||
```bash
|
||||
uv run python tools/export_import_migration.py migrate --bundle-dir .migration-bundle --target-db .\data\transcription-new.db --target-upload-dir .\data-new
|
||||
```
|
||||
|
||||
## What gets migrated
|
||||
|
||||
- Tables (in dependency order): `document_type`, `person_role`, `tag`, `document`, `person`, `photo`, `document_person`, `document_tag`, `person_tag`, `job`, `source`, `job_source`, `execution_attempt`.
|
||||
- Media tree under `UPLOAD_DIR`.
|
||||
|
||||
The bundle contains:
|
||||
- `database.json` (row export)
|
||||
- `uploads/` (copied media files)
|
||||
|
||||
Path normalization during export/import:
|
||||
- `source.file_path` is normalized to `documents/...` (upload-root-relative POSIX).
|
||||
- `photo.path` is normalized to `photos/...` (upload-root-relative POSIX).
|
||||
|
||||
Legacy V4.x portrait/homepage backfill in the export step:
|
||||
- If the source DB has no `photo` table, the exporter synthesizes `photo` rows from legacy `person.portrait_path` values and from legacy homepage image files under `UPLOAD_DIR/homepage`.
|
||||
- Legacy portrait and homepage image files are copied into the unified `UPLOAD_DIR/photos/{photo_id}{suffix}` layout in the migration bundle.
|
||||
- Legacy homepage markdown is relocated from `UPLOAD_DIR/homepage/homepage.md` to `UPLOAD_DIR/homepage.md`.
|
||||
- Legacy `person.full_name` values are split into `given_names` + `last_name` for V5.1 schema compatibility.
|
||||
|
||||
## Cutover (SQLite -> PostgreSQL)
|
||||
|
||||
After importing to a fresh target:
|
||||
1. Stop app and worker services to freeze writes.
|
||||
2. Export a migration bundle from the last SQLite state.
|
||||
3. Import bundle to PostgreSQL target.
|
||||
4. Run `verify` against source and target before switching runtime.
|
||||
5. Switch runtime config to PostgreSQL (`DATABASE__DRIVER=postgres` and related `DATABASE__*` values).
|
||||
6. Start app and worker services.
|
||||
7. Run smoke checks (`/healthz`, create/upload/process one job).
|
||||
|
||||
## Rollback
|
||||
|
||||
If verify or smoke checks fail:
|
||||
|
||||
1. Stop app and worker services.
|
||||
2. Revert runtime config to SQLite.
|
||||
3. Start app and worker against pre-cutover SQLite database.
|
||||
4. Preserve failed migration bundle and logs for analysis.
|
||||
+261
-116
@@ -1,137 +1,282 @@
|
||||
# Error Handling Policy (Current Baseline: V6.1)
|
||||
# Error Handling
|
||||
|
||||
This policy defines the active V6.1 error taxonomy, translation boundaries, and retry semantics.
|
||||
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 Categories
|
||||
## Error Handling Objectives
|
||||
|
||||
| Category | Meaning | Typical Origin | User Treatment |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| `validation` | Input payload/selection is invalid | UI form parsing, service validators | Inline correction guidance |
|
||||
| `not_found` | Target record is missing | ID lookup in service layer | Non-blocking warning or redirect |
|
||||
| `conflict` | State prevents requested action | lifecycle transitions, duplicate semantic keys | Explain required precondition |
|
||||
| `external` | Provider/network dependency failure | OpenRouter/provider adapter | Retry path and evidence retained |
|
||||
| `timeout` | Provider call exceeded configured bound | worker/provider client timeout | Retry path and bounded messaging |
|
||||
| `internal` | Unexpected local failure | unhandled service/runtime faults | Safe generic message + diagnostics capture |
|
||||
The production error-handling model is designed to:
|
||||
|
||||
## Runtime Taxonomy and Canonical Mapping
|
||||
- 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
|
||||
|
||||
Runtime code uses a richer internal taxonomy for diagnostics and persisted evidence, then maps that
|
||||
taxonomy to the six canonical categories at the API/UI envelope boundary.
|
||||
## Scope And Authority
|
||||
|
||||
### Internal runtime categories
|
||||
This page governs error-handling behavior for:
|
||||
|
||||
- `validation_error`
|
||||
- `user_input_error`
|
||||
- `not_found_error`
|
||||
- `conflict_error`
|
||||
- `external_provider_error`
|
||||
- `external_timeout_error`
|
||||
- `processing_error`
|
||||
- `infrastructure_transient_error`
|
||||
- `infrastructure_persistent_error`
|
||||
- `internal_unexpected_error`
|
||||
- UI interactions (NiceGUI pages)
|
||||
- API endpoints (FastAPI routes)
|
||||
- application services and orchestration logic
|
||||
- in-process background worker execution
|
||||
- external provider adapters and persistence adapters
|
||||
|
||||
### Internal -> Canonical mapping
|
||||
If implementation behavior conflicts with this document, this document is authoritative and implementation should be updated.
|
||||
|
||||
| Internal category | Canonical envelope category |
|
||||
| :--- | :--- |
|
||||
| `validation_error` | `validation` |
|
||||
| `user_input_error` | `validation` |
|
||||
| `not_found_error` | `not_found` |
|
||||
| `conflict_error` | `conflict` |
|
||||
| `external_provider_error` | `external` |
|
||||
| `external_timeout_error` | `timeout` |
|
||||
| `infrastructure_transient_error` | `timeout` |
|
||||
| `processing_error` | `internal` |
|
||||
| `infrastructure_persistent_error` | `internal` |
|
||||
| `internal_unexpected_error` | `internal` |
|
||||
## Core Principles
|
||||
|
||||
`ExecutionAttempt.error_category` stores the internal category value so diagnostics remain specific.
|
||||
- **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.
|
||||
|
||||
## Translation Boundaries
|
||||
## Error Taxonomy
|
||||
|
||||
- **Provider layer:** raise provider-scoped exceptions with provider context; do not emit UI text.
|
||||
- **Service layer:** map raw exceptions into internal categories and preserve causal chain.
|
||||
- **UI/API layer:** convert internal categories to canonical categories using the centralized mapping.
|
||||
The system uses stable, implementation-independent categories:
|
||||
|
||||
## Decision Context
|
||||
|
||||
### Why taxonomy is category-based (not exception-class-based)
|
||||
|
||||
- Categories encode operator-facing recovery semantics (fix input, retry later, investigate internal failure) independent of low-level exception type.
|
||||
- This keeps retry and messaging behavior consistent even when provider/client libraries change.
|
||||
|
||||
### Why page-level failure is isolated
|
||||
|
||||
- Multi-page archival documents often contain a mix of readable and degraded pages.
|
||||
- Isolating failures to page scope preserves successful results and avoids all-or-nothing loss when one page fails.
|
||||
- Aggregate job status then communicates overall outcome (`transcribed`, `partial_success`, `failed`) without hiding page detail.
|
||||
|
||||
### Why retries append evidence instead of mutating rows
|
||||
|
||||
- Retry operations are new observations, not corrections of history.
|
||||
- Appending attempts preserves forensic traceability, timing history, and provider variability analysis.
|
||||
- Projection updates remain explicit user/workflow decisions, separate from immutable evidence.
|
||||
|
||||
## Job and Page Failure Semantics
|
||||
|
||||
### Page-Level (`JobSource`)
|
||||
|
||||
- `pending` -> `transcribed` when attempt succeeds.
|
||||
- `pending` -> `failed` when attempt fails terminally.
|
||||
- `pending` -> `cancelled` on job cancellation before processing.
|
||||
|
||||
### Job-Level (`Job`)
|
||||
|
||||
- `transcribed` when all pages transcribe successfully.
|
||||
- `partial_success` when mixed success/failure outcomes exist.
|
||||
- `failed` when no page transcribes successfully.
|
||||
|
||||
## Retry and Retranscription Rules
|
||||
|
||||
1. Failed/cancelled pages may be re-queued through retranscription workflows.
|
||||
2. Retry attempts must append new `ExecutionAttempt` rows; prior evidence remains immutable.
|
||||
3. Selecting a better candidate must update projection pointers, not mutate historical attempt rows.
|
||||
|
||||
## Logging and Diagnostics Rules
|
||||
|
||||
1. Persist sufficient attempt error metadata (`error_category`, `error_message`, transport evidence) for post-hoc analysis.
|
||||
2. Avoid leaking stack traces or local paths into user-facing message envelopes.
|
||||
3. Preserve causal exception chains for internal diagnostics.
|
||||
|
||||
### Message vs detail split
|
||||
|
||||
Rules 1 and 2 pull in opposite directions: evidence records need the root cause, and
|
||||
user-facing envelopes must not carry it. `AppError` therefore separates the two audiences:
|
||||
|
||||
| Field | Audience | Carries root cause | Surfaces |
|
||||
| Category | Definition | Typical Source | Retriable |
|
||||
| --- | --- | --- | --- |
|
||||
| `message` | User-facing and API-facing | No | `show_error`, `build_error_envelope` |
|
||||
| `detail` | Internal only | Yes | `format_error_detail` (evidence), logs, sanitized UI projection only |
|
||||
| `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) |
|
||||
|
||||
`classify_unexpected_error` builds a generic `message` and puts the exception type and
|
||||
text on `detail`. Anything rendered to a user or serialized into an API envelope must
|
||||
read `message`; anything persisted as provenance or logged may read `detail`. When a UI
|
||||
surface needs to show persisted `error_detail`, it must route through a sanitizing
|
||||
projection that preserves the category, suggestion, and error reference while reducing
|
||||
machine-local absolute paths to basenames only.
|
||||
Enforced by `tests/test_errors.py::test_unexpected_error_does_not_leak_filesystem_paths`
|
||||
and `tests/test_error_message_safety.py`.
|
||||
### Classification Rules
|
||||
|
||||
## Operator Recovery Guidance
|
||||
- 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.
|
||||
|
||||
- **validation/conflict:** correct input or state and retry manually.
|
||||
- **external/timeout:** allow bounded retries and keep prior attempt evidence visible.
|
||||
- **internal:** stop automatic retries, surface a safe message, and inspect diagnostics with correlation context.
|
||||
## User-Facing Error Experience Contract
|
||||
|
||||
## UI Messaging Contract
|
||||
When an error is shown in the GUI, it must include:
|
||||
|
||||
- User-visible errors must be actionable, bounded, and category-consistent.
|
||||
- Multi-page jobs must show partial outcomes instead of collapsing into a single opaque failure.
|
||||
- Recovery actions (`retry`, `retranscribe`, `edit input`) must be offered where available.
|
||||
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)
|
||||
|
||||
## Cross-Reference
|
||||
### UI Message Rules
|
||||
|
||||
- [Error Handling invariant](./invariant/error_handling.md)
|
||||
- [System Requirements](requirements.md)
|
||||
- [Data Model](schema.md)
|
||||
- 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.
|
||||
+45
-26
@@ -1,36 +1,55 @@
|
||||
# Document Transcription System Overview (Current Baseline: V6.1)
|
||||
## Document Transcription System
|
||||
|
||||
This directory is the single source of truth for current V6.1 behavior and architecture.
|
||||
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.
|
||||
|
||||
## Canonical Reading Order
|
||||
## Start Here
|
||||
|
||||
1. [System Architecture](architecture.md) for runtime topology, boundaries, and lifecycle ownership.
|
||||
2. [System Requirements](requirements.md) for verifiable current-state requirements.
|
||||
3. [Data Model](schema.md) for entities, constraints, and evidence persistence rules.
|
||||
4. [Error Handling Policy](error_handling.md) for category, translation, and retry behavior.
|
||||
Read [architecture.md](architecture.md) first.
|
||||
|
||||
## Cross-Version Invariants
|
||||
Then review [ver1/ver1.md](ver1/ver1.md) for completion scope.
|
||||
|
||||
- [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)
|
||||
The architecture page is the primary technical reference and defines:
|
||||
|
||||
## Deployment and Operations
|
||||
- deployed topology and infrastructure limits
|
||||
- module boundaries and dependency flow
|
||||
- processing life cycle and data ownership
|
||||
- test strategy, risk controls, and extension path
|
||||
|
||||
- [Production Runbook](production-runbook.md) for deploy, rollback, and recovery.
|
||||
- [Backup and Restore](backup_restore.md) for backup configuration and restore procedure.
|
||||
- [Data Migration](data_migration.md) for the SQLite to PostgreSQL migration path.
|
||||
- [Cloudflare Tunnel and Access](cloudflare_tunnel_access.md) for remote exposure and access control.
|
||||
## What The Application Does
|
||||
|
||||
## Baseline Statement
|
||||
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.
|
||||
|
||||
The current V6.1 baseline includes the architectural cleanup, person-schema redesign,
|
||||
containerized PostgreSQL deployment, and the navigation, Document Detail, and worker-backed
|
||||
maintenance refinements reflected across this canonical document set.
|
||||
Use this `docs/*` canonical set for active design and implementation decisions.
|
||||
Core capabilities:
|
||||
|
||||
Every canonical document above states this same baseline; `tests/test_meta_contract_guards.py`
|
||||
fails if one of them falls behind. Forward-looking work is tracked in
|
||||
[`roadmap_plan.md`](roadmap_plan.md) and is not part of the baseline.
|
||||
- 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.
|
||||
|
||||
@@ -1,145 +0,0 @@
|
||||
# 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 canonical stored media used for processing 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 Canonical Source Preservation
|
||||
|
||||
1. Each source must have one canonical stored byte stream used for processing and provenance.
|
||||
2. Canonical storage may apply deterministic ingest normalization before persistence.
|
||||
3. Canonical stored bytes must have a cryptographic content digest, byte size, and stable identity.
|
||||
4. Post-ingest processing derivatives must not overwrite canonical stored bytes.
|
||||
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. Canonical source digest (and derivative digests when used), 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 canonical 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.
|
||||
|
||||
The deterministic scorer for these comparisons lives in `src/transcription/benchmarking.py`; it is
|
||||
retained as evaluation-policy infrastructure even though application runtime paths do not call it
|
||||
directly.
|
||||
|
||||
Benchmark material containing family records remains private application data unless explicitly approved for publication.
|
||||
|
||||
## 6. Ownership and Change Policy
|
||||
|
||||
1. Canonical V6.1 architecture, schema, requirements, and error-policy documents define how current behavior 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)
|
||||
@@ -1,101 +0,0 @@
|
||||
# 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)
|
||||
|
||||
@@ -1,25 +0,0 @@
|
||||
# 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))
|
||||
|
||||
@@ -1,72 +0,0 @@
|
||||
# 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. |
|
||||
|
||||
### 3.4 Document-Body Medium
|
||||
|
||||
Every transcript must identify the predominant document-body medium exactly once at the beginning:
|
||||
|
||||
| Medium | Use | Standard Markup |
|
||||
| --- | --- | --- |
|
||||
| **Handwritten** | The main body was written by hand. | `[document body handwritten]` |
|
||||
| **Typewritten** | The main body was produced with a typewriter. Uneven impressions, monospaced characters, and mechanical defects remain typewritten rather than handwritten. | `[document body typewritten]` |
|
||||
| **Typeset** | The main body was composed for printing or produced as printed text rather than with a typewriter. | `[document body typeset]` |
|
||||
| **Mixed** | No single medium predominates, or handwritten and printed/typewritten content are structurally interleaved. | `[document body mixed]` |
|
||||
|
||||
- Use exactly one document-body marker.
|
||||
- Do not wrap each line in `[handwritten: ...]` after declaring the body handwritten.
|
||||
- In typewritten or typeset documents, use localized handwriting markers only for genuinely handwritten annotations, insertions, or signatures.
|
||||
- In mixed documents, identify handwritten portions locally while preserving their reading context.
|
||||
- Preserve tables of contents, tables, forms, columns, captions, marginalia, page numbers, dotted leaders, and associated references in their logical reading order.
|
||||
- Produce plain text characters rather than HTML entities for ordinary transcription content.
|
||||
|
||||
## 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.
|
||||
@@ -1,110 +0,0 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,572 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,278 @@
|
||||
## 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
|
||||
@@ -0,0 +1,236 @@
|
||||
## 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.
|
||||
@@ -0,0 +1,262 @@
|
||||
## 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
|
||||
@@ -0,0 +1,70 @@
|
||||
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.
|
||||
@@ -0,0 +1,310 @@
|
||||
## 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
|
||||
|
||||
---
|
||||
|
||||
@@ -0,0 +1,50 @@
|
||||
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.)
|
||||
|
||||
@@ -0,0 +1,229 @@
|
||||
## 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)
|
||||
@@ -0,0 +1,134 @@
|
||||
## 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.
|
||||
@@ -0,0 +1,267 @@
|
||||
## 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
|
||||
+209
@@ -0,0 +1,209 @@
|
||||
## 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.
|
||||
@@ -1,184 +0,0 @@
|
||||
# Production Runbook
|
||||
|
||||
This runbook is the operational checklist for releasing and monitoring the transcription system.
|
||||
|
||||
## 1. Pre-release gate checklist
|
||||
|
||||
1. Run the full suite: `uv run pytest`
|
||||
2. Confirm contract guardrails are green:
|
||||
- `uv run pytest tests/test_meta_contract_guards.py`
|
||||
3. Confirm health endpoint includes worker liveness payload (`/healthz` returns `worker.state`).
|
||||
4. Confirm required runtime settings are present in deployment environment:
|
||||
- `OPENROUTER_API_KEY`
|
||||
- `DATABASE__*`
|
||||
- filesystem paths for data/logs/backups.
|
||||
- `CLOUDFLARE_TUNNEL_TOKEN`
|
||||
5. Confirm schema contract alignment is current:
|
||||
- `src/transcription/db/models.py`
|
||||
- `docs/schema.md`
|
||||
|
||||
## 2. Release execution steps
|
||||
|
||||
1. Deploy artifact/config to target environment.
|
||||
- Production stack: `docker compose -f docker-compose.production.yml up -d --build`
|
||||
- `Settings` loads from explicit `_env_file`, then `ENV_FILE`, then the repository-root `.env.production`; it does not resolve relative to the process working directory.
|
||||
- For Runtime Settings writes in production, mount `.env.production` into the app container and set `RUNTIME_SETTINGS_ENV_FILE=/app/.env.production`.
|
||||
- If deployment uses a non-default env-file location, set both `ENV_FILE` and `RUNTIME_SETTINGS_ENV_FILE` to that absolute path so startup reads and Settings-page writes stay aligned.
|
||||
- For SQLite -> PostgreSQL cutover, run `uv run python tools/export_import_migration.py verify --source-db <sqlite-path-or-url> --target-db <postgres-url>` before switching runtime.
|
||||
2. Validate service startup:
|
||||
- `/healthz` responds `200`
|
||||
- if `RUN_EMBEDDED_WORKER=true`, `worker.state` is `running`
|
||||
- if `RUN_EMBEDDED_WORKER=false`, validate `worker` container is running in Compose
|
||||
(worker healthcheck is intentionally disabled because it does not expose `/healthz`)
|
||||
- validate `cloudflared` logs show active tunnel routes and no ingress errors
|
||||
3. Execute one smoke workflow:
|
||||
- create a document/job with at least one source
|
||||
- verify terminal job outcome updates
|
||||
- verify execution evidence row appended
|
||||
4. Verify log flow:
|
||||
- stdout aggregation receives events
|
||||
- file logs are written under `./data/logs`
|
||||
5. Create a fresh PostgreSQL backup after successful deployment:
|
||||
- `sh deploy/backup/create_postgres_backup.sh` (creates DB dump plus uploads/prompts backups under `BACKUP_DIR`)
|
||||
|
||||
## 3. Rollback triggers and actions
|
||||
|
||||
### Trigger conditions
|
||||
|
||||
1. `/healthz` reports `worker.state=failed`
|
||||
2. Repeated provider timeout/error spikes beyond normal baseline
|
||||
3. Evidence write failures or DB persistence failures
|
||||
|
||||
### Actions
|
||||
|
||||
1. Roll back app artifact and config to previous release.
|
||||
2. Restart service and re-check `/healthz`.
|
||||
3. Re-run smoke workflow and confirm worker returns to `running`.
|
||||
4. Preserve incident evidence:
|
||||
- `./data/logs`
|
||||
- relevant DB rows (`job`, `job_source`, `execution_attempt`)
|
||||
5. If persistence regression is confirmed, restore the latest valid DB dump:
|
||||
- `sh deploy/backup/restore_postgres_backup.sh <dump-file>`
|
||||
- Synology media mirror and paired config snapshot (same timestamp) are restored automatically when present.
|
||||
|
||||
## 4. Post-release monitoring checklist
|
||||
|
||||
## First 24 hours
|
||||
|
||||
1. Monitor `/healthz` periodically for `worker.state`.
|
||||
2. Track job terminal distribution (`transcribed`, `partial_success`, `failed`).
|
||||
3. Sample timeout/error categories for abnormal increase.
|
||||
4. Spot-check new `execution_attempt` records for append-only growth and timing metadata.
|
||||
|
||||
## First 72 hours
|
||||
|
||||
1. Re-check error/timeout trend versus 24h baseline.
|
||||
2. Verify no recurring worker-failed states.
|
||||
3. Verify storage growth and rotation behavior under `./data/logs`.
|
||||
4. Confirm incident response notes are captured for any production anomalies.
|
||||
|
||||
## 5. Operator playbook for common incidents
|
||||
|
||||
### Worker failed
|
||||
|
||||
1. Check `/healthz` payload (`error_id`, `error_category`).
|
||||
2. Locate matching error in logs.
|
||||
3. If non-transient defect persists, roll back.
|
||||
|
||||
### Provider timeout spike
|
||||
|
||||
1. Confirm provider reachability and rate limits.
|
||||
2. Review timeout frequency and impacted job volume.
|
||||
3. If sustained, execute rollback criteria and notify stakeholders.
|
||||
|
||||
### Partial-success increase
|
||||
|
||||
1. Inspect affected `job_source` and `execution_attempt` records.
|
||||
2. Confirm failures are category-aligned (`external`/`timeout`/`internal`).
|
||||
3. Triage whether issue is source quality, provider, or runtime regression.
|
||||
|
||||
### Cloudflare ingress/access failure
|
||||
|
||||
1. Check `cloudflared` container logs for ingress parse, DNS, or auth failures.
|
||||
2. Confirm `deploy/cloudflared/config.yml` hostname mappings are correct.
|
||||
3. Confirm `CLOUDFLARE_TUNNEL_TOKEN` in `.env.production` matches the tunnel configured in Cloudflare.
|
||||
4. Confirm Cloudflare Access app policy includes the intended identity/group for that hostname.
|
||||
5. If logs show SRV/DNS failures via `127.0.0.11`, use the compose-defined resolver override
|
||||
(`dns: 1.1.1.1, 1.0.0.1`) and ensure outbound TCP 443 is allowed.
|
||||
|
||||
### Backup or restore failure
|
||||
|
||||
1. Verify `postgres` container is healthy and accepting connections.
|
||||
2. Confirm dump file exists and is non-zero size.
|
||||
3. Re-run backup/restore scripts with explicit `ENV_FILE` and `COMPOSE_FILE` if using non-default paths.
|
||||
4. If direct Synology copy fails, keep local backup and resolve mount/network before next backup cycle.
|
||||
- For LXC setups, use `deploy/backup/mount_synology_cifs.example.sh` as the persistent mount template.
|
||||
|
||||
## 6. Dependency upgrade policy
|
||||
|
||||
Dependencies are declared in `pyproject.toml` and resolved through the committed
|
||||
`uv.lock`. The lockfile guarantees reproducible installs; the version specifiers
|
||||
control what a deliberate `uv lock --upgrade` is allowed to move.
|
||||
|
||||
### NiceGUI is pinned exactly (`nicegui==3.13.0`)
|
||||
|
||||
1. **Rationale.** NiceGUI bundles Quasar and Vue. Minor releases change component
|
||||
props, slots, and styling, which surfaces as visual and interaction regressions
|
||||
rather than import or type errors. The UI suite under `tests/ui/` asserts
|
||||
structure and behavior, not rendered appearance, so a NiceGUI bump can pass the
|
||||
full test suite and still degrade the interface.
|
||||
2. **Scope of risk.** All NiceGUI usage is confined to `src/transcription/ui/` and
|
||||
uses only the public `nicegui.ui` and `nicegui.events` surfaces. The coupling is
|
||||
shallow, so the pin is about release stability, not about unpicking deep
|
||||
framework entanglement.
|
||||
3. **Current stance.** Hold the exact pin through release stabilization. Do not
|
||||
widen it as incidental cleanup, and do not let automated dependency updates move
|
||||
it. This includes forgoing patch releases, which is the accepted cost.
|
||||
4. **Revisiting.** Treat a NiceGUI upgrade as scheduled work with its own change
|
||||
window: bump the pin deliberately, run `uv run pytest -m "not external"`, then
|
||||
manually verify each page contract in `docs/ui/pages/` before accepting.
|
||||
|
||||
### All other dependencies
|
||||
|
||||
Declared with `>=` floors and moved by explicit `uv lock --upgrade`. Verify with
|
||||
`uv run ruff check .`, `uv run ty check`, and `uv run pytest -q -m "not external"`
|
||||
before committing a changed lockfile.
|
||||
|
||||
## 7. Type-check suppression policy
|
||||
|
||||
`uv run ty check` is a blocking pre-commit gate. Suppressions are allowed only for
|
||||
proven SQLAlchemy descriptor false positives where runtime behavior is correct and
|
||||
the checker cannot represent the descriptor protocol at that call site.
|
||||
|
||||
Every suppression must be:
|
||||
|
||||
1. **Targeted** to a single rule (for example `# ty: ignore[unresolved-attribute]`).
|
||||
2. **Inline** on the expression it suppresses (not file-wide).
|
||||
3. Followed by a **one-line rationale** stating it is a SQLAlchemy descriptor false positive.
|
||||
|
||||
Do not use broad or rationale-free suppressions. If a diagnostic is not a known
|
||||
false positive, fix the code instead of suppressing it.
|
||||
|
||||
## 8. Worker shutdown budget
|
||||
|
||||
Worker shutdown waits for at most:
|
||||
|
||||
`WORKER_PROVIDER_TIMEOUT_SECONDS + WORKER_SHUTDOWN_GRACE_SECONDS`
|
||||
|
||||
`WORKER_PROVIDER_TIMEOUT_SECONDS` covers an in-flight provider call, and
|
||||
`WORKER_SHUTDOWN_GRACE_SECONDS` is extra time for the loop to persist outcomes
|
||||
and exit cleanly after the call returns.
|
||||
|
||||
Set the container or service termination grace period **above this total**
|
||||
budget. If termination grace is shorter, the process may be killed before
|
||||
terminal status and evidence writes are finalized.
|
||||
|
||||
## 9. Horizontal scaling precondition
|
||||
|
||||
Multiple worker replicas can race on execution-attempt numbering for the same
|
||||
`(job_id, source_id)` pair. The runtime now retries boundedly on unique-key
|
||||
conflicts (`uq_execution_attempt_number`) and surfaces a conflict-domain error
|
||||
if retries are exhausted.
|
||||
|
||||
Do not deploy additional worker replicas unless this conflict-retry path and its
|
||||
tests are present and green in the target build.
|
||||
+64
-98
@@ -1,118 +1,84 @@
|
||||
# System Requirements (Current Baseline: V6.1)
|
||||
## Document Transcription System Requirements
|
||||
|
||||
These requirements define the active V6.1 contract and align to current implementation.
|
||||
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.
|
||||
|
||||
Requirement IDs encode the baseline that introduced them (`REQ-4-*` from V4, `REQ-6-*` from V6) and
|
||||
are stable. Never renumber an existing ID; retire it explicitly instead.
|
||||
## Scope
|
||||
|
||||
## Functional Requirements
|
||||
- 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.
|
||||
|
||||
### Domain and Record Management
|
||||
## Requirements Model (Concise Text Form)
|
||||
|
||||
- **REQ-4-001 Document Registry:** The system must create and update `Document` records with title, type, date metadata, optional location, optional archive identifier, and optional notes.
|
||||
- **REQ-4-002 Source Registry:** The system must create and update `Source` records linked to exactly one `Document`.
|
||||
- **REQ-4-003 People Registry:** The system must create and update `Person` records, support many-to-many links to `Document` with role, and support many-to-many Person tagging via the shared Tag registry.
|
||||
- **REQ-4-004 Registry Semantics:** Document types and person roles must support optional immutable semantic keys and hard-delete only when unreferenced.
|
||||
### Requirements
|
||||
|
||||
### Job and Workflow Behavior
|
||||
| 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 |
|
||||
|
||||
- **REQ-4-010 Job Creation:** The system must create `Job` records from uploaded sources and from retranscription of existing sources.
|
||||
- **REQ-4-011 Prompt Snapshotting:** Job creation must persist effective prompt and runtime settings as immutable per-job snapshots.
|
||||
- **REQ-4-012 Queue Membership:** Each `(job, source)` pair must be represented by one `JobSource` row.
|
||||
- **REQ-4-013 Job Status Lifecycle:** `Job.status` must use one of `queued`, `processing`, `transcribed`, `partial_success`, `failed`.
|
||||
- **REQ-4-014 JobSource Status Lifecycle:** `JobSource.status` must use one of `pending`, `transcribed`, `failed`, `cancelled`.
|
||||
- **REQ-4-015 Terminal Job Resolution:** Job terminal status must derive from page outcomes as `transcribed`, `partial_success`, or `failed`.
|
||||
- **REQ-4-016 Cancellation Semantics:** Job cancellation must set remaining `pending` page entries to `cancelled`.
|
||||
### Requirement Relationships
|
||||
|
||||
### Transcription and Evidence
|
||||
- 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.
|
||||
|
||||
- **REQ-4-020 Attempt Evidence:** Each provider call must emit one append-only `ExecutionAttempt` record.
|
||||
- **REQ-4-021 Attempt Payload:** `ExecutionAttempt` must retain request manifest/hash, outcome, timing, model/provider fields, and error details when present.
|
||||
- **REQ-4-022 Transport Evidence:** Provider response evidence must be attached to the attempt when a response is available.
|
||||
- **REQ-4-023 Source Projection Rule:** `Source.raw_transcription` is a projection chosen from attempt outcomes and can be repointed by explicit promotion.
|
||||
- **REQ-4-024 Candidate Visibility:** UI must expose candidate attempts with metadata needed for comparative review and selection.
|
||||
### Architecture Elements
|
||||
|
||||
### Media and Access
|
||||
| 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 |
|
||||
|
||||
- **REQ-4-030 Ingest Canonicalization:** Stored source bytes may be normalized at ingest (for example orientation correction); stored bytes are the canonical processing source.
|
||||
- **REQ-4-031 Path Safety:** Client-facing media URLs must be generated from controlled application paths only.
|
||||
- **REQ-4-032 Print Media Validation:** Print/export source media must be served through record-validated API routes.
|
||||
### Satisfaction Mapping
|
||||
|
||||
### Error and UX Contracts
|
||||
- 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.
|
||||
|
||||
- **REQ-4-040 Error Envelope:** Service/API errors must map to structured, user-safe error categories and messages.
|
||||
- **REQ-4-041 Partial Failure Visibility:** Mixed page outcomes must be visible at job and page level.
|
||||
- **REQ-4-042 Retry Support:** Failed and cancelled pages must support targeted retranscription without requiring full document recreation.
|
||||
### Verification Mapping
|
||||
|
||||
### Person Imagery
|
||||
- TESTS verifies REQ-1, REQ-2, REQ-3, REQ-4, REQ-5, REQ-10, REQ-11, REQ-12.
|
||||
|
||||
- **REQ-6-001 Photo Records:** The system must store reusable `Photo` records that are either owned by a `Person` or unowned for homepage gallery use.
|
||||
- **REQ-6-002 Primary Photo:** At most one photo per owning `Person` may be marked `is_primary`; setting a new primary must clear the previous one.
|
||||
- **REQ-6-003 Primary Reassignment:** Deleting an owner's primary photo must promote a remaining photo of that owner rather than leaving the owner without a primary.
|
||||
## Requirement Notes
|
||||
|
||||
### Operational Maintenance
|
||||
- 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.
|
||||
|
||||
- **REQ-6-010 Queued Maintenance Runs:** Settings-initiated maintenance must persist a `MaintenanceRun` and execute in the worker, not inline in the request that started it.
|
||||
- **REQ-6-011 Maintenance Run Types:** `MaintenanceRun.job_type` must use one of `backup`, `storage_reconciliation`, `gedcom_import`.
|
||||
- **REQ-6-012 Maintenance Status Lifecycle:** `MaintenanceRun.status` must use one of `queued`, `processing`, `succeeded`, `failed`.
|
||||
- **REQ-6-013 Single Claim:** A queued run must be claimed by at most one worker, using a conditional status update rather than read-then-write.
|
||||
- **REQ-6-014 Run History:** Completed runs must retain status, timing, summary, log reference, and error detail, and expose the log for viewing and download.
|
||||
- **REQ-6-015 GEDCOM Upload Import:** Settings must support manual `.ged` upload and queue-backed import into genealogy tables.
|
||||
- **REQ-6-016 GEDCOM Idempotent Upsert:** GEDCOM import must upsert `GenealogyPerson` and `GenealogyFamily` by FamilySearch IDs and avoid duplicate imported citations on re-run.
|
||||
## Verification Intent
|
||||
|
||||
### Deployment and Runtime Configuration
|
||||
- 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.
|
||||
|
||||
- **REQ-6-020 Production Persistence:** Production must run against PostgreSQL; SQLite remains supported for local development and tests.
|
||||
- **REQ-6-021 Split Worker Deployment:** Production must support running the worker as its own process with the app started at `RUN_EMBEDDED_WORKER=false`.
|
||||
- **REQ-6-022 Runtime Settings Persistence:** Runtime settings edits must persist to the mounted production environment file and survive container restart.
|
||||
- **REQ-6-023 Configuration Contract Sync:** `.env.production.example` must stay synchronized with `Settings` keys and production-safe defaults.
|
||||
- **REQ-6-024 Health Reporting:** The deployed stack must report app and worker health through `/healthz`.
|
||||
- **REQ-6-025 Backup and Restore:** Database and media/config backups must be produced on a host-visible path with a tested restore procedure.
|
||||
## Glossary
|
||||
|
||||
## Non-Functional Requirements
|
||||
|
||||
- **REQ-4-100 Boundary Integrity:** UI pages/components must not access persistence directly and must call service APIs.
|
||||
- **REQ-4-101 Service Ownership:** Aggregate writes must occur in owning service/workflow modules, not in UI handlers.
|
||||
- **REQ-4-102 Deterministic Loading:** ORM relationship reads in service/UI code must use explicit eager loading compatible with `lazy="raise"`.
|
||||
- **REQ-4-103 Async Safety:** Long-running provider calls must not block UI event handlers directly.
|
||||
- **REQ-4-104 Evidence Durability:** Attempt evidence must survive process restart once the transaction commits.
|
||||
- **REQ-4-105 Test Guardrails:** Architecture boundary tests must remain in place for services and UI boundaries.
|
||||
|
||||
## Requirement Interpretation Notes
|
||||
|
||||
### Status and lifecycle semantics
|
||||
|
||||
- `REQ-4-013` and `REQ-4-015` intentionally bind success to `transcribed`, not a generic `completed`, so docs, tests, and runtime transitions stay consistent.
|
||||
- `REQ-4-016` and `REQ-4-042` distinguish cancellation from failure at page level (`cancelled` vs `failed`) while still allowing targeted retranscription.
|
||||
|
||||
### Evidence semantics
|
||||
|
||||
- `REQ-4-020` through `REQ-4-024` separate authoritative history (`ExecutionAttempt`) from operational projection (`Source.raw_transcription`).
|
||||
- This supports immutable provenance while allowing explicit candidate promotion for operator workflows.
|
||||
|
||||
### Boundary and loading semantics
|
||||
|
||||
- `REQ-4-100` and `REQ-4-101` codify aggregate/service ownership and keep UI out of persistence concerns.
|
||||
- `REQ-4-102` exists to enforce deterministic query shape under `lazy="raise"` and avoid hidden data access in rendering callbacks.
|
||||
|
||||
## Verification Anchors
|
||||
|
||||
- Service boundary enforcement: `tests/test_service_boundaries.py`
|
||||
- UI boundary enforcement: `tests/test_ui_boundaries.py`
|
||||
- Job lifecycle reliability and terminal status behavior: `tests/services/test_workflows_reliability.py`
|
||||
- Evidence append-only and projection behavior: `tests/services/test_store.py`, `tests/services/test_transcription_service.py`
|
||||
- Person photo ownership and primary selection: `tests/services/test_photo_service.py`
|
||||
- Maintenance run lifecycle and worker execution: `tests/services/test_maintenance_service.py`
|
||||
- Runtime settings persistence: `tests/ui/test_runtime_settings_store.py`, `tests/services/test_settings_services.py`
|
||||
- Configuration contract synchronization: `tests/test_meta_contract_guards.py`
|
||||
- Deployment health reporting: `tests/api/test_health.py`
|
||||
|
||||
## Traceability Notes
|
||||
|
||||
- Source of truth for status enums:
|
||||
- `src/transcription/db/models.py`
|
||||
- Source of truth for workflow transitions:
|
||||
- `src/transcription/services/workflows.py`
|
||||
- `src/transcription/services/jobs.py`
|
||||
- Source of truth for attempt evidence writes:
|
||||
- `src/transcription/services/sources.py`
|
||||
- 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.
|
||||
|
||||
@@ -1,488 +0,0 @@
|
||||
# Architecture & Code Review Report
|
||||
|
||||
**Repository Target:** `transcription/`
|
||||
**Target Stack:** Python 3.12+ | FastAPI | NiceGUI | SQLModel/SQLAlchemy | Pydantic V2 | asyncio | OpenRouter
|
||||
|
||||
**Review date:** 2026-08-23
|
||||
**Governing procedure:** `.github/skills/python-code-reviewer/skill.md`
|
||||
**Escalations applied:** `.github/skills/evidence-provenance-auditor/skill.md`, `.github/skills/test-effectiveness-auditor/skill.md`
|
||||
**Scope:** 77 Python modules / ~13k LOC under `src/transcription`, 57 test files (377 collected non-external tests), 23 documents under `docs/`, 9 active rule files.
|
||||
|
||||
> **Status: closed.** Every finding below was remediated in the phases following this
|
||||
> review. This document is retained as a record of the reasoning, **not** as a list of
|
||||
> open work, and it is not canonical authority.
|
||||
>
|
||||
> Two recommendations were wrong on contact and were corrected during implementation:
|
||||
> the HIGH-03 fix as written would have stripped root-cause data from `ExecutionAttempt`
|
||||
> provenance, and the HIGH-01 fix needed to preserve per-page durability that the report
|
||||
> did not mention. Where this text and the current code or guard tests disagree, the code
|
||||
> and tests are correct.
|
||||
|
||||
### Verification commands and outcomes
|
||||
|
||||
| Command | Outcome |
|
||||
| :--- | :--- |
|
||||
| `uv run ruff check .` | **Pass** — `All checks passed!` |
|
||||
| `uv run pytest -q -m "not external"` | **Pass** — 377 passed |
|
||||
| `uv run ty check` | **10 diagnostics** — all SQLModel/SQLAlchemy column-descriptor false positives (`services/photos.py` ×8, `tests/test_storage_reconciliation.py` ×2). Advisory only; no suppression strategy exists. |
|
||||
|
||||
---
|
||||
|
||||
## 1. Executive Summary
|
||||
|
||||
- **Overall health is good.** The codebase has genuine architectural discipline: layered `ui → services → db`, a single Pydantic-V2 settings source, an atomic compare-and-swap job claim, append-only evidence history, and eleven deterministic guard tests that enforce structural rules rather than describing them.
|
||||
- **No Critical findings.** The highest-risk category for this domain — secret leakage into stored provenance — was explicitly audited and **passes**: request headers are never persisted, response headers use an allowlist, and the API key is `SecretStr` end-to-end.
|
||||
- **The top risk is a transaction-atomicity violation on the worker hot path.** Page evidence and terminal job status commit in two separate transactions (`workflows.py:549-598`), directly contradicting `services.instructions.md`. A crash between them leaves a transcript persisted against a job stuck in `PROCESSING`.
|
||||
- **That violation is invisible to the test suite.** The test-effectiveness audit confirms no test can fail on a split commit — the pipeline tests assert the happy-path end state, which passes either way. The invariant is documented and steered but *not enforced*.
|
||||
- **Stale-job recovery is startup-only** (`app.py:79`), with a 30-second staleness threshold. A job orphaned shortly before a fast restart is not recovered and remains `PROCESSING` indefinitely, because the worker only claims `QUEUED` rows.
|
||||
- **The mandated error-presentation boundary is bypassed at 8 sites.** `home_page.py` and `people_page.py` hand-roll `ui.notify(str(exc), ...)`, discarding the `error_id`, category, and suggestion that `error_presenter.show_error` provides. `people_page.py` imports the correct helpers and still bypasses them.
|
||||
- **User-facing output can leak filesystem paths.** `classify_unexpected_error` (`errors.py:94`) interpolates the raw exception into a message rendered in the UI; a SQLAlchemy `OperationalError` embeds the database file path. This contradicts an explicit rule in `error-handling.instructions.md`.
|
||||
- **The retry gate ignores error category** (`workflows.py:185`), so non-retriable faults would be requeued. Currently latent because `worker_max_retries` defaults to `0`.
|
||||
- **Highest-leverage work is enforcement, not refactoring.** Two atomicity tests, a `ty` suppression strategy that lets the pre-commit hook become blocking, and `ruff format --check` in the gate would convert three documented-but-unenforced invariants into deterministic ones.
|
||||
|
||||
---
|
||||
|
||||
## 2. Executive Architecture Assessment
|
||||
|
||||
**Verdict: architecturally sound with a concentrated reliability gap in the worker's commit boundary.**
|
||||
|
||||
Domain cohesion is strong. The `services/` layer owns transactions and business rules, `ui/` owns presentation, `db/` owns schema, and `providers/` isolates the OpenRouter adapter behind a `TranscriptionProvider` protocol. Dependency direction is correct and — unusually — *mechanically enforced*: `test_service_boundaries.py` AST-scans for service-to-service imports and `test_ui_boundaries.py` scans pages/components for persistence access. Provider details do not leak upward; `workflows.py` imports only the abstract `providers` types, never `openrouter`.
|
||||
|
||||
The evidence/provenance model is the strongest part of the system. `ExecutionAttempt` is genuinely append-only, retries append rather than rewrite, projection writes onto `JobSource` are clearly distinguished from history mutation, and all 14 provenance-auditor invariant checks pass.
|
||||
|
||||
**Top systemic risks:**
|
||||
|
||||
1. **Split commit boundary on the worker path (High).** Evidence durability and job terminal status are two transactions. This is the one place where the architecture's own written contract is contradicted by the implementation, on the hottest path in the system.
|
||||
2. **Recovery is a startup-only, time-thresholded sweep (Medium).** There is no runtime reconciliation, so the self-healing property depends on restart cadence rather than on a bounded interval.
|
||||
3. **Enforcement coverage has known holes (Medium).** Atomicity, error-presenter usage, and formatting are all documented rules with no deterministic test. The repo's own strength — routing invariants into tests — has not been applied to these three.
|
||||
4. **Leaky transaction ownership (Medium).** `workflows.py` reaches into `services.jobs._session_scope()` and `services.sources._session_scope()` — private members of two different services — to open transactions. Session ownership is ambiguous exactly where it most needs to be explicit.
|
||||
5. **A 10-diagnostic type-checker baseline with no suppression policy (Low).** The signal is currently ignorable, which means a real regression would blend into the noise.
|
||||
|
||||
---
|
||||
|
||||
## 3. Findings by Severity
|
||||
|
||||
### Critical Severity
|
||||
|
||||
**None identified.**
|
||||
|
||||
The secret-leakage check — the only plausible Critical for this system — passes explicitly. `OpenRouterProvider` stores an allowlisted subset of *response* headers only (`providers/evidence.py:130-134`, `SAFE_RESPONSE_HEADERS`); request headers containing `Authorization` are never captured into `TransportEvidence`; and the key is held as `SecretStr` from `config.py` through to the client. Append-only evidence history is likewise intact and test-enforced.
|
||||
|
||||
---
|
||||
|
||||
### High Severity
|
||||
|
||||
#### [HIGH-01] Page evidence and terminal job status commit in separate transactions
|
||||
|
||||
- **Location:** `src/transcription/services/workflows.py:549-565` (`_finalize_batch_outcome`), `src/transcription/services/workflows.py:584-598` (`_persist_page_outcome`)
|
||||
- **Problem & Consequence:** `.github/instructions/services.instructions.md` states: *"Never commit transcript updates separately from the paired terminal/retry job status change."* The implementation does exactly that. `_persist_page_outcome` opens its own scope and commits page evidence (line 592-594); `_finalize_batch_outcome` later opens a *second* scope and commits the terminal `JobStatus` (line 558-560). For a single-page job these are two transactions with a window between them. A process crash, container eviction, or unhandled error in that window persists the transcript while the job remains `PROCESSING`. Because the worker only claims `QUEUED` rows, that job is not reprocessed; it is recoverable only by the startup sweep, and only if it has aged past the staleness threshold (see MED-01). The user sees a job that never completes despite the transcription having succeeded and been billed.
|
||||
|
||||
This is a deliberate design tension, not an oversight: `_persist_page_outcome_durably` (line 568-581) wraps the page write in `asyncio.shield` precisely so per-page evidence survives cancellation mid-batch. That goal is correct for *multi*-page jobs. The defect is that the single-page and final-page cases inherit the split unnecessarily.
|
||||
|
||||
- **Recommendation:** Keep per-page durability for intermediate pages, but commit the final page outcome and the terminal status in one transaction.
|
||||
|
||||
```python
|
||||
# Before — two scopes, two commits
|
||||
await _persist_page_outcome_durably(job=job, services=services, page=page, session=None)
|
||||
...
|
||||
await _finalize_batch_outcome(job=job, services=services, status=status, session=None)
|
||||
|
||||
# After — final page and terminal status share one transaction
|
||||
async with services.jobs.session_scope() as tx:
|
||||
for page in intermediate_pages:
|
||||
await _persist_page_outcome_durably(job=job, services=services, page=page, session=None)
|
||||
await _write_page_outcome(job=job, services=services, page=final_page, session=tx)
|
||||
await services.jobs.mark_job_status(job.id, status, session=tx)
|
||||
await tx.commit()
|
||||
```
|
||||
|
||||
Pair this with the atomicity test in HIGH-04 so the boundary cannot silently regress.
|
||||
- **Effort:** M
|
||||
|
||||
---
|
||||
|
||||
#### [HIGH-02] Mandated error-presentation boundary bypassed at 8 sites
|
||||
|
||||
- **Location:** `src/transcription/ui/pages/home_page.py:212,220,228,255`; `src/transcription/ui/pages/people_page.py:265,321,330,339`
|
||||
- **Problem & Consequence:** `.github/instructions/ui.instructions.md:42` requires all user-facing error display to route through `components/error_presenter.py`. Seven of nine pages comply. These two hand-roll `ui.notify(str(exc), type="negative")`. The consequence is not cosmetic: `show_error` (`error_presenter.py:52-67`) surfaces the correlation `error_id`, the canonical error category, and the actionable `suggestion` field. Bypassing it means a user hitting a failure on the home or people page gets a bare exception string with **no error reference to report**, making these two pages unsupportable in production — precisely the pages most likely to be a user's entry point.
|
||||
|
||||
`people_page.py` already imports `run_ui_action` and `show_error` at lines 28-29 and uses them elsewhere in the same module, so the bypass is inconsistency rather than missing infrastructure.
|
||||
- **Recommendation:** Replace each site with the canonical helper. The unused `summarize_error` helper in `error_presenter.py` (currently a retained orphan — see LOW-07) is the natural fit where a compact string is genuinely needed.
|
||||
|
||||
```python
|
||||
# Before
|
||||
except AppError as exc:
|
||||
ui.notify(str(exc), type="negative")
|
||||
|
||||
# After
|
||||
except AppError as exc:
|
||||
show_error(exc)
|
||||
```
|
||||
|
||||
Then close the hole permanently by extending `tests/test_ui_boundaries.py` with an AST check that no module under `PAGES_DIR` calls `ui.notify(...)` with `type="negative"`.
|
||||
- **Effort:** S
|
||||
|
||||
---
|
||||
|
||||
#### [HIGH-03] Unexpected-error path leaks filesystem paths into user-facing output
|
||||
|
||||
- **Location:** `src/transcription/errors.py:91-98` (line 94), rendered via `src/transcription/ui/components/error_presenter.py:52-67`
|
||||
- **Problem & Consequence:** `classify_unexpected_error` builds `f"Unexpected error during {operation}: {exc}"` and stores it as `AppError.message`. `show_error` renders `error.message` directly to the user. Any exception whose `str()` contains infrastructure detail is therefore displayed verbatim — a SQLAlchemy `OperationalError` embeds the absolute SQLite database path, and an `OSError` from the media layer embeds the storage root. `.github/instructions/error-handling.instructions.md:74` states: *"Never leak … local filesystem paths in user-facing output."* This is the generic catch-all path, so it applies to every unanticipated failure across the application.
|
||||
- **Recommendation:** Split the diagnostic detail from the user-facing message. Log the full exception with the `error_id` as the correlation key; show the user a stable message plus that id.
|
||||
|
||||
```python
|
||||
# Before
|
||||
return AppError(
|
||||
f"Unexpected error during {operation}: {exc}",
|
||||
category=ErrorCategory.INTERNAL_UNEXPECTED,
|
||||
...
|
||||
)
|
||||
|
||||
# After
|
||||
error = AppError(
|
||||
f"Unexpected error during {operation}.",
|
||||
category=ErrorCategory.INTERNAL_UNEXPECTED,
|
||||
suggestion="Retry once. If it persists, report the error reference id.",
|
||||
retriable=False,
|
||||
)
|
||||
logger.exception("error_id=%s operation=%s", error.error_id, operation)
|
||||
return error
|
||||
```
|
||||
|
||||
Add a case to `tests/ui/test_error_presenter.py` asserting that a raised `OperationalError` carrying a path does not surface that path in the rendered message.
|
||||
- **Effort:** S
|
||||
|
||||
---
|
||||
|
||||
#### [HIGH-04] Transaction-atomicity invariants have no enforcing test
|
||||
|
||||
- **Location:** Contract at `.github/instructions/services.instructions.md` §"Workflow Transaction Boundaries"; gap confirmed across `tests/integration/test_pipeline_flow.py:66-160` and `tests/services/test_job_service.py:41-59`
|
||||
- **Problem & Consequence:** The test-effectiveness audit establishes that **neither** Transaction B (transcript + `TRANSCRIBED`) nor Transaction C (retry: `error_detail` + `retry_count` + `QUEUED`) is enforced. The existing pipeline test asserts the final state after a successful run — which passes identically whether the writes shared one commit or used two. To fail on a split-commit regression a test must inject a fault *between* the writes; no such test exists.
|
||||
|
||||
The consequence is that HIGH-01 shipped undetected and any future refactor of `advance_job` can reintroduce it just as silently. This is a *governance* failure rather than a code defect: the repo's stated model is that hard rules belong in deterministic tests, and this rule is the most consequential one that never made the transition.
|
||||
- **Recommendation:** Add `tests/integration/test_pipeline_atomicity.py` with two tests that patch the session to raise after `flush()` but before `commit()`, then assert that *neither* side of the pair is visible in a fresh session. These tests should **fail against the current implementation** and pass once HIGH-01 is fixed — write them first.
|
||||
- **Effort:** M
|
||||
|
||||
---
|
||||
|
||||
### Medium Severity
|
||||
|
||||
#### [MED-01] Stale-job recovery runs only at startup, behind a 30-second threshold
|
||||
|
||||
- **Location:** `src/transcription/app.py:71-81` (`_recover_stale_processing_jobs`), sole caller at `app.py:79` inside `_lifespan`
|
||||
- **Problem & Consequence:** `requeue_stale_processing_jobs` has exactly one call site, in the lifespan startup handler. There is no runtime re-check. The staleness predicate is `updated_at < now - worker_provider_timeout_seconds` (default **30.0s**, `config.py:116`). A job orphaned less than 30 seconds before a fast container restart therefore fails the predicate at the only moment recovery is attempted, and stays `PROCESSING` forever — the worker claims only `QUEUED` rows. It self-heals only on some *later, unrelated* restart. In a frequently-redeployed environment, restarts are exactly when orphans are created, so the recovery window is systematically misaligned with the failure it exists to handle.
|
||||
- **Recommendation:** Move the sweep onto a periodic task in the worker loop (e.g. every `max(30, provider_timeout * 2)` seconds) in addition to the startup call, and derive the threshold from a dedicated `worker_stale_job_seconds` setting rather than reusing the provider timeout, so the two can be tuned independently.
|
||||
- **Effort:** M
|
||||
|
||||
---
|
||||
|
||||
#### [MED-02] Retry gate ignores `error_category`, so non-retriable failures would be requeued
|
||||
|
||||
- **Location:** `src/transcription/services/workflows.py:184-194`
|
||||
- **Problem & Consequence:** The `JobStatus.FAILED` branch gates solely on `job.retry_count < settings.worker_max_retries`. It does not consult `error_category` or the `AppError.retriable` flag. `.github/instructions/error-handling.instructions.md` classifies `validation`, `not_found`, and `conflict` as non-retriable; under this gate a malformed source or a missing record would be retried to exhaustion, consuming provider quota on calls that cannot succeed and delaying the terminal failure the user needs to see. There is also no backoff — retries requeue immediately.
|
||||
|
||||
Currently **latent**: `worker_max_retries` defaults to `0` (`config.py:113`) and is commented out in `.env`, so the branch always falls through to the max-retries log. It becomes live the moment anyone enables retries.
|
||||
- **Recommendation:** Gate on retriability *and* count, and add exponential backoff before requeue.
|
||||
|
||||
```python
|
||||
case JobStatus.FAILED:
|
||||
if job.error_category in NON_RETRIABLE_CATEGORIES:
|
||||
logger.error("Job %s failed non-retriably (%s).", job.id, job.error_category)
|
||||
return
|
||||
if job.retry_count < settings.worker_max_retries:
|
||||
...
|
||||
```
|
||||
|
||||
Cover with a test that a `validation`-category failure is not requeued even when `worker_max_retries > 0`.
|
||||
- **Effort:** S
|
||||
|
||||
---
|
||||
|
||||
#### [MED-03] `IntegrityError` on the attempt-number flush is uncaught, risking evidence loss
|
||||
|
||||
- **Location:** `src/transcription/services/sources.py:540-546` (attempt-number computation), `sources.py:587` (unguarded `flush()`)
|
||||
- **Problem & Consequence:** `attempt_number` is derived read-then-write as `MAX(attempt_number) + 1`, and `uq_execution_attempt_number` enforces uniqueness (`db/models.py:507`, documented at `docs/schema.md:273`). The sibling `JobSource` insert *does* catch `IntegrityError` (`sources.py:531-534`), but the `ExecutionAttempt` flush at line 587 does not. Two concurrent attempt writes for the same job source would raise an unhandled `IntegrityError` and lose an evidence row — the one class of data this system exists to preserve. Not currently reachable: the worker is single-instance and processes sources sequentially. It becomes reachable the moment a second worker replica is deployed.
|
||||
- **Recommendation:** Mirror the `JobSource` handling — catch `IntegrityError`, recompute `MAX(attempt_number) + 1`, and retry the insert a bounded number of times, raising a domain error on exhaustion. Note this constraint as a horizontal-scaling precondition in `docs/production-runbook.md`.
|
||||
- **Effort:** M
|
||||
|
||||
---
|
||||
|
||||
#### [MED-04] Shutdown timeout is shorter than the provider timeout
|
||||
|
||||
- **Location:** `src/transcription/worker.py:146` (`asyncio.wait_for(worker_task, timeout=2.0)`); provider timeout at `config.py:116` (default 30.0s)
|
||||
- **Problem & Consequence:** Graceful shutdown waits 2 seconds for the worker task, but the stop event is only checked *between* jobs and an in-flight provider call may run for up to 30 seconds. Any shutdown during a provider call therefore cancels mid-flight. Combined with HIGH-01's split commit, a cancellation that lands between the evidence commit and the status commit produces exactly the stuck-`PROCESSING` state described there — so this finding materially raises HIGH-01's probability rather than being independent of it.
|
||||
- **Recommendation:** Derive the shutdown budget from the provider timeout (`worker_provider_timeout_seconds + small_grace`) instead of hardcoding `2.0`, and ensure the container's termination grace period exceeds it. Document both in `docs/production-runbook.md`.
|
||||
- **Effort:** S
|
||||
|
||||
---
|
||||
|
||||
#### [MED-05] `workflows.py` reaches into two services' private `_session_scope`
|
||||
|
||||
- **Location:** `src/transcription/services/workflows.py:558` (`services.jobs._session_scope()`), `workflows.py:592` (`services.sources._session_scope()`)
|
||||
- **Problem & Consequence:** The orchestration module opens transactions by calling a private member on two different service objects. This is the concrete mechanism behind HIGH-01: because transaction ownership is expressed through a private back-door rather than a declared boundary, nothing in the design makes it obvious that two scopes are being opened for one logical unit of work. It also couples `workflows.py` to a service implementation detail that `test_service_boundaries.py` cannot see (it checks imports, not attribute access).
|
||||
- **Recommendation:** Promote a single explicit transaction entry point — a `session_scope()` on `ServiceBundle`, or a module-level `unit_of_work(services)` helper — and make `workflows.py` use only that. Extend `test_service_boundaries.py` with an AST check forbidding `_session_scope` attribute access outside the owning service module.
|
||||
- **Effort:** M
|
||||
|
||||
---
|
||||
|
||||
### Low Severity
|
||||
|
||||
#### [LOW-01] `hashlib.sha256` over full file bytes runs on the event loop
|
||||
- **Location:** `src/transcription/services/store.py:401`
|
||||
- **Problem & Consequence:** Digest computation is CPU-bound and synchronous inside an `async def`. For large uploads this blocks the loop, stalling both the NiceGUI UI and the worker. Every sibling I/O path in the codebase correctly uses `asyncio.to_thread` (`media_storage.py:43`, `normalization.py:117`, `photos.py:176`, `sources.py:740,753`), so this is an isolated deviation.
|
||||
- **Recommendation:** `digest = await asyncio.to_thread(lambda: hashlib.sha256(file_bytes).hexdigest())`.
|
||||
- **Effort:** S
|
||||
|
||||
#### [LOW-02] `homepage_store.py` performs synchronous file I/O from async callers
|
||||
- **Location:** `src/transcription/ui/homepage_store.py:25,32`; called from `src/transcription/ui/pages/home_page.py:170`
|
||||
- **Problem & Consequence:** Same class as LOW-01 — reads/writes the homepage JSON directly rather than via `asyncio.to_thread`. Impact is small (a tiny file), but it is a second deviation from an otherwise universal convention.
|
||||
- **Recommendation:** Wrap both calls in `asyncio.to_thread`.
|
||||
- **Effort:** S
|
||||
|
||||
#### [LOW-03] Worker poll interval is hardcoded outside `Settings`
|
||||
- **Location:** `src/transcription/app.py:62` (`poll_interval_seconds=1.0`)
|
||||
- **Problem & Consequence:** The single operational knob controlling worker latency-vs-load cannot be tuned without a code change, contradicting the otherwise-clean rule that all configuration lives in `config.py` (zero `os.getenv` calls exist outside it).
|
||||
- **Recommendation:** Add `worker_poll_interval_seconds: float = 1.0` to `Settings` and read it at the call site.
|
||||
- **Effort:** S
|
||||
|
||||
#### [LOW-04] `_build_request_manifest` returns `None` silently, producing incomplete evidence
|
||||
- **Location:** `src/transcription/providers/openrouter.py:347`
|
||||
- **Problem & Consequence:** When `source_reference is None` the manifest is skipped with no log line. The attempt is still recorded but its provenance is quietly incomplete, and there is no signal that it happened — the failure mode is undetectable after the fact.
|
||||
- **Recommendation:** Log at `warning` with the job/source identifiers before returning `None`, so incomplete provenance is at least attributable.
|
||||
- **Effort:** S
|
||||
|
||||
#### [LOW-05] Ten `ty` diagnostics with no suppression strategy
|
||||
- **Location:** `src/transcription/services/photos.py` (8), `tests/test_storage_reconciliation.py` (2)
|
||||
- **Problem & Consequence:** All ten are SQLModel/SQLAlchemy false positives — column descriptors are typed as their Python value type (`UUID`, `datetime`, `bool`), so `.is_()`, `.asc()`, `func.count()`, and `group_by()` appear invalid. Because there is no suppression policy, the pre-commit hook must run `ty` in advisory mode, which means a *genuine* new type error would print alongside the known ten and block nothing.
|
||||
- **Recommendation:** Add targeted `# ty: ignore[...]` comments with a one-line rationale at each of the ten sites, then flip the pre-commit hook to blocking. This converts a permanently-ignored signal into a real gate.
|
||||
- **Effort:** M
|
||||
|
||||
#### [LOW-06] `ruff format` is not enforced; 35 files have drifted
|
||||
- **Location:** `.pre-commit-config.yaml`, `ruff.toml`
|
||||
- **Problem & Consequence:** `ruff check` is blocking but `ruff format --check` is absent from the gate, so formatting drift accumulates silently and inflates unrelated diffs whenever anyone does run the formatter.
|
||||
- **Recommendation:** Run `uv run ruff format .` once as a single isolated commit, then add `ruff format --check` to the pre-commit gate.
|
||||
- **Effort:** S
|
||||
|
||||
#### [LOW-07] Four retained orphans, all recorded as "uncertain — follow-up"
|
||||
- **Location:** `tests/test_orphan_sweep.py:33-52` (`KNOWN_ORPHANS`): `BenchmarkManifest`, `dispose_all_engines`, `refresh_engine`, `summarize_error`
|
||||
- **Problem & Consequence:** Every entry carries the weakest possible justification. `summarize_error` is the notable one: it is an unused helper in `error_presenter.py` *while two pages hand-roll error display* (HIGH-02) — the orphan and the boundary violation are the same problem viewed from two directions. `dispose_all_engines` / `refresh_engine` are plausibly test-support utilities and should be classified as such rather than left uncertain.
|
||||
- **Recommendation:** Resolve each to a definite outcome — `summarize_error` becomes used by the HIGH-02 fix; classify the engine helpers as test-support or delete them; decide on `BenchmarkManifest`.
|
||||
- **Effort:** S
|
||||
|
||||
#### [LOW-08] Orphan sweep only scans module-level public definitions
|
||||
- **Location:** `tests/test_orphan_sweep.py`
|
||||
- **Problem & Consequence:** Methods and private functions are out of scope, so dead code inside classes — the most common kind in a service-oriented codebase — is structurally invisible to the sweep.
|
||||
- **Recommendation:** Extend the AST walk to public methods on service classes, seeding `KNOWN_ORPHANS` with the current result set to keep the change non-breaking.
|
||||
- **Effort:** M
|
||||
|
||||
#### [LOW-09] f-string interpolation in logging calls
|
||||
- **Location:** `src/transcription/services/workflows.py:193` and similar sites
|
||||
- **Problem & Consequence:** `logger.error(f"Job {job.id} has failed...")` formats eagerly regardless of level and prevents structured-logging backends from grouping by template. Ruff's `flake8-logging-format` (`G`) rules are not enabled, so this is unenforced.
|
||||
- **Recommendation:** Use `logger.error("Job %s has failed and reached max retries.", job.id)` and enable ruff rule set `G`.
|
||||
- **Effort:** S
|
||||
|
||||
#### [LOW-10] Low-signal and always-true assertions in the test suite
|
||||
- **Location:** `tests/test_traceability.py:54-57`; `tests/integration/test_pipeline_flow.py:135-140,446-452`; `tests/test_orphan_sweep.py:119`; `tests/services/test_workflows_reliability.py:105,178,241,317,375`
|
||||
- **Problem & Consequence:** Per the test-effectiveness audit: `test_traceability.py:54-57` asserts properties of dict literals defined in the same file (can only fail if the test itself is edited); `assert processed is True` in the pipeline tests is unfalsifiable because `read_job` raises rather than returning `None`; the `>= 200` orphan threshold is a historical snapshot that tolerates ±40 drift; and the `assert result is not None` guards are shadowed by the attribute assertions that follow. Together these overstate effective coverage.
|
||||
- **Recommendation:** Apply the prune/strengthen backlog in §6 (Testing).
|
||||
- **Effort:** S
|
||||
|
||||
#### [LOW-11] Wall-clock timing dependencies risk CI flakiness
|
||||
- **Location:** `tests/services/test_workflows_reliability.py:157-196` (real `time.sleep(0.40)`, upper bound `< 540ms` with only 10% slack); `test_workflows_reliability.py:341` (`asyncio.wait_for(..., timeout=2)`)
|
||||
- **Problem & Consequence:** On a loaded CI runner, a 200ms asyncio task plus 400ms blocking setup can exceed the 540ms bound, producing false failures that erode trust in the suite.
|
||||
- **Recommendation:** Widen the slack factor to `0.8` or replace the blocking sleep with a controlled clock mock.
|
||||
- **Effort:** S
|
||||
|
||||
---
|
||||
|
||||
## 4. Architectural Drift & Gap Analysis
|
||||
|
||||
`Direction` is `doc->code` (implementation must change to match documented intent) or `code->doc` (an undocumented but repeatable convention that should be formalized).
|
||||
|
||||
| Area / Component | Direction | Documented / Intended Rule | Actual Implementation State | Severity | Recommended Resolution |
|
||||
| :--- | :--- | :--- | :--- | :--- | :--- |
|
||||
| Worker commit boundary | `doc->code` | `services.instructions.md`: never commit transcript updates separately from the paired terminal status change | `workflows.py:549-598` commits page evidence and terminal status in two separate sessions | High | Fix per HIGH-01; enforce per HIGH-04 |
|
||||
| UI error presentation | `doc->code` | `ui.instructions.md:42`: all user-facing error display routes through `error_presenter.py` | 8 hand-rolled `ui.notify` sites in `home_page.py` and `people_page.py` | High | Fix per HIGH-02; add AST guard to `test_ui_boundaries.py` |
|
||||
| Unexpected-error messaging | `doc->code` | `error-handling.instructions.md:74`: never leak local filesystem paths in user-facing output | `errors.py:94` interpolates raw `exc` into the rendered message | High | Fix per HIGH-03 |
|
||||
| Retry policy | `doc->code` | `error-handling.instructions.md`: validation / not_found / conflict are non-retriable | `workflows.py:185` gates on retry count only | Medium | Fix per MED-02 |
|
||||
| Stale-job recovery | `code->doc` | Not documented as startup-only or time-thresholded | Single startup call site; 30s threshold reuses the provider timeout | Medium | Fix per MED-01, then document the recovery contract in `docs/production-runbook.md` |
|
||||
| Transaction ownership | `code->doc` | `services.instructions.md` assigns transaction ownership to services | `workflows.py` opens scopes via two services' private `_session_scope` | Medium | Fix per MED-05; document the single unit-of-work entry point |
|
||||
| Blocking-I/O convention | `code->doc` | Not stated as a rule; followed at 5 of 7 sites | `store.py:401` and `homepage_store.py:25,32` deviate | Low | Fix per LOW-01/LOW-02, then state the `asyncio.to_thread` rule in `services.instructions.md` |
|
||||
| Configuration centralization | `code->doc` | Zero `os.getenv` outside `config.py` — a real, held convention | Held everywhere except the hardcoded `poll_interval_seconds` at `app.py:62` | Low | Fix per LOW-03, then formalize the rule and add a deterministic guard |
|
||||
| Type-check baseline | `code->doc` | No documented policy for `ty` diagnostics | 10 tolerated false positives; hook is advisory-only | Low | Adopt the suppression strategy in LOW-05 and document it |
|
||||
| Formatting | `code->doc` | `ruff.toml` configures the formatter | `ruff format --check` absent from the gate; 35 files drifted | Low | Fix per LOW-06 |
|
||||
| Dependency pin | — | `docs/production-runbook.md` "Dependency upgrade policy" records the exact `nicegui==3.13.0` pin as a deliberate stability decision | Matches | — | **No action** — correctly documented, not a defect |
|
||||
|
||||
---
|
||||
|
||||
## 5. Invariant Inventory & Routing Recommendations
|
||||
|
||||
| Invariant / Constraint | Current Location | Recommended Target Layer | Rationale |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| Transcript + terminal status commit atomically | Instructions only | **Deterministic test** (`tests/integration/test_pipeline_atomicity.py`) | Highest-consequence rule in the system with zero enforcement; steering alone already failed to prevent HIGH-01 |
|
||||
| Retry writes commit atomically | Instructions only | **Deterministic test** (same file) | Same class; a partial retry commit corrupts `retry_count` accounting |
|
||||
| All UI errors route through `error_presenter` | Instructions (`ui.instructions.md:42`) | **Deterministic test** (extend `test_ui_boundaries.py`) | Mechanically checkable via AST; 8 live violations prove instructions are insufficient here |
|
||||
| No filesystem paths in user-facing output | Instructions (`error-handling.instructions.md:74`) | **Deterministic test** (extend `tests/ui/test_error_presenter.py`) | Checkable by asserting a path-bearing exception does not surface its path |
|
||||
| Non-retriable categories are never requeued | Instructions | **Deterministic test** (`tests/services/test_workflows_reliability.py`) | Latent today; a test freezes the correct behavior before retries are enabled |
|
||||
| Blocking I/O runs via `asyncio.to_thread` | Convention only (5/7 sites) | **Instructions** (`services.instructions.md`) | Judgment-dependent (thresholds vary by payload size); steering fits better than a hard test |
|
||||
| Transaction opened through one owned entry point | Convention, violated | **Instructions + test** | Document the entry point; AST-guard against `_session_scope` access outside its owning module |
|
||||
| Append-only `ExecutionAttempt` history | Docs + 3 tests | **Keep as-is** | Correctly routed and genuinely mutation-sensitive; the model to imitate |
|
||||
| Service/UI boundary rules | Instructions + 2 AST tests | **Keep as-is** | Working exactly as intended |
|
||||
| Status vocabulary conformance | `docs/schema.md` + contract guards | **Keep as-is** | Enum drift would fail the suite |
|
||||
| No secrets in stored evidence | Docs + provenance skill + allowlist in code | **Keep as-is** | Allowlist is the right mechanism — fails closed by construction |
|
||||
| `ty` diagnostic suppression policy | Nonexistent | **Docs + blocking hook** | Needs a written rationale per suppression before the gate can be trusted |
|
||||
| NiceGUI exact pin | `docs/production-runbook.md` | **Keep as-is** | Deliberate, documented, correctly excluded from review findings |
|
||||
|
||||
---
|
||||
|
||||
## 6. Stack-Specific Analysis
|
||||
|
||||
### Python 3.12+ Best Practices
|
||||
Modern syntax is used consistently: `X | None` unions throughout, builtin generics, no `typing.List`/`Optional` legacy forms, `pathlib` over `os.path`. Type-annotation coverage is high, with no bare `Any` on public service signatures. Broad `except Exception` appears where it belongs — the per-page handler at `workflows.py:352` deliberately isolates one page's failure from the batch, which is correct. `# noqa: PLR0915` / `PLR1702` are used sparingly and consistently. Minor gaps: f-strings in logging (LOW-09), and two blocking-I/O deviations (LOW-01/LOW-02).
|
||||
|
||||
### FastAPI
|
||||
Lifespan is handled correctly via an `asynccontextmanager` `_lifespan` (`app.py:36-68`) rather than deprecated `@app.on_event`. Routers are domain-organized with typed path/query parameters and `response_model` declarations. Error handling is centralized through `register_error_handlers`, and the full internal→canonical category mapping is round-trip tested at the HTTP layer (`tests/api/test_error_responses.py:59-95`). `print_api.py:42-49` performs correct `relative_to`-based path containment for media serving. No blocking calls found in `async def` route handlers.
|
||||
|
||||
### NiceGUI
|
||||
Separation of concerns is good — pages delegate to services and `test_ui_boundaries.py` mechanically prevents persistence access from pages and components. Client state is client-scoped; no cross-session global-state leaks found. API usage is correct for the pinned 3.13.0 release. The two defects are the error-presenter bypass (HIGH-02) and synchronous file I/O in `homepage_store.py` (LOW-02).
|
||||
|
||||
### SQLModel & SQLAlchemy
|
||||
The strongest layer. `lazy="raise"` is declared on relationships and correctly paired with `expire_on_commit=False`, which together make N+1 access a loud failure rather than a silent performance cost — no N+1 patterns found. The job claim is a genuine atomic compare-and-swap (`jobs.py:212-222`: conditional `UPDATE ... WHERE status = QUEUED ... RETURNING`), which is the correct primitive and correctly implemented. Hot-path indexes are declared and test-verified (`test_db.py:131`). Cross-dialect portability is handled for SQLite and PostgreSQL. Weaknesses are transaction *ownership* (MED-05, HIGH-01) rather than query construction, plus the uncaught `IntegrityError` at MED-03.
|
||||
|
||||
### Pydantic V2 & Settings
|
||||
Fully migrated — no `@validator`, no `Config` class, no `.dict()` or `parse_obj` anywhere. `model_config = ConfigDict(...)` and `@field_validator` are used correctly. `config.py` is a clean single source of truth: **zero** `os.getenv` calls exist outside it, `.env` is untracked and gitignored, and the API key is `SecretStr` end-to-end. The only deviation is the hardcoded poll interval (LOW-03).
|
||||
|
||||
### Asyncio Workers
|
||||
Task lifecycle is handled properly: task references are retained (no GC risk), `CancelledError` is re-raised rather than swallowed, the provider call happens outside any DB transaction, timeouts resolve to terminal states, and there is no tight polling spin. `_persist_page_outcome_durably`'s use of `asyncio.shield` (`workflows.py:568-581`) is a thoughtful durability mechanism. The defects are the split commit boundary (HIGH-01), the shutdown-vs-provider timeout mismatch (MED-04), and startup-only recovery (MED-01).
|
||||
|
||||
### OpenRouter / Adapter Boundary
|
||||
Encapsulation is clean — `workflows.py` imports only abstract types from `providers`, never `openrouter` directly, so provider specifics do not leak into business logic. The `AsyncClient` is shared with configured timeouts and is properly closed: `worker.py:248,271` → `services.aclose()` → `sources.aclose()` (`sources.py:129-133`) → provider `aclose()` (`openrouter.py:86-87,233-235`). Responses are Pydantic-validated. **All 14 evidence-provenance-auditor invariant checks pass**, including the critical one: the API key is never persisted, request headers are never stored, and `TransportEvidence` captures response headers through an explicit allowlist (`evidence.py:130-134`). Only LOW-04 applies here.
|
||||
|
||||
### Testing & Quality Tooling
|
||||
377 tests pass with `-m "not external"`. The project test contract is honored: `--strict-markers` with all three markers (`unit`, `integration`, `external`) declared, `asyncio_mode = "strict"` with **every** `async def test_` correctly decorated across all 17 async test files, `external` properly excluded from default runs, and **no unawaited-coroutine warnings** — the `filterwarnings` error promotion is clean.
|
||||
|
||||
Contract coverage is genuinely strong for structural rules. Confirmed *mutation-sensitive* enforcement exists for: append-only evidence history (3 independent tests, including full before/after field-tuple snapshots), stuck-in-`PROCESSING` prevention, the complete 10-category error mapping, and both boundary rules.
|
||||
|
||||
The critical gap is transaction atomicity (HIGH-04) — the audit verdict is **"Effective with Conditions / Go with Conditions"**, blocking on the two missing atomicity tests. Secondary items are the low-signal assertions (LOW-10) and wall-clock flakiness (LOW-11).
|
||||
|
||||
**Prune/strengthen backlog:**
|
||||
|
||||
| Priority | Task | Location |
|
||||
| :--- | :--- | :--- |
|
||||
| High | Add Transaction B atomicity test (fault injected between transcript and status writes) | new `tests/integration/test_pipeline_atomicity.py` |
|
||||
| High | Add Transaction C atomicity test (retry: `error_detail` + `retry_count` + `QUEUED`) | same file |
|
||||
| Medium | Delete tautological assertions on same-file dict literals | `tests/test_traceability.py:54-57` |
|
||||
| Medium | Remove unfalsifiable `assert processed is True` | `tests/integration/test_pipeline_flow.py:135-140,446-452` |
|
||||
| Medium | Replace `>= 200` snapshot threshold with set-membership assertion | `tests/test_orphan_sweep.py:119` |
|
||||
| Medium | Assert mapped test files contain ≥1 test, not merely that they exist | `tests/test_traceability.py:59-60` |
|
||||
| Low | Widen timing slack or mock the clock | `tests/services/test_workflows_reliability.py:157-196` |
|
||||
| Low | Drop `assert result is not None` guards shadowed by following assertions | `tests/services/test_workflows_reliability.py:105,178,241,317,375` |
|
||||
|
||||
---
|
||||
|
||||
## 7. Duplication & Consolidation Report
|
||||
|
||||
| Pattern / Duplication | Locations | Proposed Canonical Home | Estimated Lines Removed |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| Hand-rolled `ui.notify(str(exc), type="negative")` | `home_page.py:212,220,228,255`; `people_page.py:265,321,330,339` | `ui/components/error_presenter.py::show_error` (already exists) | ~16 |
|
||||
| Optional-session `if session is None: async with _session_scope()` preamble | `workflows.py:557-561`, `workflows.py:591-595`, and sibling service write paths | `services/base.py::unit_of_work(services, session)` context manager | ~30 |
|
||||
| Synchronous I/O not wrapped in `asyncio.to_thread` | `store.py:401`, `homepage_store.py:25,32` | `services/base.py::run_blocking` helper | ~6 |
|
||||
| Read-then-increment `MAX(n) + 1` with uniqueness retry | `sources.py:540-546` (uncaught) vs `sources.py:531-534` (caught) | `services/base.py::insert_with_sequence_retry` | ~20 |
|
||||
|
||||
### Proposed Canonical Abstractions
|
||||
|
||||
```python
|
||||
# src/transcription/services/base.py
|
||||
|
||||
|
||||
@asynccontextmanager
|
||||
async def unit_of_work(
|
||||
services: ServiceBundle,
|
||||
session: AsyncSession | None = None,
|
||||
) -> AsyncIterator[AsyncSession]:
|
||||
"""Single transaction entry point. Yields a session and commits once on clean exit.
|
||||
|
||||
Replaces the `if session is None: async with X._session_scope()` preamble and the
|
||||
private-member access at workflows.py:558,592. Makes the two-commit split of
|
||||
HIGH-01 structurally hard to reintroduce.
|
||||
"""
|
||||
|
||||
|
||||
async def run_blocking[T](fn: Callable[[], T]) -> T:
|
||||
"""Run a CPU- or disk-bound callable off the event loop."""
|
||||
return await asyncio.to_thread(fn)
|
||||
|
||||
|
||||
async def insert_with_sequence_retry(
|
||||
session: AsyncSession,
|
||||
*,
|
||||
build: Callable[[int], SQLModel],
|
||||
next_value: Callable[[], Awaitable[int]],
|
||||
attempts: int = 3,
|
||||
) -> SQLModel:
|
||||
"""Insert a row carrying a derived sequence number, retrying on IntegrityError."""
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. Meta-Tooling & Instruction Update Recommendations
|
||||
|
||||
1. **Add `tests/integration/test_pipeline_atomicity.py`** (HIGH-04). The single highest-value enforcement change. Write it before fixing HIGH-01 so it demonstrably fails first.
|
||||
2. **Extend `tests/test_ui_boundaries.py`** with an AST check forbidding `ui.notify(..., type="negative")` in `PAGES_DIR`, routing all error display through `error_presenter`. Converts `ui.instructions.md:42` from steering into enforcement.
|
||||
3. **Extend `tests/ui/test_error_presenter.py`** with a case asserting that a path-bearing exception does not surface its path, enforcing `error-handling.instructions.md:74`.
|
||||
4. **Adopt a `ty` suppression policy** — targeted `# ty: ignore[...]` with rationale at the 10 known sites, documented in `docs/` — then **flip the pre-commit `ty` hook from advisory to blocking**. Until this happens the type checker provides no gate.
|
||||
5. **Add `ruff format --check` to the pre-commit gate**, preceded by one isolated formatting commit across the 35 drifted files.
|
||||
6. **Enable ruff rule set `G`** (`flake8-logging-format`) to catch f-string logging (LOW-09).
|
||||
7. **Extend `tests/test_orphan_sweep.py`** to public methods on service classes, seeding `KNOWN_ORPHANS` with current results (LOW-08). Then resolve all four existing "uncertain" entries to definite outcomes.
|
||||
8. **Extend `tests/test_service_boundaries.py`** with an AST check forbidding `_session_scope` attribute access outside its owning service module (MED-05). Also address the noted classification gap: the test excludes orchestration modules by hardcoded stem name (`store`, `workflows`, `__init__`), so a new orchestration module under a different name would be misclassified as a service.
|
||||
9. **Update `.github/instructions/services.instructions.md`** to state the `asyncio.to_thread` rule for blocking I/O and to name the single `unit_of_work` transaction entry point.
|
||||
10. **Update `docs/production-runbook.md`** with the stale-job recovery contract (interval, threshold, and its relationship to the container termination grace period), and note single-worker as a current precondition until MED-03 is fixed.
|
||||
11. **Note for `test_ui_boundaries.py`:** the forbidden-import lists are fixed string sets, so a future persistence helper under a new name would escape the check. Consider inverting to an allowlist of permitted imports for pages.
|
||||
|
||||
---
|
||||
|
||||
## 9. Prioritized Dependency-Ordered Action Plan
|
||||
|
||||
**Phase 1: Blocking fixes**
|
||||
1. Write the two atomicity tests (HIGH-04) and confirm they **fail** against current `main`.
|
||||
2. Fix the split commit boundary (HIGH-01) and confirm the tests now pass.
|
||||
3. Fix the filesystem-path leak in `classify_unexpected_error` (HIGH-03).
|
||||
4. Replace the 8 hand-rolled error notifications with `show_error` (HIGH-02).
|
||||
|
||||
**Phase 2: Enforcement hardening**
|
||||
5. Add the `ui.notify` AST guard and the path-leak presenter test, locking in items 3-4.
|
||||
6. Adopt the `ty` suppression policy and make the pre-commit hook blocking (LOW-05).
|
||||
7. Run `ruff format .` as an isolated commit, then add `ruff format --check` to the gate (LOW-06).
|
||||
8. Enable ruff rule set `G` and fix the resulting logging call sites (LOW-09).
|
||||
|
||||
**Phase 3: Reliability & concurrency**
|
||||
9. Move stale-job recovery to a periodic worker task with a dedicated setting (MED-01).
|
||||
10. Gate retries on `error_category` and add backoff (MED-02) — do this before ever raising `worker_max_retries` above 0.
|
||||
11. Derive the shutdown budget from the provider timeout (MED-04).
|
||||
12. Handle `IntegrityError` on the attempt-number flush (MED-03) — a hard precondition for running more than one worker replica.
|
||||
13. Move `sha256` and homepage-store I/O off the event loop (LOW-01, LOW-02); move the poll interval into `Settings` (LOW-03).
|
||||
|
||||
**Phase 4: Consolidation & refactoring**
|
||||
14. Introduce `unit_of_work` and migrate `workflows.py` off private `_session_scope` access (MED-05); add the corresponding boundary guard.
|
||||
15. Extract `run_blocking` and `insert_with_sequence_retry` (§7).
|
||||
16. Prune the low-signal assertions and reduce timing flakiness (LOW-10, LOW-11).
|
||||
|
||||
**Phase 5: Non-blocking governance/documentation depth**
|
||||
17. Extend the orphan sweep to methods and resolve the four uncertain orphans (LOW-07, LOW-08).
|
||||
18. Update `services.instructions.md` and `docs/production-runbook.md` per §8 items 9-10.
|
||||
19. Log incomplete request manifests (LOW-04).
|
||||
20. Consider inverting the UI boundary check to an allowlist.
|
||||
|
||||
---
|
||||
|
||||
## 10. Preserved Strengths
|
||||
|
||||
- **Evidence and provenance integrity is exemplary.** All 14 provenance-auditor invariants pass. `ExecutionAttempt` history is genuinely append-only, retries append rather than rewrite, and projection writes are cleanly distinguished from history mutation. Three independent tests — including full before/after field-tuple snapshots — make any mutation regression fail loudly.
|
||||
- **Secret hygiene is correct by construction.** The response-header **allowlist** (`evidence.py:130-134`) fails closed: a newly-introduced sensitive header is excluded by default rather than requiring someone to remember to block it. Request headers are never captured, and `SecretStr` is used end-to-end.
|
||||
- **Atomic job claiming.** `jobs.py:212-222` uses a conditional `UPDATE ... WHERE status = QUEUED ... RETURNING` — a true compare-and-swap that makes double-claiming impossible under concurrency, rather than the common read-then-write race.
|
||||
- **`lazy="raise"` paired with `expire_on_commit=False`.** This combination turns accidental lazy loads into immediate errors instead of silent N+1 queries, and it is the reason no N+1 patterns exist in the codebase. Keep it.
|
||||
- **Architectural rules are mechanically enforced, not merely documented.** AST-based boundary tests for service-to-service imports and UI persistence access are the right pattern; this review's main recommendation is simply to apply that same pattern to three more rules.
|
||||
- **Configuration discipline.** Zero `os.getenv` calls outside `config.py`, `.env` untracked and gitignored, clean Pydantic V2 throughout with no V1 residue.
|
||||
- **Path containment on media serving.** `print_api.py:42-49` uses proper `relative_to` validation rather than string prefix matching.
|
||||
- **Async worker fundamentals.** Task references retained, `CancelledError` re-raised, provider calls outside DB transactions, timeouts resolving to terminal states, no tight polling loop. `asyncio.shield` in `_persist_page_outcome_durably` is a genuinely thoughtful durability mechanism — the fix in HIGH-01 should preserve it for intermediate pages.
|
||||
- **Test contract rigor.** `--strict-markers`, `asyncio_mode = "strict"` honored across all 17 async test files with no missing decorators, and coroutine-never-awaited promoted to a hard error with a clean run.
|
||||
@@ -1,896 +0,0 @@
|
||||
# Architecture & Code Review Report
|
||||
|
||||
**Repository Target:** `C:\Github\transcription\`
|
||||
**Target Stack:** Python 3.12+ | FastAPI | NiceGUI | SQLModel/SQLAlchemy | Pydantic V2 | asyncio | OpenRouter
|
||||
**Review Date:** 2026-09-02
|
||||
**Canonical Baseline:** V6.1 (`docs/index.md`)
|
||||
|
||||
---
|
||||
|
||||
## 0. Verification Commands and Outcomes
|
||||
|
||||
All four commands were executed in this checkout before any finding was written. This report
|
||||
records the exact outcomes rather than assuming them.
|
||||
|
||||
| Command | Outcome |
|
||||
| :--- | :--- |
|
||||
| `uv run pytest -q -m "not external"` | **410 passed, 0 failed, 0 errors** (exit 0) |
|
||||
| `uv run ruff check .` | **All checks passed!** |
|
||||
| `uv run ruff format --check .` | **191 files already formatted** |
|
||||
| `uv run ty check` | **All checks passed!** |
|
||||
|
||||
The stated green baseline is real. No finding below is a test failure; every finding is a
|
||||
behavior, contract, or guard-coverage defect that the passing suite does not detect.
|
||||
|
||||
---
|
||||
|
||||
## 1. Executive Summary
|
||||
|
||||
- **The system's core evidence guarantees hold.** `ExecutionAttempt` is genuinely append-only,
|
||||
attempt numbering is allocated with bounded conflict retry, transport evidence is captured at
|
||||
the HTTP boundary before SDK parsing, and header persistence uses a true allowlist. Provenance
|
||||
invariant families A–E and G pass.
|
||||
- **Both competing atomicity invariants in `services/workflows.py` are real and both guards
|
||||
genuinely enforce them.** I injected-fault-verified the tests rather than trusting the
|
||||
docstrings: `test_pipeline_atomicity.py` fails on a split final-page commit, and
|
||||
`test_workflows_reliability.py:318` reads intermediate attempts through a *separate session*,
|
||||
so it would fail if intermediate pages stopped committing individually.
|
||||
- **The most significant defect is a privacy leak that a prior review believed it had closed.**
|
||||
The 2026-08-23 review moved root-cause text out of `AppError.message` into `AppError.detail`
|
||||
to keep filesystem paths away from users. That text now reaches users anyway, because the UI
|
||||
renders `ExecutionAttempt.error_detail` verbatim (HIGH-01). The leak was relocated, not closed.
|
||||
- **A second, independent path leak exists in five explicit `raise` sites** that the existing
|
||||
guard never covered — it tests only `classify_unexpected_error` (HIGH-02).
|
||||
- **Provenance invariant family F (path safety) fails**, and it fails *inconsistently within one
|
||||
file*: `sources_page.py:443` carefully sanitizes a stored path through
|
||||
`public_media_path_label`, then `sources_page.py:484` dumps raw `error_detail` forty lines later.
|
||||
- **The orphan sweep does not do what its docstring claims.** It matches definitions by bare name,
|
||||
so an entirely dead *module* passes whenever its function names collide with live ones.
|
||||
`ui/pages/tags_page.py` is the proof: 93 lines never imported by anything (MED-01/LOW-01).
|
||||
- **On the three flagged open items:** the V4/V6.1 doc drift is confirmed (MED-02); the
|
||||
`.env.production` coupling is real but currently correct and loud-failing, so Medium not High
|
||||
(MED-03); and the Tags roadmap is **right** — the route is genuinely not registered, so the
|
||||
module is dead code rather than a live retired route.
|
||||
- **Two latent concurrency defects carry ordering constraints** and must be fixed *before* the
|
||||
changes that would make them live (MED-04, MED-05), not after.
|
||||
- **Guidance-file accuracy:** the recently revised `.github/instructions/*` files were verified
|
||||
against code rather than trusted. They are accurate as written; the code is what diverges from
|
||||
them. The one exception is that `error-handling.instructions.md` states a `detail` rule the UI
|
||||
layer has never followed, which makes it an unenforced claim rather than a wrong one.
|
||||
|
||||
---
|
||||
|
||||
## 2. Executive Architecture Assessment
|
||||
|
||||
**Verdict: architecturally sound, with a concentrated failure in the *last mile* of error
|
||||
presentation.**
|
||||
|
||||
Domain cohesion and dependency direction are good and, unusually, mechanically enforced.
|
||||
`test_service_boundaries.py` and `test_ui_boundaries.py` AST-scan for violations using
|
||||
*allowlists* rather than blocklists, which is the correct choice — a newly added persistence
|
||||
helper cannot slip through under an unlisted name. `workflows.py` imports only the abstract
|
||||
`providers` types and never `openrouter`, so provider details genuinely stop at the adapter.
|
||||
Transaction ownership is explicit and well-reasoned: `ServiceBase._finalize` commits for
|
||||
service-owned sessions and flushes for caller-owned ones, which is what lets orchestration
|
||||
modules compose multi-aggregate writes without services importing each other.
|
||||
|
||||
The evidence layer is the strongest part of the system and shows real care. The distinction
|
||||
between transport response, SDK-parsed response, and normalized metadata is maintained in code,
|
||||
not just in prose — `_CapturingAsyncClient` exists specifically to retain the exact wire body
|
||||
before the SDK can discard unknown fields, and `TransportEvidence(response_received=False)`
|
||||
explicitly represents "no response was received" rather than conflating it with an empty one.
|
||||
|
||||
The weakness is at the boundary where internal diagnostic text becomes pixels. Every layer
|
||||
*below* the UI respects the message/detail split; the UI layer reads the internal field directly
|
||||
and renders it. The architecture defines the contract correctly and then has no enforcement at
|
||||
the one layer that violates it.
|
||||
|
||||
**Top systemic risks:**
|
||||
|
||||
1. **Internal diagnostic text reaches users through the evidence display path** (HIGH-01). The
|
||||
rule is documented in three places and enforced in none of them at the UI boundary.
|
||||
2. **Path-safety discipline is applied per-call-site rather than structurally** (HIGH-02, HIGH-01).
|
||||
It is correct wherever someone remembered; there is no guard that makes forgetting fail.
|
||||
3. **Guard coverage is narrower than guard docstrings claim.** Two guards
|
||||
(`test_orphan_sweep.py`, `test_errors.py`) assert something meaningfully weaker than the
|
||||
invariant they are named for, which converts them into a false sense of enforcement.
|
||||
4. **Worker safety currently rests on single-process sequential execution, not on configuration**
|
||||
(MED-04, MED-05). Nothing is wrong today; two plausible future changes each make something wrong.
|
||||
|
||||
---
|
||||
|
||||
## 3. Findings by Severity
|
||||
|
||||
### Critical Severity
|
||||
|
||||
*None.* No evidence loss, append-only violation, secret leakage, or silent-wrong-output defect
|
||||
was found. The candidates in this class (provider evidence mis-attribution, stale-job double
|
||||
processing) are latent and are reported at High/Medium with their unblocking conditions.
|
||||
|
||||
---
|
||||
|
||||
### High Severity
|
||||
|
||||
#### [HIGH-01] Internal-only `error_detail` is rendered directly to users, reopening the leak the 2026-08-23 fix was meant to close
|
||||
|
||||
- **Location:**
|
||||
- Write side: `src/transcription/errors.py:99-139` (`classify_unexpected_error` → `detail`, `format_error_detail` → persisted text)
|
||||
- Persist: `src/transcription/services/workflows.py:720` (`error_detail=format_error_detail(page.error)`)
|
||||
- **Render (Source Detail):** `src/transcription/ui/pages/sources_page.py:481-484`
|
||||
- **Render (Sources list):** `src/transcription/ui/pages/sources_page.py:121` → `src/transcription/ui/components/table/sources.py:39,90-95` ("Error Detail" column)
|
||||
- **Render (Maintenance):** `src/transcription/ui/pages/settings_page.py:562`, written by `src/transcription/services/maintenance.py:206`
|
||||
- Contract violated: `docs/error_handling.md:107-114`; `.github/instructions/error-handling.instructions.md:86`; `docs/invariant/error_handling.md:59`; `docs/invariant/ai_evidence_and_provenance.md:103`
|
||||
|
||||
- **Reachability:** **Live.** Concrete path, no configuration required: a page fails with any
|
||||
non-`AppError` exception → `workflows.py:388` calls `classify_unexpected_error(exc)` →
|
||||
`errors.py:118` sets `detail=f"{type(exc).__name__}: {exc}"` → `format_error_detail`
|
||||
(`errors.py:135-139`) emits `... | detail=OSError: [Errno 13] Permission denied: '/app/uploads/documents/<uuid>/page-1.jpg' | ...`
|
||||
→ persisted to `ExecutionAttempt.error_detail` → rendered verbatim at
|
||||
`sources_page.py:484` and in the `/sources` table column. A SQLAlchemy `OperationalError`
|
||||
carries the database path by the same route.
|
||||
|
||||
- **Problem & Consequence:** `docs/error_handling.md:110` states `detail` is *"Internal only"* and
|
||||
that its only surfaces are `format_error_detail` (evidence) and logs;
|
||||
`error-handling.instructions.md:86` says *"Never rendered to users or serialized into an
|
||||
envelope."* The UI reads it anyway. The consequence is not hypothetical drift — it is the
|
||||
precise defect the previous review's fix existed to prevent. That fix made `message` generic and
|
||||
moved the root cause to `detail` on the stated grounds that `detail` never reaches users. That
|
||||
premise was never true: `error_detail` had a UI consumer the whole time. The result is that the
|
||||
filesystem-path leak was relocated from the notification banner to the Source Detail card and
|
||||
the Sources table, while the test suite records the leak as fixed
|
||||
(`tests/test_errors.py:56-78`).
|
||||
|
||||
The inconsistency is visible inside a single file: `sources_page.py:443` deliberately routes a
|
||||
stored path through `public_media_path_label` (`ui/components/media_urls.py:58-72`), which
|
||||
correctly degrades an absolute path to its bare filename — and then `sources_page.py:484`
|
||||
renders unsanitized text that may contain an absolute path.
|
||||
|
||||
- **Blast Radius:** Enumerated by grepping every reader of `.detail` and `error_detail`:
|
||||
- `errors.py:137` — `format_error_detail`, the only reader of `AppError.detail`. **Must keep the root cause.**
|
||||
- `services/workflows.py:720` — the only writer of `ExecutionAttempt.error_detail`.
|
||||
- `services/maintenance.py:206` — the only writer of `MaintenanceRun.error_detail`.
|
||||
- `services/evidence.py:195` — `build_evidence_export` emits `error_detail`. Export is an
|
||||
operator-initiated evidence artifact; per invariant 3.7.1 it **must** retain it.
|
||||
- `db/models.py:508-522` — `Source.latest_error_detail` projection, consumed only by `sources_page.py:121`.
|
||||
- `ui/pages/sources_page.py:481-484`, `ui/components/table/sources.py`, `ui/pages/settings_page.py:562` — the three render sites.
|
||||
- Tests asserting on persisted text: `tests/test_v42_evidence.py:284`,
|
||||
`tests/services/test_workflows_reliability.py` (timeout detail),
|
||||
`tests/services/test_maintenance_service.py`. A fix that changes *what is stored* breaks these;
|
||||
a fix that changes *what is displayed* does not.
|
||||
|
||||
- **Recommendation — two invariants conflict here; both must be named.**
|
||||
|
||||
**Invariant 1 (evidence):** `ExecutionAttempt.error_detail` must retain the root cause.
|
||||
`docs/requirements.md:30` (REQ-4-021) and `docs/invariant/ai_evidence_and_provenance.md:33`
|
||||
require it; guarded by `tests/test_v42_evidence.py::test_attempts_are_append_only_and_exported_with_integrity`
|
||||
and `tests/services/test_workflows_reliability.py`.
|
||||
|
||||
**Invariant 2 (privacy):** user-facing surfaces must not expose local filesystem details.
|
||||
`docs/invariant/error_handling.md:59`; guarded (partially) by
|
||||
`tests/test_errors.py::test_unexpected_error_does_not_leak_filesystem_paths`.
|
||||
|
||||
**The over-correction to avoid is stripping root-cause text out of `detail` or
|
||||
`format_error_detail` to make the UI safe.** That is exactly the mistake documented in the
|
||||
reviewer skill's worked example, and it would silently destroy the provenance record this
|
||||
system exists to preserve while making every guard still pass.
|
||||
|
||||
Fix at the **render** boundary, not the write boundary. Add a presentation-layer projection and
|
||||
route all three UI sites through it, leaving the persisted evidence untouched:
|
||||
|
||||
```python
|
||||
# src/transcription/ui/components/error_presenter.py (new)
|
||||
def display_failure_detail(error_detail: str | None) -> str | None:
|
||||
"""Render persisted failure detail without machine-local paths.
|
||||
|
||||
`ExecutionAttempt.error_detail` is provenance and keeps the full root cause
|
||||
(docs/error_handling.md). This projection is the only thing a page may show.
|
||||
"""
|
||||
```
|
||||
|
||||
It should preserve the `[category]`, `suggestion=`, and `error_id=` segments (which are what
|
||||
make the display actionable) and reduce any absolute path inside `detail=` to its basename,
|
||||
mirroring `public_media_path_label`. The operator keeps diagnosability — required by
|
||||
`docs/ui/pages/sources.md:43` and `docs/requirements.md:59` (REQ-6-014) — without the container
|
||||
filesystem layout being published to the browser.
|
||||
|
||||
Then decide and record which resolution was chosen: either the UI shows the sanitized
|
||||
projection (recommended), or `docs/error_handling.md:107-114` and
|
||||
`error-handling.instructions.md:86` are revised to state that operator-facing evidence displays
|
||||
may render `error_detail` **and** that the guarantee moves to "no machine-local detail ever
|
||||
enters `detail`" — which would be a much harder guarantee to keep. Do not leave the current
|
||||
state, where the docs claim one thing and three pages do another.
|
||||
|
||||
- **Effort:** M
|
||||
|
||||
---
|
||||
|
||||
#### [HIGH-02] Absolute filesystem paths are embedded in user-facing `AppError.message` at five explicit raise sites
|
||||
|
||||
- **Location:**
|
||||
- `src/transcription/services/sources.py:856` — `f"Prompt file not found: {prompt_path}"`
|
||||
- `src/transcription/services/sources.py:864` — `f"Prompt file is empty: {prompt_path}"`
|
||||
- `src/transcription/services/sources.py:914` — `f"Source file not found: {path}"`
|
||||
- `src/transcription/services/prompts.py:99` — `f"Prompt directory is unavailable: {root}"`
|
||||
- `src/transcription/services/prompts.py:186-191` — `_filesystem_error` builds `f"{message}: {exc}"`
|
||||
- Contract violated: `.github/instructions/error-handling.instructions.md:74,85`; `docs/invariant/error_handling.md:59`
|
||||
|
||||
- **Reachability:** **Live**, on an ordinary user path. `sources.py:845` resolves
|
||||
`prompt_root = runtime_settings.prompt_dir.resolve()`, so `prompt_path` is absolute
|
||||
(`/app/prompts/transcribe_document.md` in the container). `load_prompt_text` is invoked by
|
||||
`build_prompt_execution` (`sources.py:829-831`), which runs on **every document upload** via
|
||||
`services/store.py:94` and `store.py:162`. The resulting `PromptLoadError` is an `AppError`
|
||||
subclass, so it flows through `run_ui_action` → `show_error`
|
||||
(`ui/components/error_presenter.py:51-66`), which renders `error.message` into both a
|
||||
`ui.notify` banner and a card label, and through `build_error_envelope` (`errors.py:88-96`)
|
||||
into API responses.
|
||||
|
||||
- **Problem & Consequence:** `error-handling.instructions.md:85` requires `message` to *"Stay
|
||||
generic. Never embed exception text, provider payloads, or filesystem paths."* These five sites
|
||||
embed exactly that. `prompts.py:186-191` violates the rule in **both** directions at once: it
|
||||
puts `{exc}` — an `OSError` whose `str()` includes the offending filename — into `message`, and
|
||||
it sets **no `detail=`**, so the internal field that is supposed to carry the root cause is
|
||||
empty while the user-facing field carries all of it.
|
||||
|
||||
This is not a new regression; it is coverage that the existing guard never had.
|
||||
`tests/test_errors.py:56-78` verifies only that `classify_unexpected_error` — the *catch-all*
|
||||
path — does not leak. Every deliberate `raise SomeError(f"... {path}")` in the codebase is
|
||||
outside its scope, so the suite reports the invariant as enforced while five live sites violate it.
|
||||
|
||||
- **Blast Radius:** Verified by grepping all consumers of these exception types.
|
||||
`PromptLoadError`/`PromptStoreError`/`TranscriptionError` messages are consumed by:
|
||||
`ui/components/error_presenter.py:55,63` (render), `errors.py:92` (API envelope),
|
||||
`errors.py:135` (`format_error_detail` → evidence). Because the recommended change *adds* a
|
||||
`detail` and *shortens* `message`, `format_error_detail` output still contains the path — so
|
||||
evidence value is preserved, not reduced. Tests asserting on these messages:
|
||||
`tests/test_prompts.py`, `tests/services/test_prompt_store.py`,
|
||||
`tests/services/test_transcription_service.py`. These assert on message prefixes
|
||||
(`"Prompt file not found"`), not on the interpolated path, and were checked to survive the change —
|
||||
but re-run them, since `prompts.py:186` currently produces a message whose suffix some
|
||||
assertion could depend on.
|
||||
|
||||
- **Recommendation:** Apply the pattern `errors.py:113-119` already establishes — generic
|
||||
`message`, root cause on `detail`, `raise ... from exc`. Use `path.name` when a filename is
|
||||
genuinely useful to the user.
|
||||
|
||||
```python
|
||||
# sources.py:855 — before
|
||||
raise PromptLoadError(f"Prompt file not found: {prompt_path}", ...)
|
||||
# after
|
||||
raise PromptLoadError(
|
||||
f"Prompt file not found: {prompt_path.name}",
|
||||
category=ErrorCategory.INFRA_PERSISTENT,
|
||||
suggestion="Verify PROMPT_DIR and prompt file configuration, then retry.",
|
||||
detail=f"Prompt file missing at {prompt_path}",
|
||||
)
|
||||
|
||||
# prompts.py:186 — before
|
||||
return PromptStoreError(f"{message}: {exc}", category=..., suggestion=...)
|
||||
# after
|
||||
return PromptStoreError(
|
||||
message,
|
||||
category=ErrorCategory.INFRA_PERSISTENT,
|
||||
suggestion="Check prompt directory permissions and available disk space, then retry.",
|
||||
detail=f"{type(exc).__name__}: {exc}",
|
||||
)
|
||||
```
|
||||
|
||||
Then widen the guard so this class cannot recur — see MED-07. Note the dependency: HIGH-02 and
|
||||
HIGH-01 must be fixed **together**, because moving the path from `message` to `detail` while the
|
||||
UI still renders `error_detail` relocates the leak instead of closing it. That is the same
|
||||
mistake that produced HIGH-01.
|
||||
|
||||
- **Effort:** S (fix) / M (with the guard)
|
||||
|
||||
---
|
||||
|
||||
### Medium Severity
|
||||
|
||||
#### [MED-01] The orphan sweep matches by bare name and therefore cannot detect a dead module
|
||||
|
||||
- **Location:** `tests/test_orphan_sweep.py:101-163` (`_public_definitions`, `_orphans`)
|
||||
- **Reachability:** **Live** — the guard is running now and reporting a clean sweep that is not clean.
|
||||
- **Problem & Consequence:** `_public_definitions()` keys definitions by bare name
|
||||
(`definitions[node.name]`, line 111) and `_orphans()` marks a definition referenced if that
|
||||
bare name appears **anywhere** in `src/`, `tests/`, or `tools/` (lines 157-162). Two different
|
||||
modules that define the same public name are therefore indistinguishable, and neither can ever
|
||||
be reported as an orphan.
|
||||
|
||||
`src/transcription/ui/pages/tags_page.py` demonstrates the consequence. Its only public
|
||||
definition is `register_page` (line 18). Seven live page modules define a function of the same
|
||||
name and `ui/__init__.py:37-43` calls all seven — so `register_page` is heavily referenced and
|
||||
`tags_page.register_page` is scored as reachable. In fact **nothing imports `tags_page` at all**
|
||||
(verified: the only repo-wide references to the module are the file itself and
|
||||
`tests/ui/test_tags_page.py`, which merely asserts the route 404s). 93 lines of code, including a
|
||||
lazy-load-unsafe relationship traversal at `tags_page.py:71-74`, sit outside the sweep's reach.
|
||||
|
||||
The sweep also never asks whether a *module* is imported, only whether its definitions' names
|
||||
appear somewhere — so this is a structural gap, not a one-off miss.
|
||||
|
||||
- **Blast Radius:** `tests/test_orphan_sweep.py` only; `KNOWN_ORPHANS` entries are keyed by the
|
||||
same bare/dotted names and would need re-keying if qualification is added. Expect the stricter
|
||||
sweep to surface additional true orphans on first run — triage them into `KNOWN_ORPHANS` with
|
||||
rationales rather than weakening the check.
|
||||
- **Recommendation:** Qualify definitions by module (`f"{module_path}:{name}"`) and add a separate,
|
||||
cheap module-reachability pass: a module under `src/transcription/` is reachable if any other
|
||||
module imports it, or it is a declared entrypoint (`app.py`, `__main__.py`, `worker_service.py`).
|
||||
Report unreachable modules as orphans in their own right. Also fix
|
||||
`test_public_definitions_are_discovered` (line 169), whose `>= 420` snapshot threshold is a
|
||||
weak assertion that drifts upward silently — the 2026-08-23 review already flagged the same
|
||||
pattern at the then-current `>= 200` and it was raised rather than replaced.
|
||||
- **Effort:** M
|
||||
|
||||
---
|
||||
|
||||
#### [MED-02] Canonical invariant document declares a V4 baseline while the canonical baseline is V6.1
|
||||
|
||||
- **Location:** `docs/invariant/ai_evidence_and_provenance.md:130`
|
||||
- **Reachability:** **Live** (documentation), no runtime impact.
|
||||
- **Problem & Consequence:** Section 6.1 reads *"Canonical V4 architecture, schema, requirements,
|
||||
and error-policy documents define how current behavior satisfies this invariant."*
|
||||
`docs/index.md:1,29-32` establishes V6.1 as the baseline and states that every canonical document
|
||||
asserts the same baseline. This is the **ownership clause of the invariant that governs the
|
||||
entire evidence model** — the clause that tells a reader which documents are authoritative — and
|
||||
it points at a superseded generation. A reader following it lands on stale authority precisely
|
||||
when resolving an evidence question, which is the highest-stakes case.
|
||||
|
||||
A baseline-currency guard **does** exist —
|
||||
`tests/test_meta_contract_guards.py::test_canonical_docs_declare_one_consistent_baseline`
|
||||
(lines 89-112) — and `docs/invariant/ai_evidence_and_provenance.md` is **not** in
|
||||
`BASELINE_SCAN_EXCLUSIONS` (lines 56-64), so the file is scanned. The claim escapes for two
|
||||
independent reasons, either of which alone would be sufficient:
|
||||
1. `_CURRENT_VERSION_CLAIM` (line 67) matches only the words `current` or `active` before a
|
||||
version. This line says "**Canonical** V4", a third phrasing the pattern does not know.
|
||||
2. Both patterns require `V(\d+\.\d+)` — a mandatory minor version. The bare token `V4` cannot
|
||||
match either regex under any phrasing.
|
||||
|
||||
The guard is therefore not absent but *phrase-shaped*: it enforces currency only for the two
|
||||
sentence forms someone thought of, against version strings that carry a minor. That is a weaker
|
||||
property than its docstring implies ("Every canonical doc that names the current baseline must
|
||||
name the same one").
|
||||
- **Blast Radius:** Documentation only; no code reads this string. Widening the guard's patterns
|
||||
will re-scan all canonical docs — expect it to surface further stale mentions on first run
|
||||
(`docs/architecture.md`, `docs/schema.md`, `docs/requirements.md`, and `docs/error_handling.md`
|
||||
each contain 2-3 version tokens), which should be triaged rather than excluded.
|
||||
- **Recommendation:** Two parts, and the second matters more than the first.
|
||||
1. Change "Canonical V4" to "Canonical V6.1" at line 130.
|
||||
2. Fix the guard's shape rather than adding a third phrase to the list. Accept an optional minor
|
||||
(`V(\d+)(?:\.(\d+))?`) and invert the matching: flag **every** `V<n>` token in a scanned
|
||||
canonical doc that is not the declared baseline, rather than only those preceded by an
|
||||
approved adjective. Phrase-list matching fails open — each new phrasing silently reopens the
|
||||
hole — whereas token matching fails closed and forces an explicit exclusion.
|
||||
|
||||
See §8.1 for the alternative the maintainer is considering: dropping version labels from
|
||||
canonical docs entirely, which removes the failure mode instead of guarding it.
|
||||
- **Effort:** S
|
||||
|
||||
---
|
||||
|
||||
#### [MED-03] Settings resolve `.env.production` relative to the process working directory, and the isolation fix exists only in the test harness
|
||||
|
||||
- **Location:** `src/transcription/config.py:66-75` (`env_file=".env.production"`);
|
||||
workaround at `tests/conftest.py:27-50`; guarded by `tests/test_config_isolation.py`;
|
||||
depended on by `.github/workflows/quality-gate.yml` and `docker-compose.production.yml`
|
||||
- **Reachability:** **Live but currently correct.** I verified the production path rather than
|
||||
assuming it: `Dockerfile` sets `WORKDIR /app` in the runtime stage, and
|
||||
`docker-compose.production.yml` mounts `./.env.production` to `/app/.env.production` for both the
|
||||
`app` and `worker` services, so the relative path resolves correctly today.
|
||||
- **Problem & Consequence:** Correct configuration loading depends on an **implicit, undocumented
|
||||
contract between `config.py` and the process working directory.** Nothing in `config.py` states
|
||||
it, and nothing tests it. The failure mode is not silent — `openrouter_api_key` is required with
|
||||
no default, so a wrong cwd produces a `ValidationError` at startup rather than a partially
|
||||
configured process — which is why this is Medium rather than High.
|
||||
|
||||
The more telling symptom is what the coupling forced on the test harness. `conftest.py:45-50`
|
||||
cannot escape it by passing an argument; it must **mutate the Pydantic class-level
|
||||
`model_config` dict at runtime** and restore it in a `finally`. That is a global, order-sensitive
|
||||
side effect adopted because the module offers no seam. It also silently repairs a second
|
||||
consumer: `ui/runtime_settings_store.py:402` reads the same `Settings.model_config["env_file"]`
|
||||
to decide where the Settings page writes. Two subsystems are coupled through a mutable class
|
||||
attribute.
|
||||
- **Blast Radius:** Every `Settings` construction. Consumers of `model_config["env_file"]`:
|
||||
`ui/runtime_settings_store.py:402` (write-target resolution, contract documented at
|
||||
`docs/ui/pages/settings.md:27`) and `tests/conftest.py:45-50`. A change must preserve the
|
||||
documented three-step resolution order — explicit override, `RUNTIME_SETTINGS_ENV_FILE`, then the
|
||||
configured default — or `docs/ui/pages/settings.md:27` becomes wrong.
|
||||
- **Recommendation:** Introduce one explicit resolution function that both `Settings` construction
|
||||
and `runtime_settings_store` call, honoring an `ENV_FILE` environment variable and falling back
|
||||
to a path anchored to a known root rather than to `os.getcwd()`. Tests then pass a path instead of
|
||||
mutating class state, and `tests/test_config_isolation.py` can assert against the seam rather
|
||||
than against the monkeypatch. If instead the cwd contract is accepted as deliberate, document it
|
||||
in `config.py` and in `docs/production-runbook.md` and add a guard asserting `WORKDIR`/cwd
|
||||
alignment — an implicit contract with a container image is exactly the kind of rule the invariant
|
||||
routing table exists to place.
|
||||
- **Effort:** M
|
||||
|
||||
---
|
||||
|
||||
#### [MED-04] Stale-job reclaim threshold is not derived from maximum job duration; safety currently comes from single-process sequencing
|
||||
|
||||
- **Location:** `src/transcription/config.py:116-117`
|
||||
(`worker_provider_timeout_seconds=30.0`, `worker_stale_job_seconds=30.0`);
|
||||
sweep at `src/transcription/worker.py:222-228`; reclaim at
|
||||
`src/transcription/services/jobs.py:242-268`
|
||||
- **Reachability:** **Latent.** Unblocked by *either* of: (a) running more than one worker replica
|
||||
(adding `deploy.replicas > 1` to the `worker` service in `docker-compose.production.yml`), or
|
||||
(b) setting `RUN_EMBEDDED_WORKER=true` on the `app` service while the standalone `worker`
|
||||
container is also running. It is safe today only because
|
||||
`docker-compose.production.yml` sets `RUN_EMBEDDED_WORKER: "false"` on `app` and defines exactly
|
||||
one `worker`, and because within a single loop `run_worker_loop` awaits
|
||||
`process_next_queued_job` to completion before returning to the stale sweep — so the sweep can
|
||||
never observe a job that this same process is actively working.
|
||||
- **Problem & Consequence:** The stale threshold (30s) **equals** the per-page provider timeout
|
||||
(30s), leaving zero margin even for a single-page job. A multi-page document is legitimately
|
||||
`PROCESSING` for up to N × 30s. `Job.date_updated` carries an `onupdate`
|
||||
(`db/models.py:372-375`), but between the initial claim and the terminal write the only touch
|
||||
is `sources.py:522-523` reassigning `job.provider`/`job.model` to values they usually already
|
||||
hold, which SQLAlchemy resolves to no net change and therefore no `UPDATE`. I did not empirically
|
||||
confirm the no-`UPDATE` behavior, so treat that specific step as unverified — but the finding does
|
||||
not depend on it, because even a per-page refresh leaves only a 30s margin against a 30s timeout.
|
||||
|
||||
With a second concurrent worker, the sweep would requeue a job that is mid-provider-call. Both
|
||||
workers then process the same job, producing duplicate `ExecutionAttempt` rows for the same
|
||||
logical work and racing terminal status writes. Append-only history would be *preserved* but no
|
||||
longer *faithful*: the evidence would show attempts that do not correspond to distinct
|
||||
application decisions.
|
||||
|
||||
This is worth flagging because `jobs.py:191-197` explicitly implements and documents
|
||||
`SKIP LOCKED` row locking "so concurrent workers never contend for the same job." The claim path
|
||||
is built for multi-worker operation; the reclaim path is not. A reader who trusts the claim
|
||||
docstring would reasonably scale the worker.
|
||||
- **Blast Radius:** `requeue_stale_processing_jobs` has one production caller (`worker.py:226`) and
|
||||
tests in `tests/test_worker.py` and `tests/services/test_job_service.py`. Changing the *default*
|
||||
affects `tests/test_config.py` declared-defaults assertions — check those before editing the default.
|
||||
- **Recommendation:** **Fix before adding a second worker replica, not after.** Two parts:
|
||||
(1) Make the threshold a function of the real bound rather than a coincidental peer of the
|
||||
page timeout — at minimum default `worker_stale_job_seconds` to a multiple of
|
||||
`worker_provider_timeout_seconds` with headroom, and add a model validator rejecting a stale
|
||||
threshold at or below the provider timeout.
|
||||
(2) Preferably make reclaim heartbeat-based: have `_persist_page_outcome` bump `Job.date_updated`
|
||||
explicitly so liveness reflects progress rather than elapsed time since claim.
|
||||
Add a guard asserting a multi-page job in flight is not reclaimed by a concurrently-invoked sweep.
|
||||
- **Effort:** M
|
||||
|
||||
---
|
||||
|
||||
#### [MED-05] Provider evidence capture is per-instance mutable state, making the adapter non-reentrant by contract
|
||||
|
||||
- **Location:** `src/transcription/providers/openrouter.py:197-199, 264-267, 274-275, 297-298, 397-412`;
|
||||
`_CapturingAsyncClient.last_response`/`last_body` at `openrouter.py:66-94`;
|
||||
contract at `src/transcription/providers/base.py:110-118`
|
||||
(`current_request_manifest`, `current_transport_evidence`)
|
||||
- **Reachability:** **Latent.** Unblocked by any concurrent `transcribe()` on a single adapter
|
||||
instance — most plausibly by processing a job's pages in parallel (`workflows.py:274` is
|
||||
currently a sequential `for` loop) or by any second consumer sharing one
|
||||
`SourceService.provider`. Verified safe today: `workflows.py:272` resolves one provider for the
|
||||
loop and awaits each page; the worker's `ServiceBundle` (`worker.py:206`) is distinct from
|
||||
`app.state.services` (`app.py:43`), so the UI cannot share the worker's adapter instance, and
|
||||
the UI only enqueues jobs (`ui/pages/jobs_page.py:186-208`).
|
||||
- **Problem & Consequence:** The `TranscriptionProvider` protocol defines evidence retrieval as
|
||||
"the most recent call" state read *after* the fact. `workflows.py:369-370` relies on this on the
|
||||
timeout path, reading `provider.current_request_manifest` / `current_transport_evidence` when no
|
||||
result object exists. Under concurrency, page B's response overwrites
|
||||
`_CapturingAsyncClient.last_response` before page A's timeout handler reads it, and page A's
|
||||
`ExecutionAttempt` is written with page B's transport evidence.
|
||||
|
||||
The consequence is **evidence mis-attribution** — a provenance-integrity failure, which this
|
||||
project's own rubric treats as its most serious class. It would also be near-undetectable after
|
||||
the fact: the attempt row would be well-formed, internally consistent, and wrong. The
|
||||
application-level design that makes this safe (sequential pages) is not expressed in the
|
||||
provider contract, so the constraint lives only in `workflows.py`'s loop structure.
|
||||
- **Blast Radius:** Changing the protocol touches `providers/base.py:102-136`,
|
||||
`providers/openrouter.py:221-231`, the two read sites at `workflows.py:369-370`, and the fakes in
|
||||
`tests/providers/test_openrouter.py`, `tests/services/test_workflows_reliability.py`, and
|
||||
`tests/test_provider_boundaries.py`, all of which implement or assert the current property-based
|
||||
contract.
|
||||
- **Recommendation:** **Fix before introducing any intra-job page concurrency.** The durable fix is
|
||||
to stop returning evidence through instance state: attach `request_manifest` and
|
||||
`transport_evidence` to the raised exception on every failure path — which `ProviderError`
|
||||
already supports (`providers/base.py:18-29`) and which the timeout path cannot currently use
|
||||
because `asyncio.wait_for` raises `TimeoutError` from outside the adapter. A narrower option is
|
||||
to have `transcribe()` accept a caller-owned capture sink so evidence is scoped to the call
|
||||
rather than to the adapter. As an immediate, near-zero-cost step, document the non-reentrancy on
|
||||
the protocol in `providers/base.py` so the constraint is visible where it is depended upon.
|
||||
- **Effort:** M
|
||||
|
||||
---
|
||||
|
||||
#### [MED-06] Provider error bodies reach user-facing text while three provider failure paths persist no `detail`
|
||||
|
||||
- **Location:** `src/transcription/services/sources.py:923-947` (`handle_transcription_errors`);
|
||||
message construction at `src/transcription/providers/openrouter.py:414-431`
|
||||
(`_transport_error_message`)
|
||||
- **Reachability:** **Live** for the message half (any provider failure during a UI-initiated
|
||||
transcription surfaces through `show_error`).
|
||||
- **Problem & Consequence:** Two mirrored halves of the same rule are broken in one function.
|
||||
- `sources.py:943` builds `f"Provider transcription failed: {exc}"`, and `exc` is a
|
||||
`ProviderError` whose message may embed up to 500 characters of the provider's error body
|
||||
(`openrouter.py:430`). That is a provider payload in `message`, which
|
||||
`error-handling.instructions.md:85` explicitly forbids.
|
||||
- None of the three handlers (lines 929, 935, 942) passes `detail=`. Per
|
||||
`error-handling.instructions.md:89-92`, omitting it degrades the provenance record.
|
||||
|
||||
I checked whether the provenance half is actually harmful before reporting it, and it is
|
||||
**substantially mitigated**: `workflows.py:391` calls `_find_provider_error`, which walks
|
||||
`__cause__`/`__context__` (`workflows.py:806-813`) to recover the original `ProviderError` and
|
||||
persists its `transport_evidence` — status code, safe headers, and the exact response body — onto
|
||||
the attempt. So the root cause is preserved in transport evidence even though `error_detail` is
|
||||
thin. This is why the finding is Medium rather than High. The residual cost is that the
|
||||
human-readable failure summary is uninformative for the two paths (`ProviderAuthError`,
|
||||
`ProviderResponseError`) whose messages are entirely generic.
|
||||
- **Blast Radius:** `handle_transcription_errors` is used on the transcription path in
|
||||
`sources.py`; `TranscriptionError.message` is consumed by `error_presenter.show_error`,
|
||||
`build_error_envelope`, and `format_error_detail`. Assertions on these messages live in
|
||||
`tests/services/test_transcription_service.py` and `tests/providers/test_openrouter.py`.
|
||||
- **Recommendation:** Move the interpolated provider text from `message` to `detail` on all three
|
||||
handlers, keeping the generic message the other two already use:
|
||||
```python
|
||||
except ProviderError as exc:
|
||||
raise TranscriptionError(
|
||||
"Provider transcription failed",
|
||||
category=ErrorCategory.EXTERNAL_PROVIDER,
|
||||
suggestion="Retry the transcription from jobs. If repeated, check provider availability.",
|
||||
retriable=True,
|
||||
detail=f"{type(exc).__name__}: {exc}",
|
||||
) from exc
|
||||
```
|
||||
Apply the same `detail=` addition to the `ProviderAuthError` and `ProviderResponseError`
|
||||
handlers. Note the interaction with HIGH-01: until the render boundary is sanitized, moving text
|
||||
into `detail` still reaches users through the `error_detail` display. Sequence accordingly.
|
||||
- **Effort:** S
|
||||
|
||||
---
|
||||
|
||||
#### [MED-07] No deterministic guard covers the `message`/`detail` split at explicit raise sites
|
||||
|
||||
- **Location:** `tests/test_errors.py:56-78`; rule at
|
||||
`.github/instructions/error-handling.instructions.md:78-98`; canonical statement at
|
||||
`docs/error_handling.md:102-115`
|
||||
- **Reachability:** **Live** — this coverage gap is what allowed HIGH-02 and MED-06 to exist in a
|
||||
fully green suite.
|
||||
- **Problem & Consequence:** `docs/error_handling.md:115` names
|
||||
`tests/test_errors.py::test_unexpected_error_does_not_leak_filesystem_paths` as the enforcement
|
||||
for the message/detail split. That test exercises exactly one function,
|
||||
`classify_unexpected_error`. Every direct `raise SomeAppError(...)` in `src/` — roughly 50 sites
|
||||
by grep — is unenforced. The documentation therefore overstates the enforcement, which is worse
|
||||
than having no guard: a contributor reading `error_handling.md:115` reasonably concludes the rule
|
||||
is mechanically protected.
|
||||
|
||||
Per the reviewer skill, where a check is unenforced, recommending the deterministic test is
|
||||
itself a finding.
|
||||
- **Blast Radius:** Tests only.
|
||||
- **Recommendation:** Add an AST guard, `tests/test_error_message_safety.py`, that scans `src/`
|
||||
for `raise <AppError subclass>(...)` and fails when the first positional argument is an f-string
|
||||
containing a formatted value whose name matches a path-like or exception-like identifier
|
||||
(`path`, `_path`, `root`, `dir`, `exc`, `err`, `e`). Model it on the existing AST guards, which
|
||||
are the established pattern here (`test_ui_boundaries.py`, `test_service_boundaries.py`,
|
||||
`test_orphan_sweep.py`). Pair it with a second guard asserting that no UI module reads
|
||||
`error_detail` without routing through the sanitizing projection from HIGH-01 — that one closes
|
||||
the render side, which is where the real leak is.
|
||||
- **Effort:** M
|
||||
|
||||
---
|
||||
|
||||
### Low Severity
|
||||
|
||||
#### [LOW-01] `ui/pages/tags_page.py` is dead code; the V6.1 roadmap is correct
|
||||
|
||||
- **Location:** `src/transcription/ui/pages/tags_page.py` (93 lines);
|
||||
registration list at `src/transcription/ui/__init__.py:37-43`
|
||||
- **Reachability:** **Not reachable.** This resolves the flagged open item: the route is genuinely
|
||||
**not** registered. `register_pages` calls seven page registrars and `tags_page` is not among
|
||||
them; nothing anywhere imports the module. `docs/roadmap_plan.md:47` ("Retire the Tags page") is
|
||||
accurate, and `tests/ui/test_tags_page.py` correctly asserts `/ui/tags` returns 404 — though it
|
||||
passes trivially, since an unimported module cannot register anything.
|
||||
- **Problem & Consequence:** No runtime risk; purely stranded code. It is worth noting that if it
|
||||
*were* ever re-registered, `tags_page.py:71-74` traverses `document.document_tags` and
|
||||
`link.tag_ref` inside a page render, and those relationships are configured `lazy="raise"`
|
||||
(`docs/architecture.md:200-203`) — so re-enabling this module without adding eager loads to
|
||||
`list_documents` would raise on first render.
|
||||
- **Recommendation:** Delete `src/transcription/ui/pages/tags_page.py`. Retain
|
||||
`tests/ui/test_tags_page.py` as the retirement guard. Fixing MED-01 first would make this
|
||||
finding reproducible by the suite rather than by manual inspection.
|
||||
- **Effort:** S
|
||||
|
||||
#### [LOW-02] `benchmarking.py` ships in the runtime package but is referenced only by tests
|
||||
|
||||
- **Location:** `src/transcription/benchmarking.py` (69 lines); sole consumers
|
||||
`tests/test_v42_evidence.py:15-16` (`EditorialAssessment`, `score_transcription`)
|
||||
- **Reachability:** Live as importable API; never invoked by application code.
|
||||
- **Problem & Consequence:** No defect. It supports the model-evaluation policy in
|
||||
`docs/invariant/ai_evidence_and_provenance.md:113-126`, which is legitimate, but it currently has
|
||||
no production caller and no tooling entrypoint, so it is indistinguishable from drift.
|
||||
- **Recommendation:** Either move it under `tools/` alongside the other operator utilities, or add
|
||||
a `KNOWN_ORPHANS`-style rationale recording that it is retained as the evaluation-policy
|
||||
implementation. Do not silently keep it unlabeled.
|
||||
- **Effort:** S
|
||||
|
||||
#### [LOW-03] Two overlapping prompt error types split across modules
|
||||
|
||||
- **Location:** `src/transcription/services/errors.py:15-16` (`PromptLoadError`) and
|
||||
`src/transcription/services/prompts.py:19` (`PromptStoreError`)
|
||||
- **Reachability:** Live; no misbehavior observed.
|
||||
- **Problem & Consequence:** `services/errors.py:1-8` documents itself as the neutral home for
|
||||
exceptions raised by more than one service, precisely so a caller's `except` clause does not
|
||||
change when an operation moves. `PromptStoreError` is defined outside that module and covers an
|
||||
overlapping domain (prompt file access), so a caller wanting to handle "any prompt failure" must
|
||||
import from two modules and know which is which. `sources.py:855` raises `PromptLoadError` for a
|
||||
missing prompt file while `prompts.py:132` raises `PromptStoreError` for the same condition
|
||||
reached through the Settings page.
|
||||
- **Recommendation:** Move `PromptStoreError` into `services/errors.py` next to `PromptLoadError`,
|
||||
or make one a subclass of the other so a single `except` covers prompt failures. Low urgency; do
|
||||
it opportunistically when HIGH-02 touches both files anyway.
|
||||
- **Effort:** S
|
||||
|
||||
---
|
||||
|
||||
## 4. Architectural Drift & Gap Analysis
|
||||
|
||||
| Area / Component | Direction | Documented / Intended Rule | Actual Implementation State | Severity | Recommended Resolution |
|
||||
| :--- | :--- | :--- | :--- | :--- | :--- |
|
||||
| Error presentation | `doc->code` | `docs/error_handling.md:110` — `detail` is internal only, surfaced by `format_error_detail` and logs | `sources_page.py:484`, `table/sources.py:90`, `settings_page.py:562` render `error_detail` verbatim to users | High | Sanitizing render projection (HIGH-01); do **not** strip `detail` |
|
||||
| User-facing messages | `doc->code` | `invariant/error_handling.md:59` — no local filesystem detail in user-facing messages | 5 live sites interpolate absolute paths into `AppError.message` | High | Generic `message`, path on `detail` (HIGH-02) |
|
||||
| Evidence invariant ownership | `doc->doc` | `docs/index.md:1` — baseline is V6.1 | `invariant/ai_evidence_and_provenance.md:130` names "Canonical V4"; the currency guard scans the file but its regexes match neither the phrasing nor a minor-less `V4` | Medium | Update text; make the guard token-based, or drop version labels entirely (MED-02, §8.1) |
|
||||
| Enforcement claim | `doc->code` | `docs/error_handling.md:115` — split "Enforced by `tests/test_errors.py::…`" | That test covers only `classify_unexpected_error`; explicit raises unguarded | Medium | Add AST guard (MED-07) |
|
||||
| Orphan sweep | `doc->code` | `test_orphan_sweep.py:1-13` — sweep is "deterministic" and "conservative" | Bare-name matching; cannot see a dead module (`tags_page.py`) | Medium | Qualify by module + module-reachability pass (MED-01) |
|
||||
| Worker scaling | `code->doc` | `jobs.py:191-197` — `SKIP LOCKED` so "concurrent workers never contend" | Claim path is multi-worker-safe; stale-reclaim path is not | Medium | Derive stale threshold from job duration; document single-worker constraint until fixed (MED-04) |
|
||||
| Provider adapter contract | `code->doc` | `providers/base.py:110-118` — evidence read as "most recent call" state | Contract is silently non-reentrant; safety lives in `workflows.py`'s sequential loop | Medium | Scope evidence to the call; document non-reentrancy (MED-05) |
|
||||
| Settings env file | `code->doc` | `config.py:66-75` — `env_file=".env.production"` | Correctness depends on an undocumented cwd contract with `Dockerfile` `WORKDIR /app` | Medium | Explicit resolver seam, or document + guard the contract (MED-03) |
|
||||
| Tags page | *(no drift)* | `roadmap_plan.md:47` — Tags page retired | Route genuinely unregistered; module is stranded code | Low | Delete the module (LOW-01) |
|
||||
|
||||
---
|
||||
|
||||
## 5. Invariant Inventory & Routing Recommendations
|
||||
|
||||
| Invariant / Constraint | Current Location | Recommended Target Layer | Rationale |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| `detail`/`error_detail` never rendered to users | docs + instructions | **Deterministic test** + sanitizing projection | Stated in three documents and violated in three files; prose has demonstrably failed to hold it |
|
||||
| `message` carries no paths or exception text | instructions; partial test | **Deterministic test** (AST, all raise sites) | Existing guard covers one function; the gap produced HIGH-02 |
|
||||
| `ExecutionAttempt.error_detail` retains root cause | docs + `test_v42_evidence.py` | **Keep in tests** — already correct | Counterweight to the above; must be named in any fix so it is not over-corrected |
|
||||
| Intermediate pages commit individually | `workflows.py` docstring + `test_workflows_reliability.py:318` | **Keep in tests** — verified genuine | Cross-session read makes it a real durability assertion |
|
||||
| Final page atomic with terminal status | `services.instructions.md` + `test_pipeline_atomicity.py` | **Keep in tests** — verified genuine | Fault injection makes a split commit fail |
|
||||
| Canonical baseline version consistency | `docs/index.md` + `test_meta_contract_guards.py:89` | **Repair existing test, or remove the labels** | Guard exists but matches by approved phrase and requires a minor version, so it fails open on new phrasings (MED-02) |
|
||||
| Module-level reachability / dead modules | `test_orphan_sweep.py` (ineffective) | **Deterministic test** (repair existing) | Guard exists but cannot detect the case (MED-01) |
|
||||
| Stale threshold > max job duration | *(unenforced)* | **Config validator + test** | Currently a coincidence of two equal defaults (MED-04) |
|
||||
| Provider adapter non-reentrancy | *(unenforced, implicit)* | **Instructions** + protocol docstring | A design constraint callers must know before adding concurrency (MED-05) |
|
||||
| Env-file resolution independent of cwd | `tests/conftest.py` monkeypatch | **Code seam** + `docs/production-runbook.md` | A test-only fix for a production coupling is misrouted enforcement (MED-03) |
|
||||
|
||||
---
|
||||
|
||||
## 6. Stack-Specific Analysis
|
||||
|
||||
**Python 3.12+.** Modern and consistent. PEP 695 generics are used correctly and non-trivially
|
||||
(`RegistryService[ModelT: RegistryEntry]` in `services/registry.py:58`, `UiActionOutcome[T]`,
|
||||
`_get_or_raise[ModelT]`), `type` statements appear in `db/session.py:15,50`, and `X | None` is
|
||||
used throughout. `structural Protocol` bounds (`RegistryEntry`, `WorkerNotifier`,
|
||||
`TranscriptionProvider`) are used to avoid type suppressions rather than to decorate. `ty` passes
|
||||
clean with no suppressions found. The two `# noqa` uses (`workflows.py:228` `PLR0915`,
|
||||
`workflows.py:383` `BLE001`) are both justified in context — the broad catch is a deliberate
|
||||
per-page containment boundary that immediately classifies and re-records.
|
||||
|
||||
**FastAPI.** Lifespan is handled via `@asynccontextmanager` (`app.py:36`), not the deprecated
|
||||
`@app.on_event`. Session factories are injected through `Depends` (`SessionFactoryDep`,
|
||||
`db/session.py:50`) rather than reached as globals from routes. `api/errors.py` centralizes
|
||||
envelope translation. One residual: `get_settings` is `@cache`d and read as a module-level
|
||||
fallback in ~10 modules; this is acceptable given the documented restart-to-apply contract
|
||||
(`docs/ui/pages/settings.md:28`) but means the cache is process-lifetime and unclearable.
|
||||
|
||||
**NiceGUI (pinned `3.13.0`).** The pin is a recorded release-stability decision and is not
|
||||
reported as a defect. Boundaries are enforced structurally: `test_ui_boundaries.py` uses an
|
||||
import **allowlist**, which is the right polarity. Blocking work is dispatched off the event loop
|
||||
via `run_blocking` (`settings_page.py:818,822`). The one boundary that is *not* enforced is
|
||||
presentation of internal fields (HIGH-01) — pages are prevented from touching persistence but not
|
||||
from rendering internal-only text.
|
||||
|
||||
**SQLModel / SQLAlchemy.** Strong. `lazy="raise"` on relationships forces explicit eager loading;
|
||||
read paths declare `selectinload` chains with comments explaining *why* each is needed
|
||||
(`sources.py:309-316` is a good example). `expire_on_commit=False` (`db/session.py:28`) is set
|
||||
deliberately, which is what makes post-commit attribute access in `evidence.py:159-202` safe.
|
||||
`claim_next_queued_job` (`jobs.py:186-241`) branches correctly on dialect — `SKIP LOCKED` on
|
||||
PostgreSQL, conditional `UPDATE ... RETURNING` on SQLite — rather than assuming one engine.
|
||||
Attempt-number allocation uses `begin_nested()` with bounded retry (`sources.py:598-616`), the
|
||||
right pattern for a monotonic per-parent sequence. No N+1 patterns were found in the read paths
|
||||
sampled.
|
||||
|
||||
**Pydantic V2 & Settings.** Fully V2; no `@validator`, `class Config`, `.dict()`, or `parse_obj`
|
||||
anywhere. Evidence contracts use `ConfigDict(extra="forbid", frozen=True)` (`providers/evidence.py:47`),
|
||||
which is exactly right for persisted provenance — an unexpected field fails loudly rather than
|
||||
being silently dropped. `SecretStr` guards the API key. The discriminated
|
||||
`SqliteSettings | PostgresSettings` union is clean. `normalize_provider_models` correctly runs
|
||||
`mode="before"` so the derived tuple is produced by construction rather than by mutating a frozen
|
||||
model — a subtlety that is easy to get wrong. Sole issue: the cwd-coupled `env_file` (MED-03).
|
||||
|
||||
**Asyncio Workers.** Notably careful. `asyncio.shield` wraps both the per-page commit and the
|
||||
terminal commit (`workflows.py:601-614`, `650-663`), with the `except CancelledError: await task;
|
||||
raise` pattern that actually completes the shielded work rather than merely deferring cancellation —
|
||||
a detail most implementations get wrong. `handle_worker_exceptions` (`worker.py:157-182`)
|
||||
distinguishes retriable from non-retriable faults and stops the loop rather than spinning.
|
||||
`_advance_job_with_containment` (`worker.py`/`workflows.py:507-540`) guarantees a claimed job
|
||||
cannot strand in `PROCESSING`. `worker_consumer_lifespan` has a bounded shutdown with escalation to
|
||||
`cancel()`. Gaps are MED-04 and MED-05, both latent and both with stated unblocking conditions.
|
||||
|
||||
**OpenRouter / Adapter Boundary.** Encapsulation holds: `test_provider_boundaries.py` enforces it,
|
||||
and `workflows.py` imports only `providers` abstractions. `_CapturingAsyncClient` is a
|
||||
well-judged design — it captures the exact transport body before SDK parsing without altering what
|
||||
the SDK consumes, including the streamed case. Timeout construction (`openrouter.py:200-206`)
|
||||
correctly overrides httpx's 5s per-phase default that would otherwise silently cap the configured
|
||||
budget. `SAFE_RESPONSE_HEADERS` (`providers/evidence.py:29-41`) was reviewed field-by-field:
|
||||
all nine entries are non-secret correlation, content, or rate-limit headers, and
|
||||
`filter_safe_response_headers` is a true allowlist filter with no redaction-after-capture — this
|
||||
satisfies invariant 3.8.2 exactly. `_replace_embedded_media` correctly substitutes a source
|
||||
reference for base64 payloads, satisfying 3.8.3. The one structural weakness is MED-05.
|
||||
|
||||
**Testing & Quality Tooling.** 410 tests, all green, with genuinely strong contract guards
|
||||
(boundaries, model contract, media path safety, evidence append-only, atomicity). Marker strictness
|
||||
and `asyncio_mode = "strict"` are configured, and no unawaited-coroutine warnings appeared. Two
|
||||
guards, however, assert meaningfully less than their names and docstrings claim
|
||||
(`test_orphan_sweep.py` — MED-01; `test_errors.py` path-leak coverage — MED-07), and the
|
||||
`>= 420` snapshot threshold at `test_orphan_sweep.py:169` repeats a weak-assertion pattern the
|
||||
2026-08-23 review already flagged at `>= 200`; it was raised rather than replaced with
|
||||
set-membership.
|
||||
|
||||
---
|
||||
|
||||
## 7. Duplication & Consolidation Report
|
||||
|
||||
| Pattern / Duplication | Locations | Proposed Canonical Home | Estimated Lines Removed |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| `f"{type(exc).__name__}: {exc}"` detail construction | `errors.py:118`, `maintenance.py:71,95,135,206`, `runtime_settings_store.py:388,476,554` | `errors.py::exception_detail(exc)` | ~8 (consistency > line count) |
|
||||
| Filesystem `AppError` construction from `OSError` | `prompts.py:186-191`, `runtime_settings_store.py:384-389,472-477,550-555` | `errors.py::filesystem_error(message, exc, *, suggestion)` | ~20 |
|
||||
| Overlapping prompt error types | `services/errors.py:15`, `services/prompts.py:19` | `services/errors.py` (LOW-03) | ~5 |
|
||||
| Duplicated `provider_duration_ms` / `processing_duration_ms` max-clamp arithmetic | `workflows.py:341-345, 361-368, 397-404` | `workflows.py::_page_durations(started_at, finished_at, monotonic_started_at)` | ~20 |
|
||||
| `_utc_now_naive` defined per module | `workflows.py:51`, `jobs.py:29`, `db/models.py`, `sources.py` | Single helper in `db/models.py`, imported | ~12 |
|
||||
|
||||
### Proposed Canonical Abstractions
|
||||
|
||||
```python
|
||||
# src/transcription/errors.py
|
||||
def exception_detail(exc: BaseException) -> str:
|
||||
"""Internal-only root-cause text for AppError.detail. Never user-facing."""
|
||||
|
||||
|
||||
def filesystem_error[E: AppError](error_type: type[E], message: str, exc: OSError, *, suggestion: str) -> E:
|
||||
"""Build a filesystem AppError with a generic message and the path on detail."""
|
||||
|
||||
|
||||
# src/transcription/ui/components/error_presenter.py
|
||||
def display_failure_detail(error_detail: str | None) -> str | None:
|
||||
"""Sanitize persisted failure detail for UI rendering (HIGH-01)."""
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. Meta-Tooling & Instruction Update Recommendations
|
||||
|
||||
1. **`docs/invariant/ai_evidence_and_provenance.md:130`** — resolve the V4 label. Two viable
|
||||
routes, and the maintainer has proposed the second:
|
||||
- **(a) Repair the guard.** Fix the text to V6.1 and make
|
||||
`test_canonical_docs_declare_one_consistent_baseline` token-based rather than phrase-based
|
||||
(MED-02). Keeps version labels as navigational anchors.
|
||||
- **(b) Remove version labels from canonical docs.** While the project has a single principal
|
||||
user and no released versions to support, "canonical" and "current" are the same thing, so the
|
||||
label carries no information a reader can act on — it only creates a second thing to keep in
|
||||
sync. Retain the baseline declaration in `docs/index.md` alone as the release marker, keep
|
||||
version language in `docs/roadmap_plan.md` and the migration/deployment docs (already
|
||||
excluded from the scan for exactly this reason), and replace in-body references with
|
||||
unversioned phrasing ("the canonical architecture, schema, requirements, and error-policy
|
||||
documents"). The guard then inverts: assert that no canonical doc outside the exclusion set
|
||||
contains a version token at all, which is a stricter and much cheaper property to hold than
|
||||
agreement between many labels. Requirement IDs (`REQ-4-021`, `REQ-6-014`) are stable
|
||||
identifiers, not currency claims, and should be left alone.
|
||||
2. **`docs/error_handling.md:107-115`** — either add the sanitizing-projection rule for UI display
|
||||
of `error_detail`, or revise the `detail` "Surfaces" row to admit operator-facing evidence
|
||||
displays. Update the "Enforced by" line once MED-07's guard lands, since it currently overstates
|
||||
coverage.
|
||||
3. **`.github/instructions/error-handling.instructions.md`** — add an explicit clause under
|
||||
"User-Safe Messaging" stating that *persisted* `error_detail` is subject to the same no-paths
|
||||
rule at any render boundary. The current table (line 86) states the rule for `AppError.detail`
|
||||
and stops there, so the persisted-then-rendered path falls between the lines.
|
||||
4. **`.github/instructions/providers.instructions.md`** — record the adapter non-reentrancy
|
||||
constraint (MED-05); it is currently an undocumented precondition of `workflows.py`.
|
||||
5. **`.github/instructions/services.instructions.md`** — the two competing atomicity invariants are
|
||||
well described and both guards verified; no change needed. Worth adding the stale-reclaim
|
||||
threshold constraint (MED-04) alongside them, since it is a third worker-lifecycle rule with no
|
||||
documented home.
|
||||
6. **`tests/test_orphan_sweep.py`** — repair per MED-01 and replace the `>= 420` threshold with
|
||||
set-membership assertions.
|
||||
7. **New `tests/test_error_message_safety.py`** — AST guard per MED-07, covering both the raise
|
||||
sites and the UI render sites.
|
||||
8. **`docs/production-runbook.md`** — document the cwd/`WORKDIR` contract for `.env.production`
|
||||
resolution if MED-03 is resolved by documentation rather than by a code seam.
|
||||
|
||||
---
|
||||
|
||||
## 9. Prioritized Dependency-Ordered Action Plan
|
||||
|
||||
**Phase 1 — Blocking fixes (privacy; ordered, HIGH-01 first)**
|
||||
1. **HIGH-01** — add `display_failure_detail` and route `sources_page.py:484`,
|
||||
`table/sources.py:90-95`, and `settings_page.py:562` through it. Do this **first**: it closes
|
||||
the render boundary, so the Phase-1.2 fix cannot relocate a leak again.
|
||||
2. **HIGH-02** — move paths from `message` to `detail` at the five sites, including the
|
||||
`prompts.py:186` double violation.
|
||||
3. **MED-06** — move provider payload text to `detail`; add `detail=` to all three
|
||||
`handle_transcription_errors` handlers.
|
||||
|
||||
**Phase 2 — Enforcement hardening (make Phase 1 permanent)**
|
||||
4. **MED-07** — AST guard for raise-site `message` safety **and** for UI reads of `error_detail`.
|
||||
5. **MED-01** — qualify orphan definitions by module; add module-reachability; replace the
|
||||
snapshot threshold.
|
||||
6. **MED-02** — fix the V4/V6.1 text and extend the meta-contract guard to baseline-version currency.
|
||||
|
||||
**Phase 3 — Reliability & concurrency (latent; each must precede its unblocking change)**
|
||||
7. **MED-04** — derive `worker_stale_job_seconds` from `worker_provider_timeout_seconds` with a
|
||||
rejecting validator, ideally plus a progress heartbeat. **Must land before any second worker
|
||||
replica.**
|
||||
8. **MED-05** — scope provider evidence to the call rather than the instance. **Must land before
|
||||
any intra-job page concurrency.** Document non-reentrancy immediately as an interim step.
|
||||
|
||||
**Phase 4 — Consolidation & refactoring**
|
||||
9. **MED-03** — explicit env-file resolution seam shared by `Settings` and `runtime_settings_store`;
|
||||
remove the `model_config` monkeypatch from `conftest.py`.
|
||||
10. **LOW-01** — delete `tags_page.py` (after MED-01, so the suite reproduces the finding).
|
||||
11. **LOW-03** and the §7 consolidations — fold in opportunistically while Phase 1 touches these files.
|
||||
|
||||
**Phase 5 — Non-blocking governance/documentation depth**
|
||||
12. **LOW-02** — relocate or annotate `benchmarking.py`.
|
||||
13. Instruction/doc updates §8.3–§8.5, §8.8.
|
||||
|
||||
---
|
||||
|
||||
## 10. Preserved Strengths
|
||||
|
||||
- **Append-only evidence is real, not aspirational.** Every provider call produces a distinct
|
||||
`ExecutionAttempt`; no runtime path mutates a historical row. Projection writes onto
|
||||
`Source.raw_transcription` are clearly separated from history, and `promote_machine_attempt`
|
||||
(`evidence.py:117-146`) repoints the projection without rewriting evidence — with a docstring
|
||||
that explains exactly why that one write lives in a read-oriented service.
|
||||
- **Transport-layer terminology is honored in code.** `_CapturingAsyncClient` exists specifically so
|
||||
the stored body is the application-boundary capture rather than an SDK-parsed object, and
|
||||
`TransportEvidence(response_received=False)` explicitly represents "no response" instead of
|
||||
conflating it with an empty one. This is invariant 3.4/3.5 implemented rather than asserted.
|
||||
- **Header allowlisting is done the hard, correct way** — filter-before-store with an explicit
|
||||
frozenset, never capture-then-redact (`providers/evidence.py:29-41,130-134`).
|
||||
- **Boundaries are enforced by allowlist, not blocklist.** `test_ui_boundaries.py:20-25` states the
|
||||
reasoning explicitly; it means a newly added persistence helper cannot slip through under an
|
||||
unlisted name.
|
||||
- **The two competing atomicity invariants are both correctly implemented and both genuinely
|
||||
guarded**, with the tests structured so that the naive over-correction fails.
|
||||
- **Cancellation safety in the worker is unusually well handled** — `asyncio.shield` plus
|
||||
`await task` on `CancelledError` actually completes the commit rather than merely deferring
|
||||
cancellation.
|
||||
- **Comments explain rationale, not mechanics.** `workflows.py:269-271`, `openrouter.py:200-202`,
|
||||
`config.py:114-115`, and `jobs.py:191-197` each record *why* a non-obvious choice was made,
|
||||
several citing the review log entry that motivated it. This is what made verifying the atomicity
|
||||
and timeout invariants tractable in this review.
|
||||
- **Documentation-to-code traceability is strong overall.** Page contracts, schema field tables,
|
||||
and requirement IDs are maintained and guarded; the drift found in this review is narrow and
|
||||
specific rather than systemic.
|
||||
|
||||
---
|
||||
|
||||
## Appendix A — Repo-Specific Deterministic Checks
|
||||
|
||||
| # | Check | Result | Evidence |
|
||||
| :-- | :--- | :--- | :--- |
|
||||
| 1 | Service boundary rule: no service-to-service imports | **Pass** | `tests/test_service_boundaries.py` green; AST scan, allowlist-based; `workflows.py` composes via `ServiceBundle` |
|
||||
| 2 | UI boundary rule: no persistence access from pages/components | **Pass (structurally)** | `tests/test_ui_boundaries.py` green. Caveat: it guards *data access*, not presentation of internal-only fields — see HIGH-01 |
|
||||
| 3 | Status vocabulary conformance; no stringly-typed literals | **Pass** | `tests/test_model_contract_guards.py` green; enum members verified against `db/models.py` |
|
||||
| 4 | Evidence ownership: append-only history, projections not history mutation | **Pass** | `test_v42_evidence.py::test_attempts_are_append_only_and_exported_with_integrity` verified non-vacuous (asserts both retained attempts and export integrity at lines 281-290) |
|
||||
| 5 | Canonical authority: findings resolve against `docs/*` first | **Pass with defect** | `test_canonical_authority_references_are_present` green. The companion baseline-currency guard (`test_canonical_docs_declare_one_consistent_baseline`) scans the offending file but fails open on its phrasing and on minor-less version tokens — MED-02 |
|
||||
| 6 | Schema contract fidelity: `docs/schema.md` field-accurate | **Pass** | `test_model_contract_guards.py` + `test_meta_contract_guards.py` green |
|
||||
| 7 | Media boundary: record-validated media, controlled URL resolver | **Pass** | `test_media_path_safety.py`, `tests/ui/test_media_urls.py` green; `public_media_path_label` verified path-safe |
|
||||
| 8 | Eager-loading conformance vs `lazy="raise"` | **Pass** | Declaration-side guard green; sampled read paths declare explicit `selectinload` chains. Note: dead `tags_page.py:71-74` would violate it if re-registered (LOW-01) |
|
||||
| 9 | Cross-cutting error conformance | **FAIL** | Guards green but coverage is narrower than documented: HIGH-01, HIGH-02, MED-06, MED-07 |
|
||||
| 10 | Orphan/dead-code conformance | **FAIL** | Guard green but structurally unable to detect a dead module: MED-01, proven by LOW-01 |
|
||||
|
||||
## Appendix B — Evidence & Provenance Auditor Families
|
||||
|
||||
| Family | Subject | Result | Evidence |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| A | Attempt history append-only | **Pass** | No update/delete path to `ExecutionAttempt`; insert-only with `begin_nested` + bounded sequence retry (`sources.py:556-616`) |
|
||||
| B | Attempt numbering monotonic per source | **Pass** | `insert_with_sequence_retry`; uniqueness constraint plus retry on conflict |
|
||||
| C | Transport evidence captured at the transport boundary | **Pass** | `_CapturingAsyncClient` retains the exact wire body pre-SDK-parse (`openrouter.py:66-94`) |
|
||||
| D | Absent response distinguished from empty response | **Pass** | `TransportEvidence.response_received` is explicit, not inferred |
|
||||
| E | Response header persistence is allowlist-based | **Pass** | `SAFE_RESPONSE_HEADERS` (`providers/evidence.py:29-41`) — all nine entries verified non-secret; filter-before-store |
|
||||
| F | No machine-local detail on user-facing surfaces | **FAIL** | `error_detail` rendered verbatim at three UI sites (HIGH-01); paths in `message` at five sites (HIGH-02) |
|
||||
| G | Request manifest excludes embedded media payloads | **Pass** | `_replace_embedded_media` (`openrouter.py:377-395`) substitutes a source reference for base64 data |
|
||||
| H | Evidence attribution is correct under concurrency | **Pass today / at risk** | Correct in the current sequential single-worker deployment; the contract itself is non-reentrant (MED-05) and reclaim has no margin (MED-04) |
|
||||
@@ -1,21 +0,0 @@
|
||||
# Review Reports
|
||||
|
||||
Dated architecture and code review reports generated by
|
||||
`.github/skills/python-code-reviewer/skill.md`.
|
||||
|
||||
**These files are not canonical authority.** Everything in `docs/reviews/**` is a
|
||||
point-in-time observation, not a contract. Canonical intent lives in `docs/index.md`,
|
||||
`docs/architecture.md`, `docs/requirements.md`, `docs/schema.md`,
|
||||
`docs/error_handling.md`, and `docs/invariant/**`. When a report and a canonical
|
||||
document disagree, the canonical document wins until it is deliberately updated.
|
||||
|
||||
Naming: `<YYYY-MM-DD>-code-review.md` for review reports, and
|
||||
`<YYYY-MM-DD>-remediation-handoff.md` for the implementation plan derived from one.
|
||||
|
||||
## Current
|
||||
|
||||
- [`2026-08-23-code-review.md`](./2026-08-23-code-review.md) — full review. 0 critical,
|
||||
4 high, 5 medium, 11 low. **All findings remediated.** Retained as a record of the
|
||||
reasoning, not as a list of open work. Note that a few of its recommendations were
|
||||
wrong on contact and were corrected during implementation; the code and the guard
|
||||
tests are authoritative over the report text.
|
||||
@@ -1,210 +0,0 @@
|
||||
# Roadmap Plan (Starting at V6.0)
|
||||
|
||||
This roadmap starts at **V6.0** and tracks forward-looking work only.
|
||||
|
||||
## V6.0 - Hosting Migration
|
||||
|
||||
Objective: move from local-only operation to secure, stable remote hosting.
|
||||
Status: **Completed**
|
||||
|
||||
Detailed plan: [`v6_0_hosting_migration_plan.md`](v6_0_hosting_migration_plan.md)
|
||||
|
||||
### Scope
|
||||
1. Containerize app runtime for production deployment.
|
||||
2. Run PostgreSQL in Docker and migrate from SQLite.
|
||||
3. Add Cloudflare Tunnel exposure with Access protection.
|
||||
4. Add operational safeguards (health checks, restart policies, backups).
|
||||
|
||||
### Deliverables
|
||||
- Production-ready `docker-compose` deployment for app + database + tunnel.
|
||||
- Environment-based configuration for DB, uploads, prompts, and logging.
|
||||
- Verified data migration path into PostgreSQL.
|
||||
- Runbook updates for deploy, rollback, and backup/restore.
|
||||
|
||||
### Exit Criteria
|
||||
- `/healthz` reports healthy app and worker in deployed environment.
|
||||
- One end-to-end document -> source -> job workflow succeeds remotely.
|
||||
- Backup and restore procedure is tested.
|
||||
|
||||
### Accomplished
|
||||
1. Delivered production Docker deployment with split `app`/`worker`, `postgres`, and `cloudflared`.
|
||||
2. Landed SQLite -> PostgreSQL migration tooling and runbook coverage.
|
||||
3. Added production health/reliability wiring and operational runbooks for deploy/rollback/recovery.
|
||||
4. Established host-visible backup workflow and restore path for PostgreSQL plus media/config assets.
|
||||
|
||||
## V6.1 - Testing and Refinement
|
||||
|
||||
Objective: improve navigation and operational workflows after user feedback.
|
||||
Status: **Completed**
|
||||
|
||||
### Scope
|
||||
1. Make Document Detail the primary source-page workspace:
|
||||
- Use Source-style pan/zoom + previous/next page controls.
|
||||
- Move editable revision controls into Document Detail.
|
||||
- Move archival/system metadata to dedicated Document Info route.
|
||||
2. Simplify top navigation:
|
||||
- Remove top-level Tags and Sources entries.
|
||||
- Retire the Tags page and the global Source Asset Records entry flow.
|
||||
3. Improve list/detail clarity:
|
||||
- Add Document transcription status to Archival Documents list.
|
||||
- Add Document Date in People Detail -> Linked Documents table.
|
||||
4. Add worker-backed Settings maintenance runs:
|
||||
- Add `maintenance_run` persistence (`id`, `job_type`, `status`, `started_at`, `finished_at`, `triggered_by`, `summary`, `log_path`, `error_detail`).
|
||||
- Add Run Backup and Run Storage Reconciliation actions that enqueue runs and execute in the worker.
|
||||
- Add run history with status, duration, summary, and log view/download.
|
||||
- Defer daily/weekly scheduling controls to V6.2.
|
||||
|
||||
### Accomplished
|
||||
1. Refactored Document Detail into the primary source-page workspace (pan/zoom viewer, previous/next page navigation, editable revision flow) and moved archival/system metadata to Document Info.
|
||||
2. Simplified top navigation by removing Tags/Sources entries and retiring the Tags page/global Source Asset Records flow.
|
||||
3. Improved data clarity with document transcription status in Archival Documents and Document Date in People Detail linked documents.
|
||||
4. Implemented queue-backed maintenance operations (`maintenance_run` model/service/worker/UI) with run history and log view/download.
|
||||
5. Hardened runtime settings operations in production:
|
||||
- runtime settings writes target mounted `.env.production`,
|
||||
- fallback write path for single-file bind mounts,
|
||||
- explicit hidden/deployment-key disclosure in Settings UI.
|
||||
6. Simplified backup configuration and behavior:
|
||||
- standardized on `BACKUP_DIR` + `BACKUP_RETENTION_DAYS`,
|
||||
- backup script uses `DATABASE__*` persistence keys,
|
||||
- compose maps Postgres container init values from `DATABASE__*`,
|
||||
- env contract drift tests now guard `.env.production.example`.
|
||||
|
||||
## V6.2 - GEDCOM Data Layer
|
||||
|
||||
Objective: introduce a genealogical data layer sourced from GEDCOM exports, bridged to
|
||||
existing `Person` records via FamilySearch ID, without disrupting document-focused Person
|
||||
workflows.
|
||||
|
||||
### Scope
|
||||
1. Manual `.ged` file upload only. No FamilySearch credentials are stored or used by the
|
||||
app; the user runs the third-party `getmyancestors` tool themselves and uploads the
|
||||
resulting export.
|
||||
2. Four new tables: `genealogy_person`, `genealogy_family`, `genealogy_family_child`, and
|
||||
`genealogy_citation` (raw GEDCOM `SOUR` citations, reusable in a later version to record
|
||||
when a transcribed document itself becomes citation evidence for FamilySearch).
|
||||
3. Upsert-based import keyed on FamilySearch ID (`fs_id`) so repeat imports update existing
|
||||
records in place without breaking existing `Person.family_search_id` links or duplicating
|
||||
surrogate keys.
|
||||
4. Reuse the existing V6.1 worker-backed `maintenance_run` pattern for import runs (run
|
||||
history, status, summary, log view/download) rather than new infrastructure.
|
||||
|
||||
### Deliverables
|
||||
- GEDCOM parser/importer producing the four genealogy tables.
|
||||
- `MaintenanceJobType` entry for GEDCOM import with upsert semantics and a run summary
|
||||
(records added/updated).
|
||||
- Settings UI entry to upload a `.ged` file, trigger an import run, and view history.
|
||||
|
||||
### Exit Criteria
|
||||
- Importing the same `.ged` file twice does not duplicate or orphan data.
|
||||
- Existing `Person.family_search_id` values continue to resolve to the correct
|
||||
`genealogy_person` row after import.
|
||||
- Import run history is visible with status, duration, and summary, consistent with other
|
||||
maintenance runs.
|
||||
|
||||
## V6.3 - Reporting and Genealogy-Enriched Features
|
||||
|
||||
Objective: improve research value with person-centric outputs, grounded in both archival
|
||||
documents and the V6.2 genealogical data layer.
|
||||
|
||||
This version is broken into five sequential sub-versions because of real dependency
|
||||
ordering: entity linking must exist before GEDCOM data can be targeted per-person; the
|
||||
Facts/Events mechanism must exist before timelines or reconciliation have anything
|
||||
meaningful to consume.
|
||||
|
||||
### V6.3.1 - Manual Entity Linking
|
||||
|
||||
- Search/browse UI over `genealogy_person` to find and link a candidate match to an
|
||||
application `Person`, setting `family_search_id`. Linking is reversible (unlink).
|
||||
- Once linked, GEDCOM vitals display alongside the `Person` record without requiring any
|
||||
schema change to `Person`.
|
||||
|
||||
### V6.3.2 - Person Facts and Events
|
||||
|
||||
- New fact/event table capturing: person, fact type (birth/death/event/free-form), date
|
||||
(+raw), place, free-text description, and a link to the source document as evidence.
|
||||
- Manual tagging UI while reviewing a transcribed document: select a passage, choose the
|
||||
person and fact type, record the date/description.
|
||||
- One-time migration of existing `Person.birth_date`/`birth_date_raw`/`birth_place`/
|
||||
`death_date`/`death_date_raw`/`death_place` values into fact/event rows (tagged as
|
||||
legacy/no-document-evidence where no source document is known), followed by retiring those
|
||||
six columns from `Person`. Birth/death become Facts/Events like any other locally-known
|
||||
fact, for both linked and unlinked people. `Person` permanently keeps `last_name`,
|
||||
`given_names`, `biography`, `family_search_id`, `metadata_`, tags, photos, and document
|
||||
associations.
|
||||
|
||||
### V6.3.3 - Person Timelines
|
||||
|
||||
- Timeline query merging GEDCOM milestones (birth, marriage, children's births, death) for
|
||||
linked persons with locally recorded Facts/Events.
|
||||
- Timeline UI on Person Detail with clear ordering/filters; entries link back to their
|
||||
originating document or GEDCOM record.
|
||||
|
||||
### V6.3.4 - Reconciliation
|
||||
|
||||
- Compares Facts/Events (the real, document-evidenced local signal) against corresponding
|
||||
`genealogy_person` fields for linked persons.
|
||||
- Persisted reconciliation record: person, field, local value with evidence-document link,
|
||||
GEDCOM value, and status (open / submitted / dismissed).
|
||||
- Re-evaluated automatically as part of each GEDCOM import maintenance run: opens new
|
||||
discrepancies, auto-resolves ones where GEDCOM now matches, leaves others unchanged.
|
||||
- Reconciliation review UI functions as a manual to-do list for updating FamilySearch; the
|
||||
app does not write back to FamilySearch itself.
|
||||
|
||||
### V6.3.5 - AI-Assisted Biography Generation
|
||||
|
||||
- Prompted narrative generation grounded in GEDCOM facts, Facts/Events, and relevant
|
||||
document snippets as structured input, using existing evidence-safe prompting patterns.
|
||||
- Output cites back to source documents and FamilySearch records.
|
||||
- Saved/printable report presentation for review; reports do not modify archival source
|
||||
data.
|
||||
|
||||
### Exit Criteria (applies across V6.3.1-V6.3.5)
|
||||
- Entity links are reversible and do not alter document associations.
|
||||
- Timelines are reproducible from persisted records.
|
||||
- Reconciliation items always carry a link to the document evidence justifying the local
|
||||
value, and re-running GEDCOM import correctly opens, resolves, or leaves items unchanged.
|
||||
- Narrative generation is traceable to source records and prompts.
|
||||
- Reports can be reviewed without modifying archival source data.
|
||||
|
||||
## V6.4 - Access Control and Multi-User Readiness
|
||||
|
||||
[ *More thoughts on user accounts:*
|
||||
* *Create a generic "view only" user that does not have the rights to alter any of the data*
|
||||
* *Limit user accounts access to data by Tag. I have distant family members that I would want to share the transcribed data with, but they would only be interested in a subset of it. For example my Cochran cousins would have no interest in Lancaster documents, so limit the Cochra Clan cousins to view-only access to documents tagged "cochran clan"* ]
|
||||
|
||||
Objective: prepare for managed collaboration beyond single-user operation.
|
||||
|
||||
### Scope
|
||||
1. Introduce application-level authentication.
|
||||
2. Add role-based authorization (admin/editor/contributor/viewer).
|
||||
3. Add audit visibility for user-attributed write actions.
|
||||
|
||||
### Deliverables
|
||||
- User identity model and login/session flow.
|
||||
- Route/page/service authorization enforcement.
|
||||
- Audit metadata for sensitive create/update/delete workflows.
|
||||
|
||||
### Exit Criteria
|
||||
- Unauthorized operations are blocked consistently across UI/API.
|
||||
- Role policies are enforced by deterministic tests.
|
||||
- User-attributed changes are visible for audit/review.
|
||||
|
||||
## Deferred / Future Ideas (not committed scope)
|
||||
|
||||
Captured for later consideration, not yet scheduled to a version:
|
||||
* AI-assisted entity disambiguation (kinship co-occurrence, chronological plausibility
|
||||
filtering) when linking document mentions to people.
|
||||
* Kinship-aware `@mention` tagging while transcribing.
|
||||
* Relationship-calculator badges (e.g., "3rd Great-Grandmother") in the document viewer.
|
||||
* Interactive migration/geography mapping from GEDCOM and document place mentions.
|
||||
* AI-suggested document discovery by date/location overlap with known persons.
|
||||
* Ability to search within a document to find potential people to add to the People table.
|
||||
|
||||
## Planning Notes
|
||||
|
||||
- Keep architecture, schema, and UI contracts synchronized in `docs/` as each version lands.
|
||||
- Prefer explicit schema migration over runtime compatibility write paths.
|
||||
- Preserve evidence/provenance guarantees when adding new AI-powered features.
|
||||
- GEDCOM/FamilySearch data is external, collaborative, and mutable; treat it as a managed
|
||||
cache bridged via `fs_id`, never as a replacement for archival evidence recorded from
|
||||
transcribed documents.
|
||||
-391
@@ -1,391 +0,0 @@
|
||||
# Data Model and Persistence Schema (Current Baseline: V6.1)
|
||||
|
||||
This document is the field-accurate V6.1 schema contract aligned to `src/transcription/db/models.py`.
|
||||
|
||||
## Source of Truth Anchors
|
||||
|
||||
- `src/transcription/db/models.py` (status and purpose enums, including maintenance lifecycle enums)
|
||||
- `src/transcription/db/models.py:80-120` (`DocumentType`, `PersonRole`)
|
||||
- `src/transcription/db/models.py:122-172` (`Tag`, `Document`)
|
||||
- `src/transcription/db/models.py` (`Person`, `GenealogyPerson`, `GenealogyFamily`, `GenealogyFamilyChild`, `GenealogyCitation`)
|
||||
- `src/transcription/db/models.py` (`Photo`, `DocumentPerson`, `DocumentTag`)
|
||||
- `src/transcription/db/models.py:285-347` (`Job`)
|
||||
- `src/transcription/db/models.py` (`MaintenanceRun`)
|
||||
- `src/transcription/db/models.py:350-462` (`Source`, `JobSource`)
|
||||
- `src/transcription/db/models.py:465-522` (`ExecutionAttempt`)
|
||||
|
||||
## Entity Relationship Overview
|
||||
|
||||
```mermaid
|
||||
erDiagram
|
||||
DocumentType ||--o{ Document : classifies
|
||||
Document ||--o{ Job : has
|
||||
Document ||--o{ Source : has
|
||||
Document ||--o{ DocumentPerson : links
|
||||
Document ||--o{ DocumentTag : tagged
|
||||
Person ||--o{ DocumentPerson : links
|
||||
Person ||--o{ PersonTag : tagged
|
||||
Person ||--o{ Photo : owns
|
||||
GenealogyPerson ||--o{ GenealogyFamily : husband
|
||||
GenealogyPerson ||--o{ GenealogyFamily : wife
|
||||
GenealogyPerson ||--o{ GenealogyFamilyChild : child
|
||||
GenealogyFamily ||--o{ GenealogyFamilyChild : includes
|
||||
GenealogyPerson ||--o{ GenealogyCitation : cited
|
||||
GenealogyFamily ||--o{ GenealogyCitation : cited
|
||||
Document ||--o{ GenealogyCitation : evidence
|
||||
PersonRole ||--o{ DocumentPerson : labels
|
||||
Tag ||--o{ DocumentTag : labels
|
||||
Tag ||--o{ PersonTag : labels
|
||||
Job ||--o{ JobSource : includes
|
||||
Source ||--o{ JobSource : participates
|
||||
JobSource ||--o{ ExecutionAttempt : attempts
|
||||
MaintenanceRun {
|
||||
uuid id PK
|
||||
}
|
||||
```
|
||||
|
||||
## Authoritative Enumerations
|
||||
|
||||
### JobStatus
|
||||
|
||||
- `queued`
|
||||
- `processing`
|
||||
- `transcribed`
|
||||
- `partial_success`
|
||||
- `failed`
|
||||
|
||||
### JobSourceStatus
|
||||
|
||||
- `pending`
|
||||
- `transcribed`
|
||||
- `failed`
|
||||
- `cancelled`
|
||||
|
||||
### JobPurpose
|
||||
|
||||
- `transcription`
|
||||
- `retranscription`
|
||||
|
||||
### MaintenanceJobType
|
||||
|
||||
- `backup`
|
||||
- `storage_reconciliation`
|
||||
- `gedcom_import`
|
||||
|
||||
### MaintenanceRunStatus
|
||||
|
||||
- `queued`
|
||||
- `processing`
|
||||
- `succeeded`
|
||||
- `failed`
|
||||
|
||||
## Field-Accurate Table Contracts
|
||||
|
||||
### `DocumentType`
|
||||
|
||||
| Field | Type | Notes |
|
||||
| :--- | :--- | :--- |
|
||||
| `id` | `UUID` | PK |
|
||||
| `semantic_key` | `str \| None` | nullable unique, indexed |
|
||||
| `label` | `str` | required |
|
||||
| `normalized_label` | `str` | unique, indexed |
|
||||
| `is_active` | `bool` | default `True` |
|
||||
| `created_at` | `datetime` | default now |
|
||||
| `updated_at` | `datetime` | default now, onupdate |
|
||||
|
||||
### `PersonRole`
|
||||
|
||||
| Field | Type | Notes |
|
||||
| :--- | :--- | :--- |
|
||||
| `id` | `UUID` | PK |
|
||||
| `semantic_key` | `str \| None` | nullable unique, indexed |
|
||||
| `label` | `str` | required |
|
||||
| `normalized_label` | `str` | unique, indexed |
|
||||
| `is_active` | `bool` | default `True` |
|
||||
| `created_at` | `datetime` | default now |
|
||||
| `updated_at` | `datetime` | default now, onupdate |
|
||||
|
||||
### `Tag`
|
||||
|
||||
| Field | Type | Notes |
|
||||
| :--- | :--- | :--- |
|
||||
| `id` | `UUID` | PK |
|
||||
| `semantic_key` | `str \| None` | nullable unique, indexed |
|
||||
| `label` | `str` | required |
|
||||
| `normalized_label` | `str` | unique, indexed |
|
||||
| `is_active` | `bool` | default `True` |
|
||||
| `created_at` | `datetime` | default now |
|
||||
| `updated_at` | `datetime` | default now, onupdate |
|
||||
|
||||
### `Document`
|
||||
|
||||
| Field | Type | Notes |
|
||||
| :--- | :--- | :--- |
|
||||
| `id` | `UUID` | PK |
|
||||
| `name` | `str` | required |
|
||||
| `document_type_id` | `UUID \| None` | FK -> `document_type.id`, indexed |
|
||||
| `document_date` | `date \| None` | optional |
|
||||
| `document_date_raw` | `str \| None` | optional |
|
||||
| `location_created` | `str \| None` | optional |
|
||||
| `notes` | `str \| None` | optional |
|
||||
| `archive_identifier` | `str \| None` | optional |
|
||||
| `created_at` | `datetime` | default now |
|
||||
| `updated_at` | `datetime` | default now, onupdate |
|
||||
|
||||
### `Person`
|
||||
|
||||
| Field | Type | Notes |
|
||||
| :--- | :--- | :--- |
|
||||
| `id` | `UUID` | PK |
|
||||
| `last_name` | `str` | required |
|
||||
| `given_names` | `str` | required |
|
||||
| `birth_date` | `date \| None` | optional |
|
||||
| `birth_date_raw` | `str \| None` | optional |
|
||||
| `birth_place` | `str \| None` | optional |
|
||||
| `death_date` | `date \| None` | optional |
|
||||
| `death_date_raw` | `str \| None` | optional |
|
||||
| `death_place` | `str \| None` | optional |
|
||||
| `biography` | `str \| None` | optional |
|
||||
| `family_search_id` | `str \| None` | nullable unique |
|
||||
| `metadata_` | `dict[str, JsonValue] \| None` | stored as DB column `metadata` (`JSONBCompat`) |
|
||||
| `created_at` | `datetime` | default now |
|
||||
| `updated_at` | `datetime` | default now, onupdate |
|
||||
|
||||
### `GenealogyPerson`
|
||||
|
||||
| Field | Type | Notes |
|
||||
| :--- | :--- | :--- |
|
||||
| `id` | `UUID` | PK |
|
||||
| `fs_id` | `str` | unique, indexed FamilySearch identifier |
|
||||
| `full_name` | `str` | required |
|
||||
| `birth_date` | `date \| None` | optional |
|
||||
| `birth_date_raw` | `str \| None` | optional |
|
||||
| `birth_place` | `str \| None` | optional |
|
||||
| `death_date` | `date \| None` | optional |
|
||||
| `death_date_raw` | `str \| None` | optional |
|
||||
| `death_place` | `str \| None` | optional |
|
||||
| `created_at` | `datetime` | default now |
|
||||
| `updated_at` | `datetime` | default now, onupdate |
|
||||
|
||||
### `GenealogyFamily`
|
||||
|
||||
| Field | Type | Notes |
|
||||
| :--- | :--- | :--- |
|
||||
| `id` | `UUID` | PK |
|
||||
| `fs_family_id` | `str` | unique, indexed FamilySearch family identifier |
|
||||
| `husband_id` | `UUID \| None` | nullable FK -> `genealogy_person.id`, indexed |
|
||||
| `wife_id` | `UUID \| None` | nullable FK -> `genealogy_person.id`, indexed |
|
||||
| `marriage_date` | `date \| None` | optional |
|
||||
| `marriage_date_raw` | `str \| None` | optional |
|
||||
| `marriage_place` | `str \| None` | optional |
|
||||
| `created_at` | `datetime` | default now |
|
||||
| `updated_at` | `datetime` | default now, onupdate |
|
||||
|
||||
### `GenealogyFamilyChild`
|
||||
|
||||
| Field | Type | Notes |
|
||||
| :--- | :--- | :--- |
|
||||
| `id` | `UUID` | PK |
|
||||
| `family_id` | `UUID` | FK -> `genealogy_family.id`, indexed |
|
||||
| `child_id` | `UUID` | FK -> `genealogy_person.id`, indexed |
|
||||
| `relationship_type` | `str \| None` | optional |
|
||||
| `created_at` | `datetime` | default now |
|
||||
|
||||
Constraint:
|
||||
- `UniqueConstraint(family_id, child_id)` named `uq_genealogy_family_child`
|
||||
|
||||
### `GenealogyCitation`
|
||||
|
||||
| Field | Type | Notes |
|
||||
| :--- | :--- | :--- |
|
||||
| `id` | `UUID` | PK |
|
||||
| `genealogy_person_id` | `UUID \| None` | nullable FK -> `genealogy_person.id`, indexed |
|
||||
| `genealogy_family_id` | `UUID \| None` | nullable FK -> `genealogy_family.id`, indexed |
|
||||
| `fact_type` | `GenealogyCitationFactType` | enum: `birth`, `death`, `marriage`, `other` |
|
||||
| `raw_citation_text` | `str` | required raw GEDCOM citation text |
|
||||
| `source_kind` | `GenealogyCitationSourceKind` | enum: `familysearch_imported`, `transcription_evidence` |
|
||||
| `document_id` | `UUID \| None` | nullable FK -> `document.id`, indexed |
|
||||
| `created_at` | `datetime` | default now |
|
||||
|
||||
### `Photo`
|
||||
|
||||
| Field | Type | Notes |
|
||||
| :--- | :--- | :--- |
|
||||
| `id` | `UUID` | PK |
|
||||
| `person_id` | `UUID \| None` | nullable FK -> `person.id`, indexed (`NULL` = homepage photo) |
|
||||
| `path` | `str` | required upload-root-relative POSIX path (`photos/...`) |
|
||||
| `description` | `str \| None` | optional |
|
||||
| `is_primary` | `bool` | default `False`; owner-level "featured/primary" marker |
|
||||
| `created_at` | `datetime` | default now |
|
||||
| `updated_at` | `datetime` | default now, onupdate |
|
||||
|
||||
### `DocumentPerson`
|
||||
|
||||
| Field | Type | Notes |
|
||||
| :--- | :--- | :--- |
|
||||
| `id` | `UUID` | PK |
|
||||
| `document_id` | `UUID` | FK -> `document.id`, indexed |
|
||||
| `person_id` | `UUID` | FK -> `person.id`, indexed |
|
||||
| `role_id` | `UUID` | FK -> `person_role.id`, indexed |
|
||||
| `created_at` | `datetime` | default now |
|
||||
| `updated_at` | `datetime` | default now, onupdate |
|
||||
|
||||
Constraint:
|
||||
- `UniqueConstraint(document_id, person_id)` named `uq_document_person`
|
||||
|
||||
### `DocumentTag`
|
||||
|
||||
| Field | Type | Notes |
|
||||
| :--- | :--- | :--- |
|
||||
| `id` | `UUID` | PK |
|
||||
| `document_id` | `UUID` | FK -> `document.id`, indexed |
|
||||
| `tag_id` | `UUID` | FK -> `tag.id`, indexed |
|
||||
| `created_at` | `datetime` | default now |
|
||||
| `updated_at` | `datetime` | default now, onupdate |
|
||||
|
||||
Constraint:
|
||||
- `UniqueConstraint(document_id, tag_id)` named `uq_document_tag`
|
||||
|
||||
### `PersonTag`
|
||||
|
||||
| Field | Type | Notes |
|
||||
| :--- | :--- | :--- |
|
||||
| `id` | `UUID` | PK |
|
||||
| `person_id` | `UUID` | FK -> `person.id`, indexed |
|
||||
| `tag_id` | `UUID` | FK -> `tag.id`, indexed |
|
||||
| `created_at` | `datetime` | default now |
|
||||
| `updated_at` | `datetime` | default now, onupdate |
|
||||
|
||||
Constraint:
|
||||
- `UniqueConstraint(person_id, tag_id)` named `uq_person_tag`
|
||||
|
||||
### `Job`
|
||||
|
||||
| Field | Type | Notes |
|
||||
| :--- | :--- | :--- |
|
||||
| `id` | `UUID` | PK |
|
||||
| `document_id` | `UUID` | FK -> `document.id`, indexed |
|
||||
| `status` | `JobStatus` | non-null enum (stored as enum values) |
|
||||
| `retry_count` | `int` | default `0`, `ge=0` |
|
||||
| `purpose` | `JobPurpose` | non-null enum, default `transcription` |
|
||||
| `date_created` | `datetime` | default now |
|
||||
| `date_updated` | `datetime` | default now, onupdate |
|
||||
| `provider` | `str \| None` | optional |
|
||||
| `model` | `str \| None` | optional |
|
||||
| `prompt_name` | `str \| None` | optional |
|
||||
| `prompt_hash` | `str \| None` | optional |
|
||||
| `system_prompt` | `str \| None` | optional |
|
||||
| `user_prompt` | `str \| None` | optional |
|
||||
| `temperature` | `float \| None` | optional |
|
||||
| `top_p` | `float \| None` | optional |
|
||||
|
||||
Index:
|
||||
- `Index("ix_job_status_date_created", "status", "date_created")`
|
||||
|
||||
### `MaintenanceRun`
|
||||
|
||||
| Field | Type | Notes |
|
||||
| :--- | :--- | :--- |
|
||||
| `id` | `UUID` | PK |
|
||||
| `job_type` | `MaintenanceJobType` | non-null enum |
|
||||
| `status` | `MaintenanceRunStatus` | non-null enum, default `queued` |
|
||||
| `started_at` | `datetime \| None` | optional |
|
||||
| `finished_at` | `datetime \| None` | optional |
|
||||
| `triggered_by` | `str \| None` | optional |
|
||||
| `summary` | `str \| None` | optional |
|
||||
| `log_path` | `str \| None` | optional, log-root-relative POSIX path |
|
||||
| `error_detail` | `str \| None` | optional internal failure detail |
|
||||
| `created_at` | `datetime` | default now |
|
||||
| `updated_at` | `datetime` | default now, onupdate |
|
||||
|
||||
### `Source`
|
||||
|
||||
| Field | Type | Notes |
|
||||
| :--- | :--- | :--- |
|
||||
| `id` | `UUID` | PK |
|
||||
| `document_id` | `UUID` | FK -> `document.id`, indexed |
|
||||
| `page_number` | `int` | default `1`, `ge=1` |
|
||||
| `upload_name` | `str` | required |
|
||||
| `filename` | `str` | required |
|
||||
| `file_path` | `str` | required upload-root-relative POSIX path (`documents/...`) |
|
||||
| `file_hash` | `str` | required |
|
||||
| `file_size_bytes` | `int` | `BigInteger`, non-null |
|
||||
| `raw_transcription` | `str \| None` | projection field |
|
||||
| `preferred_execution_attempt_id` | `UUID \| None` | nullable FK -> `execution_attempt.id`, indexed (`use_alter`) |
|
||||
| `revised_text` | `str \| None` | optional human revision |
|
||||
| `date_uploaded` | `datetime` | default now |
|
||||
| `date_revised` | `datetime \| None` | optional |
|
||||
|
||||
### `JobSource`
|
||||
|
||||
| Field | Type | Notes |
|
||||
| :--- | :--- | :--- |
|
||||
| `id` | `UUID` | PK |
|
||||
| `job_id` | `UUID` | FK -> `job.id`, indexed |
|
||||
| `source_id` | `UUID` | FK -> `source.id`, indexed |
|
||||
| `status` | `JobSourceStatus` | non-null enum, default `pending` |
|
||||
|
||||
Constraint:
|
||||
- `UniqueConstraint(job_id, source_id)` named `uq_job_source_job_source`
|
||||
|
||||
Runtime reconciliation:
|
||||
- Startup database operations remove retired V4.6 `job_source` evidence columns (`raw_transcription`, `ai_metadata`, `raw_api_response`, `error_detail`, `executed_at`) when present so persisted schema matches this contract.
|
||||
|
||||
### `ExecutionAttempt`
|
||||
|
||||
| Field | Type | Notes |
|
||||
| :--- | :--- | :--- |
|
||||
| `id` | `UUID` | PK |
|
||||
| `job_source_id` | `UUID` | FK -> `job_source.id`, indexed |
|
||||
| `job_id` | `UUID` | FK -> `job.id`, indexed |
|
||||
| `source_id` | `UUID` | FK -> `source.id`, indexed |
|
||||
| `attempt_number` | `int` | `ge=1` |
|
||||
| `status` | `JobSourceStatus` | non-null enum, value-stable with `JobSource.status` |
|
||||
| `provider` | `str` | required |
|
||||
| `model` | `str \| None` | optional |
|
||||
| `request_manifest` | `dict[str, JsonValue] \| None` | JSONBCompat |
|
||||
| `request_manifest_sha256` | `str \| None` | optional |
|
||||
| `request_manifest_schema_version` | `str \| None` | optional |
|
||||
| `response_received` | `bool` | default `False` |
|
||||
| `transport_status_code` | `int \| None` | optional |
|
||||
| `transport_body` | `bytes \| None` | LargeBinary |
|
||||
| `transport_content_type` | `str \| None` | optional |
|
||||
| `transport_content_encoding` | `str \| None` | optional |
|
||||
| `transport_safe_headers` | `dict[str, JsonValue] \| None` | JSONBCompat |
|
||||
| `router_request_id` | `str \| None` | optional |
|
||||
| `router_generation_id` | `str \| None` | optional |
|
||||
| `sdk_response_snapshot` | `dict[str, JsonValue] \| None` | JSONBCompat |
|
||||
| `normalized_metadata` | `dict[str, JsonValue] \| None` | JSONBCompat; may include app-namespaced `processing_timing` (`provider_call_duration_ms`, `processing_duration_ms`) |
|
||||
| `software_context` | `dict[str, JsonValue] \| None` | JSONBCompat |
|
||||
| `raw_transcription` | `str \| None` | optional |
|
||||
| `error_category` | `str \| None` | optional |
|
||||
| `error_detail` | `str \| None` | optional |
|
||||
| `failure_phase` | `str \| None` | optional |
|
||||
| `started_at` | `datetime` | required |
|
||||
| `finished_at` | `datetime` | required |
|
||||
| `duration_ms` | `int` | `ge=0` |
|
||||
| `created_at` | `datetime` | default now |
|
||||
|
||||
Constraint:
|
||||
- `UniqueConstraint(job_id, source_id, attempt_number)` named `uq_execution_attempt_number`
|
||||
|
||||
## Relationship Loading Contract
|
||||
|
||||
- Most ORM relationships are configured with `lazy="raise"`.
|
||||
- `JobSource.execution_attempts` is intentionally `lazy="noload"` with ordered attempts.
|
||||
- Service/UI read paths must explicitly eager-load required relationships before access.
|
||||
|
||||
## Persistence Invariants (Ground Truth)
|
||||
|
||||
1. `ExecutionAttempt` is append-only runtime evidence.
|
||||
2. `JobSource.status` represents queue/projection execution state and is not a full evidence container.
|
||||
3. `Source.raw_transcription` is a mutable projection and not authoritative attempt history.
|
||||
4. `Job` terminal status derives from page outcomes (`JobSource` state), not from a separate summary table.
|
||||
5. `DocumentType.semantic_key` and `PersonRole.semantic_key` are nullable-unique semantic identifiers.
|
||||
|
||||
## Cross-Reference
|
||||
|
||||
- [System Architecture](architecture.md)
|
||||
- [System Requirements](requirements.md)
|
||||
- [Error Handling Policy](error_handling.md)
|
||||
- [AI Evidence and Provenance Invariant](./invariant/ai_evidence_and_provenance.md)
|
||||
@@ -1,60 +0,0 @@
|
||||
# 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)
|
||||
- [Settings](pages/settings.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 [schema contract](../schema.md).
|
||||
7. 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 current V6.1 baseline.
|
||||
@@ -1,150 +0,0 @@
|
||||
# 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}/info` | View archival metadata and system logistics for one Document. |
|
||||
| `/documents/{document_id}/edit` | Edit metadata and the complete Linked People set. |
|
||||
| `/documents/{document_id}/delete` | Confirm or block deletion. |
|
||||
| `/documents/{document_id}/jobs` | Show Jobs belonging to the Document. |
|
||||
| `/documents/{document_id}/sources` | Source-image gallery for the Document. |
|
||||
| `/documents/{document_id}/print` | Preview and browser-print the persisted Document. |
|
||||
|
||||
## 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, Author, Tags, Document Date, Type, # Sources, and Transcription Status.
|
||||
- Document Title is left-aligned; the remaining columns are centered.
|
||||
- Author lists all linked people in the `author` role.
|
||||
- # Sources reflects the count of linked Source rows for each Document.
|
||||
- Transcription Status reflects the most recent Job status for that Document; documents with no Jobs show a blank marker.
|
||||
- Date display prefers exact date, then approximate date, then `Unknown`.
|
||||
- Selecting a row opens Document Detail.
|
||||
- Row navigation includes list context so Document Detail provides **Back to Documents**.
|
||||
- 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.
|
||||
- Tags.
|
||||
- Linked People, with exactly one Person Role per linked Person.
|
||||
|
||||
Rules:
|
||||
|
||||
- Exact date must parse as `YYYY-MM-DD`; browser presentation may follow locale.
|
||||
- The exact-date input is labeled **Document date**.
|
||||
- Existing people appear with disambiguating labels.
|
||||
- Tag assignment supports selecting existing tags and adding new labels inline.
|
||||
- **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.
|
||||
- One Linked People table contains Select, Person, and Role columns.
|
||||
- Add and Edit use an inline Person/Role editor; Save, Cancel, and Delete change staged UI state only.
|
||||
- A Person may appear once per Document regardless of role.
|
||||
- Existing inactive-role links remain visible; only active roles may be newly assigned.
|
||||
- Document fields and the complete staged link set commit atomically on the main save.
|
||||
- Save success returns to Document Detail.
|
||||
|
||||
## Detail Behavior
|
||||
|
||||
- The heading shows name, type, and internal ID.
|
||||
- The header includes a contextual back action: **Back to Documents** by default, **Back to Person** when opened from Person Detail, and **Back to Job** when opened from Job Detail.
|
||||
- The detail workspace shows a Source-style pan/zoom media viewer with **Previous Page** / **Next Page** navigation for document source pages.
|
||||
- The center column is **Editable Revision** for the active source page.
|
||||
- Related People are grouped by role and link to Person Detail.
|
||||
- **Source Pages & Transcriptions** shows source/job counts and actions for source-image gallery, document jobs, and adding a Job.
|
||||
- **Edit Document**, **Print**, **Document Details**, **View Source Detail**, and **Delete** are available from the header.
|
||||
- Invalid IDs and missing Documents produce explicit states without rendering a partial page.
|
||||
|
||||
## Document Source Images Behavior
|
||||
|
||||
- `/documents/{document_id}/sources` shows the current Document's source pages in a thumbnail gallery.
|
||||
- Each card shows the page number, stored filename, and an **Open Source Detail** action.
|
||||
- The page includes a **Back to Document** action.
|
||||
- No source pages displays an explicit empty state.
|
||||
|
||||
## Document Info Behavior
|
||||
|
||||
- `/documents/{document_id}/info` contains **Archival Metadata** and **System Logistics**.
|
||||
- It includes a **Back to Document** action.
|
||||
- Archival metadata includes authors, document type, tags, document date, location (linked when present), archive identifier, and notes.
|
||||
|
||||
## Print Behavior
|
||||
|
||||
- Print opens a dedicated preview for persisted Document data.
|
||||
- **Facsimile** places each Source image beside its current transcription and starts every Source on a new printed sheet.
|
||||
- **Text only** omits images, joins single line breaks inside paragraphs, and preserves blank-line paragraph boundaries.
|
||||
- Non-null revised text takes precedence over raw transcription, including an intentionally empty revision.
|
||||
- Archival metadata resolves Author through the hidden built-in semantic identity, not its mutable label.
|
||||
- Archival metadata includes the Document Type label.
|
||||
- Metadata tables use a narrow non-wrapping label column and wider wrapping data columns rather than stretching across the page.
|
||||
- Job metadata uses one oldest-to-newest column per Job and ends with Status.
|
||||
- Stored text is escaped and Source media uses record-validated application URLs rather than local file paths.
|
||||
- Printing uses the browser print dialog; server-generated PDFs are not provided.
|
||||
|
||||
## 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.
|
||||
- Linked People staging enforces one role and one row per Person.
|
||||
- Document and Linked People writes never partially commit.
|
||||
- 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.
|
||||
- Both print formats preserve the frozen content, ordering, text-precedence, and safety contracts.
|
||||
- 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`
|
||||
- `src/transcription/services/workflows.py`
|
||||
- `src/transcription/ui/components/linked_people.py`
|
||||
- `src/transcription/ui/pages/print_preview_page.py`
|
||||
- `src/transcription/api/print_api.py`
|
||||
- `tests/ui/test_documents_page.py`
|
||||
- `tests/services/test_document_service.py`
|
||||
|
||||
## Known Limitations and Deferred Work
|
||||
|
||||
- Source page ordering remains read-only.
|
||||
- Printing other entities, batch printing, and server-side export formats are deferred.
|
||||
@@ -1,64 +0,0 @@
|
||||
# Home Page Contract
|
||||
|
||||
## Purpose
|
||||
|
||||
Home provides a user-maintained landing page for the local archive. It combines a database-backed image gallery 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 homepage gallery and Markdown. |
|
||||
| `/homepage/edit` | `/ui/homepage/edit` | Upload images, manage image metadata, 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 featured homepage image (`photo.is_primary`) is shown first; remaining images are shown in random order.
|
||||
- The current image appears in the shared dark-room viewer with its description.
|
||||
- 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.
|
||||
- The same Home Text content is also editable from **Settings → Home Page Text**.
|
||||
|
||||
## Edit Behavior
|
||||
|
||||
- The image upload accepts JPEG, PNG, GIF, WebP, BMP, and TIFF files and supports multi-file uploads.
|
||||
- A successful upload immediately stores files in the shared `photo` table/media layout and displays a positive notification.
|
||||
- The editor supports per-image description edits, setting a featured image, and deleting the current image.
|
||||
- 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 markdown text is mutable application data at `UPLOAD_DIR/homepage.md`.
|
||||
- Homepage images are stored as `photo` rows (`person_id = NULL`) with files under `UPLOAD_DIR/photos/`.
|
||||
- Uploaded images are renamed to `{photo_id}{suffix}`.
|
||||
- Homepage images are database records; markdown remains file-backed.
|
||||
|
||||
## Acceptance Checklist
|
||||
|
||||
- `/`, `/ui`, and the application brand reach Home.
|
||||
- Home renders with or without stored Markdown and image content.
|
||||
- Edit loads existing Markdown.
|
||||
- Supported image upload stores one or more images and makes the first image featured when no featured image exists yet.
|
||||
- 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 markdown storage location is `UPLOAD_DIR/homepage.md` and must remain writable in the active runtime environment.
|
||||
- Uploading an image is immediate and is not rolled back by Cancel.
|
||||
@@ -1,99 +0,0 @@
|
||||
# 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, Document Name, # Sources, Retries, and Updated.
|
||||
- Updated is the primary date/sort field.
|
||||
- Search covers Job ID, document name, and status.
|
||||
- Status is displayed as a semantic status chip.
|
||||
- Selecting a row opens Job Detail.
|
||||
- Global Job-list row navigation includes list context so Job Detail provides **Back to Jobs**.
|
||||
- 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 selectable when creating a new Job.
|
||||
- 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.
|
||||
- When opened with `source_id`, creation becomes a retranscription flow: Source and Document are locked, Provider is
|
||||
read-only, Model is restricted to `PROVIDER_MODELS`, no upload is accepted, and one existing Source is linked.
|
||||
|
||||
## Detail and Lifecycle Behavior
|
||||
|
||||
- The heading shows Job ID and a status badge.
|
||||
- Job Detail includes a contextual back action: **Back to Jobs** by default and **Back to Document** when opened from a Document-filtered Job list.
|
||||
- Execution Logistics shows provider, model, prompt, retry count, and last update.
|
||||
- Document Links show a clickable Document Name (with Job context), Sources count, and a single **View Sources** action using job filtering.
|
||||
- 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 pending Sources become cancelled.
|
||||
- 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 selected `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`
|
||||
@@ -1,106 +0,0 @@
|
||||
# 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 one or more photos plus a 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}/photos` | Manage Person photos. |
|
||||
| `/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 Name order (`Last Name, First & Middle`) and supports search and column sorting.
|
||||
- Columns are Last Name, First & Middle; Tags; FamilySearch ID; Birth Date; Death Date; and # Documents.
|
||||
- Name and Tags are left-aligned; FamilySearch ID, date columns, and # Documents are centered.
|
||||
- # Documents reflects how many linked Documents each Person is connected to.
|
||||
- Birth and death values independently prefer exact date, then approximate date, then `Unknown`.
|
||||
- Selecting a row opens Person Detail.
|
||||
- Row navigation includes list context so Person Detail provides **Back to People**.
|
||||
- No records displays `No person records found in repository.`
|
||||
|
||||
## Create and Edit Behavior
|
||||
|
||||
Required:
|
||||
|
||||
- Last name.
|
||||
- First & middle names.
|
||||
|
||||
Optional:
|
||||
|
||||
- Exact and approximate birth/death dates.
|
||||
- Birth/death places.
|
||||
- Biography.
|
||||
- FamilySearch ID.
|
||||
- Tags.
|
||||
|
||||
Rules:
|
||||
|
||||
- Missing last name or first/middle names blocks save with a warning.
|
||||
- Exact date inputs are native browser date inputs.
|
||||
- FamilySearch IDs are normalized and validated by `PeopleService`.
|
||||
- Tags use the shared Tag registry and support inline add/select behavior.
|
||||
- Photos are managed from Person Detail via `/people/{person_id}/photos` (not in create/edit form fields).
|
||||
- Metadata JSON remains hidden.
|
||||
- Save success returns to Person Detail.
|
||||
|
||||
## Detail Behavior
|
||||
|
||||
- The header provides **New Document**, **Edit Person**, **Edit Photo(s)**, and **Delete**.
|
||||
- The header includes a contextual back action: **Back to People** by default, and **Back to Document** when opened from Document Detail.
|
||||
- **New Document** opens Document creation with this Person requested for author preselection.
|
||||
- Person Detail shows a single-photo viewer with **Previous/Next** navigation; the page-level **Edit Photo(s)** header action opens photo management.
|
||||
- Photo management (upload, description edit, set-primary, delete) is intentionally moved to `/people/{person_id}/photos`.
|
||||
- Biographical Record shows split names, computed full name, tags, compact birth/death dates, and places.
|
||||
- Birth and death place values are clickable links to Google Maps when present.
|
||||
- FamilySearch ID is shown as a metadata value and is clickable to the FamilySearch person details route when present.
|
||||
- Biography has an explicit empty value.
|
||||
- Linked Documents render as a table with **Document Name**, **Document Date**, **Role**, and **Number of Pages**; selecting a row opens 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.
|
||||
- Delete is blocked when related Photos 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.
|
||||
|
||||
## Photo Gallery Behavior (`/people/{person_id}/photos`)
|
||||
|
||||
- Upload is triggered from a header-level **Upload Photo(s)** control beside **Back to Person**.
|
||||
- The gallery renders all photos in a responsive grid (3-4 tiles wide on larger screens).
|
||||
- Description text is shown as an overlay at the bottom of each image for quick context.
|
||||
- The editor provides **Save Description**, **Set Primary** (when applicable), and **Delete Photo** actions.
|
||||
|
||||
## Acceptance Checklist
|
||||
|
||||
- List fields, alignment, date fallback, search, sorting, and navigation match this contract.
|
||||
- Last name and first/middle names are enforced on create and edit.
|
||||
- FamilySearch ID validation and link generation use the fixed supported identifier format.
|
||||
- Photo 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.
|
||||
@@ -1,55 +0,0 @@
|
||||
# Settings Page Contract
|
||||
|
||||
## Purpose
|
||||
|
||||
Settings manages installation-local registries, safe runtime .env settings, and editable text assets from one route.
|
||||
|
||||
## Route
|
||||
|
||||
| Route | Purpose |
|
||||
| --- | --- |
|
||||
| `/settings` | Manage Runtime Settings, Document Types, Person Roles, Tags, Prompts, Home Page Text, and Maintenance runs. |
|
||||
|
||||
## Behavior
|
||||
|
||||
- The page title is **Settings**.
|
||||
- Configuration surfaces are grouped as tabs:
|
||||
- **Document Types**
|
||||
- **Person Roles**
|
||||
- **Tags**
|
||||
- **Prompts**
|
||||
- **Home Page Text**
|
||||
- **Maintenance**
|
||||
- **Runtime Settings**
|
||||
- Runtime Settings exposes an allowlisted set of non-secret fields synchronized with `Settings` model fields except excluded secret/unsafe fields.
|
||||
- Runtime Settings is rendered as a compact two-column editor (**Setting**, **Value**) in a centered, narrower responsive container.
|
||||
- Runtime Settings persists changes to the resolved runtime env file, validates by constructing a `Settings` instance, and reports validation failures through the shared UI error presenter.
|
||||
- `Settings` resolves its env file in this order: explicit `_env_file`, `ENV_FILE`, then the repository-root `.env.production`.
|
||||
- Runtime Settings resolves its write target in this order: explicit function override (tests/tools), `RUNTIME_SETTINGS_ENV_FILE` environment variable (deployment override), `ENV_FILE`, then the repository-root `.env.production`.
|
||||
- Runtime Settings changes require application restart to take effect.
|
||||
- Runtime Settings renders a host-side restart command (`docker compose -f docker-compose.production.yml up -d --force-recreate app worker`) so operators can apply saved values without granting Docker control to the app container.
|
||||
- Runtime Settings includes an explicit "Other settings not shown here" markdown table listing:
|
||||
- secrets (`OPENROUTER_API_KEY`, `DATABASE__PASSWORD`)
|
||||
- high-risk database connection settings (`DATABASE__DRIVER`, `DATABASE__PATH`, `DATABASE__HOST`, `DATABASE__PORT`, `DATABASE__DATABASE`, `DATABASE__USER`)
|
||||
and deployment/helper keys (`CLOUDFLARE_TUNNEL_TOKEN`, `BACKUP_DIR`, `BACKUP_RETENTION_DAYS`, `RUNTIME_SETTINGS_ENV_FILE`, `ENV_FILE`, `COMPOSE_FILE`) plus legacy/deprecated keys (`POSTGRES_*`, `DATABASE_BACKUP_DIR`, `APP_DATA_BACKUP_DIR`, `UPLOADS_BACKUP_DIR`, `SYNOLOGY_BACKUP_DIR`), and directs edits for those keys to the resolved runtime env file path.
|
||||
- Document Types, Person Roles, and Tags support Add/Edit/Delete with existing guardrails.
|
||||
- Prompts exposes only `transcribe_document.md` for editing and restore-from-backup.
|
||||
- Home Page Text edits the same Markdown content rendered on `/homepage`.
|
||||
- Maintenance provides queue-backed **Run Backup** and **Run Storage Reconciliation** actions.
|
||||
- Maintenance also provides GEDCOM upload and **Run GEDCOM Import** actions, using the same queue-backed `MaintenanceRun` history/log flow.
|
||||
- Maintenance run history shows job type, status, started/finished timestamps, duration, summary, and log view/download actions.
|
||||
- Maintenance actions enqueue work and signal the worker; the page itself does not execute shell commands directly.
|
||||
|
||||
## Acceptance Checklist
|
||||
|
||||
- `/ui/settings` renders all seven tabs.
|
||||
- Registry and prompt workflows keep existing validation and error handling.
|
||||
- Runtime Settings excludes secret fields and rejects invalid values.
|
||||
- Saving Home Page Text persists content for the homepage view.
|
||||
|
||||
## Implementation Anchors
|
||||
|
||||
- `src/transcription/ui/pages/settings_page.py`
|
||||
- `src/transcription/ui/runtime_settings_store.py`
|
||||
- `src/transcription/ui/homepage_store.py`
|
||||
- `tests/ui/test_pages_registration.py`
|
||||
@@ -1,99 +0,0 @@
|
||||
# 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` | Document-filtered or Job-filtered Source list; global route redirects to Documents. |
|
||||
| `/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 global `/sources` route redirects to `/documents`.
|
||||
- Filtered list titles are **Sources for Document** and **Sources for Job**.
|
||||
- Filtered context provides **Back to Document** or **Back to Job**.
|
||||
- Rows are ordered by page number and then upload name.
|
||||
- Columns are Upload Title, Page Number, Document Name, Status, and Error Detail.
|
||||
- Document Name, Upload Title, and Error Detail are left-aligned; Status is centered.
|
||||
- Status labels are presented in uppercase for consistency with Jobs.
|
||||
- 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 Document** returns to Document Detail for the active source page.
|
||||
- **Retranscribe Source** opens Create Processing Job with this Source and its Document locked.
|
||||
- **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.
|
||||
- The top layout is adaptive:
|
||||
- Standard pages use three columns with a wider Editable Revision column than the image column.
|
||||
- Wide+narrow landscape images switch to a stacked left layout (image above Editable Revision) with metadata on the right.
|
||||
- Editable Revision is seeded from an existing revision or the preferred 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 (uppercase display), Job ID, execution time, provider, model, prompt, and failure detail.
|
||||
- Revision Logistics shows revised state, last-revised time, and upload time.
|
||||
- Candidate Machine Transcriptions appears below the image/revision area, remains compact until expanded, then compares it with the preferred
|
||||
machine result and requires confirmation before **Use this transcription**.
|
||||
- Candidate promotion does not alter a human revision. Empty states distinguish no machine result from no candidates.
|
||||
- An orientation-normalized artifact appears in evidence only when recognized metadata required a physical rotation.
|
||||
|
||||
## 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.
|
||||
- Quality warning artifacts remain attached to their machine attempt and are not recomputed during page rendering.
|
||||
- **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.
|
||||
- Retranscription, candidate comparison, warnings, and explicit promotion preserve every prior attempt.
|
||||
- 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 remains deferred unless a demonstrated workflow need emerges.
|
||||
@@ -0,0 +1,73 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,166 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,86 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,309 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,42 @@
|
||||
# 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`
|
||||
@@ -0,0 +1,80 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,302 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,160 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,433 @@
|
||||
# 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
|
||||
@@ -0,0 +1,113 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,153 @@
|
||||
# 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
|
||||
@@ -0,0 +1,378 @@
|
||||
# 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
|
||||
@@ -0,0 +1,178 @@
|
||||
# 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
|
||||
@@ -0,0 +1,51 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,459 @@
|
||||
# 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
|
||||
@@ -0,0 +1,206 @@
|
||||
## 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`)
|
||||
@@ -0,0 +1,322 @@
|
||||
# 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.
|
||||
@@ -5,11 +5,9 @@ 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.
|
||||
|
||||
@@ -0,0 +1,10 @@
|
||||
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.
|
||||
@@ -6,15 +6,9 @@ Do not summarize. Do not paraphrase. Do not modernize style.
|
||||
|
||||
## Output Contract
|
||||
- Return only the transcription text.
|
||||
- Begin with exactly one applicable body marker:
|
||||
- `[document body handwritten]`
|
||||
- `[document body typewritten]`
|
||||
- `[document body typeset]`
|
||||
- `[document body mixed]`
|
||||
- Preserve original wording, punctuation, and meaningful structure.
|
||||
- Keep line/section flow readable while preserving intent and document organization.
|
||||
- Never invent missing content.
|
||||
- Use ordinary plain-text characters rather than HTML entities.
|
||||
|
||||
## Rules for Ambiguous or Damaged Text
|
||||
|
||||
@@ -52,31 +46,6 @@ Do not summarize. Do not paraphrase. Do not modernize style.
|
||||
- Signal location before the note text.
|
||||
- Example form: `[written in left margin: ...]`
|
||||
|
||||
### Document body medium
|
||||
- Use `[document body handwritten]` when the main body is written by hand.
|
||||
- Use `[document body typewritten]` for mechanically typewritten pages. Uneven impressions,
|
||||
monospaced characters, worn type, and other typewriter defects are not handwriting.
|
||||
- Use `[document body typeset]` for printed pages composed with movable type or comparable
|
||||
typesetting.
|
||||
- Use `[document body mixed]` when substantial body content uses more than one medium, such
|
||||
as a completed printed form.
|
||||
- Preserve printed and handwritten text together in their original reading context.
|
||||
- On mixed documents, leave printed labels and instructions unmarked and wrap only actual
|
||||
handwritten entries in `[handwritten: ...]`.
|
||||
- Mark handwritten signatures as `[handwritten signature: ...]`.
|
||||
- If the main body is entirely handwritten, use its one body marker rather than wrapping
|
||||
each line in `[handwritten: ...]`.
|
||||
- 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.
|
||||
|
||||
### Structured layouts
|
||||
- Preserve tables of contents as associated title, dotted-leader, and page-reference rows.
|
||||
- Preserve tables and forms in reading order while keeping labels associated with their values.
|
||||
- Preserve columns in their evident reading order; do not interleave unrelated rows.
|
||||
- Preserve captions with the visual element they describe.
|
||||
- Preserve marginalia with its location marker and page numbers in their evident position.
|
||||
|
||||
### Line-break hyphenation
|
||||
- Rejoin words split across line breaks when they are clearly one word.
|
||||
- Remove only line-break hyphens used for wrapping.
|
||||
@@ -101,5 +70,3 @@ 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. Exactly one document-body marker appears, and localized handwriting markers are used only where applicable.
|
||||
6. Tables, forms, columns, captions, marginalia, dotted leaders, and page references retain their associations.
|
||||
|
||||
+1
-23
@@ -12,44 +12,22 @@ 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",
|
||||
# Exact pin, deliberate. NiceGUI 3.x minor releases ship Quasar/Vue changes that
|
||||
# break component props and styling, and tests/ui/ cannot detect visual regressions.
|
||||
# Hold through the current release stabilization; revisit as a scheduled upgrade.
|
||||
# See docs/production-runbook.md, "Dependency upgrade policy".
|
||||
"nicegui==3.13.0",
|
||||
"openrouter>=0.7.0",
|
||||
"pillow>=10.0.0",
|
||||
"psycopg2-binary>=2.9.12",
|
||||
"pydantic>=2.13.4",
|
||||
"pydantic-settings>=2.9.1",
|
||||
"python-gedcom>=1.1.0",
|
||||
"sqlmodel>=0.0.25",
|
||||
]
|
||||
|
||||
|
||||
[dependency-groups]
|
||||
[project.optional-dependencies]
|
||||
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"
|
||||
asyncio_default_fixture_loop_scope = "function"
|
||||
filterwarnings = [
|
||||
"error:coroutine .* was never awaited:RuntimeWarning",
|
||||
]
|
||||
markers = [
|
||||
"unit: pure logic tests with no external dependencies",
|
||||
"integration: tests that touch framework or database contracts",
|
||||
|
||||
@@ -1,63 +0,0 @@
|
||||
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
|
||||
"G", # https://docs.astral.sh/ruff/rules/#flake8-logging-format-g
|
||||
"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"
|
||||
@@ -1,27 +0,0 @@
|
||||
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()
|
||||
@@ -1,202 +0,0 @@
|
||||
"""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 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", tags=["documents"])
|
||||
|
||||
|
||||
class ApiModel(BaseModel):
|
||||
model_config = ConfigDict(extra="forbid", frozen=True, str_strip_whitespace=True)
|
||||
|
||||
|
||||
class DocumentTypeRead(ApiModel):
|
||||
id: UUID
|
||||
label: str
|
||||
is_active: bool
|
||||
|
||||
|
||||
class PersonRoleRead(ApiModel):
|
||||
id: UUID
|
||||
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
|
||||
|
||||
|
||||
class DocumentPersonRoleUpdateRequest(ApiModel):
|
||||
role_id: UUID
|
||||
|
||||
|
||||
class DocumentPersonRead(ApiModel):
|
||||
id: UUID
|
||||
document_id: UUID
|
||||
person_id: UUID
|
||||
role_id: UUID
|
||||
role_label: str | None = None
|
||||
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:
|
||||
item_id, label, is_active = _registry_read_values(item)
|
||||
return DocumentTypeRead(id=item_id, label=label, is_active=is_active)
|
||||
|
||||
|
||||
def _person_role_to_read(item: PersonRole) -> PersonRoleRead:
|
||||
item_id, label, is_active = _registry_read_values(item)
|
||||
return PersonRoleRead(id=item_id, label=label, is_active=is_active)
|
||||
|
||||
|
||||
def _registry_read_values(item: DocumentType | PersonRole) -> tuple[UUID, str, bool]:
|
||||
return item.id, item.label, item.is_active
|
||||
|
||||
|
||||
def _document_person_to_read(item: DocumentPerson) -> DocumentPersonRead:
|
||||
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_label=item.role_ref.label if item.role_ref is not None else None,
|
||||
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,
|
||||
)
|
||||
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,
|
||||
)
|
||||
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)
|
||||
@@ -11,6 +11,7 @@ from fastapi.responses import JSONResponse
|
||||
from transcription.errors import AppError
|
||||
from transcription.errors import ErrorCategory
|
||||
from transcription.errors import build_error_envelope
|
||||
from transcription.security import AccessDeniedError
|
||||
|
||||
logger = logging.getLogger(__name__)
|
||||
|
||||
@@ -21,9 +22,7 @@ _STATUS_BY_CATEGORY: dict[ErrorCategory, int] = {
|
||||
ErrorCategory.NOT_FOUND: 404,
|
||||
ErrorCategory.CONFLICT: 409,
|
||||
ErrorCategory.EXTERNAL_PROVIDER: 503,
|
||||
ErrorCategory.EXTERNAL_TIMEOUT: 503,
|
||||
ErrorCategory.INFRA_TRANSIENT: 503,
|
||||
ErrorCategory.PROCESSING: 500,
|
||||
ErrorCategory.INFRA_PERSISTENT: 500,
|
||||
ErrorCategory.INTERNAL_UNEXPECTED: 500,
|
||||
}
|
||||
@@ -36,6 +35,12 @@ 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)
|
||||
|
||||
@@ -1,44 +1,16 @@
|
||||
"""Health endpoint routes."""
|
||||
|
||||
from typing import NotRequired
|
||||
from typing import TypedDict
|
||||
|
||||
from fastapi import APIRouter
|
||||
from fastapi import Request
|
||||
|
||||
from transcription.worker import resolve_worker_health
|
||||
|
||||
router = APIRouter()
|
||||
|
||||
|
||||
class WorkerHealthPayload(TypedDict):
|
||||
state: str
|
||||
error_id: NotRequired[str]
|
||||
error_category: NotRequired[str]
|
||||
|
||||
|
||||
class HealthPayload(TypedDict):
|
||||
status: str
|
||||
worker: WorkerHealthPayload
|
||||
|
||||
|
||||
def healthz(request: Request) -> HealthPayload:
|
||||
"""Return health status with worker-liveness signal."""
|
||||
worker = resolve_worker_health(request.app.state)
|
||||
payload: HealthPayload = {
|
||||
"status": "ok",
|
||||
"worker": {
|
||||
"state": worker.state,
|
||||
},
|
||||
}
|
||||
if worker.error_id is not None:
|
||||
payload["worker"]["error_id"] = worker.error_id
|
||||
if worker.error_category is not None:
|
||||
payload["worker"]["error_category"] = worker.error_category
|
||||
return payload
|
||||
def healthz() -> dict[str, str]:
|
||||
"""Return a simple health status payload."""
|
||||
return {"status": "ok"}
|
||||
|
||||
|
||||
@router.get("/healthz")
|
||||
def healthz_route(request: Request) -> HealthPayload:
|
||||
def healthz_route() -> dict[str, str]:
|
||||
"""Route wrapper for health status payload."""
|
||||
return healthz(request)
|
||||
return healthz()
|
||||
|
||||
@@ -1,54 +0,0 @@
|
||||
"""Safe media route for Document print previews."""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
from pathlib import Path
|
||||
from typing import Annotated
|
||||
from uuid import UUID
|
||||
|
||||
from fastapi import APIRouter
|
||||
from fastapi import Depends
|
||||
from fastapi import HTTPException
|
||||
from fastapi import Request
|
||||
from fastapi.responses import FileResponse
|
||||
|
||||
from transcription.services.source_media import SOURCE_MIME_TYPES
|
||||
from transcription.services.sources import SourceService
|
||||
|
||||
router = APIRouter(prefix="/api", tags=["print"])
|
||||
|
||||
|
||||
def get_source_service(request: Request) -> SourceService:
|
||||
services = getattr(request.app.state, "services", None)
|
||||
if services is not None:
|
||||
return services.sources
|
||||
return SourceService()
|
||||
|
||||
|
||||
SourceServiceDependency = Annotated[SourceService, Depends(get_source_service)]
|
||||
|
||||
|
||||
@router.get("/documents/{document_id}/sources/{source_id}/media", response_class=FileResponse)
|
||||
async def read_document_source_media(
|
||||
document_id: UUID,
|
||||
source_id: UUID,
|
||||
service: SourceServiceDependency,
|
||||
) -> FileResponse:
|
||||
"""Serve one validated Source through record identifiers, never a supplied path."""
|
||||
source = await service.read_source(source_id)
|
||||
if source.document_id != document_id:
|
||||
raise HTTPException(status_code=404, detail="Source not found for Document")
|
||||
|
||||
upload_root = service.settings.upload_dir.resolve()
|
||||
path = (upload_root / Path(source.file_path)).resolve()
|
||||
try:
|
||||
path.relative_to(upload_root)
|
||||
except ValueError as exc:
|
||||
raise HTTPException(status_code=404, detail="Source media is outside managed storage") from exc
|
||||
if not path.is_file():
|
||||
raise HTTPException(status_code=404, detail="Source media is unavailable")
|
||||
|
||||
media_type = SOURCE_MIME_TYPES.get(path.suffix.lower())
|
||||
if media_type is None:
|
||||
raise HTTPException(status_code=415, detail="Unsupported Source media type")
|
||||
return FileResponse(path, media_type=media_type)
|
||||
@@ -0,0 +1,161 @@
|
||||
"""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,
|
||||
}
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user