MigrationGuard

• 

  MigrationGuard: SQLite preservation checks and gated staging. Fictional demo data.

• 

  Independently applied Duo proposal: hosted repair passes. No autonomous Duo commit or manual human review claimed.

• 

  Actual local release recording: captured Duo proposal stages a verified artifact. Fictional data.

• 

  Actual hosted failure: smoke tests pass, but protected rows fall from 4 to 2. Release blocked.

Inspiration

A database migration can be syntactically valid, pass its application smoke test and still delete history. MigrationGuard addresses that blind spot for teams maintaining SQLite-backed tools: release evidence should include the records and values the team promised to preserve, not just whether the app starts. The example is deliberately fictional; no production incident or customer adoption is claimed.

What It Does

MigrationGuard rehearses a candidate migration on a temporary online backup from a read-only source connection. It checks integrity, foreign keys and the multisets of protected columns. A changed row, missing row or invalid contract returns BLOCK and exits nonzero. Reports omit row values.

The release CLI stages only an allowed candidate. It then independently checks the actual staging database, including the application smoke test. A receipt binds the SQL, contracts and staging artifact with SHA-256 hashes. A blocked release creates reports but no deployable database; output directories must be new, preventing a stale successful artifact from being mistaken for a failed release.

The Demonstrated GitLab Workflow

1. A deliberately destructive candidate lives in a labelled draft merge request on a separate demo branch. Its application smoke test passes. Its hosted release job fails because both protected tables fall from four rows to two.
2. A genuine GitLab-managed Duo Developer session diagnoses the filtering bug and proposes a one-line additive migration. The session explicitly makes no tracked edit, commit, push or merge.
3. The separate AI-assisted authoring workflow captures the proposed SQL, verifies its hash, runs the deterministic release checks and publishes that candidate on a separate reviewed-repair branch. The hosted pipeline passes. This is not a claim that Duo committed the repair or that Darshan personally performed a manual code review.
4. The main diagnostic revision passes 32 unit tests locally and in hosted CI. Gate rules, contracts and tests are not weakened to make the repair pass.

The implemented lifecycle focus is verification and release, with Duo proposing the corrective SQL. Production deployment is not claimed. The custom repair-flow YAML remains an uninstalled draft and is not the flow shown in the evidence.

Evidence Judges Can Inspect

• Seeded failure pipeline
• Actual Duo proposal session
• Independently applied repair pipeline
• Main diagnostic pipeline
• Hosted test log: 32 tests
• Run instructions and limitations
• Provenance and QA

How It Was Built

Python standard library, SQLite, GitLab CI/CD and actual foundational Duo flows. The source is public and MIT-licensed in the organizer-provisioned workspace. The project and its automation were created for this hackathon after October 5. Coding-agent assistance was used for implementation, tests, documentation and publication on Darshan's behalf. Genuine Duo session output is identified separately from hand-authored fixtures and reference configuration.

Challenges and Lessons

Foreign-key validity does not prove history survived: deleting related records can leave a perfectly consistent remainder. The checker must compare protected values, not merely count rows. Release verification must inspect the actual artifact independently, and failure diagnostics should not leak row values. The Duo run also taught an important provenance distinction: a proposed repair, an applied commit and a passing hosted pipeline are three different facts.

Limits and Next Steps

SQLite only, trusted migration SQL, a five-second rehearsal deadline and a 100,000-row cap per protected table. A pass proves only the declared invariants. This is database rehearsal, not an operating-system sandbox. Production load, locking, concurrent writes and rollback safety are not demonstrated. No quantified carbon savings, Google Cloud deployment or production traction is claimed. Next would be broader database coverage and evaluated repair proposals across a larger set of independently labelled migration failures.

Built With

• gitlab
• python
• sqlite