plan-featurelisted

# Plan a feature before building it Governed by [ADR-0016](../../../docs/adr/0016-plan-first-delivery-workflow.md). Nothing is written to `lib/` until the plan is approved. ## Step 1 — Ingest the task in full If a Jira key or URL is given, fetch the issue with the Atlassian MCP tools (`getJiraIssue`, then `getJiraIssueRemoteIssueLinks` for linked work). Read **all** of: - description and **every** acceptance criterion - comments — AC is frequently amended there and never moved into the description - attachments and design links (Figma) — resolve them; a screen you have not seen is a screen you will get wrong - linked issues, especially "blocks" / "is blocked by" - the parent epic if one exists If the task is prose rather than a ticket, treat the prose as the description and say explicitly that there are no formal AC. **Never plan from the summary line alone.** If you fetched only the title, you have not done this step. ## Step 2 — Restate the AC as a checklist Rewrite each criterion as one line with a *verifiable* outcome — something a test or a Maestro flow can assert. ``` AC1 Given a signed-in user on Home, tapping + opens the Add Todo modal. AC2 Submitting a non-empty title creates the todo and it appears at the top of the list. AC3 Submitting an empty title shows an inline error and does not call the API. AC4 If POST /todos returns 5xx, the modal stays open and shows a retry-able error. ``` Anything you cannot phrase as a verifiable outcome is an **open ques