@hyperdrive.bot/fleet-server 0.3.99

package/dist/server/server/session/chat/chat-ingestion-session.js

@@ -0,0 +1,504 @@
+import { BACKFILL_WINDOW_OPTIONS_DAYS, runBackfill, windowStartFor, } from "../../ingestion/backfill.js";
+import { applySelection, ApplyError } from "../../ingestion/apply.js";
+import { CohortRpcError } from "../../ingestion/cohort-store.js";
+import { resolveMatchedItems } from "../../ingestion/resolve-items.js";
+import { IngestionError } from "../../ingestion/errors.js";
+import { buildIngestionRunViews } from "../../ingestion/run-projection.js";
+import { isInInbox } from "../../ingestion/reconcile/verdict-mapping.js";
+/**
+ * The widest window the resolver will read to turn item keys into items.
+ *
+ * The apply request deliberately does not carry a window (AC5 pins its five
+ * fields), and it should not: the client's account of which window it previewed
+ * is exactly the kind of client-supplied number this epic refuses to trust. So
+ * the daemon reads the widest window the picker can offer and stops the moment
+ * every requested key is in hand - which, for a selection made off a preview
+ * taken seconds earlier, is almost always the first page.
+ */
+const APPLY_RESOLVE_WINDOW_DAYS = Math.max(...BACKFILL_WINDOW_OPTIONS_DAYS);
+/**
+ * How many ledger rows the run view reads for one filter.
+ *
+ * Bounded rather than unbounded because the query rides
+ * `idx_ingestion_items_filter_seen` newest-first, so a limit is a cheap
+ * `LIMIT` on an ordered index rather than a truncation of a sorted scan. Two
+ * hundred is far past what any Inbox renders and far short of what a
+ * months-old filter accumulates; the runs it joins against are themselves
+ * capped by the schedule document's own run history.
+ */
+const RUN_VIEW_ROW_LIMIT = 200;
+/**
+ * The client-facing string for a failed ingestion request.
+ *
+ * An IngestionError collapses to its CODE, never its message: the message is
+ * the aggregator's own text, which can echo request context including a header
+ * we sent. The code is a closed set we wrote ourselves, so it is the only part
+ * safe to hand to a client or to a log line.
+ */
+function toIngestionErrorMessage(error) {
+    if (error instanceof IngestionError) {
+        return error.code;
+    }
+    // Same rule, second closed set: `ApplyError`'s message can quote a local
+    // filter id, and only the code is guaranteed to be something we wrote.
+    if (error instanceof ApplyError) {
+        return error.code;
+    }
+    // Third closed set, same rule: a cohort refusal's message names a local cohort
+    // id, so only the code crosses the wire.
+    if (error instanceof CohortRpcError) {
+        return error.code;
+    }
+    if (error instanceof Error) {
+        return error.message;
+    }
+    return String(error);
+}
+/**
+ * A client's ingestion PREVIEW and APPLY surface.
+ *
+ * Story 5.1 built this as a preview-only class whose safety argument was an
+ * absent collaborator: with no `ScheduleService` in scope, no handler here could
+ * mint a session by accident. Story 5.3 adds the apply verb, which mints
+ * sessions on purpose, so that argument no longer covers the class as a whole
+ * and is replaced by two narrower ones that still hold:
+ *
+ *   - `dispatcher` is the `DryRunDispatcher` PORT, one method wide
+ *     (`runUnattendedSession`), not the whole service. `create`, `runOnce`,
+ *     `pause` and `tick` are not on the object this class holds, so nothing here
+ *     can arm, edit or trigger a schedule. Minting one unattended session for a
+ *     selection the user just confirmed is the verb; changing a filter's cadence
+ *     is not, and is unreachable.
+ *   - `runBackfill` still gets the one-method ledger port rather than the ledger,
+ *     so the PREVIEW path remains structurally unable to write a row even though
+ *     the apply path, one method over, must.
+ *
+ * The confirmation gate that bounds the apply is not in this class either: it is
+ * in `applySelection`, on the server side of the wire, so a second caller (a
+ * CLI, a script, an MCP tool) gets the same gate without re-implementing it.
+ */
+export class ChatIngestionSession {
+    constructor(options) {
+        this.host = options.host;
+        this.filterStore = options.filterStore;
+        this.sourceStore = options.sourceStore;
+        this.gatewayResolver = options.gatewayResolver;
+        this.ledger = options.ledger;
+        this.limiter = options.limiter;
+        this.dispatcher = options.dispatcher;
+        this.cohorts = options.cohorts;
+        this.cohortStore = options.cohortStore;
+        this.schedules = options.schedules;
+        this.reconciliation = options.reconciliation;
+        this.clientId = options.clientId;
+        this.logger = options.logger;
+    }
+    /**
+     * A failed backfill is reported IN THE RESPONSE, not as an `rpc_error`.
+     *
+     * The screen has two distinct states - "the window held nothing" and "the
+     * read failed" - and it can only tell them apart if a failure arrives on the
+     * same channel as a success, carrying `result: null` beside a non-null
+     * `error`. An out-of-band rpc_error would leave the correlated request
+     * resolving to nothing, which the screen would render as an empty window.
+     */
+    emitIngestionRpcError(request, error) {
+        const message = toIngestionErrorMessage(error);
+        this.logger.error({ err: error, requestType: request.type, clientId: this.clientId }, "Ingestion request failed");
+        this.host.emit({
+            type: "ingestion/backfill/response",
+            payload: { requestId: request.requestId, result: null, error: message },
+        });
+    }
+    /**
+     * Adapt `IngestionLedger` to the one-method reader `runBackfill` accepts.
+     *
+     * Three mismatches are absorbed here rather than by widening either side:
+     * the ledger's `get` is synchronous, is keyed by `(filterId, itemKey)`, and
+     * names the mark `handledAt`.
+     *
+     * A row whose `content_hash` was never written reports as "no comparable
+     * mark" (null) rather than as a row with an empty hash. Both produce
+     * `handled: false`, but only one of them says so honestly instead of
+     * inventing a sentinel hash that happens never to collide.
+     */
+    ledgerReaderFor(filterId) {
+        const ledger = this.ledger;
+        return {
+            get: (itemKey) => {
+                if (!ledger) {
+                    return Promise.resolve(null);
+                }
+                const entry = ledger.get(filterId, itemKey);
+                if (!entry || entry.contentHash === null) {
+                    return Promise.resolve(null);
+                }
+                return Promise.resolve({ contentHash: entry.contentHash, markedAt: entry.handledAt });
+            },
+        };
+    }
+    /**
+     * Preview what a filter would have matched over a window of its source's
+     * history.
+     *
+     * Reads only. Nothing on this path writes a ledger row, mints a session or
+     * resolves an MCP target, and `backfill.no-side-effects.test.ts` asserts that
+     * against the real table rather than by reading this comment.
+     */
+    async handleIngestionBackfillRequest(request) {
+        try {
+            const filter = await this.filterStore.get(request.filterId);
+            if (!filter) {
+                throw new IngestionError("FILTER_MISSING", `No filter ${request.filterId} on this daemon.`, 404);
+            }
+            const source = await this.sourceStore.get(filter.sourceId);
+            if (!source) {
+                throw new IngestionError("SOURCE_MISSING", `Filter ${filter.id} points at source ${filter.sourceId}, which no longer exists.`, 404);
+            }
+            const now = Date.now();
+            const result = await runBackfill({
+                filter,
+                gateway: this.gatewayResolver(source.kind),
+                externalUserId: source.externalUserId,
+                // A source that has never completed its handoff has no account yet.
+                // The empty string reaches the adapter, which is free to ignore it -
+                // neither aggregator narrows a history read by account.
+                accountId: source.externalAccountId ?? "",
+                ledger: this.ledgerReaderFor(filter.id),
+                sinceMs: windowStartFor(now, request.windowDays),
+                now: () => now,
+            });
+            if (result.truncated) {
+                // Named in the log as well as on screen: a shortened read that only the
+                // UI mentions is invisible the moment somebody reads the logs instead.
+                this.logger.info({ filterId: filter.id, scanned: result.scanned, windowDays: request.windowDays }, "Ingestion backfill stopped at the item cap");
+            }
+            this.host.emit({
+                type: "ingestion/backfill/response",
+                payload: { requestId: request.requestId, result, error: null },
+            });
+        }
+        catch (error) {
+            this.emitIngestionRpcError(request, error);
+        }
+    }
+    /**
+     * Turn item keys back into payload-bearing items.
+     *
+     * The work lives in `resolve-items.ts` so the RESUME path (Story 5.4) reaches
+     * the same resolution rather than a second one that could quietly disagree
+     * about which items a group covers.
+     */
+    async resolveMatchedItems(filter, itemKeys) {
+        if (!filter) {
+            throw new IngestionError("FILTER_MISSING", "No such filter on this daemon.", 404);
+        }
+        return resolveMatchedItems({
+            filter,
+            sourceStore: this.sourceStore,
+            gatewayResolver: this.gatewayResolver,
+            itemKeys,
+            windowDays: APPLY_RESOLVE_WINDOW_DAYS,
+            now: () => Date.now(),
+        });
+    }
+    /**
+     * Dispatch a confirmed selection, or tell the client what it would dispatch.
+     *
+     * Mirrors `handleScheduleCreateRequest` (`chat-schedule-loop-session.ts:304`)
+     * in shape: try, emit, and on a throw emit a response carrying the error
+     * rather than an out-of-band `rpc_error`. The reason is the same one the
+     * backfill handler documents - a correlated request that resolves to nothing
+     * is indistinguishable, on screen, from a successful call that did nothing.
+     *
+     * Every number in the response is computed HERE. `confirmedGroups` off the
+     * request is used only as something to disagree with.
+     */
+    async handleIngestionApplyRequest(request) {
+        try {
+            const ledger = this.ledger;
+            const limiter = this.limiter;
+            if (!ledger || !limiter) {
+                // Named as its own condition rather than folded into a generic failure:
+                // an apply without a durable budget could not bound outward artifacts,
+                // and "the daemon has no ledger" is a fixable state the user should be
+                // told about verbatim.
+                throw new ApplyError("APPLY_LEDGER_UNAVAILABLE", "This daemon has no ingestion ledger, so it cannot bound a batch apply.");
+            }
+            const filter = await this.filterStore.get(request.filterId);
+            const items = await this.resolveMatchedItems(filter, request.itemKeys);
+            if (!filter) {
+                throw new IngestionError("FILTER_MISSING", `No filter ${request.filterId} on this daemon.`, 404);
+            }
+            const result = await applySelection({
+                filter,
+                items,
+                itemKeys: request.itemKeys,
+                mode: request.mode,
+                ...(request.confirmedGroups === undefined
+                    ? {}
+                    : { confirmedGroups: request.confirmedGroups }),
+                limiter,
+                ledger,
+                schedule: this.dispatcher,
+                cohorts: this.cohorts,
+                now: () => new Date(),
+            });
+            if (result.report.truncated > 0) {
+                // Named in the log as well as on screen. A shortened batch that only the
+                // UI mentions is invisible the moment somebody reads the logs instead.
+                this.logger.info({
+                    filterId: filter.id,
+                    requested: result.report.requested,
+                    admitted: result.report.admitted,
+                    truncated: result.report.truncated,
+                }, "Ingestion apply was shortened by the filter's daily cap");
+            }
+            this.host.emit({
+                type: "ingestion/apply/response",
+                payload: {
+                    requestId: request.requestId,
+                    status: result.status,
+                    cohortId: result.cohortId,
+                    collapse: result.collapse,
+                    report: result.report,
+                    targetCwd: filter.target.config.cwd,
+                    error: null,
+                },
+            });
+        }
+        catch (error) {
+            const message = toIngestionErrorMessage(error);
+            this.logger.error({ err: error, requestType: request.type, clientId: this.clientId }, "Ingestion apply failed");
+            // Status, collapse and report are null TOGETHER with a non-null error.
+            // Naming one of the three real outcomes here would be a claim about a
+            // plan that was never computed.
+            this.host.emit({
+                type: "ingestion/apply/response",
+                payload: {
+                    requestId: request.requestId,
+                    status: null,
+                    cohortId: null,
+                    collapse: null,
+                    report: null,
+                    targetCwd: null,
+                    error: message,
+                },
+            });
+        }
+    }
+    /**
+     * Read one cohort back: counters, derived counts, and whether it is finished.
+     *
+     * `cohort: null` with `error: null` means THIS COHORT DOES NOT EXIST.
+     * `cohort: null` with a non-null `error` means the read failed. The row must
+     * be able to tell those apart, so they are never collapsed into one empty
+     * answer - "empty output is not evidence of absence" is a wire-shape rule
+     * here, not just a habit.
+     */
+    async handleIngestionCohortInspectRequest(request) {
+        try {
+            const store = this.cohortStore;
+            if (!store) {
+                throw new CohortRpcError("COHORT_STORE_UNAVAILABLE", "This daemon has no ingestion ledger, so it has no record of any cohort.");
+            }
+            this.host.emit({
+                type: "ingestion/cohort/inspect/response",
+                payload: {
+                    requestId: request.requestId,
+                    cohort: store.inspect(request.cohortId),
+                    error: null,
+                },
+            });
+        }
+        catch (error) {
+            this.emitCohortInspectError(request, error);
+        }
+        return Promise.resolve();
+    }
+    /**
+     * Cancel what has not started, and report how many sessions were left running.
+     *
+     * The set this touches is decided by row status on this side of the wire; the
+     * request carries no list of groups and no force flag, so a client structurally
+     * cannot ask for a live session to be interrupted.
+     *
+     * `stillRunning` travels back with the cohort because a cancel that stopped 3
+     * of 5 groups must not read like a cancel that stopped everything.
+     */
+    async handleIngestionCohortCancelRequest(request) {
+        try {
+            const store = this.cohortStore;
+            if (!store) {
+                throw new CohortRpcError("COHORT_STORE_UNAVAILABLE", "This daemon has no ingestion ledger, so it has no record of any cohort.");
+            }
+            if (store.inspect(request.cohortId) === null) {
+                // Refused rather than answered with zeroes: `{ cancelled: 0 }` for a
+                // cohort that does not exist reads exactly like a cancel that found
+                // nothing to stop, and those are different facts.
+                throw new CohortRpcError("COHORT_MISSING", `No cohort ${request.cohortId} on this daemon.`);
+            }
+            const result = store.cancelRemaining(request.cohortId);
+            this.logger.info({
+                cohortId: request.cohortId,
+                cancelled: result.cancelled,
+                stillRunning: result.stillRunning,
+            }, "Ingestion cohort cancelled its pending groups");
+            this.host.emit({
+                type: "ingestion/cohort/cancel/response",
+                payload: {
+                    requestId: request.requestId,
+                    cohort: store.inspect(request.cohortId),
+                    cancelled: result.cancelled,
+                    stillRunning: result.stillRunning,
+                    error: null,
+                },
+            });
+        }
+        catch (error) {
+            const message = toIngestionErrorMessage(error);
+            this.logger.error({ err: error, requestType: request.type, clientId: this.clientId }, "Ingestion cohort cancel failed");
+            // Both counts are ZERO beside a non-null error, and that pairing is what
+            // makes them readable: a client that saw `cancelled: 0` with no error
+            // would believe nothing was pending, which is a claim this path never got
+            // far enough to make.
+            this.host.emit({
+                type: "ingestion/cohort/cancel/response",
+                payload: {
+                    requestId: request.requestId,
+                    cohort: null,
+                    cancelled: 0,
+                    stillRunning: 0,
+                    error: message,
+                },
+            });
+        }
+        return Promise.resolve();
+    }
+    /**
+     * One filter's ingestion runs, from the LEDGER, with the closed ones dropped.
+     *
+     * Follows `handleScheduleLogsRequest` (`chat-schedule-loop-session.ts:370`)
+     * verbatim in shape: try, emit with `error: null`, catch, emit the error on
+     * the same channel.
+     *
+     * THE ORDER OF THE LAST TWO STATEMENTS IS THE WHOLE OF AC 15, so it is spelled
+     * out rather than left to be inferred:
+     *
+     *   1. read the schedule's runs and join them to the ledger    (disk only)
+     *   2. project into `IngestionRunView`                          (pure)
+     *   3. drop the views whose verdict maps to `inInbox === false` (pure)
+     *   4. EMIT
+     *   5. only THEN kick off `verifyIfStale`, without awaiting it
+     *
+     * Step 5's `void` is LOAD-BEARING. Awaiting it would put up to six MCP round-
+     * trips - a 10s Gmail timeout among them - in front of the Inbox's first
+     * paint, on every render, for a result the very next poll would have picked
+     * up anyway. The app already re-queries every five seconds
+     * (`use-schedules.ts`, `staleTime: 5_000` + `keepPreviousData`), so the
+     * verdict this call writes lands on screen within seconds, with no flicker and
+     * no push channel (decision D-6.2-D).
+     *
+     * Step 3 happens HERE, at the daemon, and not in the app. Closure is not a
+     * rendering decision: a client that forgot the filter would show a row for
+     * work that is already done, and the whole epic is about not doing that.
+     */
+    async handleIngestionRunsRequest(request) {
+        try {
+            const views = await this.readRunViews(request.filterId);
+            const visible = request.includeClosed === true ? views : views.filter((view) => isInInbox(view.verdict));
+            this.host.emit({
+                type: "ingestion/runs/response",
+                payload: { requestId: request.requestId, runs: visible, error: null },
+            });
+            // AFTER the emit, and deliberately not awaited. See the docblock above:
+            // awaiting this would trade the Inbox's first paint for a verdict that
+            // arrives five seconds later regardless.
+            this.scheduleReconciliation(request.filterId, views);
+        }
+        catch (error) {
+            const message = toIngestionErrorMessage(error);
+            this.logger.error({ err: error, requestType: request.type, clientId: this.clientId }, "Ingestion runs request failed");
+            // An EMPTY array beside a NON-NULL error. The pairing is what keeps the
+            // two states apart: `[]` with `error: null` means this filter has no
+            // source schedule, which is an ordinary state, while `[]` with an error
+            // means the read broke. A client that cannot tell them apart renders a
+            // broken daemon as an idle filter.
+            this.host.emit({
+                type: "ingestion/runs/response",
+                payload: { requestId: request.requestId, runs: [], error: message },
+            });
+        }
+    }
+    /**
+     * Fire the background re-read, and never let it reach the caller.
+     *
+     * Every failure mode is swallowed at ERROR rather than propagated, because
+     * this call is downstream of a response that has already been emitted: a
+     * rejection here would surface as an unhandled rejection on the daemon's event
+     * loop, having already told the client everything was fine.
+     *
+     * A filter that resolves to no source, or a daemon with no reconciliation
+     * wiring, does nothing at all. Reconciliation is an enhancement to a read that
+     * already worked.
+     */
+    scheduleReconciliation(filterId, views) {
+        const reconciliation = this.reconciliation;
+        if (!reconciliation || views.length === 0)
+            return;
+        void reconciliation
+            .verify(filterId, views)
+            .catch((error) => this.logger.error({ err: error, filterId, clientId: this.clientId }, "Background ingestion reconciliation failed"));
+    }
+    /**
+     * Resolve a filter to its schedule, then join that schedule's runs to the
+     * ledger rows.
+     *
+     * A LINEAR SCAN over `list()`, and deliberately so (decision D-6.1-I):
+     * schedules are one small JSON file each in a low-cardinality directory that
+     * the service has already loaded, so an index would be a second thing to keep
+     * correct for a list that fits in a screenful.
+     *
+     * No match resolves to `[]`, never a throw. A filter that has not been armed
+     * yet has no source schedule, and that is a state the Inbox asks about
+     * routinely rather than an error.
+     *
+     * A ledger that could not open resolves to `[]` too, on the same reasoning as
+     * everywhere else in this class: a missing dedupe memory must not blank the
+     * Inbox, and `[]` with `error: null` is the honest empty.
+     *
+     * The cadence is narrowed with `"filterId" in cadence` rather than by
+     * asserting the member exists, so this compiles against any shape of
+     * `ScheduleCadenceSchema` - including one without the `source` member.
+     */
+    async readRunViews(filterId) {
+        const ledger = this.ledger;
+        if (!ledger)
+            return [];
+        const schedules = await this.schedules.list();
+        const schedule = schedules.find((candidate) => candidate.cadence.type === "source" &&
+            "filterId" in candidate.cadence &&
+            candidate.cadence.filterId === filterId);
+        if (!schedule)
+            return [];
+        return buildIngestionRunViews(schedule.runs, ledger.listRunViewRows(filterId, RUN_VIEW_ROW_LIMIT));
+    }
+    /**
+     * The inspect path's own error emitter.
+     *
+     * Not `emitIngestionRpcError`: that one emits an `ingestion/backfill/response`,
+     * because it was written for the backfill request type. Answering a cohort
+     * inspect on the backfill channel would leave the correlated request hanging
+     * forever - the exact "resolves to nothing" failure this file's other comments
+     * exist to prevent - so each ingestion RPC pair reports on its own channel.
+     */
+    emitCohortInspectError(request, error) {
+        const message = toIngestionErrorMessage(error);
+        this.logger.error({ err: error, requestType: request.type, clientId: this.clientId }, "Ingestion cohort inspect failed");
+        this.host.emit({
+            type: "ingestion/cohort/inspect/response",
+            payload: { requestId: request.requestId, cohort: null, error: message },
+        });
+    }
+}
+//# sourceMappingURL=chat-ingestion-session.js.map

