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

package/README.md

@@ -17,7 +17,8 @@ The questionnaire and web tools are built in, so don't also install extensions w
 
 ## Use
 
-1. In Pi, run `/bot-lobby add a login page`. The lobby opens in your browser.
+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**.
 
@@ -25,6 +26,11 @@ Small changes go to **Quick fix**. `--task` forces a full task, `--fast` / `--fu
 and `--branch` / `--worktree` isolates it in git. A finished isolated task pushes its branch and tries
 to open a PR through `gh`; nothing merges on its own.
 
+After every worker step, before QA and at completion, the engine runs the project's own linter
+(ESLint, Biome, Oxlint, Ruff, or a command you set) on the files the task touched. Only problems on
+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.
+
 | Agent | Does |
 | --- | --- |
 | Oracle | Your Pi session: questions, plan, delegation and approvals |
@@ -38,7 +44,7 @@ to open a PR through `gh`; nothing merges on its own.
 The lobby is keyboard-first, and every action button shows its key (`Archive E`, `Delete Del`).
 `Alt+1`…`Alt+9` switch tabs, `j` / `k` move through lists, `/` focuses search or the message box,
 `p` switches project, `d` flips the theme and `?` lists every key. Alt and Ctrl shortcuts can be
-rebound with `lobby.keys`. In Pi, `Alt+G` toggles auto mode and `Ctrl+Shift+M` hides or restores bot-lobby.
+rebound with `lobby.keys`. In Pi, `Alt+G` toggles auto mode and `Ctrl+Shift+M` turns bot-lobby on or off.
 
 ## Screenshots
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@a-t-h-i/bot-lobby",
-  "version": "0.6.24",
+  "version": "0.6.25",
   "description": "Structured multi-agent software engineering orchestrator for Pi",
   "type": "module",
   "license": "Apache-2.0",

package/prompts/designer.md

@@ -106,6 +106,20 @@ over-animated.
 - Always honor `prefers-reduced-motion`: keep the state change, drop the
   movement.
 
+## Show the options
+
+When a visual decision is the user's to make (a layout, a screen, how a
+component looks, a direction for the whole UI), show it rather than describe
+it: ask with `ask_user_question` and give every option an `htmlPreview`, a
+static mockup of that option — HTML and CSS only (no scripts, images, fonts or
+links: the sandbox strips them), laid out for a page about 1200px wide, with
+the real content, palette and proportions of what you would build, never grey
+placeholder boxes. The user sees the focused option's mockup beside the
+question, expands it and scrolls through all the options side by side, so
+draw each option at the same fidelity. Ask before you build, and only about
+what is theirs to choose; decide the rest yourself. In the planning panel,
+draw the same mockups as fenced `mockup` blocks under your options.
+
 ## Accessibility
 
 Accessibility is a core requirement: semantic HTML first (landmarks, headings in

package/prompts/master.md

@@ -128,6 +128,15 @@ and reason about the change inside it:
 
 ## User interaction
 
+For anything the user will see (a UI request, a layout, a screen, a visual
+direction), show the choices rather than describe them. When you ask about a
+visual decision, use `ask_user_question` and give each option an
+`htmlPreview` mockup (static HTML and CSS of that option, laid out for a page
+about 1200px wide); the user expands the mockups and scrolls through the
+options side by side. When the choice needs real design work, delegate it to
+the designer, who asks with its own mockups. In planning, the panel draws
+mockups under its options the same way.
+
 Write the proposal as a short `- ` bullet list, one line per change, so the user
 can see what will be done at a glance; do not dump the internal plan unless
 asked. If the user
@@ -331,6 +340,15 @@ more round, or leave it blocked); never loop QA past that on your own. When the
 user tells you to finish although QA has not passed, call `action=complete`:
 the engine asks them to confirm, then completes the task.
 
+The engine also lints the files this task's agents touched, after every
+step, before QA and at completion, and adds a **Lint** line to the report.
+Only problems on lines the task changed count. Send the new ones to the domain
+that touched the file, as a fix step that fixes the cause and never silences
+the rule. In block mode new lint errors hold completion until they are fixed
+or the user accepts the work as it is (`/bot-lobby accept`); in advise mode
+mention what is left to the user. When lint could not run, say so; it holds
+nothing.
+
 Not every change in the tree is this task's. Worker and QA reports end with
 who changed each file, from bot-lobby's record of every agent's edits:
 **planned** (this task's workers), **quick fix** (the user's own direct

package/prompts/panel.md

@@ -31,6 +31,15 @@ questions and the user's answers, and the oracle's current draft plan.
   repository, put that option first with `(Recommended)` after its label. The
   user can always type their own answer instead, so do not add an "Other"
   option.
+- When a question is about something the user will see (a layout, a
+  screen, a component's look, a flow, a visual direction), draw it: under
+  each option put a fenced `mockup` block with a mockup of that option —
+  static HTML with a `<style>` element (no scripts, images, fonts or links:
+  the sandbox strips them), laid out for a page about 1200px wide, at most
+  30,000 characters. Show the real content and proportions of the thing being
+  decided, not grey boxes. The user sees each as a
+  thumbnail beside the question and expands them to scroll through the
+  options side by side. DESIGN draws for every visual question; any seat may.
 - Read the draft's Assumptions: if one the oracle made for your seat is
   wrong, say so under Notes and ask about it again.
 - If an answer from the user is vague or conflicts with what you see in the
@@ -49,10 +58,21 @@ OPEN or READY
 1. The question, ending with a question mark?
    - Short label — what choosing it means
    - Another label — what choosing it means
+2. A question about what the user will see?
+   - Short label — what choosing it means
+     ```mockup
+     <style>…</style>
+     <div class="page">…</div>
+     ```
+   - Another label — what choosing it means
+     ```mockup
+     …
+     ```
 
 (Two to four options per question, labels of one to five words, no
 recommendation unless the answer is quite obvious, and then only that option
-carries `(Recommended)`. Omit Questions when READY.)
+carries `(Recommended)`. A `mockup` block goes under the option it shows.
+Omit Questions when READY.)
 
 ## Notes
 - …

package/prompts/planner.md

@@ -35,6 +35,15 @@ below.
   quite obvious from the conversation or the repository, put that option first
   with `(Recommended)` after its label. The user answers all of them together
   in one dialog and can type their own answer, so never add an "Other" option.
+- Show what the user will see. A member's option marked `[mockup]` has a
+  mockup drawn for it: keep that option's label when you relay the question
+  and the mockup goes with it (you need not repeat it). A visual question of
+  your own (a layout, a screen, a flow) gets a fenced `mockup` block under
+  each option, as below: static HTML with a `<style>` element (no scripts, images, fonts or links:
+  the sandbox strips them), laid out for a page about 1200px wide, at most
+  30,000 characters. Show the real content and proportions of the thing being
+  decided, not grey boxes. The user
+  expands the mockups and scrolls through the options side by side.
 - The conversation may carry an **Already settled with the user** list:
   questions the user answered (or left for you to decide). They are closed in
   any wording, so never ask one again, not even rephrased; fold the answer
@@ -81,7 +90,14 @@ Three to six words naming the task.
 1. [DEV] The most important open question?
    - Short label — what choosing it means
    - Another label — what choosing it means
-2. …
+2. [DESIGN] A question about what the user will see?
+   - Short label — what choosing it means
+     ```mockup
+     <style>…</style>
+     <div class="page">…</div>
+     ```
+   - Another label — what choosing it means
+3. …
 
 (At most four questions, each tagged with its seat; two to four options per
 question, labels of one to five words, `(Recommended)` only on an obvious one. Omit the Questions section when READY

package/prompts/qa.md

@@ -30,11 +30,31 @@ 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.
+
+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`.
+
 ## Write as few tests as possible
 
