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

package/README.md

@@ -17,14 +17,22 @@ 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**.
+   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
 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 +46,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.26",
   "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/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
@@ -160,10 +169,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
 
@@ -219,9 +233,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.
@@ -331,6 +345,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
@@ -90,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
@@ -99,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

@@ -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/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);

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/agent-runner.ts

@@ -380,21 +380,3 @@ export async function mapConcurrent<TIn, TOut>(items: TIn[], limit: number, fn:
 export async function runParallel(requests: AgentRequest[], limit: number, run: ProcessRunner = spawnPiProcess): Promise<AgentRun[]> {
   return mapWithConcurrencyLimit(requests, limit, (request) => runAgent(request, run));
 }
-
-function lastOutput(results: AgentRun[]): string {
-  return results.length > 0 ? results[results.length - 1]!.output : "";
-}
-
-/** Run agents in order, substituting `{previous}` with the prior output. */
-export async function runSequential(requests: AgentRequest[], run: ProcessRunner = spawnPiProcess): Promise<AgentRun[]> {
-  const results: AgentRun[] = [];
-  for (const request of requests) {
-    const instruction = request.instruction.includes("{previous}")
-      ? request.instruction.replaceAll("{previous}", lastOutput(results))
-      : request.instruction;
-    const result = await runAgent({ ...request, instruction }, run);
-    results.push(result);
-    if (result.status !== "success") break;
-  }
-  return results;
-}

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;
+  }
+}