D0022 — Branch protections: which set gets applied before scheduling starts?

[obotclaw[bot]]

Full argument, options and evidence: https://jwildfire.github.io/obot.roadmap/reports/decisions/2026-08-20-branch-protections/

You called this critical on 18 August and asked for it live before scheduling starts. Here is what is actually true, and the one thing you have to pick.

Of the thirteen branches the merge rules govern, two are protected and eleven are not. One of the eleven is the branch that stores the merge rules — the policy file, the merge tool, and the hooks that keep agent writes off your name. Anything with a write token can push a rewritten policy straight onto it: no pull request, no gate, no record. The rule saying those files need your sign-off is enforced by a script sitting somewhere unlocked.

The question this lives or dies on is whether the agents can still merge afterwards. Under the recommendation, yes — and not as a prediction. Two branches have carried exactly the recommended shape since July and every release merge on both went through it as the bot. The reason it works: requiring a pull request and requiring a human approval are two separate switches. The first costs nothing (the bot opens pull requests anyway); the second is what would convert every automatic merge into a message asking you to click something. The recommendation turns on the first and leaves the second off everywhere.

The one choice:

• Option A, recommended — ten branches require a pull request with no approval, plus the build check that already runs there, and refuse force-pushes and deletions. The other three (the hub's main, the demo's two) refuse force-pushes and deletions only, because automation writes to them directly by design: the hub takes a machine-written audit commit every night and your own commits straight to main by the grant you gave in July, and the demo publishes by pushing its built site. Measured cost: zero merges blocked, zero habits changed.
• Option B — Option A plus a pull-request rule on the demo's live site branch. That closes a real hole (the site is a released surface written today by a direct push the merge tool never sees), at the cost of breaking demo publishing until the publish script is rewritten, and putting you in the loop on every republish. Easy to add later.
• Option C — only refuse force-pushes and deletions, everywhere. Buys the irreversible half and leaves the reason for the exercise untouched.

Two things worth knowing before you answer. The bot cannot read or change branch protection at all — it has never been given administrator permission, confirmed by an actual refused request — and the page recommends keeping it that way, so applying runs under your account, once. And you are not asked for sign-off twice: no rule here requires a review from anyone, so the guardrail files are still gated once, by the merge tool, inside the pull request the protection makes unavoidable.

Applying is one command afterwards, and it reads every branch back rather than trusting the write. It was tested against the real estate before it was trusted: run today it fails, names all eleven unprotected branches and the guard each one lacks, and passes on the two that already match.

P1 (D0022.1) — which set gets applied: A, B or C?

---

Drafted by 👯🤖 W0079 using Claude Opus 5. NOT reviewed by @jwildfire.

[obotclaw[bot]]

There is an episode for this one now, so it can be answered from the car with no screen: Decision: branch protections on obot: the program. Four minutes.

To answer out loud, say: branch protections, option A — or option B, or option C. Answering here in the thread works as well.

Everything the episode states was checked against GitHub while it was written rather than taken from the page: thirteen governed branches, two protected today, eleven disagreeing with the spec, and nothing applied yet.

---

Posted by 👯🤖 W0087 using Claude Opus 5.