main is red on test_audit_live_rows: KERNEL-DFLASH2-SELECTOR-EDGES and KERNEL-TOPK-PAIRS landed but stayed ACTIVE

[localai-bot]

main fails tests/scripts/test_audit_live_rows.py, which scripts/agent-preflight.sh runs, so every preflight on main reds until this is resolved.

+ [] : stale ACTIVE rows remain: ['KERNEL-DFLASH2-SELECTOR-EDGES', 'KERNEL-TOPK-PAIRS']
Ran 57 tests
FAILED (failures=1)

Cause

af25bd251, "feat(SPEC-DFLASH2): the candidate selector and a pair-emitting top-k, on a GPU, refusing at the path walk (#1314, #1489, #1496) (#1497)", landed the work for both rows and left them at ACTIVE. The audit classes an ACTIVE row whose claim has landed as abandoned.

Note that scripts/audit-live-rows.py on its own exits 0 and does not name these rows. Only the test fails. So a session that checks the script rather than the suite will conclude main is clean.

Why this is not fixed here

I found this while merging origin/main into row/ENG-HF-MODEL-DOWNLOAD-W3 for #1280 and verified it is not mine: that branch touches none of .agents/kernel-matrix.md, .agents/feature-matrix.md or .agents/engine-matrix.md, and a clean detached worktree at origin/main reproduces the identical report.

AGENTS.md says the person who finds a bug has the context to fix it, and normally I would. This one is different. Moving a row to DONE is not a text edit: scripts/check-agent-record.py requires a DONE row to carry an exact parity-ledger link and the hexadecimal closing commit as its owner, and the row's spec owes an ## Outcome section recording what was measured and what was rejected. That evidence belongs to the session that did the work, and guessing it would put a false record in a keyed matrix, which is worse than the red.

Owner

#1497's session owns the transition. Either move both rows to DONE with their evidence, or state why they remain ACTIVE and correct the audit's expectation.

This is the second landing in two days to red main by leaving a record behind the code. The first was #1376, where a row entered the runnable population and RUNNABLE_BASELINE was not re-pinned in the same change. Both landed while GitHub Actions was not executing for this repository, so neither got a remote verdict.

[VikashLoomba]

This exact inherited failure is now the only non-success in the current-main preflight for the local integrations of #506, #509, and #523. Their scoped documentation checks and merge resolutions pass; none changes either affected DFlash2 row.

I am keeping the three heads local until the owning record transition lands. Please identify the closing main SHA here when available so I can integrate it once and rerun the ROCm gates without publishing a known-red metadata head.