fix(dynseal): say the schema was retired, not that a migration is missing #13
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/dynseal-schema-was-retired"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
dynseal/forge_db.pyonmaintells you to applymigrations/20260928_2014_dynseal_provenance.sqlin the spel repo. That migration was withdrawn — spel#901 is closed unmerged — somaincurrently points at a file that will never exist. I introduced that pointer in #11; this removes it.More importantly, it replaces it with what actually happened, because the premise behind spel#901 was wrong.
What I got wrong
spel#901 read "the three tables are absent from
information_schema" and concluded "the migration never applied, so the353_dynseal_provenanceledger row is false." The absence check was right. The inference was not: I checked whether the tables exist now and never checked whether anything had dropped them.Something had.
20260523_0700_drop_verified_stubs.sql, applied 2026-05-24 and registered in the ledger, contains:and its header states the criterion the audit applied:
Counting rows in a table requires the table to exist. So migration 353 applied on 2026-05-09 exactly as the ledger says, its tables sat unused for fifteen days, and a deliberate stub-cleanup removed them on 2026-05-24.
The schema is absent by decision, not by accident. The ledger row is accurate.
What this changes
MIGRATION = "20260928_2014_dynseal_provenance.sql"CREATED_BY/RETIRED_BY, both archived filenames with their applied datesforge_db.pyrather than a second copy of itThe error asks for the decision rather than for a migration run, because re-creating those tables would reintroduce precisely what a documented audit removed, on grounds that still hold — dynseal has no production caller today.
Verification
Not a mock.
assert_dynseal_schema()called against the live forge database, where the three tables really are absent:Both files compile. Nothing imports the removed
MIGRATIONconstant (checked acrossdynseal/anddocs/). No conflict with open PR #12, which touchesenterprise_adapter.py,minimal_boot_verifier.py,test_security_scenarios.py,pytest.iniandci.yml— not these two files.The wider check, since the reasoning generalised
The argument behind spel#901 was that the archived original has no
BEGIN/COMMITand registers itself before its DDL, so under autocommit the registration could survive a failed migration. That defect is real — it is why the current template wraps the file and registers last. But "could" is not "did".Scanning all 781 archived migrations: 84 register before their first DDL, 144 register with no
BEGIN, 28 do both. I checked every object those 28 claim to create against the live catalogue. Three looked missing; all three are explained by a later deliberate drop:20260508_2247_dynseal_provenancedrop_verified_stubs, 2026-05-2420260511_0047_style_guide_schemacorpus.style_rules,corpus.dictionary_entriesdrop_phase2_stubs, 2026-05-24 — "content ingested, quality/health pipeline never built"20260511_0226_wish_executioncore.wish_execution(its 5 functions survive)20260502_2221_drop_wish_execution_legacyZero false ledger rows across all 28. The defect class is real in the files and produced nothing in the database. Worth knowing; not worth a migration.
Impact Statement
Changes two error messages and their surrounding comments in
dynseal/, which has no production caller. No schema change, no behaviour change on any success path — the only reachable difference is the text raised when dynseal starts against a database lacking its tables, which is every database today. Reverting is a one-commit revert with no data implications.`forge_db.py` told you to apply `migrations/20260928_2014_dynseal_provenance.sql` in the spel repo. That migration was withdrawn (spel#901, closed unmerged), so the instruction pointed at a file that will never exist. I introduced that pointer; this removes it and replaces it with what actually happened. The premise behind spel#901 was wrong. It read "the three tables are absent from information_schema" and concluded "the migration never applied, so the ledger row is false." It never checked whether anything had dropped them. Something had. `20260523_0700_drop_verified_stubs.sql`, applied 2026-05-24 and registered in the ledger, contains: -- Public metadata stubs (DevSecOps framework never connected) DROP TABLE IF EXISTS public.information_provenance CASCADE; DROP TABLE IF EXISTS public.pattern_attestations CASCADE; DROP TABLE IF EXISTS public.supply_chain_log CASCADE; and its header states the criterion: "All 17 tables have zero rows and no active INSERT/SELECT in the live codebase." Counting rows requires the tables to exist. So 353 applied on 2026-05-09 exactly as the ledger says, the tables sat unused for fifteen days, and a deliberate audit removed them. The schema is therefore absent by decision. The error now says so, names both migrations by their archived filenames, and asks for the decision rather than for a migration run — because re-creating the tables would reintroduce precisely what that audit removed, on grounds that still hold: dynseal has no production caller today. Verified by calling assert_dynseal_schema() against the live forge database, where the tables really are absent, and reading the message it raises.