@aragon-agent/cli 0.6.34 → 0.6.36

package/dist/todo/plan-sections.d.ts

@@ -0,0 +1,60 @@
+/**
+ * The rail's two-section row allocation (todo-acceptance-criteria §6.9.2).
+ *
+ * ASCII ONLY: `src/todo/**` is inside the glyph scanner's scope.
+ *
+ * ONE ROW IDENTITY, DEFINED BEFORE IT IS IMPLEMENTED, and it is the only
+ * bookkeeping this feature does:
+ *
+ *   showGauge            1 row when the gauge rule fires (width >= 20, rows >= 8)
+ *   + 1                  the TODO header row
+ *   + (compact ? 0 : 1)  ONE blank row: the full rail has it, the compact rail does not
+ *   + todoItemRows
+ *   + Number(todoFooter)
+ *   + (acc ? acc.headerRows + acc.itemRows : 0)
+ *   <= rows
+ *
+ * `overhead = 3` appears only in the full rung with a `visible` second section:
+ * 1 TODO header + 1 blank row + 1 ACCEPT header. THAT BLANK ROW IS THE SAME ROW
+ * TWICE OVER - it is the breathing space under the TODO header AND the separator
+ * between the two sections - so counting it twice overflows the box by one row,
+ * and Ink's `overflow="hidden"` clips the overflow silently. The symptom a user
+ * reports is "the panel only shows 2 criteria", which is why this comment is at
+ * the top of the file rather than next to the arithmetic.
+ *
+ * PURE: no I/O, no timers, no imports from `ui/**`. The rail renders what this
+ * returns; `/perf` reports the `acceptance.reason` it returns; the status-bar chip
+ * asks it whether the rail is already reporting the count. One number, one owner.
+ */
+import type { PlanPhase } from './types.js';
+export interface PlanSectionsInput {
+    /** The rail's whole row budget (`TodoPanel`'s `rows` prop). */
+    rows: number;
+    /** The rail's whole column budget, chrome included. */
+    width: number;
+    phase: PlanPhase;
+    todoCount: number;
+    /** 0 means "no acceptance section at all". */
+    acceptanceCount: number;
+    /** Decided by `TodoPanel` under the existing gauge rule (width >= 20, rows >= 8). */
+    showGauge: boolean;
+}
+/**
+ * `visible` - header row plus item rows.
+ * `summary` - one row only (`AC 2/5`), no header, no items.
+ * `absent`  - nothing at all; the count has to reach the status-bar chip (I-7).
+ */
+export type AcceptanceSectionReason = 'visible' | 'summary' | 'absent';
+export interface PlanSections {
+    todoItemRows: number;
+    /** Whether the `-N +M` footer is drawn (the existing `compactFooter` semantics). */
+    todoFooter: boolean;
+    acceptance: {
+        reason: AcceptanceSectionReason;
+        /** 1 = header row drawn; 0 = summary row only. */
+        headerRows: number;
+        /** > 0 to draw item rows. */
+        itemRows: number;
+    } | null;
+}
+export declare function buildPlanSections(input: PlanSectionsInput): PlanSections;

package/dist/todo/plan-sections.js

