toolroll 0.9.104 → 0.9.105

package/dist/telegram-live.d.ts

@@ -1,116 +0,0 @@
-/**
- * The paired phone's live reply (docs/plans/responsive-chat.md §3.1): a 👀 on the owner's message as soon as it is
- * saved, and while the lead works one Bot API message draft (`sendMessageDraft`, private chats only) that shows the
- * status line and the reply as it is written.
- *
- * Nothing here is durable or authoritative. A draft is Telegram's "temporary 30-second preview": it disappears when the
- * bot sends a message or when it is not refreshed, so a draft that is never replaced is harmless. The answer itself is
- * still the planned, receipted `sendMessage` parts (telegram-lead.ts), sent only after this turn's sender has closed.
- * Drafts carry words only: no keyboard, no card, no token. Every draft that carries more than Telegram's own empty
- * "Thinking…" placeholder is sent only after the caller's full standing check (live pairing, approver, the project
- * ceiling the turn opened under, the turn still running under its generation, the row's claim).
- *
- * Rate: Telegram's own retry_after is shared with every other send (`telegramRetryAt` / `deferTelegram`). While it
- * holds, an ack waits and a draft is dropped (the answer and failure notices go first, acks next, drafts last); a
- * draft that is asked to pause widens this turn's spacing.
- */
-import type { LeadProgress } from "./lead-progress.js";
-import { type LiveView } from "./live-reply.js";
-import { type ShapeOptions, type TelegramEntity } from "./reply-shape.js";
-import type { Store } from "./store.js";
-import type { TelegramTransport } from "./telegram.js";
-/** The acknowledgement on the owner's message: "seen, working on it". Removed once the answer or the failure notice is
- * delivered; never replaced by a "done" mark (an answer isn't finished work). */
-export declare const ACK_EMOJI = "\uD83D\uDC40";
-/** At most one reaction change per chat this often; a burst waits its turn, in order. */
-export declare const ACK_GAP_MS = 1000;
-/** Drafts start this far apart and widen (doubling, up to the cap) whenever Telegram asks for a pause. */
-export declare const DRAFT_SPACING_MS = 1200;
-/** Telegram keeps a draft about 30 seconds: one that has not changed is sent again after this long. */
-export declare const DRAFT_KEEPALIVE_MS = 25000;
-/** Telegram's message limit, counted after entities (UTF-16 units, as JS strings are). */
-export declare const TELEGRAM_TEXT_MAX = 4096;
-/** Test seams for the timings above (production uses the defaults). */
-export type TelegramLiveTiming = {
-    ackGapMs?: number;
-    draftSpacingMs?: number;
-    keepAliveMs?: number;
-};
-export type DraftEntity = TelegramEntity | {
-    type: "italic";
-    offset: number;
-    length: number;
-};
-export type DraftPayload = {
-    text: string;
-    entities: DraftEntity[];
-};
-/** The body of a writing draft within `budget` characters once rendered: cut at a safe place in the shaped text first
- * (never inside code, a link, a bold anchor or an emoji), rendered, measured, and cut smaller if it still doesn't fit.
- * A body that can't fit (a single link longer than the budget) shows nothing. */
-export declare function draftBody(shaped: string, budget: number): DraftPayload;
-/**
- * One live view as a draft: the status line in italics, then (once text exists) the partial reply as text plus
- * entities, never Markdown. Plain "Thinking…" is Telegram's own empty-text placeholder. Closed views send nothing.
- */
-export declare function telegramDraftOf(view: LiveView): DraftPayload | null;
-/**
- * Put 👀 on the owner's message (`on`) or take it off. Best effort and never awaited by the caller's durable work: a
- * missing pairing, a failure or a long pause skips it silently. `paired` is re-checked at the moment of sending; a
- * reaction carries no project data, so the pairing alone fences it. Resolves once this change was tried.
- */
-export declare function telegramAck(args: {
-    store: Store;
-    botId: string;
-    transport: TelegramTransport;
-    clock: () => Date;
-    chatId: string;
-    messageId: string;
-    on: boolean;
-    paired: () => boolean;
-    gapMs?: number;
-}): Promise<void>;
-export type TelegramLiveDraft = {
-    /** The turn's progress listener (runLeadTurn's `onProgress`). */
-    onProgress: (event: LeadProgress) => void;
-    /** Stop: nothing more is sent, and the draft in flight has settled when this resolves. Durable delivery comes after. */
-    close: () => Promise<void>;
-    /** The turn the drafts follow, once it started. */
-    readonly turn: number | null;
-};
-/**
- * One running turn's draft. `standing` is the caller's full proof for a draft that carries words (it may await; the
- * close is re-checked after it); `paired` is enough for Telegram's empty "Thinking…". A draft Telegram refuses outright
- * (not a pause, not a lost answer) turns this turn's drafts off; previews are best effort.
- */
-export declare function createTelegramLiveDraft(args: {
-    store: Store;
-    botId: string;
-    transport: TelegramTransport;
-    clock: () => Date;
-    chatId: string;
-    binding: number;
-    draftId: number;
-    shape: ShapeOptions;
-    standing: (turn: number) => Promise<boolean>;
-    paired: () => boolean;
-    timing?: TelegramLiveTiming;
-}): TelegramLiveDraft;
-/**
- * A message waiting for the lead (busy, or behind the owner's earlier messages): "Waiting for your earlier messages…"
- * as a draft, refreshed only after the keep-alive interval, and never while this chat's running turn has its own
- * draft. Carries no project data: the pairing and the claim fence it.
- */
-export declare function telegramWaitingDraft(args: {
-    store: Store;
-    botId: string;
-    transport: TelegramTransport;
-    clock: () => Date;
-    chatId: string;
-    binding: number;
-    draftId: number;
-    allowed: () => boolean;
-    timing?: TelegramLiveTiming;
-}): Promise<void>;
-/** The message is answered or failed: its waiting draft is forgotten. */
-export declare function forgetWaitingDraft(botId: string, draftId: number): void;

