indusagi 0.13.5 → 0.13.7

package/dist/types/capabilities/kernel/spec.d.ts

@@ -1,168 +0,0 @@
-/**
- * The frozen tool kernel.
- *
- * Every built-in capability is authored as a declarative {@link ToolSpec}: a
- * name, a model-facing description, a JSON-Schema parameter shape, and a single
- * async `run`. The bespoke per-tool plumbing — advertising a descriptor to the
- * model, coercing the model's raw arguments, running under cancellation, and
- * shaping the result back into the runtime's tool boundary — is concentrated in
- * one adapter, {@link defineTool}. A tool author writes only `run`; the kernel
- * supplies the rest uniformly.
- *
- * The two outward contracts are imported, never redefined here: the runtime's
- * {@link ToolCall} / {@link ToolOutcome} boundary and the gateway's
- * {@link ToolDescriptor} / {@link JsonSchema} model-facing shape.
- */
-import type { ToolCall, ToolOutcome } from "../../runtime/contract";
-import type { ToolDescriptor, JsonSchema } from "../../llmgateway/contract";
-import type { Fs, Shell } from "./backends";
-import type { OutputBudget } from "./output";
-/** A plain-text fragment a tool returns to the model. */
-export interface TextContentBlock {
-    readonly kind: "text";
-    readonly text: string;
-}
-/** A structured fragment a tool returns; serialized when handed to the model. */
-export interface JsonContentBlock {
-    readonly kind: "json";
-    readonly value: unknown;
-}
-/** One unit of a {@link ToolResult}: either prose or structured data. */
-export type ToolContentBlock = TextContentBlock | JsonContentBlock;
-/**
- * The value a tool's `run` resolves to.
- *
- * `content` is the ordered set of fragments shown to the model. `isError`, when
- * true, marks the whole result as a failure the model should be told about; the
- * kernel propagates it onto the {@link ToolOutcome}.
- */
-export interface ToolResult {
-    readonly content: ToolContentBlock[];
-    readonly isError?: boolean;
-}
-/**
- * The per-session record a {@link ReadStateHandle} keeps for one file.
- *
- * It captures just enough to detect that a file has drifted on disk since it was
- * last read: the floored modification time and byte size at read time, an
- * optional content hash for a future exact-match fallback, and the wall-clock
- * moment the read happened. The handle keys these by absolute path.
- */
-export interface ReadStateRecord {
-    /** Last-modified time at read, epoch milliseconds (floored). */
-    readonly mtimeMs: number;
-    /** Byte size at read time. */
-    readonly size: number;
-    /** Optional content hash for an exact-equality fallback; absent today. */
-    readonly contentHash?: string;
-    /** Wall-clock moment the read was recorded, epoch milliseconds. */
-    readonly readAt: number;
-}
-/**
- * The minimal, duck-typed handle a host may stash on {@link ToolContext.framework}
- * under {@link READ_STATE_HANDLE_KEY} to enable the read-before-edit gate.
- *
- * Deliberately tiny — `get` / `set` / `has` keyed by absolute path — so the
- * framework consumer and the product injector can agree on the *shape* without a
- * cross-package type import. The product supplies a concrete store; the framework
- * only ever reads/writes through these three methods.
- */
-export interface ReadStateHandle {
-    /** The recorded state for a path, or undefined if it was never read. */
-    get(absPath: string): ReadStateRecord | undefined;
-    /** Record (or refresh) the state for a path. */
-    set(absPath: string, record: ReadStateRecord): void;
-    /** Whether a path has any recorded read state this session. */
-    has(absPath: string): boolean;
-}
-/**
- * The string-literal key under which a {@link ReadStateHandle} lives on
- * {@link ToolContext.framework}.
- *
- * Mirrors the existing `DELEGATE_HANDLE_KEY = "delegate"` /
- * `MEMORY_HANDLE_KEY = "memoryStore"` convention: a shared literal both the
- * framework consumer and the product injector reference so they agree without a
- * cross-package type import.
- */
-export declare const READ_STATE_HANDLE_KEY: "readState";
-/**
- * Everything a tool's `run` is handed besides its own parsed input.
- *
- * It carries the working directory, the two coarse I/O backends, a cancellation
- * `signal`, and the default {@link OutputBudget} a tool should apply when its
- * output risks overflowing the model's window.
- *
- * `framework` is an open bag of optional host-injected handles, keyed by string
- * literals (e.g. {@link READ_STATE_HANDLE_KEY}). It is the additive seam through
- * which a host can opt a session into behaviors like the read-before-edit gate
- * without changing any tool signature; when a handle is absent the tools behave
- * exactly as they did before.
- */
-export interface ToolContext {
-    readonly cwd: string;
-    readonly fs: Fs;
-    readonly shell: Shell;
-    readonly signal: AbortSignal;
-    readonly budget: OutputBudget;
-    /** Open record of optional, host-injected framework handles. */
-    readonly framework?: {
-        readonly [key: string]: unknown;
-    };
-}
-/**
- * The declarative description of one tool.
- *
- * `I` is the input shape `run` expects after coercion. The kernel validates the
- * raw call against `parameters` loosely (presence and basic typing) and hands a
- * best-effort `I` to `run`; rigorous validation, where a tool wants it, lives in
- * `run` itself.
- */
-export interface ToolSpec<I = unknown> {
-    /** The name advertised to and invoked by the model. */
-    readonly name: string;
-    /** The model-facing description of what the tool does and when to use it. */
-    readonly description: string;
-    /** The JSON-Schema object describing the tool's parameters. */
-    readonly parameters: JsonSchema;
-    /** The tool's behavior; receives coerced input and the live context. */
-    run(input: I, ctx: ToolContext): Promise<ToolResult>;
-}
-/**
- * A {@link ToolSpec} after {@link defineTool} has wrapped it.
- *
- * `descriptor()` yields the model-facing advertisement; `invoke()` is the
- * runner-side entry point that turns a {@link ToolCall} into a
- * {@link ToolOutcome}.
- */
-export interface DefinedTool {
-    /** The tool's name (mirrors the spec, exposed for registry bookkeeping). */
-    readonly name: string;
-    /** The descriptor handed to the model on each invocation. */
-    descriptor(): ToolDescriptor;
-    /** Execute one call under the given context and normalize the result. */
-    invoke(call: ToolCall, ctx: ToolContext): Promise<ToolOutcome>;
-    /** Display label for the facade (mirrors the name). */
-    readonly label: string;
-    /** Top-level description for the facade's tool validation + the model schema. */
-    readonly description: string;
-    /** Top-level JSON-schema parameters for the facade's tool validation. */
-    readonly parameters: JsonSchema;
-    /** Facade execution entry point: run the tool and return facade-shaped content. */
-    execute(toolCallId: string, params: unknown, signal?: AbortSignal, onUpdate?: (partial: unknown) => void): Promise<{
-        content: Array<{
-            type: "text";
-            text: string;
-        }>;
-        details: Record<string, unknown>;
-        isError: boolean;
-    }>;
-}
-/**
- * Wrap a {@link ToolSpec} into a {@link DefinedTool}.
- *
- * The returned `invoke` coerces the call's input, honors an already-aborted
- * signal up front, runs the spec, and folds both the success result and any
- * thrown failure into a {@link ToolOutcome}. No spec ever has to write this
- * boilerplate itself.
- */
-export declare function defineTool<I = unknown>(spec: ToolSpec<I>): DefinedTool;

