This is the lifecycle your engineering team is adopting, running live. Claude writes the files (an intent, a spec, a plan, the code, a review, an incident report). A named person accepts each one at an amber gate. When something is wrong, the stage that owns it fixes it before anything moves forward, and the same mistake is not made twice. Drag to look around; click a station to zoom in.
Your browser could not start 3D graphics, so the simulation cannot render here.
The written version below covers the same loop.
Someone in claims operations describes a problem in their own words.
Five kinds of thing appear on the ring. Everything else is scenery.
An artifact Claude wrote: intent.md, spec.md, plan.md, the pull request, the incident. It is a real file saved in the repository, in your words.
A gate. The card stops until a named person accepts it: product owner, engineer, code owner, release manager, service owner. Claude cannot pass a gate by itself.
A hook: a small script that runs automatically while Claude works. Protected files, secrets, tests during a bug fix, and production releases are guarded this way.
A mistake caught in the act, such as editing generated code or committing a secret. It hits the shield and bounces, and it is fixed in that same stage before anything moves on. The second time, the correction goes into CLAUDE.md so it stops happening.
Every accepted artifact and every approval becomes a commit — teal for one Claude wrote, amber for one a human made by approving or authorising, the same colors as the arch and the shield above. The chain in the centre is the audit trail. Click or tap any dot to see what it was.
Each stage ends by saving one file. The next stage starts by reading it. Nothing moves on a chat message alone.
| Stage | Claude produces | A person decides | Command |
|---|---|---|---|
| 1Plan | intent.md — the problem, the desired outcome, constraints, open questions, in the originator's words | Product owner accepts by merging | |
| 2Design | spec.md — requirements and design under the organisation's security, compliance, brand and UX policies, with flagged concerns first | Product owner accepts; policy owners decide each flagged concern | |
| 3Build | plan.md then the code, with tests run after every step; the plan is kept honest | Engineer accepts the plan before any code; tech lead if high risk | |
| 4Test | Proof: build, tests, lint, screenshots, attached to the pull request; a fresh-eyes verifier re-checks | Automatic, tests cannot be weakened during a fix | |
| 5Deploy | An AI review of every pull request (bugs, security, compliance against the spec and plan), then the release | Code owner approves; release manager authorises production | |
| 6Maintain | A script watches production; on a real anomaly Claude diagnoses and writes a new intent.md | Service owner triages: fix now, schedule, dismiss |
Always available (not stage-scoped):
Nobody works alone at a stage, and Claude is a member of every team, not a replacement for one. The names below are the ones you see acting in the simulation. As someone acts, their marker on the platform lights up.
An idea becomes a committed intent in hours, in the originator's own words. The spec arrives written; your job is to read the flagged concerns first, settle them with their owners, and accept. No requirements workshop.
Accepting is a one-click merge with your name and the time on it. Nobody has to write minutes; the repository is the audit trail, and /sdlc:status answers "where is it?" without a meeting.
Security, compliance, brand and UX policies shape the spec as it is written and are enforced by hooks as code is built. Conflicts are flagged for you instead of discovered in a review weeks later.