debug-issuelisted

# Debug issue A failure has a cause. A fix without one is a guess that moves the symptom and leaves the cause live, so you never learn which change actually fixed it. This loop separates the two: capture the failure first, test one hypothesis at a time against evidence, fix the cause, then prove it. Both the primary and its workers debug, so the loop is shared. It runs the same whether the primary diagnoses a problem directly or a worker is assigned a bug inside a project. ## When to use - Something fails and the cause is not obvious: a failing test, a broken command, a crash, a build error, a regression, or reported behavior no one has explained. - A worker is assigned a specific bug to fix in the target project. - An earlier fix moved the symptom instead of removing it. ## When not to use - The failure is trivial and already understood: make the fix directly, with no hypothesis to test. - No fix is authorized and the ask is to explain or diagnose: that is `investigate-issue`, which returns evidence and a conclusion without changing code. - The work is to build a specified change, not to chase a failure: that is `implement-task`. ## Inputs - The failure: the exact command, the input, and the observed output. - A way to run the failing behavior — the project's own test or check command where one exists. - The project's conventions and commands, from `load-project-context`. ## Procedure 1. **Reproduce and capture the failure.** Reproduce before changing