package/dist/telegram-progress.d.ts

@@ -1,20 +0,0 @@
-import { type PhoneTaskLink } from "./telegram-status.js";
-import type { Run, Store } from "./store.js";
-import { type TaskStatus, type TaskStatusFacts } from "./task-status.js";
-/** Offsets are UTF-16, as required by Telegram. Only our two headings are bold;
- * user text stays literal, including angle brackets and Markdown characters. */
-export type ProgressEntity = {
-    type: "bold";
-    offset: number;
-    length: number;
-};
-/** `viewer`: the person whose chat shows the card. Their own act is never told back to them. */
-export declare function telegramProgressCard(store: Store, run: Run, taskId: string, project: string, now?: Date, root?: string, viewer?: string): {
-    text: string;
-    entities: ProgressEntity[];
-    link: PhoneTaskLink;
-    next: string;
-    status: TaskStatus;
-    facts: TaskStatusFacts;
-    completedByLead: boolean;
-};

package/dist/telegram-settings.d.ts

@@ -1,9 +0,0 @@
-import type { Store } from "./store.js";
-import { type Html } from "./html.js";
-/** How long a written reply may wait to be sent before it shows here with a Retry. */
-export declare const UNSENT_REPLY_MS: number;
-export declare function telegramSettingsHtml(store: Store, botId: string | null, who: string, options?: {
-    code?: string;
-    problem?: string;
-    now?: Date;
-}): Html;

package/dist/telegram-status.d.ts

