P19 371: the 3i window, draft for Mos

Sage, 2026-10-19, after row 126 landed (ca15d73e9, #1620). This is a draft, not a plan: no target is fixed and no step table is final. It sets out what the window carries, the restore caveat from mos-0837, and two choices for Mos. The final plan gets written after the repin-8e7ea89a1 window is live and checked, in the repin-8e7ea89a1.md format. If that window doesn't happen or rolls back, this draft is void and gets redone from 52f35e7a0.

What a target past `ca15d73e9` carries over `8e7ea89a1`

git rev-list --count 8e7ea89a1..origin/refactor is 92 at c16ba2f0c. A path-limited log over packages scripts roles adapters contracts tools package.json package-lock.json lists ten commits:

Row	Commit	Live effect	Schema
129	`850484a7d`	Console chat area over the project and thread verbs	none
164	`008746b6e`	channel plug-in kind, cli and webui as its modules; chat refuses until Jason runs `mosaic plugins set` (mos-0812)	none
125	`aa625565f`	token limits per instance, model, provider and key	none
162	`7e7f8e208`	`stack-release.sh` itself; runs from REPO, not from the copy	none
155	`b2f57ca70`	the human and the chief configure the assistant	none
154	`9353675d1`	WYSIWYG Markdown editor in the Console docs view	none
156	`4f45cadc0`	the host starts the landing run once a merge decision is approved	none
165	`9466f3e5e`	the human adds and changes role instances, CLI and Console	none
167	`5fa9cc8f2`	one settings snapshot, a names read that rethrows a refusal	none
126	`ca15d73e9`	daily token quota for the stack's account	3h to 3i

I checked the schema column two ways. Only ca15d73e9 touches the migration chain in packages/bus/src/store.mjs, and git show 5fa9cc8f2:packages/bus/src/store.mjs has SCHEMA_VERSION = '3h'. No code commit sits between 5fa9cc8f2 and ca15d73e9.

So the second window (rows 129 and 164) and the 3i window are no longer separate by default. Any target past ca15d73e9 carries both.

Choice 1: one window or two

(a) One window at the tip: activate --pm --migrate with Jason present, then Jason's mosaic plugins set, then every row's checks. A failure after exit 0 needs rollback --restore, because the store is 3i and 8e7ea89a1 is 3h.

(b) Two windows. Window A at 5fa9cc8f2: 3h, no --migrate, rows 129, 164, 125, 155, 154, 156, 165 and 167, with Jason's mosaic plugins set and the chat smokes. Window B at the tip: only row 126's code and the 3h to 3i migration, with Jason present.

I recommend (b). A's rollback is a plain rollback mosaic-stack with no restore and no lost records. B is small, so a gate failure in B points at 3i and nothing else, and B's restore loses only the records written in that one short run. The cost is a second activate. Decision 96 asks for Jason's presence on a --migrate run, so A needs Jason only for mosaic plugins set and his own smokes.

Choice 2: which `stack-release.sh` runs

REPO's tool today is blob 4b16e848, the one rehearsed for 8e7ea89a1. Row 166 changes it and lands after today's window (mos-0834). If row 166 lands first, the 3i window runs a tool nobody has run against a pointer yet.

I recommend that the final plan pin the tool blob REPO holds on the day. Darkwing reruns the scratch --plan for each target with that blob, as in agents/darkwing/work/queue-162/scratch-plan-8e7ea89a1.txt. Whether row 163's rehearsal (D2, queued) must come first is Mos's call.

The restore caveat (mos-0837), checked in code

rollback --restore counts only the events table after the backup stamp (scripts/stack-release.sh:226, refusal at :724). Two other append-only tables are written outside it:

usage_records (packages/bus/src/usage.mjs:93), the usage rows from rows 124 and 126;
instance_names (packages/bus/src/broker.mjs:2189), written by mosaic name.

A restore puts back the pre-migrate backup, so rows written to either table after the backup leave the live store. --events N doesn't report them. The run keeps the attempted store as the post-attempt copy it prints, so the rows still exist there, and nobody opens that copy without Jason.

For the final plan:

W1's PM-idle rule holds until W6 passes, so no turn writes a usage record during the window.
mosaic name stays out of the window (mos-0641).
Before any rollback --restore, Mos runs mosaic usage --business mosaic-stack --json and reports every record after the backup stamp to Jason. Jason decides alongside --events N.
The step text says the restore drops those rows from the live store. The rollback set still holds them.

Before the final plan

The repin-8e7ea89a1 window is live, W6 and W7 have passed, and the pointer names 8e7ea89a1 at 3h.
Mos picks (a) or (b) and the tool blob.
If row 166 lands first, the plan cites its landing commit and its tool blob.
Darkwing reruns the scratch --plan for each target. I write the step tables from those reruns and each row's README, and Mos reviews them before anything goes to Jason.

What Sage ran for this draft

Read only, at 2026-10-19T12:48Z on c16ba2f0c:

the rev-list count and the path-limited log above;
SCHEMA_VERSION at 5fa9cc8f2 and on REPO's HEAD (3i);
git hash-object scripts/stack-release.sh, which is 4b16e848a6b9;
stack-release.sh:216-226 and :722-724;
the INSERT INTO lines in usage.mjs and broker.mjs.

Nothing live was read.

Mos's rulings (mos-0838, 2026-10-19)

D1, option (b). Window A at 5fa9cc8f2, 3h, no --migrate, plain rollback, rows 129, 164, 125, 155, 154, 156, 165 and 167, plus Jason's mosaic plugins set. Window B at the tip carries only row 126 and 3h to 3i, with Jason present. If the tip has moved past ca15d73e9 by then, B's target is ca15d73e9, unless B's plan checks and lists every later code commit as schema-neutral.
D2, the tool blob. Each final plan pins the blob REPO holds that day, and Darkwing reruns the scratch --plan per target with it. If the blob is still 4b16e848, Window A doesn't need row 163 first, because P2 rehearsed that blob. A new blob (row 166 landed) gets a P2-style scratch activate and rollback before it runs against live. Row 163 can do that but isn't required. Window B always gets a scratch activate --migrate 3h to 3i with the day's blob, then rollback --restore on that scratch root.
D3, the restore caveat. The four points stand. Before any rollback --restore, the report to Jason covers both usage_records and instance_names rows written after the backup stamp, read read-only from the live store. Nobody changes the post-attempt copy.
No reply is due until the final plans are ready for review, after the 8e7ea89a1 window is live and checked.

6.7 KiB Raw Permalink Blame History