machine-grant design r4 (#436): S1 migration is an agent-run Q173 window on dragon-lin, .53/.54 start at 3j (mos-1133)

agents/gizmoduck/work/machine-grant/DESIGN.md

@@ -1,15 +1,22 @@
-# Machine grant path, design draft r3 (Vikunja #436, row 210 follow-up)
+# Machine grant path, design draft r4 (Vikunja #436, row 210 follow-up)
 
 Owner: Gizmoduck. Reviewer: Duckworth. Sizing and row assignment: Sage. Design only. Code starts when
 Duckworth approves the design and row 210 lands (sage-1527).
 
-Sources: Q188 (DECISIONS.md:1642, jason-master-restart 8ecf252), mos-1115, mos-1120, mos-1125, mos-1127, mos-1131,
+Sources: Q188 (DECISIONS.md:1642, jason-master-restart 8ecf252), mos-1115, mos-1120, mos-1125, mos-1127, mos-1131, mos-1133,
 sage-1527, Duckworth's r1 review (REVIEW-r1.md, duckworth/reviews d025ef492, corrected at 749080115),
 Honker's PRD 1.8 draft (honker/row194-b2 3c30f1036, REQ-TRUST-2 and REQ-GRANT-1 to -4), row 210 DESIGN r3
 (e021dfa26) and its approved candidate 455964f23. Code cites are `path:line` at origin/refactor f41729178
 unless they say "210:", which means the row 210 candidate 455964f23 (the same code as the branch head
 a2fd30390). Host facts come from ops-01's read-only check of .53 and .54 at 22:21Z (mos-1127).
 
+## r4 changes (from r3 d8bcf8066)
+
+mos-1133 corrects S1's migration lines. r3 said the 3i-3j re-pin needs `--migrate` with Jason present (P19
+371). That was wrong. P19 371 predates Q173, and Q173 lets Mos, Sage or Darkwing re-pin, migrate, roll back
+and restore the mosaic-stack business on dragon-lin. S1 now says so and adds the .53 and .54 plan. Nothing
+else changed.
+
 ## r3 changes (from r2 eb4c756a1)
 
 mos-1131 (from duckworth-0057 and mos-1129): under PRD 1.8 only an Approve creates a grant, and a hand edit
@@ -563,8 +570,15 @@ The business file holds none of it (mos-1131 point 2). A hand edit makes nothing
 The store file is writable by the stack's OS user, like the key files (199 D6). Section 9's same-user limit
 covers it.
 
-A new store schema is a migration. Per the 3i landing rules (row 126), the re-pin that brings it needs
-`--migrate` with Jason present (P19 371). Row a has to plan for that.
+A new store schema is a migration (mos-1133):
+
+- On dragon-lin the 3i-3j re-pin is an agent-run `--migrate` window under Q173. Mos, Sage or Darkwing runs
+  it as the tester, takes a backup first and sends a STATE report after. Jason doesn't need to be present.
+  P19 371 predates Q173 and doesn't apply.
+- On .53 and .54 the plan is for row a to land before the installs (row a in review by 10-24, installs
+  10-26). Both hosts then start at 3j and need no migration.
+- If row a slips past an install, r5 or the row a packet says so. That host then goes 3i to 3j through I3's
+  upgrade driver (#432), and Mos rules on it at that point.
 
 ## 6. Revoke
 
@@ -758,7 +772,8 @@ Answered since r1:
     their migration, `host.run` reading them, and `hosts status`. More than r2's 1 day, because of the
     migration and moving 210's tests. My estimate is 1.5 days.
   - Row b: the raise binding, the executor, reconcile and revoke, after row a, about 1.5 days.
-  - Both come after row 210 lands and need the 1.8 line before landing. Target: in review by 10-24.
+  - Both come after row 210 lands and need the 1.8 line before landing. Target: in review by 10-24, so
+    row a lands before the 10-26 installs (S1, mos-1133).
 - Q-M1 (mos-1120): Mos revokes as the tester. Replaced by mos-1132, see below and section 6.
 - Q-O1 (ops-01 through mos-1125): yes, with the six changes now in E3.
 - Q-O2 (ops-01, reply to gizmoduck-0063): the `privileged` file is accepted, with four rules and four writer