@@ -1,83 +0,0 @@
-import { publicChatText } from './chat-display.js';
-import type { Notification, Store } from "./store.js";
-export type PhoneCommand = {
-    kind: "status";
-} | {
-    kind: "help";
-} | {
-    kind: "task";
-    id: string;
-} | {
-    kind: "tasks";
-} | {
-    kind: "lead";
-};
-export declare function phoneCommand(text: string): PhoneCommand | null;
-export declare const PHONE_HELP: string;
-/** The same display scrub for every phone-bound string a person or a model authored. */
-export declare const phoneText: typeof publicChatText;
-export declare function projectLabel(repo: string): string;
-/** The phone's reading of saved results: `root` lets a finished result read its saved checks, requirements and
- * review exactly as the console does. Without it, the dispatch diagnosis speaks. */
-export type PhoneRead = {
-    root?: string | undefined;
-    now?: Date;
-    repos?: readonly string[];
-};
-/** repos is the transport's explicit enrollment ceiling, never opened-project
- * history. This snapshot is intentionally bounded and advertises that bound. */
-export declare function phoneStatus(store: Store, repos: readonly string[], now: Date, focused?: string | null, root?: string): string;
-/** One task a person can pick to talk about from a chat app. */
-export type PhoneTaskChoice = {
-    id: string;
-    title: string;
-    label: string;
-    group: string;
-};
-/** The tasks a paired chat can pick from: what needs the person first,
- * then work in progress, waiting work and recent results; one entry per
- * task (its revisions share it), optionally narrowed by words in the id or
- * title. Bounded, within the chat's own project ceiling. */
-export declare function phoneTaskChoices(store: Store, repos: readonly string[], now: Date, query?: string | null, limit?: number, root?: string): PhoneTaskChoice[];
-/** `id` keys the chat's choice (the task's first version, where its chat
- * lives); `view` is what to show: the exact version named, else the current one. */
-export type PhoneTaskPick = {
-    kind: "one";
-    id: string;
-    view: string;
-    title: string;
-} | {
-    kind: "many";
-    choices: PhoneTaskChoice[];
-} | {
-    kind: "none";
-};
-/** `/task <what>`: an exact task id, a number from the /tasks list, or
- * words from a title — one match is chosen, several are offered. */
-export declare function resolvePhoneTask(store: Store, repos: readonly string[], now: Date, query: string): PhoneTaskPick;
-/** The picker as text, for chat apps without buttons. */
-export declare function phoneTaskListText(choices: readonly PhoneTaskChoice[], focused: string | null): string;
-/** Said under a task's status when a chat app chooses it. */
-export declare const PHONE_FOCUS_LINE = "Talking about this task now: ask anything or say what to change. Reply to this message later to come back to it; /lead goes back to the lead.";
-/** A chosen task's status, then the line that says the chat now talks about it. */
-export declare function phoneFocusText(view: string): string;
-export declare const PHONE_NO_MATCH = "No such task in your connected projects. Send /tasks to pick one.";
-export declare const PHONE_BACK_TO_LEAD = "Back to the lead. Your messages here are about all your work again.";
-/** A fixed console destination for one task, named beside its label; the origin joins it only on the wire. */
-export type PhoneTaskLink = {
-    label: string;
-    path: string;
-};
-/** Where the rest lives when no button can say so: the closing line of an unlinked `/task`. */
-export declare const PHONE_CONSOLE_FOOTER = "Read-only status. Saved files and full actions are in the console.";
-export declare function phoneTask(store: Store, repos: readonly string[], id: string, now: Date, root?: string): string;
-/** One task's status for a chat app: the words, its one console link, and
- * the saved result it shows (a reply to it is about that result). */
-export declare function phoneTaskView(store: Store, repos: readonly string[], id: string, now: Date, root?: string): {
-    text: string;
-    link: PhoneTaskLink | null;
-    run: number | null;
-};
-/** Concise display only: authorization uses the stored full project identity. */
-/** Where a fact belongs: its project and, given one, the task's short title — never the task's id. */
-export declare function notificationIdentity(row: Pick<Notification, "project" | "taskId">, title?: string): string;

package/dist/telegram-team.d.ts

