docs(slice1): runbook section 1 run through the Gitea admin API (row 35, #1517, lead decision 74)

Jason ruled that agents run the steps his admin grant to the jarvis
Gitea token covers. Sage created the four mosaic-stack bots (ids
114-117, restricted, non-admin), added them as collaborators (W/W/W/R),
and minted one scoped token each (ids 191-194). The tokens were written
0600 outside the repo. Scripts and receipt are in
agents/sage/work/gitea-setup/. The guide and SR brief now say who
runs which section. Sections 2 to 4 (Vikunja) stay with Jason.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

docs/guides/slice-1-identities.md

@@ -1,10 +1,17 @@
 # Slice 1 identities: Gitea bots, Vikunja bots and their tokens
 
-Jason runs this guide once per business, by hand (PRD REQ-CRED-1, round
+An operator runs this guide once per business (PRD REQ-CRED-1, round
 3, 1A and 2A). It creates every service identity slice 1 uses and writes
 each token to a 0600 file the broker reads. Nothing in v1 mints these
 tokens for you. Brief: `docs/plans/2026-10-04_slice-1.md`, row SR.
 
+Who the operator is depends on the credential. On 2026-10-09 Jason gave
+the jarvis Gitea token site admin rights and ruled that agents run the
+steps it covers, so Sage ran section 1 for `mosaic-stack` through the
+API (lead decision 74). Sections 2 to 4 need the Vikunja owner and
+`svc-$BIZ` logins, which no agent holds, so they stay with Jason until he
+grants a Vikunja credential.
+
 Plan on about 20 minutes with an existing Vikunja, and 30 if you start
 the bundled one.
 
@@ -18,7 +25,9 @@ the bundled one.
 - To check a token file, use `stat`, never `cat`.
 - The Vikunja owner and `svc-$BIZ` passwords and the Gitea admin login
   are the high-value secrets. They are used only in this guide, and never reach
-  the broker or an agent.
+  the broker or a worker. The one exception is the jarvis Gitea admin
+  token, which Jason granted to the lead seat for section 1 (decision 74).
+  It stays in its fleet file, and the broker never reads it.
 
 ## 0. Set up the shell
 
@@ -40,8 +49,21 @@ The commands need curl 7.76 or later, for `--fail-with-body`.
 
 ## 1. Gitea: four bot users and their tokens
 
-Gitea tokens don't expire, and the HTTP route for creating one needs a
-password, so this part uses the web UI.
+Gitea tokens don't expire, and the HTTP route for creating one needs
+the bot's password. The steps below use the web UI.
+
+With a site admin token there's an API route that does the same five
+steps: `agents/sage/work/gitea-setup/setup.mjs`, which ran for
+`mosaic-stack` on 2026-10-09 (receipt `2026-10-09_run.txt` beside it). It
+creates each bot with a random password that exists only in its
+memory, adds the collaborator, mints the token with basic auth as the bot,
+and writes the file with `O_EXCL` at 0600. The password is never
+written down, so nobody can log in as a bot. It also creates each bot as
+`restricted` with `private` visibility, which the steps below don't ask
+for. A restricted user sees only repositories it collaborates on. The
+bots' addresses are `<user>@noreply.mosaicstack.dev`, which receive no
+mail. `verify.mjs` checks each token's login, repository permission and
+refusals, and prints no secret.
 
 1. As a site admin, create the users `mosaic-stack-pm-bot`,
    `mosaic-stack-cto-bot`, `mosaic-stack-coder-bot` and
@@ -369,8 +391,17 @@ role. The stack never writes this file.
   the broker, then delete the old token in the same settings page.
   Update `rotateBy`. Each rotation gets one line in
   `docs/SESSIONS.md`: date, who, which identities, and no values.
+  The `mosaic-stack` bots from `setup.mjs` have no known password, so
+  nobody can log in to rotate. Rerunning the script for one role after
+  moving its old file aside resets the password and mints a new token. It
+  doesn't yet delete the old token, which needs the same basic auth.
+  Adding that is a follow-up due before the first `rotateBy`,
+  2027-01-07.
 - **Revoking a role at once:** delete its token, the Gitea one in the
   bot's settings and the Vikunja one with the `DELETE` above as
   `svc-$BIZ`, or remove the bot's collaborator access or, as the owner,
-  its project share. The broker's next
+  its project share. For a bot with no known password, a Gitea admin
+  removes the collaborator
+  (`DELETE /repos/{owner}/{repo}/collaborators/{user}`) or sets
+  `prohibit_login` on the user, which also stops its tokens. The broker's next
   call gets a 401 or 403 and refuses.