@@ -0,0 +1,108 @@
+/**
+ * The rail's two-section row allocation (todo-acceptance-criteria §6.9.2).
+ *
+ * ASCII ONLY: `src/todo/**` is inside the glyph scanner's scope.
+ *
+ * ONE ROW IDENTITY, DEFINED BEFORE IT IS IMPLEMENTED, and it is the only
+ * bookkeeping this feature does:
+ *
+ *   showGauge            1 row when the gauge rule fires (width >= 20, rows >= 8)
+ *   + 1                  the TODO header row
+ *   + (compact ? 0 : 1)  ONE blank row: the full rail has it, the compact rail does not
+ *   + todoItemRows
+ *   + Number(todoFooter)
+ *   + (acc ? acc.headerRows + acc.itemRows : 0)
+ *   <= rows
+ *
+ * `overhead = 3` appears only in the full rung with a `visible` second section:
+ * 1 TODO header + 1 blank row + 1 ACCEPT header. THAT BLANK ROW IS THE SAME ROW
+ * TWICE OVER - it is the breathing space under the TODO header AND the separator
+ * between the two sections - so counting it twice overflows the box by one row,
+ * and Ink's `overflow="hidden"` clips the overflow silently. The symptom a user
+ * reports is "the panel only shows 2 criteria", which is why this comment is at
+ * the top of the file rather than next to the arithmetic.
+ *
+ * PURE: no I/O, no timers, no imports from `ui/**`. The rail renders what this
+ * returns; `/perf` reports the `acceptance.reason` it returns; the status-bar chip
+ * asks it whether the rail is already reporting the count. One number, one owner.
+ */
+import { TODO_LIMITS } from './limits.js';
+/**
+ * Clamp, and NEVER silently reverse: `clampRows` requires `lo <= hi` at the call
+ * site, which every branch below establishes before it calls (§6.9.2, P2-5).
+ * `clampRows(x, 1, 0)` would return 0 - a panel that draws no acceptance rows and
+ * says nothing about why.
+ */
+function clampRows(value, lo, hi) {
+    return Math.min(Math.max(value, lo), hi);
+}
+/**
+ * The share of the item budget a `work`/`done` rail gives the criteria: 0.3, so the
+ * two sections trade rows rather than one starving the other (§6.9.2 step 6). The
+ * `verify` phase does not use it - there the criteria take everything above one row.
+ */
+const ACCEPTANCE_SHARE = 0.3;
+export function buildPlanSections(input) {
+    const rows = Math.max(0, Math.floor(input.rows));
+    const acceptanceCount = Math.max(0, Math.floor(input.acceptanceCount));
+    const todoCount = Math.max(0, Math.floor(input.todoCount));
+    // 1. The existing definition of "compact", unchanged.
+    const compact = rows < TODO_LIMITS.panelFullRows;
+    // 2. What is left after the gauge, unchanged.
+    const available = rows - Number(input.showGauge);
+    // 3. The existing footer rule, unchanged.
+    const todoFooter = compact && todoCount > rows - 1;
+    // 4. No criteria: BYTE-IDENTICAL to the pre-feature arithmetic (I-5).
+    if (acceptanceCount === 0) {
+        return {
+            todoItemRows: compact
+                ? rows - 1 - Number(todoFooter)
+                : rows - 2 - Number(input.showGauge),
+            todoFooter,
+            acceptance: null,
+        };
+    }
+    // 5. Compact rung: rows in {3,4,5}, the gauge never fires, available === rows.
+    if (compact) {
+        const base = rows - 1 - Number(todoFooter);
+        // Lend one row to the summary line, but never the TODO window's last row.
+        // `absent` is reachable ONLY at rows === 3 with a footer (base === 1), which
+        // is the one "panel is up, section is not" combination (AC-34).
+        if (base - 1 >= 1) {
+            return {
+                todoItemRows: base - 1,
+                todoFooter,
+                acceptance: { reason: 'summary', headerRows: 0, itemRows: 1 },
+            };
+        }
+        return {
+            todoItemRows: base,
+            todoFooter,
+            acceptance: { reason: 'absent', headerRows: 0, itemRows: 0 },
+        };
+    }
+    // 6. Full rung: rows >= 6. Three rows of chrome for the second section.
+    const budget = available - 3;
+    if (input.phase === 'verify') {
+        // Every step is done, so the step list carries no information - one row says
+        // so and the rest goes to the criteria the eye is actually on (D-7).
+        return {
+            todoItemRows: 1,
+            todoFooter: false,
+            acceptance: {
+                reason: 'visible',
+                headerRows: 1,
+                itemRows: clampRows(budget - 1, 1, acceptanceCount),
+            },
+        };
+    }
+    // `work` AND `done` share this branch on purpose: a plan that just passed every
+    // criterion must keep showing the table it passed - that is the screen the user
+    // wants to read - rather than fold like `verify` does.
+    const accItemRows = clampRows(Math.round(budget * ACCEPTANCE_SHARE), 1, Math.min(acceptanceCount, budget - 1));
+    return {
+        todoItemRows: budget - accItemRows,
+        todoFooter: false,
+        acceptance: { reason: 'visible', headerRows: 1, itemRows: accItemRows },
+    };
+}