@@ -1,68 +0,0 @@
-/**
- * Telegram inside the shared team conversations (v72): a group follows one
- * team conversation, a private chat may select one, and every message a
- * paired teammate sends there is saved through the same team operation the
- * browser and CLI use — same queue, same single writer, same permissions and
- * spending consent. Replies and teammates' messages come back through a
- * per-chat cursor read on every bridge cycle. No model runs here.
- */
-import type { Store } from "./store.js";
-import { type InlineButton } from "./telegram-lead.js";
-import type { TelegramTransport } from "./telegram.js";
-import type { TelegramMessage } from "./contracts/telegram-callback.js";
-export type TeamCommand = {
-    kind: "list";
-} | {
-    kind: "select";
-    index: number;
-} | {
-    kind: "off";
-};
-/** `/team` lists, `/team <n>` chooses, `/team off` (or `private`) leaves. Any other slash text is not ours. */
-export declare function teamCommand(text: string): TeamCommand | null;
-export declare const PAIR_FIRST = "Pair your phone first: open Settings \u2192 Telegram in Toolroll, then send the code here in a private chat.";
-type Counts = {
-    ignored: number;
-    chatQueued?: number;
-    chatRefused?: number;
-    statusReplies?: number;
-    problems: string[];
-};
-export type TeamInbound = {
-    store: Store;
-    botId: string;
-    now: Date;
-    report: Counts;
-    /** The enrolled ceiling read for this update; null when unreadable. */
-    projects: readonly string[] | null;
-    phoneOrigin: (() => string | null) | undefined;
-    updateId: number;
-    message: TelegramMessage;
-    /** Queue one reply for after the update's transaction commits. */
-    say: (chatId: string, text: string, keyboard?: InlineButton[][]) => void;
-};
-/**
- * Handle one inbound message that belongs to the team layer. Returns true
- * when it was consumed here (a `/team` command in any chat, any message in
- * a group, or a private message while a conversation is selected); false
- * hands the update to the older personal paths untouched.
- */
-export declare function applyTeamInbound(input: TeamInbound): boolean;
-/** The request identity a Telegram message carries into the team queue: the chat and the update, so the same update never saves twice and delivery can tell its own messages apart. */
-export declare function teamRequestId(chatId: string, updateId: number): string;
-type TeamDeliveryReport = {
-    sent: number;
-    problems: string[];
-};
-/**
- * Carry new conversation messages to every chat that follows one: the
- * lead's replies, teammates' messages (never this chat's own), and each
- * reply's pending cards. Read from the cursor on every cycle; a failed send
- * leaves the cursor where it was, so the next cycle retries the same
- * message rather than skipping it.
- */
-export declare function deliverTeamChats(store: Store, botId: string, transport: TelegramTransport, clock: () => Date, report: TeamDeliveryReport, projects: readonly string[], phoneOrigin?: () => string | null, options?: {
-    readProjects?: () => Promise<readonly string[]>;
-    canDeliver?: () => boolean;
-}): Promise<void>;
-export {};

package/dist/telegram.d.ts

