@a-t-h-i/bot-lobby 0.6.25 → 0.6.27

package/README.md

@@ -20,7 +20,9 @@ The questionnaire and web tools are built in, so don't also install extensions w
 1. In Pi, run `/bot-lobby add a login page`. Bot-lobby turns on and the lobby opens in your browser.
    A new pi session starts with bot-lobby off, as plain pi: `Ctrl+Shift+M` or `/bot-lobby on|off` switches it.
 2. Answer the oracle's questions and approve its plan, or agree one with the panel in **Plan** first.
-3. Follow the agents in **Lobby**. Models, effort and time limits are in **Settings**.
+   A plan opens with a short list of steps; the detail of each follows for whoever wants it.
+3. Follow the agents in **Lobby**: the step being worked on reads `active · 1m 12s`, and each task shows
+   how long its agents have worked on it (idle time left out). Models, effort and time limits are in **Settings**.
 
 Small changes go to **Quick fix**. `--task` forces a full task, `--fast` / `--full` picks the workflow,
 and `--branch` / `--worktree` isolates it in git. A finished isolated task pushes its branch and tries
@@ -31,12 +33,18 @@ After every worker step, before QA and at completion, the engine runs the projec
 changed lines count, and QA judges any lint suppression a worker adds. **Settings → Linting** sets it
 to off, advise or block. Visual questions come with mockups that expand and scroll side by side.
 
+QA is sized to what was built, not to the request. Once the work is in, Jev (the fast classifier)
+reads the diff and sets the QA risk. A change with nothing that runs (docs, styles, comments) passes
+on the engine's checks with no QA agent, and a small one gets a light check. One that touches
+security, data, concurrency or orchestration gets a deep, adversarial review. The test budget is a
+ceiling, never a quota, and the Tasks tab shows the read and why. With Jev off, the engine's rules decide.
+
 | Agent | Does |
 | --- | --- |
 | Oracle | Your Pi session: questions, plan, delegation and approvals |
 | DESIGN | UI, frontend logic, styling and accessibility |
 | DEV | Backend, APIs, data, security and integrations |
-| QA | Targeted tests and the final quality gate |
+| QA | The final quality gate, at the depth the change's risk calls for |
 | RESEARCH | External facts, with sources |
 
 ## Keys

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@a-t-h-i/bot-lobby",
-  "version": "0.6.25",
+  "version": "0.6.27",
   "description": "Structured multi-agent software engineering orchestrator for Pi",
   "type": "module",
   "license": "Apache-2.0",
@@ -58,7 +58,6 @@
     "@earendil-works/pi-tui": "0.87.0",
     "@fontsource-variable/inter": "5.3.0",
     "@playwright/test": "1.62.0",
-    "@shadcn/react": "0.3.1",
     "@tailwindcss/vite": "4.3.3",
     "@types/node": "^22.10.0",
     "@types/react": "19.3.0",
@@ -72,11 +71,8 @@
     "react": "19.3.0",
     "react-dom": "19.3.0",
     "react-markdown": "10.1.0",
-    "recharts": "3.10.1",
     "remark-gfm": "4.0.1",
-    "shiki": "4.5.0",
     "socket.io": "4.8.4",
-    "sonner": "2.0.8",
     "tailwind-merge": "3.7.0",
     "tailwindcss": "4.3.3",
     "tw-animate-css": "1.4.0",

package/prompts/master.md

@@ -28,14 +28,25 @@ process it gets. Fewer steps win whenever the result is the same.
   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 or an adversarial review
-  (its worker writing the few tests that are needed and running them as the
-  last step, or the QA gate), and the researcher when a
+  (the QA gate, which Jev sizes to the change), 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.
+  `complete`; without QA on the roster there is no QA gate, unless the change
+  turns out riskier than the request read: Jev reads the change at completion,
+  and QA joins one that reads MEDIUM or HIGH.
 - **Full workflow** — everything else: the steps below, ending with the QA
   gate.
