A playbook shows where RedMirror Reflection fits for your job, with a real, kernel-proven example. In the AI-native SDLC, agents write most of the code and run the first reviews, so the bottleneck moves to the approval gate. Reflection is the verification layer there: it proves whether code can reach a state it should not. Pick the playbook for your role below.
The AI-native SDLC runs in six stages, and agents move through them fast. Verification is not a seventh stage bolted on at the end; it threads through the pipeline and earns its keep at test and deploy, where a change is about to become real. That is where a proof beats an opinion.
| Stage | What agents do | Where Reflection fits |
|---|---|---|
| Plan / Design | Turn ideas into accepted plans and specs. | Name what must hold: who may act, what must be conserved, what order is legal. Those become the invariants. |
| Build | Implement against the plan. | The coding agent proposes suspected bugs as it writes; Reflection stands ready to confirm or dismiss each. |
| Test | Continuous evaluation. | The kernel proves whether a logic or state bug is reachable, with a reproduction. Zero tokens for the structural half. |
| Deploy | Layered review, then a gate. | Gate the pull request on proven bugs, not ranked opinions. |
| Maintain | Autonomous monitoring. | Re-verify on every change; a later diff that breaks an invariant is caught. |
The full argument, stage by stage, is in Where verification fits in the AI-native SDLC.
Turn a suspected access-control bug into a reproduction the triager cannot argue with.
Real example: broken object-level authz · CWE-639Prove a service can't reach a bad state before the pull request lands, and fail CI when it can.
Real example: value not conserved · CWE-682Confirm or refute a suspected privilege escalation with a concrete attack path, not an opinion.
Real example: missing authorization · CWE-863Put a verification step between "it runs" and "it ships", so AI-written code can't quietly leak money.
Real example: coupons stack / total below zeroEach one carries a real run, not a staged screenshot. An ordinary model, driven through a coding agent, proposes what to check; a compiled kernel then searches every reachable state and a finding survives only when the kernel refutes an invariant with a concrete attack path. The runs happen in a disposable Docker container, and the harness is published so a skeptic can reproduce them. The kernel runs on your machine and uses no tokens, so the structural half of the check is free.
A RedMirror playbook is a short, role-specific guide to putting verification in your workflow: where RedMirror Reflection fits for your job, and a real, reproducible example where a compiled kernel proves a bug with a reachable attack path. There is one for bug bounty hunters, software engineers, security analysts, and vibecoders.
At the test and deploy gates. Agents write most of the code and run the first review passes, so the bottleneck moves to the approval gate. RedMirror Reflection is the verification layer there: it proves whether the code can reach a state it should not, so a human reviews proofs instead of ranked opinions.
Yes. Each playbook's example comes from a real run in a disposable Docker container, driving RedMirror Reflection with an ordinary model through OpenRouter. A finding is only shown when the kernel refuted an invariant with a reachable attack path, not because a model guessed. The harness is published so the runs can be reproduced.
Read the one that matches your job: bug bounty hunters want the proof-carrying report, software engineers want the pre-merge gate, security analysts want the reproduction that proves exploitability, and vibecoders want the check that runs before their AI-written code ships.
Whatever your role, the shape is the same: your model, your machine, proofs not guesses. Install the binary, point it at your code and your own model, and your coding agent finds real bugs and proves each one. First month free, then $4.99/month, cancel any time.