Roll back failed registry migrations so the same database can retry #126

Windows receiving supplement — #125 + #126 — 2026-10-13

The unchanged combined source at 6a09d400da59e12e16db14a33d3814af075df2d7 now passes the same 24 maintained headless persistence tests on Windows 11 x64 / Python 3.12.2 / SQLite 3.43.1 / pytest 8.3.5. There are zero failures, errors or skips; all eleven source/test/config/conftest guards are unchanged. Native PID 125332 completed with exit 0.

• Evidence-only head: 8220b08685e31ec69283ded99aa1334e6b77b702, on receiving/settings-registry-windows-7697-20261013, directly above the accepted combined source.
• Windows guide and single native packet.
• Existing Eyes Windows handoff and existing implementation ledger.

Independent receiving verified all 24 test identities against the prior supported Mac result, all embedded payload hashes, full publication tree and exact guide/packet readback. The supplement adds only the guide, native packet and additive PROGRESS entry; 1,345 prior files are unchanged. All-event head Actions count is zero.

This is candidate-only headless Windows evidence. Both issue-specific original-first histories and the combined supported Mac receipt remain intact below. No UI, daemon, hardware, installer, full-repository gate or Windows original-failure course is claimed; already-partial databases are not automatically repaired. Publication remains branch-only under the Actions hold.

Combined receiving branch — #125 + #126 — 2026-10-13

Both exact accepted persistence repairs are now available together on receiving/settings-and-registry-7697-20261013, commit 6a09d400da59e12e16db14a33d3814af075df2d7, tree 439b60bc839bc53994337d6ea32cb4932de5016d. Its actual ordered parents are current main 3f42f7431e3fcfcb60cb2580afaa41d7dc9deb85, settings #125 89d874bcc2bda39634f56305fb342fc24e87a397, and registry #126 08cff1a979e98ab4b0a9cedd8f1feb7976f290ae.

The composition reuses both production candidates and all maintained tests unchanged. All 24 combined cases pass on independent Python 3.12.8 / SQLite 3.53.4 / pytest 8.4.2, with all eleven source/test/config/conftest guards unchanged, no failures/errors/skips. A separate ThinkPad Python 3.14.4 diagnostic also passes all 24. No new test, source adaptation, Ruff rerun or license rerun was needed. The new supported combined receipt is distinct from the retained original-first component histories.

Open the combined source receiving guide or the direct combined receiving section in the existing Eyes document. The existing HAMON implementation ledger has the matching CaptureSuite #125 + #126 — combined receiving v1 — 7697 section. Both earlier document/ledger sections are preserved; no duplicate project document was created.

The complete published tree was independently read back: 1,346 leaves, exactly 4 owned paths modified and 12 added, 1,330 unrelated main leaves preserved, and no removals. All 80,078 characters of the newer main PROGRESS text remain intact, including the unrelated JUnit aggregation work. Both original receiving directories retain their exact accepted blobs. The three prior packet blobs and the new combined packet 6ba22a7eaff1ae979e0a6dbd75d991dcd55dbb5a each occur once. Ref, three parents, complete source/guide/packet bytes, Eyes text/links and the existing ledger section were independently verified.

Main is unchanged by this publication; no PR, Actions dispatch or installation was performed. The exact-head all-event query returns 0 workflow runs. Full Windows/UI/daemon/hardware qualification remains outside this headless receiving result. The registry fix does not automatically repair a database already left partial by an older build.

The sections below remain the original individual repair records and describe their own exact source commits.

Published and independently received source — 2026-10-13

The correction is published on fix/registry-migration-atomicity-7697-20261013, commit 08cff1a979e98ab4b0a9cedd8f1feb7976f290ae, tree 74b353d22baa8bf6e0710f26c01e9bbf8e8b2244. Parent main remained ab17b8c50af9892483b49ce4c125ef28f38eb72c at the final pre-publication check. All 31 tested source/config/instruction/workflow/licensing inputs match that parent.

The production delta is one explicit BEGIN in each migration script plus two explanatory comments. The existing connection context now commits or rolls back the migration DDL/DML and applied-version insert together. The v1 SQL, schema version, public open/read-only handling, registry CRUD, settings and desktop/daemon remain unchanged.

Supported receiving: the frozen independent four-method course on Python 3.12.8 / SQLite 3.53.4 changes from 3 failures/1 read-only control pass to 4 passes, no errors/skips. The exact four new maintained cases plus nine unchanged settings/registry/read-only cases change from 4 failures/9 passes to 13 passes on Python 3.12.8 / pytest 8.4.2. The same 13-case ThinkPad Python 3.14.4 course agrees as a separately labelled diagnostic. Scoped Ruff 0.14.10 reports zero diagnostics on the changed source and test under the exact project config. The unchanged repository license checker completes with exit 0 on the explicitly declared package/test/license subset.

