Installed App Release Guardian

• 

  SwiftUI Simulator: a saved purchase survives relaunch after a lost acknowledgment, using the repaired backend.

• 

  Same retry, different outcome: four accepted orders became five before repair and stayed four after. Fresh replays of saved sources.

• 

  GitLab Duo repairs api/orders.py on the existing branch. Independent checks stay pinned in a separate repository.

• 

  The exact Duo repair passes both clients, 10 backend invariants, 11 recovery requirements and 2 HTTP requirements.

• 

  The owner approves candidate 269f14f3, then merges MR !5. The agent neither approves nor merges. The backend is not deployed.

• 

  Missing operation identity: Duo's read-only assessment leaves the branch unchanged and the release blocked. No code commit.

• 

  Duo proposes a backend repair. A separate pinned policy checks its exact commit. The allowlisted owner decides whether to merge.

• 

  Rollback MR !4 retains two blocked proposals before a passing repair. Incomplete recovery stays blocked; this MR remains unmerged.

Inspiration

A purchase can succeed on the server while its receipt never reaches the phone. Customers keep older app versions and persisted offline queues, so a backend migration can turn a harmless retry into another order. Mobile teams need to know that accepted work survives both the upgrade and the way back.

What it does

Release Guardian is for mobile teams whose customers keep older app versions and offline purchase queues. It rehearses backend changes against frozen installed-client contracts and recovery histories. GitLab Duo diagnoses a failed source and repairs only the backend. Independent policy checks verify its exact commit before an allowlisted human decides the merge.

In the principal public run, both ordinary client suites passed, but migration and rollback changed an accepted receipt: four purchases became five. Duo fixed one backend file. The same frozen policy passed both clients 5/5 each, backend invariants 10/10, eleven recovery requirements and two HTTP requirements. The owner then played the signed approval job and merged that verified candidate.

How we built it

The application combines a Python/SQLite API, frozen Swift clients, a SwiftUI phone demo and one review website. A separate public verification repository supplies fixed-revision checks through a GitLab pipeline execution policy. Signed job identity, source hashes and producer bindings connect the failed source, Duo commit, policy pipeline, report and manual approval.

We built this from scratch for Path A / Start Fresh / Supervised. The main application pipeline also packages the review service and runs advisory SAST and secret detection. The owner manually hosts the review website on Google Cloud Run; the site cannot start Duo or consume GitLab credits. The latest source includes a bounded fixed receipt replay of saved backend bytes with fresh databases. The deployed review presents the current public installation, and its bounded replay reproduces the before-and-after receipt result without GitLab credentials or model calls. The broader Swift and worker experiments are available locally.

Agent and pipeline stages covered: Create — Duo's backend commit on the existing branch; Verify — frozen clients, backend invariants, eleven recovery and two HTTP requirements; Package — the review-app package job; Secure — advisory SAST and secret detection on main, with findings disclosed; Govern — independent pipeline policy, signed job identity and an owner-played approval job. Manual hosting is separate; no agent-driven release or monitoring stage is claimed.

What we achieved

Seven code-producing Duo attempts, two rejected proposals, one read-only refusal and one owner approval. No agent approval or merge. The seven attempts include the two rejected proposals.

Six deliberately seeded public scenarios retain their full evidence: five successful repairs and one read-only missing-identity refusal. The rollback scenario includes two rejected Duo proposals before its third repair passed the unchanged gate. An incomplete recovery route was kept as incomplete. Only the principal repair was owner-approved and merged; evaluation MRs remain separate and unmerged.

Judges can inspect the public pipelines and commits, run a bounded receipt comparison, download all six cases, and verify the retained evidence with Python only. The semantic verifier rejects a missing fulfillment even after the altered data is rehashed.

Challenges and what we learned

Passing request/response tests does not establish that accepted receipts survive migration. Persisted identities, account boundaries, intentional duplicate-looking purchases and rollback need their own observations. An AI proposal can improve one path while breaking another, so we retained both rejected proposals and rechecked the exact code each time.

Missing identity is a protocol limitation. Without a stable operation identifier, the backend cannot safely distinguish a retry from another intended purchase. The read-only assessment left that release blocked rather than shrinking support. Its original answer also had a secondary provenance explanation error; the public verification note preserves and corrects it.

What's next

Apply the adapter to an external mobile API and its real migration history, expand observed failure histories, and evaluate the workflow with independent mobile developers. Production impact and usability gains require that additional validation.

Evidence

• Principal native Duo flow
• Duo's one-file repair
• Exact-repair policy checks
• Owner-played signed approval
• Owner-merged MR !5
• Post-merge main pipeline
• Missing-identity refusal · MR !7 · no code commit
• Six scenarios, rejected proposals, refusal and exact executed flow definitions
• 90-second judge guide
• Live review app · current public installation

Scope and limits

All orders, clients and fulfillment effects are synthetic; no payments or production users are claimed. Thirteen means eleven recovery plus two HTTP requirements, alongside the client and backend tests. Client 0.9 is a declared profile without a native executable fixture. Local consistency checks do not authenticate archived GitLab signatures offline. Security scans are advisory; their current findings and context are disclosed in the repository. Cloud Run hosts the review service, not the repaired backend. Original repositories retain dated development history and are not counted again.

Built With

• css3
• docker
• gitlab
• gitlab-ci/cd
• gitlab-duo-agent-platform
• google-cloud
• google-cloud-run
• gunicorn
• html5
• javascript
• python
• sqlite
• swift
• swiftui