Route proposal modules through embedded PromptKit definitions
This commit is contained in:
@@ -35,10 +35,14 @@ Shared proposal-generation plumbing is centralized in:
|
||||
- `internal/framework/proposal_generation`
|
||||
|
||||
Module packages own:
|
||||
- prompt selection (`internal/prompts` prompt IDs);
|
||||
- module-specific prompt payload construction.
|
||||
- prompt selection (`internal/prompts` prompt IDs).
|
||||
|
||||
Shared prompt helpers live in `internal/framework/promptcontext`.
|
||||
`proposal_generation.BuildProposalVariables` encodes the glossary, selected
|
||||
transcript section, and trimmed description once for all four modules. PromptKit
|
||||
renders their embedded definitions from those variables and validates the
|
||||
correction-set schema before Audita maps proposals. Domain validators still
|
||||
check confidence, applicability, protected glossary terms, and replacement
|
||||
policy. Shared context encoding lives in `internal/framework/promptcontext`.
|
||||
|
||||
## Validator Chain Ownership
|
||||
|
||||
@@ -48,21 +52,21 @@ Module packages call the built-in chain resolver at construction.
|
||||
## Failure and Warning Behavior
|
||||
|
||||
Module construction failures propagate to orchestration; execution failures can
|
||||
preserve partial module results. Malformed structured proposal payloads become
|
||||
warnings and section-level rejection. Consumer-visible outcomes are defined by
|
||||
preserve partial module results. Exhausted structural repair becomes a warning
|
||||
and section-level rejection; provider and protocol failures propagate. Consumer-visible outcomes are defined by
|
||||
the [report contract](../integrations/output-files.md#module-outcomes).
|
||||
|
||||
## Changing Modules
|
||||
|
||||
1. Add or update the narrowly scoped package under `internal/modules/<module_key>`.
|
||||
2. Keep module-specific prompt ownership in the module and `internal/prompts`;
|
||||
see [prompt rendering and metadata](prompts.md).
|
||||
2. Keep module prompt selection in the module and its definition in
|
||||
`internal/prompts`; see [prompt assets](prompts.md).
|
||||
3. Wire module registration and catalog resolution through framework module
|
||||
registration and the core module catalog. Update selectable keys in the
|
||||
[configuration contract](../config.md) when they change.
|
||||
4. Verify replacement policy and validator-chain selection against the
|
||||
[architecture requirements](../policy/architecture.md#correction-and-concurrency-invariants).
|
||||
5. Review module, prompt-rendering, and proposal-generation tests. Inspect parity
|
||||
5. Review module, prompt-variable, and proposal-generation tests. Inspect parity
|
||||
and release fixtures when public output changes, choosing sufficient coverage
|
||||
under the [testing policy](../policy/testing.md).
|
||||
6. Update this document for implementation changes and the appropriate public
|
||||
|
||||
Reference in New Issue
Block a user