9deeaaa9c2
All checks were successful
deploy / deploy (push) Successful in 5m35s
Stage 2 writes the first label, and nothing about the label protocol can be dogfooded until an identity exists that is allowed to. Provisioned now rather than deferred. account tireless-poller (tireless-poller@lair.cafe), no ssh key — it never clones anything team lair/tireless-poller: Issues=write, PullRequests=read, Code=none, everything else none, scoped to named repos token write:issue, read:repository, read:user This is the one place an org team earns its keep. Collaborator permissions in Gitea are repo-wide, so granting issue write that way would hand this account code push too — the unit-level team grants labelling without it. The units now load different environment files, and that is not tidiness. The runner spawns coding agents as subprocesses, and subprocesses inherit the environment, so a label-capable token in the runner's environment is a token every agent run can read. poller.env is loaded only by tireless-poller.service, which spawns nothing. Be precise about what that buys: the separation is between processes, not users. Both units run as `tireless`, so the runner's uid can still read poller.env even though its process never loads it. An agent would have to go looking rather than find it handed over in `env` — a real difference, not a boundary. Closing it means separate service accounts or LoadCredential=; recorded as a stage 8 item so it is a known gap rather than an assumed guarantee. Verified each identity can do its own job and not the other's: tireless tireless-poller add label 403 200 fork repo works 403 read issues 200 200 One measurement caveat recorded in §6.4: the poller can still read repository contents despite Code=none, because lair/tireless is public. The unit permission bites on private repos — do not read that as the grant being wrong. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013TxK1CWPkFXqdcXMJ4hVe6