| name | debug-fast-fail |
| description | Use only when the exam project fails to start, fails a key test, or returns the wrong contract. Prioritize the fastest evidence path to restore the main loop. Not for large refactors or speculative cleanup. |
| origin | ECC-derived |
Debug Fast Fail
Source Lineage
Primary inherited sources:
legacy/ecc-source/agents/build-error-resolver.md
legacy/ecc-source/commands/build-fix.md
legacy/ecc-source/skills/verification-loop/SKILL.md
legacy/ecc-source/skills/continuous-agent-loop/SKILL.md
Inherited methods:
- detect the real stack before choosing commands
- reproduce once, then group errors by file and dependency order
- fix one blocker at a time with minimal diffs
- rerun the smallest relevant check after each change
- recover the main loop before doing cleanup
When To Use
Use this when the main path breaks and time pressure matters.
Expected Outputs
- a short failure summary
- the smallest next diagnostic step
- the smallest fix that restores the main loop
- a note on whether more cleanup was intentionally skipped
Debug Order
- reproduce the failure once
- identify whether it is startup, dependency, contract, build, or test related
- inspect the narrowest relevant file or log
- fix only what blocks the main loop
- rerun the smallest meaningful check
Guardrails
Stop and escalate the diagnosis if:
- the same error survives three careful attempts
- the proposed fix is really an architectural rewrite
- the change set is growing faster than confidence
- the failure comes from missing dependencies or environment the exam does not expect you to provision
Failure Categories
- startup failure
- missing dependency or configuration
- invalid request or response shape
- adapter or upstream failure
- broken test expectation
What Not To Do
- do not rewrite working code while debugging
- do not broaden the change set without evidence
- do not pause on cleanup that does not affect delivery
- do not run the full verification suite when one focused command can confirm the fix