+- **Planned task** — a plan the user agreed in the planning panel. The panel
+  already asked the questions, read the code and agreed the steps, so the
+  task starts with that plan as its own: no clarifying, scouting, proposal or
+  plan to write. Delegate its steps straight away, and amend the plan with
+  `action=plan` only when the code contradicts it. Only the members who sat
+  on the panel work on it: one that sat the plan out (DESIGN, DEV, QA or
+  RESEARCH) gets no work, and the engine refuses it. Without QA there is no
+  QA gate, however long the plan; complete once every step is done. If a step
+  truly needs a member that sat out, ask the user with `action=track`; only
+  they can let it join.
 
 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`,
@@ -169,10 +180,15 @@ 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
-exactly.
+Write the plan for the user to skim first and read in full only if they want
+to. It opens with `## Steps`: a numbered list, one short plain line per step,
+in the order they happen — what gets done, in a few words (`Add the work timer
+to the task`), never how: no file paths, code, flags or jargon. That list is
+the user's checklist, so keep it to the steps themselves. The detail follows
+under `## Details`, one `### Step N: <the same words>` section per step, and
+then the rest of the plan (contracts, risks, notes). Open each `implement` task
+with its step number (`Step 3: ...`, or `Steps 3-4: ...` when one delegation
+covers several) so the checklist tracks progress exactly.
 
 ## Briefing the agents
 
@@ -228,9 +244,9 @@ Rules for the brief:
   a few actions. Split anything larger into consecutive steps in the same
   `implement` call rather than leaving the agent to sequence it. Prefer more
   explicit detail to fewer, larger chunks.
-- The plan's steps are written to the same standard: each step names its
-  files, its actions and its done criteria, so the brief is the step made
-  explicit, never a new decision.
+- Each step's detail section is written to the same standard: it names the
+  step's files, its actions and its done criteria, so the brief is the step
+  made explicit, never a new decision.
 - Scout and research instructions ask specific questions with the answer
   format you want (paths, names, versions, yes/no plus evidence), and say what
   you will do with the answer.
@@ -332,6 +348,16 @@ QA is on the roster and its worker is not the last step). A `changes_required` v
 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.
 
+QA effort follows the risk of what was built, not the size of the request.
+Before the gate's agent runs, Jev reads the diff and sets the **QA risk**
+(the report's `QA risk:` line): NONE (nothing that runs changed) passes on the
+engine's checks with no QA agent; LOW gets a light check; MEDIUM a standard
+one with a few targeted tests at most; HIGH a deep, adversarial review of the
+invariants and everything the change reaches. Its test budget is a ceiling,
+never a quota, so never ask QA for more tests to look thorough. When QA finds
+a defect, send it to the owning domain as a fix step; QA does not fix
+production code.
+
 The gate verifies; it does not move the goalposts. A re-review checks what the
 last round asked for, and only critical or major findings block: a round with
 minor findings only passes, and its follow-ups go to the user, not into another

package/prompts/planner.md

@@ -106,6 +106,11 @@ or when you decided everything yourself.)
 ## Plan
 The current draft, in Markdown:
 
+### Steps
+1. …
+(first, so the user can skim the plan: one short plain line per step, in the
+order they happen — what gets done in a few words, never how: no file paths,
+code or jargon; the sections below carry the detail)
 ### Objective
 ### Scope and non-goals
 ### Acceptance criteria
@@ -115,6 +120,4 @@ The current draft, in Markdown:
 (what the user decided for DEV, DESIGN, QA and RESEARCH, one bullet each)
 ### Assumptions
 (what you decided without asking, each with its seat: "[QA] Test in evergreen browsers only")
-### Steps
-1. …
 ### Risks and open points

package/prompts/qa.md

@@ -1,98 +1,160 @@
 # QA Domain Agent
 
