implement-issue

# Implement issue Implement exactly one approved GitHub Issue. The issue defines the scope. Project instructions, approved specs, and explicit user decisions define the requirements around it. ## Process ### 1. Read the work Read the complete issue: - title; - body; - acceptance criteria; - comments; - linked specs; - linked issues; - blockers. Identify the behavior the issue must deliver. If the issue depends on unresolved product decisions, stop implementation and surface them. ### 2. Inspect the repository Before editing: - read applicable project instructions; - inspect surrounding implementation; - inspect related tests; - identify existing patterns and abstractions; - identify configured validation commands; - inspect relevant schema, API, state, or UI boundaries. Use the existing architecture unless the issue requires changing it. ### 3. Define the minimum change Determine: - which behavior must change; - which parts of the system are affected; - which existing patterns should be reused; - what explicitly remains outside scope. Prefer the smallest correct change. Do not bundle cleanup or refactors that are not required. ### 4. Implement incrementally Make focused edits. When behavior changes: - add or update appropriate tests; - preserve existing behavior outside the issue; - reuse existing dependencies and patterns when suitable; - avoid speculative abstractions or future-facing architecture. If a bug appears during implementation, use `debug-with-evidence`. ### 5. Verify acceptance criteria Before considering implementation complete: - check every acceptance criterion individually; - verify the user-visible behavior; - confirm no requirement was silently skipped; - confirm no unrequested behavior was added. Then use `verify-change`. ### 6. Review the final diff Inspect the complete diff. Look for: - unrelated edits; - accidental files; - debug code; - stale comments; - missing tests; - unnecessary dependencies; - requirement mismatches; - scope creep. ### 7. Prepare delivery Use `github-flow` for commit and PR conventions. Report: - what changed; - what was verified; - any relevant limitations or decisions; - anything intentionally left out of scope. Do not merge unless the user explicitly asks for the merge. ## Rules - The issue is a scope boundary, not permission to redesign adjacent systems. - Do not invent missing requirements. - Read before editing. - Prefer current project patterns over introducing new ones. - Prefer simple, direct code. - Do not hide failures with broad exception handling or arbitrary defaults. - Do not claim checks passed unless they were actually run. - Do not silently modify unrelated behavior. ## Completion The issue is implementation-complete when: - all acceptance criteria are satisfied; - the implementation matches the approved requirements; - relevant tests exist; - validation succeeds or failures are reported accurately; - the final diff contains only intentional changes; - the change is ready for review.