package/dist/types/capabilities/planning/todo.d.ts

@@ -1,62 +0,0 @@
-/**
- * The `todo` planning capability: a tiny, per-conversation task list the model
- * can keep in front of itself while it works.
- *
- * Two cooperating tools are exposed. {@link todoSetTool} replaces the entire
- * checklist in one shot — the caller hands over the whole array of items it wants
- * tracked, and any previous list for that context is discarded. {@link todoReadTool}
- * plays the list back so the model can re-read where it stands without mutating
- * anything. Both are authored against the kernel surface alone; the backing store
- * is plain in-process state, so no `ctx.fs` or `ctx.shell` access is needed.
- *
- * State lives in a single module-level {@link TodoStore} keyed by the live
- * {@link ToolContext}. Every distinct conversation threads a distinct context
- * object through `run`, so each conversation gets its own isolated list. The store
- * exposes {@link TodoStore.reset} so a test can wipe all accumulated lists between
- * cases.
- */
-import type { ToolContext } from "../kernel";
-/** The lifecycle stage of a single checklist entry. */
-export type TodoStatus = "pending" | "active" | "done";
-/** One line of the checklist. */
-export interface TodoItem {
-    /** Caller-chosen stable identifier, unique within a single list. */
-    readonly id: string;
-    /** Human-readable summary of the task. */
-    readonly text: string;
-    /** Where this task sits in its lifecycle. */
-    readonly status: TodoStatus;
-}
-/**
- * In-process home for every context's checklist.
- *
- * Keys are the identity of the {@link ToolContext} object handed to `run`, so two
- * conversations never see each other's items. The class is a thin wrapper over a
- * {@link Map}; it is deliberately minimal because the tools own all of the
- * validation and presentation logic.
- */
-export declare class TodoStore {
-    private readonly lists;
-    /** Return the list recorded for `ctx`, or an empty array if none was set yet. */
-    read(ctx: ToolContext): readonly TodoItem[];
-    /** Replace the entire list recorded for `ctx` with `items`. */
-    replace(ctx: ToolContext, items: readonly TodoItem[]): void;
-    /** Discard every stored list. Intended for test isolation only. */
-    reset(): void;
-}
-/**
- * The shared, module-level store both tools read and write.
- *
- * Exported so tests can call {@link TodoStore.reset} between cases and assert on
- * stored state directly.
- */
-export declare const todoStore: TodoStore;
-/**
- * Convenience re-export of the store's reset, so a test can wipe state with a
- * single named import instead of reaching through the instance.
- */
-export declare function reset(): void;
-/** Replace the whole stored checklist for the calling context. */
-export declare const todoSetTool: import("..").DefinedTool;
-/** Play back the stored checklist for the calling context without changing it. */
-export declare const todoReadTool: import("..").DefinedTool;

