Plan resilient processing and focused run reports

This commit is contained in:
2026-09-24 16:50:21 +00:00
parent cb405f6fc7
commit 8ffbf41b89
2 changed files with 697 additions and 604 deletions

File diff suppressed because it is too large Load Diff

View File

@@ -2,9 +2,9 @@
**Last updated:** 2026-09-24
**Status:** Feature direction agreed; not implemented. This document defines the
target behavior and user intent, not a staged implementation plan. Remaining
interface details are listed under Open Questions.
**Status:** Target behavior agreed; not implemented. This document defines the
desired end state and user intent. Concrete design decisions and implementation
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
old report formats or expose raw library structures.
applicable. The implementation plan specifies the versioned schemas; neither old
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
detail. Preserve the existing overwrite convention: a new run can replace files
with an explicit report-directory selection, defaulting to the invocation working
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
ConfigKit-backed setting/override design to be finalized. Debug artifacts may use
JSON where useful. Preserve configured-secret redaction in every presentation.
Use a single ConfigKit-backed debug boolean with a `--debug` CLI override. Debug
artifacts may use JSON where useful. Preserve configured-secret redaction in every
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
[runtime follow-up](runtime-behavior.md); the legacy `never` behavior must not
quietly become the meaning of the new reporting-disable option.
workflow. Enabled debug output is retained on success or failure; disabled debug
creates no debug directory. This supersedes the retention question in the
[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,
internal, and architecture documentation. This roadmap does not change their
current implemented contracts.
- Canonical CLI, configuration, operations, integration, internal, and architecture
documentation describes the implemented final behavior. Until implementation,
this roadmap does not change their current implemented contracts.
## Open Questions
## Implementation Reference
The product choices above replace the earlier alternatives and user comments.
Remaining details belong in the eventual decision-complete implementation plan:
- Select exact CLI/configuration names and precedence for reporting enablement,
debug, and the report directory for stdout runs. Reports for file-output runs
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.
The product decisions are settled. [implementation.md](implementation.md) defines
the selected settings and precedence, YAML schemas, counts and ordering, interrupted
work presentation, destination checks, and output finalization. It also owns the
ordered implementation stages and validation work. This document remains the
reference for the desired behavior and its acceptance criteria.