Carry repair provenance through application workflows

docs/internal/app-orchestration.md

@@ -7,7 +7,7 @@ is owned by the [CLI reference](../cli.md) and [operations guide](../operations.
 
 ## Single-Report Flow
 
-`GenerateDetailed` resolves the requested report and output destination before initializing an optional explicit debug writer. An explicit output file wins; otherwise the configured output directory is used, falling back to the captured working directory. Output preflight validates the final filename, permits only an absent or regular final destination, and validates the bounded same-directory temporary form without creating a missing parent. It then validates the report's generated-text catalog binding, exact Promptkit prompt, and selected profile before collecting weather data. Profile inspection requires a model, permits an empty backend identity for endpoint-only profiles, and leaves inherited resolution and optional credential sources to Promptkit. The resolved profile, backend, and model are carried in the active result.
+`GenerateDetailed` resolves the requested report and output destination before initializing an optional explicit debug writer. An explicit output file wins; otherwise the configured output directory is used, falling back to the captured working directory. Output preflight validates the final filename, permits only an absent or regular final destination, and validates the bounded same-directory temporary form without creating a missing parent. It then validates the report's generated-text catalog binding, exact Promptkit prompt, and selected profile before collecting weather data. Profile inspection requires a model, permits an empty backend identity for endpoint-only profiles, and leaves inherited resolution and optional credential sources to Promptkit. The resolved profile, backend, model, and actual repair count (once a completed execution exists) are carried in the active result; the configured repair budget remains part of the exact prompt contract.
 
 The workflow builds facts, a module snapshot, briefing metadata, and the YAML prompt package in memory. It executes Promptkit only against the inspected prompt and profile, reconciles the preparation callback and completed result with that identity and the prepared report schema, validates the returned generated text, builds a render context, and renders Markdown. `fileutil` writes the completed Markdown through a same-directory temporary file, rechecks the final destination and context after close and immediately before the atomic rename. Only after that write succeeds does single-report notification run.
 

docs/internal/prepared-report.md

@@ -21,8 +21,9 @@ Before accepting generated JSON, the execution boundary reconciles the prepared
 report definition, inspected prompt hash and selected profile identity, the one
 preparation callback, and the completed Promptkit result. The callback and
 completion must agree on prompt, profile, backend, model, and rendered/input
-hashes; the callback output and completed validation must name the prepared
-report's JSON Schema. A mismatch produces no rendered Markdown and leaves
+hashes; the callback output must also carry the prepared report's configured
+repair budget, while the completed validation records the actual corrective
+calls used within that budget. A mismatch produces no rendered Markdown and leaves
 results with only the inspected safe identity.
 
 Single-report generation executes one prepared profile and publishes its

docs/roadmap/implementation.md

@@ -286,6 +286,8 @@ GOWORK=off go test -race -count=1 ./internal/adapters/promptkit
 
 ### Stage 5: Carry Repair Provenance Through Application Workflows
 
+Status: Complete.
+
 Purpose: make application orchestration understand configured and actual repair
 counts before changing the embedded prompt policy.