generated from john/python-template
Implemented v1 step1
This commit is contained in:
@@ -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)
|
||||
+19
-2
@@ -61,6 +61,20 @@ flowchart LR
|
||||
Worker --> MG
|
||||
```
|
||||
|
||||
## Runtime Ownership And Startup Policy (V1 Step 1)
|
||||
|
||||
The current implementation now uses explicit lifespan-owned runtime resources.
|
||||
|
||||
- application lifespan initializes and disposes database runtime resources
|
||||
- worker lifecycle is owned by application lifespan startup/shutdown
|
||||
- worker receives lifespan-owned database engine dependency explicitly
|
||||
- schema bootstrap policy is environment-aware and explicit:
|
||||
- development/test default to bootstrap enabled
|
||||
- production defaults to bootstrap disabled
|
||||
- explicit override is available via configuration
|
||||
|
||||
This aligns implementation toward REQ-7 and REQ-10 while preserving personal-scale operational simplicity.
|
||||
|
||||
## Layered Module Structure
|
||||
|
||||
### Interface Layer
|
||||
@@ -121,7 +135,7 @@ Production transcription flow:
|
||||
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 completed or failed.
|
||||
5. Job status transitions from queued to processing to transcribed or failed.
|
||||
6. The UI and API expose status, revision history, and searchable transcript text.
|
||||
|
||||
## Data Model Ownership
|
||||
@@ -253,7 +267,10 @@ Control:
|
||||
## Related Pages
|
||||
|
||||
- [System overview](index.md)
|
||||
- [Testing guide](tests.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
|
||||
|
||||
|
||||
+6
-1
@@ -6,6 +6,8 @@ This project is a production application for transcribing and preserving histori
|
||||
|
||||
Read [architecture.md](architecture.md) first.
|
||||
|
||||
Then review [ver1/ver1.md](ver1/ver1.md) for completion scope and [ver1/ver1-step1-results.md](ver1/ver1-step1-results.md) for current architecture-consolidation status.
|
||||
|
||||
The architecture page is the primary technical reference and defines:
|
||||
|
||||
- deployed topology and infrastructure limits
|
||||
@@ -40,7 +42,10 @@ This operating model keeps deployment and maintenance simple while preserving cl
|
||||
## Documentation Map
|
||||
|
||||
- Architecture and technical design: [architecture.md](architecture.md)
|
||||
- Testing strategy and guidance: [tests.md](tests.md)
|
||||
- Version 1 implementation plan: [ver1/ver1.md](ver1/ver1.md)
|
||||
- Version 1 Step 1 plan: [ver1/ver1-step1.md](ver1/ver1-step1.md)
|
||||
- Version 1 Step 1 results: [ver1/ver1-step1-results.md](ver1/ver1-step1-results.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)
|
||||
|
||||
@@ -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.
|
||||
Reference in New Issue
Block a user