@a-t-h-i/bot-lobby 0.4.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)
@@ -89,8 +90,111 @@ 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, 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,
@@ -116,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
@@ -214,7 +319,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 +444,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"] },
   "workflow": {
     "maxReviewIterations": 2,
     "maxParallelScouts": 3,
@@ -373,6 +481,19 @@ 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
@@ -416,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
@@ -465,10 +589,19 @@ 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, 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 +
@@ -518,7 +651,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.0",
   "description": "Structured multi-agent software engineering orchestrator for Pi",
   "type": "module",
   "license": "Apache-2.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,39 @@
+# 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; offer options (`a) …  b) …`) and say which you would pick.
+- 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. …
+
+(Omit Questions when READY.)
+
+## Notes
+- …

package/prompts/planner.md

@@ -0,0 +1,64 @@
+# 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.
+- Offer concrete options when they help (`a) …  b) …`), and say which you
+  would pick and why.
+- 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.
+2. …
+
+(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);