Implemented v1 step1

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

@@ -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.

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

@@ -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.

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

@@ -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.

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

@@ -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.

docs/adr/README.md

@@ -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)