Review jam: reviewer bee as a service, merger that reads the bee's discounted checks, publisher heading that passes check

Problem (measured 2026-10-03)

The review column on the Queen kanban does not drain.

auto-merge-ready-prs.yml merged 0 pull requests since 2026-09-20; all 300 merges in that window were by hand.
Its gate demands every check green. Advisory checks are red on nearly every pull request, and spec-guards is red on master itself, so that gate can never pass.
It is also cron-only: an approval waits up to an hour.
The reviewer bee (Reviewer bees approve under their own bot identity (t27-bees GitHub App) #5547, t27-bees[bot]) exists only as a session someone remembers to start.
Every pull request tools/queen/publish.py opens fails the required-by-convention check job. It writes # NOW -- <title> (published YYYY-MM-DD), and tools/check_now_entry_shape.py requires the heading to end in (YYYY-MM-DD). So a correct reviewer must refuse every queen pull request.

Change

tools/bees/reviewer.py runs the reviewer bee as a launchd service.
- The runner gathers the facts: the selection, the required checks from the ruleset, and each red check's failing step, log tail and conclusion on master.
- A sandboxed claude -p (--restricted --safe-mode --tools Read,Grep,Glob, no token in its environment) judges the pull request.
- The runner validates the verdict, re-reads the head, then approves and labels as t27-bees[bot].
- It runs several reviews at a time.
In auto-merge-ready-prs.yml, a red check passes only when all three hold: it is not required by the ruleset, it has concluded, and the bot's approval of that head carries discounted-check: <name> -- <why>. Required checks must be present and green. An unreadable ruleset fails closed.
The merger also runs on pull_request_target: labeled (bee-reviewed), so the bot's label merges at once. The cron stays as the backstop.
The publisher writes # NOW -- Published: <title> (YYYY-MM-DD). Its self-test runs the real check_now_entry_shape.check_entry on that entry, so the rule is not copied.

Original checks (kept for history; the Queen does not run these)

1. python3 tools/bees/reviewer.py self-test prints self-test: 0 failure(s)
1. python3 tools/bees/merger_gate_selftest.py prints merger gate self-test: 0 failure(s) of 26
1. the same self-test with MERGER_WORKFLOW pointing at master's copy of the workflow reports 4 failures (negative control: discounted red check, StatusContext, own run, required check never posted)
1. python3 tools/queen/publish.py --self-test prints ok: 26 shapes, and with the old heading restored it fails on "the entry this writes passes the check gate"
1. python3 tools/bees/reviewer.py run --dry-run --pr N on an open queen pull request writes a verdict and posts nothing

Original file list

tools/bees/merger_gate_selftest.py
tools/bees/reviewer.py
tools/check_now_entry_shape.py
tools/queen/publish.py

Queen-runnable restatement (2026-10-05)

Items 1-3 are Python and workflow YAML (open PR #5777), which the only-t27 rule refuses without the owner's label; item 4 is moot because master removed the NOW gate (0d5424b). The part a bee can do in t27 is to state the merger's discounted-check rule as a spec with tests, so the rule lives in one place.

Boundary

specs/queen/merger_gate.t27

User Scenarios & Testing

Given master, where no spec states when a red check may be discounted, when the rule spec lands, then its tests state that a red check passes only when it is not required, has concluded, and the bot's approval of that head names it in discounted-check:, and that an unreadable ruleset fails closed.

Requirements

FR-001: specs/queen/merger_gate.t27 MUST declare fn red_check_passes(required: bool, concluded: bool, discounted: bool) -> bool (true only when not required, concluded and discounted) and fn required_check_passes(posted: bool, green: bool) -> bool and fn gate_open(ruleset_readable: bool, all_checks_pass: bool) -> bool (false whenever the ruleset is unreadable).
FR-002: The change MUST NOT add or modify non-t27 hand-written code (specs/policy/own_language.t27).
FR-003: Tests MUST include the four negative controls named in the issue: a discounted required check, an unconcluded check, a required check never posted, an unreadable ruleset; plus one positive case, so the spec holds at least 5 tests.

Success Criteria

grep -cE 'fn (red_check_passes|required_check_passes|gate_open)' specs/queen/merger_gate.t27 prints 3
grep -cE '^[[:space:]]*test ' specs/queen/merger_gate.t27 prints at least 5
t27c test-report specs/queen/merger_gate.t27 2>&1 | grep -cE '^ (FAIL +0|pass +[1-9][0-9]*)$' prints 2

bees/reviewer: re-read the PR list once when mergeability is UNKNOWN …

bees/reviewer: write the launchd job with plistlib (Refs #5776)

bees/reviewer: an unreadable pull request skips itself, not the whole…

bees/reviewer: an expired agent login stops the run and charges no he…

bees/reviewer: run the agent on a Keychain-held setup-token (Refs #5776)

census: quiet "named a path but not quiet" 162 -> 164 (Refs #5776)

bees/reviewer: `probe` -- does the agent authenticate as launchd will…

bees/reviewer: run the agent on z.ai's free GLM flash, on the keys we…

bees/reviewer: launchd runs Python itself, not a login shell (Refs #5776

bees/reviewer: the launchd job runs Standard, not Background (Refs #5776

bees/reviewer: an approval needs two models to agree, independently (…

bees/reviewer: the runner measures the issue's criteria; doctor, queu…

bees/reviewer: repair an approval that leaves a line out; tick and it…

bees/reviewer: read again when GitHub fails a read for a moment (Refs #…

trinity: review speed -- weak points, prior art, plan and backlog (Refs

Review Warden, round 2026-10-04T16:41Z (method: .claude/agents/review-warden.md on #6089)

Moved

duplicate-bodies is red on master since #6070: bless the four fixture copies into the ledger #6099 landed: the Queen's queen-6099 became duplicate-bodies is red on master since #6070: bless the four fixture copies into the ledger #6113, merged 16:29:35Z. duplicate-bodies should be green on master again.

Red

tri review-log: a health card from a window of the reviewer bee's own log (scripts/tri_loop/review_log.py) #6086 (tri review-log): the Queen escalated it at 16:01:58Z after the bee finished at 15:45:27Z; queen-6086 holds no commit ahead of master. I re-read its criteria the way her runner does (criteria_with_source + command_safety): all 7 command checks pass the safety gate, so the escalation is not the criteria-could-not-run fault from the first filing. Her reason is on /queen/needs-you, a guarded route I do not read.
tri epic-ci: which checks of an epic's pull requests turned red since the last snapshot (scripts/tri_loop/epic_ci.py) #6087 (tri epic-ci): one review event at 15:41:24Z with no state, and nothing since; queen-6087 holds no commit ahead of master. That is one sample, so no cause is named yet.
tri queen-log: a health card from a window of the Queen engine's own log (scripts/tri_loop/queen_log.py) #6056 (tri queen-log): queen-6056 6ba5126 is +1 commit (3 files, the issue's Boundary), 52 behind master, and has no PR. Opening one is the board loop's job, not mine.
agents: review-warden, a profile agent for the review-speed watch (Closes #6088) #6089: duplicate-bodies failed at 16:06:30Z, which is before duplicate-bodies is red on master since #6070: bless the four fixture copies into the ledger #6113 fixed it on master. It should pass once the branch picks up master.
bees/merger/publisher: reviewer bee as a service, merger reads discounted checks, publisher heading passes check (Closes #5776) #5777: now CONFLICTING with master (head 2b604f0), on top of the pinned-origin confirmation that already blocked it.
Reviewer bee, measured over 24 h by doctor: 33 of 64 reviews ended with no usable verdict. Top causes: timeouts x5, second-model approval rule x5, self-contradicting APPROVE x4. The job itself is healthy (5 keys, last exit 0).

Needs the owner

The escalation reason for tri review-log: a health card from a window of the reviewer bee's own log (scripts/tri_loop/review_log.py) #6086 on /queen/needs-you.
bees/merger/publisher: reviewer bee as a service, merger reads discounted checks, publisher heading passes check (Closes #5776) #5777: resolve the conflict and give the pinned-origin confirmation. Move the reviewer bee from the workstation's launchd to a Railway service #6117 (move to Railway) waits on this. Move the reviewer bee from the workstation's launchd to a Railway service #6117 is skipped by the Queen for having no Boundary, which is expected because it is an owner-items issue.
Optional: ~/.config/review-warden/queen-report.token, if these reports should also go to the Queen's board.

Classify wasm-explorer.yml; record two batch-merged ports that fail g…

Merge origin/master into fix/master-red-after-batch-merge (L1's two-d…

Review Warden, round 2026-10-04T18:40Z (method: .claude/agents/review-warden.md on master)

Moved

Master red after the 2026-10-04 batch merge: four ratchets back to green #6221 merged 18:38:51Z (master red after the batch merge: four ratchets back to green). Its 19 checks on master e30cfc0ab were still queued at 18:44Z, so green is not yet confirmed.
agents: review-warden, a profile agent for the review-speed watch (Closes #6088) #6089 (this agent) is on master since 17:41:33Z.

Red

tri queen-log: a health card from a window of the Queen engine's own log (scripts/tri_loop/queen_log.py) #6056 (tri queen-log): a new finished event at 18:41:38Z, state ended unexpectedly (cause undetermined). queen-6056 is unchanged at 6ba5126 (+1, 3 files, 244 behind master), still no PR.
tri review-log: a health card from a window of the reviewer bee's own log (scripts/tri_loop/review_log.py) #6086 / tri epic-ci: which checks of an epic's pull requests turned red since the last snapshot (scripts/tri_loop/epic_ci.py) #6087: still open, queen-6086 and queen-6087 hold no commit ahead of master. No event for either in 17:59-18:41Z; the 16:44-17:59Z window is beyond the 120-event cap of /queen/public-activity, so it is unread, not empty.
bees/merger/publisher: reviewer bee as a service, merger reads discounted checks, publisher heading passes check (Closes #5776) #5777: still CONFLICTING (head 2b604f0, unchanged since 15:20Z). All three tri review-log/epic-ci/queen-log cards depend on it or on the tasks above, so they are still skipped.
Reviewer bee, doctor over 24 h: 71 reviews, 35 without a usable verdict (incomplete 28, agent-failed 7). Recurring: second-model approval rule x7, timeouts x5, self-contradicting APPROVE x4, undiscounted Corpus ratchet red x3. Four heads are out of attempts until a new push: Port gHashTag/trinity:fpga/openxc7-synth/d_clk_direct.v (Verilog, 1 module) to specs/port/trinity/fpga/openxc7-synth/d_c #5595, Port gHashTag/trinity:fpga/openxc7-synth/d_e21_test.v (Verilog, 1 module) to specs/port/trinity/fpga/openxc7-synth/d_e21 #5689, Port gHashTag/BrowserOS:trios/agent-server/apps/server/src/lib/provider-error-classifier.ts (TypeScript, 1 function) to #5926, Port gHashTag/trinity:fpga/openxc7-synth/blink_minimal.v (Verilog, 1 module) to specs/port/trinity/fpga/openxc7-synth/bl #5956. Job healthy (5 keys, last exit 0).

Needs the owner

bees/merger/publisher: reviewer bee as a service, merger reads discounted checks, publisher heading passes check (Closes #5776) #5777: resolve the conflict and the pinned-origin confirmation. Every reviewer-bee fix above lives in tools/bees/reviewer.py, which is not on master, so the Queen cannot take it as a task.
The tri review-log: a health card from a window of the reviewer bee's own log (scripts/tri_loop/review_log.py) #6086 escalation reason on /queen/needs-you (a guarded route I do not read), still open from 16:01Z.

No new Queen tasks this round (0 of 2). Queen board report skipped: no ~/.config/review-warden/queen-report.token.

Review Warden, round 2026-10-04T20:40Z

Moved

Reviewer bee (reviewer.py doctor): job loaded, last exit 0; 65 reviews in 24 h: changes 23, approved 11, incomplete 22, agent-failed 8, person 1. Last round it was 71 reviews with 35 without a verdict; now 30 of 65 have no verdict. Three heads are out of attempts until a new push: Port gHashTag/trinity:fpga/openxc7-synth/d_clk_direct.v (Verilog, 1 module) to specs/port/trinity/fpga/openxc7-synth/d_c #5595, Port gHashTag/BrowserOS:trios/agent-server/apps/server/src/lib/provider-error-classifier.ts (TypeScript, 1 function) to #5926, Port gHashTag/trinity:fpga/openxc7-synth/blink_minimal.v (Verilog, 1 module) to specs/port/trinity/fpga/openxc7-synth/bl #5956.
The seal fix is open: fix(seals): re-seal runtime/process and kanban-card-chat (Closes #6256) #6257 (Closes Re-seal runtime/process and kanban-card-chat: master red on seal-currency since ea6839b2c #6256) re-seals runtime/process and kanban-card-chat. On master, Seal Coverage failed on every completed run since 19:32Z (77e5c44, 82d8795: "3 seal(s) newly do not hold"), and those are the same 3 seals that fix(seals): re-seal runtime/process and kanban-card-chat (Closes #6256) #6257 re-seals.

Red

Spec Guards on master: its last green run was 2026-09-16 (52f2fea). Every master run since 17:45Z stops at "Does every seal still describe what the compiler emits", so the ring step after it is skipped. On fix(seals): re-seal runtime/process and kanban-card-chat (Closes #6256) #6257 the seal step passes, and the run then fails at check_ring_spec_drift.py (run 37230465534: ring-096-rust DRIFTED on 5 functions, ring-097/098/101 UNRELATED). This is spec-guards: ring-096-rust disagrees with specs/numeric/formats.t27 on 5 signatures (f32/gf16 vs f64) #5746. Merging fix(seals): re-seal runtime/process and kanban-card-chat (Closes #6256) #6257 alone will not turn Spec Guards green.
Recurring causes of a review with no verdict (all are reviewer.py fixes, so they wait for bees/merger/publisher: reviewer bee as a service, merger reads discounted checks, publisher heading passes check (Closes #5776) #5777): second model needed x7, timeout x6, Corpus ratchet not discounted x3.
bees/merger/publisher: reviewer bee as a service, merger reads discounted checks, publisher heading passes check (Closes #5776) #5777 is still CONFLICTING. Queen tasks tri review-log: a health card from a window of the reviewer bee's own log (scripts/tri_loop/review_log.py) #6086 and tri epic-ci: which checks of an epic's pull requests turned red since the last snapshot (scripts/tri_loop/epic_ci.py) #6087 have queen-* branches with no commits ahead of master (+0) and no events. tri queen-log: a health card from a window of the Queen engine's own log (scripts/tri_loop/queen_log.py) #6056 (queen-6056 6ba5126, +1) has no PR. The Queen's 120-event window covered only 20:04–20:41Z, so I could not read 18:42–20:04Z.

Needs the owner

Rebase or resolve bees/merger/publisher: reviewer bee as a service, merger reads discounted checks, publisher heading passes check (Closes #5776) #5777. Until it lands, the reviewer-bee fixes cannot go to the Queen.
fix(seals): re-seal runtime/process and kanban-card-chat (Closes #6256) #6257 is ready except for the spec-guards: ring-096-rust disagrees with specs/numeric/formats.t27 on 5 signatures (f32/gf16 vs f64) #5746 red. Decide whether it should merge past that red.
tri review-log: a health card from a window of the reviewer bee's own log (scripts/tri_loop/review_log.py) #6086, tri epic-ci: which checks of an epic's pull requests turned red since the last snapshot (scripts/tri_loop/epic_ci.py) #6087 and tri queen-log: a health card from a window of the Queen engine's own log (scripts/tri_loop/queen_log.py) #6056 have not moved for about 5 h. Re-dispatch or close them.

No new Queen tasks this round. Queen board report skipped: no token file at ~/.config/review-warden/queen-report.token.

Implement merger gate specification with discounted check rules

docs: the coordination entry this branch needs to land

Finding from the #6657 merge-jam work (2026-10-06 ~14:40Z), for the reviewer's blame() / Facts.on_base:

on_base(name) reads the check on the newest base commit that ran it. A pull_request run, and any re-run of it, is pinned to the merge commit made when the run started, so its first parent is the master of that moment, not today's.

The case it gets wrong is about to happen: spec-guards is red on master (ring-096 DRIFTED) and on 116 of 136 open bee PRs. #5921 fixes master. Once it merges, master's newest spec-guards is green, so every one of those 116 stale reds will be classified "PR-caused (green on master)", although none of the PRs touches ring-096.

Proposed change, deterministic and with no model call: classify against the first parent of the run's merge commit (the run's head_sha on refs/pull/N/merge), falling back to the newest base commit only when that commit has no run of the check. A red that was red on the master it merged onto is master-caused, whatever master did since.

Until then I am updating the affected bee branches in small batches after #5921 lands, so their checks re-run against the fixed master.

🤖 Generated with Claude Code

fix(merger): judge red checks the bee answered for, run on the bee's …

fix(bees): the second model seconds a review that fell back, an overl…

fix(codegen): gen-rust enum order and gen-zig float-call cast (#6941) (…

fix(bees): strip quotes/backticks off a discount name, not the verdic…

fix(bees): a wrapped or single-dash none still means no blocking chec…

Navigation Menu

Repository navigation

Review jam: reviewer bee as a service, merger that reads the bee's discounted checks, publisher heading that passes check #5776

Problem (measured 2026-10-03)

Change

Original checks (kept for history; the Queen does not run these)

Original file list

Queen-runnable restatement (2026-10-05)

Boundary

User Scenarios & Testing

Requirements

Success Criteria

44 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Review jam: reviewer bee as a service, merger that reads the bee's discounted checks, publisher heading that passes check #5776

Description

Problem (measured 2026-10-03)

Change

Original checks (kept for history; the Queen does not run these)

Original file list

Queen-runnable restatement (2026-10-05)

Boundary

User Scenarios & Testing

Requirements

Success Criteria

Activity

44 remaining items

gHashTag commented on Oct 4, 2026

gHashTag commented on Oct 4, 2026

gHashTag commented on Oct 4, 2026

gHashTag commented on Oct 6, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions