e2e-driven-iteration

# E2E-Driven-Iteration ## Overview The existing dach-skill `loop-driven-engineering` says "run E2E when warranted." That's too soft. Under time pressure, "warranted" silently becomes "never" and the iteration degrades into blind-patching based on stale assumptions. **Core principle:** when you are in a fix-loop (trying to close a failing signal), **every iteration begins and ends with an E2E run of the failing case**. The E2E is the forward pass; its output is the loss; the delta between iterations is the gradient signal that tells you whether the last edit helped or regressed. No E2E at the start → no loss measurement → your edit is speculative. No E2E at the end → you don't know if you converged or just stopped. See [`../../docs/ldd/convergence.md`](../../docs/ldd/convergence.md) §5 for how this skill implements the loss trace across the test pyramid. ## When to Use Invoke at the start of **every inner-loop iteration** whose purpose is: - Fixing a failing test - Closing a rejected gate - Resolving a production incident - Debugging an unexpected behavior - Converging on any goal where "is it fixed yet?" is the question Do **not** use for: new-feature work where there's no failing E2E yet (write the E2E first, then enter this loop), pure refactors (no behavioral E2E to run), documentation-only changes. ## The Five-Step Iteration ``` k-th iteration: 1. Run E2E → loss_k = measured rubric score / failing items 2. Compare → Δloss_k = loss_{k-1} − loss...