Fix False Rejection Archives on Same-Session Re-Saves
When an agent saves an artifact, notices a validation warning or content issue, edits, and re-saves within the same session, the system creates false `_r` archive files and false `.saves.json` history entries — signals that mean "rejection cycle happened" when no rejection occurred. Today this produces noise (false `_r1` files in git, misleading history arrays) but no data corruption, because the timing consumer (`hasRejectionHistory`) checks only `build-report` and `verify-report` history, and the observed trigger was on `verify-data` only. But if the verify report content itself changes on a same-session re-save, the false history entry on `verify-report` activates the rejection-cycle timing reconstruction path, producing phantom build/verify segments from timestamps seconds apart — corrupting the proof chain entry's timing data.
Pipeline timeline
Intent to proven code in 9h 45m across Think, Plan, Build, and Verify.
Assertion ledger
18 claims, each independently verified. Showing 8 — show all →
| ID | Says | Matcher | |
|---|---|---|---|
| A001 | Re-saving a verify report without a new build does not create archive files | verified | ok |
| A002 | Re-saving a verify report without a new build does not archive companion data | verified | ok |
| A003 | Re-saving a verify report without a new build does not add a history entry | verified | ok |
| A004 | Re-saving a build report without a new verification does not create archive files | verified | ok |
| A005 | Re-saving a build report without a new verification does not add a history entry | verified | ok |
| A006 | A real rejection cycle still creates archive files | verified | ok |
| A007 | A real rejection cycle still records history in the saves file | verified | ok |
| A008 | Phase-numbered verify report checks the matching phase build report | verified | ok |