package/dist/types/capabilities/registry.d.ts

@@ -1,44 +0,0 @@
-/**
- * The built-in capability assembly.
- *
- * The kernel ships a generic {@link ToolRegistry} and a generic
- * {@link makeNodeContext}; this module marries the two into the concrete,
- * batteries-included surface a host actually wires up. It registers every
- * built-in tool, names the standard collections the agent selects between, and
- * exposes a one-call {@link toolBox} helper that produces a runnable
- * {@link ToolBox} backed by the real Node filesystem and shell.
- *
- * Three collections are defined:
- *   - `read-only` — tools that only observe the workspace and the web: read,
- *     ls, grep, find, websearch, webfetch. Safe to expose when no mutation
- *     should be possible.
- *   - `coding`    — everything in `read-only` plus the mutating and stateful
- *     tools: write, edit, bash, the todo pair, and process control.
- *   - `all`       — the union of every registered tool, with nothing withheld.
- *
- * Nothing here reaches for `node:fs` or `node:child_process` directly — the
- * Node binding lives entirely in `backends/`, which this module merely consumes.
- */
-import { ToolRegistry } from "./kernel";
-import type { ToolBox } from "../runtime/contract";
-/** The names of the collections this module defines. */
-export type ToolCollection = "read-only" | "coding" | "all";
-/**
- * Build a fresh {@link ToolRegistry} populated with every built-in tool and the
- * three standard collections.
- *
- * A new registry is minted on each call so callers never share mutable state;
- * the tool objects themselves are stateless singletons and are safe to share.
- */
-export declare function builtinRegistry(): ToolRegistry;
-/**
- * Produce a runnable {@link ToolBox} for the named collection, backed by the
- * real Node filesystem and shell.
- *
- * The returned box advertises exactly the descriptors of the chosen collection
- * and dispatches each call to the matching tool, minting a fresh
- * {@link ToolContext} (rooted at `cwd`) per dispatch and threading the runtime's
- * cancellation signal in. `cwd` defaults to the current process working
- * directory when omitted.
- */
-export declare function toolBox(collection: ToolCollection, cwd?: string): ToolBox;

