Frontend runbook
It moved here from the Google doc [Runbook] v2 frontend: web app on 2026-10-08 (D28), with its text, step IDs and runs unchanged. Later runs are logged as comments on each pack's issue.
Owner: @zuki · Status: Draft
Last reviewed: 2026-10-07 · Conforms to the register through D29
In one sentence: The steps the Frontend Engineer writes and zuki runs for apps/web and its integration with the v2 database, one tab per module.
How this runbook works
Section titled “How this runbook works”- The rules are in [Register] v2 decisions and working rules, under Human first and Runbook step format. This runbook follows them and never overrides them.
- The Frontend Engineer session writes the steps; zuki runs them and logs each run. A step is done when its Runs line shows a clean run by zuki.
- One tab per module, each with four sections: Applies (the decisions that govern the work), Needs from backend (what this module uses from the backend runbook's Interface section, and its status), Needs from docs (the rules in apps/docs its tests will cite, D27), and Steps.
- The database contract lives in the backend runbook. When a page needs a function, view, column or error key that isn't there, write the request under Interface in the matching tab of [Runbook] v2 backend: database and migration, and wait for its step pack. Never work around a missing piece with a direct table write or a hand-written type.
- Rules come first (D27). What a page does is written in apps/docs as rules with IDs before any test. From M1 on, an FE pack writes its Playwright journeys first, in
apps/web/e2e, each test title starting with the ID of the rule it proves, then the pages. In the same change it sets those rules' Status from planned to built, and edits nothing else in apps/docs. A rule that looks wrong goes back to the Docs Engineer, or to the register as a change request; it is never changed to fit the code. - How packs arrive. In M0 a pack ships as a zip from the FE chat and enters the repository only through steps zuki runs (D25). From the data phase on, packs arrive as pull requests in Opleettop/monorepo, opened through the Claude GitHub app, which zuki reviews and merges (D28).
- Steps for screens say what to look at: Expect names the page, the role to sign in as from the E2E organization, the language, and what should appear.
- Commands are pnpm first. When you edit a command in this doc, turn off Tools › Preferences › Use smart quotes first, or the copied command breaks.
- Stamp: after each session, update "Conforms to the register through Dn" in the header above.
Step template
Section titled “Step template”Copy this table for each new step.
| Field | Example |
|---|---|
| ID | FE-M1-01 |
| Goal | One line: what is true after this step |
| Before | What must already be true |
| Run | pnpm … |
| Expect | What you should see: page, role, language |
| Check | A command, test or screen that proves it worked |
| If it fails | What to look at; when to stop and ask |
| Undo | How to reverse it, or "Not reversible: ask zuki first" |
| Level | L0 |
| Runs | date · who · result · notes |
Related
Section titled “Related”- [Register] v2 decisions and working rules
- [Guide] Using the Opleet design system in v2
- [Spec] v2 monorepo architecture
- [Ref] Roles, permissions and row-level security
Modules
Section titled “Modules”- M0 Monorepo move
- M1 Access and master data, M2 Vehicles, M3 Drivers, queue and screening, M4 Onboarding, booking and contracts, M5 Operations, M6 Money and M7 Reports have no steps yet.