| name | frontend |
| description | Defines frontend implementation order, contract use, resident development checking, live integration, and the frontend gate. Read before frontend work, then read every sibling topic. |
Frontend
The frontend delivers requirement-backed user journeys through the settled generated SDK. Begin only after the backend gate passes.
Topics
- sdk.md: generated accessors, the shared connection, simulation, sessions, and live integration.
- architecture.md: folders, routes, hooks, state ownership, components, and errors.
- screens.md: screen planning, forms, lists, values, states, and responsive behavior.
- design.md: visual discipline and accessibility.
- verification.md: browser journeys, viewports, simulation, live execution, and the verification record.
- debugging.md: assigning a failure to the runtime and the layer that owns it.
Implementation Order
- Read every requirement and all authored and generated API source under
packages/api/src/.
- Map requirements and SDK operations to screens in
packages/frontend/wiki/screen-plan.md, taking the operation list from the @accessor tag every generated accessor carries and the requirement list from the enumeration in screens.md. pnpm plan decides whether the plan accounts for every section.
- Declare every page and journey surface before implementation.
- Build the shared shell, primitives, providers, route table, connection, domain hooks, and view models.
- Implement screens and their loading, empty, error, refusal, retry, and post-mutation states.
- Write one exported Playwright journey function for every requirement-backed user flow.
- Run
pnpm test:contract under simulation while building, and close on pnpm test:e2e against the live backend, which its mode builds. The live run is the gate; verification.md owns why they are two suites.
Do not turn every endpoint into a page. Do not omit a user capability because it is difficult.
Consumption and presentation are separate obligations. architecture.md owns consumption: every published operation is consumed, whatever the interface looks like. A screen decides whether that capability earns its own page — an operation may lack a visible screen only when it is infrastructure, redundant with a complete user path, or non-user-facing, with the exact reason and invalidating condition recorded in packages/frontend/wiki/omissions.md. That record answers for the missing page, never for a missing call.
If a requirement needs behavior the SDK cannot express, repair the API or backend, regenerate, and re-pass the backend gate.
Continuous Development
From packages/frontend, start:
pnpm dev
Keep it running through Overall Final. Vite and @ttsc/unplugin use the package tsconfig.json and lint.config.ts, report type, lint, and contributor diagnostics, and reload after input changes.
Use simulation while building contract-shaped screens and deterministic fixtures for named UI states. Before live integration, ensure backend pnpm dev is running from packages/backend.
Stack
Use the existing Vite, React, React Router, TanStack Query, Tailwind, generated Nestia SDK, and Playwright stack. Do not add a frontend server, backend-for-frontend, handwritten transport layer, or second API contract.
Add a dependency only after a concrete need appears.
Frontend Gate
The frontend gate requires:
- the active arm's frontend review;
- a clean current
pnpm dev reload;
- every requirement-backed journey represented by a browser spec, and every screen walked by one of them;
- every published SDK operation called by a domain hook, and every hook used by a screen;
- every product-facing operation reachable from a screen, or a recorded omission for its missing page;
pnpm plan green, so every requirement section is delivered by a screen entry or decided by an omission;- every production component consumed by a screen or necessary shared boundary;
- responsive and accessible behavior at required viewports;
- every screen driven in the interactive browser, with
packages/frontend/wiki/interactive-review.md recording what was observed;
- every requirement journey green under
pnpm test:e2e against the live backend, each asserting the concrete effect its requirement names; and
packages/frontend/wiki/verification.md recording what actually ran.
A green build proves that the application bundles. It does not prove that users can complete the product.
