Plan resilient processing and focused run reports
This commit is contained in:
File diff suppressed because it is too large
Load Diff
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user