Problem
dactyl-db v0.1.6 automatically bootstraps a fixed set of tables when opening SQLite and routes every public call through a query-map path. Decapod owns the canonical decapod.db schema, migrations, indexes, triggers, PRAGMA setup, and rollback/backup lifecycle. The current facade has no explicit caller-owned schema or migration boundary and cannot safely represent multi-statement DDL.
Required contract
Define a migration/DDL surface that:
- lets the caller own and version its schema;
- supports deterministic single statements and explicit batches where needed;
- distinguishes query rows, affected-row writes, and schema operations;
- defines transaction and rollback behavior;
- prevents the facade from silently creating unrelated tables in a caller-owned database;
- works for local SQLite and has a documented Neon/Propodus equivalent.
Proof
Add a fixture with caller-owned tables, indexes, triggers, upgrades, rollback, and a fresh empty database. Prove that dactyl does not mutate undeclared schema. Link to DecapodLabs/decapod#1118, #1111, and #1120.
Problem
dactyl-db v0.1.6 automatically bootstraps a fixed set of tables when opening SQLite and routes every public call through a query-map path. Decapod owns the canonical decapod.db schema, migrations, indexes, triggers, PRAGMA setup, and rollback/backup lifecycle. The current facade has no explicit caller-owned schema or migration boundary and cannot safely represent multi-statement DDL.
Required contract
Define a migration/DDL surface that:
Proof
Add a fixture with caller-owned tables, indexes, triggers, upgrades, rollback, and a fresh empty database. Prove that dactyl does not mutate undeclared schema. Link to DecapodLabs/decapod#1118, #1111, and #1120.