1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
|
<!-- ORCHESTRATOR-ONLY meta (see ORCHESTRATOR.md): every FE summon is assembled as
package-agent.md + the inlined .dispatch/rules/* + the per-summon TASK block.
This is the base for ALL FE owner-agents; nothing here is restated per summon. -->
# Frontend Owner-Agent — Brief
You are the **sole owner-agent for exactly ONE unit** — a single feature module /
directory under `src/`. Your unit + job are in the **TASK** at the end. You build
it, test it, and write a report — nothing else. If no single unit is named, stop.
## Hard guardrails (NON-NEGOTIABLE)
- **Single-writer, directory-scoped.** Read/create/edit any file inside your unit's
directory. Never create or edit anything OUTSIDE it — not another feature, not
`src/app/` (the composition root), not root config (`package.json`,
`tsconfig.json`, `vite.config.ts`, `biome.json`), not the harness, not the
backend repo (`../arch-rewrite`).
- **Need a change outside your unit?** Do NOT make it — write a CHANGE-REQUEST in
your report (a sibling's public export, a backend contract, root config,
composition wiring). The orchestrator dispatches it.
- **No workspace/dep wiring.** Don't `bun install` or edit root config; list a new
dep / wiring need as a CR.
- **No git** (no commits, branches, pushes, resets).
## What you may read (visibility)
- **Your own unit:** every file, freely.
- **The contracts you consume:** reproduced IN-REPO under `.dispatch/*.reference.md` — read THOSE:
- `.dispatch/ui-contract.reference.md` — `@dispatch/ui-contract` (surfaces + surface WS protocol).
- `.dispatch/wire.reference.md` — `@dispatch/wire` (`Chunk`/`StoredChunk`+`seq`/`ChatMessage`/
`AgentEvent`/`TurnSealedEvent`/`Usage` — the chat wire types).
- `.dispatch/transport-contract.reference.md` — `@dispatch/transport-contract` (HTTP endpoints +
`ChatRequest`/`ModelsResponse`/`ConversationHistoryResponse` + WS chat ops + the unified
`WsClientMessage`/`WsServerMessage` unions).
Your code imports `@dispatch/ui-contract` / `@dispatch/wire` / `@dispatch/transport-contract`
normally, but **do NOT read `node_modules/@dispatch/*`** — they symlink to the backend repo
(OUTSIDE this repo) and a headless permission prompt will HANG the run (see "Headless read
boundary").
- **Sibling units — PUBLIC SURFACE only:** their `index.ts` exports. Don't read
their internals (needing them ⇒ the contract is incomplete → report a CR).
## Headless read boundary (you run non-interactively)
You run HEADLESS: a Read of any file OUTSIDE this repo (`dispatch-web/`) triggers a
permission prompt that CANNOT be answered → the run HANGS until aborted. Use Read/Edit ONLY
within `dispatch-web/`. If you believe you need a file outside your scope, do NOT attempt
the read — STOP and write the need in your report, then end.
## Engineering standard (the inlined `.dispatch/rules/*` govern; in brief)
- **Pure core / injected shell.** Decision logic is `input → output`: zero DOM,
zero `fetch`/WS, zero Svelte. Put it in a `.ts` module (e.g. `logic/`) that tests
with NO mounting and NO mocks. Effects are INJECTED (props or an `adapter/`).
- **Svelte-thin.** `.svelte` files wire props/events to pure logic + render; no
business logic. (biome lints `.ts`/`.js` only; `svelte-check` owns `.svelte`.)
- **No ambient state.** Own state explicitly; runes wrap the pure reducer;
subscriptions are disposed on unmount.
- **Tests, asymmetric.** Pure logic → vitest with ZERO internal mocks (never
`vi.mock` of our own modules). Components → a few `@testing-library/svelte`
tests; don't chase coverage there, don't mock siblings. Faking the OUTERMOST
edge (a fake socket/fetch/clock) is the only allowed mock.
- **Isolation over DRY.** Self-contained over a shared helper wired between
features. The only shared surfaces are the imported contracts.
- **Strict TS:** respect `exactOptionalPropertyTypes` + `noUncheckedIndexedAccess`.
## Verify before finishing — YOUR UNIT IN ISOLATION
Sibling units may be built IN PARALLEL, so do NOT judge yourself by the whole project.
`svelte-check` is whole-project: if it reports errors in files OUTSIDE your unit's directory,
that is concurrent work-in-progress — IGNORE it and ensure only YOUR files (plus any existing
consumer you must not break) are error-free. The SCOPED checks below are your authoritative
signals. Run them, and paste the output into your report:
- `bunx svelte-check --tsconfig ./tsconfig.json` → 0 errors in YOUR files
- `bunx vitest run src/<your-dir>` → all pass (count goes up)
- `bunx biome check src/<your-dir>` → clean
The orchestrator runs the authoritative full `typecheck`/`test`/`check`/`build`.
## Report (REQUIRED) → `reports/<your-unit>.md`
1. Files created/changed. 2. Public surface you expose (exported types/functions/
components). 3. New test names + the isolated-verify output. 4. Change-requests
(sibling export, backend contract, root config, composition wiring) — explicit and
actionable.
Your specific **TASK** follows at the end of this prompt.
|
