Validate correction repair through the processing command

This commit is contained in:
2026-11-11 04:47:43 +00:00
parent f4c638313e
commit aa8073cab1
19 changed files with 511 additions and 41 deletions

View File

@@ -16,7 +16,13 @@ credential source names for artifact redaction without inspecting unrelated
environment values. See the [integration contract](../integrations/openai-compatible-llm.md)
for failure behavior and the [configuration reference](../config.md) for sources.
Proposal calls can retain the original prompt, effective variables, prepared messages, and final response for section-local repair replay. The adapter renders the repair definition with the selected profile, appends branch history to the original prompt, and checks the prepared prefix before execution. The requested repair definition is retained in call attribution alongside the native base-prompt metadata.
When correction repair is enabled, the proposal call retains its prompt,
effective variables, prepared messages, and full final response for section-local
replay. The adapter renders the repair definition with the selected profile,
appends only that branch’s history, and checks the original prepared prefix
before execution. The complete conversation is sent to the selected provider;
provider rejection ends that branch as unavailable. The requested repair
definition is retained in call attribution alongside native base-prompt metadata.
The observation collector tracks logical calls and execution events. Ordinary
reports use compact safe outcomes; request and response evidence is optional

View File

@@ -13,6 +13,9 @@ Modules implement `contracts.TranscriptModule`:
- `Validators()`
- `Propose(ctx, req)`
Built-in modules also expose `RepairPromptID()` for the runner to select their
repair definitions; proposal-only callers retain the existing interface.
Runner resolves configured module specs to module instances through `internal/framework/modules`.
## Built-In Modules
@@ -61,6 +64,10 @@ Module packages call the built-in chain resolver at construction.
## Failure and Outcome Behavior
Each actionable rejection can be revised or withdrawn within its original
section. A revision retains the original proposal identity and must pass the
full validator chain before application.
Module construction failures are fatal. Recoverable proposal model failures
record an unsuccessful operation and yield no candidates for that section;
other sections and module instances continue. Fatal adapter or application

View File

@@ -11,9 +11,10 @@ and `audita/modules.grammar.proposal`; the corresponding repair IDs replace
PromptKit composes embedded defaults with operator prompt sources. Shared
instructions come from the embedded fragments in `assets/shared`; the request
adapter fills absent `HardeningPolicy`, `ProposalContract`, `RepairContract`, and
`ValidationContract` variables without replacing values explicitly supplied by
the caller. Processing supplies Audita's response-schema contract separately.
shared-variable helper fills absent `HardeningPolicy`, `ProposalContract`,
`RepairContract`, and `ValidationContract` variables. The processing adapter
supplies the embedded instruction fragments for those names. Processing supplies
Audita's response-schema contract separately.
The operator's prompt definition controls which variables its template uses.
For a standard request preview or validation, select a native PromptKit profile
@@ -23,7 +24,10 @@ proposal definitions use `TranscriptDescriptionBlock`, `GlossaryJSON`,
and the separate spelling list defines protection. Preview defaults the
spelling list to `[]` when omitted. The validator definitions use `TranscriptDescriptionBlock` and
`PayloadJSON`. The latter is supplied candidate JSON and does not require a
proposal inference call. An operator replacement may use different variables.
proposal inference call. Repair definitions use `RepairContract` and
`RepairRequestJSON`, containing the original proposal reference, current
correction, and ordered findings. An operator replacement may use different
variables.
See the [upstream CLI reference](https://forge.maximumdirect.net/base-layer/commandkit/src/commit/f369d6a78253b6e6fcb1e023fb2e9c3af1d20ff0/docs/cli.md)
for the standard preview, validation, and smoke commands.

View File

@@ -49,7 +49,10 @@ For each module section:
When correction repair is enabled, the runner also gathers independent findings
for rejected candidates when a validator has usable evidence. Unavailable
assessments remain unavailable, and only candidates that pass every applicable
check can advance. A zero repair budget retains the original shortlist flow.
check can advance. A known rejection can enter repair even when another
assessment is unavailable; an unavailable assessment alone does not. Revised
candidates run the applicable checks again. A zero repair budget retains the
original shortlist flow.
Decision cardinality is enforced inside Audita: each candidate proposal must
receive exactly one outcome per validator it reaches. The runner still rejects