package/dist/todo/prompt.d.ts

@@ -1,5 +1,6 @@
 /**
- * The `<todo_planning>` system-prompt block (todo-plan-execution §3.7).
+ * The `<todo_planning>` system-prompt block (todo-plan-execution §3.7;
+ * todo-acceptance-criteria §6.5).
  *
  * ASCII ONLY: `src/todo/**` is inside the glyph scanner's scope, and this string
  * also reaches a model that may be running in a `cmd.exe` terminal.
@@ -7,8 +8,9 @@
  * SPLICED CONDITIONALLY by `buildSystemPrompt`, which is what preserves C-10:
  * with `todo.enabled: false` the prompt is BYTE-IDENTICAL to the pre-todo output
  * for a fixed tool array. An unconditional guidance line anywhere here would
- * quietly break `--no-todo`, `--no-team`, `--no-skills` and the plan-mode
- * snapshot all at once.
+ * quietly break `--no-todo`, `--no-team`, `--no-skills` and the plan-mode snapshot
+ * all at once. The acceptance paragraph obeys the same rule one level down: with
+ * `acceptance: false` the block is byte-identical to v1.
  *
  * THE BLOCK'S THRESHOLD (3+ steps) IS STRICTER THAN THE STRUCTURAL GUARD
  * (`minFreshItems`, 2). A backstop looser than the guidance never argues with a
@@ -16,24 +18,27 @@
  * separate deliverables is fine, and the prompt simply does not encourage it.
  *
  * `TODO_BLOCK_VERSION` exists so a change to this wording is greppable from a
- * behaviour report - INCLUDING a change to either `{{VISIBILITY}}` variant,
- * which is part of the block.
+ * behaviour report - INCLUDING a change to either `{{VISIBILITY}}` variant, which
+ * is part of the block.
  */
 import { TODO_BLOCK_VERSION } from './limits.js';
 export { TODO_BLOCK_VERSION };
 export interface TodoBlockParams {
     panelVisible: boolean;
+    /**
+     * `todo.acceptance`, read LIVE. False reproduces the v1 block byte for byte
+     * (the version constant itself is not inside the block, so it cannot spoil the
+     * comparison).
+     */
+    acceptance: boolean;
 }
 /**
- * BOUNDED AT 1600 CHARACTERS, and the number is asserted in `todo-tool.test.ts`.
+ * BOUNDED AT 2400 CHARACTERS, and the number is asserted in `todo-tool.test.ts`.
  *
  * The block is paid for on EVERY turn of every todo-enabled session, so anything
  * that does not change a planning decision does not belong in it (the discipline
- * `buildTeamBlock` records at 1200 for a shorter block). This one lands at ~1430
- * as designed — three bullet lists plus the `{{VISIBILITY}}` sentence — and was
- * NOT trimmed to reach a borrowed budget, because every line in it changes a
- * planning decision, which is the test that actually applies. The bound exists
- * so that adding a paragraph stays a decision someone makes on purpose. See
- * spec §15 IF-3.
+ * `buildTeamBlock` records at 1200 for a shorter block). v1 landed at 1433; v2
+ * lands at 2300 (2264 for the hidden variant), and the bound exists so that adding a
+ * paragraph stays a decision someone makes on purpose rather than a drift.
  */
 export declare function buildTodoBlock(params: TodoBlockParams): string;

package/dist/todo/prompt.js