-Tests cost tokens and add upkeep, so the default is to write none. Run the
-project's existing tests for what the change touches and judge them; do not add
-to them to look thorough.
+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.
 
 Write a new test only when one of these holds, and say which in your report:
 

package/prompts/quickfix.md

@@ -25,6 +25,10 @@ the change now, the way they would ask pi directly.
   servers, watchers or background processes.
 - Change files with `edit`/`write`, never through shell redirection or
   `sed -i`.
+- The engine lints the files you touched when you finish and shows the user
+  what it finds on the lines you changed. Run the project's linter on them
+  first and fix what it finds; never silence a rule with a disable comment or
+  a config change.
 
 ## Anything people look at
 

package/prompts/reviewer.md

@@ -18,6 +18,23 @@ Review requirements, the approved plan, the actual diff, affected files, tests,
 security, accessibility where relevant, error handling, reliability,
 performance where relevant, maintainability, and scope discipline.
 
+## Lint
+
+When your context has a Lint section, the engine ran the project's linter on
+the files this task touched. Problems on lines the task changed are the
+task's; what was already there is not. A lint pass is evidence, not
+acceptance, and a lint failure in block mode already holds completion, so
+report it only when it shows a real defect. The section also lists every lint
+suppression and lint-config change the task added. Judge each one: a disable
+comment, ignore entry or loosened rule without a reason that holds (in a
+comment beside it, or the worker's report) is a `major` finding, and so is
+code removed or bent only to satisfy a rule. You cannot edit, so name the file
+and line and say what the fix should be.
+
+When the change is trivial or non-destructive, the engine's lint result and a
+typecheck are enough executed checks for a PASS; cite them under
+Verification (`- engine lint on the touched files — no new problems`).
+
 ## Change provenance
 
 The working tree can hold changes that are not this task's: the user makes

package/prompts/worker.md

@@ -30,18 +30,33 @@ section of your output instead and continue with the rest of the work.
 
 ## Testing
 
-Run the targeted tests for what you changed (the files and behavior you
-touched); the QA gate runs the full suite afterwards. Write as few tests as
-possible: add one only for a breaking change, for a bug fix whose regression
-would be silent, or for behavior that could turn out unpredictable (concurrency,
-ordering, time, untrusted input), or when your brief asks for tests. Never pad
-a change with tests for the sake of coverage.
+Run only the targeted checks for what you changed: the typecheck of the
+touched package and the nearest tests for the files you touched; QA decides
+whether more is needed. A trivial or non-destructive change (copy, styling,
+layout, docs, a config value) needs the typecheck and the linter, no tests.
+Write as few tests as possible: add one only for a breaking change, for a bug
+fix whose regression would be silent, or for behavior that could turn out
+unpredictable (concurrency, ordering, time, untrusted input), or when your
+brief asks for tests. The linter and the type checker already catch unused
+code, wrong types, hook rules and style, so never write a test for what they
+catch. Never pad a change with tests for the sake of coverage.
 
 - Always pass a bash `timeout` to tests and builds (for example 300 seconds).
 - Never start dev servers, watch mode or other long-running processes, and
   never leave background processes behind.
 - Change files with `edit`/`write`, not through shell redirection or `sed -i`.
 
+## Lint
+
+After every step the engine lints the files you touched with the project's
+own linter and reports what it finds on the lines you changed. Run that linter
+on your files before you report, and fix what it finds at the cause. Never
+silence it: no new disable comments (`eslint-disable`, `@ts-ignore`, `noqa`,
+`biome-ignore` and the like), no loosened rules, ignore lists or lint config,
+no code deleted or bent just to make a rule pass. Every one of them is listed
+for QA, who reads it as a finding unless it carries a reason that holds. When
+a rule is wrong for your change, leave it failing and say why under Notes.
+
 ## Time budget
 
 Work efficiently: read what you need, make the change, verify, report. If the

package/src/ask/tool.ts

@@ -22,9 +22,9 @@ export { ASK_TOOL };
 
 const OptionSchema = Type.Object({
   htmlPreview: Type.Optional(Type.Object({
-    html: Type.String({ maxLength: MAX_PREVIEW_HTML }),
+    html: Type.String({ maxLength: MAX_PREVIEW_HTML, description: "Static HTML of a mockup of this option; scripts, images, fonts and links are stripped." }),
     css: Type.Optional(Type.String({ maxLength: MAX_PREVIEW_CSS })),
-  }, { additionalProperties: false })),
+  }, { additionalProperties: false, description: "A static HTML/CSS mockup of this option, laid out for a page about 1200px wide: shown as a thumbnail beside the question, which the user expands to scroll through every option's mockup. Give one to every option of a visual question (a layout, a screen, a component's look)." })),
   label: Type.String({ maxLength: MAX_LABEL, description: `The option as the user sees and picks it: 1-5 words, at most ${MAX_LABEL} characters.` }),
   description: Type.Optional(Type.String({ description: "What choosing it means: its trade-offs or consequences. Markdown." })),
   preview: Type.Optional(Type.String({ description: "Markdown shown beside the options while this one is focused: a mockup, a code snippet, a diagram, a config. Only when seeing it helps the user compare." })),
