sage: Window B last section rewritten for the approved two-phase path, row 169 (mos-0848 (b), mos-0852, #1558, #1666)

agents/sage/work/window-plan/repin-ca15d73e9.md

@@ -12,8 +12,8 @@ because it runs `--migrate` (decision 96).
 - The target stays ca15d73e9 although origin `refactor` is past it. The two code
   commits after it are c216f47db (row 65) and efb51169d (ledger). c216f47db makes
   every launch refuse until `plugins.harness` is set, and the `--pm` gate can't
-  pass that today (P19 382). mos-0845 D4: no window past c216f47db goes to Jason
+  pass that today (P19 382). mos-0848 (b): no window past c216f47db goes to Jason
-  until 382 has landed. See the last section.
+  until row 169 (382) has landed. See the last section.
 - REPO: the canonical checkout. Tool blob on the day: `4b16e848a6b9` unless row
   166 or 382's fix has landed. mos-0838 D2: whatever the blob, Window B gets a
   scratch `activate --migrate` 3h to 3i and a `rollback --restore` on that
@@ -133,28 +133,54 @@ pruned: the rollback set, the backup and any post-attempt store stay.
 ## The first window past c216f47db (not yet a plan)
 
 This isn't Window B. It's written here so the harness patch has a fixed place
-(mos-0842, mos-0845 D4). It goes to Jason only after P19 382 has landed.
+(mos-0842). It goes to Jason only after row 169 (P19 382, #1666) has landed
+(mos-0848 (b)). Row 169 builds on row 166, so both are in the tool by then.
 
 The problem. From c216f47db, `harnessOn` (`runtime.mjs:136-145`) turns a harness
-on only if `plugins.harness` lists it. The live file has no `harness` kind, and
+on only if `plugins.harness` lists it. The live file has no `harness` kind, and no
-no setter before c216f47db knows that kind, so Jason can't set it early. The
+setter before c216f47db knows that kind. A plugins set from the target copy goes
-`--pm` start launches the chief, the launcher refuses `harness-off`
+through the live bus (c216f47db `cli.mjs:572`), which runs the old code. So a
-(`launcher.mjs:251-253`), the gate finds no `launched` line
+plain `activate --pm` fails. The launcher refuses the chief `harness-off`,
-(`stack-release.sh:375-393`), and the run rolls back. A plugins set from the
+`launcher.mjs:657` throws with exit 3, `cli.mjs:507-509` closes the host, and the
-target copy before activate doesn't help either: it goes through the live bus
+unit's `RestartPreventExitStatus=2 3 4` (`mosaic-bus.service.in:33`) keeps the
-(c216f47db `cli.mjs:572`), which runs the old code. A silent default for a
+bus down. mos-0845 D4 is withdrawn (mos-0848). A silent default for a missing
-missing `harness` kind is refused (D4).
+`harness` kind is refused.
 
-The fix, 382. mos-0845 D4 ruled that the gate accepts one named `harness-off`
+The approved path, from the row 169 brief (`docs/plans/2026-10-19_pm-after-harness.md`,
-refusal for `launch.by` in place of the `launched` line, then Jason's plugins
+blob bfc5fa7ba36e, mos-0852). The step table is written once 169 lands, on the
-set, then a plain restart. That can't work as ruled, and Sage reported it in
+landed tool blob and its rehearsal in `agents/darkwing/work/queue-169/`:
-sage-1007. A refused PM launch takes the bus down: c216f47db
+
-`packages/cli/src/launcher.mjs:657` throws `PM launch refused: ...` with exit 3,
+1. Before the window: P0, P1 for OLD and NEW on the live file, which has no
-`packages/cli/src/cli.mjs:507-509` closes the host and rethrows, and the unit's
+   `harness` and must load under both. P2 against a stub Console of NEW. Then
-`RestartPreventExitStatus=2 3 4` (`packages/cli/systemd/mosaic-bus.service.in:33`)
+   `activate <NEW> mosaic-stack --pm-after-harness --plan`, which shows no
-keeps it down. The gate's unit and status checks fail before `pm_launched`, and
+   `pm-after-harness-target`, `pm-after-harness-set` or `unknown-kind-for-target`
-there is no live bus for Jason's plugins set. The steps wait for Mos's
+   refusal.
-ruling on sage-1007. The earlier step list is withdrawn until then.
+2. Phase 1: `activate <NEW> mosaic-stack --pm-after-harness`. Exit 0, `result
+   ok`, every gate check except `pm_launched`. The pointer reads `pm: false`,
+   `pmPending: true`, and `status` prints the pending line. The bus is live
+   without its PM, and the tool says so.
+3. Jason runs `$C_NEW plugins set` with `harness` `["claude-code"]` through the
+   live NEW bus, then reads it again. Mos runs `business-check` under NEW on the
+   patched file. LOAD_OK is required.
+4. Phase 2: `pm-on mosaic-stack`. Exit 0 means the full gate passed, the chief
+   launched, and the pointer is `pm: true` with no `pmPending`. Then W6 and W7.
+5. `pm-on` exit 1 (`pm-on-failed`): the bus stays live without its PM and the
+   pointer stays pending. Jason fixes the `harness` entry and runs `pm-on` again,
+   or Mos decides on a rollback. Exit 2 (`pm-on-down`): both units are stopped,
+   and Jason or Mos settles it.
+
+Rollback. From pending before step 3, `rollback` installs OLD with `--pm` and
+gates `pm_launched` with nothing else first. After step 3, OLD refuses the
+unknown `harness` kind when it loads the file (ca15d73e9 `kinds.mjs:78`). So,
+as in Window A's channel undo (mos-0849 G2):
+1. Jason sets `harness` to `null` through the live NEW bus and reads it again.
+2. Mos runs `business-check` under OLD. LOAD_OK is required.
+3. Only then `rollback --plan`, then `rollback`. The tool refuses
+   `unknown-kind-for-target` by name until step 1 is done.
+
+Also in the range: efb51169d (ledger, #1665). Its live effect gets a row in the
+commit table when the plan is written. If B is live at 3i, this window has no
+migration.
 
 ## What Sage ran for this plan