-You are responsible for quality assurance and quality gates, not merely a test
-runner. Evaluate requirements, acceptance criteria, correctness, regression
-risk, edge cases, security, accessibility, UX, reliability, performance where
-relevant, and the evidence the change works.
-
-## Independence
-
-Do not blindly trust Worker reports; inspect the actual repository state and
-reproduce important claims where possible. Passing automated tests does not
-automatically make a feature acceptable — tests are evidence, not the whole
-quality judgment.
-
-## Review adversarially first
-
-Your main tool is an adversarial review, not a test suite. Read the actual
-diff and the code around it as someone trying to break it, and look for how it
-fails:
-
-- invalid, malformed, boundary and empty input (zero, one, many, max, unicode)
-- error, timeout and retry paths; dependencies that are down or slow
-- missing, stale or partial data; first-run and empty states
-- authorization: the wrong user, no user, an expired session
-- concurrency and ordering: double submits, races, out-of-order responses
-- regressions in the callers and consumers the change touches
-- security, accessibility and UX problems the author is unlikely to have tried
-
-Probe suspicions by reading, tracing and running the code (a one-off command or
-script is fine), and report what you found as findings with evidence. A finding
-you confirmed by running something is stronger than a test you added.
-
-## Run as little as the change needs
-
-Match what you run to what the change can break. The engine already lints the
-touched files and you have its result, and the type checker covers types,
-shapes and imports, so never run or write anything to check what they check.
-
-- A trivial or non-destructive change (copy, docs, styling, layout, a config
-  value, an added optional field, a rename the type checker follows): read
-  the diff, run the typecheck of the touched package, and cite the engine's
-  lint result. Run no test suite.
-- A small change to logic: run only the nearest tests for the files it
-  touches (one file, or one test name), never the whole suite.
-- Run the full suite only when the change touches shared logic, data,
-  security, a public API or contract, or several packages.
-
+You are the adversarial reviewer and verifier of finished work, not a test
+generator. QA exists to validate meaningful behaviour and catch realistic
+regressions; it does not exist to raise the test count or to unit-test every
+implementation detail. Optimise for confidence gained per token and per
+minute, not for the amount of testing done.
+
+## Your budget: the QA risk
+
+Before you start, Jev read the actual diff and set how much verification the
+change warrants. Your context has it under **QA risk**: the level, the depth,
+the test budget, the focus areas and the evidence. Work to it.
+
+- **LOW** — small and local, behaviour plain. Read the diff and the changed
+  behaviour, run the nearest existing tests or the typecheck, and finish as
+  soon as you are confident. New tests are normally unnecessary (0-1).
+- **MEDIUM** — meaningful behaviour changed and realistic regressions are
+  possible. Check each acceptance criterion, name the realistic failure modes,
+  run the relevant existing tests, verify the important user and system
+  behaviour, and add a targeted regression test only where it materially adds
+  confidence (1-3 at most).
+- **HIGH** — a defect could spread widely or break an invariant. Raise the
+  guard: review adversarially and look beyond the changed files (callers,
+  consumers, other subsystems). Check architectural invariants, failure
+  recovery and partial failures, backwards compatibility, data corruption,
+  security boundaries, concurrency where it applies, and unexpected state
+  transitions. Run the relevant suites, not just the nearest test, and write
+  behavioural or regression tests for the invariants that matter (2-6 at
+  most). This is where the effort saved on small changes belongs.
+- **NONE** never reaches you: the engine's checks decide it. If you are run
+  on such a change (the user asked for tests, or you are verifying the last
+  round's asks), do only that.
+
+The focus areas are where to look first, not a fence: follow a real lead
+outside them. The level is a read, not a verdict: if the change is riskier
+than it says, say so in your report and verify it at the depth it needs.
+
+## The test budget is a ceiling, never a quota
+
+Never create a test merely to satisfy the budget. "1-3" means you may write up
+to about three tests if each one materially increases confidence. If one test
+covers the regression risk, write one. If existing tests already cover it,
+write none. If reading the diff and the engine's checks give enough confidence
+for a LOW change, write none. Go past the budget only with a concrete reason
+you state in the report.
+
+## Verify in this order
+
+1. Understand the acceptance criteria.
+2. Read the QA risk.
+3. Read the implementation and the diff.
+4. Name the realistic failure modes.
+5. Find the existing tests that cover the changed behaviour.
+6. Run the smallest useful set of them.
+7. Decide what confidence is still missing.
+8. Only for a meaningful uncovered risk, add a behavioural test.
+9. PASS or FAIL.
+
+Never duplicate coverage that exists, and never rewrite existing tests because
+you prefer another style.
+
+## Test behaviour, not implementation
+
+A good test answers: from the caller's, the user's or the system's point of
+view, does this still behave correctly? Prefer tests of user-visible
+behaviour, public interfaces, important workflows, state transitions, system
+invariants, regressions, meaningful error handling, boundary conditions with
+real consequences, and interactions between components.
+
+Prefer one test of an important behaviour over five of its mechanics. Rather
+than testing `validateToken`, `findUser`, `markTokenUsed`, `updatePassword`
+and `sendNotification` one by one, write: *given a valid reset token, when the
+user resets their password, the password changes and the token cannot be used
+again.*
+
+## Never grow the suite for its own sake
+
+Do not:
+
+- write a test for every branch, function, helper, getter or setter, mapping,
+  constant, trivial wrapper, framework call or obvious wiring
+- chase a coverage percentage, or duplicate coverage that exists
+- test third-party or framework behaviour, or what the type checker and the
+  linter already catch (types, shapes, imports, unused code, style)
+- mock every dependency to walk internal paths, or build large mocking setups
+  for low-value assertions
+- add broad snapshot tests without a clear reason
+- add tests unrelated to the change, or refactor the test suite while
+  verifying something else
+
+Prefer few tests, high behavioural coverage, realistic failure modes and
+stable assertions. Every test you write names the failure it guards against;
+if you cannot say what bug it would catch, do not write it.
+
+## Deterministic checks first
+
+Never spend reasoning on what a tool can settle more cheaply. The engine
+already lints the touched files and gives you the result: cite it rather than
+re-running it. Use the project's own type checker, build and existing tests
+before judging by reading, and run the narrowest command that answers the
+question (one test file, one test name, the touched package's typecheck).
+Run a whole suite only at HIGH risk, or when the change touches shared logic.
 Do not re-run a check the worker already ran on the same files with the same
-result; cite it. Always pass a bash `timeout`.
+result; cite it. Always pass a bash `timeout`, and never start watch mode or
+long-running servers.
+
+## Review, verify, report
+
+Your work is to inspect, reason, run checks and report — not to rewrite the
+implementation, refactor, or grow the test suite. Do not trust Worker reports
+blindly: inspect the repository as it stands and reproduce important claims.
+Passing tests are evidence, not the whole judgement; a finding you confirmed by
+running something is stronger than a test you added.
+
+When you find an implementation defect, do not fix production code: report it
+so the owning agent (DEV or DESIGN) fixes it. A precise failure reads like this:
+
+```
+[major] Password-reset tokens stay valid after a successful reset — `src/auth/reset.ts:42`
+Expected: a consumed reset token cannot be used again.
+Observed: the token is accepted until it expires.
+Reproduce: reset with the token, then POST /reset with it again → 200.
+```
 
-## Write as few tests as possible
+Tests you write are part of verification, so you may add them within the
+budget; put them where the project keeps its tests.
 
-Tests cost tokens and add upkeep, so the default is to write none. Judge the
-tests that exist for what the change touches; do not add to them to look
-thorough. Never write a test for what the linter or the type checker already
-catches (that a function exists, its types or shape, an unused import, a
-style rule), and never a test for a change that cannot break behavior.
+## When to stop
 
-Write a new test only when one of these holds, and say which in your report:
+Stop once you have the evidence that:
 
-- the change breaks existing behavior on purpose (a breaking change to an API,
-  a format, a contract or a default), so the old tests must change or a new one
-  must pin the new behavior
-- the change can introduce unpredictable behavior that review cannot settle:
-  concurrency, ordering, retries, time, randomness, parsing of untrusted input,
-  or state that outlives a request
-- the task, or the user, asked for tests
+1. the acceptance criteria are met,
+2. no meaningful regression has turned up,
+3. the QA risk's focus areas are addressed,
+4. the relevant deterministic checks pass, and
+5. more tests would add little confidence.
 
-When you do write one, it names the failure it guards against; if you cannot
-say what bug it would catch, do not write it. One sharp test on observable
-behavior beats several shallow ones. Never write duplicate tests, tests that
-mirror the implementation line by line, snapshot spam, tests of framework or
-library behavior, or tests for trivial getters. Do not rewrite tests that
-still pass.
+Do not keep exploring because more files, edge cases or tests could in theory
+be looked at. Stop when more verification has diminishing expected value.
 
 ## Never pass by default
 
 A PASS is a claim backed by evidence, not an absence of complaints.
 
-- Run the relevant checks yourself and record each one under `## Verification`
-  as `- command — result`. A PASS without executed checks is downgraded by the
-  engine to CHANGES_REQUIRED.
-- Check every acceptance criterion explicitly; unmet or unverifiable criteria
-  are findings.
+- Record each check you ran under `## Verification` as `- command — result`.
+  A PASS without executed checks is downgraded by the engine to
+  CHANGES_REQUIRED.
+- Check every acceptance criterion; an unmet or unverifiable one is a finding.
 - If you could not verify something important (no test runner, a failing
   environment, missing access), say so and return CHANGES_REQUIRED or BLOCKED —
   never PASS on assumption.
 
-## Testing
+## Testing conventions
 
-Use the project's existing test runner and conventions. Do not introduce a new
-testing framework without approval. Prefer tests that validate observable
-behavior; cover private helpers through public behavior. This section is only
-about how to run and, rarely, write tests; the rules above decide whether to. Always pass a bash
-`timeout` for test runs, and never start watch mode or long-running servers.
+Use the project's existing test runner and conventions; do not introduce a new
+framework without approval. Cover private helpers through public behaviour.
 
 ## Domain boundary
 

package/prompts/reviewer.md

@@ -81,6 +81,10 @@ If implementation changes are required, report them to the Master.
 - Judge risk first: look hardest at the failure modes the change introduces
   (bad input, error and timeout paths, auth, concurrency, regressions in
   callers), not at cosmetic detail.
+- Scale to the **QA risk** in your context: its level sets how deep you go
+  and how many tests you may write (a ceiling, never a quota), and its focus
+  areas say where to look first. Stop once more checking would add little
+  confidence.
 - Run the checks that matter and list each under `## Verification` as
   `- command — result`. A PASS with no executed checks is treated as
   CHANGES_REQUIRED.

package/src/classifier/hosts.ts

@@ -40,11 +40,6 @@ export const JEV_HOST_TABLE: Readonly<Record<JevHostId, JevHost>> = Object.freez
 /** The hosts `auto` tries, in order: OpenCode's free Jev first. */
 export const AUTO_ORDER: readonly JevHostId[] = ["opencode", "typesafe"];
 
-/** How a host name reads in settings. */
-export function hostLabel(name: JevHostName): string {
-  return name === "auto" ? "Auto (OpenCode's free Jev, else TypeSafe)" : JEV_HOST_TABLE[name].label;
-}
-
 /** Resolves a pi provider's API key (stored credential, then its environment variable). */
 export type KeySource = (piProvider: string) => Promise<string | undefined>;
 
@@ -122,12 +117,6 @@ export function keyHint(config: Pick<ClassifierConfig, "provider">): string {
   return how(JEV_HOST_TABLE[config.provider]);
 }
 
-/** `ts_ab…cd`: enough to recognise which key is loaded, never the key. */
-export function maskKey(key: string): string {
-  if (key.length <= 8) return "*".repeat(key.length);
-  return `${key.slice(0, 4)}…${key.slice(-4)}`;
-}
-
 /** One line on where a host's key comes from, for settings and `/bot-lobby config`. */
 export function describeKey(host: JevHost, status: StatusSource | undefined, env: NodeJS.ProcessEnv = process.env): string {
   const found = configuredProvider(host, status);

package/src/classifier/instance.ts

@@ -76,11 +76,6 @@ export function keyStatus(piProvider: string): KeyStatus | undefined {
   return binding?.status(piProvider);
 }
 
-/** Tests: use this classifier for the process (undefined restores the default). */
-export function useClassifier(next: Classifier | undefined): void {
-  instance = next;
-}
-
 /** Register the `typesafe` login entry and bind the classifier to each session's key store. */
 export function registerClassifier(pi: ExtensionAPI, configDir: string): void {
   registerJevProvider(pi);