plans: lead decision 117, Q123, the PM stays PM and C-suite hiring goes to Mos

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

docs/plans/2026-09-26_lead-decisions.md

@@ -2632,3 +2632,24 @@ which stay with him. Each item names who decided it and what happened.
       Mos for it, and labelled that reading as Mos's. Jason's answer
       names the instance, not the editor, so Mos confirms with Jason
       when row 84 lands. Nothing in row 84 writes the business file.
+117. **The PM stays PM; C-suite hiring goes to Mos after row 84 (Q123,
+    2026-10-12).** Jason sent the PM a request through `talk` (5cc5fb64)
+    calling it the chief-of-staff and asking it to create the other
+    C-suite agents. The PM refused and asked for a policy change
+    (2178c093). Jason, through Mos (sage-0099), verbatim: "Q123: The
+    chief-of-staff was my error, but it was a good test regardless.
+    Option A". Mos logged it in DECISIONS (c8cc99f) and on Vikunja #154
+    (c65).
+    - Option A: the chief-of-staff is instance `mos`, as decision 116
+      records. The PM keeps the `pm` role. Requests to hire C-suite
+      seats go to Mos once row 84 (M1, #1578) lands.
+    - The PM's reply said the CTO isn't in the business file. That is
+      wrong: `roles.cto` is there, held by darkwing; only
+      `launch.instances` lacks it. The PM sees the business file only
+      through its `launch` tool, which lists `launch.instances`
+      (packages/harness/src/tools.mjs:86-87), while roles/pm.md:13
+      tells it to assign to instances the business file declares. Row
+      84 gives the PM a read of the declared roles, not only the
+      launchable ones. Mos agreed.
+    - Q123 doesn't settle who edits the business file. Decision 104
+      stands, and Mos asks Jason that as its own question.