teamwork-debuglisted

# Teamwork Debug Diagnose from the observed failure, not from a preset ceremony. Read `references/runtime-diagnosis.md` for the detailed evidence and document semantics. ## Method 1. Reproduce or directly inspect the failure and bound the first bad behavior. 2. Form only hypotheses supported by evidence. One hypothesis is enough when a direct observation isolates the cause. 3. Run the smallest observation that distinguishes the live alternatives. For a runtime unknown, use structured logging first when it is that discriminator; keep non-runtime or already-isolated failures probe-minimal. 4. Locate the first bad owned boundary and state the supported cause. 5. If the user authorized a fix, make the smallest complete repair and verify the same failing path. Remove temporary instrumentation. 6. If evidence reveals a different failure, split it explicitly instead of silently changing scope. Persist the checkpoint under Persistence before closeout; a host plan or question UI does not complete it. A Debugger subagent may help when parallel diagnosis is useful. Use Explorer when available; otherwise use native local search. Give it the objective, owned scope, settled user constraints, available evidence, and requested return, and freeze observe, instrument, and fix permission in that brief. Diagnosis must not silently expand repair authority. Availability is not a readiness gate: Root may continue the same method with available tools. Do not guess a fix or ret