59649824f6
Some checks failed
WORKFLOW-gitea.md said what the working surface is and why. It did not say how, in what order, or how to know a step worked -- so it was a destination with no route. This is the route. Seven phases, each with a check, each marked 👤 human or 🤖 me: 1 identities two agent users, Write NOT Admin 2 protection main behind a PR + 1 approval -- BEFORE tokens exist 3 tokens three principals, three tokens, three files 4 structure labels and bundles, and deliberately NO Kanban board 5 MCP gitea-mcp v1.7.0, per-agent identity, user scope not .mcp.json 6 items migrate the live findings only -- not 1,227 historical lines 7 restart and verify the three things that must be true Phase 1 leads because it is not hygiene: Gitea does not let a PR's author approve it, so while an agent IS `fabi` either the human cannot approve its work or it can approve its own. The review gate does not exist until the agents are distinct people. (It also fixes 495 commits of agent work attributed to the human's email.) Phase 2's check is a real push and a real PR, not a reading of the settings page. The reason protection lives in the server rather than in a brief is that it should not depend on good behaviour -- so verifying it should not either. Phase 5's install facts are checked, not remembered: gitea-mcp v1.7.0, `gitea-mcp_Linux_x86_64.tar.gz`, `-t stdio -H <host>`, `GITEA_ACCESS_TOKEN`. The `--tools` filter is flagged as an EXPERIMENT that might exclude the merge tool as defence in depth -- explicitly not a substitute for phase 2. Ends with what is still to build (propose-work, an attachment uploader, gitea-verify, the wiki landing page) and a "what I have not verified" section: the approve-your-own-PR behaviour, the --tools names, the Projects API, and the Gitea version -- the API was unreachable from my sandbox three times running.