Plan feedback-aware validation retries

docs/roadmap/future.md

@@ -13,124 +13,15 @@ structural output repair within one completion. Notarius owns stage candidates,
 validator chains, semantic rejection policy, and whether another stage attempt
 is warranted.
 
-### 1. Upgrade To PromptKit v0.8.0
+### Feedback-Aware Stage Validation Retries
 
 This item has been promoted to the standalone
-[PromptKit v0.8.0 Upgrade](promptkit-v0.8.md) roadmap. That document owns the
-release-by-release compatibility review, adopted features, structured-repair
-policy, target integration boundary, acceptance criteria, and settled design
-decisions.
+[Feedback-Aware Stage Validation Retries](validation-retries.md) roadmap. That
+document owns the target validation state machine, correction protocol, retry
+budgets, terminal policies, provenance requirements, settled producer
+contracts, and PromptKit v0.9.0 adoption.
 
-### 2. Feedback-Aware Stage Validation Retries
-
-- Model Notarius's corrective stage-retry conversation explicitly after
-  PromptKit v0.8.0. The first attempt sends the ordinary complete initial
-  prompt. If application validation rejects the resulting LLM-produced
-  candidate and another stage attempt is available, reconstruct that complete
-  initial prompt byte-for-byte and append exactly two messages: an assistant
-  message containing the defective response and an application-owned user
-  message detailing every applicable semantic validation error and requesting
-  one corrected, complete replacement response. This is a freshly constructed
-  correction request, not continuation of an accumulating conversation.
-- Use the configured stage `retries` value as the one outer retry budget for
-  this loop. `retries: N` continues to mean at most `N` additional complete
-  chunk, extract, merge, or normalize attempts after the initial attempt,
-  whether an attempt is needed because of a producer error or semantic
-  rejection. Do not add a second semantic-correction count. PromptKit's
-  prompt-level `repair_attempts` budget is independent and internal to each
-  individual LLM completion, and does not consume or replenish the Notarius
-  stage budget.
-- Extend the framework-managed validation boundary for chunk, extract, merge,
-  and normalize stages so a rejected LLM-produced candidate and its exact raw
-  model response remain available to construct the next stage attempt.
-  Deterministic producers cannot improve by repeating the same inputs; a
-  rejection from a deterministic stage is therefore terminal under the
-  configured rejection policy rather than consuming retries mechanically.
-- Preserve the original session ID, selected profile, structured-output
-  contract, prompt inputs, and reusable prompt prefix. Carry only the latest
-  candidate and latest aggregate feedback; do not build an unbounded retry
-  conversation. Keep model-facing corrective guidance separate from
-  operator-facing diagnostics, and apply explicit size, redaction, and debug
-  disclosure rules to both.
-- Run every applicable validator in the configured chain before deciding
-  whether to retry. Do not short-circuit merely because an earlier validator
-  rejected the candidate. Aggregate all semantic rejection reason codes and
-  corrective guidance into the retry message so one retry can address the
-  whole candidate. A validator is applicable only when its declared target and
-  prerequisites can be satisfied; record a deterministic skipped diagnostic
-  rather than invoking a validator on an input it cannot interpret. Initially
-  execute the chain sequentially in configured order so results, diagnostics,
-  costs, and feedback ordering remain deterministic; consider validator
-  concurrency only in response to measured latency.
-- Continue running independent applicable validators after one validator
-  execution failure so the attempt retains as much useful diagnostic
-  information as practical. Do not present validator operational failures as
-  defects in the producer candidate and do not include them in corrective
-  feedback.
-- Distinguish three terminal conditions and make their policies configurable
-  at a coherent pipeline or binding scope:
-  - **producer structural failure:** PromptKit could not return a usable
-    structured candidate after its repair budget. Default to `fail_run`; an
-    allowed alternative may record a terminal stage or lane rejection where
-    execution can safely continue, but may not accept the invalid output;
-  - **semantic rejection:** one or more validators completed and rejected the
-    candidate. Default to `fail_run` after corrective stage retries are
-    exhausted; allow an explicit alternative that records the existing
-    rejected-output outcome without advancing that output;
-  - **validator execution failure:** a validator could not produce a valid
-    decision because of generation, structural-output, transport, or internal
-    failure. Default to a genuine warning and an explicitly recorded
-    `validation_incomplete` or equivalent degraded state while allowing the
-    candidate to continue; allow strict configuration to fail the run instead.
-- An LLM-backed validator uses the same scheduled PromptKit boundary as every
-  other LLM-backed module. Its own response may use PromptKit's bounded
-  structural repair. Distinguish its possible output states:
-  - output rejected by PromptKit's structural contract should consume only the
-    validator prompt's configured PromptKit repair budget;
-  - output that is structurally valid but violates a deterministically
-    checkable validator-result invariant should be classified as a validator
-    execution failure;
-  - output that satisfies the complete validator-result contract is the
-    validator's decision, even though an LLM judgment may remain imperfect.
-    Automatically judging that judgment would require another semantic
-    validator and is outside this feature.
-  If the validator cannot return a contract-valid decision, do not recursively
-  create another Notarius semantic-validation loop around it. Apply the
-  configured validator-failure policy. The default warning must identify the
-  validator and affected stage without exposing sensitive content.
-- Separate validator execution retry from producer correction. A transient
-  validator operational failure must not automatically discard and regenerate
-  an otherwise usable producer candidate. Any bounded retry of the validator
-  itself should reuse that same immutable candidate and remain subordinate to
-  PromptKit and provider retry behavior.
-- Preserve attempt-level provenance, cumulative token usage, validator
-  outcomes, aggregated correction feedback, and terminal policy decisions in
-  the debug and manifest models without copying raw source material into
-  ordinary errors or durable summaries.
-- Define terminal-outcome precedence. A semantic rejection dominates a
-  validator execution failure for the same candidate: use the completed
-  rejections to correct the producer while separately recording incomplete
-  validation. If a later candidate has no semantic rejection but one validator
-  still fails, apply the configured validator-failure policy to that candidate.
-  Never allow a known semantic rejection to become accepted through a
-  warn-and-continue setting, and never accept a structurally invalid producer
-  response. Permissive policy may preserve a rejected-output outcome or accept
-  a structurally valid candidate with explicitly incomplete validation; it may
-  not relabel known-invalid output as approved.
-
-Before implementation, record the generic validation and retry state machine
-in an ADR. The ADR should own the separation between PromptKit repair and
-Notarius correction, use of the existing stage-retry budget, reconstruction of
-correction conversations, all-applicable-validator aggregation, deterministic
-validator ordering, non-recursive validator failure handling, outcome
-precedence, default fail-open/fail-closed choices, configurable terminal
-policies, and provenance and sensitive-data constraints. A dependency-upgrade
-ADR is not needed for PromptKit v0.8.0 itself. Current behavior remains
-authoritative until the validation ADR is implemented and the canonical
-architecture, configuration, operations, and internal documentation are
-updated.
-
-### 3. D&D Combat Scene Semantic Validation
+### D&D Combat Scene Semantic Validation
 
 - Add an optional production LLM-backed D&D validator that determines whether
   proposed scene boundaries and classifications represent substantive active
@@ -172,7 +63,7 @@ updated.
   the chunker or otherwise changes stage ownership or the durable chunk-plan
   contract.
 
-### 4. Warning Signal And Presentation Reform
+### Warning Signal And Presentation Reform
 
 - Audit every warning producer and representative successful runs. Ordinary
   success producing dozens of warnings is a failed operator experience: the