b1e01777ff
All checks were successful
deploy / deploy (push) Successful in 5m36s
The design had tireless pushing `tireless/*` branches into the repo it was working on, with branch protection denying it `main`. It now works the way an outside contributor does: pushes only to its own fork, reaches the real repository through a pull request, and has no write access to that repository at all. That is a stronger guarantee than the one it replaces. Branch protection is a rule that can be edited, applies per repo, and is easy to forget on the next repo added; a bot with no push permission cannot write to `main` whatever anyone forgets. The wrinkle is the label protocol. Labels are a write on the issues unit, and Gitea collaborator permissions are repo-wide, so granting issue write as a collaborator would hand back the code push the fork exists to avoid. Access is therefore an org team with unit-level permissions -- lair/tireless-agent, with Issues=write, PullRequests=write, Code=read, everything else none, scoped to named repositories rather than the whole org. Provisioned and verified end to end rather than assumed: push to the fork succeeds push to lair/tireless "User permission denied for writing." label an issue 200 / 204 cross-repo PR from fork opened as `tireless` delete the repository 403 Two credentials with different blast radii: an ssh key on the account for git transport, and an API token scoped write:issue + write:repository + read:user for issues and PRs. known_hosts is pre-seeded, because an unattended git must not prompt and accept-new would trust whatever answered first. Stage 4 gains the consequence: two remotes, and a fork that has to be checked for staleness before branching. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013TxK1CWPkFXqdcXMJ4hVe6