Document feedback-aware validation retries

docs/internal/llm.md

@@ -50,6 +50,14 @@ correction do not add messages or introduce caller roles. Ordinary request
 summaries record correction byte counts and digests only; complete messages are
 available solely in an explicitly requested debug trace.
 
+The adapter leaves the ordinary rendered message prefix, named inputs,
+variables, session, profile, execution overrides, prepared-execution path, and
+PromptKit repair policy unchanged for a corrected request. It never imports a
+PromptKit message type into a module or pipeline contract. PromptKit reports
+actual structural repair count and cumulative token usage per completion; the
+pipeline's safe terminal debug record projects those values without copying
+message content.
+
 Client construction may also receive a run-wide reasoning-effort override from
 the CLI factory boundary. The adapter copies the caller-owned pointer and
 creates a fresh PromptKit execution override for each request: a nil pointer
@@ -237,10 +245,11 @@ or corrective call remain provider-neutral operational errors with the same
 redaction boundary.
 
 Structural repair does not replace pipeline retry behavior: a binding's
-configured retry count reruns its complete stage attempt after an error or
-rejection. The pipeline owns attempt lifecycle, validation chains, and retry
-diagnostics; see [Pipeline Internals](pipeline.md#validation-retries-and-output)
-and the [binding reference](../config.md#module-bindings-and-validators).
+configured retry count reruns its complete stage attempt after an operational
+or structural error, module-requested retry, or actionable semantic rejection.
+The pipeline owns attempt lifecycle, validation chains, and retry diagnostics;
+see [Pipeline Internals](pipeline.md#validation-retries-and-output) and the
+[binding reference](../config.md#module-bindings-and-validators).
 
 ## Timeout Ownership
 
@@ -270,6 +279,13 @@ surfaced; when the completion already failed, its call error remains the
 result. Debug-bundle location, retention, and handling are operational concerns
 documented in [Operations](../operations.md#debug-bundles).
 
+The attempt-terminal summary is a separate safe trace record: it contains
+attempt kinds, validator outcome counts and reason codes, effective policy,
+terminal action, and repair/usage references. It excludes raw assistant
+responses and correction text. Those values can appear only in the explicitly
+requested detailed prompt and response artifacts, which require sensitive-data
+handling.
+
 Run manifests receive selected profile summaries, including optional effective
 backend and reasoning provenance, and component identities—not prompt, schema,
 source, reference, or response content. The published field semantics belong

docs/internal/modules.md

@@ -22,6 +22,15 @@ to bindings whose declared execution class is `llm_backed` and rejects a
 binding-specific profile on a deterministic module. The user-facing precedence
 contract belongs in [Configuration](../config.md#pipelines).
 
+An eligible LLM-backed chunk, extract, merge, or normalize producer may also
+declare correction protocol `single_response_v1`. That declaration is a
+promise that the implementation accepts one attempt-local semantic correction
+and returns an owned copy of the exact one model response that directly
+controlled the candidate. It must forward correction only to its structured
+completion request; it must not manufacture prior-response material by
+serializing a normalized artifact or expose opaque application IDs. Input,
+output, validator, and deterministic specs cannot declare the protocol.
+
 Implementations that accept options must provide both an option validator and
 a builder. The validator is used while resolving configuration; the builder
 decodes the same options and constructs the implementation from the prepared
@@ -91,6 +100,12 @@ combined-material bound preserves the deterministic result under the family's
 fallback policy. Provider, transport, cancellation, and context-construction
 failures remain execution errors.
 
+When the engine actually makes a proposal call, its typed result carries the
+owned exact proposal response under the same correction contract as other
+eligible producers. Deterministic skip, limit, and fallback outcomes carry no
+model candidate, so a later rejection applies terminal policy without spending
+an ineffective semantic retry.
+
 The core supplies a conservative generic prompt and the single private
 response schema. A domain prompt may substitute its semantic instructions but
 mounts the core-owned protocol and candidate/transcript presentation assets.
@@ -111,6 +126,8 @@ its domain prompt.
 3. Implement strict option decoding, construction, and the typed stage
    interface. Preserve caller ownership: do not retain mutable request data
    and return defensive copies where an implementation exposes stored data.
+   If declaring correction capability, forward the request correction and
+   retain only the exact validated response that controlled the result.
 4. Register the module through its typed registry helper and add it to the
    owning family registrar. Add a default validator chain only when that
    family owns the behavior; otherwise require an explicit compatible chain.

docs/internal/pipeline.md

@@ -147,9 +147,10 @@ failure outcome for each validator.
 
 The runner applies the binding's retry policy around a stage operation and its
 complete validation chain. It preserves warnings only from the final accepted
-or rejected attempt. Cancellation stops retries. Normalizer-specific retry
-directives consume this same budget and validate any final safe fallback through
-the normalizer chain.
+or rejected attempt, plus one fixed warning per validator whose execution
+budget was exhausted under `warn_continue`. Cancellation stops retries.
+Normalizer-specific retry directives consume this same budget and validate any
+final safe fallback through the normalizer chain.
 
 The artifact-neutral producer-attempt state machine owns that shared budget,
 attempt provenance, semantic-correction material, and terminal-policy
@@ -181,6 +182,15 @@ The CLI publishes those files only after the runner returns without a framework
 error. Logical file names and schemas are defined by the [output integration
 contracts](../integrations/).
 
+For every completed producer disposition, the runner projects one bounded
+validation summary to the manifest, the affected rejection when present, and
+the CLI result receipt. The summary records status, configured-order rejecting
+validators and reason codes, incomplete validators, producer-attempt count,
+and terminal action. It contains no operator message, correction guidance, or
+model response. `complete`, `rejected`, and `incomplete` describe the final
+candidate disposition; a run-level `incomplete` status indicates at least one
+current-run output advanced under `warn_continue`.
+
 ## Checkpoint And Debug Hooks
 
 The runner receives checkpoint and debug interfaces rather than roots. It
@@ -190,6 +200,15 @@ handoff. Generated-reference dependencies participate in checkpoint decisions.
 Selective recomputation can require a canonical accepted normalized predecessor
 before a dependent lane starts.
 
+The runner writes successful checkpoint artifacts only after complete accepted
+validation. Chunk plans follow the same rule for publication. A rejection,
+invalid structured response, or incomplete validation is never reusable state;
+the current run may still hand off an otherwise valid `warn_continue` result
+according to its terminal policy. Attempt debug records retain safe kind,
+validator, repair-usage, policy, and terminal-decision provenance. Full
+assistant and correction content remains confined to the requested detailed
+LLM trace.
+
 Debug recording is attempt-scoped and application-owned. A failure to persist
 required debug data is a framework error. State roots, persistence, reason-code
 meanings, resume, and cleanup are intentionally owned by