# AGENT.md — website
> Sub-agent / multi-agent guidance for AI coding tools.
> Describes how roles divide work, not what currently exists.
## Mode: devist (structured)
This sub-project lives inside the main devist repo (`website/`). Treat it
as a focused frontend feature area, not a standalone product.
## Roles
| **designer** | Page IA, layout, visual hierarchy, empty/loading/error states, color spec | `_workspace/design/website-*.md` |
| **frontend-builder** | Everything in `website/src/` — pages, components, hooks, queries, realtime, types | `*.tsx`, `*.ts` under `website/src/` |
| **backend-builder** | DB schema + RLS + publication that the dashboard reads; worker push code that produces the data | `migrations/*.sql`, `src/worker/*.rs` |
| **qa-validator** | End-to-end smoke for each feature: typecheck, build, dev server, realtime + ack flows | (records observations in `_workspace/`) |
## When to spawn each
- **New page or major nav reorg** → designer first, then frontend-builder.
- **New column shown in the UI** → backend-builder writes the migration + worker push update; frontend-builder adds rendering. qa-validator runs the chain end-to-end.
- **New control / modal / hook with no schema impact** → frontend-builder alone.
- **CSS / copy / event handler tweak** → frontend-builder, no others needed.
## Coordination rules
1. **Schema before UI.** Migration + worker change land first and apply to
local Supabase before the frontend consumes them. Otherwise the
dashboard breaks at runtime, not compile time.
2. **`types.ts` is the contract.** Update it the moment a column changes.
Don't let SQL and TS drift.
3. **Realtime filters are server-side.** Use the existing helper hook;
don't filter in `onInsert` if the channel filter can do it.
4. **Hand-offs through code.** Migrations, types, query function
signatures — these are the contracts. Chat history isn't.
## Persistence
- **Plans** in `_workspace/{project,roadmap,sprint}.md` (4-tier).
- **Decisions** in commit messages (with reasoning).
- **Long-lived guidance** in `CLAUDE.md` and this file.
## What sub-agents should NOT do
- ❌ Add tests just because qa is in the loop. Manual smoke is policy
until it isn't.
- ❌ Skip the migration step when adding a field — typing the field in
TS without the SQL behind it is a silent failure.
- ❌ Mutate columns other than `acked_at` from the browser. The
column-level GRANT will reject it.
- ❌ Treat `website/` as a separate repo. It ships with devist.
- ❌ Refactor unrelated code while shipping a feature.
## When to escalate
Escalate to a multi-agent run (designer + frontend + backend in parallel) when:
- The change spans data model + push + UI in one commit.
- The change introduces a new top-level page or auth surface.
- A migration's RLS policy needs review.
For everything else, frontend-builder alone is enough.