diff --git a/agents/sage/work/window-plan/repin-ca15d73e9.md b/agents/sage/work/window-plan/repin-ca15d73e9.md index ef4025645..58c3abac8 100644 --- a/agents/sage/work/window-plan/repin-ca15d73e9.md +++ b/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 - 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 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 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