Plan resilient processing and focused run reports

docs/roadmap/resilience.md

@@ -2,9 +2,9 @@
 
 **Last updated:** 2026-09-24
 
-**Status:** Feature direction agreed; not implemented. This document defines the
+**Status:** Target behavior agreed; not implemented. This document defines the
-target behavior and user intent, not a staged implementation plan. Remaining
+desired end state and user intent. Concrete design decisions and implementation
-interface details are listed under Open Questions.
+steps are recorded in [implementation.md](implementation.md).
 
 ## Purpose and User Intent
 
@@ -173,12 +173,12 @@ Reporting is enabled by default. The ordinary bundle is:
 Write all three documents, including empty event lists for uneventful completed
 runs. Use Audita-owned schemas with safe explanations and stable reason codes;
 retain run, stage-instance, chunk, operation, and validator/batch identities where
-applicable. Exact schemas are detailed-design work, not a reason to preserve the
+applicable. The implementation plan specifies the versioned schemas; neither old
-old report formats or expose raw library structures.
+report formats nor raw library structures define the new output contract.
 
 Place reports beside the output transcript. Retain transcript-to-stdout support
-with an explicit report-directory selection; its default is a remaining interface
+with an explicit report-directory selection, defaulting to the invocation working
-detail. Preserve the existing overwrite convention: a new run can replace files
+directory. Preserve the existing overwrite convention: a new run can replace files
 at its selected destinations. Do not add a mandatory fresh-directory restriction
 or compatibility exports.
 
@@ -209,9 +209,9 @@ and finalization must not depend on retaining a debug run directory.
 
 Production issue records are compact. Full responses, transcript excerpts,
 correction lists, and complete validation decisions are opt-in debug evidence.
-Use a single debug boolean, with `--debug` as the proposed CLI spelling and a
+Use a single ConfigKit-backed debug boolean with a `--debug` CLI override. Debug
-ConfigKit-backed setting/override design to be finalized. Debug artifacts may use
+artifacts may use JSON where useful. Preserve configured-secret redaction in every
-JSON where useful. Preserve configured-secret redaction in every presentation.
+presentation.
 
 Debug-off prevents detailed artifact persistence; writing and later deleting
 those files is insufficient. In-memory domain state needed to process candidates
@@ -220,9 +220,12 @@ selections and do not alter processing behavior.
 
 There is no obligation to retain `--report-json`, old artifact layouts, parallel
 exports, or old retention settings. Reuse code only where useful to the new
-workflow. Resolve the disposition of debug retention alongside the existing
+workflow. Enabled debug output is retained on success or failure; disabled debug
-[runtime follow-up](runtime-behavior.md); the legacy `never` behavior must not
+creates no debug directory. This supersedes the retention question in the
-quietly become the meaning of the new reporting-disable option.
+[runtime follow-up](runtime-behavior.md). The legacy `never` behavior is not the
+meaning of the new reporting-disable option. Optional debug-write failures produce
+a safe stderr diagnostic without changing correction decisions or the run exit
+status; ordinary report and transcript-write failures retain their fatal semantics.
 
 ## Deterministic Human-Facing Presentation
 
@@ -274,21 +277,14 @@ volume, and a short reason breakdown. Detailed inspection belongs in YAML or deb
   batches with successful survivors, total failure, fatal cancellation, output
   failures, and reporting/debug selections. Preserve domain safeguards, capacity
   limits, and redaction.
-- On implementation, update canonical CLI, configuration, operations, integration,
+- Canonical CLI, configuration, operations, integration, internal, and architecture
-  internal, and architecture documentation. This roadmap does not change their
+  documentation describes the implemented final behavior. Until implementation,
-  current implemented contracts.
+  this roadmap does not change their current implemented contracts.
 
-## Open Questions
+## Implementation Reference
 
-The product choices above replace the earlier alternatives and user comments.
+The product decisions are settled. [implementation.md](implementation.md) defines
-Remaining details belong in the eventual decision-complete implementation plan:
+the selected settings and precedence, YAML schemas, counts and ordering, interrupted
-
+work presentation, destination checks, and output finalization. It also owns the
-- Select exact CLI/configuration names and precedence for reporting enablement,
+ordered implementation stages and validation work. This document remains the
-  debug, and the report directory for stdout runs. Reports for file-output runs
+reference for the desired behavior and its acceptance criteria.
-  belong beside the transcript; the stdout report-directory default is not yet set.
-- Finalize YAML versions/fields, machine identifiers versus human chunk labels,
-  operation-volume denominators, deterministic record order, and failed/not-attempted
-  presentation without changing the agreed counting or fixed table layout.
-- Specify how destinations are checked without destructive transcript truncation,
-  finalization order, path-collision handling, and debug placement/retention. Keep
-  ordinary filesystem behavior proportionate; do not add a transaction framework.