ZeroScream

Duo writes the migration. ZeroScream refuses shutdown while accepted work is unfinished, then verifies a fresh business result after retirement.

Comment

Try it / testing instructions

GitLab Duo (native agent session), Orbit, a reviewed MR, exact passing CI and an independent CI verifier connect this retirement's evidence.

A green health check doesn't mean a service is safe to shut down. ZeroScream refuses retirement until the accepted work is finished and proven.

  1. Open the live console. Inspect the preserved run: four completed obligations, seven passing gates, the historical unfinished-work refusal, the post-removal business canary and signed receipt. The public refusal record records why planning refused.
  2. Inspect the GitLab issue, actual flow configuration, migration MR and exact passing pipeline. The native Duo session page requires authorized GitLab access; the video shows recorded provider-page evidence. Public configuration, MR and CI remain inspectable anonymously.

  3. Open the CI job's public verification-summary.json. Verify the exported receipt and events offline with the pre-pinned public key using the developer guide.

  4. Optionally inspect the separate Cloud Run retirement experiment: exact provider-confirmed removal and matched synthetic responses, with no carbon-saving claim.

This is a controlled synthetic staging run, preserved and independently verifiable. Public inspection does not rerun retirement. It is not automatically re-runnable against an arbitrary repository or service; another integration needs its own reviewed contracts and adapters.

Plain-language terms: obligations are business work already accepted; gates are mandatory evidence checks; a canary is a fresh test event proving useful work still completes after removal.

Inspiration

The most important result in ZeroScream's demonstration was a refusal. A new delivery had succeeded through the replacement service. Six of seven checks passed. Two earlier deliveries were still unfinished, so ZeroScream refused to prepare the shutdown.

That is the problem I wanted to solve: replacing a service does not settle the work it already accepted. A passing build and a healthy successor leave a difficult final question unanswered: can the old service actually go away?

I built ZeroScream for platform teams retiring a legacy dispatcher or background worker without abandoning deliveries already promised to downstream systems. GitLab is the place to propose, review, test and inspect that migration.

What it does

ZeroScream connects an issue, an owned service, its consumers and the obligations that must survive its removal. GitLab Duo proposes the consumer migration; deterministic gates decide whether the evidence supports retirement.

The deployed showcase uses a synthetic webhook platform. It deliberately retained two original deliveries: one held and one retry-pending. Newer successor success could not substitute for those results. Planning returned a refusal with only two of four accepted obligations complete.

After those same deliveries completed, all four obligations and all seven gates passed. A separately authorized executor removed only the registered legacy dispatcher process on the private Google Cloud VM. A fresh event then traversed the installed consumer and matched the independent receiver's durable business record.

A signed receipt binds the exact target, approved plan, migration and frozen evidence snapshot. Verification checks both its signature and the recorded evidence digest.

How I built it

A native GitLab Duo session inspected the approved consumer, queried Orbit and created the actual migration merge request. The reviewed merged revision passed its exact default-branch contract pipeline before installation. ZeroScream then compared the source bytes loaded by the running consumer with that verified migration.

The configured flow has one retirement_agent, with Orbit/repository tools and native branch, commit and MR creation. Deterministic policy checks and a separately authorized executor control retirement; they are not additional AI agents.

The policy engine uses Python, FastAPI, Pydantic and SQLite. Workload plugins define accepted work, independent completion checks and post-removal business verification. Node.js services and an isolated outbox worker exercise those contracts. React and TypeScript provide the evidence console and developer workspace.

Cloud Run supplies the public HTTPS edge to a persistent private Compute Engine controller. OpenTelemetry trace ingestion was verified in Google Cloud. Short-lived, audience-bound GitLab identity limits agent access; the migration agent does not receive the retirement executor credential or signing state.

Challenges

Repository intent, passing CI and deployed code are separate facts. I had to connect them without treating any one as a substitute for the others. Runtime caller identity and business completion also needed independent evidence rather than an agent's interpretation.

The post-removal check required more than an HTTP success response. It had to exercise the installed client and match the receiver's actual durable effect. Failed and refused agent attempts remain in the attempt ledger.

Accomplishments

The connected workflow demonstrated genuine Duo execution, Orbit context, a reviewed MR, exact passing CI, installed source verification, unfinished-work refusal, scoped removal and a fresh business canary. Offline verification passed, and a controller restart preserved the retired state, completed work and unchanged receipt.

A separate GitLab CI verifier independently checked the accepted proof and published artifacts. The reusable installer also passed evidence verification in the supplied consumer repository. That verifies the same retirement; it is not a second removal.

Additional cloud retirement validation

A separate controlled experiment exercised the existing Cloud Run adapter against one exact IAM-private test service. Identity, permission and ETag checks preceded deletion; a separate provider read confirmed absence. The unchanged successor returned 300/300 independently hash-verified responses before removal, 300/300 afterward and 5/5 fresh canary responses. The before/after p95 response times were 328/313 ms. Both test services were removed afterward, while the original demo, work ledger and signed receipt remained unchanged.

Inspect the cloud experiment and its method and raw evidence. This is direct adapter validation, separate from the original complete Duo/MR/CI/seven-gate/signed-receipt workflow. Minimum instances stayed at zero. No net energy or carbon saving is established.

What I learned

An application's completion contract matters more than its deployment status. New success cannot erase old obligations. AI is useful for proposing a migration, while explicit evidence and authorization must govern the final destructive action.

What's next

The core includes webhook-delivery and document-export plugins. Additional applications need reviewed workload and runtime adapters; connecting a repository alone cannot establish compatibility.

Production expansion includes confidential evidence access controls, stronger executor/signing separation, backups and externally enforced archival. The original end-to-end trial retired an owned staging process. The separate Cloud Run adapter experiment above has its own narrower evidence. The original receipt’s signature establishes integrity, not universal dependency coverage, model authorship or immutable external storage.

Sustainability evidence

A separate local replica experiment completed 1,000 independently verified deliveries across five paired comparisons. Retiring the unused legacy process reduced the measured Node services' mean resident memory by 48.13 MiB (31.15%). CPU differences were inconclusive. This is process-resource evidence, not measured net carbon savings or a complete SCI score; controller, CI and Duo overhead are outside that experiment. The method, raw results and limits are public.

Supplemental Secure stage

Before the deadline, GitLab's official SAST analyzer scanned submitted source revision c8d3c57c24b8d08acafb3eabcca2ab8b9e30522f. Pipeline2994423007 contains the successful scanner and an intentionally blocking report gate:150 raw entries included7 High,83 Medium and60 Info, with12 repeated-ID entries. Static first-pass review found counterevidence for the seven High claims, but no dismissal or waiver was applied and other findings remain unreviewed. The gate stays blocked. Evidence and limits distinguish this additional CI security checkpoint from the original retirement proof; the live run and signed receipt are unchanged. This supports nine-stage coverage, not nine autonomous AI stages or a security-clean claim.

Built With

Share this project:

Updates

Submission history