Dev debugging

!bun ${CLAUDE_SKILL_DIR}/../../scripts/load-constraints.ts dev-debug

Use debugging to investigate a named failure, not to re-authorize implementation. When invoked during /dev, resolve the receipt-selected {planFile, planHash} and create/reconcile TaskList investigation and repair items. Do not create HYPOTHESES.md, LEARNINGS.md, HANDOFF.md, STATE.md, a fixed plan, or any visible planning ledger.

Fresh investigation loop

Capture the symptom, reproduction command, current plan identity, and scope in one TaskList investigation item.
Dispatch one fresh investigator at a time. The investigator reproduces the failure, tests one hypothesis, and returns evidence, changed files, a specific regression-test result, and the next hypothesis. Keep investigation conclusions in the TaskList item and returned result.
A confirmed fix requires a new failing regression test (RED), minimal repair, GREEN, and a fresh full relevant suite. The doer never self-verifies.
Convert an actionable confirmed repair into a current-plan TaskList work item and route it through dev-implement; then independently verify it. If the diagnosis changes requirements or approved architecture, stop and return to native clarification/planning for a new receipt.
Stop and escalate on repeated non-progress, missing reproduction, or a blocker requiring user input.

Return contract

Dev debug result
- Plan: {planFile, planHash}
- Investigation: TaskList ID
- Reproduction and hypotheses: [{hypothesis, result, evidence}]
- Repair: TaskList ID | none
- Regression evidence: {red, green, suite}
- Status: FIXED | BLOCKED | ESCALATE

A returned FIXED is only an implementation report until the independent verifier records PASS.