main fails its own audit-live-rows --check gate: KERNEL-DFLASH2-GROUPED-CONV is an ABANDONED ACTIVE row

[localai-bot]

The audit-live-rows --check CI gate (.github/workflows/ci.yml:487) fails on main itself, so it reds every pull request that merges main.

Verified on a pristine main worktree

Detached worktree at origin/main (cae8ace0c), nothing else applied:

$ python3 scripts/audit-live-rows.py          # bare mode
rc=0
$ python3 scripts/audit-live-rows.py --check  # the mode CI runs
245 live rows; 1 abandoned ACTIVE; 18 PARTIAL rows to review; 3 IDs live in two matrices: …
rc=1

The offending row is KERNEL-DFLASH2-GROUPED-CONV, .agents/kernel-matrix.md:143, verdict ABANDONED — no branch, no commit on main mentioning the row ID.

Note the two modes disagree. Bare audit-live-rows.py exits 0; only --check exits 1. An agent baselining this briefly concluded the failure was its own because it ran the bare form — worth knowing for anyone reproducing, and arguably worth making the bare mode say that it is not the gate.

How it got here

The row arrived with 028438e68 (#1465, SPEC-DFLASH2), which landed on main without a completed CI verdict. That is the same mechanism as #1464 and #1403: of the last 25 main runs of the ci workflow, 16 are cancelled and 3 success, because ci.yml:122-124 applies cancel-in-progress to push as well as pull_request. A cancelled run is not a red, so nothing alerted.

This is a different and newer failure from #1464 — that one is five broken CPU test suites, this one is a records gate — but they share a cause and both block the same lane.

Why it needs an owner rather than a workaround

A gate that is red on main is worse than a gate that is absent: every PR inherits it, reviewers learn to baseline-subtract it, and the habit carries over to the day the red is genuinely theirs. That has already cost this repository once this week — #1415 carries a real device-leakage regression (DSR REGRESSION in bucket 'vt_ifdef': 35 > baseline 32) that three independent review passes missed, because CI never completed during any of them.

What would close this

Either the row is genuinely live and owes a branch or a commit that names its ID, or it is genuinely abandoned and its matrix row should say so. Do not silence the checker — .agents/-level policy is explicit that a red gate must not be made green by deleting an assertion or widening its scope, and this gate is doing exactly the job it was written for. It found a real record defect.

The row's owner is the SPEC-DFLASH2 lane; #1314 and #1404 are the DFlash2 porting rows and are not this record defect.

Related: #1464, #1403, #1285, #1316.

[localai-bot]

Verified fixed on main. On a pristine detached worktree at origin/main:

python3 scripts/audit-live-rows.py --check
250 live rows; 0 abandoned ACTIVE; 18 PARTIAL rows to review; 3 IDs live in two matrices: …
rc=0

0 abandoned ACTIVE where it previously read 1, and the gate now exits 0. KERNEL-DFLASH2-GROUPED-CONV no longer trips it. Fixed on main by 6b48edb2c; test_audit_live_rows is green again on branches that merge it.

The mechanism that let it land unverified in the first place is still open — see #1403 (16 of the last 25 main CI runs cancelled) — and the other main breakage it arrived alongside, #1464, is still open.

One note for whoever touches this checker next: bare audit-live-rows.py exits 0 while --check exits 1, and an agent baselining this concluded the failure was its own because it ran the bare form. Worth making the bare mode say it is not the gate.

[localai-bot]

The closure stands, but the gate went green for the wrong reason — worth knowing before trusting that signal again.

Independently re-measured on a detached worktree at origin/main = 6b48edb2c, nothing applied:

python3 scripts/audit-live-rows.py          -> rc=0
python3 scripts/audit-live-rows.py --check  -> rc=0
250 live rows; 0 abandoned ACTIVE; 18 PARTIAL rows to review

So the row resolves. But look at what resolves it:

| `KERNEL-DFLASH2-GROUPED-CONV` | `ACTIVE` | .agents/kernel-matrix.md:143 | LANDED |
  on main: 206afb639 feat(LTX25-DEVICE-RESIDENCY W5): a vt::Conv3d op, and the
  decode that finally dispatches to it (#1007) (#1462) | - |

206afb639 is an LTX-2.5 commit. It names KERNEL-DFLASH2-GROUPED-CONV in its body only in passing, while discussing a kernel count:

for `KERNEL-DFLASH2-GROUPED-CONV`; this branch bumped 52 -> 53 for

All three commits on main that mention the row ID are LTX-2.5 commits doing the same thing (206afb639, 7481a2eec, fdefb4529). The commit that actually landed the kernel — 028438e68, "the grouped dynamic depthwise convolution" (SPEC-DFLASH2 W2, #1314, PR #1465) — never names the row ID at all; its subject and body cite SPEC-DFLASH2 and #1314.

The kernel did land (git log -S'DFlashGroupedConvKernel' -- src/vt/cpu/cpu_ops.cpp returns 028438e68, and tests/vt/test_ops_dflash2_grouped_conv.cpp exists), so the row is genuinely live and closing this is right.

The point is the instrument. audit-live-rows.py asks whether any commit on origin/main mentions the row ID as a whole token. An unrelated commit that happens to quote the ID in prose satisfies that, so this gate would have stayed green even if the kernel had never landed — and conversely, it was red for a fortnight while the kernel was on main, because the landing commit used the row's issue number instead of its ID. The signal tracks whether somebody typed the string, not whether the work exists.

Two consequences worth carrying forward:

1. A green audit-live-rows --check is not evidence that a row's work landed. Confirm with git log -S on a symbol, as above.
2. Landing commits that name only the issue number leave their row looking abandoned. 028438e68 naming KERNEL-DFLASH2-GROUPED-CONV would have kept this gate honest in both directions.

Also worth recording, since it cost an earlier session a wrong conclusion: the two modes disagreed while this was red. audit-live-rows.py alone returned rc 0 and printed the abandoned count as text; only --check (the mode CI runs, ci.yml:487) returned rc 1. An agent baselining with the bare form read its own red as its fault. #1469 records the same split from the other side.

Measured at 6b48edb2c while running the origin/main measurement for #1464.