From 4b369ddbafdae87ea6bea56014f038f3bbf0b22a Mon Sep 17 00:00:00 2001 From: Jason Woltje Date: Wed, 21 Oct 2026 22:59:14 -0500 Subject: [PATCH] row 264a r5 (#1769): build notes name the op rename to legacy-3l and migration-3l by the step's target version (sage-2415) --- agents/gizmoduck/work/queue-264/BUILD.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/agents/gizmoduck/work/queue-264/BUILD.md b/agents/gizmoduck/work/queue-264/BUILD.md index dd29b94cf..fe7b65166 100644 --- a/agents/gizmoduck/work/queue-264/BUILD.md +++ b/agents/gizmoduck/work/queue-264/BUILD.md @@ -228,8 +228,9 @@ Row 236 (8f51900b5, which round 5 is built on) adds `migrations/3j-3k.sql` with sage-2412) 264a's step moves one version. The design above still says 3j-3k; read it as 3k-3l. - `migrations/3k-3l.sql` is round 4's `3j-3k.sql` with three renames and nothing else: the copy - tables are `*_3k`, and the op values are `legacy-3l` and `migration-3l`. A step named for the - version it leaves should not write a value naming another one. + tables are `*_3k`, and the op values are `legacy-3l` and `migration-3l`. The op values name the + step's target version, as round 4's `legacy-3k` did on 3j-3k (sage-2415). No earlier migration + set a precedent either way. - store.mjs runs 236's 3j to 3k step, then 3k to 3l. `SCHEMA_VERSION` is `3l`, and `SCHEMA_SHA256` is the merged schema.sql's, cd68512212ce8bf8f5631138b2e63a340fa7b940088430649bb7784af7df162a. schema.sql merged with no conflict: 264a's edits are above 236's two tables at the end.