mosaicstack/stack
25
0 Fork 1
Code Issues 404 Pull Requests 13 Packages Projects Releases 15 Wiki Activity

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

Browse Source
This commit is contained in:
jason.woltje committed 2026-10-19 13:11:26 -05:00
1 parent cbdcf1967f
commit 56534526b2
1 file changed
+47 -21
Download Patch File Download Diff File Expand all files Collapse all files
agents/sage/work/window-plan/repin-ca15d73e9.md
+47 -21
View File
@@ -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
until 382 has landed. See the last section.
pass that today (P19 382). mos-0848 (b): no window past c216f47db goes to Jason
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
no setter before c216f47db knows that kind, so Jason can't set it early. The
`--pm` start launches the chief, the launcher refuses `harness-off`
(`launcher.mjs:251-253`), the gate finds no `launched` line
(`stack-release.sh:375-393`), and the run rolls back. A plugins set from the
target copy before activate doesn't help either: it goes through the live bus
(c216f47db `cli.mjs:572`), which runs the old code. A silent default for a
missing `harness` kind is refused (D4).
on only if `plugins.harness` lists it. The live file has no `harness` kind, and no
setter before c216f47db knows that kind. A plugins set from the target copy goes
through the live bus (c216f47db `cli.mjs:572`), which runs the old code. So a
plain `activate --pm` fails. The launcher refuses the chief `harness-off`,
`launcher.mjs:657` throws with exit 3, `cli.mjs:507-509` closes the host, and the
unit's `RestartPreventExitStatus=2 3 4` (`mosaic-bus.service.in:33`) keeps the
bus down. mos-0845 D4 is withdrawn (mos-0848). A silent default for a missing
`harness` kind is refused.
The fix, 382. mos-0845 D4 ruled that the gate accepts one named `harness-off`
refusal for `launch.by` in place of the `launched` line, then Jason's plugins
set, then a plain restart. That can't work as ruled, and Sage reported it in
sage-1007. A refused PM launch takes the bus down: c216f47db
`packages/cli/src/launcher.mjs:657` throws `PM launch refused: ...` with exit 3,
`packages/cli/src/cli.mjs:507-509` closes the host and rethrows, and the unit's
`RestartPreventExitStatus=2 3 4` (`packages/cli/systemd/mosaic-bus.service.in:33`)
keeps it down. The gate's unit and status checks fail before `pm_launched`, and
there is no live bus for Jason's plugins set. The steps wait for Mos's
ruling on sage-1007. The earlier step list is withdrawn until then.
The approved path, from the row 169 brief (`docs/plans/2026-10-19_pm-after-harness.md`,
blob bfc5fa7ba36e, mos-0852). The step table is written once 169 lands, on the
landed tool blob and its rehearsal in `agents/darkwing/work/queue-169/`:
1. Before the window: P0, P1 for OLD and NEW on the live file, which has no
`harness` and must load under both. P2 against a stub Console of NEW. Then
`activate <NEW> mosaic-stack --pm-after-harness --plan`, which shows no
`pm-after-harness-target`, `pm-after-harness-set` or `unknown-kind-for-target`
refusal.
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