Complete Phase 11 proposal generation framework

This commit is contained in:
2026-05-12 02:25:33 +00:00
parent 12202508bf
commit b360493cdc
12 changed files with 1032 additions and 56 deletions

View File

@@ -55,6 +55,10 @@ Implemented:
- LLM validator batching by validation prompt-token budget.
- LLM validator runtime integration through structured LLM client abstraction and scheduler hooks.
- LLM validator prompt/response diagnostics artifact wiring with secret redaction.
- Shared LLM proposal-generation helper with structured correction-set parsing.
- Deterministic proposal-index assignment for shared proposal generation.
- Proposal-generation prompt/response diagnostics artifact wiring with secret redaction.
- Production module-registry scaffolding with known key recognition and explicit unsupported/unimplemented errors.
- Broad deterministic and CLI/subprocess test coverage for implemented phases through `go test ./...`.
- Internal typed structured LLM contract (`StructuredLLMClient.CompleteStructured(ctx, req, out)`).
- `internal/framework/llm` instructor-go-backed adapter with:
@@ -71,7 +75,7 @@ Implemented:
Not yet implemented in runtime pipeline:
- Real correction modules.
- Shared module proposal generation and module registry wiring.
- Domain proposal prompts for real modules.
- End-to-end transcript polishing behavior.
## Completed phases
@@ -210,7 +214,7 @@ Not implemented in Phase 8 (by design):
## Remaining work plan
Next recommended phase: **Phase 11 (shared LLM proposal generation framework and module registry)**.
Next recommended phase: **Phase 12 (grammar module)**.
## Phase 9: Structured LLM client and scheduler infrastructure
@@ -261,7 +265,7 @@ Do not implement:
### Expected behavior at end of phase
The codebase has tested Phase 9 LLM infrastructure, but default CLI runtime behavior remains deterministic preprocessing/reporting because real modules and LLM-backed validators are not implemented.
At the end of Phase 9, the codebase had tested LLM infrastructure primitives, while default CLI runtime behavior remained deterministic preprocessing/reporting because real modules were not implemented yet.
### Definition of done status
@@ -298,48 +302,40 @@ Implemented:
Not implemented in Phase 10 (by design):
- Real correction modules (`glossary`, `homophones`, `spoken_word`, `grammar`).
- Shared module proposal generation and module registry work (Phase 11).
- Real module implementation and full runtime wiring (Phase 12+).
- Domain proposal prompts.
- Default CLI end-to-end transcript polishing behavior.
## Phase 11: Shared LLM proposal generation framework and module registry
### Purpose
Completed.
Create the reusable proposal-generation layer used by all real modules, and establish the real module registry without yet requiring all modules to be fully implemented.
Implemented:
- Shared proposal-generation package `internal/framework/proposal_generation`.
- Reusable request model for proposal generation including:
- module key/instance
- replacement policy
- working transcript context
- optional section metadata
- glossary/config context
- diagnostics context
- injected structured LLM client/scheduler dependencies.
- Structured correction-set response model and parsing into existing proposal models:
- `proposals.CorrectionProposal`
- `proposals.EnrichedCorrectionProposal`.
- Deterministic proposal-index assignment via caller-provided start index.
- Proposal-generation diagnostics artifact writing using generic LLM diagnostics primitives with secret redaction.
- Scheduler-aware proposal generation through the internal LLM scheduler interface.
- Production module-registry scaffolding in `internal/framework/modules` with:
- known module-key recognition for `glossary`, `homophones`, `spoken_word`, `grammar`
- constructor registration and dependency-injection path
- explicit unsupported and recognized-but-unimplemented module errors.
- Runner/CLI injection-path tests showing shared proposal generation can flow through runner validation/application semantics using fake modules/clients.
### Scope
Implement:
- Shared LLM proposal generation helper.
- Proposal prompt request/response models.
- Structured correction set response parsing.
- Proposal index assignment.
- Module prompt/response diagnostics.
- Module registry package for real module keys.
- Module construction from run specs.
- Clean unsupported-module behavior.
- Shared module test harness using fake LLM responses.
- One minimal real module may be implemented as a proof of the proposal-generation path if that keeps the phase coherent, but only if it does not blur scope.
Do not implement:
- All real modules.
- Full default pipeline parity.
- Prompt improvements beyond faithful porting of Python behavior.
### Expected behavior at end of phase
The framework can support real LLM proposal generation, and modules can be registered and instantiated consistently. At least the infrastructure for real modules exists, even if most modules are implemented in later phases.
### Definition of done
- Shared proposal-generation helper exists.
- Proposal prompt/response diagnostics are written for module proposal calls.
- Module registry resolves known module keys deterministically.
- Unsupported modules fail cleanly.
- Fake module tests exercise shared proposal-generation behavior.
- Module reports include proposal-generation failures where applicable.
- `go test ./...` passes.
Not implemented in Phase 11 (by design):
- Real production `glossary`, `homophones`, `spoken_word`, and `grammar` modules.
- Domain proposal prompts for production modules.
- Default CLI end-to-end transcript polishing behavior.
## Phase 12: Grammar module