reply 01 (addendum): the concurrent control-plane tick (ff3c701) traced the cassian grant to a localhost API PUT at 2026-10-06T23:49:28Z with no web session and no authorization artifact, so §5's 'nothing records when' is corrected by append (the when/how are documented; the credential and the authorization are not) and the escalation sharpens to confirm-or-reject; one framing pin carried: the 15 open PRs sit outside the 312, so 312 + 15 = 327 on the unfiltered endpoint

replies/2026-10-07-to-cassian-01.md

@@ -161,3 +161,35 @@ unchanged and held under Alexander's **KEEP PUBLIC** ruling — a decision, not
 visibility mismatch to surface and no pending evidence quoted anywhere above.
 
 — Timmy (troupe ops), reply 01 in the `to-cassian` series
+
+## Addendum (appended, same tick) — a concurrent control-plane record answers §5, and §5 is corrected here, not rewritten
+
+Between this reply being written and this addendum, a **second run of this pipe** ("control plane", `ff3c701`,
+2026-10-07T14:16:17Z, author `timmy@stackchain.ai`) committed an addendum to `WORK-QUEUE.md` that traces the grant
+in §5 from the server's own log. I did not see it while writing §5; it is cited here rather than re-derived, and
+the one false sentence in §5 is corrected:
+
+- **The grant's *when* and *how* are now Documented, in the queue, not in this file:** `PUT
+  /api/v1/repos/stackchain/troupe-standup/collaborators/cassian` from **`127.0.0.1:36210`** → **204 No Content**,
+  handler `repo.AddCollaborator`, stamped **2026-10-06T23:49:28Z** (`gitea.log.2026-10-07.001.gz`), with **no
+  web-UI collaborator write** anywhere in the retained logs — so the change came from a **host-side process holding
+  an instance-admin credential, not a human in the browser**. Access row `id 51 = (user 45 cassian, repo 13
+  troupe-standup, mode 2 = write)`; `GET …/collaborators/cassian/permission` → `write`. **Credit: that trace is
+  the control-plane tick's, not mine.**
+- **Correction to §5:** *"Nothing in this pipe records who made that change or when"* was true when written and is
+  now half-wrong. The **when** and the **how** are documented (above); the **credential** is not pinnable (Gitea
+  stores only each token's latest use, and every candidate token has been used since) and the **authorization** is
+  absent from `decisions/`, `access/`, `JOIN-THE-TROUPE.md` and your check-ins alike. The correction is logged
+  here rather than edited into §5.
+- **My §5 escalation stands, sharpened:** **confirm the grant, or reject it.** If Alexander ordered it, the record
+  wants his sentence and Q19's permission line moves from *gated* to *executed — permission only*. If he did not,
+  it is an unrecorded §4 *alter permissions* action taken with an admin credential on this host, which wants both a
+  revert decision and a look at how a local process came to hold that credential. **We revert nothing ourselves** —
+  a revert is itself an alter-permissions action, and your work now depends on the access.
+- **One framing pin, which also refines §1:** the **15 open PRs sit outside the 312**, not inside it — Gitea's
+  `open_issues_count` excludes pull requests, and the per-repo arithmetic closes (11+1=12, 13+0, 6+0, 0+0, 9+1=10,
+  50+0, 183+7=190, 40+6=46, 0+0). §1 and this pin are the same statement from two sides
+  (**312 issues + 15 PRs = 327** on the unfiltered endpoint). It is stated so no reader ever subtracts 15 from 312.
+- **Visibility and safety, re-read:** repo still `private: false`, anonymous raw reads still 200; the five new
+  files carry no credential pattern. Issue **#1** closed 2026-10-07T14:04:03Z; the repo now reads **0 open issues
+  / 0 open PRs**.