@@ -1,271 +0,0 @@
-/**
- * The Telegram bridge: decisions out, answers back, zero tokens spent.
- *
- * This is channel plumbing — no LLM is anywhere in this path, and everything
- * it renders is deterministic. The security model, in one breath: a chat is
- * not a person, so pairing is a local authenticated act that binds one
- * private chat AND one immutable user id to one approver generation; a
- * button is not a command, so callback_data carries only an opaque one-time
- * token whose meaning lives in this database where a stolen bot token
- * cannot read it; and an answer lands in the same transaction that proves
- * the binding is still live and consumes the token — or it does not land.
- *
- * What a stolen bot token CAN do is stated rather than wished away: read
- * the decision text this installation chose to send through Telegram,
- * repaint the bot's keyboards with deceptive labels, and race our poll for
- * updates. It cannot mint an action token, answer as the operator, or make
- * `answered_by` say anything the pairing did not authorize. Rotating the
- * BotFather token plus `bridge telegram unpair` is the recovery, and both
- * are one command.
- */
-import { type Store, type Notification } from "./store.js";
-import { type TelegramConversationOptions } from "./telegram-lead.js";
-export type TelegramReadProjects = () => Promise<readonly string[]>;
-/** The environment name — and therefore the name the builder strips from agents (both names; see names.ts). */
-export { TELEGRAM_TOKEN_ENV as TOKEN_ENV, TELEGRAM_TOKEN_ENVS as TOKEN_ENVS } from "./names.js";
-export declare const PAIRING_TTL_MS: number;
-export declare const BRIDGE_LEASE_MS: number;
-export declare const DELIVERY_CLAIM_MS: number;
-/** Where Telegram pushes this bot's updates: under the public hooks address (Tailscale Funnel covers /hooks). */
-export declare const TELEGRAM_HOOK_PATH = "/hooks/telegram";
-/** The secret Telegram sends with every push (its header), kept beside the database; made once when asked to. */
-export declare function telegramHookSecret(dir: string, make?: boolean): string | null;
-/** The address Telegram pushes to: the public hooks address (https only) and /hooks/telegram; null without one. */
-export declare function telegramPushUrl(hooksBase: string | null): string | null;
-/** A push is Telegram's when its secret header matches ours (compared in constant time). */
-export declare function pushedByTelegram(header: unknown, secret: string | null): boolean;
-/** Keep one pushed update for the bridge. A schema-invalid JSON update is logged and acknowledged, never retried. */
-export declare function keepPushedUpdate(store: Store, botId: string, body: Buffer, now: Date): {
-    ok: true;
-    kept: boolean;
-} | {
-    ok: false;
-};
-export type TokenSource = {
-    token: string;
-    botId: string;
-    source: "env" | "file";
-};
-/**
- * Environment wins, the credential file beside the database otherwise.
- * The file is how the CLI and the web settings card set it (0600, owner
- * only); the env var is how people who already run keychain tooling keep
- * it out of files entirely.
- */
-export declare function loadBotToken(env: Record<string, string | undefined>, file: string): TokenSource | null;
-/** Write the credential file, owner-only. Refuses a string that is not a bot token. */
-export declare function saveBotToken(file: string, token: string): {
-    ok: true;
-} | {
-    ok: false;
-    message: string;
-};
-export declare function clearBotToken(file: string): boolean;
-/** The last four characters are enough to recognize a token without holding it. */
-export declare function redactToken(token: string): string;
-/** Scrub a token out of any text on its way to a log, an error, or a row. */
-export declare function scrub(text: string, token: string): string;
-/**
- * One Bot API call. Injectable, so the suite scripts Telegram instead of
- * dialing it. The optional signal lets a follower cancel a long poll the
- * moment it is told to stop, instead of waiting the poll window out.
- */
-export type TelegramTransport = (method: string, params: Record<string, unknown>, signal?: AbortSignal, 
-/** v64: one verified file to send as multipart — the ONLY way bytes leave. Absent, the call is JSON exactly as before. */
-upload?: TelegramUpload, 
-/** More verified files in the same multipart call: the rest of one album (sendMediaGroup). */
-more?: readonly TelegramUpload[]) => Promise<{
-    ok: boolean;
-    result?: unknown;
-    description?: string;
-    parameters?: {
-        retry_after?: number;
-    };
-    uncertain?: boolean;
-}>;
-/**
- * The one typed shape a file takes onto the wire: bytes the caller already
- * verified, under a name and type the caller chose from the verified
- * kind. There is no path, no URL and no `file_id` form here on purpose —
- * Telegram never fetches anything for us, and nothing on this machine is
- * uploaded by name.
- */
-export type TelegramUpload = {
-    field: "document" | "photo" | `shot${number}`;
-    fileName: string;
-    contentType: "image/png" | "image/jpeg" | "text/plain";
-    bytes: Buffer;
-};
-/** A release card's full terms (release-card.ts) as the document Telegram sends with it: text this process wrote. */
-export declare const termsUpload: (file: {
-    name: string;
-    text: string;
-}) => TelegramUpload;
-export declare function createTransport(token: string, timeoutMs?: number): TelegramTransport;
-/**
- * Why this process can't reach Telegram the way the service does, or null.
- * A coding agent's sandbox fences the network: Codex says so in its own
- * variables, and Claude Code's sandbox routes traffic through a proxy on
- * this computer, which curl uses and Node's fetch does not — so sends fail
- * "fetch failed" while curl works (Oct 2). Builds, checks and agents also
- * get a database of their own, so none of them can hold the live bridge;
- * this keeps an agent-launched `watch` or `bridge` from holding it either.
- */
-export declare function networkFence(env: Record<string, string | undefined>): string | null;
-/** The plain line a fenced process says instead of polling or sending. */
-export declare function networkFenceLine(reason: string): string;
-/** fetch's own message ("fetch failed") with the reason under it, e.g. "fetch failed (EMFILE: too many open files)". */
-export declare function transportError(error: unknown): string;
-/** The multipart body: every param a field (objects as JSON), the file last. Exported for the adapter's own test only. */
-export declare function multipartOf(params: Record<string, unknown>, upload: TelegramUpload, ...more: readonly TelegramUpload[]): FormData;
-export declare function hashPairingCode(code: string): string;
-/** 128 bits, hex — pasteable, and not guessable inside any code's lifetime. */
-export declare function mintPairingCode(): string;
-export type BridgeReport = {
-    sent: number;
-    answered: number;
-    paired: number;
-    ignored: number;
-    /** Updates Telegram still holds beyond this pass's page budget. */
-    backlog: boolean;
-    problems: string[];
-    /** Free-text notes captured as drafts. */
-    noted?: number;
-    /** Digests sent this pass (away mode). */
-    digests?: number;
-    /** Successful replies to read-only phone commands, separate from outbox sends. */
-    statusReplies?: number;
-    /** Ordinary messages persisted for the shared assistant this pass. */
-    chatQueued?: number;
-    /** Assistant replies delivered (including a recovered earlier reply). */
-    chatAnswered?: number;
-    /** Messages settled without a reply from the assistant: refused, failed, unpaired, or answered deterministically. */
-    chatRefused?: number;
-    /** Proposal cards confirmed by a tap this pass. */
-    chatConfirmed?: number;
-    /** v98: another program asked Telegram for this bot's updates (harmless: nothing is lost). */
-    contention?: number;
-    /** v98: Telegram answered that it pushes this bot's updates to a webhook. */
-    webhookActive?: boolean;
-    /** The long poll was ended on purpose because a message was due to go out (live-wakeups.md): not a failure. */
-    deliveryWake?: boolean;
-    /** v98: pushed updates applied this pass. */
-    pushed?: number;
-};
-/**
- * One bridge pass: claim and send what the outbox holds, then read one
- * budgeted window of updates and apply each in its own transaction. Cron
- * calls this; running it twice concurrently loses the lease race and does
- * nothing, which is the design working.
- */
-export declare function bridgePass(store: Store, options: {
-    botId: string;
-    transport: TelegramTransport;
-    clock?: () => Date;
-    owner?: string;
-    /** false: inbound only — another channel is primary and carries the
-     * pages; taps and replies still land here. */
-    deliver?: boolean;
-    readProjects?: TelegramReadProjects;
-    /** Reload channel configuration before every outbound part. */
-    canDeliver?: () => boolean;
-    /** Ordinary text talks to the shared assistant. Absent: text that is not a command or a decision note is ignored, as before. */
-    conversation?: TelegramConversationOptions;
-}): Promise<{
-    ok: true;
-    report: BridgeReport;
-} | {
-    ok: false;
-    reason: "bridge-busy";
-    message: string;
-}>;
-/**
- * The longest long poll the follower may ask for. `createTransport`'s HTTP
- * timeout is 30s and must outlive the poll window, or the client would abort
- * a poll Telegram is still honestly holding open.
- */
-export declare const MAX_POLL_SECONDS = 25;
-export type FollowReport = {
-    cycles: number;
-    sent: number;
-    answered: number;
-    paired: number;
-    ignored: number;
-    problems: string[];
-    statusReplies?: number;
-    chatQueued?: number;
-    chatAnswered?: number;
-    chatRefused?: number;
-    chatConfirmed?: number;
-};
-/**
- * The follower (§M4): one actor that holds the poll lease and stays on the
- * wire, so an answer tapped on a phone reaches the store in seconds, not at
- * the next cron firing. `bridge telegram --follow` runs it standalone;
- * watch embeds the same actor — the poll lease guarantees only one is
- * live, and a cron pass overlapping it simply loses the lease race.
- *
- * Each cycle re-acquires the lease under the same owner — that is the
- * fenced renewal: same generation while held, and if the lease lapsed
- * mid-poll (a stall longer than the TTL), the re-acquire takes the next
- * generation and the cursor rides it, so nothing this follower stamped
- * with the old generation can move state afterwards. Transport failures
- * back off exponentially and are counted, not hidden; cancellation aborts
- * the in-flight long poll instead of waiting it out.
- */
-/** What Telegram lists when the person taps "/". */
-export declare const TELEGRAM_COMMANDS: {
-    command: string;
-    description: string;
-}[];
-export declare function followBridge(store: Store, options: {
-    botId: string;
-    transport: TelegramTransport;
-    signal: AbortSignal;
-    clock?: () => Date;
-    owner?: string;
-    /** false: inbound only; another channel is primary. */
-    deliver?: boolean;
-    readProjects?: TelegramReadProjects;
-    /** Reload channel configuration before every outbound part. */
-    canDeliver?: () => boolean;
-    /** Ordinary text talks to the shared assistant. */
-    conversation?: TelegramConversationOptions;
-    pollSeconds?: number;
-    /** One line per cycle that did something — the follower's narration hook. */
-    onCycle?: (report: BridgeReport) => void;
-    /** Injectable for tests; the default resolves early on abort. */
-    sleep?: (ms: number) => Promise<void>;
-    /** v98: have Telegram push updates to this public address (with this secret) instead of asking for them. */
-    push?: {
-        url: string;
-        secret: string;
-    } | null;
-    /** v98: how often to check Telegram still pushes to us (tests shorten it). */
-    pushCheckMs?: number;
-    /** While a long poll is open, how often to look for a message due to go out (tests shorten it). */
-    deliveryCheckMs?: number;
-}): Promise<FollowReport>;
-/** The digest text: a header with the count and the window, then one
- * fact per entry — its subject, then its body's first line, indented.
- * Plain text, no buttons: nothing in a digest is tappable. */
-export declare function digestText(rows: readonly Notification[], since: string | null, now: Date, titleOf?: (taskId: string) => string): string;
-/**
- * An ordinary message from the paired person: persisted for the shared
- * assistant in THIS transaction — before the cursor moves — with the exact
- * binding, sender, update, message and the request identity the engine
- * receipts its turn under. Two things are answered here and now without a
- * model: text over the engine's bound (never truncated), and a reply to a
- * message that carried several tasks (never guessed). Everything hostile is
- * silence, as for every other inbound shape.
- */
-/** At most this many of a chat's messages wait for the lead at once (the personal lead queue's bound). */
-export declare const TELEGRAM_MAX_WAITING = 10;
-/** A pushed update was kept for this bot: wake its bridge if it runs in this process (docs/plans/responsive-chat.md §3.1). */
-export declare function wakeTelegramBridge(botId: string): void;
-/**
- * Whether a message for this bot was written after `mark` and is still due: unresolved, addressed to everyone or to a
- * person paired with this bot, and the bot not held back by Telegram's rate limit. Read-only; delivery itself still
- * decides each row under its own fences.
- */
-export declare function telegramOutboxDue(store: Store, botId: string, mark: number, now: Date): boolean;

