Repository navigation
review-alarm: 20 PR(s) unreachable by every review producer #4554
Description
Activity
🤖 SPARQ agent
This alarm, and two defects I filed independently tonight, look like one root cause. Recording the
link so nobody re-derives it.The alarm's own diagnosis is the key line
5 open PR(s) have no countable review verdict and are unreachable by every review producer —
verdict PRODUCTION, not transport, is the stalled stageThat is precise and, I believe, correct. Here is a mechanism that produces exactly it.
Candidate root cause: a PR with no closing reference is silently excluded from the verdict store
Filed as jeswr/agent-account-registry#1231.
auto-mint-provenancerefuses any PR whose body
lacks a closing reference withno-issue-reference, and the refusal is silent to the author.
The verdict store onledgeris what every automated consumer reads to decide whether a PR has been
reviewed — so such a PR is structurally outside review provenance no matter how many times it is
actually reviewed.Concrete, measured instance: registry PR #756 has six review rounds and seven line-anchored
verdicts, and zero ledger records. I briefed an agent that it had "never been reviewed" — the
reviews were all there in comments; the machine record was not. That cost ~2.3 h re-reviewing
already-reviewed work.⚠️ This matches "verdict production, not transport" exactly: the reviews are produced and posted;
they never become countable.Second, independent contributor: lane invisibility by head-ref shape
Filed as agent-account-registry#657.
dispatch-claim.py:347admits only
^sparq-agent/issue-(\d+)-, so 21 of 100 open sparq PRs (18 non-draft) are invisible to the
review lane. Ten were CLEAN-and-unarmed, seven carryingreview:changesfor 2–23 days with nothing
able to service them.⚠️ Note:1518: the head-ref shape is paired with #570's exact-App author gate, so provenance is
already a conjunction. The fix belongs on the author side, not by loosening the ref regex —
widening it would let any pushable branch present itself as pipeline-owned on a public repo.Why the alarm is doing its job
The alarm is not the problem — it is the only thing that caught this. It fires, names the count,
distinguishes production from transport, and maintains this issue. Three separate paths found the
same class tonight and only this one found it automatically.⚠️ So do not silence or threshold it. If the count is uncomfortable, the population is the thing
to fix.Suggested check for whoever picks this up
For each PR the alarm names, record (a) whether its body carries a valid closing reference
(keyword + one-or-more spaces/tabs +#<n>), and (b) whether its head ref matches
HEAD_REF_RE. My prediction is that every one fails at least one. If that holds, #1231 and #657
are the fix and this alarm closes as a consequence. If it does not hold, there is a third producer
gap and that is the more valuable finding — I would rather be wrong here.Small discrepancy worth resolving: the annotation on the current
mainrun says 5 PRs, this
issue's title says 7. Probably two different runs, but if the alarm's own count moves between the
annotation and the issue body, that is worth a look on its own.- changed the title
[-]review-alarm: 7 PR(s) unreachable by every review producer[/-][+]review-alarm: 20 PR(s) unreachable by every review producer[/+]on Sep 28, 2026 Closing as obsolete: the workflow or script this issue is about was removed in #6673, which retired the autonomous agent fleet and its CI machinery (ci-fast is now the only required check). If the underlying concern still applies to the remaining CI, reopen this or open a fresh issue.
Generated by Claude Code
review-alarm: 25 open PR(s) have gone more than 24h with no countable review verdict, and no review producer can ever reach them.These PRs fail the registry review lane's author-side admission gates (
enumerate_review_itemsin the registry'sscripts/dispatch-claim.py): the head ref does not match^sparq-agent/issue-([1-9][0-9]*)-, and/or the author is not the worker App bot. That lane is the only verdict producer sparq has, so nothing will ever dispatch a review for them without a human or an orchestrator doing it by hand.sq-vvu9d-zksparql-specneeds:userwas applied by @sparq-orchestrator[bot] as a MACHINE write — it is not a human's open decision and buys no exemption; self-review by the PR author @jeswr (never countable)feat/vectors-bigendian-sq-i7wneeds:userwas applied by @sparq-orchestrator[bot] as a MACHINE write — it is not a human's open decision and buys no exemptionci/batch-merge-v2-bisectionresearch/crate-region-parallelismfix/cron-lane-liveness-4328fix/frontier-headroom-attribution-5119dependabot/npm_and_yarn/multi-5db45a0b5adependabot/npm_and_yarn/ip-address-10.4.0dependabot/github_actions/errata-ai/vale-action-3.0.0feat/ak-migration-bench-reruncodex/throughput-slorelease-plz-2026-08-31T23-23-10Zcodex/sol-impl-opus-reviewdependabot/npm_and_yarn/multi-c073259809dependabot/npm_and_yarn/fastify-5.12.1dependabot/npm_and_yarn/js-yaml-4.3.2codex/update-comparator-raw-duplicatescodex/zk-disclosure-implementationdependabot/github_actions/actions/setup-java-6.0.1codex/release-v0.1.4-recoverycodex/vc-eddsa-rdfc-vectorsdependabot/github_actions/actions-minor-patch-a83d9ccee8dependabot/npm_and_yarn/multi-211fa015e3dependabot/npm_and_yarn/ip-address-10.7.2dependabot/npm_and_yarn/crates/sparq-shacl/tests/diff_fuzz/undici-6.29.0Census of every state exit (open PRs in
sparq-org/sparq):A verdict is countable only when it is line-anchored (
VERDICT: pass|failas the comment's last non-blank line), names the current head as a standalone 40-hex SHA, and was not posted by the PR's own author.A
needs:user/review:needs-userhold exempts a PR from this alarm only when a HUMAN applied it — resolved from thelabeledtimeline event, and downgraded to a machine write when an orchestrator-authoredclass=<reason>park receipt lands within 300s of it (sparq#4911).hold-owner-machinein the census counts holds that bought no exemption;hold-owner-unknowncounts holds whose applier could not be resolved, which stay exempt.