@aragon-agent/cli 0.6.34 → 0.6.36

package/dist/todo/follow-through.js

@@ -1,6 +1,6 @@
 /**
- * follow-through — what happens when a run ends with unfinished steps
- * (todo-plan-followthrough §3.2 / §3.3).
+ * follow-through — what happens when a run ends with unfinished work
+ * (todo-plan-followthrough §3.2 / §3.3; todo-acceptance-criteria §6.6).
  *
  * ASCII ONLY: `src/todo/**` is inside the glyph scanner's scope
  * (`glyphs.test.ts`), and every string this module builds is user-visible.
@@ -14,9 +14,18 @@
  * IT NEVER WRITES TO `TodoStore` (I-1 / C-3). Follow-through reads snapshots and
  * produces a MESSAGE; the plan changes only when the model calls `todo_write`,
  * which keeps the list a projection of what the model believes.
+ *
+ * "UNFINISHED WORK" HAS TWO HALVES SINCE ACCEPTANCE CRITERIA EXISTED (§6.6.1):
+ * steps still to do, and criteria still unchecked. Every exit below reads them
+ * from `outstandingOf`, and while ANY step is left the wording is byte-identical
+ * to the version without this feature (I-5) - because that is the phase in which
+ * the old sentences are already true. In the verification phase, where
+ * `total - doneCount` is always 0, saying "0 steps left" would be the exact
+ * opposite of the truth at the moment the user most wants reassurance.
  */
+import { buildVerifyMessage, criteriaPhrase, outstandingOf } from './acceptance.js';
 import { TODO_FOLLOW_LIMITS } from './limits.js';
-/** The zero budget. A fresh App, a fresh headless run, and every cleared list. */
+/** The zero budget. A fresh App, a fresh headless run, and every cleared plan. */
 export function emptyBudget() {
     return { used: 0, noProgressStreak: 0, anchorTotal: 0, doneAtRunStart: 0 };
 }