package/dist/templates.d.ts

@@ -1,69 +0,0 @@
-/**
- * The template library (adoption track, step 2) — common work shipped as
- * STATIC DATA that renders into editable, UNAPPROVED drafts.
- *
- * What a template is: a pre-filled form. What it is not: automation with
- * authority. Applying one produces exactly the rows a manual filing
- * produces — through the same one door (proposal.ts), with the same
- * validators, landing unapproved — and the apply output says so in
- * capitals, because `--file` must never read as a yes.
- *
- * The Codex adoption review (finding 10) drew the v1 line: templates may
- * express ONLY what a task proposal or a scheduled flow can carry today. A
- * repeating template (v115: what a routine template was) makes a scheduled
- * flow whose schedule starts paused, and whose every firing waits for
- * approval under the project's rules. The two
- * use cases that imply separate authenticated authority — GitHub issue
- * intake (a grant) and CI babysitting (publish + the repair button) —
- * ship as RECIPES: they display the existing ceremonies, and cannot be
- * applied, because a template must never create a grant, enable
- * autonomous repair, or touch provider configuration.
- *
- * Deliberately no versioning story: an applied draft is a COPY. Editing
- * this library later changes nothing anybody filed.
- */
-import type { AcceptanceCriterion } from "./scope.js";
-export type TaskTemplate = {
-    kind: "task";
-    name: string;
-    purpose: string;
-    title: string;
-    goal: string;
-    outOfScope: string | null;
-    touches: string[];
-    /** v39: baked in, like every other term — a template ships a signed
-     * rubric because it ships a scope, and a scope-producing road never
-     * gets to omit one. */
-    acceptance: AcceptanceCriterion[];
-    /** The fields most installations change — shown in `show` and preview. */
-    edit: string[];
-};
-export type ScheduledTemplate = {
-    kind: "scheduled";
-    name: string;
-    purpose: string;
-    /** The flow's name. */
-    title: string;
-    goal: string;
-    outOfScope: string | null;
-    touches: string[];
-    acceptance: AcceptanceCriterion[];
-    requirements: string[];
-    schedule: string;
-    costCeilingUsd: number | null;
-    edit: string[];
-};
-export type RecipeTemplate = {
-    kind: "recipe";
-    name: string;
-    purpose: string;
-    /** Why this cannot be applied — the authority it would need. */
-    why: string;
-    steps: {
-        say: string;
-        run: string;
-    }[];
-};
-export type Template = TaskTemplate | ScheduledTemplate | RecipeTemplate;
-export declare const TEMPLATES: readonly Template[];
-export declare function templateByName(name: string): Template | null;