package/dist/types/capabilities/search/find.d.ts

@@ -1,33 +0,0 @@
-/**
- * Filename search capability.
- *
- * `find` enumerates entries beneath a starting path whose *name* matches a query.
- * The query is interpreted as either a shell-style glob (when it contains `*` or
- * `?`) or, failing that, a plain case-insensitive substring. The walk is a
- * hand-rolled recursive descent over {@link ToolContext.fs}; it never touches
- * `node:fs`, a child process, or a platform `find` binary, so it behaves the same
- * against any backend a host plugs in (real disk, sandbox, in-memory).
- *
- * Results are returned as paths relative to the search root, one per line, and
- * are pared back through {@link ToolContext.budget} so the listing can never
- * overflow the model's window.
- */
-/** Which kind of filesystem entry the caller wants back. */
-type EntryKind = "file" | "dir";
-/** The arguments this tool accepts from the model. */
-export interface FindInput {
-    /** Glob pattern (with `*`/`?`) or plain substring to match against names. */
-    readonly query: string;
-    /** Directory to search beneath; defaults to the working directory. */
-    readonly path?: string;
-    /** Restrict hits to regular files (`"file"`) or directories (`"dir"`). */
-    readonly type?: EntryKind;
-}
-/**
- * The filename-search tool. Walks a path with {@link ToolContext.fs}, tests each
- * entry's *name* against a glob or substring query, optionally filters by file
- * vs. directory, and returns the matching root-relative paths clamped to
- * {@link ToolContext.budget}.
- */
-export declare const findTool: import("..").DefinedTool;
-export {};

package/dist/types/capabilities/search/grep.d.ts

@@ -1,30 +0,0 @@
-/**
- * Content search capability.
- *
- * `grep` hunts for a regular expression inside the *text* of files beneath a
- * starting path. The traversal is a hand-rolled recursive descent over
- * {@link ToolContext.fs}; it never reaches for `node:fs`, a child process, or the
- * platform `grep` binary, so it behaves identically against any backend a host
- * cares to plug in (real disk, sandbox, in-memory).
- *
- * Each hit is reported as `relative/path:line` followed by the line that matched.
- * Bulky output is pared back through {@link ToolContext.budget} so the result can
- * never overrun the model's window.
- */
-/** The arguments this tool accepts from the model. */
-export interface GrepInput {
-    /** The regular expression to test each line against. */
-    readonly pattern: string;
-    /** Directory (or single file) to search under; defaults to the working dir. */
-    readonly path?: string;
-    /** Standard JS regex flag letters, e.g. `"i"` for case-insensitive. */
-    readonly flags?: string;
-    /** Stop after this many hits have been collected. */
-    readonly maxMatches?: number;
-}
-/**
- * The content-search tool. Walks a path with {@link ToolContext.fs}, tests each
- * line of every readable text file against the supplied regex, and returns
- * `path:line` hits clamped to {@link ToolContext.budget}.
- */
-export declare const grepTool: import("..").DefinedTool;

package/dist/types/capabilities/shell/bash.d.ts

