Complete Phase 7 runner orchestration

docs/rewrite-notes.md

@@ -44,10 +44,12 @@ Implemented:
 - Process report output through `--report-json` and run-dir `report.json`.
 - Report-level diagnostics artifact references.
 - Framework foundation packages for contracts and proposal preview/apply semantics.
+- Production runner orchestration over a mutable working transcript.
+- Module-level report structures and run-level module summaries.
+- CLI runner integration point via injectable module factory/registry (used by deterministic tests).
 - Broad deterministic and CLI/subprocess test coverage for implemented phases through `go test ./...`.
 
 Not yet implemented in runtime pipeline:
-- Module runner orchestration.
 - Real correction modules.
 - Validator-chain execution.
 - Structured LLM client integration.
@@ -135,53 +137,33 @@ Implemented:
 Intentionally deferred:
 - Module prompt/response diagnostics artifacts are not produced yet because module execution and LLM calls are not implemented in the runtime path.
 
+### Phase 7: Pipeline runner with deterministic test modules
+
+Completed.
+
+Implemented:
+- `internal/framework/runner` production package with sequential module orchestration.
+- Deterministic module run-spec resolution and repeated instance naming (`glossary_1`, `glossary_2`, etc.).
+- Mutable working transcript handoff across module instances.
+- Proposal application through `internal/framework/proposals`.
+- Per-module applied/skipped change capture and module status/timing metadata.
+- Partial-progress return on module failure, with pipeline stop on first failure.
+- Process report support for module-level results and run-level module summaries.
+- CLI runtime integration point via injectable module factory/registry, exercised by deterministic fake-module tests.
+
+Not implemented in Phase 7 (by design):
+- Real `glossary`, `homophones`, `spoken_word`, `grammar` production modules.
+- Validators (Phase 8).
+- Structured LLM calls or scheduler behavior.
+- Prompt/response diagnostics.
+- End-to-end transcript polishing.
+
+Current runtime behavior note:
+- Default user-facing CLI behavior remains deterministic normalization/chunking output unless test-only module injection is used during tests.
+
 ## Remaining work plan
 
-## Phase 7: Pipeline runner with deterministic test modules
-
-### Purpose
-
-Introduce the production pipeline runner that executes configured module instances sequentially over a mutable working transcript, but without real LLM calls or real correction modules yet.
-
-This phase closes the largest architectural gap: the runtime path currently normalizes and chunks, but does not execute module stages.
-
-### Scope
-
-Implement:
-- `internal/framework/runner` or equivalent production runner package.
-- Module run-spec resolution from configured module keys.
-- Sequential execution of module instances.
-- Mutable working transcript handoff from one module to the next.
-- Integration with existing proposal application package.
-- Module-level report structures.
-- Applied/skipped changes recorded per module instance.
-- Test-only deterministic modules or fake modules to exercise runner behavior.
-- CLI wiring from `internal/cli/run.go` into the runner.
-
-Do not implement:
-- Real `glossary`, `homophones`, `spoken_word`, or `grammar` modules.
-- LLM calls.
-- Validator chains.
-- LLM scheduler behavior.
-- Prompt/response diagnostics.
-
-### Expected behavior at end of phase
-
-The CLI should still not perform real transcript polishing by default unless a test-only module sequence is explicitly used in tests. The production path may resolve configured module names, but unsupported real modules should fail cleanly or remain gated until implemented in later phases.
-
-The runner itself should be production-quality and tested with deterministic fake modules.
-
-### Definition of done
-
-- Configured module keys can be resolved into deterministic run specs.
-- Repeated module names are resolved consistently, such as `glossary_1` and `glossary_2`.
-- Runner executes module instances sequentially.
-- Later modules see transcript changes from earlier modules.
-- Applied and skipped changes are recorded per module instance.
-- Process report includes module-level report structures.
-- Existing stdout/stderr behavior remains unchanged.
-- Diagnostics retention behavior remains unchanged.
-- `go test ./...` passes.
+Next recommended phase: **Phase 8 (runtime validator framework and deterministic validators)**.
 
 ## Phase 8: Runtime validator framework and deterministic validators
 
@@ -716,4 +698,4 @@ Before accepting a phase implementation, verify:
 - Are fake LLM tests used instead of requiring real credentials?
 - Are new public behaviors documented?
 - Does the code follow the architecture in `docs/architecture.md`?
-- Does the implementation move Audita closer to Python feature parity?
+- Does the implementation move Audita closer to Python feature parity?