package/dist/server/server/session/chat/chat-schedule-loop-session.d.ts

@@ -0,0 +1,175 @@
+import type pino from "pino";
+import type { SessionInboundMessage, SessionOutboundMessage } from "../../messages.js";
+import type { StoredAgentRecord } from "../../agent/agent-storage.js";
+import type { ManagedAgent } from "../../agent/agent-manager.js";
+import { type FileBackedChatService } from "../../chat/chat-service.js";
+import type { LoopService } from "../../loop-service.js";
+import type { ScheduleService } from "../../schedule/service.js";
+import { FleetService } from "../../fleet/fleet-service.js";
+import type { FleetExecution } from "@hyperdrive.bot/fleet-protocol/fleet/types";
+/**
+ * The collaborators a chat command reaches that are NOT part of the chat/schedule/loop
+ * domain: the agent roster reads and the agent-message send used only by chat/post
+ * mention fanout. The Session shell owns the agent lifecycle; this subsystem orchestrates
+ * a notification through it but does not own it.
+ */
+export interface ChatScheduleLoopSessionHost {
+    emit(msg: SessionOutboundMessage): void;
+    listStoredAgents(): Promise<StoredAgentRecord[]>;
+    listLiveAgents(): ManagedAgent[];
+    listLoopExecutions(loopName: string): Promise<FleetExecution[]>;
+    resolveAgentIdentifier(identifier: string): Promise<{
+        ok: true;
+        agentId: string;
+    } | {
+        ok: false;
+        error: string;
+    }>;
+    sendAgentMessage(agentId: string, text: string): Promise<void>;
+}
+export interface ChatScheduleLoopSessionOptions {
+    host: ChatScheduleLoopSessionHost;
+    chatService: FileBackedChatService;
+    scheduleService: ScheduleService;
+    loopService: LoopService;
+    fleetService?: FleetService;
+    clientId: string;
+    logger: pino.Logger;
+}
+/**
+ * A client's chat, schedule, and loop request surface. The three families are the
+ * least-coupled in the session: each is a stateless request/response over its own
+ * service (chat rooms, cron routines, autonomous loops), with no shared observer,
+ * git, or voice state and no subscriptions to tear down. They live in one subsystem
+ * because they are dispatched together — schedule/* was historically reached through
+ * the chat dispatcher's fall-through arm. The three rpc-error emitters stay separate:
+ * they differ by default code, and only the chat one reads ChatServiceError.code.
+ */
+export declare class ChatScheduleLoopSession {
+    private readonly host;
+    private readonly chatService;
+    private readonly scheduleService;
+    private readonly loopService;
+    private readonly fleetService;
+    private readonly clientId;
+    private readonly logger;
+    constructor(options: ChatScheduleLoopSessionOptions);
+    private emitChatRpcError;
+    handleChatCreateRequest(request: Extract<SessionInboundMessage, {
+        type: "chat/create";
+    }>): Promise<void>;
+    handleChatListRequest(request: Extract<SessionInboundMessage, {
+        type: "chat/list";
+    }>): Promise<void>;
+    handleChatInspectRequest(request: Extract<SessionInboundMessage, {
+        type: "chat/inspect";
+    }>): Promise<void>;
+    handleChatDeleteRequest(request: Extract<SessionInboundMessage, {
+        type: "chat/delete";
+    }>): Promise<void>;
+    handleChatPostRequest(request: Extract<SessionInboundMessage, {
+        type: "chat/post";
+    }>): Promise<void>;
+    handleChatReadRequest(request: Extract<SessionInboundMessage, {
+        type: "chat/read";
+    }>): Promise<void>;
+    handleChatWaitRequest(request: Extract<SessionInboundMessage, {
+        type: "chat/wait";
+    }>): Promise<void>;
+    private toScheduleSummary;
+    private emitScheduleRpcError;
+    handleScheduleCreateRequest(request: Extract<SessionInboundMessage, {
+        type: "schedule/create";
+    }>): Promise<void>;
+    handleScheduleListRequest(request: Extract<SessionInboundMessage, {
+        type: "schedule/list";
+    }>): Promise<void>;
+    handleScheduleInspectRequest(request: Extract<SessionInboundMessage, {
+        type: "schedule/inspect";
+    }>): Promise<void>;
+    handleScheduleLogsRequest(request: Extract<SessionInboundMessage, {
+        type: "schedule/logs";
+    }>): Promise<void>;
+    handleSchedulePauseRequest(request: Extract<SessionInboundMessage, {
+        type: "schedule/pause";
+    }>): Promise<void>;
+    handleScheduleResumeRequest(request: Extract<SessionInboundMessage, {
+        type: "schedule/resume";
+    }>): Promise<void>;
+    handleScheduleDeleteRequest(request: Extract<SessionInboundMessage, {
+        type: "schedule/delete";
+    }>): Promise<void>;
+    handleScheduleRunOnceRequest(request: Extract<SessionInboundMessage, {
+        type: "schedule/run-once";
+    }>): Promise<void>;
+    handleScheduleUpdateRequest(request: Extract<SessionInboundMessage, {
+        type: "schedule/update";
+    }>): Promise<void>;
+    private emitLoopRpcError;
+    handleLoopRunRequest(request: Extract<SessionInboundMessage, {
+        type: "loop/run";
+    }>): Promise<void>;
+    handleLoopListRequest(request: Extract<SessionInboundMessage, {
+        type: "loop/list";
+    }>): Promise<void>;
+    handleLoopInspectRequest(request: Extract<SessionInboundMessage, {
+        type: "loop/inspect";
+    }>): Promise<void>;
+    handleLoopLogsRequest(request: Extract<SessionInboundMessage, {
+        type: "loop/logs";
+    }>): Promise<void>;
+    handleLoopStopRequest(request: Extract<SessionInboundMessage, {
+        type: "loop/stop";
+    }>): Promise<void>;
+    private emitFleetRpcError;
+    handleFleetListRequest(request: Extract<SessionInboundMessage, {
+        type: "fleet/list";
+    }>): Promise<void>;
+    handleFleetInspectRequest(request: Extract<SessionInboundMessage, {
+        type: "fleet/inspect";
+    }>): Promise<void>;
+    handleFleetRunNowRequest(request: Extract<SessionInboundMessage, {
+        type: "fleet/run-now";
+    }>): Promise<void>;
+    handleFleetPauseRequest(request: Extract<SessionInboundMessage, {
+        type: "fleet/pause";
+    }>): Promise<void>;
+    handleFleetResumeRequest(request: Extract<SessionInboundMessage, {
+        type: "fleet/resume";
+    }>): Promise<void>;
+    /**
+     * Promote a loop to live, or demote it to dry-run.
+     *
+     * `changed: false` means the loop was already in that mode and nothing was written,
+     * which the UI reports as a no-op rather than a success so a stale toggle cannot look
+     * like it did something.
+     */
+    handleFleetSetModeRequest(request: Extract<SessionInboundMessage, {
+        type: "fleet/set-mode";
+    }>): Promise<void>;
+    /** A loop raising a typed question for a human. */
+    handleFleetAskRequest(request: Extract<SessionInboundMessage, {
+        type: "fleet/ask";
+    }>): Promise<void>;
+    /** The decision inbox: what a loop is waiting on a person for. */
+    handleFleetDecisionsRequest(request: Extract<SessionInboundMessage, {
+        type: "fleet/decisions";
+    }>): Promise<void>;
+    /**
+     * Answer a decision. Attributed to a human, which is what distinguishes it from the
+     * same option being applied by the clock running out.
+     */
+    handleFleetResolveDecisionRequest(request: Extract<SessionInboundMessage, {
+        type: "fleet/resolve-decision";
+    }>): Promise<void>;
+    handleFleetSetParamsRequest(request: Extract<SessionInboundMessage, {
+        type: "fleet/set-params";
+    }>): Promise<void>;
+    handleFleetCreateRequest(request: Extract<SessionInboundMessage, {
+        type: "fleet/create";
+    }>): Promise<void>;
+    handleFleetExecutionsRequest(request: Extract<SessionInboundMessage, {
+        type: "fleet/executions";
+    }>): Promise<void>;
+}
+//# sourceMappingURL=chat-schedule-loop-session.d.ts.map