solve-issuelisted

# Solve Issue Implement a single issue. One issue in, committed code out. ## Outcome Every run ends as exactly one of these. Report it in whatever form your caller asked for — these are the words, not the wire format: - **`complete`** — every acceptance criterion is met, every check passes, and the work is committed. - **`partial`** — meaningful progress, but a check fails or a criterion is unmet. Commit the work with a `[WIP]` marker so the branch preserves it, and say what remains. A later round resumes here. - **`blocked`** — cannot proceed without human input or an environment fix. Not a way to avoid reporting `partial`. When you stop on a blocker, always output: ``` BLOCKED: <reason> <verbatim error or dependency name> ``` Do not attempt workarounds. Do not proceed. ## Inputs The caller provides one of: - A **file path** — read the issue from that path. - **Issue content** inline — use it directly. Tracker operations named below (`fetch`, `mark-done`) are defined in `$(git rev-parse --show-toplevel)/.coding-crew/docs/issue-tracker.md`. If that file is missing, invoke the `configure-tracker` skill once to create it. `PROJECT_ROOT` (where code lives and all commands run) and `MAIN_ROOT` (the main checkout, where `.scratch/` and gitignored files live) are **inherited from the caller** — use the values already established and do not re-derive them. ## Steps ### 0. Branch guard You must not be on the default branch. Check, and stop immediately if you are —