atomikd by amphare

reviewing a plan

Find the wrong decision while it is still a paragraph.

A plan can read perfectly and still be wrong. It can cite a function that does not exist, an import that moved, a dependency nobody built. Review is not a stamp on prose that sounds right. It is an adversarial read, and it happens twice: once on the plan before you build, once on the diff before you merge. The point is the same both times, and it is cheap: catch the wrong call while it is still a paragraph, not expensive code to unwind.

twice

The plan, then the diff

Review lands twice, on two different things. The plan asks whether the design is right, before a line is written. The diff asks whether the implementation is actually right, adversarially, before it merges. A plan approved cleanly can still be built wrong; a green test suite can still ship the wrong behavior. Two gates, one question: is this correct, or does it only look correct.

plan review 1the plan build review 2the diff merge

design gate, then implementation gate, one question at each

the posture

Try to break it, not bless it

The failure mode of review is agreement. A reviewer who reads to approve finds nothing; a reviewer who reads to refute finds the one path that does not hold. So the posture is adversarial: not "do the tests pass" but "find the ways this is wrong." Every path, symbol, and number in a plan is a claim to verify against the real code, not a fact to trust. If reality contradicts the plan, the plan is what changes; quietly coding around it is how the defect ships.

A plan that reads perfectly and cites a function that does not exist is not a good plan. It is a confident one.

depth

Match the scrutiny to the blast radius

Review is not one size. A low-risk plan is a self-check against the anti-patterns, a careful read by the author. A high-risk one earns a real reviewer, a round or two, and a fixed rubric so the bar is repeatable and not a mood. The rule is uncomfortable and correct: a high-risk plan approved with zero scrutiny is not fast. It is unreviewed.

low the rubric medium + the deep read high + cross-review
the floor is the rubric. risk adds the rest.

the stack

Three modes, picked by risk

01 · machine

The rubric

Five dimensions, scored: schema conformity, architecture, dependency correctness, and the rest. Fast, repeatable, mechanical.

the floor, every plan
02 · discipline

The deep read

A senior reviewer's checklist made explicit: anti-hallucination, substrate verification, the roads not taken. Loadable on any model.

medium and up
03 · panel

Cross-review

Several models from different families read the same plan and vote. Diversity catches what redundancy misses.

when being wrong is expensive

gates

Trust is earned, not declared

Two rules keep a control honest, and both are about saying in advance what will happen.

01 · earn it

Anything that will act

A gate, a limit, a mandatory step. It ships advisory first, gets measured against known-good and known-bad, and graduates to blocking only when the numbers clear a bar set in advance. You do not flip a gate on by fiat. That trial has a name and a shape: the soak.

evidence, then authority
02 · exit it

Anything that loops

A review that loops states when it stops: the agreement bar, and what happens if it is not met, which is to escalate to a human. A loop with no exit is a hang, not a process.

a stated stopping rule
AMPHAREgoverned autonomy
the kit · the method · shapes · explorer · review · soak
review the plan before you build · review the diff before you merge · adversarial, scaled to risk
the full review guide, standard, and discipline live in the kit docs beside this page