@@ -45,7 +45,7 @@ export const AskParams = Type.Object({
 const DESCRIPTION = [
   "Ask the user one to four questions with options to pick from, when the answer would change what you do and you would otherwise guess.",
   "Each question has 2-4 options in a neutral order, with no recommendation (mark one \"(Recommended)\", first, only when the answer is quite obvious); the user can pick one (or several with multiSelect), or answer in their own words.",
-  "Questions, descriptions and previews are Markdown. Give options a `preview` when the user needs to see them to choose: a UI mockup, a layout sketch, a code snippet, a config; the focused option's preview shows beside the list. An option can also carry an `image` file (a screenshot, a rendered mockup).",
+  "Questions, descriptions and previews are Markdown. For anything the user will see (a layout, a screen, a component's look), give every option an `htmlPreview`: a static HTML/CSS mockup the user can expand and scroll through side by side with the others. Give options a Markdown `preview` for a code snippet, a config or a text sketch; the focused option's preview shows beside the list. An option can also carry an `image` file (a screenshot, a rendered mockup).",
   "Do not use it for yes/no confirmations of what you were already told to do, or for questions the conversation already answers.",
 ].join(" ");
 

package/src/delivery/review.ts

@@ -10,7 +10,7 @@ import { readRules, type Rules } from "./rules.ts";
 import type { DeliveryContext } from "./transport.ts";
 
 export function localVerified(task: Task): boolean {
-  return task.state === "completed" && !task.qaWaiver && completionBlockers(task, pendingApprovals(task).length).length === 0
+  return task.state === "completed" && !task.qaWaiver && !task.lintWaiver && completionBlockers(task, pendingApprovals(task).length).length === 0
     && (!qaRequired(task) || task.qaVerdict === "pass");
 }
 export function newDelivery(task: Task, project: string): Delivery {

package/src/execution/git.ts

@@ -31,6 +31,15 @@ export async function headCommit(cwd: string): Promise<string | undefined> {
   }
 }
 
+/** The repository's top folder, or undefined (no git, not a repository). */
+export async function repositoryTop(cwd: string): Promise<string | undefined> {
+  try {
+    return (await git(cwd, ["rev-parse", "--show-toplevel"])) || undefined;
+  } catch {
+    return undefined;
+  }
+}
+
 /** The newest commit on HEAD made before `iso` (where a task started), or undefined. */
 export async function commitBefore(cwd: string, iso: string): Promise<string | undefined> {
   try {
@@ -137,3 +146,71 @@ export async function changedFiles(cwd: string, base?: string): Promise<{ top: s
     return undefined;
   }
 }
+
+/** What a set of files gained since a commit: which files are new, which lines changed, and the text added. */
+export interface AddedLines {
+  /** Files new since `base` (untracked, or added): every line of them is new. */
+  whole: Set<string>;
+  /** Line numbers, in each file as it stands now, added or changed since `base`. */
+  lines: Map<string, Set<number>>;
+  /** The added text, line by line, bounded. */
+  text: Array<{ file: string; line: number; text: string }>;
+}
+
+/** Most added lines kept as text; line numbers stay whole. */
+const MAX_ADDED_TEXT = 20_000;
+
+/**
+ * The lines `files` (repository-relative, under `top`) gained since `base`
+ * (HEAD when absent): from `git diff -U0`, plus every line of an untracked
+ * file. Undefined when git cannot say, so callers treat every line as new.
+ */
+export async function addedLines(top: string, base: string | undefined, files: readonly string[]): Promise<AddedLines | undefined> {
+  if (files.length === 0) return { whole: new Set(), lines: new Map(), text: [] };
+  try {
+    const [diff, untracked] = await Promise.all([
+      run("git", ["-c", "core.quotePath=false", "diff", "-U0", "--no-color", "--no-ext-diff", base ?? "HEAD", "--", ...files], { cwd: top, maxBuffer: MAX_BUFFER }).then((result) => result.stdout),
+      run("git", ["ls-files", "--others", "--exclude-standard", "-z", "--", ...files], { cwd: top, maxBuffer: MAX_BUFFER }).then((result) => result.stdout),
+    ]);
+    const out: AddedLines = { whole: new Set(), lines: new Map(), text: [] };
+    let file: string | undefined;
+    let at = 0;
+    for (const line of diff.split("\n")) {
+      if (line.startsWith("+++ ")) {
+        const path = line.slice(4).replace(/^"|"$/g, "");
+        file = path === "/dev/null" ? undefined : path.replace(/^b\//, "");
+        continue;
+      }
+      const hunk = /^@@ -\d+(?:,\d+)? \+(\d+)(?:,(\d+))? @@/.exec(line);
+      if (hunk) {
+        at = Number(hunk[1]);
+        const count = hunk[2] === undefined ? 1 : Number(hunk[2]);
+        if (file && count > 0) {
+          const set = out.lines.get(file) ?? new Set<number>();
+          for (let number = at; number < at + count; number += 1) set.add(number);
+          out.lines.set(file, set);
+        }
+        continue;
+      }
+      if (file && line.startsWith("+") && !line.startsWith("+++")) {
+        if (out.text.length < MAX_ADDED_TEXT) out.text.push({ file, line: at, text: line.slice(1) });
+        at += 1;
+      }
+    }
+    for (const path of untracked.split("\0").filter(Boolean)) {
+      out.whole.add(path);
+      try {
+        const full = join(top, path);
+        if (statSync(full).size > MAX_NEW_FILE_BYTES) continue;
+        const content = readFileSync(full, "utf8");
+        if (content.includes("\0")) continue;
+        content.split("\n").forEach((text, index) => { if (out.text.length < MAX_ADDED_TEXT) out.text.push({ file: path, line: index + 1, text }); });
+      } catch {
+        // Unreadable: its lines still count as new.
+      }
+    }
+    return out;
+  } catch {
+    return undefined;
+  }
+}