package/dist/terminal-catalog.d.ts

@@ -1,11 +0,0 @@
-import type { Database } from "./store.js";
-import type { TerminalLedger } from "./live-terminal.js";
-export declare function terminalCatalogPath(orders: Database): string | null;
-/** The console's ledger: creates the catalog, drops rows of consoles that are gone, and writes its own. */
-export declare function openTerminalLedger(orders: Database, alive?: (pid: number) => boolean): TerminalLedger | null;
-export declare function installTerminalUpdateGate(orders: Database, id: string): void;
-export declare function removeTerminalUpdateGate(orders: Database, id: string): void;
-/** Terminals starting or running in a console that is still alive: active work an update waits for. */
-export declare function activeTerminalUpdateWork(orders: Database, alive?: (pid: number) => boolean): {
-    terminals: number;
-};

package/dist/terminal-text.d.ts

@@ -1,11 +0,0 @@
-/**
- * Text someone else wrote, made safe to print on a terminal: the one sanitizer the live view, `peek` and the terminal
- * UI share. Escape sequences in every form go (CSI in 7- or 8-bit form, OSC such as hyperlinks and title changes,
- * every other ESC sequence), and with them every C0 and C1 control character (a carriage return that would
- * overwrite a line, a backspace, a bell), every invisible format character and bidi override; a tab becomes a space.
- * Pure: no imports, so the terminal UI's bundle carries it as is.
- */
-/** One line: controls, escapes and bidi overrides out; tabs to spaces. A newline is a control here too. */
-export declare function cleanTerminalLine(text: string): string;
-/** Any text for the terminal UI: each line cleaned as above, its newlines kept (a lone carriage return is not one). */
-export declare function terminalText(text: string): string;