@aragon-agent/cli 0.6.47 → 0.6.48

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

@@ -1,60 +0,0 @@
-/**
- * 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

@@ -1,108 +0,0 @@
-/**
- * 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/row-window.d.ts

@@ -1,51 +0,0 @@
-/**
- * `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

@@ -1,107 +0,0 @@
-/**
- * `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 };
-}

package/dist/todo/types.d.ts

@@ -1,124 +0,0 @@
-/**
- * Runtime shapes for the todo subsystem (todo-plan-execution §5.1).
- *
- * ASCII ONLY: `src/todo/**` is inside the glyph scanner's scope.
- *
- * `TodoEvent` is CLI-LOCAL and is deliberately NOT a member of core's
- * `AgentEvent` union (D-11), exactly as `TeamEvent` is not: core freezes its
- * runtime export list (`public-api.test.ts`) and forbids host coupling
- * (`no-host-coupling.test.ts`), so a new event member would break the first and
- * teach core about a host shape it has no business defining.
- */
-/**
- * Re-exported so `config/schema.ts` can name the mode without importing the
- * decision module (todo-plan-followthrough §3.1). TYPE-ONLY, so the apparent
- * cycle `types -> follow-through -> types` is erased at compile time and there
- * is no runtime import at all.
- */
-export type { FollowThroughMode } from './follow-through.js';
-export type TodoStatus = 'pending' | 'in_progress' | 'completed';
-export interface TodoItem {
-    /** Imperative, sanitized, <= TODO_LIMITS.contentChars. */
-    content: string;
-    /** Present continuous, shown while in progress. Falls back to `content`. */
-    activeForm: string;
-    status: TodoStatus;
-}
-/**
- * The two settled states of a criterion, plus "not checked" and "being checked"
- * (todo-acceptance-criteria §6.1). Mutually exclusive and exhaustive.
- *
- * `in_progress` IS A STORE-OWNED DERIVED STATE (v2, P0-1): the model cannot write
- * it, the tool schema does not expose it, normalization always downgrades it to
- * `pending`, and `TodoStore.write()` re-derives at most one after every commit.
- * That is the same discipline `TodoItem`'s "exactly one in_progress" follows: one
- * state has exactly one writer, otherwise the derived phase, the rail's anchor
- * and the transcript card each read a different "criterion being checked".
- */
-export type AcceptanceStatus = 'pending' | 'in_progress' | 'passed' | 'failed';
-export interface AcceptanceItem {
-    /** One checkable statement, sanitized, <= ACCEPT_LIMITS.contentChars. */
-    content: string;
-    /** How it will be checked (command / file / observation), <= checkChars. */
-    check: string;
-    status: AcceptanceStatus;
-    /** Required for `passed` / `failed`; otherwise the verdict drops to `pending`. */
-    evidence: string;
-    /**
-     * Explicit re-open. Only honoured when the same criterion's normalized
-     * `content` is unchanged (§6.2.1 step 9). INPUT ONLY: never stored, consumed
-     * and discarded by `write()`.
-     */
-    reopen?: boolean;
-}
-/** The immutable projection, isomorphic to `TodoSnapshot`. Rebuilt per commit. */
-export interface AcceptanceSnapshot {
-    items: AcceptanceItem[];
-    total: number;
-    /** `passed` + `failed`. */
-    checkedCount: number;
-    passedCount: number;
-    failedCount: number;
-    /** Injected clock, for the same reason `TodoSnapshot.updatedAt` has one (P2-4). */
-    updatedAt: number;
-}
-/**
- * `work`   - at least one step is not completed.
- * `verify` - every step is completed and at least one criterion is unresolved.
- * `done`   - every step is completed and every criterion is settled (or there is
- *            no acceptance table at all).
- *
- * DERIVED, NEVER STORED (I-3): `derivePlanPhase` is the only judge.
- */
-export type PlanPhase = 'work' | 'verify' | 'done';
-/** The immutable projection the UI renders. Rebuilt on every write. */
-export interface TodoSnapshot {
-    items: TodoItem[];
-    total: number;
-    doneCount: number;
-    /** Index of the single in_progress item, or -1 when everything is completed. */
-    activeIndex: number;
-    /**
-     * Stamped by an INJECTED clock (`TodoStore`'s constructor takes
-     * `now?: () => number`, defaulting to `Date.now`), for the reason `TeamPanel`
-     * takes a `now?` prop: a snapshot test that reads the wall clock is a test
-     * that fails on a slow machine and nowhere else (P2-4).
-     */
-    updatedAt: number;
-    /**
-     * The acceptance projection; `null` when there are no criteria (or the
-     * capability is off).
-     *
-     * REQUIRED, NOT OPTIONAL (fail-closed, §6.1): `TodoStore` is the only writer and
-     * it always knows what belongs here. Optional would let one call site silently
-     * under-report an entire table. The cost is the 15 existing test fixtures that
-     * spell out a `TodoSnapshot` literal (§7.3) - a mechanical edit, done in the
-     * same step as this field.
-     */
-    acceptance: AcceptanceSnapshot | null;
-}
-/**
- * Why a list went away.
- *
- *   `user`  - `/todo clear`, or `/clear screen` (the screen-only form). Both are
- *             an explicit user instruction, which is I-2's standing exception;
- *             neither touches `messages`.
- *   `reset` - `/clear` (or its alias `/reset`) through `clearMessages()`, or a
- *             `/resume` whose file carried no list (§3.13).
- *   `turn`  - a new TUI task started, or a legacy caller began a turn after
- *             every item was completed.
- *   `stale` - unfinished, and unwritten for more than `TODO_LIMITS.staleTurns`
- *             consecutive turns (§3.2 / P1-7).
- */
-export type TodoClearReason = 'user' | 'reset' | 'turn' | 'stale';
-export type TodoEvent = {
-    type: 'updated';
-    snapshot: TodoSnapshot;
-} | {
-    type: 'rejected';
-    reason: string;
-} | {
-    type: 'cleared';
-    reason: TodoClearReason;
-};
-export type TodoEventListener = (event: TodoEvent) => void;

