Problem
A run's result exists only as console text. Once the terminal buffer is gone, or when the caller is a program that did not capture stdout, there is no way to find out what happened except to run the build again. Exit codes are coarse as well: a restore failure, a compile error, and a failing test are indistinguishable to the caller.
Outcome
Every run leaves a machine-readable record on disk, and the exit code says what class of failure occurred.
- A summary at a known path (proposal:
.fallout/last-run.json) with per-target status, duration, the diagnostics that target produced, and the artifacts it wrote.
- Diagnostics carry a stable identity — severity, code, file, line, message — rather than prose.
- Distinct exit codes per failure class, documented and stable.
Acceptance criteria
Notes
This complements #391 (Serilog event core plus NDJSON machine path), which covers the live event stream but not a durable artifact or exit codes. .fallout/temp is already cached by every CI workflow, so a sibling path needs no new workflow plumbing.
Problem
A run's result exists only as console text. Once the terminal buffer is gone, or when the caller is a program that did not capture stdout, there is no way to find out what happened except to run the build again. Exit codes are coarse as well: a restore failure, a compile error, and a failing test are indistinguishable to the caller.
Outcome
Every run leaves a machine-readable record on disk, and the exit code says what class of failure occurred.
.fallout/last-run.json) with per-target status, duration, the diagnostics that target produced, and the artifacts it wrote.Acceptance criteria
Notes
This complements #391 (Serilog event core plus NDJSON machine path), which covers the live event stream but not a durable artifact or exit codes.
.fallout/tempis already cached by every CI workflow, so a sibling path needs no new workflow plumbing.