@@ -1,5 +1,6 @@
 /**
- * The `<todo_planning>` system-prompt block (todo-plan-execution §3.7).
+ * The `<todo_planning>` system-prompt block (todo-plan-execution §3.7;
+ * todo-acceptance-criteria §6.5).
  *
  * ASCII ONLY: `src/todo/**` is inside the glyph scanner's scope, and this string
  * also reaches a model that may be running in a `cmd.exe` terminal.
@@ -7,8 +8,9 @@
  * SPLICED CONDITIONALLY by `buildSystemPrompt`, which is what preserves C-10:
  * with `todo.enabled: false` the prompt is BYTE-IDENTICAL to the pre-todo output
  * for a fixed tool array. An unconditional guidance line anywhere here would
- * quietly break `--no-todo`, `--no-team`, `--no-skills` and the plan-mode
- * snapshot all at once.
+ * quietly break `--no-todo`, `--no-team`, `--no-skills` and the plan-mode snapshot
+ * all at once. The acceptance paragraph obeys the same rule one level down: with
+ * `acceptance: false` the block is byte-identical to v1.
  *
  * THE BLOCK'S THRESHOLD (3+ steps) IS STRICTER THAN THE STRUCTURAL GUARD
  * (`minFreshItems`, 2). A backstop looser than the guidance never argues with a
@@ -16,61 +18,78 @@
  * separate deliverables is fine, and the prompt simply does not encourage it.
  *
  * `TODO_BLOCK_VERSION` exists so a change to this wording is greppable from a
- * behaviour report - INCLUDING a change to either `{{VISIBILITY}}` variant,
- * which is part of the block.
+ * behaviour report - INCLUDING a change to either `{{VISIBILITY}}` variant, which
+ * is part of the block.
  */
 import { TODO_BLOCK_VERSION } from './limits.js';
 export { TODO_BLOCK_VERSION };
 /**
  * The ONLY sentence in the block that mentions a display at all. Everything else
- * talks about "the list", which is what makes "the two variants differ in
- * exactly one sentence" checkable rather than approximate (AC-42).
+ * talks about "the list", which is what makes "the two variants differ in exactly
+ * one sentence" checkable rather than approximate - and it is why the acceptance
+ * paragraph's visibility sentence is appended HERE rather than written inline:
+ * with the capability on, the variants differ in exactly TWO sentences, one per
+ * section, in the same position and the same number of lines.
  */
 const VISIBLE = 'The user sees this list in a panel beside the conversation, so it is the only place ' +
     'they can watch a long task progress.';
 const NOT_VISIBLE = 'The user cannot see this list in this session, but keeping it is still how you stay ' +
     'on one step at a time and report what is left.';
