row 264a r8 (#1769): build notes correction for the r7 red (account-migration, sqlite_sequence rows from the 3k-3l inserts), the whole-snapshot audit of every migrating test, the r7 run in Runs (sage-2621, duckworth-0129)

agents/gizmoduck/work/queue-264/BUILD.md

@@ -336,6 +336,51 @@ the range-diff is `=` for all eleven.
   its default session, and the cli format and tester tests use stub rows or no threads.
 - Touched test files: 20 (thread-claims.test joins). Mutants M1-M4.
 
+### Correction: the r7 red (sage-2621, duckworth-0129)
+
+The r7 gate on Sage's CLEAR (sage-2619) stopped on its first file. account-migration.test failed 2 of
+3: "3h copy migrates to 3i" at :87 and "a 3h→3i step that fails partway" at :136. Each compares a
+whole snapshot of the store after the steps to 3l, `sqlite_sequence` included, with the snapshot
+before them, and found two more rows: `session_defaults` and `sessions`, both at seq 0.
+
+The cause is mine. 3k-3l.sql:50-52 fills `sessions` and `session_defaults` with INSERT ... SELECT,
+and SQLite writes a `sqlite_sequence` row for an AUTOINCREMENT table on that insert even when it
+copies no row. My round 1 schema commit (67fded6af then, 31fcecf7b in r8) changed the file's
+version pin, `master` filter and engine copy, but no round ran the file before r7 (Correction above:
+no run was claimed). The same gap held in every migration test that dumps `sqlite_sequence`.
+
+What I read in r8, before any run: every touched test (and every bus, cli and webui test that calls
+`migrateSchema`) that compares a whole snapshot or whole table across a step to 3l.
+`git grep migrateSchema` and `git grep sqlite_sequence` over `packages/*/tests/*` and `scripts/*`
+gave the list. A Python sqlite3 dry run of the real steps on each fixture's shape
+(gizmo-264-out/dry-seq-r8.py, no repo node) gave the rows after the step.
+
+- account-migration :87 and :136: red as run. Fixed. :132 compares before the 3l step (the failing
+  3h→3i engine rolls back) and is unchanged.
+- gitea-migration :90 (3j to 3l) and grant-migration :95 (3i to 3l): `rows()` leaves out the new
+  tables by name but keeps `sqlite_sequence`. Same two rows at seq 0. Fixed. gitea :113 and grant
+  :117 compare after a rolled-back step and are unchanged.
+- usage-migration :67 (3g to 3l), name-migration :65 (3f to 3l), spec-migration :61 (3e to 3l):
+  whole snapshots with `sqlite_sequence`. Their fixtures have one thread, so the two rows are at
+  seq 1. Fixed. In usage-migration the step also moves the `thread_claims` and `thread_opens` rows
+  after `instance_names`' (3k-3l.sql:84-86 deletes and writes them again), so its snapshot now reads
+  `sqlite_sequence` by name, as account-migration's has since row 126 (ca15d73e9).
+- Read and not affected: thread-migration :110 and :144 compare `messages` and `deliveries` only;
+  sessions.test T7 and the D9 refusal compare named 3l tables, 3l against 3l, and :177 lists table
+  names; each engine-refusal test (account :156, gitea and grant's third test) compares 3l with
+  3l; comment-migration and chief-of-staff count rows and compare no snapshot; stack-release.test
+  T46 lists table names from schema.sql, and its `--migrate` tests run stub copies at 3g to 3h.
+
+The fix, in all six files: the compare after the step leaves out the two new rows and asserts them
+exactly, names and seq, so an extra row of any other name still fails. account, gitea and grant
+leave out the rows `SESSIONS_3L` names (sage-2621); their stores have no thread rows, so nothing
+else in that list has a sequence row. usage, name and spec leave out only `sessions` and
+`session_defaults`, because their `thread_claims` and `thread_opens` rows must stay in the compare:
+the step carries those seqs. Nothing else in the files changes.
+
 ## Runs
 
-None yet. Every run waits for Sage's CLEAR.
+- r7 a23afbf95 on 980cec88c, Sage's CLEAR sage-2619, 2026-10-22 11:29:47Z. HEAD and the manifest
+  digest eb7c1ab3 printed and matched. RED on the first file, account-migration.test 1 pass 2 fail
+  (Correction above); the run stopped there as ruled, with no retry. The sweep found 0 node
+  processes in the worktree. Slot returned.