window-plan: P19 371 3i window draft for Mos, one or two windows and the restore caveat

This commit is contained in:
2026-10-19 07:49:00 -05:00
parent c16ba2f0c4
commit e69e646b40
@@ -0,0 +1,109 @@
# 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
1. The repin-8e7ea89a1 window is live, W6 and W7 have passed, and the pointer names
8e7ea89a1 at 3h.
2. Mos picks (a) or (b) and the tool blob.
3. If row 166 lands first, the plan cites its landing commit and its tool blob.
4. 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.