/**
 * @ericzhaozzz/wechat-channel — Pi Agent extension
 *
 * Bridges WeChat messages to pi's AI agent via a child process worker.
 *
 * What is left in this file is the part that cannot be pure: one closure
 * over mutable state, holding the state machines and pi's event wiring.
 * Everything that needs no state has been lifted out — `settings.ts` (where
 * the files are, what was configured), `store.ts` (the disk), `state.ts`,
 * `policy.ts`, `render.ts`, `text.ts`, `ui.ts`, `media.ts`. That direction
 * is the only refactoring this repo has found productive: extracting the
 * *stateful* half into a class was merged and then reverted
 * (69f3a28 → 9975ba8).
 *
 * The sections below run in dependency order, roughly outermost first:
 *
 *   Instance lifetime      retirement, and the stale-ctx rule
 *   Operator feedback      the pi CLI side: notifications and the footer
 *   Owner feedback         the WeChat side: notices, never resends
 *   Owner                  who is allowed to drive the agent
 *   Dedup / rate limiting / typing / heartbeat
 *   Worker process         launch (worker-launch.ts), ipc, ready/QR waits
 *   Channel ownership      the lease's wiring: what it restores, what it stops
 *   State persistence      the mirror in ~/.pi/wechat/channel-state.json
 *   Worker lifecycle       start, stop, restart backoff
 *   Login                  and silent re-login
 *   Worker messages        the switch every worker event lands in
 *   Channel commands       `#cancel` and friends, from WeChat itself
 *   Message queue          debounce, steer, dispatch to the agent
 *   Reply delivery         the ledger that owns an answer until WeChat has it
 *   Agent watchdog         so a stuck turn cannot hold the queue forever
 *   Event handlers         pi's session_start / agent_end / tool_execution
 *   wechat_send            the agent's own way to reach the owner mid-turn
 *   /wechat                the operator's subcommands, one function each
 */
import type { ExtensionAPI } from '@earendil-works/pi-coding-agent';
import { type WorkerLauncher } from './worker-launch.js';
/**
 * What this extension gets from outside itself, other than pi.
 *
 * pi calls the factory with one argument, so every field is optional and the
 * production default is used when it is absent. It exists for the tests: a
 * fake launcher is the only way to drive the worker lifecycle without a real
 * child process polling a real iLink account.
 */
export interface ChannelDeps {
    /** How to get a worker. Defaults to `spawnWorker`. */
    launchWorker?: WorkerLauncher;
}
export default function (pi: ExtensionAPI, deps?: ChannelDeps): void;
//# sourceMappingURL=index.d.ts.map