Development record
The ingest verb permits re-ingesting a run id that already committed: run_id is payload-chosen and nothing refuses a second ingest, so the second write overwrites run.json while the first run's reading records stay in the ledger unnamed by any run record, and a later refusal can drop refusal.json beside an existing run.json so one run directory asserts both that it committed and that it was refused. spc-63 and ingest.go both say a rerun is a new run with a new run id, never an amendment; that is a comment rather than a check.
issueresolvedminoriss-2608311230305308
The ingest verb permits re-ingesting a run id that already committed: run_id is payload-chosen and nothing refuses a second ingest, so the second write overwrites run.json while the first run's reading records stay in the ledger unnamed by any run record, and a later refusal can drop refusal.json beside an existing run.json so one run directory asserts both that it committed and that it was refused. spc-63 and ingest.go both say a rerun is a new run with a new run id, never an amendment; that is a comment rather than a check.
Grounds
- pursued: the finding is closed by a test that fails without the change; a later review or mutation run finding the same shape again would show this wrong
Frontmatter
| id | iss-2608311230305308 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2608311230305308-the-ingest-verb-permits-re-ingesting-a.md
open on GitHub ↗ · commit history ↗
mentions1
- spc-63The cold-reading output contract: a strict per-position schema, a supply-regime gate, and a staged ingest that leaves evidence or nothing