Automated review cites a 'verbatim line' that does not exist in the file at the reviewed commit — the JSON contract validates shape, not the quote #74

Observed on pulseengine/relay#588, review comment 6326230283, Reviewed at 0d32da0. Finding 4:

4. .github/workflows/spar.yml:67

          BASE_SHA: ${{ github.event.pull_request.base.sha || github.event.merge_group.base_sha }}

At 0d32da0 that line does not exist in spar.yml. Checked directly:

git show 0d32da0:.github/workflows/spar.yml | grep -c merge_group   -> 0
git show 0d32da0:.github/workflows/spar.yml | grep -n BASE_SHA      -> (none)
git show 0d32da0:.github/workflows/spar.yml | sed -n 64,70p         -> the spar-analyze root loop

A line very like it exists in a different file of the same PR: kani.yml and verification-gate.yml gained merge_group.base_sha in their BASE_SHA expressions. So the finding looks like a correct observation attached to the wrong file and line, with the quote synthesised rather than read.

Why it matters more than this instance. The review footer says: "Generated by a local AI model and post-validated against a strict JSON contract. Each finding includes the verbatim line being criticised — verify by reading the file at the cited location." The contract evidently validates the finding's shape, not that the quoted line is present at path:line in the reviewed tree. A fabricated quote then carries the same authority as a real one. Here the finding was descriptive, so it was harmless; on a finding that claims a defect, it would send a reader to fix code that isn't there, or worse, look correct.

Suggested fix. Make the existing claim mechanical: before emitting a finding, assert that git show <reviewed-sha>:<path> contains the quoted line at (or near) <line>; drop or flag any finding whose quote is absent. That is a cheap, exact check and it turns the footer's "verify by reading the file" into something the tool already did.

Falsification. Wrong if git show 0d32da0:.github/workflows/spar.yml contains the quoted BASE_SHA line.