package/dist/todo/types.js

@@ -1,12 +0,0 @@
-/**
- * Runtime shapes for the todo subsystem (todo-plan-execution §5.1).
- *
- * ASCII ONLY: `src/todo/**` is inside the glyph scanner's scope.
- *
- * `TodoEvent` is CLI-LOCAL and is deliberately NOT a member of core's
- * `AgentEvent` union (D-11), exactly as `TeamEvent` is not: core freezes its
- * runtime export list (`public-api.test.ts`) and forbids host coupling
- * (`no-host-coupling.test.ts`), so a new event member would break the first and
- * teach core about a host shape it has no business defining.
- */
-export {};

package/dist/tools/human-input.d.ts

@@ -1,212 +0,0 @@
-/**
- * The human-input channel (plan-mode §3.5 / §5.1) — types, the fail-closed
- * default gate, and the two pure normalizers that repair whatever the model
- * actually sent.
- *
- * Everything here is pure except the type declarations: no Ink, no React, no
- * `node:*`. `tools/` is inside the glyph scanner's scope, so every literal is
- * ASCII.
- *
- * WHY THE NORMALIZERS ARE THE ONLY AUTHORITY ON THE LIMITS (P0-4). The
- * model-facing schemas in `plan-tools.ts` declare SHAPE only — `type`,
- * `required`, `default` — and put every bound in the `description`. They used to
- * carry `minItems` / `maxItems` / `maxLength`, and that had two failure modes at
- * once: `ToolExecutor` rejected a six-question call outright with `Invalid
- * parameters: ...` before any repair could run, wasting a full research turn on
- * a cosmetic defect; and `ajv` is an OPTIONAL dependency of core, so without it
- * the fallback validator checks `required` plus primitive types only and the
- * same call sailed through. One design, two behaviours, selected by whether an
- * optional install step succeeded. Bounds live here instead, where they are
- * deterministic and unit-tested.
- */
-export interface NormalizedOption {
-    label: string;
-    /** `''` when the model supplied none. */
-    description: string;
-    /** Exactly one per question is true after repair. */
-    recommended: boolean;
-    /** The synthetic free-text option. */
-    isOther: boolean;
-}
-export interface NormalizedQuestion {
-    id: string;
-    /** <= 12 chars, truncated. Rendered as a chip above the question. */
-    header: string;
-    question: string;
-    /** 3..5 entries: the 2..4 the model gave, plus the synthetic `Other`. */
-    options: NormalizedOption[];
-    allowMultiple: boolean;
-}
-export interface Answer {
-    id: string;
-    question: string;
-    /** Option labels. Length 1 unless `allowMultiple`. */
-    selected: string[];
-    /** Set only when `Other` was chosen. */
-    custom: string | null;
-}
-export interface NormalizedPlan {
-    title: string;
-    summary: string;
-    steps: {
-        title: string;
-        detail: string;
-    }[];
-    filesTouched: string[];
-    risks: string[];
-    openQuestions: string[];
-}
-export type HumanRequest = {
-    kind: 'questions';
-    questions: NormalizedQuestion[];
-} | {
-    kind: 'plan';
-    plan: NormalizedPlan;
-};
-export type HumanResponse = {
-    kind: 'answers';
-    answers: Answer[];
-    cancelled: boolean;
-} | {
-    kind: 'planDecision';
-    decision: 'approved' | 'revise' | 'dismissed';
-    feedback: string;
-};
-export interface HumanInputGate {
-    /**
-     * STATIC property of the channel: `true` only for a gate that can never
-     * acquire a human at all. Set on `DENY_ALL_HUMAN_INPUT` and nowhere else.
-     *
-     * This — not `canPrompt()` — is what `createPlanTools()` keys registration
-     * off. `canPrompt()` is a LIVE probe and is legitimately `false` for the whole
-     * window between `makeController()` and the App's first effect, because the
-     * App attaches the bridge handler later. A registration decision taken from it
-     * would be "no plan tools", forever, in every interactive session, with no
-     * error anywhere. The two predicates answer different questions and must not
-     * be merged.
-     */
-    readonly neverPrompts?: boolean;
-    /** True only while a TUI is mounted and able to render an overlay. */
-    canPrompt(): boolean;
-    /**
-     * Resolves with `null` when cancelled / unmounted / aborted. NEVER rejects.
-     *
-     * `signal` is the tool's `ctx.signal` and is REQUIRED in practice. It is the
-     * only ceiling the wait has: `ToolExecutor`'s timeout is cooperative — it
-     * aborts the context signal and keeps awaiting the tool's promise, with no
-     * `Promise.race` anywhere — and the idle watchdog is deliberately paused for
-     * the duration of the wait. Passing `undefined` therefore gives a wait with no
-     * ceiling of any kind, and the process wedges behind an overlay nobody is
-     * going to answer.
-     */
-    request(req: HumanRequest, signal?: AbortSignal): Promise<HumanResponse | null>;
-}
-export interface HumanInputBridge {
-    handler: ((req: HumanRequest, signal?: AbortSignal) => Promise<HumanResponse | null>) | null;
-    /**
-     * Resolve every outstanding request with `null`.
-     *
-     * Called on App unmount AND when a run ends. `ConfirmBridge` nulls its handler
-     * on unmount but leaves any in-flight promise dangling forever; with a
-     * three-second `y/N` that never mattered, but a question wizard the user
-     * abandons with `Ctrl+C` twice would hang the tool until its ceiling.
-     */
-    cancelPending(): void;
-}
-/**
- * Fails CLOSED. The headless default — forgetting to pass a gate must refuse,
- * never hang and never assume yes.
- */
-export declare const DENY_ALL_HUMAN_INPUT: HumanInputGate;
-export declare const QUESTION_LIMITS: {
-    readonly maxQuestions: 5;
-    readonly minOptions: 2;
-    readonly maxOptions: 4;
-    readonly headerChars: 12;
-    readonly questionChars: 300;
-    readonly labelChars: 60;
-    readonly optionDescriptionChars: 120;
-};
-export declare const PLAN_LIMITS: {
-    readonly titleChars: 80;
-    readonly summaryChars: 600;
-    readonly maxSteps: 20;
-    readonly stepTitleChars: 100;
-    readonly stepDetailChars: 400;
-    readonly maxFiles: 30;
-    readonly maxRisks: 10;
-    readonly maxOpenQuestions: 10;
-};
-/**
- * The STORAGE bound of the `ask_user` de-duplication guard — NOT a refusal
- * condition, and the distinction is the whole point.
- *
- * Storage is memory hygiene: a turn that asks a thousand DISTINCT question sets
- * is pathological, but it is still the user's turn, and Esc interrupts it. The
- * refusal rule is semantic: "never ask the same answered questions twice". Folding
- * the bound into the refusal rule would restore the round cap this feature
- * deletes, with a different number written on it.
- *
- * Owned here rather than in `plan-tools.ts` (the caller) or `controller.ts` (the
- * state holder) because this file is already the single authority on the
- * structural limits of human input, beside `QUESTION_LIMITS` / `PLAN_LIMITS`.
- */
-export declare const ASK_GUARD_LIMITS: {
-    readonly maxRemembered: 128;
-};
-/**
- * Trim to `max` characters, preferring a word boundary within the last
- * `WORD_BOUNDARY_WINDOW` characters. Cutting a sentence mid-word reads as
- * corruption; cutting it at a space reads as a summary.
- */
-export declare function clampText(raw: unknown, max: number): string;
-/**
- * Repair whatever the model sent into something renderable.
- *
- * Returns `[]` when nothing survives, which the tool turns into the one hard
- * failure this path has. Every rule below is reachable precisely BECAUSE the
- * schema stopped declaring the bounds (P0-4); with `minItems` / `maxItems` in
- * the schema, `ajv` rejected the call first and rules 1 and 4 were dead code.
- */
-export declare function normalizeQuestions(raw: unknown): NormalizedQuestion[];
-/**
- * Repair a submitted plan. Returns `null` only when no step survives — the one
- * hard failure, because there is then nothing left to review.
- *
- * A plan that is one step over the cap is still a plan, and rejecting it costs a
- * full research turn to regain nothing. Truncation is silent to the model but
- * VISIBLE to the user: the review overlay's position indicator counts the real
- * rows, so a clipped plan cannot masquerade as complete.
- */
-export declare function normalizePlan(raw: unknown): NormalizedPlan | null;
-export interface AnswersResultShape {
-    answers: Answer[];
-    cancelled: boolean;
-}
-/**
- * A question SET's identity: the question texts, trimmed, lowercased, whitespace
- * collapsed, sorted, joined.
- *
- * `id` and `header` are excluded on purpose — a model that re-asks the same thing
- * under a new id is asking the same thing, and the ids are the model's own
- * bookkeeping rather than part of what the user reads.
- *
- * The fingerprint is stable because `normalizeQuestions` already ran on the TOOL
- * side: header truncation and option trimming cannot make the same question look
- * different here. Worst case is 5 questions x 300 chars = 1,500 chars.
- */
-export declare function questionFingerprint(questions: NormalizedQuestion[]): string;
-/**
- * Render the `ask_user` result: one human-readable line so the transcript
- * preview is legible without parsing, then the JSON the model reads.
- *
- * CARRIES NO ROUND COUNTER, deliberately (D-4). The model used to be told
- * `roundsUsed` / `roundsRemaining` on every call, which is a per-turn reminder
- * that it is running out — and an agent that reads "you have 1 round left"
- * behaves like one. There is no limit any more, so there is nothing to report.
- *
- * `asked` is passed separately rather than derived from `answers.length`
- * because a cancelled wizard returns fewer answers than it asked for, and
- * "answered 1 of 3" is the whole information content of that line.
- */
-export declare function formatAnswersResult(shape: AnswersResultShape, asked: number): string;