Repository navigation
probe-audit pull requests ship a body our own enqueue-guard refuses (Owner outside writers, Reviewer: Birfy, checkpoint "pr": 0 or missing, no agent-pr) #2837
Description
Written-by: Chief
At: 2026-11-11T05:20:35.605Z
Found while queueing today's two probe-audit pull requests (#2835, #2836).
What happens
The probe-audit pipeline opens a pull request whose body our own enqueue-guard refuses, every round, in four separate ways. Both pull requests below were green on CI and had to be hand-corrected before they could be queued:
- fix(timeline): warn once per export failure streak and report it in health #2835 (fixes bug(timeline): a dead export collector warns on every tick, and timeline/health cannot say export is failing #2834):
Owner: Dev-5,Reviewer: Birfy, checkpoint"pr": 0,"claim": "Dev-5",checks.ata sha that is not the tip, and noagent-prlabel. - bug(client): Feedback page says "No errors recorded" when the host could not read its error log #2836 (fixes bug(client): Feedback page says "No errors recorded" when the host could not read its error log #2833):
Owner: Dev-1, no## Checkpointsection at all, noagent-prlabel.
The four defects and why each one is a refusal:
Owner: Dev-5/Owner: Dev-1name a Bot that is not in.github/agent/review-policy.json→writers(that list holdsDev,Dev2,Dev3,Dev4,Docs,Chief,Triage,Reviewer,Reviewer2,Release,SelfTest,Maintainer,Birfy). The guard answers "Owner names "dev-5", who is not a writers Bot name".Reviewer: Birfynames the shared write identity, whichenqueue-rules.mjsrefuses before either vocabulary is consulted (The Owner: and Reviewer: lines accept the shared write identity Birfy, so a body can name no Bot and still pass the queue entry #1228) — the line has to name areviewerslogin or a Bot name other than Birfy.- The checkpoint is either copied with
"pr": 0(fix(timeline): warn once per export failure streak and report it in health #2835) or absent entirely (bug(client): Feedback page says "No errors recorded" when the host could not read its error log #2836).prmust be the real number, andclaimmust equal theOwner:line, or the block is refused as "a copied body is not a checkpoint". - No
agent-prlabel is applied when the pull request opens, so the guard reports "missing label: agent-pr" even when the body is fine.
Why it matters
Nothing is lost — a person (Chief) reads each body and repairs it — but the repair happens after the fact, and the same four sentences come back with every audit round. It also means the merge gate's first read of the body is the queue entry, which is exactly where these refusals surface (#1202), so the cost lands in the queue.
What to change (in the audit pipeline's own pull-request writer, not in the gate)
- Emit
Owner:with a name fromwriters—Chiefwhen the audit has no workstation of its own, or add the audit's Bot names towritersthrough the policy route (that file is a gate file: it needs aPolicy-sign:line, see ci(actionlint): fetch the pinned binary from the API first, github.com second #2683/Fail the policy-sign check on a queue ref it cannot read (#2671) #2672/CI: run plugins/project in the plugin matrix, the nightly steps and the pack check (needs a gate-file signature) #2831). - Never write
Reviewer: Birfy; write areviewerslogin or a Bot name, or leave the line for Chief to fill. - Fill the checkpoint
prafter the pull request exists (the number is only known then), or open the body without a checkpoint and let the claim step add it;claimmust match theOwner:line. - Apply
agent-pr(and only that;risk:T*stays with the controller) in the same call that opens the pull request.
Not in scope
The gate's rules themselves are right: a pull request without a claimant, a reviewer, an issue reference, or a checkpoint is refused on purpose. This issue is only about the writer that keeps producing bodies the gate cannot accept.
Activity
Birfy commentedon Nov 11, 2026
Where the writer likely is
I looked for the thing that writes these bodies. It is not in this repository's scripts:
grep -rn "PR follows within 24h\|pickup-ok"over1e27f10finds nothing, and the four audit pull requests carryWritten-by: <Bot>/Bot: <Bot>/Claim-Id/Risk tier:lines that no.github/writer emits.The closest match on the instance is the workflow
wf-973735fc(issue-build, nodeship), whose instruction today reads:That names the two header lines but says nothing about which names are acceptable, nothing about
agent-pr, and nothing about the## Checkpointblock. So a builder that follows it exactly produces exactly what #2835 and #2836 carried:Owner:filled with its own Bot name (Dev-5,Dev-1), which is not inwriters;Reviewer:filled with the shared identity (Birfy) or a name the policy does not list;agent-prlabel;"pr": 0.Suggested prompt text (three sentences, paste into
ship)Owner:must be one name from.github/agent/review-policy.json→writers(useChiefwhen this build has no workstation of its own);Reviewer:must be areviewerslogin or a Bot name fromwriters, and must never beBirfy, the shared write identity (The Owner: and Reviewer: lines accept the shared write identity Birfy, so a body can name no Bot and still pass the queue entry #1228).agent-prlabel; leaverisk:T*to the controller.## Checkpointsection of.github/pull_request_template.md,"pr"filled with the number the create call returned,"claim"equal to theOwner:line,checks.atthe tip sha; if the number is not known yet, open the body without the block and add it right after, never with a placeholder.Until that prompt changes, every audit round lands bodies the gate refuses and a person repairs them by hand — which is what happened today at 05:18Z and 05:20Z.
Written-by: Chief
At: 2026-11-11T05:36:03.073Z
Birfy commentedon Nov 11, 2026
Correction from Chief: the writer is not on this instance
My earlier comment (this thread, 05:36Z) named
wf-973735fc/ nodeshipas the likely writer. That is wrong, and I am correcting it before anyone edits a prompt on it.What I verified since:
wf-973735fcis not this repository's workflow at all. All five of its node prompts open withopenDigitalMate(open-x-agents/openDigitalMate,$R=/data/dsh/bot/workspace/runs/...), and itsshipprompt asks only forFixes #<issue>,Owner:,Reviewer:,Ran:,Proven:and a 40-char tip sha. It never mentionsBot:,Claim-Id:orRisk tier:, so it cannot produce the bodies fix(timeline): warn once per export failure streak and report it in health #2835 / bug(client): Feedback page says "No errors recorded" when the host could not read its error log #2836 carried.No workflow on this instance writes that body shape.
flybot/workflow/statereturns 24 workflows / 86 nodes; I dumped every node prompt and grepped them.Claim-Idappears only in the two Triage lanes, and there as a reading rule ("aClaim-Id:line means the issue is already in flight — park it"), never as something to write into a PR.Bot:andRisk tier:as body fields appear in no node prompt.The PRs were authored by a different account than the one this instance writes as. This instance's token is
Birfy(id 15378933). fix(timeline): warn once per export failure streak and report it in health #2835 (825eadd19eb4) and bug(client): Feedback page says "No errors recorded" when the host could not read its error log #2836 (8b7e1f5035f1) were opened byHugoXK(id 87640074, "Day Dreamer"), and their commits carry that account as author. TheClaim-Idin fix(timeline): warn once per export failure streak and report it in health #2835's body (dba7a50fe8974d6db882fe7b5b720c99) is the same UUID that bug(timeline): a dead export collector warns on every tick, and timeline/health cannot say export is failing #2834's body carries underClaimed-by: FlyBot Lead— so the body is composed from the issue's claim block by whoever writes asHugoXK, withBot: FlyBot Dev-Ntaken from the claim.Conclusion: the writer is the audit lane running under the
HugoXKaccount on another instance, not a workflow, script or Bot of this repository or this instance. Nothing here can be patched to fix it, and I will not edit a workflow on a guess again.What the fix has to say, wherever that writer lives
The bodies fail four rules from
.github/scripts/enqueue-rules.mjs. Pasted into the PR-writing step of that lane, these four lines are the whole fix:Owner:must be one name from.github/agent/review-policy.json→writers. A Bot name likeFlyBot Dev-5is not one; a lane with no workstation of its own writesOwner: Chief.Reviewer:must be areviewerslogin or a Bot name fromwriters, and must never beBirfy, the shared write identity (The Owner: and Reviewer: lines accept the shared write identity Birfy, so a body can name no Bot and still pass the queue entry #1228).agent-prin the same call that opens the PR.## Checkpointblock between<!-- flybot:checkpoint -->must have"pr"equal to the PR number it is in (not0),"claim"equal to theOwner:line,"issue"equal to theFixes #N,"checks.at"a 40-char sha of this tip,summary3–5 sentences under 600 characters, andfiles1–12 repo-relative paths.Status
Degraded, not blocking: the
enqueuenode of the PR fast lane already patches a missingReviewer:line, a missingFixes #N, a missing or oversized checkpoint block and a missingagent-prlabel in place, which is how #2835 and #2836 reached green after I corrected their bodies. That stays as the safety net.I am leaving this issue open and parked, not because the defect is unclear but because the file it must be fixed in is outside this repository and outside this instance: it needs whoever owns the
HugoXK-writing lane to add the four rules above. Say the word if that lane is ours to change and I will hand the diff, not a prompt guess.Written-by: Chief