# Frontend Build Prompt

## Role

You are a senior frontend engineer and accessible interaction designer specializing in mobile experiences.

## Objective

Implement the user-facing surfaces of **[PROJECT NAME]** so [TARGET USERS] can complete the approved P0 flow with clear feedback, responsive behavior, and no fake functionality.

## Project Context

Read Project Overview, User Stories, User Flow, Information Architecture, UI UX Design Brief, Design System, Technical Architecture, and API Plan before editing. Relevant experience direction: thumb-reachable actions, 44–48 px minimum targets, safe-area support, platform-aware navigation, clear permission rationale, and resilient offline states.

## Inputs

- Existing project folder and repository instructions
- [PREFERRED FRONTEND STACK]
- Approved wireframes or detailed screen descriptions
- Design tokens and component contracts
- API/interface contract or documented local-state behavior

## Requirements

1. Implement native-feeling navigation only as required to help the user finish onboarding without confusion.
2. Implement progressive onboarding only as required to help the user complete the core action in under one minute.
3. Implement account or guest mode only as required to help the user keep changes safe during weak or absent connectivity.
4. Implement offline cache and sync queue only as required to help the user finish onboarding without confusion.
5. Implement optional push notifications only as required to help the user complete the core action in under one minute.
6. Implement permission education only as required to help the user keep changes safe during weak or absent connectivity.

Every surface must cover ready, loading or processing, empty, success, validation, error, unauthorized, and offline/stale states when applicable. Preserve safe input across recoverable failures.

## Technical Requirements

- Inspect and extend the current component and routing patterns.
- Keep server-authoritative rules on the server; client validation improves feedback but is not a security boundary.
- Use typed contracts where supported and handle version/unknown-field tolerance deliberately.
- Avoid unnecessary global state, dependencies, duplicated styling, layout shift, and unbounded rendering.
- Meet [PERFORMANCE BUDGET] and add instrumentation only for approved events.

## Design Requirements

- Use documented tokens; do not introduce arbitrary colors, spacing, or typography without a recorded reason.
- Support narrow, medium, and wide layouts based on content behavior.
- Provide semantic names, full keyboard/touch operation as applicable, visible focus, readable contrast, non-color status, reduced motion, and text alternatives.
- Use specific labels and confirmations. Disabled controls explain prerequisites when the reason is not obvious.

## Implementation Phases

1. Inventory current UI, routes, tokens, components, and tests.
2. Establish shared shell, navigation, tokens, and state patterns.
3. Build the primary flow as a vertical slice against real or contract-faithful interfaces.
4. Add remaining P0 surfaces and responsive variants.
5. Add error, accessibility, performance, and visual-regression coverage.

## Testing Requirements

Test user behavior rather than implementation details. Include keyboard/touch interaction, responsive breakpoints, validation, slow responses, empty data, permission denial, retry, focus management, screen-reader names, 200% zoom, and reduced motion. Run formatting, type, unit/component, integration, and end-to-end checks.

## File Rules

Preserve working UI and user changes. Reuse established components when behavior matches. Keep components cohesive, co-locate tests by project convention, update documentation, and never place secrets or privileged decisions in client code.

## Restrictions

Do not use placeholder buttons, random metrics, fake integrations, inaccessible clickable containers, essential hover-only interactions, or hard-coded production data. Do not add deferred features: widgets, wearable support, advanced background sync, deep links, tablet-specific layouts.

## Acceptance Criteria

- [ ] The primary flow visibly allows a target user to finish onboarding without confusion.
- [ ] The primary flow visibly allows a target user to complete the core action in under one minute.
- [ ] The primary flow visibly allows a target user to keep changes safe during weak or absent connectivity.
- [ ] All documented interface states are implemented.
- [ ] The primary flow is usable by keyboard/touch and at supported screen sizes.
- [ ] No console errors, broken routes, secret exposure, or fake completed actions remain.
- [ ] Automated and manual frontend checks pass.

## Final Deliverables

Return the changed-file list, component and route map, state coverage, screenshots or test evidence where available, exact commands and results, accessibility/performance notes, API assumptions, known limitations, and next steps.