implementation-checkpoint-planner

Map task dependencies, mark work with high uncertainty, irreversibility, or blast radius, then place a checkpoint after enough evidence exists but before dependent expansion. Define each gate's decision question, required evidence, reviewer role, and continue/revise/replan criteria.

Place checkpoints after foundational abstractions, API or schema contracts, irreversible changes like data migrations, cross-cutting concerns such as security or accessibility, and multi-team handoffs. Avoid gating routine low-risk reversible work.

Require the smallest observable evidence set that exposes the key failure mode: passing contract or integration tests, migration dry runs with rollback proof, working vertical slices, measured performance thresholds, or recorded stakeholder approval.

Skip checkpoints for routine, low-risk, reversible work with no downstream dependents, and remove gates whose review cost exceeds the plausible cost of failure. Do not add a gate solely because a phase ends.

A failed checkpoint triggers a bounded revise path for rework and re-review, or a replan path when evidence invalidates an assumption or architecture choice. Downstream tasks stay blocked and later checkpoints are re-evaluated rather than blindly resuming.