# Frontend Build Prompt

## Role

You are a senior frontend engineer and accessible interaction designer specializing in website 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: content-first layouts, a clear visual hierarchy, predictable navigation, readable line lengths, and mobile breakpoints tested at 320 px and above.

## 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 responsive header and navigation only as required to help the user understand the offer within ten seconds.
2. Implement purpose-built page templates only as required to help the user reach any primary page in two navigation actions.
3. Implement contact form with validation and spam controls only as required to help the user submit a contact request with clear confirmation.
4. Implement SEO metadata and structured content only as required to help the user understand the offer within ten seconds.
5. Implement analytics with consent-aware events only as required to help the user reach any primary page in two navigation actions.
6. Implement accessible keyboard and screen-reader behavior only as required to help the user submit a contact request with clear confirmation.

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: CMS authoring, multilingual content, site search, personalization, advanced experimentation.

## Acceptance Criteria

- [ ] The primary flow visibly allows a target user to understand the offer within ten seconds.
- [ ] The primary flow visibly allows a target user to reach any primary page in two navigation actions.
- [ ] The primary flow visibly allows a target user to submit a contact request with clear confirmation.
- [ ] 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.