@@ -1,18 +0,0 @@
-/**
- * The `bash` capability: run a single shell command to completion.
- *
- * This tool hands a one-shot command string to the kernel's {@link Shell.exec}
- * backend, waits for it to settle, and reports back the captured standard
- * output, standard error, and exit status as a single text block the model can
- * read. It never reaches for `node:child_process` itself — every side effect
- * flows through the injected {@link ToolContext.shell} seam, so a host may run it
- * locally, sandboxed, or remotely without the tool noticing.
- *
- * Cancellation and a wall-clock deadline are both honored: the context's
- * {@link ToolContext.signal} is threaded into the launch (so an aborted turn
- * tears the command down), and a per-call `timeoutMs` caps how long a runaway
- * command may block. Output that would overflow the model's window is trimmed
- * through the context's {@link ToolContext.budget} before it is returned.
- */
-/** The `bash` tool: a one-shot shell command runner. */
-export declare const bashTool: import("..").DefinedTool;

package/dist/types/capabilities/shell/process.d.ts

@@ -1,33 +0,0 @@
-/**
- * The `process` capability: a controller for long-lived background commands.
- *
- * Where {@link bashTool} runs a single command to completion and blocks, this
- * tool starts a command that keeps running between turns — a dev server, a file
- * watcher, a log tail — and lets the model check in on it later. It owns a small
- * in-module registry of live jobs (the {@link ProcessTable}); each registry
- * entry pairs the kernel {@link ShellHandle} with a rolling capture of whatever
- * the job has printed so far.
- *
- * Four verbs drive it:
- *   - `start` launches a command in the background and hands back its job id.
- *   - `list`  enumerates every tracked job with its current status.
- *   - `poll`  drains the output buffered since the last look and reports whether
- *             the job is still alive or how it ended.
- *   - `stop`  signals a running job to terminate and forgets it.
- *
- * The kernel {@link ShellHandle} exposes no output streams of its own — only a
- * pid, a kill, and an exit subscription. To capture what a background job prints
- * without ever touching `node:child_process`, the launcher wraps the command so
- * the platform shell redirects both streams into per-job scratch files, then
- * reads those files back through the {@link ToolContext.fs} seam. Every side
- * effect therefore flows through `ctx.shell` and `ctx.fs`; this module reaches
- * for no Node API of its own.
- */
-/** Clear the background-job registry; intended for test setup/teardown. */
-export declare function resetProcessTable(): void;
-/**
- * The `process` tool: a registry-backed controller for background commands.
- *
- * Exported as a named {@link DefinedTool} so a host can register it directly.
- */
-export declare const processTool: import("..").DefinedTool;

package/dist/types/capabilities/web/webfetch.d.ts

@@ -1,25 +0,0 @@
-/**
- * The `webfetch` capability: pull a web page and hand the model a clean,
- * reading-friendly rendition of it.
- *
- * The tool issues a single HTTP(S) GET through the platform `fetch`, reads the
- * body as text, and runs it through a small, self-contained HTML simplifier.
- * That simplifier is deliberately naive — it is not a real parser. It strips the
- * non-visible machinery (script, style, template, and comment regions), turns a
- * handful of structural tags (headings, paragraphs, list items, line breaks,
- * anchors) into plain-text equivalents, deletes every remaining tag, decodes the
- * common character entities, and squeezes runaway whitespace. The result reads
- * roughly like markdown without pretending to be a faithful conversion.
- *
- * Two ceilings guard the size of what comes back: an optional caller-supplied
- * `maxBytes` that bounds how much of the downloaded body is even considered, and
- * the context's {@link OutputBudget}, which is always applied last so the model's
- * window can never be overrun. Any failure on the network path — an unreachable
- * host, a non-success status, a body that will not decode — is caught and
- * returned as a flagged error result rather than thrown, so the agent loop sees a
- * tidy message instead of a crash.
- *
- * Authored entirely against the kernel surface plus the platform `fetch` global;
- * no Node module is imported here.
- */
-export declare const webFetchTool: import("..").DefinedTool;

