You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ERROR: canonical issue files are invalid: _intake Frozen archive evidence must equal the declared line in the frozen archive source
Root cause: two gates are mutually unsatisfiable for this record
.agents/issues/GATE-ISSUE-INDEX-TABLE-SHAPE/ISSUE-GH-1033.md is an _intake record. Its ## Problem must quote the frozen archive row byte-for-byte — _archive_evidence_matches_source (scripts/issue_records.py:306-320) demands exact UTF-8 equality against .agents/completed/issue-index.md line 350.
Commit e3539d994 ("re-point 640+ dangling record links") rewrote the quote's spec link from ../specs/gate-issue-index-table-shape.md to ../../specs/gate-issue-index-table-shape.md:
the archive row sits in .agents/completed/, where ../specs/... resolves correctly;
the record sits in .agents/issues/GATE-ISSUE-INDEX-TABLE-SHAPE/, where the quote only resolves with ../../specs/....
check-links (scripts/check-agent-record.py:620) requires every link in a record to resolve; the frozen-evidence check requires the quote to be byte-identical to the archive line. One string cannot satisfy both. Measured: first divergence at column 2191; the archive line is 2237 chars, the evidence 2240.
At e3539d994^ (6c6e4a9cc) the archive file did not exist in the tree at all, so there is no last-green commit to revert to: the defect landed together with the file it compares against.
The design question a one-line fix must answer
Restoring ../specs/ makes --check green but re-breaks check-links for this record (dangling link). Keeping ../../specs/ keeps links green and --check permanently red. The real fix is a decision:
Compare the frozen evidence with the same link-normalization check-links applies, so both gates read one truth — the check's purpose is "the quote is faithful to the archive", and faithfulness survives a link rebase; byte-equality is stronger than the purpose needs and is exactly what made the two gates collide.
Exempt the quoted frozen-evidence block from check-links in _intake records (it is a quotation, not a navigation link).
Found while probing the base tree for #3347 (all 12 of my open PRs rebase onto
d15b1cc09).Reproduce
Root cause: two gates are mutually unsatisfiable for this record
.agents/issues/GATE-ISSUE-INDEX-TABLE-SHAPE/ISSUE-GH-1033.mdis an_intakerecord. Its## Problemmust quote the frozen archive row byte-for-byte —_archive_evidence_matches_source(scripts/issue_records.py:306-320) demands exact UTF-8 equality against.agents/completed/issue-index.mdline 350.Commit
e3539d994("re-point 640+ dangling record links") rewrote the quote's spec link from../specs/gate-issue-index-table-shape.mdto../../specs/gate-issue-index-table-shape.md:.agents/completed/, where../specs/...resolves correctly;.agents/issues/GATE-ISSUE-INDEX-TABLE-SHAPE/, where the quote only resolves with../../specs/....check-links(scripts/check-agent-record.py:620) requires every link in a record to resolve; the frozen-evidence check requires the quote to be byte-identical to the archive line. One string cannot satisfy both. Measured: first divergence at column 2191; the archive line is 2237 chars, the evidence 2240.At
e3539d994^(6c6e4a9cc) the archive file did not exist in the tree at all, so there is no last-green commit to revert to: the defect landed together with the file it compares against.The design question a one-line fix must answer
Restoring
../specs/makes--checkgreen but re-breakscheck-linksfor this record (dangling link). Keeping../../specs/keeps links green and--checkpermanently red. The real fix is a decision:check-linksapplies, so both gates read one truth — the check's purpose is "the quote is faithful to the archive", and faithfulness survives a link rebase; byte-equality is stronger than the purpose needs and is exactly what made the two gates collide.check-linksin_intakerecords (it is a quotation, not a navigation link).Option 1 seems right to me; happy to file the row and send the PR once a maintainer picks a direction.