Reverse Ready

Your release works. Will rollback? Follow a data compatibility failure through GitLab Duo’s proposal, independent CI proof and a human decision.

Comment

Inspiration

The deployment is green. The new customer exists. Then the old version returns HTTP 500.

A rollback can restore yesterday's code without restoring its ability to use today's data. Backend leads and release engineers need to test that return before a migration ships. Preserving every record is not enough if old code cannot read or edit it.

What it does

Reverse Ready follows one concrete journey: observe a rollback failure → ask GitLab Duo for a focused repair → verify the exact candidate independently → let a maintainer review the evidence.

In the Customer API demonstration, v2 moves an email into a new representation. v2 creates and reads Customer #104 successfully; unchanged v1 then fails after rollback. After Duo's proposed two-file repair, v1 reads and edits that customer, v2 sees the exact edit, and all four logical records are preserved.

A separate Orders repository exercises a different money-format migration and its own reviewed adapter. Old code adjusts the new order from PLN 67.50 to PLN 52.34; new code sees that amount. Both repositories have original GitLab CI artifacts and revision-bound reviews. They are synthetic demonstrations, not customer deployments.

How we built it — and where GitLab matters

The Node.js 24 verifier runs real old/new/old HTTP processes against one continuous disposable SQLite database. It records operations, observed values and database-continuity checks. A React/TypeScript interface makes the failure, proposal and independent result readable.

GitLab Duo Agent Platform performs the diagnosis and proposes the repair. Native Customer Duo session 10020509 produced draft MR !2 at 3cc7f01e32c06ff08afe6c3064f4d6c152b4905a. Separate Orders session 10026330 produced its own two-file proposal at c24b91ee0042478b83ef3195bcf6a6e3a6c48fa1. The operator did not substitute a hand-written application repair for these demonstrated proposals.

AI reasoning is not the proof. A separate protected-main GitLab pipeline tests the captured full candidate SHA with the unchanged old version and trusted verifier. The controller collects and authenticates the original report and source gate. Customer job 17451779289 and Orders job 17466721130 passed all 11 operations, preserved four records and verified six continuity checkpoints. A changed commit needs a new check; missing or mismatched evidence blocks review. Saved review does not merge or deploy either repair.

This is Start Fresh: Assisted. A maintainer initiates the work, performs the native GitLab handoff and reviews the result. The public Google Cloud Run deployment is a read-only evidence viewer; new work runs through the local operator and native GitLab Duo/CI. The original Cloudflare URL remains an alternative entry. The source includes setup, tests, original proof links, MIT license and visible CI history.

Challenges and what we learned

The difficult part was keeping a persuasive AI proposal separate from evidence that the actual repaired revision works. We made candidate, trusted-source and original-artifact identity explicit, and kept the candidate's CI configuration out of the verification path.

We also challenged the idea with a strong alternative: a good integration test plus Duo can check this behavior too. Our recorded AI-operated comparisons did not establish a repeated effort or retrieval advantage. We retained those results. There is no claim of human time saving, production recovery time, customer adoption or ROI.

Reverse Ready's implemented contribution is the coordinated reviewable record linking the failure, AI proposal, original CI proof and human decision. Its commercial hypothesis is a focused team tool with private evidence coordination and self-hosted support; willingness to pay still needs validation with real maintainers.

Delivery you can inspect

The working application runs on Google Cloud Run. Protected-main jobs publish and re-download an immutable host package, create a commit-bound GitLab Release, and check the deployed UI, API and original proof identities. The lifecycle ledger documents Plan, Create, Verify, Govern, Package, Release, Configure and a bounded Monitor observation, with the actual actor for each. Secure is unclaimed.

A separate native Duo audit checked GitLab delivery receipts. Its independent live requests were blocked by its environment's proxy; public serving checks are separately recorded by CI and anonymous probes. This remains an operator-authorized Assisted workflow, with each rollback verdict scoped to its own scenario and candidate. Inspect the original receipts and limits.

Measured efficiency, with a defined boundary

Reusing verified immutable evidence cut median paired process CPU by 93.77% in our 1,000-response Cloud Run benchmark. With the same assumed one-hour, one-vCPU/512-MiB reservation, our component SCI model estimates 0.548790 → 0.547315 gCO2e per batch (0.27% lower). Energy is modeled, 24 of 121 sensitivity cases are unfavorable, and this does not establish whole-product savings.

All observations, preregistered protocols, public coefficients and sensitivity cases are available. This component experiment is separate from the unsuccessful effort-advantage comparisons retained above.

Try it

Before you ship the change, prove the way back.

Built With

Share this project:

Updates

Submission history