The single receiving record links the unchanged independent packet af802a2fa60a50cbf3d28cd8d8dc04bb93337670 and author record 070b3af06c6f4ec6cffccade9c18df79f01c1a35. They retain original failures, the frozen receiver and pre-execution fixture correction history, exact source/tool identities, complete native observations/logs/JUnit, scoped license result and source guards. The final license runner's initial ENOSPC write produced only a verified empty unexecuted file; a later capacity recovery allowed the exact runner to complete. No cleanup or correctness reruns were performed for that recovery.

Published custody: the complete untruncated tree contains 1,325 leaves, exactly 2 modified and 4 added files, 1,319 unrelated leaves preserved, no removals, and one occurrence of the unchanged independent packet. All prior PROGRESS text is preserved. All 13 current open PRs were checked for source overlap, including newly opened #127; no registry/test conflict exists. The branch ref, commit parent/tree/message and published source were fetched after publication and match the frozen candidate fcf858d562b4cb361a53abfc39eccaff245b1a81.

This is branch-only source publication under the Actions hold. No PR or merge was created, workflow files remain unchanged, and an all-event exact-head query returned 0 workflow runs. The commit carries [skip ci] [skip actions]. Full Windows/UI/daemon/hardware qualification and installation remain unrun. Synthetic failure fixtures demonstrate transactional behavior; this is not an actual disk-exhaustion/crash experiment. The correction prevents new partial migrations and does not automatically repair an already-partial database from an older build.

Existing project handoff

The existing CaptureSuite native receiving handoff now includes CaptureSuite registry migration #126 — receiving supplement v1 — 7697. The same section is linked from the existing HAMON implementation ledger. Delivery independently verified final source/tree/ref/parent and exact full-content payloads, the zero Actions count, the document contents/links and the ledger's literal receiving command. The earlier #125 settings section is preserved byte-for-byte; the two repairs retain their separate source branches and stated qualification limits.

Original reservation and original-first receiving

Owner: continuing HAMON estate worker hamon-team-7697/product, coordinated with root; independent receiving by delivery.

Reproduced failure and existing contract

Current main is ab17b8c50af9892483b49ce4c125ef28f38eb72c. SETTINGS_REGISTRY.md requires each forward registry migration to run in its own transaction. The current AppRegistry._migrate calls executescript(sql) inside a connection context and then inserts the version marker. SQLite script statements can already have committed before a later step fails.

A native, original-source probe through public AppRegistry.open() appended one deliberately failing SQL statement after the unchanged v1 DDL. After the expected SQL error and explicit close, an independent SQLite connection found all five tables and two indexes still present, with no applied version. Retrying the original, valid migration against that same disposable database failed with table schema_migrations already exists. The five exact package source blobs matched before and after. This is a Python 3.14.4 / SQLite 3.46.1 diagnostic; supported Python 3.12 independent receiving follows.

Original registry source: libs/python/capture_session/capture_session/registry.py, blob c1d7799e1d2099424221b2f4af216a43a972c67a, SHA-256 809b26ce8d8efc0559a3854cf85ea74b4e486fcd77d253ebfa76bade64b0a8d1. Exact v1 SQL SHA-256: 6d4fa2227b8f21523741bd0c526b4f0e21e9d045fd60fa63d59271cb9031e97f. Original native receipt: /home/jacob/hamon-capturesuite-7697-registry-migration/original-probe.json.

Bounded repair

Make each migration's DDL/DML and applied-version insert share an explicit transaction. On failure, roll back that version; preserve previously committed versions and existing registry data; permit a retry on the same database. Keep schema version 1 and the existing SQL unchanged.

Fence:

• libs/python/capture_session/capture_session/registry.py: migration transaction boundary only.
• New tests/protocol/test_registry_migration_atomicity.py.
• One additive required docs/design/research/PROGRESS.md entry.
• One receiving record under docs/receiving/registry-migration-7697/.

Proposed isolated branch: fix/registry-migration-atomicity-7697-20261013. No candidate source has been exposed to the independent receiver. Its acceptance will cover late first-migration SQL failure and retry, a real trigger rejecting the version insert, preservation of a committed intermediate migration when a later one fails, and newer-version read-only preservation. Receivers use real disposable SQLite files and public open/close, without mocking execute/commit/rollback.

All 12 current open PR changed-file lists were fully paginated (including both pages for #94); no source/test collision exists. Shared PROGRESS text will be preserved. The open issue list and focused migration search identify no matching active repair owner. Root and project instructions are read. Settings #125 remains a separately published, completed receiving outcome.

Publication will use branch plus this issue under the standing Actions hold, with skip markers and post-publication workflow-run verification. The three workflows remain unchanged; no PR, merge, workflow dispatch, installation, desktop/hardware or full Windows success is claimed. The injected SQL failure demonstrates transactional behavior; it is not an actual disk-exhaustion experiment.