Ship One New Feature in an Existing Mobile App

You are a senior mobile developer adding ONE well-scoped feature to an existing app without destabilising what already works.

<context>
[THE APP — platform and stack — e.g. "Flutter 3 on iOS and Android", "native Android/Kotlin", "React Native + Expo"]
[THE FEATURE — as the user experiences it — e.g. "customers can attach photos to a service request"]
[EXISTING CODE THAT TOUCHES THIS — paste the relevant screens, services and models, or describe the architecture honestly]
[BACKEND REALITY — e.g. "Firebase", "our REST API — can add endpoints", "no backend, local only"]
[CONSTRAINTS — e.g. "must work offline", "app store release next month", "solo developer"]
</context>

Before planning, define the feature's seams: where it plugs into existing navigation, state and data — and what it must NOT touch. List the 2-3 integration points and name the riskiest.

<task>
1. Write the feature spec in 6-10 lines: the user flow, the states (including permission denied, offline, failure), and explicit non-goals for v1.
2. Plan the work as ordered slices that each leave the app shippable — e.g. UI behind a flag, then local logic, then backend wiring, then polish — with honest hour estimates.
3. Implement the core slices for my stack: new files complete, changes to existing code as clearly marked minimal diffs against what I pasted. Handle the unhappy paths from the spec.
4. Include the platform requirements for THIS feature type — e.g. photo-access permission strings and manifest entries on both platforms — with exact entries; where store policy is involved, mark [VERIFY: current App Store / Play policy] rather than asserting it.
5. Define the release test pass: the manual script per platform (5 steps, which devices), plus unit tests for the logic slice in my stack's framework.
6. State the rollback: how to disable or hide the feature quickly if it misbehaves in production — flag, config or safe revert.
</task>

<output_format>
Spec — sliced plan with hours — code (new files, then diffs) — platform entries — test pass — rollback.
</output_format>

Rules:
- Touch only what the feature needs; justify every change to existing code in one line.
- No invented APIs: backend endpoints beyond what I described are written as a contract for me to build, marked clearly.
- If the feature as described is too big for one release under my constraints, cut scope in the spec and say what moved to v2 — never deliver half of everything.

Copy the block above straight into Claude — anything in [BRACKETS] is yours to fill in.