diagnose-and-fixlisted

# Diagnose and Fix Confirm the mechanism, recommend one route, and perform only approved actions. The parent orchestrates; a fresh Fix Implementer edits under the passed contract. ## Always - A bug report or “fix this” starts diagnosis only. Safe read-only repository inspection is allowed before approval; production edits and side effects are not. - Confirm root cause only when evidence proves the mechanism. Otherwise return `blocked` or `not reproduced` with the exact artifact, access, command, or risk acceptance needed; do not substitute “likely.” - Keep root checkout files/index user-owned: never switch it, edit it, merge there, or use it for delivery. Orchestration may run from `$PROJECT_ROOT` to manage approved non-root worktrees/refs through `worktree`. - Keep repairs minimal. Classify a repair by cost, not by category. A repair is `localized` only when both (i) the mechanism is confirmed by evidence, ideally a deterministic failing test, and (ii) the change is bounded and cheaply reversible. Check (i) and (ii) separately and require both; neither one alone is enough. When both hold, fix and review it here whatever subsystem or category it touches. - A repair is `broad/risky`, and therefore goes through `implementation-plan`, only when one of these holds: the mechanism is unconfirmed and the fix requires choosing between viable designs; the change is hard to reverse, such as a schema or data migration or a published contract or API; or the blast radiu