What
scripts/audit-live-rows.py --check exits 1 on PR #431 with 1 abandoned ACTIVE, and passes on main with 0. The row it flags is BACKEND-TENSTORRENT-MISTRAL, whose implementation is in that very PR.
Run locally with the contributor's fork ref present, the same row reads:
| `BACKEND-TENSTORRENT-MISTRAL` | `ACTIVE` | IN-FLIGHT | unmerged commits on luzero/row/BACKEND-TENSTORRENT-MISTRAL | - |
222 live rows; 0 abandoned ACTIVE — exit 0.
Why CI disagrees
.github/workflows/ci.yml:316:
git fetch -q origin +refs/heads/main:refs/remotes/origin/main
python3 scripts/audit-live-rows.py --check
Only main is fetched. The audit distinguishes LANDED (commits naming the row on origin/main) from IN-FLIGHT (commits on a branch not yet on origin/main) from ABANDONED (neither). With no branch refs in the checkout, IN-FLIGHT is unreachable — so a row whose work is genuinely in flight is indistinguishable from one nobody is working on.
The script's own require_origin_main() docstring names exactly this hazard for a different input:
"An unfetched or missing origin/main would therefore make EVERY row look abandoned ... Absence of work and absence of information must never look the same."
The same principle applies to the branch side, and it isn't guarded there.
Consequence
Any PR that moves a row to ACTIVE before its code lands fails agent-record, deterministically. That is the normal shape of the work — the row goes ACTIVE, the implementation arrives in the same PR — so this is not an edge case. It hits external contributors hardest, since their branch lives on a fork that CI never fetches at all.
Combined with the other two ways agent-record currently fails for reasons unrelated to the change under test — the fork-ancestry abort in check-commit-trailers.py:281, and the integration step asserting all sibling checks are completed-success while they are still running — a red agent-record on a fork PR presently carries close to zero signal. That is the real cost: a gate people learn to ignore.
Possible fixes
- Have the audit consider
HEAD as a branch source. On a PR, HEAD is the merge commit and already contains the row's commits, so IN-FLIGHT becomes reachable with no extra fetch.
- Or fetch the PR head ref in the workflow step alongside
main.
- Either way,
--check should distinguish "no information about branches" from "no branch work exists", and fail closed on the former rather than reporting ABANDONED.
Found while landing #431 (#670). Not caused by that PR — reproduced by running the audit on main (clean) versus the PR branch with and without a fork ref present.
What
scripts/audit-live-rows.py --checkexits 1 on PR #431 with1 abandoned ACTIVE, and passes onmainwith0. The row it flags isBACKEND-TENSTORRENT-MISTRAL, whose implementation is in that very PR.Run locally with the contributor's fork ref present, the same row reads:
222 live rows; 0 abandoned ACTIVE— exit 0.Why CI disagrees
.github/workflows/ci.yml:316:Only
mainis fetched. The audit distinguishesLANDED(commits naming the row onorigin/main) fromIN-FLIGHT(commits on a branch not yet onorigin/main) fromABANDONED(neither). With no branch refs in the checkout,IN-FLIGHTis unreachable — so a row whose work is genuinely in flight is indistinguishable from one nobody is working on.The script's own
require_origin_main()docstring names exactly this hazard for a different input:The same principle applies to the branch side, and it isn't guarded there.
Consequence
Any PR that moves a row to
ACTIVEbefore its code lands failsagent-record, deterministically. That is the normal shape of the work — the row goesACTIVE, the implementation arrives in the same PR — so this is not an edge case. It hits external contributors hardest, since their branch lives on a fork that CI never fetches at all.Combined with the other two ways
agent-recordcurrently fails for reasons unrelated to the change under test — the fork-ancestry abort incheck-commit-trailers.py:281, and the integration step asserting all sibling checks arecompleted-successwhile they are still running — a redagent-recordon a fork PR presently carries close to zero signal. That is the real cost: a gate people learn to ignore.Possible fixes
HEADas a branch source. On a PR,HEADis the merge commit and already contains the row's commits, soIN-FLIGHTbecomes reachable with no extra fetch.main.--checkshould distinguish "no information about branches" from "no branch work exists", and fail closed on the former rather than reportingABANDONED.Found while landing #431 (#670). Not caused by that PR — reproduced by running the audit on
main(clean) versus the PR branch with and without a fork ref present.