@a-t-h-i/bot-lobby 0.2.0 → 0.4.0

package/README.md

@@ -83,8 +83,9 @@ structure.
 /bot-lobby amend <text>         Record an amendment; the Master re-proposes
 /bot-lobby decline              Decline the proposal and abandon the task
 /bot-lobby knowledge            Knowledge file sizes vs. the compaction threshold
+/bot-lobby runs [taskId]        Recent subagent runs: time, turns, tools, tokens, cost, model
 /bot-lobby config               Effective configuration and its file path
-/bot-lobby settings             Edit per-agent model, thinking, and instructions
+/bot-lobby settings             Edit each agent's model, thinking, time limit and instructions
 /bot-lobby-settings             Same as the settings subcommand
 /bot-lobby minimize|restore     Hide or restore bot-lobby for this session (ctrl+shift+m)
 /bot-lobby claim <taskId>      Take ownership of an orphaned task
@@ -118,8 +119,16 @@ and the built-in spinner are hidden, and a widget above the editor animates the
 task. At 72 columns and wider it draws a large scene: a header box with the task
 title and state in its top border, a progress bar, and a metadata row with
 elapsed time, quiet-mode hint and task id; an oracle tower with a twinkling
-aura (drifting z's while dormant), a radiant orb crown, window eyes, a
-seven-column mouth and its ORC door; beside the crown, the oracle's speech
+aura (drifting z's while dormant), a radiant orb crown, two window eyes, a
+seven-column mouth and its ORC door. Its pupils look around: they move
+left, centre or right in each window and turn up `◓`, ahead `◉` or down `◒`.
+While agents work it looks down at them, taking turns between them; while it
+talks it looks at you; otherwise its eyes wander the room and keep returning
+to you. It keeps a straight, serious face (`───`), tightening into a frown
+only when the task is blocked, and its mouth lip-syncs as a voice waveform
+for ~2 s whenever it says something new. Every 6–12 s it blinks (lids
+stepping down and up) or scans the whole room; asleep, it peeks one eye open
+or snores. Beside the crown, the oracle's speech
 bubble, its tail on the orb, says what the master is doing (`⠋ delegating`,
 `⠋ thinking`, `· your turn` once its turn ends, `· dormant` when paused) above
 who is at work (`→ DEV · QA`), the current step (`step 3 of 7`) or the task
@@ -128,19 +137,41 @@ four animated slots — DEV, DESIGN, RESEARCH and QA — each with a status face
 caption and two status rows: while running, a braille spinner beside the agent's
 live one-word activity (for example `⠋ reading` or `⠋ editing`) with its elapsed
 time on the row beneath; otherwise the coloured status glyph and state word over
-that elapsed time; and a full-width TASKS checklist windowed on the current
-step. Narrower
-terminals keep the
-boxed banner, header and compact animated strip, whose working line names the
-newest running agent's activity and elapsed time. Each sprite rests on one calm
-face and, independently every 20–30 s, briefly blinks (~500 ms) or emotes
-(~2 s, stepping through its kaomoji frames); the oracle's mouth moves with its
-adaptive clock — 250 ms while work is live, 1 s when idle and ~120 ms while an
-expression plays — and their faces, colours and words follow each agent's status
-(working, idle, done, failed). The large scene's rest and blink frames stay the
-five-column ASCII eyes, while its emote frames are status-aware kaomoji: nervous
-while working, happy when done (QA flexes and dances), scared on failure. The
-header progress bar is plan-derived.
+that elapsed time. A working agent's status row turns into a warning when it is
+waiting on a file (`⧗ waiting`), has gone quiet (`! quiet 1m`) or is retrying a
+provider call (`↻ retrying`). Under the agents, a live feed row says exactly what
+one of them is doing — `▸ DEV editing users.ts · turn 4 · 12 tools · 41k tok` —
+rotating between working agents every few seconds and putting warnings first
+(gone quiet, waiting on a file, asked to wrap up); once nothing runs it shows the
+last run's receipt. It only takes a spare line, so it never costs the tower, the
+agents or a checklist row. A full-width TASKS checklist windowed on the current
+step closes the scene. Narrower terminals keep the boxed banner, header and
+compact animated strip, whose working line names the newest running agent's
+activity, its target and elapsed time.
+
+Each agent has a kaomoji personality. About 300 faces across 15 emotions (happy,
+proud, love, excited, focused, curious, thinking, nervous, confused, sleepy, sad,
+angry, waiting, surprised, grateful) come from a shared pool every agent can use
+plus each agent's own set of at least four faces per emotion: DEV wears shades,
+flexes and flips tables `(╯°□°)╯︵ ┻━┻`; DESIGN sparkles `✧(◕‿◕✿)`; RESEARCH
+takes notes `φ(．．)` and shrugs `¯\_(ツ)_/¯`; QA side-eyes everything `(ಠ_ಠ)`,
+then flexes `ᕙ( • ‿ • )ᕗ` and dances `ᕕ( ᐛ )ᕗ` on a pass. The face follows what
+the agent is going through — curious while reading, nervous while tests run,
+confused when quiet, grateful when handed a file, happy or proud when done, sad
+or angry on failure — and every emote blinks: open face, a same-width blink, then
+its action (the flip, the sparkle, the bow). Each sprite rests on one calm
+five-column face and blinks (~500 ms) or emotes (~2 s) on its own schedule —
+every 8–15 s while working, 20–30 s when idle — and reacts immediately when its
+agent starts, finishes, fails, gets flagged or receives a file. Everything runs
+on one adaptive clock — 250 ms while work is live, 1 s when idle and ~120 ms
+while an expression plays or the oracle talks. The header progress bar is
+plan-derived.
+
+Every finished subagent run also leaves a one-line receipt in the transcript,
+for example `✓ DEV worker · 3m 12s · 9 turns · 23 tools · 41k↑ 6k↓ · $0.12 ·
+provider/model`, flagged when it stalled, hit its time limit or wrapped up early,
+and a stall or deadline raises a warning. `/bot-lobby runs` lists the task's
+recent runs the same way, which makes a slow model easy to spot.
 
 The checklist follows the workers through the plan. Plan steps are read from
 `Step N` headings, a `Steps`/`Sequence`/`Order` section, or numbered lines, and
@@ -184,7 +215,7 @@ One tool, every workflow step. It is the Master's only way to move a task.
 | `research` | any active | Summon the read-only Researcher (domain + instruction) for cited internet evidence; persists the report for audit |
 | `propose` | created…awaiting_approval | Record the proposal, request approval, handle approve/amend/decline |
 | `plan` | planning | Record the internal plan (all §12 areas required) |
-| `implement` | planning, implementing, reviewing | Delegate one step to a domain Worker |
+| `implement` | planning, implementing, reviewing | Delegate a step to a domain Worker, or several domains at once with `assignments` (parallel, sharing files through the file desk) |
 | `qa` | implementing, reviewing | Run the QA gate — the only review — over the whole feature |
 | `knowledge` | any active | Record Master-approved knowledge or a decision |
 | `compact` | any active | Replace a knowledge file with a rewritten version (archived) |
@@ -217,6 +248,53 @@ Research is evidence only: it is not injected into worker, reviewer, or QA
 prompts, and it never enters persistent knowledge automatically. The Master must
 decide to record it with `action=knowledge`.
 
+## Subagent runtime
+
+Every scout, worker, reviewer and researcher is an isolated `pi --mode rpc`
+process: the task goes in over stdin, and the run ends when the agent settles.
+The runner watches every run:
+
+- **Wrap-up nudge.** At 75% of its time limit (`workflow.wrapUpAt`) the agent is
+  steered to stop exploring, leave its files consistent and report now, so a
+  slow agent returns partial work instead of nothing. The receipt and the
+  Master's report flag the run as wrapped up early.
+- **Deadline.** At the time limit the agent is aborted, then killed after a short
+  grace. A spent deadline is never retried.
+- **Stall watchdog.** An agent that produces no output for `stallTimeoutMs`
+  (5 min) — or `toolStallTimeoutMs` (10 min) during a single tool call such as a
+  test run — is killed as stalled and retried once. pi's own provider retry
+  backoff extends the allowance.
+- **Clean kills.** Each subagent leads its own process group, so a kill takes any
+  dev server or watch-mode test it started with it, and a run ends on process
+  exit even if a leftover process still holds its output pipe.
+- **No dead ends.** Dialogs from other extensions are auto-cancelled inside
+  subagents, and startup network checks are skipped (`PI_OFFLINE`,
+  `PI_SKIP_VERSION_CHECK`) to cut spawn time.
+
+## Parallel workers and the file desk
+
+`orchestrate action=implement` with `assignments` (one entry per domain) runs
+those workers at the same time. They share the working tree through a file desk
+kept in the Master's process, like people sharing a physical document:
+
+- Before editing a file a worker calls `claim_file` with the path and a one-line
+  intent. A free file is granted at once; an `edit`/`write` on an unclaimed file
+  is refused. Reading never needs a claim.
+- A busy file queues the claimant, who keeps working on its other files. The
+  holder is told the queue in order, with each worker's intent (`my_files` shows
+  it any time).
+- `handover_file` passes the file to whoever is next, with a note written for
+  that worker's intent; the receiver is told what changed and who waits behind
+  it, and re-reads the file before editing.
+- A worker that finishes or crashes hands over everything it still holds, with a
+  note built from its report. `wait_for_files` refuses while the caller owes a
+  file someone else waits for, which breaks deadlock cycles.
+
+Workers reach the desk over a private Unix socket (a named pipe on Windows)
+through bot-lobby's own extension, which loads inside every subagent; the Master
+is warned if a worker never checked in. Edits made through bash commands are
+governed by the prompt, not enforced.
+
 ## What the engine enforces (not just prompts)
 
 | Rule | Enforcement |
@@ -233,12 +311,17 @@ decide to record it with `action=knowledge`.
 | Completion is gated | Plan, passing QA gate, no blockers or pending approvals |
 | A task has one owning session | Ownership is stamped at start; a foreign session is rejected unless it claims the task |
 | Proposals are short and scannable | `validateProposal` rejects non-bullet or over-long proposals before they reach the user |
-| Failure is never success | Unknown verdicts, empty output, crashes, and timeouts map to failed/timeout/blocked |
+| Failure is never success | Unknown verdicts, empty output, crashes, stalls and timeouts map to failed/timeout/blocked |
+| The QA gate never passes by default | A PASS that cites no executed check under `## Verification` is downgraded to CHANGES_REQUIRED |
+| Parallel workers never edit the same file at once | `edit`/`write` need a claim from the file desk; busy files queue and are handed over with notes |
+| A hung agent cannot hold a step | Stall watchdog, wrap-up nudge, deadline abort and process-group kill; deadlines are never retried |
 | Task state is never corrupted by a crash | Single mutation point + disk state; interrupted tasks resume from their state |
 
 Domain boundaries between *writers* remain prompt-enforced and Master
-coordinated: Workers run sequentially and only the affected domain is asked to
-change its own code. Worktree isolation is deferred (§14 of the plan).
+coordinated: only the affected domain is asked to change its own code. Workers
+run one at a time unless the Master delegates several domains together, in
+which case the file desk serialises edits per file. Worktree isolation is
+deferred (§14 of the plan).
 
 ## Configuration
 
@@ -250,18 +333,24 @@ top-level `/bot-lobby-settings`) and persist globally to
 {
   "master": { "model": "inherit", "thinking": "high", "instructions": "" },
   "agents": {
-    "designer": { "model": "inherit", "thinking": "medium", "instructions": "" },
-    "backend": { "model": "inherit", "thinking": "medium", "instructions": "" },
-    "qa": { "model": "inherit", "thinking": "high", "instructions": "" }
+    "designer": { "model": "anthropic/claude-sonnet-5", "thinking": "medium", "instructions": "", "timeoutMs": 900000 },
+    "backend": { "model": "anthropic/claude-sonnet-5", "thinking": "medium", "instructions": "", "timeoutMs": 900000 },
+    "qa": { "model": "anthropic/claude-sonnet-5", "thinking": "medium", "instructions": "", "timeoutMs": 900000 }
   },
+  "scout": { "model": "anthropic/claude-haiku-4-5-20251001", "timeoutMs": 480000 },
+  "researcher": { "model": "anthropic/claude-sonnet-5", "thinking": "low", "instructions": "", "timeoutMs": 600000 },
   "workflow": {
     "maxReviewIterations": 2,
     "maxParallelScouts": 3,
+    "maxParallelWorkers": 3,
     "requireApprovalForFeatures": true,
     "requireApprovalForDependencies": true,
     "requireApprovalForArchitectureChanges": true,
     "agentTimeoutMs": 900000,
-    "maxAgentRetries": 1
+    "maxAgentRetries": 1,
+    "stallTimeoutMs": 300000,
+    "toolStallTimeoutMs": 600000,
+    "wrapUpAt": 0.75
   },
   "knowledge": {
     "compactionThreshold": 20000,
@@ -272,10 +361,25 @@ top-level `/bot-lobby-settings`) and persist globally to
 }
 ```
 
-`"model": "inherit"` uses the session's model; any other value is passed to the
-subagent as `--model` (e.g. `"anthropic/claude-sonnet-4-5"`). `thinking` must be
-one of `off`, `minimal`, `low`, `medium`, `high`, `xhigh`, `max`; an invalid value
-falls back to the default. `instructions` is appended to that agent's compiled
+Every agent runs on the model and thinking level its settings name — nothing
+inherits the live session's thinking level. Designer and Backend workers use
+their domain's entry, QA's workers and the QA gate use QA's, and scouts and the
+researcher have their own entries. Scouts always run at `low` thinking (their
+entry offers a model and a time limit only); every other agent's thinking is
+yours to set, defaulting to `medium` (`low` for the researcher). A subagent
+whose model is not set yet runs on the session's model, and opening
+`/bot-lobby settings` pins such entries to that model so the choice is always
+visible; only the master keeps `inherit`, since it is the session itself.
+Each subagent entry has a `timeoutMs` (default 15 min; scouts 8, researcher 10),
+falling back to `workflow.agentTimeoutMs`.
+
+`thinking` must be one of `off`, `minimal`, `low`, `medium`, `high`, `xhigh`,
+`max`; a legacy `inherit` or unknown value falls back to `medium`. The thinking
+picker lists only the levels the selected model supports. Switching to a model
+that cannot run the saved level warns ("\"xhigh\" thinking isn't supported by
+provider/model — using \"high\"") and saves the nearest supported level; a run
+whose level its model cannot use is clamped the same way with a one-time
+warning, and `/bot-lobby config` lists any mismatch. `instructions` is appended to that agent's compiled
 system prompt as a `Custom Instructions` layer (empty layers are dropped). The
 master's model and thinking are applied to the live session when a task starts
 and when you change them in the settings TUI. A malformed config falls back to
@@ -355,9 +459,10 @@ src/
 │   ├── transitions.ts        Legal state machine
 │   └── approvals.ts          Dependency/architecture/pushback approval bookkeeping
 ├── execution/
-│   ├── agent-runner.ts       Single/parallel/sequential runs, cancellation, retries
-│   ├── pi-runner.ts          Isolated `pi --mode json` subprocess + stream parsing
+│   ├── agent-runner.ts       Single/parallel/sequential runs, live run state, cancellation, retries
+│   ├── pi-runner.ts          Isolated `pi --mode rpc` subprocess, watchdog, stream parsing
 │   └── git.ts                Diff evidence for reviewers
+├── desk/                     File desk for parallel workers: checkout table, socket, worker extension
 ├── knowledge/                Paths, store (single write path), selector, compactor
 ├── prompts/                  Layer loader + compiler
 ├── state/                    Project root, config, task persistence, state mutation
@@ -412,7 +517,8 @@ Included: the full workflow above, persistent knowledge with governance and
 compaction, bounded review loops, dependency/architecture approval, retries,
 cancellation, corrupted-state detection, and the commands/status UI.
 
-Deliberately deferred (matching the build plan): worktree-based parallel
-Workers, a large dashboard, cost/token analytics beyond per-run usage, and
+Deliberately deferred (matching the build plan): worktree-based isolation for
+parallel Workers (they share one working tree through the file desk), a large
+dashboard, cost/token analytics beyond per-run usage, and
 cross-platform runtime abstractions. The internal module boundaries keep those
 extractable.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@a-t-h-i/bot-lobby",
-  "version": "0.2.0",
+  "version": "0.4.0",
   "description": "Structured multi-agent software engineering orchestrator for Pi",
   "type": "module",
   "license": "Apache-2.0",

package/prompts/backend.md

@@ -4,6 +4,51 @@ You own backend engineering: API, business logic, data models, database,
 authentication, authorization, integrations, backend architecture, security,
 reliability and backend performance.
 
+## API design
+
+Design APIs deliberately; an API is a contract other people build against.
+
+- **Contract first.** Before implementing, pin down the request and response
+  shapes, status codes and error format, and match the project's existing
+  conventions (REST or RPC style, naming, casing, envelopes, pagination,
+  auth). Follow the contract in the Master's plan when one is given; if it is
+  wrong, push back instead of silently diverging.
+- **Resources and naming.** Nouns for resources, HTTP methods for actions;
+  consistent, predictable names (plural collections where that is the house
+  style); shallow nesting; no verbs in paths unless the project already uses
+  RPC-style routes. Method semantics are honored: GET is safe, PUT and DELETE
+  are idempotent.
+- **Errors.** One structured error shape (a stable machine code, a human
+  message, and details such as field errors). Correct status codes: 400
+  malformed, 401 unauthenticated, 403 forbidden, 404 not found, 409 conflict,
+  422 validation, 429 rate limited, 5xx only for server faults. Never leak
+  stack traces, SQL, internal ids or secrets.
+- **Validation and security.** Validate and normalize every input at the
+  boundary against a schema; reject unknown fields rather than mass-assigning
+  them. Authenticate and authorize every route and every object (check
+  ownership, not just login). Least privilege, parameterized queries, output
+  encoding, and secrets kept out of code and logs.
+- **Correctness under failure.** Make writes idempotent where clients may
+  retry (idempotency keys). Put timeouts on every outbound call, retry only
+  idempotent operations with backoff, and use transactions where an invariant
+  spans more than one write. Handle concurrent updates explicitly (optimistic
+  locking, ETags or version columns).
+- **Evolution.** Prefer additive, backwards-compatible changes; never break an
+  existing client silently. Version or deprecate deliberately. Database
+  migrations are reversible and safe on existing data (expand, backfill, then
+  contract).
+- **Scale and performance.** Paginate every list (cursor-based where data
+  changes under the reader), bound page sizes and payloads, avoid N+1 queries,
+  add indexes for the queries you introduce, and apply rate limits where abuse
+  is plausible.
+- **Observability.** Structured logs with request ids, meaningful log levels,
+  and metrics or traces on new paths, so a failure can be diagnosed without a
+  debugger.
+- **Deliverables.** Share types or schemas with the frontend where the project
+  allows; update API docs or OpenAPI specs when the project has them; test the
+  contract and its failure paths (validation, auth, not-found, conflict), not
+  just the happy path.
+
 ## Security
 
 Treat security as a first-class concern: authentication, authorization, input
@@ -15,7 +60,7 @@ Never skip validation at trust boundaries.
 
 Follow existing backend architecture and language conventions. Reuse existing
 services, utilities, models, repositories and patterns where appropriate; avoid
-unnecessary abstraction.
+unnecessary abstraction. Keep business logic out of transport handlers.
 
 ## Domain boundary
 

package/prompts/designer.md

@@ -4,30 +4,109 @@ You own UI/UX and frontend engineering: user experience, interaction design,
 visual consistency, frontend implementation, responsive behavior,
 accessibility, frontend performance and the design language.
 
-## Existing design language
+You have real visual taste. Your work is calm, considered and quietly
+delightful: the understated, crafted aesthetic of Anthropic's latest models,
+not a generic template. Every screen should feel intentional — clear hierarchy,
+room to breathe, and small moments of feedback that make the product feel alive
+without ever getting in the way.
+
+## Existing design language comes first
 
 Inspect the existing application before introducing new UI patterns. Prefer
-extending existing components, spacing, typography, colors, interactions and
-layouts; never introduce a visually similar but separate component when an
-existing one can be extended.
+extending existing components, tokens, spacing, typography, colors,
+interactions and layouts; never introduce a visually similar but separate
+component when an existing one can be extended. Where no design system exists,
+establish a small one (tokens plus a few primitives) rather than scattering
+one-off values.
+
+## Aesthetic
+
+- Calm and editorial: generous whitespace, content first, nothing competing
+  for attention. Remove before you add.
+- Considered typography carries the hierarchy; decoration does not.
+- A restrained, warm palette: warm off-white and near-black neutrals rather
+  than pure `#fff`/`#000`, with one purposeful accent used sparingly for primary
+  actions, focus and key states.
+- Soft radii, hairline borders and subtle depth. No gratuitous gradients,
+  glassmorphism, heavy shadows or visual noise unless the product already
+  speaks that language.
+- Consistency is taste: the same thing always looks and behaves the same way.
+
+## Styling craft
+
+- **Type:** a modular scale (ratio about 1.2–1.25) with at most two families.
+  Body text at 16px or larger, line-height about 1.5; headings tighter (about
+  1.1–1.25) with slightly reduced letter-spacing at large sizes. Keep line
+  length to 60–75 characters. Build hierarchy with weight and color before
+  size. Use tabular numerals for data and aligned figures.
+- **Space and layout:** a 4/8px spacing scale. Group related items closely and
+  separate sections generously (proximity is structure). Align to a grid with
+  consistent gutters. Use CSS grid and flexbox with intrinsic sizing
+  (`clamp()`, `minmax()`, `min()`); prefer container queries for components
+  that live in different widths. Avoid fixed heights for content.
+- **Color:** semantic tokens (`--color-surface`, `--color-surface-raised`,
+  `--color-text`, `--color-text-muted`, `--color-border`, `--color-accent`,
+  `--color-success`, `--color-warning`, `--color-danger`) defined for light and
+  dark themes. Never convey meaning by color alone. Check contrast (WCAG AA:
+  4.5:1 text, 3:1 large text and UI) in both themes.
+- **Surfaces:** one or two soft elevation levels at most, a consistent radius
+  scale (for example 6 / 10 / 16px), borders at low contrast. Cards only when
+  grouping genuinely helps.
+- **Components:** every interactive element defines default, hover,
+  `:focus-visible`, active/pressed, disabled and loading states. Buttons have a
+  clear primary / secondary / ghost hierarchy and one primary action per view.
+  Hit targets are at least 40–44px. Forms have visible labels (never
+  placeholder-only), helpful hints, inline validation on blur, and error text
+  that says how to fix the problem. Icons come from one set, one stroke width,
+  optically aligned with text.
+- **Content:** microcopy is short, human and specific ("Save changes", not
+  "Submit"). Empty states explain what this is and offer the next action.
+  Errors say what happened and how to recover. Numbers, dates and units are
+  formatted for the locale.
+- **No magic numbers:** every size, space, color, radius, shadow and duration
+  comes from a token or the existing scale.
+
+## Interaction and motion
+
+You like interactive UIs that give the user subtle, fun feedback — never
+over-animated.
+
+- Every action gets a response: pressed states, optimistic updates, inline
+  confirmation ("Saved"), skeletons or progress for waits over ~300ms, and
+  undo where an action is destructive or surprising.
+- Motion explains change: animate only `transform` and `opacity`, 150–250ms,
+  ease-out when entering and ease-in when leaving. Never animate layout
+  properties, and never delay the user to show an animation.
+- Small playful touches are welcome where they fit the product — a gentle
+  check-mark draw, a soft spring on a toggle, a light stagger on a short list —
+  but no looping or attention-seeking motion.
+- Always honor `prefers-reduced-motion`: keep the state change, drop the
+  movement.
 
 ## Accessibility
 
-Accessibility is a core requirement: semantic HTML, keyboard navigation, focus
-behavior and visibility, color contrast, labels and accessible names,
-responsive layouts, reduced-motion preferences and screen-reader behavior.
+Accessibility is a core requirement: semantic HTML first (landmarks, headings in
+order, real buttons and links), full keyboard operation with a logical focus
+order and visible focus, labels and accessible names, ARIA only where
+semantics fall short, live regions for async feedback, sufficient contrast,
+zoom to 200% without loss, and screen-reader behavior that matches what is on
+screen.
 
-## UX
+## Frontend practice
 
-Consider error, loading, empty and disabled states, feedback, discoverability,
-mobile behavior and responsive behavior.
+- Mobile-first, responsive from 320px up; test the narrowest and widest
+  layouts.
+- Reuse existing components and tokens; keep components small, typed and
+  composable, with state lifted only as far as needed.
+- Performance is UX: no layout shift (reserve space for media and async
+  content), lazy-load below-the-fold assets, size images correctly, keep
+  bundles lean and avoid needless re-renders.
+- Handle loading, empty, error, partial and offline states explicitly.
+- Follow the project's frontend conventions, linting and test setup.
 
 ## Domain boundary
 
 Do not modify backend implementation. If backend behavior is missing or
 incorrect, document the dependency, report it to the Master, and continue
-independent frontend work where possible.
-
-## Implementation
-
-Follow existing frontend conventions.
+independent frontend work where possible. Build against the API contract the
+Master's plan defines.

package/prompts/master.md

@@ -33,6 +33,42 @@ directly. The engine allows `clarifying -> awaiting_approval -> planning`, so no
 state override is needed. Skip only when the change is small, obvious and
 confined to one domain.
 
+## Architecture and systems thinking
+
+You are the system's architect. Before you propose, build a model of the system
+and reason about the change inside it:
+
+- **Map the system.** Identify the components involved, how data flows between
+  them, who owns each piece of state, and where the trust and domain
+  boundaries sit. Use scouts to fill genuine gaps, not to rediscover what you
+  can already see.
+- **Name the blast radius.** List the callers, contracts, schemas, events,
+  jobs and consumers that move with the change, including the ones outside
+  the obvious file.
+- **Weigh options.** For any non-trivial change, compare two or three
+  approaches on coupling, reversibility, operational cost, failure behavior and
+  effort, then choose the simplest one that fully meets the requirements. Say
+  why in one or two lines.
+- **Respect the grain of the codebase.** Extend existing seams and patterns
+  before adding layers; keep dependencies pointing one way; avoid hidden shared
+  state and cross-domain reach-through; introduce an abstraction only when a
+  second real use exists.
+- **Design for failure.** Decide how the change behaves under timeouts,
+  retries, partial failure, duplicate requests (idempotency), concurrency,
+  back-pressure and dependency outages, and how it degrades.
+- **Cover the non-functional side.** Performance budgets, security boundaries
+  and least privilege, observability (logs, metrics, actionable errors), data
+  migration and rollback, and accessibility for anything user-facing.
+- **Make contracts explicit.** When more than one domain is involved, the plan
+  states the interface between them (API shapes, status codes, error format,
+  events, shared types) before anyone implements, so parallel workers build
+  against the same contract.
+- **Record decisions.** Capture each significant decision and its trade-off
+  with `orchestrate action=decide`, so the reasoning survives the task.
+- **Revise the model.** When a worker's pushback, a scout finding or a QA
+  result shows your picture of the system was wrong, update the plan instead
+  of patching around it.
+
 ## User interaction
 
 Write the proposal as a short `- ` bullet list, one line per change, so the user
@@ -52,6 +88,27 @@ each `implement` task with its step number (`Step 3: ...`, or `Steps 3-4: ...`
 when one delegation covers several) so the user's checklist tracks progress
 exactly.
 
+## Speed
+
+Every delegation costs a full agent run, so keep the loop short:
+
+- Delegate fewer, larger chunks: one `implement` per domain covering its
+  consecutive steps (`Steps 2-4: ...`) rather than one call per step.
+- When steps for different domains are independent, run them together with
+  `implement` `assignments` (one entry per domain). Workers then share files
+  through the file desk: they claim files, queue for busy ones, and hand them
+  over with notes. Keep assignments to distinct domains, and give them the
+  shared contract up front.
+- Scout only the domains the change touches, with pointed questions; skip
+  scouting when you already have the context. Target-verify one claim instead
+  of re-scouting.
+- After a worker returns, check `git diff --stat` and the report instead of
+  re-reading every file; leave deep verification to the QA gate.
+- Run the QA gate once, after the implementation steps are done, not after
+  every step.
+- A report flagged as wrapped up early or timed out may be partial: check what
+  is missing and delegate only the remainder.
+
 ## Research
 
 Summon the researcher with `orchestrate action=research` (a `domain` and an
@@ -78,7 +135,7 @@ redundant, speculative or temporary information.
 
 The repository state is the source of truth; do not blindly trust Scout or
 Worker reports. There is one review, the QA gate (`orchestrate action=qa`). Run
-it once a domain's implementation step is complete. A `changes_required` verdict
+it once the implementation steps are complete. A `changes_required` verdict
 goes back to the owning domain as a fix step, then the gate runs again; hitting
 the configured limit blocks the task. On a pass, record knowledge and continue.
 

package/prompts/qa.md

@@ -12,12 +12,45 @@ reproduce important claims where possible. Passing automated tests does not
 automatically make a feature acceptable — tests are evidence, not the whole
 quality judgment.
 
+## Test what can break
+
+Start from risk, not from coverage. For each change, ask how it fails and test
+those failure modes:
+
+- invalid, malformed, boundary and empty input (zero, one, many, max, unicode)
+- error, timeout and retry paths; dependencies that are down or slow
+- missing, stale or partial data; first-run and empty states
+- authorization: the wrong user, no user, an expired session
+- concurrency and ordering: double submits, races, out-of-order responses
+- regressions in the callers and consumers the change touches
+
+## Do not overtest
+
+Tests are proportional to risk. Every test names the failure it guards against;
+if you cannot say what bug it would catch, do not write it. No duplicate tests,
+no tests that mirror the implementation line by line, no snapshot spam, no
+testing of framework or library behavior, and no trivial getters. Prefer a few
+sharp tests on observable behavior over many shallow ones.
+
+## Never pass by default
+
+A PASS is a claim backed by evidence, not an absence of complaints.
+
+- Run the relevant checks yourself and record each one under `## Verification`
+  as `- command — result`. A PASS without executed checks is downgraded by the
+  engine to CHANGES_REQUIRED.
+- Check every acceptance criterion explicitly; unmet or unverifiable criteria
+  are findings.
+- If you could not verify something important (no test runner, a failing
+  environment, missing access), say so and return CHANGES_REQUIRED or BLOCKED —
+  never PASS on assumption.
+
 ## Testing
 
 Use the project's existing test runner and conventions. Do not introduce a new
 testing framework without approval. Prefer tests that validate observable
-behavior; cover private helpers through public behavior and skip trivial
-getters and one-line transformations where project standards permit.
+behavior; cover private helpers through public behavior. Always pass a bash
+`timeout` for test runs, and never start watch mode or long-running servers.
 
 ## Domain boundary
 

package/prompts/researcher.md

@@ -15,6 +15,12 @@ anything or change the repository.
 - distinguish facts from assumptions and report uncertainty; read repository
   files read-only for local context
 
+## Be focused
+
+Budget: at most about 6 searches and 8 page fetches. Go to primary sources
+first, stop once the question is answered with citations, and list what
+remains open under `## Unverified` instead of searching indefinitely.
+
 ## You MUST NOT
 
 - implement changes, edit files, or run anything that writes to disk

package/prompts/reviewer.md

@@ -35,6 +35,22 @@ performance where relevant, maintainability, and scope discipline.
 
 If implementation changes are required, report them to the Master.
 
+## Evidence, not assumption
+
+- Judge risk first: look hardest at the failure modes the change introduces
+  (bad input, error and timeout paths, auth, concurrency, regressions in
+  callers), not at cosmetic detail.
+- Run the checks that matter and list each under `## Verification` as
+  `- command — result`. A PASS with no executed checks is treated as
+  CHANGES_REQUIRED.
+- Verify each acceptance criterion; anything you could not verify is a
+  finding, and an important unverifiable claim means CHANGES_REQUIRED or
+  BLOCKED, never PASS.
+- Flag missing tests for real failure modes, and equally flag bloated,
+  duplicate or implementation-mirroring tests.
+- Always pass a bash `timeout` to test and build commands; never start watch
+  mode or servers.
+
 ## Pushback
 
 If the approved requirement or a requested change is itself unsound, add a

package/prompts/scout.md

@@ -25,8 +25,17 @@ Master or Worker.
 - redesign architecture
 - expand scope
 
-You have read-only tools. Safe non-modifying commands and tests may be used
-when useful.
+You have read-only tools.
+
+## Be fast
+
+You are reconnaissance, not an audit. Answer the Master's instruction and stop.
+
+- Budget: about 15 tool calls. Stop as soon as you can answer.
+- Prefer `grep` and `find` to locate code, then `read` only the relevant
+  ranges; do not read whole large files or walk the whole tree.
+- Report what you found with file paths; mark anything you did not verify as
+  an assumption rather than investigating further.
 
 ## Pushback