Release Rehearsal

Rehearse the release against the work people already saved.

Comment

Release Rehearsal

Inspiration

A photographer finishes a selection for a client: the hero frame, a careful crop, an exposure adjustment and a note about leaving room for a cover title. The next app version opens the project. The photographs are still there. The decisions are gone.

Release Rehearsal makes that loss visible before someone approves a release. It is built for teams whose updates must preserve the projects people have already made.

What it does

The review studio runs a candidate migration against a retained snapshot, then compares the saved notes, editing decisions and attachment identities. The same photograph appears on both sides, so a changed crop comes from the saved data rather than a substituted image.

Three synthetic scenarios show different outcomes: a compatible upgrade passes; a defective migration loses notes and edits; and an ambiguous attachment mapping stops because two cameras produced the same filename. The source does not establish which attachment was intended, so the tool refuses to guess.

The reviewer can inspect field-level evidence, export reports and open a CI bundle in read-only mode. The original failure remains available after a repair. Local approval is tied to the current evidence, so a stale request cannot approve a different result.

How I built it

The application uses Node.js, JavaScript, HTML and CSS, with a migration engine, local evidence storage and a photographic review interface. The fictional projects and photographs are synthetic; the exposure preview is approximate.

The local restoration recipe is explicitly labelled. It restores a rehearsal snapshot without changing migration source or calling an AI model. The GitLab path is different: it executes the committed candidate, and Duo repairs the source itself.

A real GitLab Duo session investigated the failure and opened draft MR !1. The repair changes only lib/candidate-migration.mjs. Comparison with its parent confirmed that the other 41 files, including the fixtures and evaluator, were unchanged.

The initial pipeline caught the defect with five of seven saved-draft checks passing. CI reran the repair at 624d3c0f04d7318c08d779c18b3d16e6d1d8083f: all four automated jobs passed, including seven of seven saved-draft checks, the compatible upgrade and the refusal case.

After I accepted the evidence review, the manual job passed and the full pipeline became Passed. Its artifact records the reviewed commit, candidate hash and scenario outcomes. The MR remains a draft; accepting the evidence does not merge or deploy software.

Challenges

The central challenge was keeping a convincing demonstration separate from a verified repair. Restoring a snapshot can make the interface look correct without fixing the migration. The CI path therefore runs the committed repair without the local shortcut.

The ambiguous case exposed another boundary: a confident choice between two identically named files could silently damage the project. Refusing that choice is part of the workflow, not a missing success screen.

Accomplishments

The result connects a visible loss of work to a real source change, repeatable CI checks and an explicit human decision. Both the failed baseline bundle and the repaired bundle were imported into the studio as read-only evidence. The reported commit, candidate hash and original job remain visible.

The local validation recorded on October 15 includes 37 passing tests and desktop/mobile checks. The later remote run demonstrates a candidate-only Duo repair and a passing pipeline after human review. These are engineering checks on supplied scenarios, not production benchmarks or a user study.

What I learned

A project that opens is only the beginning of compatibility. The design lesson was to make the user's saved decisions the subject of review. Separating the local demonstration, the source repair and the approval record made the automation easier to inspect and its limits easier to explain.

What's next

Test continuity contracts with real product teams, add migration adapters and measure which losses existing tests miss. Production schemas also need explicit rules for values such as a null delivery setting, which this prototype treats as absent. The current checks do not establish safety for arbitrary migrations.

Built with

Node.js, JavaScript, HTML, CSS, Git, GitLab CI/CD and GitLab Duo Agent Platform. The custom flow was configured for supervised work: the agent performed the repair steps, and a person accepted the resulting evidence.

AI assistance supported development and synthetic asset creation. The demonstration uses Sebastián's recorded voice and edited recordings of the actual app and GitLab workflow. It is not a single continuous recording of the agent run.

Built With

Share this project:

Updates

Submission history