docs(plans): project relaunch with roles, idea and SetSpark evidence (goal 4 input)

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-10-03 23:51:56 -05:00
parent 7a3c364b41
commit 2eca954163
2 changed files with 104 additions and 0 deletions
@@ -0,0 +1,100 @@
+# Project relaunch with roles, not static identities (idea, 2026-10-04)
+
+Status: an idea Jason raised, recorded by Sage. Not a brief and not
+scheduled. It feeds the goal 4 (fleet retirement) brief once goal 2
+closes.
+
+## The idea
+
+Jason, in the SetSpark project-manager thread on 2026-10-03, 23:41 CDT:
+
+> It would almost be better to have roles in the project, launch a
+> project-manager agent, then have the PM launch other sessions with the
+> proper harness and have them volunteer for, and assume, a role in the
+> project.
+
+And to Sage: should Mosaic Stack, its harness and a "(Re)Launch" command
+for a project be built this way? The roster holds the information, the
+agents' needs are known, and the PM launches the other agents. Voluntary
+collaboration follows from that.
+
+## What Mosaic Stack already has
+
+- A roster (`agents/README.md`) listing each seat's job, harness and
+  model, and a `launch.sh --fresh` for every seat.
+- Role authority in `roles/`, changed only by reviewed commits.
+- Claims: `queue next` names a piece, and `queue move ... in-progress`
+  claims it under a lock and a log.
+- Registrations: a launch writes `<dataRoot>/seats/repo/<seat>/registration.json`.
+
+Gate G (2026-09-28) was the first end-to-end test. Jason launched a fresh
+Rocko session with no history. It ran `queue next`, found row 31, read the
+brief and finished the work, with no other message.
+
+## What broke, and what this model would fix
+
+- **Launching.** Only a human can start a seat. The launchers open a TUI
+  that Sage can't drive from T3, so Jason had to do it (decision 41). A
+  PM that launches sessions removes that step. T3 has a thread-creation
+  API, and SetSpark's PM noted the same thing.
+- **Credentials.** The fresh Rocko couldn't post its review request
+  because nothing set `MOSAIC_GITEA_CREDENTIAL_FILE`. A launch command
+  that reads the roster sets each role's environment.
+- **Identity.** A seat's name lives in a thread title and in people's
+  memory. On 10-03, SetSpark showed what that costs:
+  - one seat named itself from a commit author;
+  - two seats shared one memory folder, and one had to guard itself
+    against adopting the other's identity note;
+  - seat names drifted ("implementer", "implementation-agent",
+    "setspark-implementer");
+  - one seat guessed a peer's thread id;
+  - Jason asked "who is the PM?" before launching one.
+
+## What SetSpark's 2026-10-03 sessions showed
+
+This comes from two read-only subagent passes over six threads, not
+from the repo.
+- **Nobody volunteered.** Roles came from Jason's first prompts and from
+  the PM assigning tasks. The PM launched no sessions.
+- **Agents used founder credentials.** Two seats pushed with Jason's
+  GitHub token and connected with his personal SSH key until Business
+  Operations caught it.
+- **Concurrent writes clashed.** A reviewer took over a task 15 seconds
+  after the implementer moved it to Review, two seats edited one task
+  description at the same time, and messages crossing led to a review of
+  an outdated PR head.
+- **Admin work fell on Jason all evening:** apps, team membership, buckets
+  and approvals. He said he was "constantly" babysitting.
+- **A restart kept the conversation, not the role.** The restart probe
+  showed that a stopped T3 session restarts its tool process and keeps its
+  conversation, because the harness resumes it. The thread id and a
+  claimed role aren't tied to anything that survives.
+
+## Constraints Sage would put on it
+
+1. **A role has one holder.** Claiming a role takes a lock, logged the way
+   queue claims are. Two sessions never hold the same role.
+2. **Claiming a role grants exactly that role.** A session gets the
+   contract in `roles/` and its scoped credential, nothing more. Roles
+   come only from the roster, and no session can invent one.
+3. **Credentials belong to the role, not the founder.** Each role gets its
+   own token file in place. A session that finds only founder credentials
+   stops.
+4. **The founder authorizes launching.** Which harnesses, how many sessions
+   at once, a spend limit and a stop command. The PM launching sessions
+   changes who starts work, which today is Jason, so it needs his explicit
+   ruling.
+5. **Identity is the role plus the run.** A registration records which
+   session holds which role and since when. Releasing or ending the run
+   frees the role.
+
+## Open questions for the brief
+
+- Is the PM a role like any other (Sage today), or the launcher itself?
+- Does a session pick its role, or does the PM assign one and the session
+  accept it? Jason's word was "volunteer".
+- Which harnesses are in scope first: T3 threads only, or Pi headless and
+  the launchers too?
+- A Paperclip trial is open (SESSIONS 2026-09-30, `/mnt/storage/src/paperclip-trial`).
+  The review found it covers much of this coordination layer, but its
+  defaults conflict with fail-closed. Compare it before building our own.