+/** The acceptance section's one visibility sentence, per variant (§6.5). */
+const ACCEPT_VISIBLE = 'The criteria are shown in the same panel, under the steps, so they are also what the ' +
+    'user watches during the final check.';
+const ACCEPT_NOT_VISIBLE = 'The criteria are still how you keep yourself honest during the final check.';
 /**
- * BOUNDED AT 1600 CHARACTERS, and the number is asserted in `todo-tool.test.ts`.
+ * The acceptance paragraph. Five lines of guidance, and each one is there because
+ * it changes a planning decision:
+ *
+ *  - the first says criteria exist at all and belong in the SAME call;
+ *  - the second names the phase transition and the one-at-a-time rule;
+ *  - the third forbids the "call it done anyway" ending;
+ *  - the fourth is the only defence against the commonest degeneration, a
+ *    criterion that is just the step name again (R-5).
+ *
+ * MEASURED, NOT ESTIMATED (P1-5): this paragraph plus the visibility sentences
+ * and two newlines adds 867 characters to a 1433-character block, so the v2 block
+ * is asserted at 2300 and bounded at 2400 in `todo-tool.test.ts`. Trimming it to
+ * fit 2200 would cost the criterion-versus-step contrast below (143 characters),
+ * which is the only mitigation R-5 has - see Q-8.
+ */
+const ACCEPTANCE_LINES = [
+    'Every plan also carries ACCEPTANCE CRITERIA: one line each saying how you will know',
+    'that part of the work is really done. The user checks your claim against them.',
+    '- Plan them in the SAME todo_write call (the acceptance array), each with the check',
+    '  you will run for it.',
+    '- Once every step is completed the plan is in VERIFY: check the criteria ONE at a',
+    '  time, run the check you named, and record the verdict with its evidence. A verdict',
+    '  without evidence is not a verdict.',
+    '- A failed check is not a detail: fix the work, reopen that criterion (reopen: true),',
+    '  check it again - never call the work done while one has failed.',
+    '- A criterion is not a step: "Add the rail" is a step, "the rail shows 3 items on an',
+    '  80x24 terminal" is a criterion.',
+];
+/**
+ * BOUNDED AT 2400 CHARACTERS, and the number is asserted in `todo-tool.test.ts`.
  *
  * The block is paid for on EVERY turn of every todo-enabled session, so anything
  * that does not change a planning decision does not belong in it (the discipline
- * `buildTeamBlock` records at 1200 for a shorter block). This one lands at ~1430
- * as designed — three bullet lists plus the `{{VISIBILITY}}` sentence — and was
- * NOT trimmed to reach a borrowed budget, because every line in it changes a
- * planning decision, which is the test that actually applies. The bound exists
- * so that adding a paragraph stays a decision someone makes on purpose. See
- * spec §15 IF-3.
+ * `buildTeamBlock` records at 1200 for a shorter block). v1 landed at 1433; v2
+ * lands at 2300 (2264 for the hidden variant), and the bound exists so that adding a
+ * paragraph stays a decision someone makes on purpose rather than a drift.
  */
 export function buildTodoBlock(params) {
-    return [
+    const lines = [
         '<todo_planning>',
         'For work that takes three or more distinct steps, keep a visible plan with the',
         'todo_write tool.',
         params.panelVisible ? VISIBLE : NOT_VISIBLE,
-        '',
-        'Use it when:',
-        '- the request has three or more steps that must happen in order;',
-        '- the user gave you several things to do in one message;',
-        '- you are part-way through a long task and the user asks what is left.',
-        '',
-        'Do NOT use it for:',
-        '- anything you can finish in one or two steps - just do it and say what you did;',
-        '- a question, an explanation, or a search with no work attached;',
-        '- restating a step you are already in the middle of.',
-        '',
-        'How to use it:',
-        '- Send the COMPLETE list every time. The tool replaces the whole list; it has no',
-        '  add or update operation.',
-        '- Exactly one item is in_progress at a time. Mark an item completed the moment',
-        '  it is done and mark the next one in_progress in the SAME call.',
-        '- Do not batch. Finishing three steps and reporting them together hides where you',
-        '  are RIGHT NOW, which is the whole point of keeping the list.',
-        '- Give each item a content ("Add the rail to AppShell") and an activeForm',
-        '  ("Adding the rail to AppShell"). The list shows activeForm for the step in',
-        '  progress and content for the rest.',
-        '- Only mark an item completed when it is really finished. If you hit a blocker,',
-        '  leave it in_progress, add an item describing what is blocking, and say so.',
-        '</todo_planning>',
-    ].join('\n');
+    ];
+    if (params.acceptance) {
+        lines.push(params.panelVisible ? ACCEPT_VISIBLE : ACCEPT_NOT_VISIBLE);
+    }
+    lines.push('', 'Use it when:', '- the request has three or more steps that must happen in order;', '- the user gave you several things to do in one message;', '- you are part-way through a long task and the user asks what is left.', '', 'Do NOT use it for:', '- anything you can finish in one or two steps - just do it and say what you did;', '- a question, an explanation, or a search with no work attached;', '- restating a step you are already in the middle of.', '', 'How to use it:', '- Send the COMPLETE list every time. The tool replaces the whole list; it has no', '  add or update operation.', '- Exactly one item is in_progress at a time. Mark an item completed the moment', '  it is done and mark the next one in_progress in the SAME call.', '- Do not batch. Finishing three steps and reporting them together hides where you', '  are RIGHT NOW, which is the whole point of keeping the list.', '- Give each item a content ("Add the rail to AppShell") and an activeForm', '  ("Adding the rail to AppShell"). The list shows activeForm for the step in', '  progress and content for the rest.', '- Only mark an item completed when it is really finished. If you hit a blocker,', '  leave it in_progress, add an item describing what is blocking, and say so.');
+    if (params.acceptance)
+        lines.push(...ACCEPTANCE_LINES);
+    lines.push('</todo_planning>');
+    return lines.join('\n');
 }

