Methodology

The pipeline is the product. Ten phases, agents doing the work at each one, and two points where the pipeline stops and will not be talked into continuing.

Why a rules layer instead of a better prompt

Every constraint you give an agent in a prompt is advisory. It competes for attention with everything else in the context, it degrades as the context fills, and it is subject to the agent's own judgement about whether this particular case is the exception. That is usually fine. It is not fine for the two rules where being wrong is expensive: shipping a known Critical vulnerability, and shipping something no human ever looked at.

So those two rules are not in a prompt. They are implemented in the layer that owns transitions between pipeline stages — the code that decides whether a piece of work is allowed to move from one phase to the next. An agent requesting a transition it is not entitled to gets a rejection, the same as any other caller. There is nothing to persuade, because the agent is not the one being asked.

The practical test of that claim is what happens when you attack it. Both gates are tested against the bypasses that would matter: an agent asking directly, a call made straight to the API, a webhook replayed, a project configuration file edited to weaken the rule, and — the subtle one — evidence that was valid for an earlier version of the code being reused for a later one.

The ten phases

Numbered as CIAN numbers them. Automated testing is numbered late but runs as part of building, which is why it appears where it does below rather than in numeric order.

1. Phases 1–4 · Intake, batching and prioritisation Work is taken from your tracker and ordered. Changes that depend on each other are batched so they are not built in parallel and merged into conflict.
2. Phase 5 · Feature development An agent implements the change in an isolated workspace for that piece of work.
3. Phase 9 · Automated testing Tests run as part of building, under a structured contract — results are recorded as data the pipeline can act on, not prose an agent summarises.
4. Phase 6 · Security — hard gate Static analysis, dependency audit and configuration review. An unresolved Critical or High finding stops the work here. This is the first of the two gates: it refuses the transition into code review.
5. Phase 5b · Code review The change is reviewed against the codebase it is joining, not just against itself.
6. Phase 7 · QA deployment The change is deployed somewhere it can be exercised as a running system.
7. Phase 8 · Human acceptance — hard gate A person reviews the deployed change and approves or rejects it. This is the second gate: without a complete, current approval record, the work does not reach done.
8. Phase 10 · Documentation Documentation is generated and published for the change that actually shipped.

Gate one: Critical/High security findings block the pipeline

No work enters code review carrying an unresolved Critical or High finding. Not with an override flag, not on an agent's assessment that the finding is a false positive, not by editing the project's configuration, and not at 2am under deadline pressure.

Two details do most of the work here. The first is that the gate trusts nothing supplied by whoever is asking to move the work forward — it reads only results already durably recorded for that exact piece of work. The second is that a recorded result is bound to the exact revision it was produced against. A scan that came back clean on one revision proves nothing about a revision that changed afterwards, and the gate treats a stale clean result exactly as it treats no result at all.

The gate does not run the scanner and does not decide what counts as Critical. It enforces one thing absolutely: no current clean result, no passage.

Gate two: human acceptance is a mandatory pause

Nothing reaches done without a recorded human approval. No agent bypass, and no timeout that approves on your behalf.

An approval record is only valid if it captures all four of: who approved it, when, an attestation of the device they approved from, and the exact revision they reviewed. A partial record is rejected outright rather than stored as a weaker approval. Because the record names a revision, approving build N does not satisfy the gate for build N+1 — a change made after your review has not been reviewed, and the gate says so.

Waiting has a bound, but running out of time is not consent. A request that goes unanswered moves to a held state so it can be found and escalated. Held blocks the pipeline in exactly the same way as pending; there is no path through this gate that the passage of time can open.

What this does not claim