loop-driven-engineering

# Loop-Driven-Engineering ## Overview Engineering is **three loops**, not one. You plan, you try, you measure, you diagnose, you try again — on the **code axis** (inner loop), the **deliverable axis** (refinement), and the **method axis** (outer loop). The thing that separates good engineering from flailing is choosing the right loop for the current loss, respecting each loop's budget, and not smuggling one loop's edits into another's. **Core principle:** the loop closes when applicable gates are green **and** the doc-level mental model is current. Not when one test passes. Not when "it looks right." Not when the LLM sounds confident. This skill is a **flexible pattern**, not a rigid procedure. Use judgment; adapt the structure to the task. But the budget, the escalation rule, and the loop-separation rule are hard. See [`../../docs/ldd/convergence.md`](../../docs/ldd/convergence.md) for the three-loop model in full, and [`../../diagrams/three-loops.svg`](../../diagrams/three-loops.svg) for the picture. ## When to Use Invoke at the **start** of any non-trivial engineering task: - Feature touching ≥2 files or ≥1 public surface - Bugfix where the cause is not yet identified - Refactor with observable behavior change (even if spec-preserving) - Incident response - Plan-driven work (a multi-step design under time pressure) - Any work where you are tempted to "just start coding" Do **not** use for: - Trivial edits (rename a variable, fix a typo, delete dead code) - Pure lo...