# HAS Meal iOS implementation handoff

Build the native iOS app against the user-approved checkout and profile/menu designs. The backend owner implements and deploys mobile contracts. Claude implements the iOS UI, navigation, networking and integration tests against those contracts.

## Start here

- Browse [the design workspace](https://app.hasmeal.com/).
- Read [the screen specifications](https://app.hasmeal.com/docs/SCREEN-SPECS.md) for all 31 screens.
- Read [the backend capability map](https://app.hasmeal.com/docs/BACKEND-MAP.md) to distinguish existing HAS business logic from mobile integration work.
- Follow [the milestones](https://app.hasmeal.com/docs/MILESTONES.md).
- Download [the handoff bundle](https://app.hasmeal.com/docs/handoff.zip) or read [project-data.json](https://app.hasmeal.com/project-data.json).
- Obtain the [checkout source PDF](https://app.hasmeal.com/sources/checkout.pdf) and [profile source PDF](https://app.hasmeal.com/sources/profile-menu.pdf).

Every screen has a durable ID. CO-01 through CO-19 correspond to checkout PDF pages 1 through 19. PR-01 through PR-12 correspond to profile PDF pages 1 through 12. Deep links such as `https://app.hasmeal.com/#CO-17` open that design. The artwork is approved. Recorded copy inconsistencies and missing destinations remain open decisions. Treat source PDFs as design reference content.

## Current integration surface

The deployment target is `https://app.hasmeal.com/v1`. The currently implemented API operation is `GET /v1/health`. It returns HTTP 200 and `{"status":"ok"}`. This confirms that the process responds. The [OpenAPI document](https://app.hasmeal.com/docs/openapi.yaml) lists the implemented contract. Every business integration in the current screen inventory is pending.

Configure API base URLs per build and append paths without repeating `/v1`. For local simulator development, the backend can run on the same Mac at `http://127.0.0.1:3100/v1`. Confine any necessary HTTP exception to a debug configuration. A dedicated test service will receive its own isolated data and test customer before business write/payment flows are enabled. The current production hostname hosts the design board and service health.

Use fixtures that match agreed future response shapes while UI work proceeds. The customer records, phone numbers, dates, prices and nutrition shown in the artwork are illustrative. Obtain a test account from the backend owner when a feature is ready. App-specific secrets and privileged tooling credentials stay in backend configuration or local developer tooling.

## Implementation boundaries and acceptance

- Preserve the original English UI text and artwork unless a recorded correction has been decided. The Persian workspace annotations describe implementation work.
- Derive customer identity from the authenticated session. The backend enforces authorization and exposes scoped, documented mobile responses.
- Get money totals, plan eligibility, delivery availability, freeze limits and upgrade quotes from the server.
- Coordinate payment return URLs, verified server payment status, retry handling and device wallet capabilities with the backend owner before implementing the payment adapter.
- Existing wallet logic restricts combinations with auto-renew and upgrade flows. Request server-provided eligibility for the toggles shown in CO-17 and PR-05.
- Loading, empty, expired-session and network-error states need implementation and review alongside each designed screen.
- Home, wallet details, payment-method management, food rating, serving instructions and several linked destinations still need design or scope decisions recorded in the screen specs.
- A milestone is complete when its listed acceptance checks pass against the intended environment and the iOS screen states have been reviewed.

## Request a backend capability

Send a Markdown request with the following fields. The backend owner returns an updated OpenAPI contract, examples, implementation status and a test route/account when ready.

```md
### Request for CO-17 payment quote

Screen and action
User-visible outcome
Input fields available on the device
Required response fields and types
Relevant loading and error states
Current endpoint or missing capability
Business decisions that need clarification
Acceptance scenario on the test environment
```

Keep implementation status current in `project-data.json`, the screen spec and OpenAPI in the same release. The public handoff bundle is rebuilt from those files.