main · last commit
13 days ago ·
7g0stsfu
ah-g39 SPEC section 7: storage schema stale by four migrations
Past Stand
bd reopen ah-g39
| Created by | Eugene Blikh |
| Owner | bigbes@gmail.com |
| Created | 2026-08-04T23:52:27Z |
| Started | 2026-08-04T23:54:12Z |
| Updated | 2026-08-05T00:03:45Z |
| Closed | 2026-08-05T00:03:45Z |
Found during the ah-efe sweep; outside that epic's assigned sections, so filed separately. §7 documents the schema through v2 only — 'step 1→2 (Stage 2, schema v2) adds runs.timeout_seconds' — and its DDL block shows only tasks/runs/events. internal/store/store.go:94 has SIX entries in schemaMigrations: base, runs.timeout_seconds, task_parents, tasks.auto_routes, kv, yonote_qa. This matters more now than it did: ah-efe.1 just documented the port methods those tables back (RecordChild/GenerationOf/ParentOf/ChildIDsOf, GetKV/SetKV, CreateQA/QAByTask/QAByComment/MarkQAAnswered), so §7 is the last place the storage layer still reads as Stage 2 — a reader who follows §6's Store interface into §7 finds no table behind half of it.
§7's DDL and its migration-step list match schemaMigrations element for element, with each step naming the feature and bead that introduced it. Verified against internal/store/store.go and the embedded schema.sql.
No outgoing dependencies.
Nothing depends on this issue.
| id | ah-g39 |
| content_hash | 4c8f2bcd36f6af9659209ee12fafe09dcc3b552de41990822769510f698952b2 |
| title | SPEC section 7: storage schema stale by four migrations |
| description | Found during the ah-efe sweep; outside that epic's assigned sections, so filed separately. §7 documents the schema through v2 only — 'step 1→2 (Stage 2, schema v2) adds runs.timeout_seconds' — and its DDL block shows only tasks/runs/events. internal/store/store.go:94 has SIX entries in schemaMigrations: base, runs.timeout_seconds, task_parents, tasks.auto_routes, kv, yonote_qa. This matters more now than it did: ah-efe.1 just documented the port methods those tables back (RecordChild/GenerationOf/ParentOf/ChildIDsOf, GetKV/SetKV, CreateQA/QAByTask/QAByComment/MarkQAAnswered), so §7 is the last place the storage layer still reads as Stage 2 — a reader who follows §6's Store interface into §7 finds no table behind half of it. |
| design | |
| acceptance_criteria | §7's DDL and its migration-step list match schemaMigrations element for element, with each step naming the feature and bead that introduced it. Verified against internal/store/store.go and the embedded schema.sql. |
| notes | |
| status | closed |
| priority | 3 |
| issue_type | chore |
| assignee | NULL |
| estimated_minutes | NULL |
| created_at | 2026-08-04T23:52:27Z |
| created_by | Eugene Blikh |
| owner | bigbes@gmail.com |
| updated_at | 2026-08-05T00:03:45Z |
| closed_at | 2026-08-05T00:03:45Z |
| closed_by_session | |
| external_ref | NULL |
| spec_id | |
| compaction_level | 0 |
| compacted_at | NULL |
| compacted_at_commit | NULL |
| original_size | NULL |
| sender | |
| ephemeral | 0 |
| wisp_type | |
| pinned | 0 |
| is_template | 0 |
| mol_type | |
| work_type | |
| source_system | |
| metadata | �{} |
| source_repo | |
| close_reason | Done in 6b7bacf. §7 documented the migrator as if it stopped at v2 and its DDL block showed only tasks/runs/events, so task_parents, kv and yonote_qa — three of the tables §6's Store interface is written against — had no schema behind them at all, and tasks.auto_routes was missing from the tasks DDL even though it is in taskColumns and every SELECT. §7 now enumerates all schemaMigrations elements with the feature and the introducing bead: 0→1 base schema.sql (ah-nyl.2), 1→2 runs.timeout_seconds (ah-xuc.4), 2→3 task_parents (ah-0ge.1), 3→4 tasks.auto_routes (ah-4el), 4→5 kv + yonote_qa in ONE element (ah-ptu). The DDL block is now the EFFECTIVE schema after all five steps, with a header note that schema.sql itself is frozen at the v1 shape and does not contain the two ALTERed columns, which are marked inline. CORRECTION TO THIS BEAD'S OWN PREMISE: schemaMigrations has FIVE elements, not six — kv and yonote_qa are two CREATE TABLEs inside one element — so schemaVersion == 5 and §7 was stale by three migrations, not four. New prose covers auto_routes never resetting, task_parents's ON CONFLICT(child_id) idempotency and its ok=false-means-root contract, kv's missing delete (cleared to "") and its two key shapes, and yonote_qa's comment_id UNIQUE spawn guard. It also states plainly that there is NO CREATE INDEX anywhere — the only indexes are the ones SQLite derives from PRIMARY KEY/UNIQUE, so ChildIDsOf and any events.task_id scan are table scans — and that kv (one delegation_park row per delegating attempt) and events both grow unboundedly with nothing pruning them. |
| event_kind | |
| actor | |
| target | |
| payload | |
| await_type | |
| await_id | |
| timeout_ns | 0 |
| waiters | |
| hook_bead | |
| role_bead | |
| agent_state | |
| last_activity | NULL |
| role_type | |
| rig | |
| due_at | NULL |
| defer_until | NULL |
| no_history | 0 |
| started_at | 2026-08-04T23:54:12Z |
| is_blocked | 0 |
| issue_id | ah-g39 |
| label | milestone:v0.1.0 |
| id | 019fcf31-5d81-7cd1-888e-af516a4badd7 |
| issue_id | ah-g39 |
| event_type | created |
| actor | Eugene Blikh |
| old_value | |
| new_value | |
| comment | NULL |
| created_at | 2026-08-05T02:52:26Z |
| id | 019fcf32-f83a-7da8-93f2-50fe5a1dcee5 |
| issue_id | ah-g39 |
| event_type | status_changed |
| actor | Eugene Blikh |
| old_value | {"id":"ah-g39","title":"SPEC section 7: storage schema stale by four migrations","description":"Found during the ah-efe sweep; outside that epic's assigned sections, so filed separately.\n\n§7 documents the schema through v2 only — 'step 1→2 (Stage 2, schema v2) adds runs.timeout_seconds' — and its DDL block shows only tasks/runs/events. internal/store/store.go:94 has SIX entries in schemaMigrations: base, runs.timeout_seconds, task_parents, tasks.auto_routes, kv, yonote_qa.\n\nThis matters more now than it did: ah-efe.1 just documented the port methods those tables back (RecordChild/GenerationOf/ParentOf/ChildIDsOf, GetKV/SetKV, CreateQA/QAByTask/QAByComment/MarkQAAnswered), so §7 is the last place the storage layer still reads as Stage 2 — a reader who follows §6's Store interface into §7 finds no table behind half of it.","acceptance_criteria":"§7's DDL and its migration-step list match schemaMigrations element for element, with each step naming the feature and bead that introduced it. Verified against internal/store/store.go and the embedded schema.sql.","status":"open","priority":3,"issue_type":"chore","owner":"bigbes@gmail.com","created_at":"2026-08-04T23:52:27Z","created_by":"Eugene Blikh","updated_at":"2026-08-04T23:52:27Z"} |
| new_value | {"status":"in_progress"} |
| comment | NULL |
| created_at | 2026-08-05T02:54:11Z |
| id | 019fcf3b-b6c0-7484-b870-4bb209968c48 |
| issue_id | ah-g39 |
| event_type | closed |
| actor | Eugene Blikh |
| old_value | |
| new_value | Done in 6b7bacf. §7 documented the migrator as if it stopped at v2 and its DDL block showed only tasks/runs/events, so task_parents, kv and yonote_qa — three of the tables §6's Store interface is written against — had no schema behind them at all, and tasks.auto_routes was missing from the tasks DDL even though it is in taskColumns and every SELECT. §7 now enumerates all schemaMigrations elements with the feature and the introducing bead: 0→1 base schema.sql (ah-nyl.2), 1→2 runs.timeout_seconds (ah-xuc.4), 2→3 task_parents (ah-0ge.1), 3→4 tasks.auto_routes (ah-4el), 4→5 kv + yonote_qa in ONE element (ah-ptu). The DDL block is now the EFFECTIVE schema after all five steps, with a header note that schema.sql itself is frozen at the v1 shape and does not contain the two ALTERed columns, which are marked inline. CORRECTION TO THIS BEAD'S OWN PREMISE: schemaMigrations has FIVE elements, not six — kv and yonote_qa are two CREATE TABLEs inside one element — so schemaVersion == 5 and §7 was stale by three migrations, not four. New prose covers auto_routes never resetting, task_parents's ON CONFLICT(child_id) idempotency and its ok=false-means-root contract, kv's missing delete (cleared to "") and its two key shapes, and yonote_qa's comment_id UNIQUE spawn guard. It also states plainly that there is NO CREATE INDEX anywhere — the only indexes are the ones SQLite derives from PRIMARY KEY/UNIQUE, so ChildIDsOf and any events.task_id scan are table scans — and that kv (one delegation_park row per delegating attempt) and events both grow unboundedly with nothing pruning them. |
| comment | NULL |
| created_at | 2026-08-05T03:03:44Z |
| id | 019fcf42-089d-7505-b8b2-75439675d3a0 |
| issue_id | ah-g39 |
| event_type | label_added |
| actor | Eugene Blikh |
| old_value | NULL |
| new_value | NULL |
| comment | Added label: milestone:v0.1.0 |
| created_at | 2026-08-05T03:10:39Z |
No comments.
Close reason