package/dist/types/capabilities/web/websearch.d.ts

@@ -1,23 +0,0 @@
-/**
- * The `websearch` capability: run a web query and hand the model a ranked list
- * of hits.
- *
- * The query is sent to DuckDuckGo's no-frills HTML endpoint, whose markup is
- * lightweight enough to scrape with a couple of targeted regular expressions —
- * no headless browser, no HTML parser dependency. Each hit is distilled to the
- * three fields a model actually reasons over: a title, the destination URL, and
- * a short snippet. The list is capped (by `maxResults`, with a sane default and
- * a hard ceiling) and the whole payload is byte-bounded through the context's
- * {@link OutputBudget} so a chatty results page can never overflow the window.
- *
- * Network reachability is never guaranteed, so every failure mode — a thrown
- * fetch, a non-OK status, a body that yields nothing parseable — is turned into
- * an `isError` {@link ToolResult} rather than an exception. The caller (and the
- * model) always gets a well-typed result back.
- *
- * Authored against the kernel surface plus the Web-standard `fetch` global.
- * There is no filesystem or shell work here, and DuckDuckGo has no kernel seam,
- * so the only outside primitive used is `fetch` — the platform networking API,
- * not a node-specific module.
- */
-export declare const webSearchTool: import("..").DefinedTool;

package/dist/types/connectors-saas/connectors-saas.test.d.ts

@@ -1,12 +0,0 @@
-/**
- * Tests for the SaaS connector bridge, driven by an in-memory MOCK
- * {@link SaasBackend}.
- *
- * There is deliberately NO network and NO `@composio/core` here: a fake backend
- * exposing one toolkit ("github") with two operations stands in for the vendor
- * catalog, so the whole bridge — gateway assembly, the content-hash enable cache,
- * the remote-tool builder, the declarative connect rule table, and the result
- * summarizer — is exercised against plain objects. The real adapter is covered
- * separately; these tests pin the dependency-inverted core's behaviour.
- */
-export {};

package/dist/types/connectors-saas/index.d.ts

@@ -1,16 +0,0 @@
-/**
- * The SaaS connector bridge — public surface.
- *
- * One import site for the whole bridge: the stateful {@link SaasGateway} façade and
- * its factories, the {@link SaasBackend} port plus its data vocabulary, the single
- * vendor adapter ({@link createComposioBackend}), and the fluent {@link ScopePlanner}
- * scope resolver. The render and control internals stay private behind the gateway;
- * a host wires an agent up through this barrel alone.
- */
-export { createSaasGateway, createComposioGateway, } from "./saas/gateway";
-export type { SaasGateway, SaasGatewayOptions, EnableReport, ConnectReport, StatusReport, } from "./saas/gateway";
-export type { SaasBackend, ToolkitInfo, RemoteTool, RemoteResult, ConnectedAccount, ConnectionStatus, ConnectionRequest, ConnectionState, ExecuteOptions, InitiateOptions, } from "./saas/core/index";
-export { createComposioBackend, ComposioBackendError } from "./saas/adapter/composio-backend";
-export type { ComposioBackendOptions } from "./saas/adapter/composio-backend";
-export { ScopePlanner } from "./saas/core/index";
-export type { ResolvedScope, ScopeKind } from "./saas/core/index";

package/dist/types/connectors-saas/saas/adapter/composio-backend.d.ts

