running-planslisted

# Execute without drifting Execution rarely fails because one step was performed badly. It fails by drifting: the goal shifts mid-run, a verification is skipped because the output "looked right", or the same failing action is retried eleven times. Answer the user in whatever language they wrote in. ## The loop, per step 1. **Mark it running** in the plan file, and in the todo tool if one exists. 2. **Do the step** using its bound provider. 3. **Check the result against the step's own `verify` line.** Not against your expectation of it. A tool returning without error is not evidence that it did the right thing — read the artifact. 4. **Mark the outcome** and append one journal line: what came out, what you now know, what surprised you. Step 3 is the one that gets skipped under pressure, and it is the one that matters. Everything downstream inherits an unverified step's errors. ## When the provider fails or is missing Go to the step's `fallback`. It was written before the pressure of the moment, which is exactly why it is more trustworthy than an improvisation now. If the fallback is also unavailable, stop. Do not invent a third route: an unplanned substitution is a scope change the user never approved. **Two failures of the same action is the limit.** Then diagnose before touching it again: - Read the actual error, in full. - Classify it — configuration (missing credential, not logged in), input (a parameter too narrow or malformed), or external (rate limit, outage).