Instruction file imported from edobry/minsky (.cursor/rules/error-investigation.mdc). Copyright stays with the author.

Error Investigation

• 2-strikes rule: after the 2nd identical tool error from the same tool, stop. Do not retry. Read the tool's actual error message, diagnose the root cause (permission? stale input? upstream state?), and file a bug task if the error is systemic. Resume only once you understand why it failed. Counting attempts, not classifying the situation — it's a mechanical rule.
• 2-strikes counts wrong OUTCOMES, not just errors (mt#3154). A call that succeeds — exit 0, HTTP 200, no exception — but leaves the target state unchanged is a strike; two on the same objective trips the same stop-and-reassess as two errors. Verify the outcome, not the invocation: re-read the state you meant to change (query the setting, re-read the health BODY, count the rows). On a trip, STOP improvising and load the surface's skill (user-preferences.mdc §Probe before SELF-IMPROVISING). Incident: three railway redeploy calls each reported success while re-deploying the same wrong image — zero strikes under the old error-only wording.
• Workarounds are not fixes. Switching to an alternative path/method without understanding the root cause may hide a systemic bug that breaks other users. If a workaround is needed to proceed, file the underlying bug task first.
• When any MCP tool call returns an error, stop and investigate before the next attempt. Even on the first occurrence, don't retry blindly — retry only with a hypothesis about what the error means.
• Never mark a task complete with known errors outstanding (lint, type, test, build) — see dont-ignore-errors (not always-loaded; rules_get) for the batch-verification and completion-gate detail.