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

Merge branch 'pi/gate-limit' into agents/gitea-mcp

Browse Source
This commit is contained in:
MechaCat02
2026-09-04 17:55:00 +02:00
parent 9aeeb8c574 b67b6243e6
commit ce9fc6eea6
2 changed files with 28 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -115,6 +115,26 @@ Neither whitelist is decoration, and neither replaces the other:
Withholding the review tool from the agents (Phase 5) is defence in depth behind
these, not a substitute: an agent still has a browser-shaped API token.
### 🔴 What this rule does not gate, said plainly
It binds everyone who reaches Gitea through the API or the web. **It does not
bind anyone who can run `gitea admin` inside the container** — and that includes
the supervising agent on the Pi, the one that created the agent accounts and
minted their tokens. From that shell you can issue an admin token or edit this
rule, and nothing here would stop you.
That is not a hole to plug here; it is the boundary of what Phase 2 buys, and it
should be written down rather than discovered. **Phases 1 and 2 gate the two
containerised agents** — the ones that run unattended on a loop, whose whole
design assumption is that policy lives somewhere they cannot reach. A supervisor
with a shell on the host is not in that set, and the protection above should not
be read as universal.
The distinction is exactly the one Phase 1.2 draws with **Write, not Admin**: the
looping agents get a permission level that cannot edit the rule that binds them.
`tools/gitea-protect --verify` asserts that level on every run, which is the
check that keeps this true rather than merely stated.
> ### Check — and actually run it, do not assume it
>
> The whole point of putting this in protection rather than in a document is

11
tools/gitea-setup
View File

@@ -113,7 +113,12 @@ if [ "$DRY" = 1 ]; then
else
echo "labels and bundles are in place at https://$HOST/$REPO/issues"
echo
echo "Remaining, by hand in the web UI (the API for Projects lags it):"
echo " Projects -> New Project -> columns:"
echo " Proposed | Approved | In progress | Needs human | Done"
# No board, and this used to say the opposite. Gitea's project board does not
# follow labels, so it would be a SECOND copy of the state to hand-sync -- the
# exact failure that produced a 1,227-line BLOCKED.md. Labels are the truth and
# a saved issue filter gives the same view for nothing. Leaving the old
# "remaining, by hand: Projects -> New Project" line here would have had the
# tool instructing the reader to build the thing the doc argues against.
echo "No project board, deliberately -- labels are the truth. See"
echo "docs/agents/GITEA-SETUP.md Phase 4. Use a saved issue filter instead."
fi