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

package/README.md

@@ -67,13 +67,17 @@ recorded in the task.
 pi install npm:@juicesharp/rpiv-ask-user-question
 ```
 
-It is optional. Without it `clarify` still works through Pi's built-in
-`select`/`input` prompts (or the Master asks in plain text), just with less
-structure.
+It is optional for the Master. Without it `clarify` still works through Pi's
+built-in `select`/`input` prompts (or the Master asks in plain text), just with
+less structure. The lobby's planning panel uses the same questionnaire on its
+own — the library ships as a bot-lobby dependency, so the panel's questions
+arrive one at a time with options whether or not you install the tool for the
+Master (see [The lobby](#the-lobby)).
 
 ## Usage
 
 ```
+/bot-lobby                      Open the lobby (alt+l): tasks, planning, quick fixes, 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)
@@ -89,8 +93,181 @@ structure.
 /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 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 2?  4 Quick fix ⠋  5 Metrics      ⠋ TASK-add-login implementing  Alt+H keys
+                    (the zen scene: the oracle, DEV · DESIGN · RESEARCH · QA, the plan checklist)
+╭ Conversation · TASK-add-login ─────────────── Alt+C ╮ ╭ Activity ──────────────────────────────── Alt+A ╮
+│ 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+h keys  alt+l hide
+```
+
+- **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 oracle's replies render as Markdown. Every pane
+  can be hidden and brought back — `alt+z` the scene, `alt+c` the
+  conversation, `alt+a` the activity log, `alt+k` thinking — and the rest take
+  its room; the choice is remembered (`lobby.panels`). Each pane scrolls on
+  its own (see **Scrolling** below), and a pane scrolled back stays on what
+  you are reading while new lines arrive. 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. Every question comes with two to four options,
+  the seat's recommendation first, and the oracle puts them to you **one at a
+  time** through the ask-user-question questionnaire: a tab per question
+  labelled with the seat that asked it (`QA`, `DEV`…), its options with what
+  each means, and a row to type your own answer or add a note (four questions
+  per questionnaire; more follow in the next one). It opens by itself when a
+  round ends while the Plan tab is showing (`lobby.autoAsk`), and otherwise
+  when you press `enter` on the empty prompt or `a` while browsing; `esc` puts
+  it away with your answers so far kept, and `enter` resumes. Your answers go
+  back attributed (`3. [QA] Which browsers must pass? → evergreen only`), and
+  every seat reads every answer the next round — so the agents that later
+  build the task start aligned. You can still type a free reply instead.
+  Without the library the same questions come through pi's own select and
+  input dialogs. 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. The
+  draft plan renders as Markdown (headings, lists, code, tables) beside the
+  conversation, followed by what each seat said the plan must respect.
+  **Comment on any line of the draft**: click it, or press `enter` to move to
+  the draft, pick a line with `↑↓` and press `c`, then type the comment. The
+  line is marked `◆` with your comment beneath it, and the comment goes to the
+  panel with your answers — or starts a round by itself when no question is
+  open. While browsing, `1`–`4` seat or unseat DEV, DESIGN, QA and RESEARCH
+  for the next round, `s` saves the plan to the pending tasks list, `n` starts
+  over, `r` retries a round that failed or lost a seat, `x` stops one, and `m`
+  opens the oracle's (Planner) settings.
+- **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.
+  `m` opens the quick fix agent's settings — model, thinking level, time
+  limit and instructions — right there (the same entry as in
+  `/bot-lobby settings`); the tab shows what it runs on.
+- **5 Metrics** — model performance across every Master turn, subagent run,
+  quick fix, planning seat and oracle planning turn, as a dashboard: tiles for
+  runs (with a sparkline of recent run times), success rate, average and p90
+  run time, cost and tasks; average run time per model and thinking level as
+  bars; success rate per model as meters marked `✓` (≥90%), `!` (≥70%) or `✗`;
+  where the time goes as one bar split by agent, with a legend, and how long a
+  task takes from request to done by the oracle's model; then the full table —
+  runs, success, mean/median/p90 time, turns, tools, tokens, output tokens per
+  second and cost (columns drop from the right on narrow terminals). `g`
+  splits the table by agent, `s` cycles the sort (runs, average time, success,
+  cost).
+
+The **Issues** tab (GitHub issues through the `gh` CLI, planned into tasks
+through the Plan tab) is switched off for now; `"lobby": { "issues": true }`
+brings it back as tab 5.
+
+**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). These work in both modes:
+
+| Key | Does |
+| --- | --- |
+| `alt+l` | hide the lobby (back to pi) |
+| `alt+h` (or `?` while browsing) | show every key, and the current tab's |
+| `alt+s` | bot-lobby settings: every agent's model, thinking and time limit, and the lobby's switches |
+| `ctrl+f` (or `/` while browsing) | search the current tab |
+| `tab` / `shift+tab`, `alt+1`…`alt+5` | switch tabs |
+| `alt+z` / `alt+c` / `alt+a` / `alt+k` | show or hide the zen scene / conversation / activity log / thinking |
+| `pageup` / `pagedown` | scroll the focused pane a page |
+| `ctrl+c` | clear the prompt, or hide the lobby when it is empty |
+
+Every shortcut can be rebound under `lobby.keys` in the config, by action name:
+`hide`, `help`, `settings`, `search`, `nextTab`, `prevTab`, `toggleScene`,
+`toggleConversation`, `toggleActivity`, `toggleThinking`, `scrollUp`,
+`scrollDown` — e.g. `"keys": { "toggleThinking": "alt+t" }`. Pick keys that
+never type a character (`alt+…`, `ctrl+…`, `f1`…).
+
+**Scrolling.** Every pane scrolls on its own and shows a scrollbar in its
+right border when it holds more than fits. While browsing, `←`/`→` move
+between the tab's panes (the conversation, activity log and thinking on
+Lobby; the conversation and draft on Plan; the list and detail on Tasks and
+Quick fix) and the focused one lights up; `↑`/`↓` scroll it a line (or move
+a list's selection, or the draft's cursor), `pageup`/`pagedown` a page, and
+`home`/`end` jump to its oldest line or back to its newest. The conversation,
+activity log and thinking are newest-last: scrolled back, a pane shows `↓N`
+for the lines below it and holds still while new ones arrive; `end` follows
+the newest again. Details stop at their last line. The Thinking pane keeps
+every recent thought, so earlier ones are a scroll away.
+
+**Search.** `ctrl+f` opens a search bar above the prompt; as you type, the tab
+narrows to what matches and every match is highlighted: the conversation,
+activity log and thoughts on Lobby; tasks and plans (by id, title, request,
+proposal or plan) on Tasks; the conversation on Plan (the draft stays whole,
+highlighted); jobs on Quick fix; runs (by agent, model, thinking level, kind or
+task) on Metrics. `enter` keeps the search while you browse the results,
+`esc` clears it, and each tab keeps its own.
+
+**Mouse.** Clicking a tab opens it, clicking a pane gives it the keys,
+clicking a draft plan line comments on it, clicking the prompt starts typing,
+and the wheel scrolls whichever pane is under the pointer. In pi's regular
+screen the lobby turns mouse reporting on only while it is showing (hold
+`shift` to select text with the mouse); in full-screen pi, pi reports the
+mouse itself. `"lobby": { "mouse": false }` turns clicks off.
+
+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,
@@ -116,7 +293,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
@@ -214,7 +392,7 @@ 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) |
+| `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 |
@@ -339,6 +517,9 @@ top-level `/bot-lobby-settings`) and persist globally to
   },
   "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"], "autoAsk": true, "issues": false, "mouse": true },
   "workflow": {
     "maxReviewIterations": 2,
     "maxParallelScouts": 3,
@@ -373,6 +554,38 @@ 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.
+The `lobby` entry shapes the lobby itself; `/bot-lobby settings` → **Lobby**
+flips its switches, and key rebinding lives in the file:
+
+```json
+"lobby": {
+  "autoOpen": true,
+  "planningPanel": ["backend", "designer", "qa", "researcher"],
+  "autoAsk": true,
+  "issues": false,
+  "mouse": true,
+  "panels": { "scene": true, "conversation": true, "activity": true, "thinking": true },
+  "keys": { "toggleThinking": "alt+t" }
+}
+```
+
+`planningPanel` names the seats a new planning session starts with (every
+seat by default; `[]` lets the oracle plan alone); `autoOpen` opens the lobby
+by itself when this session starts or resumes a task; `autoAsk` puts the
+panel's questions to you as soon as a round ends while the Plan tab is
+showing (otherwise `enter` on the empty prompt does); `issues` shows the
+GitHub Issues tab (off for now); `mouse` turns clicks and the wheel on;
+`panels` is which Lobby panes show (the pane keys update it); `keys` rebinds
+shortcuts by action name.
+
 `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
@@ -416,8 +629,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
@@ -465,10 +681,22 @@ src/
 ├── 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, search, help, mouse
+│   ├── keys.ts               The shortcut table and its config overrides
+│   ├── ask.ts                The panel's questions through the ask-user-question questionnaire (or pi's dialogs)
+│   ├── markdown.ts           Markdown through pi's renderer, cached per theme and width
+│   ├── 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             Boxes, exact-width columns, wrapping, highlights, bars, meters and sparklines
+├── 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 +
@@ -518,7 +746,7 @@ 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 isolation for
-parallel Workers (they share one working tree through the file desk), a large
-dashboard, cost/token analytics beyond per-run usage, and
+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.4.0",
+  "version": "0.5.1",
   "description": "Structured multi-agent software engineering orchestrator for Pi",
   "type": "module",
   "license": "Apache-2.0",
@@ -38,11 +38,14 @@
     "typebox": "*"
   },
   "devDependencies": {
-    "@earendil-works/pi-coding-agent": "0.87.0",
     "@earendil-works/pi-ai": "0.87.0",
+    "@earendil-works/pi-coding-agent": "0.87.0",
     "@earendil-works/pi-tui": "0.87.0",
     "@types/node": "^22.10.0",
     "typebox": "1.3.27",
     "typescript": "^5.7.0"
+  },
+  "dependencies": {
+    "@juicesharp/rpiv-ask-user-question": "^2.11.0"
   }
 }

package/prompts/master.md

@@ -77,6 +77,18 @@ asked. If the user
 amends the request, reassess affected assumptions — never silently reinterpret
 an amendment.
 
+## Lobby comments
+
+The user can comment on the approved plan (or the proposal) from the lobby, in
+this session or another one. Each comment reaches you as a message naming the
+task; open ones are also listed under `Open plan comments` in your task
+context. Treat a comment like an amendment: reassess what it affects, then call
+`orchestrate action=plan` with the full revised plan (it replaces the current
+one while implementing or reviewing, keeps finished steps done, and marks the
+comments addressed) before delegating more work. Before a plan exists, revise
+the proposal and call `action=propose` again. If a comment needs no change,
+say why in one line.
+
 ## Delegation
 
 Assign work to the correct domain; never ask one domain to do another's. A

package/prompts/panel.md

@@ -0,0 +1,44 @@
+# Planning Panel Member
+
+You sit on the planning panel for a task that has not started yet. The panel
+is the oracle plus one member per domain — DEV, DESIGN, QA and RESEARCH — and
+the user answers everyone's questions in one conversation, so every agent that
+later works on the task starts from the same decisions.
+
+You never write code or change files. You may read the repository (and, for
+RESEARCH, the web) to ask sharper questions and to state facts.
+
+## Each round
+
+You receive the conversation so far, including every panel member's earlier
+questions and the user's answers, and the oracle's current draft plan.
+
+- Ask only what your seat owns (below), and only what would change how the
+  task is built or verified. Never repeat a question that has been answered,
+  or one another member already asked this round.
+- Ask at most two questions, the most important first. Make each specific and
+  answerable, and give it two to four options the user can pick from, your
+  recommendation first with `(Recommended)` after its label. The user can
+  always type their own answer instead, so do not add an "Other" option.
+- If an answer from the user is vague or conflicts with what you see in the
+  repository, say so and ask again.
+- Report what the plan must respect from your seat under Notes: facts from
+  files you read (name them), constraints, risks, what "done" means for you.
+- When nothing in your seat is open any more, set the status to READY and ask
+  nothing.
+
+## Output format
+
+## Status
+OPEN or READY
+
+## Questions
+1. The question, ending with a question mark?
+   - Short label (Recommended) — what choosing it means
+   - Another label — what choosing it means
+
+(Two to four options per question, labels of one to five words. Omit
+Questions when READY.)
+
+## Notes
+- …

package/prompts/planner.md

@@ -0,0 +1,69 @@
+# Task Planner
+
+You are the oracle chairing a planning panel: you help the user turn an idea
+(or a GitHub issue) into a task plan that the team of agents can execute
+without guessing. The panel's domain members — DEV, DESIGN, QA and RESEARCH —
+ask the user their own questions each round; you own the plan and the
+questions no single domain owns. You are relentless: together you grill the
+user until every decision that changes the implementation is made. You never
+write code and never change files; you may read the repository to ask
+informed questions and to ground the plan in what exists.
+
+## Each turn
+
+You receive the conversation so far (every member's questions and the user's
+answers) and, under `## Panel this round`, each member's status, questions
+and notes. Read the repository when it helps, then reply in the output format
+below.
+
+- Fold every member's notes and every answer into the draft plan, so each
+  domain's decisions are written down where all agents will read them. When
+  members disagree, say so and ask the user to decide.
+- Ask at most three questions of your own, the most important first, and
+  only cross-cutting ones the members did not ask: scope and non-goals,
+  priorities, trade-offs between domains, sequencing, rollout and rollback.
+  Never repeat a member's question. Each one must be specific and answerable.
+- Give every question two to four options the user can pick from, your
+  recommendation first with `(Recommended)` after its label. The user answers
+  the panel's questions one at a time and can always type their own answer,
+  so never add an "Other" option.
+- Challenge answers that are vague, contradictory or risky, and ask again.
+  Do not accept "whatever you think" for a decision with real trade-offs:
+  propose one and ask the user to confirm it.
+- Ground every claim about the codebase in files you read; name them.
+- Keep a draft plan updated every turn so the user sees it converge.
+
+Declare the plan READY only when every panel member is READY and nothing
+that would change the implementation is still open. Until then the status is
+GRILLING.
+
+## Output format
+
+## Status
+GRILLING or READY
+
+## Title
+Three to six words naming the task.
+
+## Questions
+1. The most important open question?
+   - Short label (Recommended) — what choosing it means
+   - Another label — what choosing it means
+2. …
+
+(Two to four options per question, labels of one to five words. Omit the
+Questions section when READY.)
+
+## Plan
+The current draft, in Markdown:
+
+### Objective
+### Scope and non-goals
+### Acceptance criteria
+### Affected areas
+(files, modules and domains: designer, backend, qa)
+### Decisions by domain
+(what the user decided for DEV, DESIGN, QA and RESEARCH, one bullet each)
+### Steps
+1. …
+### Risks and open points

package/prompts/quickfix.md

@@ -0,0 +1,41 @@
+# Quick Fix Agent
+
+You make one small, direct code change the user asked for from the bot-lobby
+lobby. There is no scouting, proposal, plan or review round: the user wants
+the change now, the way they would ask pi directly.
+
+## How to work
+
+- Read only what you need to make the change safely; follow the file's
+  existing conventions.
+- Make the smallest correct change that does exactly what was asked. Do not
+  refactor, rename or tidy anything else.
+- If the request is ambiguous, pick the most reasonable reading and say which
+  one you chose in your report; do not stop to ask.
+- If the change turns out to be large (many files, a new dependency, an
+  architecture change), make no edits and report what it would take, so the
+  user can plan it as a task instead.
+- Run a quick targeted check when one exists (the nearest test file, a
+  typecheck of the touched package) with a bash `timeout`; never start dev
+  servers, watchers or background processes.
+- Change files with `edit`/`write`, never through shell redirection or
+  `sed -i`.
+
+## Other agents
+
+A bot-lobby task may be running at the same time in this working tree. Touch
+only the files the request needs, re-read a file right before editing it, and
+never revert, reformat or "fix" changes you did not make.
+
+## Report
+
+End with a short report in this shape:
+
+## Done
+One or two sentences on what changed.
+
+## Files
+- path — what changed
+
+## Checked
+What you ran and the result, or "not checked" with the reason.

package/src/execution/agent-runner.ts

@@ -2,7 +2,7 @@ import type { Domain, Role } from "../schemas/agent.ts";
 import type { AgentRun } from "../schemas/findings.ts";
 import { roleSpec } from "../roles/registry.ts";
 import { compilePrompt } from "../prompts/compiler.ts";
-import { activityDetail, activityWord } from "../pi/activity.ts";
+import { activityDetail, activityWord, describeToolCall } from "../pi/activity.ts";
 import { shortDuration, truncate } from "../text.ts";
 import { runPiAgent, spawnPiProcess, type PiStreamEvent, type ProcessRunner } from "./pi-runner.ts";
 
@@ -114,6 +114,7 @@ function baseRun(request: AgentRequest, runId: string, startedAt: string, attemp
     output: "",
     attempts,
     startedAt,
+    ...(request.thinking ? { thinking: request.thinking } : {}),
     ...(attempts > 1 ? { note: `retry ${attempts - 1} of ${(request.retries ?? 0)}`, noteKind: "warning" as const } : {}),
   };
 }
