Everything I could decide myself is decided. What's left needs
you. Each one has a recommendation from Fable — if you agree, pick it and
press Done. "I'm not sure" is a real answer and becomes work for me.
You don't need to open the session — pressing Done sends your answer back and it picks up.
1agentflow#45 — the repo's first CI + review gate is built and proven, but it is RED on its own 'review' check and cannot be made green before merge. Merge it red to bootstrap?
In plain terms. The agentflow repo has had no automatic checks at all. Every change there got a green tick that meant nothing — there was literally nothing configured that could fail, so three changes this afternoon looked approved when nobody and nothing had checked them. This adds real checks, and proves they work by deliberately breaking something and watching them go red.
The catch: the new automatic reviewer refuses to run until it is already live on the main branch — a safety rule, so nobody can sneak in a change that rewrites its own reviewer. So this one change has to go in showing red. Everything else on it is genuinely green.
If you say yes, a person still has to click merge — I am not allowed to, and that floor is the point. Then I watch one ordinary change go through to confirm the reviewer works, and only after that do we switch on the rule that actually blocks bad merges. Switching it on the same day would freeze every open change, including the one that would fix it. Nine changes are waiting behind this.
Fable recommends: Merge red now; apply branch protection (require-checks.sh --apply) only AFTER one real PR shows the review path can go green Every other check is green on its own merits (lint, relay 599 tests, supervisor), and scratch PR #46 proved they genuinely bite — a planted type error and unused binding turned lint and relay RED, then the branch was deleted. The one red check is the Claude review action refusing to run because review.yml is not on main yet — its own anti-exfiltration rule, so a gate cannot be passed by a gate that does not exist yet. No pre-merge state can lift it. The reviewer on this PR is a human reading the diff. Protection must NOT be applied in the same breath: if the bot still posts no marker on the next PR, 'review' becomes a required context that cannot pass and every PR is blocked, including the fix, with enforce_admins on. Five PRs (#39 #40 #41 #42 #44) are queued behind this with no gate to judge them, and three already came back MERGE WITH FIXES with findings a green mergeStateStatus would have hidden. Tried first, unsuccessfully: f13a92d59 — RESOLVED, held under option reversal (confidence high/high). It read PR #45 and run 31278545285 directly and confirmed only the 'review' status is FAILURE while lint/relay/supervisor/seed/review-bot/resolve are SUCCESS, and that the positive control genuinely bit. It picked the same sequencing: observe a new check green once, then require it. It could not settle the merge itself — that rung is reserved to a human by the .github/* floor, which is why this is here rather than acted on. Its stated cost-if-wrong: one PR's window where main stays unprotected (the state the repo has always been in, now with visible UNSTABLE signals) versus option 2's bad tail of a fully bricked merge queue needing a protection rollback.