@@ -36,13 +45,35 @@ function legacyUnfinishedNotice(left) {
 function advise(interactive, text) {
     return interactive ? ` ${text}` : '';
 }
+/** `<n> acceptance criteria are unchecked` — singular and plural in one place. */
+function uncheckedCriteria(count) {
+    return `${criteriaPhrase(count)} ${count === 1 ? 'is' : 'are'} unchecked`;
+}
+/**
+ * The verification-phase notice for one exit (§6.6.1.1).
+ *
+ * ONE FUNCTION, SIX CALLERS, because the noun's number and the verb's number have
+ * to agree in the same sentence and six hand-written strings will not stay in
+ * agreement.
+ */
+function verificationNotice(checks, interactive, tail, advice) {
+    return `${uncheckedCriteria(checks)}${tail}${advise(interactive, advice)}`;
+}
 export function decideFollowThrough(input) {
     const { mode, snapshot, runEnd, budget, interactive } = input;
-    // 1. Nothing is unfinished. `beginUserTurn` already drops a fully-completed
-    //    list at the next turn, so this branch must not pre-empt that feedback.
-    if (!snapshot || snapshot.doneCount >= snapshot.total)
+    // 1. Nothing is unfinished - INCLUDING the criteria (§6.6.1). "Every step is
+    //    completed" stopped being the same claim as "there is nothing left" the
+    //    moment a plan carried acceptance criteria; `beginUserTurn` already drops a
+    //    fully-resolved plan at the next turn, so this branch must not pre-empt that
+    //    feedback.
+    const outstanding = snapshot ? outstandingOf(snapshot) : { steps: 0, checks: 0 };
+    if (!snapshot || outstanding.steps + outstanding.checks === 0)
         return { kind: 'none' };
-    const left = snapshot.total - snapshot.doneCount;
+    const left = outstanding.steps;
+    // WHILE ANY STEP IS LEFT THE OLD SENTENCES ARE ALREADY TRUE, so they are reused
+    // verbatim (I-5) and only the verification phase gets new wording.
+    const verifying = left === 0 && outstanding.checks > 0;
+    const checks = outstanding.checks;
     // 2. The user asked for silence and gets silence, INCLUDING no notice.
     if (mode === 'off')
         return { kind: 'none' };
@@ -51,25 +82,38 @@ export function decideFollowThrough(input) {
     //    continue it is worse.
     if (runEnd.aborted)
         return { kind: 'none' };
-    // 4. NEVER `continue`, IN ANY MODE (D-6). Auto-continuing into a model that
-    //    just failed authentication or ran out of quota is the unbounded cost loop
-    //    with none of the upside.
+    // 4. NEVER `continue`, IN ANY MODE (D-6). Auto-continuing into a model that just
+    //    failed authentication or ran out of quota is the unbounded cost loop with
+    //    none of the upside.
     if (runEnd.errored) {
         return {
             kind: 'notify',
             level: 'warn',
-            text: `${left} ${left === 1 ? 'step' : 'steps'} left; the run ended with an error.` +
-                advise(interactive, '/todo continue to retry, /todo clear to drop it.'),
+            text: verifying
+                ? verificationNotice(checks, interactive, '; the run ended with an error.', '/todo continue to retry, /todo clear to drop it.')
+                : `${left} ${left === 1 ? 'step' : 'steps'} left; the run ended with an error.` +
+                    advise(interactive, '/todo continue to retry, /todo clear to drop it.'),
         };
     }
-    // 5. The default. Byte-identical to round 1 in the TUI (AC-1).
+    // 5. The default. Byte-identical to round 1 in the TUI whenever steps remain
+    //    (AC-1 / AC-44's reverse direction).
     if (mode === 'notify') {
+        if (!verifying) {
+            return {
+                kind: 'notify',
+                level: 'info',
+                text: interactive
+                    ? legacyUnfinishedNotice(left)
+                    : `${left} ${left === 1 ? 'step' : 'steps'} unfinished`,
+            };
+        }
         return {
             kind: 'notify',
             level: 'info',
             text: interactive
-                ? legacyUnfinishedNotice(left)
-                : `${left} ${left === 1 ? 'step' : 'steps'} unfinished`,
+                ? `${uncheckedCriteria(checks)}. Use /todo continue to finish the check, ` +
+                    '/todo clear to drop it.'
+                : `${criteriaPhrase(checks)} unchecked`,
         };
     }
     // 6. The ceiling that holds when everything else is wrong.
@@ -77,33 +121,45 @@ export function decideFollowThrough(input) {
         return {
             kind: 'notify',
             level: 'warn',
-            text: `${left} ${left === 1 ? 'step' : 'steps'} left; auto-continue has run ` +
-                `${TODO_FOLLOW_LIMITS.maxAutoContinuesPerList} times for this plan.` +
-                advise(interactive, '/todo continue to keep going.'),
+            text: verifying
+                ? verificationNotice(checks, interactive, `; auto-continue has run ${TODO_FOLLOW_LIMITS.maxAutoContinuesPerList} times ` +
+                    'for this plan.', '/todo continue to keep going.')
+                : `${left} ${left === 1 ? 'step' : 'steps'} left; auto-continue has run ` +
+                    `${TODO_FOLLOW_LIMITS.maxAutoContinuesPerList} times for this plan.` +
+                    advise(interactive, '/todo continue to keep going.'),
         };
     }
     // 7. A model that has stopped engaging with its own plan hands back after one
     //    nudge rather than after twenty-five.
     if (budget.noProgressStreak >= TODO_FOLLOW_LIMITS.maxNoProgressContinues) {
+        const attempts = TODO_FOLLOW_LIMITS.maxNoProgressContinues;
         return {
             kind: 'notify',
             level: 'warn',
-            text: `${left} ${left === 1 ? 'step' : 'steps'} left; the last ` +
-                `${TODO_FOLLOW_LIMITS.maxNoProgressContinues} attempts completed none of them.` +
-                advise(interactive, '/todo continue to retry, or take over.'),
+            text: verifying
+                ? verificationNotice(checks, interactive, `; the last ${attempts} attempts checked none of them.`, '/todo continue to retry, or take over.')
+                : `${left} ${left === 1 ? 'step' : 'steps'} left; the last ` +
+                    `${attempts} attempts completed none of them.` +
+                    advise(interactive, '/todo continue to retry, or take over.'),
         };
     }
     const graceMs = interactive ? TODO_FOLLOW_LIMITS.graceMs : 0;
+    const seconds = Math.round(graceMs / 1000);
     return {
         kind: 'continue',
         message: buildContinuationMessage(snapshot),
         graceMs,
         // The seconds figure is DERIVED from the constant, never spelled again: a
         // notice that promises 3 s while the timer waits 5 is worse than no notice.
-        notice: interactive
-            ? `Continuing with ${left} remaining ${left === 1 ? 'step' : 'steps'} in ` +
-                `${Math.round(graceMs / 1000)}s - Esc to stop.`
-            : `continuing (${left} ${left === 1 ? 'step' : 'steps'} left)`,
+        notice: verifying
+            ? interactive
+                ? `Continuing with ${checks} unchecked acceptance ` +
+                    `${checks === 1 ? 'criterion' : 'criteria'} in ${seconds}s - Esc to stop.`
+                : `continuing (${checks} acceptance ${checks === 1 ? 'criterion' : 'criteria'} unchecked)`
+            : interactive
+                ? `Continuing with ${left} remaining ${left === 1 ? 'step' : 'steps'} in ` +
+                    `${seconds}s - Esc to stop.`
+                : `continuing (${left} ${left === 1 ? 'step' : 'steps'} left)`,
     };
 }
 /**
@@ -111,32 +167,36 @@ export function decideFollowThrough(input) {
  * every `agent_end` (and on every resolved `prompt()` in headless).
  *
  * `used` is NOT incremented here — a decision that is never acted on costs
- * nothing. Both fire points charge it themselves (I-5): the TUI's grace timer
- * and the headless loop, and BOTH are required. An uncharged counter in `-p` is
- * an uncapped loop in the one environment with no human to press Esc (P1-2).
+ * nothing. Both fire points charge it themselves (I-5): the TUI's grace timer and
+ * the headless loop, and BOTH are required. An uncharged counter in `-p` is an
+ * uncapped loop in the one environment with no human to press Esc (P1-2).
  */
 export function advanceBudget(prev, snapshot, wasAutoContinuation) {
-    // THE ONLY PATH THAT CLEARS `used` (I-8). The list is gone; so is its economy.
+    // THE ONLY PATH THAT CLEARS `used` (I-8). The plan is gone; so is its economy.
     // It is not reachable by a model on its own: `TodoStore.write` leaves the
-    // previous list untouched when a payload yields zero usable items, and the
-    // other three ways a list disappears are `/todo clear`, `/reset` and
-    // `beginUserTurn` dropping a list that is either finished (nothing to
-    // continue) or stale (which the streak rule beats to the punch, §3.5).
+    // previous plan untouched when a payload yields zero usable items, and the other
+    // three ways a plan disappears are `/todo clear`, `/reset` and `beginUserTurn`
+    // dropping a plan that is either finished (nothing to continue) or stale (which
+    // the streak rule beats to the punch, §3.5).
     if (!snapshot)
         return emptyBudget();
+    // The plan's identity is STEPS PLUS CRITERIA (§6.6.3): a re-plan that only
+    // changes the number of criteria is still a re-plan.
+    const anchor = snapshot.total + (snapshot.acceptance?.total ?? 0);
+    const progress = snapshot.doneCount + (snapshot.acceptance?.checkedCount ?? 0);
     // A RE-PLAN BUYS FORGIVENESS, NOT A FRESH WALLET (D-16). Replanning is
     // engagement rather than looping, which is why the streak is forgiven; zeroing
     // `used` as well is what makes the hard ceiling unreachable, because a size
     // change every turn would reset it every turn.
-    if (snapshot.total !== prev.anchorTotal) {
+    if (anchor !== prev.anchorTotal) {
         return {
             used: prev.used,
             noProgressStreak: 0,
-            anchorTotal: snapshot.total,
-            doneAtRunStart: snapshot.doneCount,
+            anchorTotal: anchor,
+            doneAtRunStart: progress,
         };
     }
-    const progressed = snapshot.doneCount > prev.doneAtRunStart;
+    const progressed = progress > prev.doneAtRunStart;
     // NOTE THE GUARD: a run the USER started never charges the streak, because the
     // user asking a question mid-plan is not the model failing to advance it.
     const noProgressStreak = progressed
@@ -150,7 +210,7 @@ export function advanceBudget(prev, snapshot, wasAutoContinuation) {
         anchorTotal: prev.anchorTotal,
         // Assigned in EVERY branch, which is what makes the next call's comparison
         // meaningful.
-        doneAtRunStart: snapshot.doneCount,
+        doneAtRunStart: progress,
     };
 }
 /**
@@ -158,14 +218,18 @@ export function advanceBudget(prev, snapshot, wasAutoContinuation) {
  *
  * IT ENUMERATES RATHER THAN REFERRING (D-11). Round 1 submitted the fixed string
  * "Continue with the remaining todo items.", which is a reference to a
- * `todo_write` call that in a long session may have scrolled far enough back
- * that the model reconstructs it wrong — and reconstructing it wrong is SILENT,
- * because whatever it writes next is a full replacement and becomes the new
- * truth.
+ * `todo_write` call that in a long session may have scrolled far enough back that
+ * the model reconstructs it wrong — and reconstructing it wrong is SILENT, because
+ * whatever it writes next is a full replacement and becomes the new truth.
+ *
+ * IN THE VERIFICATION PHASE IT BRANCHES TO `buildVerifyMessage` (§6.6.2): with
+ * every step completed, the old body would emit "These steps are not done yet:"
+ * followed by nothing at all, which is what `/todo continue` and auto-continue
+ * would both submit at exactly the moment the plan needs its criteria checked.
  *
  * `content` and never `activeForm`: the imperative is what an instruction wants.
- * Numbers are the item's 1-based position in the WHOLE list, so "step 5" means
- * the same thing here as it does in the rail. Completed items are omitted.
+ * Numbers are the item's 1-based position in the WHOLE plan, so "step 5" means the
+ * same thing here as it does in the rail. Completed items are omitted.
  * `TODO_LIMITS.maxItems` bounds the whole message at roughly 1.8 kB.
  */
 export function buildContinuationMessage(snapshot) {
@@ -173,6 +237,8 @@ export function buildContinuationMessage(snapshot) {
         .map((item, index) => ({ item, index }))
         .filter(({ item }) => item.status !== 'completed')
         .map(({ item, index }) => `${index + 1}. ${item.content}`);
+    if (remaining.length === 0)
+        return buildVerifyMessage(snapshot);
     return [
         'Continue the plan. These steps are not done yet:',
         ...remaining,

package/dist/todo/limits.d.ts

@@ -87,5 +87,66 @@ export declare const TODO_FOLLOW_LIMITS: {
  *
  * NOT BUMPED BY follow-through (D-3): the model is never told about the
  * mechanism, so the block is byte-identical to `bf6aeb1a`.
+ *
+ * BUMPED BY todo-acceptance-criteria (D-3 inverted): that feature CHANGES what
+ * the model reads, so the revision must be greppable from a behaviour report.
+ */
+export declare const TODO_BLOCK_VERSION = "v2-2026-10";
+/**
+ * ACCEPT_LIMITS - the structural bounds of the acceptance table
+ * (todo-acceptance-criteria §6.1). STRUCTURAL, NOT POLICY, exactly like
+ * `TODO_LIMITS`: what a rail row, a transcript row and a model payload can
+ * physically carry.
  */
-export declare const TODO_BLOCK_VERSION = "v1-2026-07";
+export declare const ACCEPT_LIMITS: {
+    /**
+     * TWELVE, DELIBERATELY FEWER THAN `TODO_LIMITS.maxItems` (20). A plan with more
+     * than a dozen criteria is not a plan, it is a test suite - and `check` is where
+     * a suite belongs ("npm test"). The cap is semantic pressure: the model either
+     * merges criteria or admits it wrote a suite.
+     */
+    readonly maxItems: 12;
+    /** `AcceptanceItem.content`, clamped (never rejected). */
+    readonly contentChars: 100;
+    /** `AcceptanceItem.check`, clamped. May be empty: a weak criterion, not an error. */
+    readonly checkChars: 120;
+    /** `AcceptanceItem.evidence`, clamped. */
+    readonly evidenceChars: 200;
+    /**
+     * A FRESH plan must declare at least this many usable criteria (§6.2.3 step 4).
+     * Gated on an EMPTY store AND on `todo.acceptance` being on: the requirement is
+     * "plan the criteria too", so it applies exactly where the capability does.
+     * Named `...Criteria`, not `...Items`, so it cannot be confused with
+     * `TODO_LIMITS.minFreshItems` (2) used two steps earlier.
+     */
+    readonly minFreshCriteria: 1;
+};
+/**
+ * TODO_RESULT_LIMITS - the bound on what `todo_write` returns each turn
+ * (I-11 / §6.4.4). The acceptance paragraph pushes the text from about 700
+ * characters to roughly 1100, and every character is paid for on every call, so
+ * the ceiling is structural rather than advisory.
+ */
+export declare const TODO_RESULT_LIMITS: {
+    readonly maxChars: 1400;
+    /** Appended when the text had to be clipped, so a clipped answer says so. */
+    readonly truncationNote: "Note: result text truncated.";
+};
+/**
+ * VERIFY_MESSAGE_LIMITS - the CONSTRUCTIVE bound of `buildVerifyMessage`
+ * (§6.6.2 / AC-22), in the tradition of `buildChildDigest`: independent of how
+ * long the lists are, because every row it emits is clamped.
+ *
+ * The two numbers are ONE arithmetic, measured rather than estimated: at 5
+ * unchecked + 2 failed with `check` at 100 and `evidence` at 60 the worst case is
+ * 19 rows / 1699 characters, leaving 101 characters below `maxChars` and one row
+ * below `maxRows`.
+ */
+export declare const VERIFY_MESSAGE_LIMITS: {
+    readonly uncheckedItems: 5;
+    readonly failedItems: 2;
+    readonly checkChars: 100;
+    readonly evidenceChars: 60;
+    readonly maxChars: 1800;
+    readonly maxRows: 20;
+};

package/dist/todo/limits.js

@@ -87,5 +87,66 @@ export const TODO_FOLLOW_LIMITS = {
  *
  * NOT BUMPED BY follow-through (D-3): the model is never told about the
  * mechanism, so the block is byte-identical to `bf6aeb1a`.
+ *
+ * BUMPED BY todo-acceptance-criteria (D-3 inverted): that feature CHANGES what
+ * the model reads, so the revision must be greppable from a behaviour report.
+ */
+export const TODO_BLOCK_VERSION = 'v2-2026-10';
+/**
+ * ACCEPT_LIMITS - the structural bounds of the acceptance table
+ * (todo-acceptance-criteria §6.1). STRUCTURAL, NOT POLICY, exactly like
+ * `TODO_LIMITS`: what a rail row, a transcript row and a model payload can
+ * physically carry.
  */
-export const TODO_BLOCK_VERSION = 'v1-2026-07';
+export const ACCEPT_LIMITS = {
+    /**
+     * TWELVE, DELIBERATELY FEWER THAN `TODO_LIMITS.maxItems` (20). A plan with more
+     * than a dozen criteria is not a plan, it is a test suite - and `check` is where
+     * a suite belongs ("npm test"). The cap is semantic pressure: the model either
+     * merges criteria or admits it wrote a suite.
+     */
+    maxItems: 12,
+    /** `AcceptanceItem.content`, clamped (never rejected). */
+    contentChars: 100,
+    /** `AcceptanceItem.check`, clamped. May be empty: a weak criterion, not an error. */
+    checkChars: 120,
+    /** `AcceptanceItem.evidence`, clamped. */
+    evidenceChars: 200,
+    /**
+     * A FRESH plan must declare at least this many usable criteria (§6.2.3 step 4).
+     * Gated on an EMPTY store AND on `todo.acceptance` being on: the requirement is
+     * "plan the criteria too", so it applies exactly where the capability does.
+     * Named `...Criteria`, not `...Items`, so it cannot be confused with
+     * `TODO_LIMITS.minFreshItems` (2) used two steps earlier.
+     */
+    minFreshCriteria: 1,
+};
+/**
+ * TODO_RESULT_LIMITS - the bound on what `todo_write` returns each turn
+ * (I-11 / §6.4.4). The acceptance paragraph pushes the text from about 700
+ * characters to roughly 1100, and every character is paid for on every call, so
+ * the ceiling is structural rather than advisory.
+ */
+export const TODO_RESULT_LIMITS = {
+    maxChars: 1400,
+    /** Appended when the text had to be clipped, so a clipped answer says so. */
+    truncationNote: 'Note: result text truncated.',
+};
+/**
+ * VERIFY_MESSAGE_LIMITS - the CONSTRUCTIVE bound of `buildVerifyMessage`
+ * (§6.6.2 / AC-22), in the tradition of `buildChildDigest`: independent of how
+ * long the lists are, because every row it emits is clamped.
+ *
+ * The two numbers are ONE arithmetic, measured rather than estimated: at 5
+ * unchecked + 2 failed with `check` at 100 and `evidence` at 60 the worst case is
+ * 19 rows / 1699 characters, leaving 101 characters below `maxChars` and one row
+ * below `maxRows`.
+ */
+export const VERIFY_MESSAGE_LIMITS = {
+    uncheckedItems: 5,
+    failedItems: 2,
+    checkChars: 100,
+    evidenceChars: 60,
+    maxChars: 1800,
+    maxRows: 20,
+};

package/dist/todo/panel-rows.d.ts

@@ -1,55 +1,45 @@
 /**
- * `selectTodoRows` — which items the rail shows (todo-plan-execution §3.10).
+ * Which rows the rail shows (todo-plan-execution §3.10).
  *
  * 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 this feature by a wide margin.
- * The rail therefore never scrolls - it windows around the item 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-item plan shows steps 1-8 - all
- * completed - and hides the one the user is actually watching.
+ * THE ALGORITHM LIVES IN `row-window.ts` since todo-acceptance-criteria §6.9.4:
+ * the acceptance section needs the same anchored-window fixpoint over a different
+ * item shape, and two copies of it would be two places for the "anchor must stay
+ * visible" rule to rot. The three exports below keep their EXACT signatures and
+ * their field-for-field output (AC-13), so every existing caller and test is
+ * unaffected.
  */
-import type { TodoItem } from './types.js';
-export interface TodoRowSelection {
-    visible: {
-        item: TodoItem;
-        index: number;
-    }[];
-    hiddenAbove: number;
-    hiddenBelow: number;
-}
+import type { AcceptanceItem, TodoItem } from './types.js';
+import { type RowWindow } from './row-window.js';
+export type TodoRowSelection = RowWindow<TodoItem>;
+export type AcceptanceRowSelection = RowWindow<AcceptanceItem>;
 /**
- * The row the window is built around: the item in progress, or the first
+ * The row the todo window is built around: the item in progress, or the first
  * unfinished one, or the last item when everything is done.
  *
  * `normalizeTodos` guarantees an `in_progress` item whenever one is not
- * completed (I-3), so the second branch is a belt-and-braces path for a list
- * this module was handed without going through the store.
+ * completed (I-3), so the second branch is a belt-and-braces path for a list this
+ * module was handed without going through the store.
+ */
+export declare function todoAnchorIndex(items: readonly TodoItem[]): number;
+/**
+ * The row the acceptance window is built around (§6.9.4): the criterion being
+ * checked, or the first unchecked one, or the last row when every verdict is in.
+ *
+ * THE `in_progress` BRANCH IS THE WHOLE POINT. Without it the anchor would be
+ * "first pending", so re-sending the list while checking criterion 3 would snap
+ * the rail back to criterion 1 - the F-2 lesson again, one feature later.
  */
-export declare function todoAnchorIndex(items: TodoItem[]): number;
+export declare function acceptanceAnchorIndex(items: readonly AcceptanceItem[]): number;
 /**
  * @param maxRows Rows available for the item rows AND the two overflow markers
  *                together. The shared layout subtracts actual team/menu rows.
- *
- * 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 item 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. The full rail has at least four item rows. The compact rail uses
- * `selectCompactTodoRows` with a single merged footer instead.
  */
 export declare function selectTodoRows(items: TodoItem[], maxRows: number): TodoRowSelection;
-/** Select an anchored contiguous window without reserving overflow-marker rows.
- * maxItemRows is a row count; invalid/nonpositive values return an empty window
- * with every item counted below it. Does not mutate the list or throw.
- */
+/** Select an anchored contiguous window without reserving overflow-marker rows. */
 export declare function selectCompactTodoRows(items: TodoItem[], maxItemRows: number): TodoRowSelection;
+/** The acceptance section's window; same discipline, same anchors, other shape. */
+export declare function selectAcceptanceRows(items: AcceptanceItem[], maxRows: number): AcceptanceRowSelection;
+/** The acceptance section's compact window (summary rung uses this). */
+export declare function selectCompactAcceptanceRows(items: AcceptanceItem[], maxRows: number): AcceptanceRowSelection;

package/dist/todo/panel-rows.js

@@ -1,29 +1,23 @@
 /**
- * `selectTodoRows` — which items the rail shows (todo-plan-execution §3.10).
+ * Which rows the rail shows (todo-plan-execution §3.10).
  *
  * 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 this feature by a wide margin.
- * The rail therefore never scrolls - it windows around the item 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-item plan shows steps 1-8 - all
- * completed - and hides the one the user is actually watching.
+ * THE ALGORITHM LIVES IN `row-window.ts` since todo-acceptance-criteria §6.9.4:
+ * the acceptance section needs the same anchored-window fixpoint over a different
+ * item shape, and two copies of it would be two places for the "anchor must stay
+ * visible" rule to rot. The three exports below keep their EXACT signatures and
+ * their field-for-field output (AC-13), so every existing caller and test is
+ * unaffected.
  */
+import { selectCompactRowsAround, selectRowsAround } from './row-window.js';
 /**
- * The row the window is built around: the item in progress, or the first
+ * The row the todo window is built around: the item in progress, or the first
  * unfinished one, or the last item when everything is done.
  *
  * `normalizeTodos` guarantees an `in_progress` item whenever one is not
- * completed (I-3), so the second branch is a belt-and-braces path for a list
- * this module was handed without going through the store.
+ * completed (I-3), so the second branch is a belt-and-braces path for a list this
+ * module was handed without going through the store.
  */
 export function todoAnchorIndex(items) {
     if (items.length === 0)
@@ -37,80 +31,40 @@ export function todoAnchorIndex(items) {
     return items.length - 1;
 }
 /**
- * How much of the window sits ABOVE the anchor.
+ * The row the acceptance window is built around (§6.9.4): the criterion being
+ * checked, or the first unchecked one, or the last row when every verdict is in.
  *
- * 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".
+ * THE `in_progress` BRANCH IS THE WHOLE POINT. Without it the anchor would be
+ * "first pending", so re-sending the list while checking criterion 3 would snap
+ * the rail back to criterion 1 - the F-2 lesson again, one feature later.
  */
-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 };
+export function acceptanceAnchorIndex(items) {
+    if (items.length === 0)
+        return 0;
+    const active = items.findIndex((item) => item.status === 'in_progress');
+    if (active >= 0)
+        return active;
+    const unchecked = items.findIndex((item) => item.status === 'pending' || item.status === 'in_progress');
+    if (unchecked >= 0)
+        return unchecked;
+    return items.length - 1;
 }
 /**
  * @param maxRows Rows available for the item rows AND the two overflow markers
  *                together. The shared layout subtracts actual team/menu rows.
- *
- * 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 item 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. The full rail has at least four item rows. The compact rail uses
- * `selectCompactTodoRows` with a single merged footer instead.
  */
 export function selectTodoRows(items, maxRows) {
-    const count = items.length;
-    const anchor = todoAnchorIndex(items);
-    if (count === 0)
-        return { visible: [], hiddenAbove: 0, hiddenBelow: 0 };
-    if (maxRows <= 0) {
-        return { visible: [], hiddenAbove: anchor, hiddenBelow: count - 1 - anchor };
-    }
-    // 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, anchor, 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 };
+    return selectRowsAround(items, maxRows, todoAnchorIndex);
 }
-/** Select an anchored contiguous window without reserving overflow-marker rows.
- * maxItemRows is a row count; invalid/nonpositive values return an empty window
- * with every item counted below it. Does not mutate the list or throw.
- */
+/** Select an anchored contiguous window without reserving overflow-marker rows. */
 export function selectCompactTodoRows(items, maxItemRows) {
-    const slots = Number.isFinite(maxItemRows) ? Math.max(0, Math.floor(maxItemRows)) : 0;
-    if (slots === 0 || items.length === 0) {
-        return { visible: [], hiddenAbove: 0, hiddenBelow: items.length };
-    }
-    const { start, end } = windowFor(items.length, todoAnchorIndex(items), slots);
-    return {
-        visible: items.slice(start, end).map((item, offset) => ({ item, index: start + offset })),
-        hiddenAbove: start,
-        hiddenBelow: items.length - end,
-    };
+    return selectCompactRowsAround(items, maxItemRows, todoAnchorIndex);
+}
+/** The acceptance section's window; same discipline, same anchors, other shape. */
+export function selectAcceptanceRows(items, maxRows) {
+    return selectRowsAround(items, maxRows, acceptanceAnchorIndex);
+}
+/** The acceptance section's compact window (summary rung uses this). */
+export function selectCompactAcceptanceRows(items, maxRows) {
+    return selectCompactRowsAround(items, maxRows, acceptanceAnchorIndex);
 }