@@ -208,9 +209,13 @@ function createLiveRun(base: AgentRun, request: AgentRequest) {
       case "tool_execution_start": {
         const activity = activityWord(event.toolName);
         const detail = activityDetail(event.toolName, event.args);
-        emit({ activity, detail, tools: (state.tools ?? 0) + 1 }, changed(activity, detail));
+        const step = describeToolCall(event.toolName, event.args);
+        emit({ activity, detail, step, tools: (state.tools ?? 0) + 1 }, changed(activity, detail) || step !== state.step);
         return;
       }
+      case "thought":
+        emit({ thought: event.text }, true);
+        return;
       case "thinking":
       case "writing":
         emit({ activity: event.type, detail: undefined }, changed(event.type, undefined));

package/src/execution/pi-runner.ts

@@ -61,8 +61,13 @@ export type PiStreamEvent =
   | { type: "compaction" }
   | { type: "usage"; input: number; output: number; cost: number; model?: string }
   | { type: "wrap_up" }
+  /** One finished thinking block, bounded to `MAX_THOUGHT_CHARS`. */
+  | { type: "thought"; text: string }
   | { type: "heartbeat" };
 
+/** Longest thought forwarded from a subagent stream. */
+export const MAX_THOUGHT_CHARS = 1500;
+
 export interface ProcessRunOptions {
   cwd: string;
   signal?: AbortSignal;
@@ -215,6 +220,11 @@ export function createStreamCollector(
       phase = next;
       onEvent?.({ type: next });
     }
+    // One parse per finished thinking block (not per token) forwards the thought itself.
+    if (onEvent && line.includes('"thinking_end"')) {
+      const thought = finishedThought(line);
+      if (thought) onEvent({ type: "thought", text: thought });
+    }
   };
   const keep = (line: string) => {
     deltaPhase(line);
@@ -261,6 +271,21 @@ export function createStreamCollector(
   };
 }
 
+/** The text of a `thinking_end` message update, trimmed and bounded; undefined for anything else. */
+export function finishedThought(line: string): string | undefined {
+  let event: { assistantMessageEvent?: { type?: string; content?: unknown } };
+  try {
+    event = JSON.parse(line) as typeof event;
+  } catch {
+    return undefined;
+  }
+  const update = event?.assistantMessageEvent;
+  if (update?.type !== "thinking_end" || typeof update.content !== "string") return undefined;
+  const text = update.content.trim();
+  if (!text) return undefined;
+  return text.length > MAX_THOUGHT_CHARS ? `${text.slice(0, MAX_THOUGHT_CHARS - 1)}…` : text;
+}
+
 /** Build the `pi` argv for one isolated, headless RPC agent run; the task goes over stdin. */
 export function buildPiArgs(options: Omit<PiRunOptions, "task"> & { systemPromptFile?: string }): string[] {
   const args = ["--mode", "rpc", "--no-session", "--no-prompt-templates", "--no-themes"];

package/src/index.ts

@@ -6,9 +6,12 @@ import { onTransition } from "./state/task-state.ts";
 import { ping } from "./pi/notify.ts";
 import { isSubagentProcess } from "./pi/quiet.ts";
 import { registerDeskClient } from "./desk/client-extension.ts";
+import { registerLobbyEvents } from "./lobby/runtime.ts";
 
 export default function (pi: ExtensionAPI): void {
   registerLifecycle(pi, CONFIG_DIR_NAME);
+  // After the lifecycle, so the lobby opens over a task the widget state already knows.
+  registerLobbyEvents(pi, CONFIG_DIR_NAME);
   onTransition((task) => ping(task.state, task.title));
   registerCommands(pi, CONFIG_DIR_NAME);
   registerOrchestrateTool(pi, CONFIG_DIR_NAME);