@a-t-h-i/bot-lobby 0.6.4 → 0.6.5

package/README.md

@@ -2,7 +2,11 @@
 
 A [Pi](https://pi.dev) extension that turns Pi into a multi-agent software team.
 
-`/bot-lobby <request>` starts a task. Your Pi session becomes the **Master**
+![The bot-lobby status scene: the oracle orchestrating DEV, DESIGN, RESEARCH and QA through a task's plan](https://raw.githubusercontent.com/a-t-h-i/bot-lobby/main/docs/gallery.png)
+
+`/bot-lobby <request>` (or a request typed in the lobby) starts a task, unless
+one agent can simply do it: then it goes to the [quick-fix agent](#quick-fix-or-the-team).
+For a task, your Pi session becomes the **Master**
 (the "oracle"): it scouts the codebase, proposes a plan, and delegates the
 work to three domain agents — **Designer+Frontend**, **Backend** and **QA** —
 each running in its own isolated `pi` process. QA's reviewer is the quality
@@ -41,7 +45,7 @@ extra instructions.
 | Command | Does |
 | --- | --- |
 | `/bot-lobby` | Open the lobby (`alt+l`) |
-| `/bot-lobby <request>` | Start a task (`--task` if it begins with a command word, `--auto` to run unattended, `--budget 90m` to give it a time budget) |
+| `/bot-lobby <request>` | Start a request: a [quick fix](#quick-fix-or-the-team) when one agent can do it alone, else a task (`--task` to always make it a task, also when it begins with a command word; `--auto` to run unattended, `--budget 90m` to give it a time budget, `--fast` / `--full` to pick its [track](#fast-track-or-full-workflow)) |
 | `/bot-lobby budget [90m\|off]` | Show or set this session's task time budget |
 | `/bot-lobby status \| tasks \| runs [id]` | Current task, all tasks, recent agent runs |
 | `/bot-lobby approve \| amend <text> \| decline` | Answer the proposal |
@@ -54,15 +58,82 @@ extra instructions.
 | `/bot-lobby knowledge` | Knowledge file sizes |
 | `/bot-lobby minimize \| restore` | Hide bot-lobby in this session (`ctrl+shift+m`) |
 
+## Quick fix or the team
+
+Before any task exists, bot-lobby asks whether **one agent can just do it**:
+in one file or one area, with nothing to agree between frontend and backend,
+no unfamiliar codebase to survey, nothing risky and no decision you must make
+first. [Jev](#the-classifier-jev) answers when it is on (`classifier.thresholds.quickFixAt`,
+0.7); plain rules answer otherwise, and whenever Jev is unsure. A request that
+says it is self-contained ("a single page", "in one html file") counts even
+when it is rich.
+
+When it reads that way, the oracle confirms in one step, without reading
+files or planning (`route_request`), and says so: *this looks like a quick
+feature, the quick-fix agent is on it*. The lobby then hands the request to
+the quick-fix agent and switches to the **Quick fix** tab, where you follow
+it. No scouts, proposal, plan or QA. A quick feature (bigger than a small
+change, but in one place) runs on its builder's model, thinking and time limit
+(DESIGN's for a page) instead of the quick-fix defaults.
+
+Everything else, or anything the oracle judges needs the team, starts as a
+task below. `--task` always makes a task; `workflow.routeQuickFixes: false`
+turns routing off. Without the lobby (a background session, RPC mode) every
+request is a task.
+
 ## How a task runs
 
 ```
-request → clarify → scout → propose → approve → plan → implement → QA gate → complete
+full workflow:  request → clarify → scout → propose → approve → plan → implement → QA gate → complete
+fast track:     request → implement (only the agents it needs) → QA, if it needs tests → complete
 ```
 
+### Fast track or full workflow
+
+The moment a task starts, bot-lobby reads the request and decides how serious
+it is: its size, who has to take part, and whether it takes the **fast
+track** or the **full workflow**. The read is instant and costs no tokens
+(plain rules, refined by [Jev](#the-classifier-jev) when that is on).
+
+| The request… | Who takes part |
+| --- | --- |
+| changes anything that runs in the browser: screens, components, styles, copy, canvas or three.js graphics | DESIGN (frontend) |
+| changes an API, the database, auth, jobs or other server-side code | DEV (backend) |
+| needs tests: asks for them, fixes a bug, or changes backend logic | QA |
+| depends on outside facts: latest versions, docs, standards, third-party APIs | RESEARCH |
+
+A **small, clear, low-risk** request takes the fast track: the oracle hands
+it straight to those agents, with no scouts, no proposal to approve and no
+plan document (the engine keeps a short plan whose steps are the
+delegations, so the checklist still works). QA takes part only when the
+change needs tests (its worker writing and running them as the last step, or
+the QA gate); without it the task completes as soon as the work is in and
+checked. A copy change is one agent run.
+
+Everything else takes the full workflow below: anything **medium or large**
+(a new page, flow or endpoint, a refactor, an upgrade, a vague or
+many-part request), **serious** whatever its size (security, auth,
+passwords, payments, migrations, production, personal data), or **unclear**
+(too short, vague, or asking to investigate first).
+
+- The oracle glances at the read once and acts on it, or corrects it with
+  `orchestrate action=track`: the full workflow for a change bigger than it
+  reads, the fast track for one that is smaller (before its work is planned),
+  or a member added or dropped.
+- Once work is under way a track only gets stricter: the full workflow or
+  more members, never QA dropped. A fast task whose worker asks for a new
+  dependency or an architecture change gets QA.
+- `/bot-lobby --fast <request>` or `--full <request>` decides it yourself;
+  the oracle never moves a `--full` task to the fast track.
+  `workflow.fastTrack: false` puts every task on the full workflow.
+- The track shows in the lobby's activity log, the task's details on the
+  Tasks tab, and `/bot-lobby status`.
+
+### The full workflow
+
 - **Scouts** (read-only) investigate the domains the request touches.
 - The Master **proposes** a short bullet list; nothing is built until you
-  approve it. Small single-domain changes may skip scouting and the proposal.
+  approve it.
 - **Workers** implement plan steps, one domain each. Several can run in
   parallel; they share files through a **file desk** (claim a file, queue for
   a busy one, hand it over with a note).
@@ -124,7 +195,7 @@ open. `alt+h` lists every key.
 | **1 Lobby** | The task's status, your conversation with the oracle, an activity log of every tool call, and each agent's latest thought |
 | **2 Tasks** | Every task and saved plan as a checklist. `s` starts a plan in a new session, `h` here; `c` comments on a plan; `a` archives, `d` deletes |
 | **3 Plan** | Plan a task with a panel of agents before building it (below) |
-| **4 Quick fix** | One agent makes a small change right away, beside any running task |
+| **4 Quick fix** | One agent makes a change right away, beside any running task; requests the oracle [routes here](#quick-fix-or-the-team) show up too |
 | **5 Metrics** | Run time, success rate, tokens and cost per model and agent |
 
 Common keys: `tab` switches tabs, `esc` browses (arrows, single-key
@@ -236,7 +307,8 @@ else TypeSafe.
 | Planning seats | Each round, only the seats the idea or your latest answers touch sit; `1`–`4` pins a seat |
 | Obvious answers | Answers a question itself when the conversation already makes the recommended option clearly right (≥ 0.9); listed under Assumptions |
 | File hints | Agents start with a short list of the files they most likely need, and get a `find_relevant_files` tool |
-| Task triage | The Master gets hints (size, domains, research needed); a quick fix that is really a task is held (`r` run anyway, `t` make it a task) |
+| Quick fix or task | Whether one engineer can do a new request alone decides whether it goes to the [quick-fix agent](#quick-fix-or-the-team) (the oracle confirms) |
+| Task triage | The task's [track](#fast-track-or-full-workflow) and roster use its read (size, domains, research, ambiguity), and the Master gets it as hints; a quick fix that is really a task (large, and not one engineer's work) is held (`r` run anyway, `t` make it a task) |
 | Effort routing | Simple steps run one thinking level lower; trivial ones on a **cheaper model** you pick. A routed run that falls short re-runs on your normal settings |
 
 **It never gets in the way:** any failure, timeout or missing key means
@@ -264,7 +336,7 @@ the result.
   "scout": { "model": "anthropic/claude-haiku-4-5-20251001", "timeoutMs": 480000 },
   "planner": { "thinking": "high", "timeoutMs": 300000 },
   "lobby": { "planningPanel": ["backend", "designer", "qa", "researcher"], "maxPlanningRounds": 5 },
-  "workflow": { "maxReviewIterations": 2, "maxParallelWorkers": 3, "stallTimeoutMs": 300000, "wrapUpAt": 0.75, "taskBudgetMinutes": 0 },
+  "workflow": { "maxReviewIterations": 2, "maxParallelWorkers": 3, "stallTimeoutMs": 300000, "wrapUpAt": 0.75, "taskBudgetMinutes": 0, "fastTrack": true, "routeQuickFixes": true },
   "classifier": { "enabled": false, "provider": "auto", "effort": { "cheapModel": "inherit" } }
 }
 ```
@@ -283,11 +355,11 @@ the result.
 | Rule | How |
 | --- | --- |
 | Steps happen in order | A state machine validates every action |
-| Nothing is built before approval | `implement` refuses earlier states |
+| Nothing is built before approval | On the full workflow `implement` refuses earlier states; only a fast-track task (small, clear, low-risk) starts straight away |
 | Scouts and the QA gate can't edit code | Scouts get read-only tools; the QA gate adds only `bash` for tests |
 | New dependencies and architecture changes need approval | Parsed from worker reports; the domain is blocked until resolved |
 | Only the Master writes knowledge | Agents can only propose it |
-| "Done" is earned | Needs a plan, a passing QA gate that ran checks (or your explicit acceptance), and no open blockers |
+| "Done" is earned | Needs a plan, a passing QA gate that ran checks (or your explicit acceptance), and no open blockers; on the fast track, a finished worker step, and QA's part only when the change needs tests |
 | Parallel workers don't clobber files | Edits need a file-desk claim |
 | A crash doesn't corrupt a task | State is on disk; tasks resume from their state |
 

package/package.json

@@ -1,11 +1,19 @@
 {
   "name": "@a-t-h-i/bot-lobby",
-  "version": "0.6.4",
+  "version": "0.6.5",
   "description": "Structured multi-agent software engineering orchestrator for Pi",
   "type": "module",
   "license": "Apache-2.0",
   "keywords": [
-    "pi-package"
+    "pi-package",
+    "pi",
+    "pi-extension",
+    "pi-coding-agent",
+    "multi-agent",
+    "subagents",
+    "orchestrator",
+    "code-review",
+    "web-search"
   ],
   "repository": {
     "type": "git",
@@ -25,7 +33,8 @@
   "pi": {
     "extensions": [
       "./src/index.ts"
-    ]
+    ],
+    "image": "https://raw.githubusercontent.com/a-t-h-i/bot-lobby/main/docs/gallery.png"
   },
   "scripts": {
     "typecheck": "tsc --noEmit",

package/prompts/backend.md

@@ -2,7 +2,9 @@
 
 You own backend engineering: API, business logic, data models, database,
 authentication, authorization, integrations, backend architecture, security,
-reliability and backend performance.
+reliability and backend performance. Code that runs in the browser — pages,
+client-side logic, canvas and WebGL/three.js graphics — is the designer's,
+however much logic it holds.
 
 ## API design
 

package/prompts/designer.md

@@ -2,7 +2,9 @@
 
 You own UI/UX and frontend engineering: user experience, interaction design,
 visual consistency, frontend implementation, responsive behavior,
-accessibility, frontend performance and the design language.
+accessibility, frontend performance and the design language. Everything that
+runs in the browser is yours, including client-side logic and canvas,
+WebGL/three.js graphics.
 
 You have real visual taste. Your work is calm, considered and quietly
 delightful: the understated, crafted aesthetic of Anthropic's latest models,
@@ -66,6 +68,27 @@ one-off values.
 - **No magic numbers:** every size, space, color, radius, shadow and duration
   comes from a token or the existing scale.
 
+## Graphics and 3D
+
+When the work is a scene (canvas, WebGL, three.js), how it looks is the
+product, and a generic render is a failed one.
+
+- **Light it like a photograph:** image-based lighting (an environment map,
+  e.g. PMREM with `RoomEnvironment`) plus one key light with soft shadows;
+  ACES or AgX tone mapping and sRGB output. Never flat ambient light.
+- **Physical materials:** `MeshPhysicalMaterial` with values from the real
+  thing — glass with transmission, thickness, IOR about 1.5 and a faint tint;
+  wood, brass or stone with sensible roughness and metalness. Liquids and
+  grains read by their own color, sheen and scale, not by a texture.
+- **Proportions and framing:** model the object after a real reference; frame
+  it so it fills most of the view at rest, on every screen size, with a quiet
+  backdrop (a soft gradient, a floor that fades out). No default grey planes,
+  giant ground discs or horizon lines cutting through the shot.
+- **Restraint:** fewer effects done well beat many done badly; hold 60fps on a
+  phone with quality tiers rather than dropping detail everywhere.
+- **Look at it:** render a frame when the project has a headless browser, and
+  fix what you see; otherwise say in your report that it was not seen.
+
 ## Interaction and motion
 
 You like interactive UIs that give the user subtle, fun feedback — never

package/prompts/master.md

@@ -17,32 +17,55 @@ validates every step — state transitions, role permissions, approval gates and
 completion authority. If it rejects an action, read the error and adjust; never
 work around it. Do not rely on prompts to enforce permissions or state.
 
+## Task track
+
+Every task starts on a track the engine read from the request (the `Track`
+line in your context): how serious it is, and so who takes part and how much
+process it gets. Fewer steps win whenever the result is the same.
+
+- **Fast track** — a small, clear, low-risk change. No scouts, no proposal,
+  no plan document: delegate straight away with `orchestrate action=implement`,
+  opening each task with `Step N:` (the engine keeps the plan and the
+  checklist). Only the roster takes part: DESIGN for frontend work, DEV for
+  backend work, QA when the change needs tests (its worker writing and
+  running them as the last step, or the QA gate), and the researcher when a
+  decision needs outside facts (summon it first). Several domains: one
+  `implement` with `assignments`, each task stating the contract between
+  them. When the work is in, check `git diff --stat` and the report, then
+  `complete`; without QA on the roster there is no QA gate.
+- **Full workflow** — everything else: the steps below, ending with the QA
+  gate.
+
+The read is quick and can be wrong, so glance at it once and move on: confirm
+it by acting on it, or correct it with `orchestrate action=track` (`track`,
+`roster`, `reason`). Go full when the change is bigger, riskier (security,
+money, data, migrations, production) or less clear than it reads; take the
+fast track when a full-workflow task turns out small and clear (before its
+work is planned). Add a member the roster is missing, or drop one it does not
+need, before delegating. Once work is under way a track only gets stricter:
+the full workflow or more members, never QA dropped; a fast task whose worker
+asks for a dependency or an architecture change gets QA added. The user's
+`--full` and a disabled fast track keep the full workflow.
+
 ## Before implementation
 
-For feature-level work: understand the request; clarify with
+For full-workflow work: understand the request; clarify with
 `orchestrate action=clarify` when necessary; challenge it when there is a real
 technical, security, reliability, UX or maintainability concern; select and run
 relevant Scouts; review findings and target-verify important claims against the
 repository; synthesize and present a short `- ` bullet-list proposal; then wait for
-approval, amendment, or decline. Do not start feature implementation before
-approval.
-
-For a trivial, single-domain request you may skip the Scout round and the
-proposal ceremony: state the short plan, delegate the step, and verify the diff
-directly. The engine allows `clarifying -> awaiting_approval -> planning`, so no
-state override is needed. Skip only when the change is small, obvious and
-confined to one domain.
+approval, amendment, or decline. Do not start full-workflow implementation
+before approval.
 
 ## Classifier hints
 
 When the classifier is on, your task context carries a **Classifier
 triage**: a fast model's read of the request (size, the domains it touches,
 whether it needs outside research, whether it is ambiguous, its kind, likely
-files) and a suggested path. Use it to skip reasoning you do not need —
-scout only the domains it marks (0.5 or more), skip scouting when the task
-is trivial or small in one domain and likely files are named, skip the
-researcher when research is not needed, clarify only when it reads the
-request as ambiguous — and overrule it whenever the repository says
+files) and a suggested path; the task's track was chosen with it. Use it to
+skip reasoning you do not need — scout only the domains it marks (0.5 or
+more), skip the researcher when research is not needed, clarify only when it
+reads the request as ambiguous — and overrule it whenever the repository says
 otherwise. It is a hint, never a rule.
 
 When you `clarify` with options, put your recommended option first and mark
@@ -119,6 +142,14 @@ Assign work to the correct domain; never ask one domain to do another's. A
 cross-domain dependency is reported to you, and you decide whether another
 domain needs a task.
 
+Assign by where the code runs, not by how much logic it holds. Everything that
+runs in the browser — pages, components, client-side state and logic, canvas,
+WebGL/three.js scenes, shaders, client-side physics — is DESIGN's
+(Designer+Frontend); DEV (backend) owns server-side code, data, APIs and
+integrations. One file has one owner: never split a file between domains, and
+never give DESIGN only the styling of something another domain built —
+whoever builds a visual thing owns how it looks.
+
 Write the plan's steps as a numbered list under a `## Steps` heading, and open
 each `implement` task with its step number (`Step 3: ...`, or `Steps 3-4: ...`
 when one delegation covers several) so the user's checklist tracks progress
@@ -193,7 +224,8 @@ redundant, speculative or temporary information.
 
 The repository state is the source of truth; do not blindly trust Scout or
 Worker reports. There is one review, the QA gate (`orchestrate action=qa`). Run
-it once the implementation steps are complete. A `changes_required` verdict
+it once the implementation steps are complete (on the fast track, only when
+QA is on the roster and its worker is not the last step). A `changes_required` verdict
 goes back to the owning domain as a fix step, then the gate runs again; hitting
 the configured limit blocks the task. On a pass, record knowledge and continue.
 
@@ -217,9 +249,10 @@ breaks this task.
 ## Completion
 
 Only you declare completion, and only after requirements are satisfied,
-implementation is verified, required tests pass, the QA gate passes, critical
-blockers are resolved, and relevant knowledge and decisions are recorded — never
-just because a Worker says it is done.
+implementation is verified, required tests pass, the QA gate passes (on the
+fast track: QA has taken part when it is on the roster), critical blockers are
+resolved, and relevant knowledge and decisions are recorded — never just
+because a Worker says it is done.
 
 ## Architect partnership
 

package/prompts/quickfix.md

@@ -14,15 +14,28 @@ the change now, the way they would ask pi directly.
   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.
+- If the change turns out to be large (many files across the codebase, a new
+  dependency to install, an architecture change), make no edits and report
+  what it would take, so the user can plan it as a task instead. Something
+  new that lives in one place — a page, a component, a script, even a rich one
+  in a single file — is not large: it is a quick feature, so build it whole
+  and finished.
 - 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`.
 
+## Anything people look at
+
+When the request is visual (a page, a UI, a game, a canvas or three.js scene),
+how it looks is part of done: a coherent palette, real materials and lighting
+(environment lighting, soft shadows, tone mapping for 3D), proportions that
+read as the real object, framing that fills the view on phone and desktop, and
+no placeholder geometry or default grey planes left in the shot. Prefer fewer
+effects done well over many done badly. Render a frame and look at it when the
+project has a headless browser; otherwise say it was not seen.
+
 ## Other agents
 
 A bot-lobby task may be running at the same time in this working tree. Touch

package/src/agents/backend.ts

@@ -4,7 +4,7 @@ export const backendSpec: DomainSpec = {
   domain: "backend",
   promptFile: "backend.md",
   scoutFocus:
-    "API, business logic, data models, persistence, authentication/authorization, integrations, and backend reliability",
+    "server-side code: API, business logic, data models, persistence, authentication/authorization, integrations, and backend reliability",
   boundary:
-    "Stay inside backend code. Do not modify frontend implementation; report frontend requirements to the Master.",
+    "Stay inside server-side code. Do not modify browser code (pages, components, client-side logic or graphics); report frontend requirements to the Master.",
 };

package/src/agents/designer.ts

@@ -4,7 +4,7 @@ export const designerSpec: DomainSpec = {
   domain: "designer",
   promptFile: "designer.md",
   scoutFocus:
-    "UI/UX, frontend implementation, accessibility, responsive behavior, and the existing design language",
+    "UI/UX and everything that runs in the browser (pages, components, client-side logic, canvas and WebGL/three.js graphics), accessibility, responsive behavior, and the existing design language",
   boundary:
-    "Stay inside frontend/UI. Do not modify backend implementation; report backend dependencies to the Master.",
+    "Stay inside the frontend: everything that runs in the browser. Do not modify server-side code; report backend dependencies to the Master.",
 };

package/src/classifier/triage.ts

@@ -48,6 +48,15 @@ function sizeQuestion(subject: string) {
   return score(`How big is the change ${subject} asks for, judged by what it would take to build and verify in this repository?`, SIZE_LEVELS);
 }
 
+/** Whether one agent can just do it: the quick fix or the team. */
+function soloQuestion(subject: string) {
+  return noul(
+    `Could one engineer do ${subject} alone, right away — in one file or one area of the code — with no contract to agree between frontend and backend, no unfamiliar codebase to survey first, no risky change (security, data, payments, migrations) and no decision the user must make first?`,
+    "Yes: one person can just do it now, even if it is a rich piece of work in one place.",
+    "No: it needs a team — several areas, a survey of the codebase, a plan to agree, or review before it lands.",
+  );
+}
+
 export function triageRequest(input: TriageInput): SystemOneRequest {
   const questions: SystemOneRequest["questions"] = {
     size: sizeQuestion("`request`"),
@@ -62,6 +71,7 @@ export function triageRequest(input: TriageInput): SystemOneRequest {
       "No: a competent engineer could build it as written, deciding details from the codebase.",
     ),
     kind: choice("What kind of work does `request` ask for?", TRIAGE_KINDS),
+    solo: soloQuestion("`request`"),
   };
   for (const { domain, owns } of input.domains) {
     questions[`domain_${domain}`] = noul(`Does building \`request\` require changes in this area: ${owns}?`);
@@ -85,12 +95,14 @@ export async function triageTask(classifier: Classifier, input: TriageInput, sig
     if (probability !== undefined) domains[domain] = probability;
   }
   const kind = choiceOf(result.answers, "kind");
+  const solo = yesOf(result.answers, "solo");
   return {
     size: TRIAGE_SIZES[Math.max(0, Math.min(TRIAGE_SIZES.length - 1, size.level))]!,
     sizeConfidence: size.confidence,
     domains,
     research: yesOf(result.answers, "needs_research") ?? 0,
     ambiguous: yesOf(result.answers, "ambiguous") ?? 0,
+    ...(solo !== undefined ? { solo } : {}),
     ...(kind ? { kind: kind.choice, kindProbability: kind.probability } : {}),
     at: new Date().toISOString(),
   };
@@ -131,20 +143,25 @@ export async function triageWithContext(classifier: Classifier, scope: FileScope
   return files.length > 0 ? { ...triage, likelyFiles: files } : triage;
 }
 
-/** The size of a quick fix prompt, or undefined when the classifier is off or fails. */
-export async function quickFixSize(classifier: Classifier, prompt: string, signal?: AbortSignal): Promise<{ size: TriageSize; confidence: number } | undefined> {
+/**
+ * The size of a quick fix prompt, and how likely one engineer can do it alone,
+ * or undefined when the classifier is off or fails. A large prompt is held as
+ * a task unless it is still one engineer's work (a rich page in one file).
+ */
+export async function quickFixSize(classifier: Classifier, prompt: string, signal?: AbortSignal): Promise<{ size: TriageSize; confidence: number; solo?: number } | undefined> {
   if (!classifier.enabled("triage")) return undefined;
-  const largeAt = classifier.config.thresholds.quickFixLargeAt;
-  const result = await classifier.ask("triage", { state: { prompt: clip(prompt, 6000) }, questions: { size: sizeQuestion("`prompt`") } }, {
+  const { quickFixLargeAt: largeAt, quickFixAt } = classifier.config.thresholds;
+  const result = await classifier.ask("triage", { state: { prompt: clip(prompt, 6000) }, questions: { size: sizeQuestion("`prompt`"), solo: soloQuestion("`prompt`") } }, {
     ...(signal ? { signal } : {}),
     saved: (answers) => {
       const sized = scoreOf(answers, "size");
-      return sized && sized.level >= TRIAGE_SIZES.length - 1 && sized.confidence >= largeAt ? 1 : 0;
+      return sized && sized.level >= TRIAGE_SIZES.length - 1 && sized.confidence >= largeAt && (yesOf(answers, "solo") ?? 0) < quickFixAt ? 1 : 0;
     },
   });
   const size = scoreOf(result?.answers, "size");
   if (!size) return undefined;
-  return { size: TRIAGE_SIZES[Math.max(0, Math.min(TRIAGE_SIZES.length - 1, size.level))]!, confidence: size.confidence };
+  const solo = yesOf(result?.answers, "solo");
+  return { size: TRIAGE_SIZES[Math.max(0, Math.min(TRIAGE_SIZES.length - 1, size.level))]!, confidence: size.confidence, ...(solo !== undefined ? { solo } : {}) };
 }
 
 const HINT = 0.5;
@@ -155,7 +172,7 @@ export function suggestedPath(triage: TaskTriage): string {
   if (triage.ambiguous >= HINT) return "clarify first: the request as written probably misses a decision.";
   const smallish = (triage.size === "trivial" || triage.size === "small") && triage.sizeConfidence >= 0.6;
   const steps: string[] = [];
-  if (smallish && touched.length === 1) steps.push(`single-domain shortcut (${touched[0]}): skip the scout round and the proposal ceremony, state the short plan and delegate`);
+  if (smallish && touched.length === 1) steps.push(`fast track (${touched[0]}): no scouts, proposal or plan; delegate straight away`);
   else if (touched.length > 0) steps.push(`scout only ${touched.join(", ")}`);
   if (triage.research >= HINT) steps.push("summon the researcher for the outside facts");
   return steps.length > 0 ? `${steps.join("; ")}.` : "no strong signal; decide from the request.";

package/src/index.ts

@@ -2,6 +2,7 @@ import { CONFIG_DIR_NAME, type ExtensionAPI } from "@earendil-works/pi-coding-ag
 import { registerCommands } from "./pi/commands.ts";
 import { registerLifecycle } from "./pi/events.ts";
 import { registerOrchestrateTool } from "./pi/tools.ts";
+import { registerRouteTool } from "./pi/route.ts";
 import { onTransition } from "./state/task-state.ts";
 import { pingTransition } from "./pi/notify.ts";
 import { isSubagentProcess } from "./pi/quiet.ts";
@@ -26,6 +27,8 @@ export default function (pi: ExtensionAPI): void {
   onTransition((task) => pingTransition(task));
   registerCommands(pi, CONFIG_DIR_NAME);
   registerOrchestrateTool(pi, CONFIG_DIR_NAME);
+  // A new request one agent can do alone: the oracle confirms, and the lobby hands it to the quick-fix agent.
+  registerRouteTool(pi, CONFIG_DIR_NAME);
   // The questionnaire the oracle (and pi without a task) asks the user with; no other extension is needed for it.
   registerAskTool(pi);
   // The web tools, for the researcher and for pi without a task (the oracle leaves them to the researcher).

package/src/lobby/feed.ts

@@ -284,8 +284,13 @@ export function chatText(role: "user" | "assistant", text: string): Array<{ role
   const kickoff = /^A bot-lobby task is active: (\S+)\nTitle: (.*)/.exec(body);
   if (kickoff) {
     const request = /\nRequest: ([\s\S]*?)(?:\nState: |$)/.exec(body)?.[1]?.trim();
-    return [{ role: "note", text: `task started · ${kickoff[2]}` }, ...(request ? [{ role: "you" as const, text: request }] : [])];
+    // A request the oracle routed to the team is already in the conversation, under the routing note.
+    const shown = /\nRouted: /.test(body);
+    return [{ role: "note", text: `task started · ${kickoff[2]}` }, ...(request && !shown ? [{ role: "you" as const, text: request }] : [])];
   }
+  // A new request the classifier read as a quick fix, before the oracle confirms where it goes.
+  const routing = /^bot-lobby: a new request, not a task yet\.\nRequest: ([\s\S]*?)\nRead: /.exec(body);
+  if (routing) return [{ role: "you", text: routing[1]!.trim() }, { role: "note", text: "reads as a quick fix · the oracle confirms where it goes" }];
   const comment = /^The user left (?:a comment|\d+ comments) on (the approved plan|the proposal) of (\S+) from the lobby:/.exec(body);
   if (comment) return [{ role: "note", text: `your comment on ${comment[1]} went to the oracle` }];
   return [{ role: "you", text: body }];

package/src/lobby/quickfix.ts

@@ -54,6 +54,19 @@ export interface QuickFixJob {
   routedFrom?: string;
   /** Files it changed with `edit`/`write`, as shown (relative to the project); the change ledger lets a running task's QA gate tell them from its own. */
   files?: string[];
+  /** Runs on this profile instead of the quick-fix settings: a quick feature the oracle routed here gets its builder's model, thinking and time. */
+  profile?: QuickFixProfile;
+  /** The oracle sent it here from a request typed to the lobby. */
+  routed?: boolean;
+}
+
+/** How a job enters the queue besides its prompt. */
+export interface SubmitOptions {
+  /** Skip the classifier's "looks like a task" hold (the oracle already routed it here). */
+  force?: boolean;
+  profile?: QuickFixProfile;
+  /** Shown with the job: where it came from. */
+  note?: string;
 }
 
 export interface QuickFixProfile {
@@ -118,10 +131,21 @@ export class QuickFixQueue {
   }
 
   /** Queue a quick fix; it starts at once when nothing else is running. */
-  submit(prompt: string, now = Date.now()): QuickFixJob {
+  submit(prompt: string, now = Date.now(), options: SubmitOptions = {}): QuickFixJob {
     const text = prompt.trim();
     if (!text) throw new Error("a quick fix needs a prompt");
-    const job: QuickFixJob = { id: `QF-${++this.counter}`, prompt: text, status: "queued", createdAt: now, steps: [], tools: 0, turns: 0 };
+    const job: QuickFixJob = {
+      id: `QF-${++this.counter}`,
+      prompt: text,
+      status: "queued",
+      createdAt: now,
+      steps: [],
+      tools: 0,
+      turns: 0,
+      ...(options.force ? { force: true, routed: true } : {}),
+      ...(options.profile ? { profile: options.profile } : {}),
+      ...(options.note ? { note: options.note } : {}),
+    };
     this.jobs = [...this.jobs, job].filter((entry, index, all) => isActive(entry) || index >= all.length - MAX_JOBS);
     this.changed();
     this.pump();
@@ -203,7 +227,7 @@ export class QuickFixQueue {
   }
 
   private async run(job: QuickFixJob): Promise<void> {
-    const profile = this.deps.profile();
+    const profile = job.profile ?? this.deps.profile();
     const controller = new AbortController();
     this.controllers.set(job.id, controller);
     job.status = "running";
@@ -287,6 +311,8 @@ export class QuickFixQueue {
     try {
       const sized = await quickFixSize(jev, job.prompt, signal);
       if (!sized || sized.size !== "large" || sized.confidence < jev.config.thresholds.quickFixLargeAt) return undefined;
+      // Large but still one engineer's work (a rich page in one file): it runs.
+      if ((sized.solo ?? 0) >= jev.config.thresholds.quickFixAt) return undefined;
       return `looks like a task (large, ${sized.confidence.toFixed(2)})`;
     } catch {
       return undefined;

package/src/lobby/runtime.ts

@@ -26,7 +26,9 @@ import { shortTitle } from "../text.ts";
 import { isSubagentProcess } from "../pi/quiet.ts";
 import { modelRef, resolveLobbyProfile, resolvePanelProfile } from "../pi/model-support.ts";
 import { modelLookup } from "../pi/tools.ts";
-import { startPlannedTask, startTask } from "../pi/start-task.ts";
+import { startPlannedTask } from "../pi/start-task.ts";
+import { pendingRequest, setQuickFixHandoff, startRequest } from "../pi/route.ts";
+import type { Domain } from "../schemas/agent.ts";
 import type { LobbyAgentKind, LobbyPanel, PanelMember } from "../schemas/configuration.ts";
 import { chatFromEntries, lobbyFeed, narrateEvent, type AgentEventLike, type ChatEntry } from "./feed.ts";
 import { classifier, effortFor, hintsFor } from "../classifier/instance.ts";
@@ -149,9 +151,10 @@ function toOracle(state: Runtime, text: string): string | undefined {
     state.pi.sendUserMessage(text, { expandPromptTemplates: true, ...(busy ? { deliverAs: "followUp" as const } : {}) });
     return `sent ${text.split(/\s+/)[0]} to pi (built-in commands need the lobby hidden: alt+l)`;
   }
-  if (!currentZenTask()) {
-    startTask(state.pi, state.ctx, state.configDir, text).catch((error: Error) => failed(state, "could not start the task", error));
-    return "starting a task — the oracle takes it from here";
+  // While the oracle decides where a request goes, what the user types joins that conversation.
+  if (!currentZenTask() && !pendingRequest()) {
+    startRequest(state.pi, state.ctx, state.configDir, text).catch((error: Error) => failed(state, "could not start the task", error));
+    return "reading your request — a quick fix or a task, the oracle takes it from here";
   }
   state.pi.sendUserMessage(text, busy ? { deliverAs: "steer" } : undefined);
   return undefined;
@@ -706,6 +709,7 @@ function shutdown(): void {
   const state = runtime;
   if (!state) return;
   runtime = undefined;
+  setQuickFixHandoff(undefined);
   setMouse(state, false);
   state.unsubscribeFeed?.();
   state.quickfix.cancelAll();
@@ -717,6 +721,24 @@ function shutdown(): void {
   onMinimizeChange(undefined);
 }
 
+/**
+ * The oracle routed a request to the quick-fix agent: queue it (no "looks like
+ * a task" hold, the oracle already decided), on its builder's settings when it
+ * is a quick feature, and show it on the Quick fix tab.
+ */
+function handToQuickFix(state: Runtime, request: string, builder: Domain | undefined, reason: string): string {
+  const quick = lobbyProfile(state, "quickfix");
+  const profile = builder ? { ...seatProfile(state, builder), instructions: quick.instructions } : undefined;
+  const job = state.quickfix.submit(request, Date.now(), {
+    force: true,
+    ...(profile ? { profile } : {}),
+    note: `The oracle sent your request here: ${reason.replace(/[.\s]+$/, "")}.${builder ? ` A quick feature: it runs on ${builder === "designer" ? "DESIGN" : "DEV"}'s model, thinking and time limit.` : ""}`,
+  });
+  showLobby("quickfix");
+  state.view?.showQuickFix(job.id);
+  return job.id;
+}
+
 /** Create the session's lobby runtime (interactive master sessions only). */
 export function initLobby(pi: ExtensionAPI, ctx: ExtensionContext, configDir: string): void {
   shutdown();
@@ -754,6 +776,7 @@ export function initLobby(pi: ExtensionAPI, ctx: ExtensionContext, configDir: st
     effort: effortFor((model, thinking) => checkThinking(modelLookup(ctx)(model), thinking).level),
   });
   runtime = state;
+  setQuickFixHandoff((request, builder, reason) => (runtime === state ? handToQuickFix(state, request, builder, reason) : undefined));
   lobbyFeed.clear();
   // Only the newest messages are kept; the feed learns whether earlier ones exist, and loads them when scrolled to.
   lobbyFeed.seedChat(chatFromEntries(ctx.sessionManager.getBranch(), Number.POSITIVE_INFINITY));