package/dist/todo/row-window.d.ts

@@ -0,0 +1,51 @@
+/**
+ * `selectRowsAround` — the generic anchored window (todo-acceptance-criteria §6.9.4).
+
+ASCII ONLY: `src/todo/**` is inside the glyph scanner's scope.
+
+PURE WINDOWING, NO OFFSET STATE ANYWHERE (non-goal 2 / R-10). Ink has no absolute
+positioning and this codebase already owns one hand-rolled viewport
+(`ScrollViewport`) whose invariants took a whole spec to pin down; a second
+scrollable region with its own offset, its own intent nonce and its own wheel band
+would be the largest source of new bugs in that feature by a wide margin. The rail
+therefore never scrolls - it windows around the row being worked on and reports
+what is off each end.
+
+THE DIRECT DESCENDANT OF `selectPanelRows`'s F-2 LESSON: the team panel originally
+took the first five children by ARRAY INDEX, which showed the five that finished
+FIRST and hid everything still working. Here the equivalent mistake is
+`slice(0, maxRows)`, which on a 20-row plan shows rows 1-8 - all completed - and
+hides the one the user is actually watching.
+
+GENERIC OVER THE ROW TYPE (todo-acceptance-criteria §6.9.4): the todo window and
+the acceptance window are the same algorithm over two different item shapes, so
+the anchored-window fixpoint lives here once and three thin wrappers expose it.
+The wrappers' outputs are field-for-field identical to the original todo-only
+implementation (AC-13).
+ */
+export interface RowWindow<T> {
+    visible: {
+        item: T;
+        index: number;
+    }[];
+    hiddenAbove: number;
+    hiddenBelow: number;
+}
+/**
+ * The anchored contiguous window, WITHOUT reserving overflow-marker rows.
+ *
+ * `maxRows` is a row count; invalid or non-positive values return an empty window
+ * with every row counted below it, which is what makes a caller whose arithmetic
+ * produced 0 render nothing rather than render everything.
+ */
+export declare function selectCompactRowsAround<T>(items: readonly T[], maxRows: number, anchor: (items: readonly T[]) => number): RowWindow<T>;
+/**
+ * The anchored window WITH the two overflow markers accounted for.
+ *
+ * THE ANCHOR IS ALWAYS VISIBLE, and that beats the row bound when the two
+ * conflict. They can only conflict below `maxRows` 3 with overflow on BOTH sides
+ * - one row plus two markers is three rows - where this returns the anchor and
+ * lets the caller's `overflow="hidden"` clip a marker. Hiding the one row the user
+ * is watching in order to keep a `+N above` would be the wrong trade.
+ */
+export declare function selectRowsAround<T>(items: readonly T[], maxRows: number, anchor: (items: readonly T[]) => number): RowWindow<T>;

package/dist/todo/row-window.js

