@aragon-agent/cli 0.6.47 → 0.6.48

package/dist/todo/follow-through.js

@@ -1,248 +0,0 @@
-/**
- * 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.
- *
- * PURE. No I/O, no timers, no React, no `Date.now()` — the discipline
- * `TodoStore`'s injected clock already establishes. The TUI (`App.tsx`) and
- * headless mode (`agent/headless.ts`) both call `decideFollowThrough`, which is
- * the only reason the two cannot drift; a second copy of this table in either
- * caller is the defect this file exists to prevent.
- *
- * 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 plan. */
-export function emptyBudget() {
-    return { used: 0, noProgressStreak: 0, anchorTotal: 0, doneAtRunStart: 0 };
-}
-/**
- * Round 1's notice, preserved BYTE FOR BYTE (AC-1).
- *
- * This is what makes `followThrough: 'notify'` — the default — indistinguishable
- * from `bf6aeb1a` on the path that matters. Its singular/plural treatment
- * ("item is" / "items are") is round 1's; the strings added by this round use
- * "steps", the noun `<todo_planning>` and the rail already use.
- */
-function legacyUnfinishedNotice(left) {
-    return (`${left} todo ${left === 1 ? 'item is' : 'items are'} unfinished. ` +
-        'Use /todo continue to pick up where this run stopped, or /todo clear to drop it.');
-}
-/** `/todo continue ...` advice, which means nothing in `-p`. */
-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 - 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 = 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' };
-    // 3. A BUG FIX, NOT A POLICY (D-5). The user pressed Esc; restating what they
-    //    interrupted is the CLI answering a question nobody asked, and offering to
-    //    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.
-    if (runEnd.errored) {
-        return {
-            kind: 'notify',
-            level: 'warn',
-            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 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
-                ? `${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.
-    if (budget.used >= TODO_FOLLOW_LIMITS.maxAutoContinuesPerList) {
-        return {
-            kind: 'notify',
-            level: 'warn',
-            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: 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: 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)`,
-    };
-}
-/**
- * Fold a finished run into the budget. Called BEFORE `decideFollowThrough`, on
- * 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).
- */
-export function advanceBudget(prev, snapshot, wasAutoContinuation) {
-    // 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 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 (anchor !== prev.anchorTotal) {
-        return {
-            used: prev.used,
-            noProgressStreak: 0,
-            anchorTotal: anchor,
-            doneAtRunStart: progress,
-        };
-    }
-    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
-        ? 0
-        : wasAutoContinuation
-            ? prev.noProgressStreak + 1
-            : prev.noProgressStreak;
-    return {
-        used: prev.used,
-        noProgressStreak,
-        anchorTotal: prev.anchorTotal,
-        // Assigned in EVERY branch, which is what makes the next call's comparison
-        // meaningful.
-        doneAtRunStart: progress,
-    };
-}
-/**
- * The text an auto-continuation — or `/todo continue` — submits.
- *
- * 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.
- *
- * 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 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) {
-    const remaining = snapshot.items
-        .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,
-        'Work the next one, then call todo_write to mark it completed and the following ' +
-            'one in_progress before you move on.',
-    ].join('\n');
-}

package/dist/todo/limits.d.ts

@@ -1,152 +0,0 @@
-/**
- * TODO_LIMITS — the single authority on every structural bound this subsystem
- * enforces (todo-plan-execution §4.2).
- *
- * ASCII ONLY: `src/todo/**` is inside the glyph scanner's scope
- * (`glyphs.test.ts`), whose `inScope` regex this feature extends. A NEW TREE IS
- * INVISIBLE TO THAT SCAN UNTIL IT IS ADDED (C-4), which is a guard rail that
- * silently stops guarding — the same hole the team feature had to close for
- * `team/`.
- *
- * TWO KINDS OF NUMBER, AND THEY ARE NOT INTERCHANGEABLE — the distinction
- * `TEAM_LIMITS` records at length:
- *
- *  - Everything below is STRUCTURAL: what the panel can physically carry, what
- *    a plan can mean, what a payload may weigh. A user has no business tuning
- *    them, so they are constants.
- *  - The two `todo.*` config keys (`config/schema.ts`) are POLICY: register the
- *    tool at all, render the rail at all. They are clamped, persisted and
- *    user-facing.
- */
-export declare const TODO_LIMITS: {
-    /** Items one list may hold. Extras are dropped with a repair note. */
-    readonly maxItems: 20;
-    /** `TodoItem.content`, clamped (never rejected). */
-    readonly contentChars: 80;
-    /** `TodoItem.activeForm`, clamped. */
-    readonly activeFormChars: 80;
-    /**
-     * Below this, a FRESH list is refused - the structural half of R-c ("simple
-     * tasks are done directly, not planned"). Gated on an EMPTY store: shrinking
-     * an existing list to one item is legitimate, so the guard must not fire
-     * there (§3.3 step 2).
-     */
-    readonly minFreshItems: 2;
-    /** Minimum shared middle rows for the compact rail. */
-    readonly panelMinRows: 3;
-    /** Full rail includes a blank separator and separate overflow markers. */
-    readonly panelFullRows: 6;
-    /** Below this many terminal columns the status-bar counter degrades to `[3/7]`. */
-    readonly statusCompactCols: 100;
-    /**
-     * Consecutive user turns an UNFINISHED list survives without a `todo_write`
-     * before `beginUserTurn()` drops it (§3.2 / P1-7). Three keeps the common
-     * interruption sequence ("wait, explain X" / "and Y?" / "ok, continue")
-     * intact and returns the column on the fourth unrelated turn.
-     */
-    readonly staleTurns: 3;
-};
-/**
- * TODO_FOLLOW_LIMITS — the economy that makes auto-continue's worst case
- * ARITHMETIC rather than trust (todo-plan-followthrough §8.1).
- *
- * STRUCTURAL, NOT POLICY, exactly like `TODO_LIMITS` above: `todo.followThrough`
- * is the user-facing knob and it decides only WHETHER the loop runs. How far it
- * may run is not something a user has any way to reason about, and a setting
- * here would be a setting whose wrong value is a bill.
- */
-export declare const TODO_FOLLOW_LIMITS: {
-    /**
-     * Auto-continuations for ONE LIST LINEAGE, however productive, and NOT reset
-     * by a re-plan (P0-1 / D-16). See `FollowThroughBudget.used`.
-     *
-     * DELIBERATELY GREATER THAN `TODO_LIMITS.maxItems` (20): a fully productive
-     * 20-step plan must never be cut off by the total cap, so the cap only ever
-     * binds on pathology. Lowering it below `maxItems` would make the ceiling fire
-     * on success, which is the one thing it must not do.
-     */
-    readonly maxAutoContinuesPerList: 25;
-    /**
-     * Consecutive auto-continuations that completed nothing before control goes
-     * back to the human. Two, so a model that merely forgot to tick an item gets
-     * exactly one free nudge and a model that has stopped engaging with its own
-     * plan does not get a third.
-     */
-    readonly maxNoProgressContinues: 2;
-    /**
-     * Interactive grace window before an armed continuation fires. The notice text
-     * derives its "in Ns" from THIS value rather than spelling 3 again, so the two
-     * cannot disagree.
-     */
-    readonly graceMs: 3000;
-};
-/**
- * Bumped whenever the wording of the `<todo_planning>` block changes - INCLUDING
- * either `{{VISIBILITY}}` variant, which is part of the block - so a behaviour
- * report can be tied to a block revision with one grep.
- *
- * 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 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

@@ -1,152 +0,0 @@
-/**
- * TODO_LIMITS — the single authority on every structural bound this subsystem
- * enforces (todo-plan-execution §4.2).
- *
- * ASCII ONLY: `src/todo/**` is inside the glyph scanner's scope
- * (`glyphs.test.ts`), whose `inScope` regex this feature extends. A NEW TREE IS
- * INVISIBLE TO THAT SCAN UNTIL IT IS ADDED (C-4), which is a guard rail that
- * silently stops guarding — the same hole the team feature had to close for
- * `team/`.
- *
- * TWO KINDS OF NUMBER, AND THEY ARE NOT INTERCHANGEABLE — the distinction
- * `TEAM_LIMITS` records at length:
- *
- *  - Everything below is STRUCTURAL: what the panel can physically carry, what
- *    a plan can mean, what a payload may weigh. A user has no business tuning
- *    them, so they are constants.
- *  - The two `todo.*` config keys (`config/schema.ts`) are POLICY: register the
- *    tool at all, render the rail at all. They are clamped, persisted and
- *    user-facing.
- */
-export const TODO_LIMITS = {
-    /** Items one list may hold. Extras are dropped with a repair note. */
-    maxItems: 20,
-    /** `TodoItem.content`, clamped (never rejected). */
-    contentChars: 80,
-    /** `TodoItem.activeForm`, clamped. */
-    activeFormChars: 80,
-    /**
-     * Below this, a FRESH list is refused - the structural half of R-c ("simple
-     * tasks are done directly, not planned"). Gated on an EMPTY store: shrinking
-     * an existing list to one item is legitimate, so the guard must not fire
-     * there (§3.3 step 2).
-     */
-    minFreshItems: 2,
-    /** Minimum shared middle rows for the compact rail. */
-    panelMinRows: 3,
-    /** Full rail includes a blank separator and separate overflow markers. */
-    panelFullRows: 6,
-    /** Below this many terminal columns the status-bar counter degrades to `[3/7]`. */
-    statusCompactCols: 100,
-    /**
-     * Consecutive user turns an UNFINISHED list survives without a `todo_write`
-     * before `beginUserTurn()` drops it (§3.2 / P1-7). Three keeps the common
-     * interruption sequence ("wait, explain X" / "and Y?" / "ok, continue")
-     * intact and returns the column on the fourth unrelated turn.
-     */
-    staleTurns: 3,
-};
-/**
- * TODO_FOLLOW_LIMITS — the economy that makes auto-continue's worst case
- * ARITHMETIC rather than trust (todo-plan-followthrough §8.1).
- *
- * STRUCTURAL, NOT POLICY, exactly like `TODO_LIMITS` above: `todo.followThrough`
- * is the user-facing knob and it decides only WHETHER the loop runs. How far it
- * may run is not something a user has any way to reason about, and a setting
- * here would be a setting whose wrong value is a bill.
- */
-export const TODO_FOLLOW_LIMITS = {
-    /**
-     * Auto-continuations for ONE LIST LINEAGE, however productive, and NOT reset
-     * by a re-plan (P0-1 / D-16). See `FollowThroughBudget.used`.
-     *
-     * DELIBERATELY GREATER THAN `TODO_LIMITS.maxItems` (20): a fully productive
-     * 20-step plan must never be cut off by the total cap, so the cap only ever
-     * binds on pathology. Lowering it below `maxItems` would make the ceiling fire
-     * on success, which is the one thing it must not do.
-     */
-    maxAutoContinuesPerList: 25,
-    /**
-     * Consecutive auto-continuations that completed nothing before control goes
-     * back to the human. Two, so a model that merely forgot to tick an item gets
-     * exactly one free nudge and a model that has stopped engaging with its own
-     * plan does not get a third.
-     */
-    maxNoProgressContinues: 2,
-    /**
-     * Interactive grace window before an armed continuation fires. The notice text
-     * derives its "in Ns" from THIS value rather than spelling 3 again, so the two
-     * cannot disagree.
-     */
-    graceMs: 3000,
-};
-/**
- * Bumped whenever the wording of the `<todo_planning>` block changes - INCLUDING
- * either `{{VISIBILITY}}` variant, which is part of the block - so a behaviour
- * report can be tied to a block revision with one grep.
- *
- * 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 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,45 +0,0 @@
-/**
- * Which rows the rail shows (todo-plan-execution §3.10).
- *
- * ASCII ONLY: `src/todo/**` is inside the glyph scanner's scope.
- *
- * 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 { 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 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.
- */
-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 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.
- */
-export declare function selectTodoRows(items: TodoItem[], maxRows: number): TodoRowSelection;
-/** 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,70 +0,0 @@
-/**
- * Which rows the rail shows (todo-plan-execution §3.10).
- *
- * ASCII ONLY: `src/todo/**` is inside the glyph scanner's scope.
- *
- * 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 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.
- */
-export function todoAnchorIndex(items) {
-    if (items.length === 0)
-        return 0;
-    const active = items.findIndex((item) => item.status === 'in_progress');
-    if (active >= 0)
-        return active;
-    const unfinished = items.findIndex((item) => item.status !== 'completed');
-    if (unfinished >= 0)
-        return unfinished;
-    return items.length - 1;
-}
-/**
- * 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 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.
- */
-export function selectTodoRows(items, maxRows) {
-    return selectRowsAround(items, maxRows, todoAnchorIndex);
-}
-/** Select an anchored contiguous window without reserving overflow-marker rows. */
-export function selectCompactTodoRows(items, maxItemRows) {
-    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);
-}