implementlisted

# Implement a verified change Deliver one coherent, reviewable outcome. Tests, context, and affected documentation belong to the change; an implementation request does not authorize unrelated work, external publication, merge, or deployment. ## 1. Read the work and verify readiness 1. Read the request, project instructions, current repository state, and existing work record. For a Linear issue, include comments, linked decisions, acceptance criteria, prerequisites, and delivery boundary. 2. Apply [intake and handoff](references/intake-and-handoff.md) to verify the work type, ownership, prerequisites, prototype version, and context changes. 3. Trace the affected behavior through callers, contracts, configuration, and tests. Separate unrelated local work and pre-existing failures. 4. Resolve discoverable facts locally. For consequential open choices or conflicts, record the decision needed and propose returning to interview; pause only the dependent work. A ready label alone is not evidence of readiness. **Done:** scope, prerequisites, authorization, and independent acceptance evidence are clear. Otherwise report the precise blocker and continue only independent, authorized work. In read-only or planning mode, retain a plan rather than edit. ## 2. Prepare the change and verification 1. Preserve the prepared branch/worktree and unrelated changes. Identify existing components and dependencies to reuse; avoid speculative restructuring. Record the task