Skip to content

Four record gates return rc 0 on a document containing literal conflict markers #1417

Description

@localai-bot

Found by the fresh review of #1414, and proven by mutation rather than argued.

The gap

Splice three literal conflict markers (<<<<<<<, =======, >>>>>>>) and a duplicated keyed row into docs/STATUS.md, and every record gate still passes:

Checker rc on the mangled file
scripts/check-public-doc-tables.py 0, with its normal OK message
scripts/check-agent-record.py 0
scripts/check-doc-checkpoint.py 0
scripts/check-issue-index-append-only.py 0

No script under scripts/ mentions conflict markers at all. That was checked with an unpiped grep whose pattern was first proven against a positive control, so it is a measured absence and not a failed search.

Mutation record: the mutation asserted its own application before writing, git diff --stat showed 1 file changed, 4 insertions, and the tree was restored byte-identically afterwards (sha256 verified).

Why it matters here

This is not hypothetical. An earlier revision of #1414's branch carried a docs/STATUS.md that had been mangled by stale working-tree state leaking in from a pre-squash branch, together with an unrelated spec file deleted outright. The full record gate set was run against it and reported clean. It was caught by a person reading git diff --stat and noticing a path nobody meant to touch.

The general shape is the one this repository keeps rediscovering: a gate that cannot say what it examined has not reported. check-public-doc-tables.py validates cell and row budgets and em-dashes; check-agent-record.py validates counts and anchors. Neither asks whether the file is well-formed markdown in the first place, so a table row that is half one branch and half another satisfies every budget it is measured against.

What would close it

The cheap fix is a single check, in one place rather than four, that refuses any tracked text file containing a line matching ^<<<<<<< , ^>>>>>>> , or a bare ^=======$ adjacent to one. It belongs wherever the pre-push record gates already run, so it cannot be forgotten by a checker that has no other reason to read the file.

The red-first test writes markers into a scratch copy and asserts a NON-ZERO exit, and the mutation deletes the check and asserts the test goes green — otherwise the new gate has the same defect it was added to fix.

Two cautions for whoever takes it. A working-tree mutation of an append-only file returns rc 0 and looks like a gate that cannot detect it, so mutate with a detached scratch commit where commit-reading checkers are involved. And a checker that resolves its repository root from its own path reads the SHARED checkout when run from a worktree, which can make a test vacuous while printing OK.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions