@a-t-h-i/bot-lobby 0.3.0 → 0.5.0

package/README.md

@@ -74,6 +74,7 @@ structure.
 ## Usage
 
 ```
+/bot-lobby                      Open the lobby (alt+l): tasks, planning, quick fixes, issues, metrics
 /bot-lobby <request>            Start a task and hand it to the Master
 /bot-lobby status [taskId]      Active task, state, approvals, blockers, legal next states
 /bot-lobby tasks                Task list (plus any unreadable task state)
@@ -83,13 +84,117 @@ 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
+/bot-lobby lobby | help         Open the lobby, or show this list
 ```
 
+## The lobby
+
+The lobby is bot-lobby's full-screen home: a tabbed view over every task in the
+project, your planning, quick fixes, GitHub issues and model performance, with
+one prompt at the bottom whose target follows the tab. It opens by itself when
+this session starts (or resumes) a task — the small zen widget returns whenever
+you hide it — and `alt+l` or `/bot-lobby` opens and hides it at any time, with
+or without a task.
+
+```
+ ◆ bot-lobby │ 1 Lobby  2 Tasks 2  3 Plan  4 Quick fix ⠋  5 Issues  6 Metrics        ⠋ TASK-add-login implementing
+ ───────────────────────────────────────────────────────────────────────────────────────────────────────────
+                    (the zen scene: the oracle, DEV · DESIGN · RESEARCH · QA, the plan checklist)
+ ── Conversation · TASK-add-login ──────────────────── ┬ ── Activity ───────────────────────────────────────
+ you ▸ add a login page with email + password           │ 12:04 MASTER    ✓ scouting designer, backend
+ oracle ▸ Proposal:                                     │ 12:06 DEV       ⠋ reading auth.ts…
+          - LoginForm component                         │ 12:06 DESIGN    ⠋ editing LoginForm.tsx…
+          - POST /api/login with rate limiting          │ 12:06 QUICK FIX ✓ done: rename getUser
+ ── Thinking ───────────────────────────────────────────────────────────────────────── DEV · 12s ago ──
+ The auth module already exposes a session helper; reuse it rather than adding a new one.
+ ── message the oracle ─────────────────────────────────────────────────────────────────────────────────
+  _
+ TYPE  enter send · shift+enter newline · esc browse · tab next tab · alt+l hide lobby
+```
+
+- **1 Lobby** — the task's zen scene, then the conversation with the oracle
+  (its text only: no tool rows, no thinking), an activity log that narrates
+  every tool call in plain words (`reading index.html…`, `searching for
+  "router" in src`, `running npm test`, `delegating to backend: Step 2 …`) from
+  the Master and every subagent, and a single **Thinking** pane — the one place
+  thoughts show up: the oracle's live thought as it streams, and each finished
+  thought from a subagent, quick fix or the planner (pi's own transcript,
+  behind the lobby, still carries the oracle's thinking blocks; `ctrl+t`
+  collapses them there). The prompt talks to the
+  oracle (while it works, enter steers the running turn; `esc` stops it); with
+  no task, it starts one.
+- **2 Tasks** — every task in the project: this session's, the ones other pi
+  sessions are driving, pending plans saved from the planner, and recently
+  finished ones. The detail pane shows the request, the approved plan with its
+  step checklist, your comments on it, amendments, what the task waits on and
+  its recent runs. `c` comments on the selected task's plan (see below), `s`
+  starts a pending plan as a task in this session, `d` twice discards one.
+- **3 Plan** — task planning mode with a planning panel. Describe what you
+  want and every seat grills you from its own domain, on the model and
+  thinking level its settings name: **DEV** (APIs, data, errors, security,
+  performance), **DESIGN** (flows, states, copy, visual language,
+  accessibility), **QA** (acceptance criteria, test strategy, edge cases,
+  definition of done) and **RESEARCH** (libraries, versions, docs and prior
+  art, with the web tools when `pi-web-access` is installed). The **oracle**
+  chairs on the Planner model: it reads the seats' questions and notes, folds
+  every answer into the draft plan (with a *Decisions by domain* section) and
+  asks only what no single seat owns. Each round the seats run in parallel,
+  read-only, then the oracle; the questions arrive numbered and attributed
+  (`3. QA  Which browsers must pass?`), you answer them all in one message,
+  and every seat reads every answer the next round — so the agents that later
+  build the task start aligned. A roster shows what each seat is doing and
+  whether it is READY; the plan is READY only when every seat and the oracle
+  agree, and the draft pane lists what each seat said the plan must respect.
+  While browsing, `1`–`4` seat or unseat DEV, DESIGN, QA and RESEARCH for the
+  next round, `enter` switches between the conversation and the draft, `s`
+  saves the plan to the pending tasks list, `n` starts over, `r` retries a
+  round that failed or lost a seat, and `x` stops one.
+- **4 Quick fix** — a direct prompt, the way you would ask pi, that skips the
+  whole workflow: one coding agent (full tools) makes the change right away
+  while any task keeps running. Quick fixes run one at a time in the order you
+  send them; each shows its steps and final report, and `x` cancels one. A
+  request that turns out to be large is reported back instead of attempted.
+- **5 Issues** — the repository's open GitHub issues through the `gh` CLI (it
+  owns sign-in; bot-lobby stores no token). `enter` reads one with its
+  comments, `n` files a new one (first line is the title), `r` refreshes, and
+  `p` plans it: the Plan tab opens seeded with the issue, and the saved plan
+  keeps a link to it, so an issue becomes a task only after it has been
+  planned.
+- **6 Metrics** — model performance across every Master turn, subagent run,
+  quick fix, planning seat and oracle planning turn: per model and thinking level, the number of runs,
+  success rate, mean/median/p90 time, turns, tools, tokens, output tokens per
+  second and cost (columns drop from the right on narrow terminals); how long a
+  task takes from request to done by the oracle's model and thinking level; and
+  where the time goes by agent. `g` splits the table by agent, `s` cycles the
+  sort (runs, average time, success, cost).
+
+**Keys.** Like a modal editor, the lobby has a typing mode (keys go to the
+prompt) and a browsing mode (`esc`; arrows move through lists, single keys run
+the tab's commands, and on Lobby, Plan and Quick fix any other key resumes
+typing). Everywhere: `tab`/`shift+tab` or `alt+1`…`alt+6` switch tabs,
+`pageup`/`pagedown` scroll, `ctrl+c` clears the prompt (or hides the lobby
+when it is empty) and `alt+l` hides the lobby. Anything that needs pi itself —
+built-in slash commands, `/model`, the tool-row toggle — works with the lobby
+hidden; bot-lobby's own `/bot-lobby …` commands also work from the Lobby
+prompt. When the Master asks you something (an approval, a clarifying
+question), the lobby steps aside for the dialog and comes back once you answer.
+
+**Plan comments.** A comment on a task's plan is saved beside the task
+(`comments.jsonl`) from any session, and the session that owns the task passes
+new comments to its oracle — right away when you comment in that session,
+within a few seconds from another one, held while the task is paused or the
+session is minimized. The oracle treats a comment like an amendment and calls
+`orchestrate action=plan` with the full revised plan, which replaces the
+approved plan while implementing or reviewing, keeps finished steps done and
+marks the comments addressed (`○` waiting, `◐` sent to the oracle, `✓` plan
+amended). Before a plan exists, a comment asks for a revised proposal instead.
+
 ## Sessions and ownership
 
 A task is owned by the pi session that started it (`ctx.sessionManager` id,
@@ -115,7 +220,8 @@ every in-flight subagent process.
 
 While the owning session has a task active, its transcript switches to a zen view: `orchestrate` rows
 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
+task (the same scene heads the lobby's first tab; the widget shows while the
+lobby is hidden). 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, two window eyes, a
@@ -136,19 +242,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), all 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 — 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
@@ -191,8 +319,8 @@ One tool, every workflow step. It is the Master's only way to move a task.
 | `scout` | created…synthesizing | Run domain reconnaissance in parallel; repeat later to target-verify a claim |
 | `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 |
+| `plan` | planning, implementing, reviewing | Record the internal plan (all §12 areas required); later, replace it with an amended plan (addresses lobby comments) |
+| `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) |
@@ -225,6 +353,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 |
@@ -241,12 +416,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
 
@@ -258,18 +438,27 @@ 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 },
+  "quickFix": { "model": "anthropic/claude-sonnet-5", "thinking": "low", "instructions": "", "timeoutMs": 600000 },
+  "planner": { "model": "anthropic/claude-sonnet-5", "thinking": "high", "instructions": "", "timeoutMs": 300000 },
+  "lobby": { "autoOpen": true, "planningPanel": ["backend", "designer", "qa", "researcher"] },
   "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,
@@ -280,10 +469,38 @@ 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`.
+
+The lobby's two agents have entries of their own: `quickFix` (the direct-change
+agent, `low` thinking and 10 minutes by default) and `planner` (the oracle
+chairing the planning panel, `high` thinking; its time limit bounds one round
+for every seat, 5 minutes by default). Both appear in `/bot-lobby settings`,
+take custom instructions, and run on the session's model until you pin one.
+Planning seats reuse their domain's entry — DEV the Backend's, DESIGN the
+Designer's, QA the QA's, RESEARCH the Researcher's model, thinking and
+instructions — so a seat plans on the model that will later build its part.
+`lobby.planningPanel` names the seats a new planning session starts with
+(every seat by default; `[]` lets the oracle plan alone), and
+`lobby.autoOpen` (default `true`) opens the lobby by itself when this session
+starts or resumes a task.
+
+`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
@@ -320,8 +537,11 @@ and the output contract — and an empty layer is dropped.
 ├── Backend/knowledge/          knowledge.md, engineering-standards.md, decisions.md, completed-tasks.md
 ├── QA/knowledge/               knowledge.md, testing-standards.md, decisions.md, completed-tasks.md
 ├── archive/<Agent>/            previous knowledge versions (outside all retrieval paths)
+├── backlog/PLAN-<slug>.json    pending tasks saved from the planner (optionally linked to an issue)
+├── metrics.jsonl               one line per finished run of any agent, for the Metrics tab
 └── tasks/TASK-<stamp>/
     ├── state.json              the task record (kept after completion)
+    ├── comments.jsonl          your lobby comments on the plan and their delivery (append-only)
     ├── proposal.md             scratchpads: deleted on completion
     ├── plan.md
     ├── designer.md backend.md qa.md
@@ -363,15 +583,25 @@ 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
+├── lobby/
+│   ├── runtime.ts            Mounts the full-screen lobby on pi's TUI, dialogs hand-off, comment delivery, Master metrics
+│   ├── view.ts               The tabbed view: tab bar, per-tab prompt, typing/browsing modes, keys
+│   ├── tabs/                 Pure renderers: home, tasks, plan, quickfix, issues, metrics
+│   ├── feed.ts               Activity log, thinking pane and conversation store
+│   ├── quickfix.ts           Direct-change jobs, one at a time
+│   ├── planner.ts            The planning panel: seats and the oracle per round, reply parsing, saving a plan
+│   ├── issues.ts             GitHub issues through the gh CLI
+│   └── layout.ts             Exact-width columns, rules, wrapping and scroll windows
+├── state/                    Project root, config, task persistence, state mutation, comments, backlog, metrics
 ├── schemas/                  Task, agent, findings, configuration types
 └── pi/                       Commands, lifecycle, orchestrate tool, status widget
-prompts/                      global, master, designer, backend, qa, scout, worker, reviewer, researcher
+prompts/                      global, master, designer, backend, qa, scout, worker, reviewer, researcher, quickfix, planner, panel
 ```
 
 Prompts are composed, never duplicated: `global + domain + role + task context +
@@ -420,7 +650,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) and
 cross-platform runtime abstractions. The internal module boundaries keep those
-extractable.
+extractable. The lobby (see above) has since added the full-screen dashboard
+and per-model performance analytics.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@a-t-h-i/bot-lobby",
-  "version": "0.3.0",
+  "version": "0.5.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.