fix

# Fix Use the same durable, reviewable workflow as feature work. Diagnose first, then produce the spec amendment, fix plan, and task files before changing production code. The user can review those artifacts, switch the main session to a cheaper model, and explicitly authorize native subagents for parallel-safe tasks. ## Core Flow ```text Evidence -> Root cause -> Spec amendment -> Fix plan + tasks -> User approval/model switch -> TDD implementation -> PR AI review ``` Do not patch production code before the planning checkpoint unless the user explicitly opts out of the workflow. ## Phase 0: Evidence And Root Cause When a bug originates from an issue tracker, read the canonical issue and every image attachment before hypothesizing. Reproduce with existing tests, a read-only trace, or a minimal throwaway repro. Do not add production code during this phase. State the root cause before planning: - what is actually wrong, not only the symptom; - why it happens and under which conditions; - the smallest reliable reproduction; and - the intended regression-test level and path. If the problem cannot be reproduced or the cause remains unclear, stop and ask the user rather than guessing at a fix. ## Phase 1: Fix Specification Before implementation, find the affected durable spec under `docs/specs/<slug>/spec.md` and amend its behavior or GIVEN/WHEN/THEN scenario to cover the regression. If no relevant spec exists, create a concise repair spec at `docs/specs/<fix-slug>/spec....