@@ -1,60 +0,0 @@
-/**
- * The Composio adapter — the *single* place `@composio/core` leaks into the SaaS
- * connector bridge.
- *
- * Everything else in `src/connectors-saas/` talks to the {@link SaasBackend} port
- * (see `../core/port`). This file is the lone implementation that satisfies that
- * port by delegating to the real `Composio` SDK client and translating the
- * vendor's richer, snake-/camel-cased catalog shapes down into our small, frozen
- * vocabulary. Because the vendor's response types are sprawling (deeply-nested
- * zod-inferred unions) and not worth re-deriving here, `any` is deliberately
- * permitted at this boundary — and *only* here. The mapping helpers
- * (`normalizeStatus`, `pickAuthUrl`, the `to*` projectors) re-narrow every value
- * back to a typed port shape before it crosses out, so nothing untyped escapes.
- *
- * Method-by-method delegation:
- *   listToolkits        → composio.toolkits.get({})
- *   listTools           → composio.tools.getRawComposioTools({ toolkits: [slug] })
- *   execute             → composio.tools.execute(slug, { userId, arguments, connectedAccountId })
- *   listConnectedAccounts → composio.connectedAccounts.list()
- *   initiateConnection  → composio.toolkits.authorize(userId, slug, authConfigId?)
- *   checkConnection     → composio.connectedAccounts.get(id)
- *
- * The Composio SDK is user-scoped: nearly every call wants a `userId`. The bridge
- * port is single-user by design, so we thread a fixed default user through the
- * adapter; callers that need multi-tenancy construct one backend per user.
- */
-import type { SaasBackend } from "../core/port";
-/** Options for standing up the Composio-backed {@link SaasBackend}. */
-export interface ComposioBackendOptions {
-    /** The Composio API key the SDK client authenticates with. */
-    readonly apiKey: string;
-    /**
-     * The user scope to act under. The Composio catalog is user-scoped; the bridge
-     * port is single-user, so one fixed id is threaded through every call. Defaults
-     * to `"default"` when omitted.
-     */
-    readonly userId?: string;
-}
-/**
- * Thrown when a backend operation cannot be satisfied through the Composio SDK in
- * a way that maps cleanly onto the port — i.e. a genuinely unsupported request,
- * not a transient API failure. Carries the offending method name for tracing.
- */
-export declare class ComposioBackendError extends Error {
-    /** The port method that could not be satisfied (e.g. `"checkConnection"`). */
-    readonly method: string;
-    constructor(method: string, message: string, options?: {
-        cause?: unknown;
-    });
-}
-/**
- * Build the Composio-backed {@link SaasBackend}.
- *
- * This is the bridge's single seam onto `@composio/core`: hand it an API key and
- * it returns an object that speaks only the port. Nothing the caller touches
- * references a vendor type.
- */
-export declare function createComposioBackend(opts: {
-    apiKey: string;
-}): SaasBackend;

package/dist/types/connectors-saas/saas/control/connect.d.ts

