docs: lead decisions 138 (merge-train SOP), 139 (Q144) and 140 (chief-of-staff model)

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

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

@@ -3086,3 +3086,55 @@ which stay with him. Each item names who decided it and what happened.
       finding.
     - When unsure, the reviewer calls it blocking and says why. Sage can
       move it down.
+
+138. **The merge train is standard landing practice on every project
+    (2026-10-14, Jason's ruling, relayed by Mos, Mos's DECISIONS
+    6a79ff4).** Jason: "Then using the merge-train method is now SOP for
+    us on ALL projects." It makes the batching half of decision 136
+    (#278) and Sage's large-N rules from sage-0179 the standard. Mos
+    carries it to the other projects' seats. For mosaic-stack:
+    - Each row first passes its own builder round on its own base and
+      gets every approval. The train gate only catches interactions
+      between rows.
+    - When two or more approved rows wait, the lander runs one full
+      landing gate on the combined tree at the target, then makes one
+      commit per row in queue order. Each commit is checked against its
+      row's candidate (`queue review verify-commit`).
+    - Rows that change the same path don't ride the same train, unless
+      the later row's manifest is rebuilt after the earlier one lands.
+    - A train holds about 1/p rows, where p is the share of rows that
+      break the combined tree. Until p is measured, a train holds at
+      most 4 rows.
+    - A red train is rerun once before anything else, because a flaky
+      test would send the search after a row that isn't broken. The
+      flake rule for #258/#261/#262/#263 still applies. If it is red
+      again, bisect by halves on the combined tree: drop the row that
+      breaks it back to its builder, land the green rows, and put the
+      rest on the next train.
+    - One commit per row stays the revert unit.
+
+139. **Q144 yes: chief-of-staff may hold role.launch (2026-10-14, Jason,
+    relayed by Mos).** Jason: "Q144: yes. It is very possible I
+    misunderstood the Q101 decision." Decision 104 recorded Q101's
+    condition, "Any later widening needs your approval again." Mos reads
+    this yes as that approval for `role.launch` in
+    `roles/chief-of-staff.json`. It changes no file yet. The grant lands
+    with its contract change in one reviewed commit, after Jason answers
+    Q145 (decision 140).
+
+140. **The chief of staff sits between the user and every other agent
+    (2026-10-14, Jason, relayed by Mos).** Jason, verbatim:
+    "User -> Chief of Staff -> All other agents. The COS seat maintains
+    the ability to hire/terminate any other agent seat to fulfill the
+    organizational requirements stated by the user. The COS seat is the
+    main point of interaction for the user. The user must have the
+    ability to destroy and recreate a COS seat via the WebUI without the
+    need for Terminal access. Configuration of the system will be kept
+    simple for the user during onboarding." Also: "The WebUI doesn't
+    have a method for launching an agent session like this and the
+    needs are vacuous." It replaces the dropped "add cto to the PM's
+    launch.instances" path. Mos asked Jason one fork as Q145: the chief
+    of staff is the only launcher, or it launches and revokes anyone
+    while the PM keeps the coder and reviewer. Design and rows wait for
+    that answer. Sage's read-only answers on rows, revoke and the WebUI
+    are sage-0189.