@@ -0,0 +1,107 @@
+/**
+ * `selectRowsAround` — the generic anchored window (todo-acceptance-criteria §6.9.4).
+
+ASCII ONLY: `src/todo/**` is inside the glyph scanner's scope.
+
+PURE WINDOWING, NO OFFSET STATE ANYWHERE (non-goal 2 / R-10). Ink has no absolute
+positioning and this codebase already owns one hand-rolled viewport
+(`ScrollViewport`) whose invariants took a whole spec to pin down; a second
+scrollable region with its own offset, its own intent nonce and its own wheel band
+would be the largest source of new bugs in that feature by a wide margin. The rail
+therefore never scrolls - it windows around the row being worked on and reports
+what is off each end.
+
+THE DIRECT DESCENDANT OF `selectPanelRows`'s F-2 LESSON: the team panel originally
+took the first five children by ARRAY INDEX, which showed the five that finished
+FIRST and hid everything still working. Here the equivalent mistake is
+`slice(0, maxRows)`, which on a 20-row plan shows rows 1-8 - all completed - and
+hides the one the user is actually watching.
+
+GENERIC OVER THE ROW TYPE (todo-acceptance-criteria §6.9.4): the todo window and
+the acceptance window are the same algorithm over two different item shapes, so
+the anchored-window fixpoint lives here once and three thin wrappers expose it.
+The wrappers' outputs are field-for-field identical to the original todo-only
+implementation (AC-13).
+ */
+/**
+ * How much of the window sits ABOVE the anchor.
+ *
+ * A QUARTER, and the asymmetry is the point: completed context above the anchor
+ * is sacrificed before upcoming work below it, because the user's question is
+ * "what is next", not "what is behind me".
+ */
+const ABOVE_SHARE = 0.25;
+function windowFor(count, anchor, slots) {
+    if (slots >= count)
+        return { start: 0, end: count };
+    const above = Math.min(anchor, Math.max(0, Math.floor((slots - 1) * ABOVE_SHARE)));
+    let start = anchor - above;
+    let end = start + slots;
+    if (end > count) {
+        end = count;
+        start = Math.max(0, end - slots);
+    }
+    return { start, end };
+}
+/**
+ * The anchored contiguous window, WITHOUT reserving overflow-marker rows.
+ *
+ * `maxRows` is a row count; invalid or non-positive values return an empty window
+ * with every row counted below it, which is what makes a caller whose arithmetic
+ * produced 0 render nothing rather than render everything.
+ */
+export function selectCompactRowsAround(items, maxRows, anchor) {
+    const slots = Number.isFinite(maxRows) ? Math.max(0, Math.floor(maxRows)) : 0;
+    if (slots === 0 || items.length === 0) {
+        return { visible: [], hiddenAbove: 0, hiddenBelow: items.length };
+    }
+    const { start, end } = windowFor(items.length, anchor(items), slots);
+    return {
+        visible: items.slice(start, end).map((item, offset) => ({ item, index: start + offset })),
+        hiddenAbove: start,
+        hiddenBelow: items.length - end,
+    };
+}
+/**
+ * The anchored window WITH the two overflow markers accounted for.
+ *
+ * THE ANCHOR IS ALWAYS VISIBLE, and that beats the row bound when the two
+ * conflict. They can only conflict below `maxRows` 3 with overflow on BOTH sides
+ * - one row plus two markers is three rows - where this returns the anchor and
+ * lets the caller's `overflow="hidden"` clip a marker. Hiding the one row the user
+ * is watching in order to keep a `+N above` would be the wrong trade.
+ */
+export function selectRowsAround(items, maxRows, anchor) {
+    const count = items.length;
+    const anchorIndex = anchor(items);
+    if (count === 0)
+        return { visible: [], hiddenAbove: 0, hiddenBelow: 0 };
+    if (maxRows <= 0) {
+        return {
+            visible: [],
+            hiddenAbove: anchorIndex,
+            hiddenBelow: count - 1 - anchorIndex,
+        };
+    }
+    // The marker rows and the window depend on each other: a `+N above` row costs a
+    // slot, which can shrink the window, which can create a `+N below`. Two passes
+    // reach the fixpoint for every input this can be handed; the loop bound is a
+    // backstop, not a live case.
+    let reserved = 0;
+    let start = 0;
+    let end = count;
+    for (let pass = 0; pass < 3; pass += 1) {
+        const slots = Math.max(1, maxRows - reserved);
+        const win = windowFor(count, anchorIndex, slots);
+        start = win.start;
+        end = win.end;
+        const need = (start > 0 ? 1 : 0) + (end < count ? 1 : 0);
+        if (need === reserved)
+            break;
+        reserved = need;
+    }
+    const visible = [];
+    for (let i = start; i < end; i += 1)
+        visible.push({ item: items[i], index: i });
+    return { visible, hiddenAbove: start, hiddenBelow: count - end };
+}