fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

tools: apply and re-check the branch protection rule, rather than clicking it

Browse Source 
Phase 2 as a file. Six settings where two are load-bearing and both were missing
from the first draft is the shape of thing that gets mis-clicked at 1am, so it
goes through the API: what was applied is readable in a diff, and `--verify`
can re-check it later instead of it being checked once.

--verify states its expectations INDEPENDENTLY of what the apply path sends.
A check derived from "whatever we posted" cannot fail -- it re-derives the
expectation from the thing under test, which is the same instrument-shaped
failure as a check that passes on an instance with no rule at all.

It also asserts both agents are still Write and not Admin, because an agent
promoted to Admin can edit the rule and then merge, so a green rule proves
nothing on its own. That is the `gitea-verify` card from "Still to build";
what is left of it is only putting it on a timer.

`block_admin_merge_override` stays false on purpose, and the reasoning is in
the file: approvals are whitelisted to `fabi`, and Gitea will not let `fabi`
approve a `fabi` PR -- so with the override blocked, a human-authored PR could
never reach one approval and could never merge at all. The override is not a
hole in the agent gate because the agents are Write, not Admin. Phase 1.2 pays
for that; this is where it is spent.

Reads the repository-scoped credential that already exists on the agent box
(~/.sylph-git-credentials) rather than the issue-only ~/.sylph-gitea-api-token,
which every branch-protection endpoint refuses. That keeps the setup needing no
new credential, and keeps push rights on one machine.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01McNbzUeq1KRBWs4G6X2YVj
This commit is contained in:
Claude (Pi session)
2026-09-04 16:49:58 +02:00
parent eccb789c0b
commit 799fa93383
2 changed files with 263 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
docs/agents/GITEA-SETUP.md
View File

@@ -59,7 +59,34 @@ agent remove the rule that stops it merging.
**Do this before the agents hold tokens**, so there is no window in which they
can push to `main`.
Repo → Settings → Branches → *Protected Branches* → add rule for `main`:
**Apply it through the API, not the form** — `tools/gitea-protect`. Six settings
of which two are load-bearing, and both of those were missing from the first
draft of this phase: that is the shape of thing that gets mis-clicked. An API
call is reviewable in a diff and repeatable, and the same file re-checks it later.
```bash
tools/gitea-protect --dry-run # the exact rule, no credential read
tools/gitea-protect # create or update, then verify
tools/gitea-protect --verify # assert it still holds; exit 1 if not
```
📌 **Run it on the agent box, not the Pi.** Branch protection is a
repository-scope endpoint, so `~/.sylph-gitea-api-token` cannot do it — that
token is deliberately issue-only. The credential that can is the one already
sitting on that machine, `~/.sylph-git-credentials`, which the tool reads. Doing
it there means no new credential, and no second machine holding push rights just
to close a one-time setup step.
🔴 The tool sets `block_admin_merge_override: false`, deliberately. Turning it on
would lock **you** out of your own work — approvals are whitelisted to `fabi`,
Gitea will not let `fabi` approve a `fabi` PR, so a human-authored PR could never
reach one approval and could never merge. The admin override is what keeps that
door open, and it is not a hole in the agent gate for exactly one reason: the
agents are **Write, not Admin**. That is what Phase 1.2 is buying, and this is
where it gets spent.
Or by hand — Repo → Settings → Branches → *Protected Branches* → add rule for
`main`:
| setting | value | why |
|---|---|---|
@@ -275,8 +302,10 @@ Not blockers for Phase 7, but the workflow is not finished without them:
existing refusals stay: no `main`, no force-push.
* **an attachment uploader** — the MCP exposes `attachment_read` only, so putting
a screenshot on an issue needs a direct `POST /repos/{owner}/{repo}/issues/{index}/assets`.
* **`gitea-verify`** — asserts protection is still on and the agents are still
Write-not-Admin. Phase 2 is checked once; this checks it every day.
* ~~**`gitea-verify`**~~ — done, as `tools/gitea-protect --verify`: asserts every
field of the rule *independently* of what the apply path sends, and that both
agents are still Write-not-Admin. What is still missing is only the *every
day* part — nothing runs it on a timer yet.
* **wiki landing page** — bundles in flight and what each agent is on. There is
currently no view of what is happening except container logs.