Open an issue. Walk away. It ships, or it tells you why not.

A GitLab Duo flow takes an issue to production through a test gate it can trust, security scans, staging and a verified promotion. testrazor is the gate.

See the recorded run GitLab project

Proof: the deploy this run shipped

The pipeline's production app reports the commit it serves. testrazor-transcend.vercel.app is the deploy this run shipped.

recorded 2026-10-27
4f7e605acommit production served
deploy-13GitLab release
32 x 2tests, run twice
0flaky
0real failures
PASSgate

Recorded values from the run of 2026-10-27. Production moves on with later pushes; the run is pinned by release deploy-13 and pipeline 2994109303.

The loop, nine stages, no human in the middle

Assign the issue to the flow's service account. GitLab CI does the rest, and the flow reports back on the issue.

  1. Plan

    The issue is the intent; the flow restates its acceptance checks.

  2. Create

    The flow writes the change and a test that fails without it, one merge request.

  3. Verify

    testrazor runs only the tests the change reaches, twice; flaky is quarantined, real failures block.

  4. Secure

    SAST and Secret Detection; High or Critical, or any secret, blocks.

  5. Package

    The site is built only if the gates passed.

  6. Release

    Protected main merges only the exact SHA that passed, deploys staging, promotes it.

  7. Configure

    Environments, protected deploy credentials, pinned agent image.

  8. Monitor

    Smoke checks prove the served commit; failure rolls back automatically.

  9. Govern

    The flow cannot edit CI, gates or tests; 3 fix attempts, then BLOCKED.

Why the gate matters

A hands-off agent is only as safe as the green check it merges on.

Without testrazor

  • Slow full suite.
  • Random red from flaky tests.
  • The agent retries until green.
  • A real bug merges.

With testrazor

  • Only the tests the change reaches.
  • Run twice.
  • Flaky quarantined by evidence.
  • A real failure always blocks.

The recorded run, 2026-10-27 (UTC)

Every line links to the real GitLab page.

  1. Issue #1 opened and assigned to the flow.
  2. The flow opens merge request !1 with code and a test.
  3. The first merge request pipeline fails on our CI config; the flow rebases onto the fix (attempt 1 of 3).
  4. The flow's merge call is refused (HTTP 403, flow tokens cannot merge). It posts BLOCKED on the issue instead of working around it.
  5. We add a pipeline-side merge with a SHA guard; the flow resumes the same merge request.
  6. Our first pipeline-side merge trigger fails (this project forbids pipeline variables); we fix it on main and the flow rebases again at 11:37.
  7. Merge request pipeline green: 32 tests, 0 flaky, 0 real failures, security gate PASS. testrazor ran all 10 test files because the change touched README.md, which it cannot map to tests, so it failed safe.
  8. A pipeline on protected main merges !1 (using the operator's merge token) at the passing SHA 145b8b0e as 4f7e605a.
  9. Main pipeline: staging verified, production promoted and verified serving 4f7e605a, release deploy-13.
  10. The flow posts Release report: SHIPPED on issue #1.

Guardrails

  • The flow may edit source and tests only. It cannot edit CI, the gates, the quarantine or existing tests.
  • It cannot skip a test or weaken a gate.
  • Three fix attempts, then it stops and reports BLOCKED with the reason.
  • Flow tokens cannot merge. A protected main pipeline merges only the exact SHA that passed every gate.
  • Production is promoted only after staging serves the expected commit; a failed smoke check rolls back.
  • Credentials: deploy and merge tokens are protected variables; merge request pipelines and agent code never see them.