@@ -1,114 +0,0 @@
-/**
- * The connection state machine, expressed as a declarative RULE TABLE.
- *
- * Driving an OAuth-style link from "nothing yet" to "active" is a small loop with
- * a handful of terminal and non-terminal states. The naive way to write it is an
- * `if`-cascade inside the poll loop — "if active return; else if failed throw;
- * else if expired re-initiate; else wait and poll again" — which buries the policy
- * inside control flow and is easy to get subtly wrong. We pull that policy out into
- * {@link CONNECT_RULES}: one row per normalized {@link ConnectionStatus}, each row
- * naming the {@link ConnectAction} the driver should take next. The poll loop then
- * does nothing but *consult the table* and obey.
- *
- * {@link planConnect} is the pure function at the heart of it: state in, action
- * out, no I/O. {@link initiateAndAwait} is the one impure driver that opens a
- * connection through the {@link SaasBackend} port and polls it to a terminal
- * outcome, asking {@link planConnect} at every step what to do. Because the policy
- * is data, a test can assert the whole decision matrix without touching a backend.
- */
-import type { ConnectionState, ConnectionStatus, InitiateOptions, SaasBackend } from "../core/index";
-/**
- * What the driver should do once it has observed a connection's current state.
- *
- * - `await-auth` — the user still has to act (visit `authUrl`); keep polling.
- * - `poll` — the link is progressing on the backend; check again shortly.
- * - `done` — the link is `active`; the carried `accountId` is ready to use.
- * - `expired` — the attempt lapsed; the caller may re-initiate from scratch.
- * - `failed` — the attempt terminally failed; surface the reason and stop.
- */
-export type ConnectAction = {
-    readonly kind: "await-auth";
-    readonly authUrl?: string;
-} | {
-    readonly kind: "poll";
-} | {
-    readonly kind: "done";
-    readonly accountId?: string;
-} | {
-    readonly kind: "expired";
-} | {
-    readonly kind: "failed";
-    readonly reason: string;
-};
-/** Whether an action is one the driver stops on rather than loops past. */
-export declare function isTerminal(action: ConnectAction): boolean;
-/**
- * One row of the connection decision matrix: a normalized status mapped to the
- * action the driver should take when it observes that status. Keeping `decide` as
- * a thunk over the live {@link ConnectionState} lets a row read the state's
- * `accountId` / `authUrl` without the table itself needing to branch.
- */
-interface ConnectRule {
-    /** The normalized status this row governs. */
-    readonly when: ConnectionStatus;
-    /** Produce the next action from the observed state. */
-    decide(state: ConnectionState): ConnectAction;
-}
-/**
- * The connection rule table — the whole policy as data.
- *
- * `active` → done (carrying the linked account); `pending` → either wait for the
- * user when an `authUrl` is outstanding, or poll the backend otherwise; `expired`
- * and `failed` are the two terminal failure shapes. There is exactly one row per
- * member of {@link ConnectionStatus}, so the matrix is total by construction.
- */
-export declare const CONNECT_RULES: readonly ConnectRule[];
-/**
- * Decide the next {@link ConnectAction} for an observed {@link ConnectionState}.
- *
- * Pure: it consults {@link CONNECT_RULES} and applies the matching row. Because
- * the table is total over {@link ConnectionStatus}, the only way to miss is an
- * out-of-vocabulary status, which we treat as a terminal failure rather than a
- * silent no-op.
- */
-export declare function planConnect(state: ConnectionState): ConnectAction;
-/** How the {@link initiateAndAwait} driver paces and bounds its polling. */
-export interface AwaitOptions extends InitiateOptions {
-    /** Milliseconds between polls of a still-pending connection. Default 1500. */
-    readonly pollIntervalMs?: number;
-    /** Maximum number of polls before giving up with a timeout. Default 40. */
-    readonly maxPolls?: number;
-    /** Injectable delay, so tests can drive the loop without real time passing. */
-    readonly sleep?: (ms: number) => Promise<void>;
-}
-/**
- * The terminal outcome of driving a connection attempt to completion.
- *
- * `action` is always one for which {@link isTerminal} holds. `requestId` and the
- * final `authUrl` (if the user still needed to act) are carried for surfacing.
- */
-export interface ConnectOutcome {
-    /** The connection request that was driven. */
-    readonly requestId: string;
-    /** The toolkit the request targeted. */
-    readonly toolkit: string;
-    /** The terminal action the state machine settled on. */
-    readonly action: ConnectAction;
-    /** The most recent authorization URL observed, if any. */
-    readonly authUrl?: string;
-}
-/**
- * Open a connection to `toolkit` and poll it to a terminal state via the backend.
- *
- * The driver is deliberately thin: it initiates once, then loops — observe state,
- * ask {@link planConnect}, and either stop (terminal action) or wait-and-poll
- * (`poll` / `await-auth`). Polling is bounded by `maxPolls`; exhausting the budget
- * yields a `failed` outcome rather than hanging. All policy lives in the rule
- * table; this function only sequences I/O around it.
- *
- * Note it does *not* re-initiate on `expired` — that decision belongs to the
- * caller, who may want to surface the lapse to the user first; the outcome simply
- * reports `expired` so the caller can choose.
- */
-export declare function initiateAndAwait(backend: SaasBackend, toolkit: string, options?: AwaitOptions): Promise<ConnectOutcome>;
-export {};