@hyperdrive.bot/fleet-server 0.3.99

package/dist/server/server/ingestion/apply.d.ts

@@ -0,0 +1,220 @@
+import type { StoredFilter } from "@hyperdrive.bot/fleet-protocol/ingestion/filter-types";
+import type { ApplyStatus, CapReport, CollapseCount } from "@hyperdrive.bot/fleet-protocol/ingestion/types";
+import type { CapLimiterAdmit } from "./cap-limiter.js";
+import { type DryRunDispatcher } from "./dry-run.js";
+import type { ClaimOptions, MarkOptions } from "./ledger.js";
+import type { MatchedItem, MatchedItemGroup } from "./types.js";
+/**
+ * Above THIS many groups, a manual apply needs an explicit yes.
+ *
+ * `1`, not `0` and not `5`. Forty items that collapse to a single group produce
+ * ONE outward artifact - one merge request, one draft - and that is the
+ * single-item case the user already consented to by pressing the verb. The
+ * threshold is about how many artifacts appear in the world, never about how
+ * many rows were ticked.
+ */
+export declare const BATCH_CONFIRM_THRESHOLD_GROUPS = 1;
+/** What one group of a cohort is doing, on the cohort record. */
+export type CohortGroupStatus = "pending" | "running" | "succeeded" | "failed" | "skipped";
+export interface CohortGroupPatch {
+    status?: CohortGroupStatus;
+    agentId?: string | null;
+    error?: string | null;
+    /**
+     * The run this group was dispatched as. Written on `running` and nowhere else.
+     *
+     * Added by Story 5.4 because it is the ONLY thing that makes "this group was
+     * dispatched exactly once" checkable after a crash: a second dispatch would
+     * have to write a second, different value. `agentId` cannot stand in for it -
+     * it is null at dispatch and only arrives when the session comes back.
+     */
+    runId?: string | null;
+}
+export interface CohortCreateInput {
+    filterId: string;
+    mode: "dry-run" | "apply";
+    createdAt: number;
+    /** Every group this cohort dispatched, in the grouper's deterministic order. */
+    groups: Array<{
+        key: string;
+        itemKeys: string[];
+    }>;
+    /** How many groups were handed to the provider. NEVER how many succeeded. */
+    dispatched: number;
+    report: CapReport;
+}
+/**
+ * The narrow port `applySelection` records a cohort through (D6).
+ *
+ * Two methods, no store, no sqlite, no home directory. Story 5.4's
+ * `cohort-store.ts` becomes the production implementation by satisfying this
+ * structurally; this story's tests use an in-memory fake. Depending on the
+ * concrete store here would make 5.3 unshippable until 5.4 lands and would
+ * invite a second cohort store to appear in this file in the meantime.
+ */
+export interface CohortRecorder {
+    create(input: CohortCreateInput): Promise<string>;
+    markGroup(cohortId: string, groupKey: string, patch: CohortGroupPatch): Promise<void>;
+}
+/**
+ * The ledger surface the apply path touches, and nothing wider.
+ *
+ * `claim` and `mark` only. No `touch`, no `recordFailure`, no `prune`: the two
+ * methods here are the two halves of the discipline this module has to keep -
+ * claim when the dispatch leaves, mark only when it comes back succeeded - and
+ * a wider port would put "record this as handled" within reach of the dispatch
+ * site.
+ */
+export interface ApplyLedger {
+    claim(filterId: string, itemKey: string, options: ClaimOptions): boolean;
+    mark(filterId: string, itemKey: string, options: MarkOptions): void;
+}
+export interface ApplyResult {
+    status: ApplyStatus;
+    cohortId: string | null;
+    collapse: CollapseCount;
+    report: CapReport;
+}
+export interface ApplySelectionParams {
+    filter: StoredFilter;
+    /**
+     * The matched items the selection is drawn FROM - the preview the user was
+     * looking at, already matched, already carrying payloads.
+     *
+     * DIVERGENCE from the story's AC1 signature, which lists eight keys and no
+     * item source. Task 2 requires `applySelection` to "resolve `itemKeys` to
+     * items", and none of the eight can do that: `ledger` stores hashes and never
+     * payloads, and a gateway is deliberately absent. Passing the pool in keeps
+     * the resolution a pure set intersection and keeps this module unable to read
+     * a source at all, which is decision 3 in the file header.
+     */
+    items: readonly MatchedItem[];
+    /** The subset of `items` the user ticked, by `MatchedItem.key`. */
+    itemKeys: readonly string[];
+    mode: "dry-run" | "apply";
+    /**
+     * The group count the CLIENT is confirming, echoed back from a previous
+     * `needs-confirmation` response. Absent on a first call.
+     *
+     * Never a client-side computation and never a preference. It is a claim about
+     * what the client was shown, and this module's only use for it is to check it
+     * against a freshly recomputed number and refuse on a mismatch.
+     */
+    confirmedGroups?: number;
+    limiter: CapLimiterAdmit;
+    ledger: ApplyLedger;
+    /** `ScheduleService`, structurally. The ONE new-agent minting path in the daemon. */
+    schedule: DryRunDispatcher;
+    cohorts: CohortRecorder;
+    now: () => Date;
+    /** Injected for determinism in tests. Defaults to `randomUUID`, like `service.ts`. */
+    runIdFactory?: () => string;
+    /**
+     * Called once the background dispatch loop settles.
+     *
+     * `applySelection` resolves BEFORE the sessions finish (AC1), so without this
+     * a test would have to poll for completion and a caller would have no way to
+     * know the cohort reached a terminal state. It is a notification, never a
+     * result: nothing downstream is allowed to treat "the loop ended" as "the
+     * groups succeeded".
+     */
+    onSettled?: (summary: {
+        cohortId: string;
+        succeeded: number;
+        failed: number;
+    }) => void;
+}
+/**
+ * Filter ids with a manual apply in flight, process-wide.
+ *
+ * DIVERGENCE from the story's Task 2, which names
+ * `ScheduleService.runningScheduleIds`. That set is private, has no accessor,
+ * and is keyed by SCHEDULE id - a manual apply has no schedule row, so there is
+ * no id of that kind to put in it. The ledger's own comment is explicit that
+ * `claim()` is item-level dedupe and NOT a process lock, so item claims do not
+ * cover this either: two concurrent applies of the same filter would each pass
+ * the confirmation gate, each admit against the cap, and interleave two cohorts
+ * over one working directory.
+ *
+ * Module-scoped rather than per-session because the daemon serves many client
+ * connections from one process, and a per-connection guard would let two open
+ * tabs dispatch the same backlog twice. Exported so a test can assert it is
+ * empty after the loop settles rather than inferring it from behaviour.
+ */
+export declare const applyInFlightFilterIds: Set<string>;
+/**
+ * A refusal from the apply path, carrying a closed-set code.
+ *
+ * Its own class rather than an `IngestionError` code, because `IngestionError`'s
+ * set is consumed by `health.ts` to decide whether a SOURCE is `revoked` or
+ * `degraded`. Neither of those is true of "an apply is already running" or "this
+ * daemon has no ledger", and adding the codes there would force a health verdict
+ * about an aggregator that is working perfectly.
+ *
+ * `code` is what reaches the client (the message can quote local state); the set
+ * is closed and written here, so it stays renderable without becoming a channel
+ * for anything upstream.
+ */
+export declare class ApplyError extends Error {
+    readonly code: "APPLY_ALREADY_RUNNING" | "APPLY_LEDGER_UNAVAILABLE";
+    constructor(code: ApplyError["code"], message: string);
+}
+/** A manual apply refused because one is already running for this filter. */
+export declare class ApplyInFlightError extends ApplyError {
+    constructor(filterId: string);
+}
+/**
+ * Dispatch one group's session and record what happened to it.
+ *
+ * The claim/mark split is the whole point, and the asymmetry is deliberate:
+ * every item is CLAIMED before the provider is called, and items are MARKED only
+ * after the run comes back succeeded. A group whose run rejects therefore leaves
+ * zero marks, leaves `content_hash` untouched, and leaves every one of its items
+ * fresh for a later retry. Marking at dispatch would be recording intent as
+ * fact, and the cost of that mistake here is a backlog the user believes was
+ * handled and nobody ever looks at again.
+ *
+ * A group with nothing left to claim is SKIPPED, not dispatched: every one of
+ * its items is already held by another run, so briefing a session about them
+ * would duplicate that run's outward artifact.
+ *
+ * ONE try covers the whole body, ledger calls included, and that is not defensive
+ * padding - it is a bug this spec caught. `ledger.claim` sits before the
+ * dispatch, so a sqlite throw there (the file locked, the disk full, or the
+ * connection closed under a daemon that is shutting down mid-batch) escaped the
+ * inner try, escaped the loop's `for`, and rejected the un-awaited background
+ * promise. An unhandled rejection takes the daemon down, long after the caller
+ * that started the apply stopped listening. Caught here, the same condition is
+ * one failed group on the cohort and nine surviving runs.
+ */
+/**
+ * Dispatch ONE group: claim, mint, mark. The unit of one outward artifact.
+ *
+ * Exported for Story 5.4's restart resume, which must take the IDENTICAL path a
+ * freshly-applied group takes - same limiter reservation, same ledger claim,
+ * same single-flight, same prompt. A resume that re-implemented this would be a
+ * second dispatcher, and the two would drift on the first change to either.
+ */
+export declare function dispatchGroup(params: {
+    filter: StoredFilter;
+    group: MatchedItemGroup;
+    runId: string;
+    ledger: ApplyLedger;
+    schedule: DryRunDispatcher;
+    cohorts: CohortRecorder;
+    cohortId: string;
+    limiter: CapLimiterAdmit;
+}): Promise<boolean>;
+/**
+ * Apply a selection: price it, gate it, and dispatch it.
+ *
+ * RESOLVES EARLY, on purpose. On `status: "dispatched"` this promise settles
+ * once the cohort row exists and the dispatch loop has been kicked off - not
+ * once the sessions have finished. Forty sessions can take an hour; a client
+ * that had to hold a correlated RPC open for that long would time out, and the
+ * user would be told the apply failed while forty agents were still working.
+ * The cohort row is the durable record, and it reads `succeeded === 0` at the
+ * moment this returns, which is exactly what it should say.
+ */
+export declare function applySelection(params: ApplySelectionParams): Promise<ApplyResult>;
+//# sourceMappingURL=apply.d.ts.map

package/dist/server/server/ingestion/apply.js

@@ -0,0 +1,345 @@
+// The APPLY verb: turn a user's selection on the backfill worklist into real
+// sessions, under the filter's own group key and the filter's own daily cap.
+//
+// This is the one gesture in the product that can produce dozens of outward
+// artifacts in a single tap - merge requests, Gmail drafts, CI pipelines,
+// reviewer pings - so the module's whole shape is organised around one
+// invariant: THE NUMBER SHOWN IS THE NUMBER DISPATCHED.
+//
+// Three structural decisions carry that invariant, and each is expressed as an
+// absence rather than as a rule somebody has to remember:
+//
+//   1. NO GROUPING HERE. `groupMatchedItems` and `collapseCount` are imported
+//      from `./grouping.js`. This file contains no `Map`-keyed bucketing, no
+//      local `groupKey` reducer and no `Set`-based count. Two implementations
+//      of "how many sessions is this" can disagree; one cannot, and the one
+//      that can disagree is the one that would be wrong on the confirmation
+//      screen.
+//   2. NO LIMITER CONSTRUCTION. The `CapLimiter` arrives injected and is the
+//      same object the overnight tick spends. `new CapLimiter(` does not appear
+//      in this file, and a source-scan test fails the build if it ever does.
+//      A second limiter would be a second belief about the day's budget.
+//   3. NO SOURCE GATEWAY. `applySelection` never receives one, so nothing here
+//      can read a mailbox, resolve an MCP target or reach an aggregator. Items
+//      arrive already matched, from the preview the user was looking at.
+//
+// The confirmation gate is enforced HERE, on the server, and not on the screen.
+// A screen-side confirmation is bypassable by any other caller - a CLI, a
+// script, a future MCP tool - and by a client bug. So a multi-group apply is a
+// two-round-trip protocol: the first call prices the plan with the
+// NON-CONSUMING `limiter.preview` and refuses; the client shows the daemon's own
+// numbers; the second call echoes `confirmedGroups`, the daemon recomputes, and
+// refuses again on any mismatch. See D7 in the story.
+import { randomUUID } from "node:crypto";
+import { FILTER_ID_LABEL, INGESTION_MODE_LABEL, ITEM_GROUP_LABEL, ITEM_KEYS_LABEL, } from "@hyperdrive.bot/fleet-protocol/agent-labels";
+import { buildSourceRunPrompt } from "../schedule/source-prompt.js";
+import { runDryRun } from "./dry-run.js";
+import { collapseCount, groupMatchedItems } from "./grouping.js";
+/**
+ * Above THIS many groups, a manual apply needs an explicit yes.
+ *
+ * `1`, not `0` and not `5`. Forty items that collapse to a single group produce
+ * ONE outward artifact - one merge request, one draft - and that is the
+ * single-item case the user already consented to by pressing the verb. The
+ * threshold is about how many artifacts appear in the world, never about how
+ * many rows were ticked.
+ */
+export const BATCH_CONFIRM_THRESHOLD_GROUPS = 1;
+/**
+ * Filter ids with a manual apply in flight, process-wide.
+ *
+ * DIVERGENCE from the story's Task 2, which names
+ * `ScheduleService.runningScheduleIds`. That set is private, has no accessor,
+ * and is keyed by SCHEDULE id - a manual apply has no schedule row, so there is
+ * no id of that kind to put in it. The ledger's own comment is explicit that
+ * `claim()` is item-level dedupe and NOT a process lock, so item claims do not
+ * cover this either: two concurrent applies of the same filter would each pass
+ * the confirmation gate, each admit against the cap, and interleave two cohorts
+ * over one working directory.
+ *
+ * Module-scoped rather than per-session because the daemon serves many client
+ * connections from one process, and a per-connection guard would let two open
+ * tabs dispatch the same backlog twice. Exported so a test can assert it is
+ * empty after the loop settles rather than inferring it from behaviour.
+ */
+export const applyInFlightFilterIds = new Set();
+/**
+ * A refusal from the apply path, carrying a closed-set code.
+ *
+ * Its own class rather than an `IngestionError` code, because `IngestionError`'s
+ * set is consumed by `health.ts` to decide whether a SOURCE is `revoked` or
+ * `degraded`. Neither of those is true of "an apply is already running" or "this
+ * daemon has no ledger", and adding the codes there would force a health verdict
+ * about an aggregator that is working perfectly.
+ *
+ * `code` is what reaches the client (the message can quote local state); the set
+ * is closed and written here, so it stays renderable without becoming a channel
+ * for anything upstream.
+ */
+export class ApplyError extends Error {
+    constructor(code, message) {
+        super(message);
+        this.name = "ApplyError";
+        this.code = code;
+    }
+}
+/** A manual apply refused because one is already running for this filter. */
+export class ApplyInFlightError extends ApplyError {
+    constructor(filterId) {
+        super("APPLY_ALREADY_RUNNING", `An apply is already running for filter ${filterId}`);
+        this.name = "ApplyInFlightError";
+    }
+}
+/**
+ * The selected subset, in the pool's own order.
+ *
+ * Order comes from `items`, never from `itemKeys`, so a client that shuffled its
+ * selection set cannot change which groups survive a truncating cap. A key that
+ * matches nothing is DROPPED rather than throwing: a stale key is an ordinary
+ * consequence of the world moving between the preview and the apply, and it
+ * shows up honestly as a smaller `collapse.selected` than the client expected.
+ */
+function selectItems(items, itemKeys) {
+    const wanted = new Set(itemKeys);
+    return items.filter((item) => wanted.has(item.key));
+}
+/**
+ * Dispatch one group's session and record what happened to it.
+ *
+ * The claim/mark split is the whole point, and the asymmetry is deliberate:
+ * every item is CLAIMED before the provider is called, and items are MARKED only
+ * after the run comes back succeeded. A group whose run rejects therefore leaves
+ * zero marks, leaves `content_hash` untouched, and leaves every one of its items
+ * fresh for a later retry. Marking at dispatch would be recording intent as
+ * fact, and the cost of that mistake here is a backlog the user believes was
+ * handled and nobody ever looks at again.
+ *
+ * A group with nothing left to claim is SKIPPED, not dispatched: every one of
+ * its items is already held by another run, so briefing a session about them
+ * would duplicate that run's outward artifact.
+ *
+ * ONE try covers the whole body, ledger calls included, and that is not defensive
+ * padding - it is a bug this spec caught. `ledger.claim` sits before the
+ * dispatch, so a sqlite throw there (the file locked, the disk full, or the
+ * connection closed under a daemon that is shutting down mid-batch) escaped the
+ * inner try, escaped the loop's `for`, and rejected the un-awaited background
+ * promise. An unhandled rejection takes the daemon down, long after the caller
+ * that started the apply stopped listening. Caught here, the same condition is
+ * one failed group on the cohort and nine surviving runs.
+ */
+/**
+ * Dispatch ONE group: claim, mint, mark. The unit of one outward artifact.
+ *
+ * Exported for Story 5.4's restart resume, which must take the IDENTICAL path a
+ * freshly-applied group takes - same limiter reservation, same ledger claim,
+ * same single-flight, same prompt. A resume that re-implemented this would be a
+ * second dispatcher, and the two would drift on the first change to either.
+ */
+export async function dispatchGroup(params) {
+    const { filter, group, runId, ledger, schedule, cohorts, cohortId, limiter } = params;
+    try {
+        const claimed = group.items.filter((item) => ledger.claim(filter.id, item.key, { runId, agentId: null }));
+        if (claimed.length === 0) {
+            await cohorts.markGroup(cohortId, group.key, {
+                status: "skipped",
+                error: "every item in this group is already claimed by another run",
+            });
+            // The reservation goes back. Without this, a group nobody dispatched would
+            // stay burned for the rest of the UTC day and the operator would read "cap
+            // reached" with one fewer artifact than the number implies.
+            limiter.release(filter.id, 1);
+            return false;
+        }
+        await cohorts.markGroup(cohortId, group.key, { status: "running", runId });
+        const outcome = await schedule.runUnattendedSession({
+            targetConfig: filter.target.config,
+            prompt: buildSourceRunPrompt({ filter, items: claimed, runId, mode: "apply" }),
+            // No `paseo.schedule-id` / `paseo.schedule-run`: a manual apply is not a
+            // schedule run, and labelling it as one would put a phantom row in every
+            // surface that walks schedule provenance.
+            labels: {
+                [FILTER_ID_LABEL]: filter.id,
+                [ITEM_GROUP_LABEL]: group.key,
+                [ITEM_KEYS_LABEL]: claimed.map((item) => item.key).join(","),
+                [INGESTION_MODE_LABEL]: "apply",
+            },
+        });
+        // ONLY here. The run reached `succeeded`, so the items it covered are
+        // handled, and `agentId` is recorded the way `finishRun` records it on a
+        // `ScheduleRun`.
+        for (const item of claimed) {
+            ledger.mark(filter.id, item.key, {
+                outcome: "applied",
+                contentHash: item.contentHash,
+                agentId: outcome.agentId,
+            });
+        }
+        await cohorts.markGroup(cohortId, group.key, {
+            status: "succeeded",
+            agentId: outcome.agentId,
+            error: null,
+        });
+        return true;
+    }
+    catch (error) {
+        // Best-effort: if the cohort recorder is the thing that failed, there is
+        // nowhere left to write the failure, and throwing from a catch block would
+        // put us straight back in the unhandled-rejection hole this try exists to
+        // close.
+        await cohorts
+            .markGroup(cohortId, group.key, {
+            status: "failed",
+            agentId: null,
+            error: error instanceof Error ? error.message : String(error),
+        })
+            .catch(() => undefined);
+        return false;
+    }
+}
+/**
+ * Apply a selection: price it, gate it, and dispatch it.
+ *
+ * RESOLVES EARLY, on purpose. On `status: "dispatched"` this promise settles
+ * once the cohort row exists and the dispatch loop has been kicked off - not
+ * once the sessions have finished. Forty sessions can take an hour; a client
+ * that had to hold a correlated RPC open for that long would time out, and the
+ * user would be told the apply failed while forty agents were still working.
+ * The cohort row is the durable record, and it reads `succeeded === 0` at the
+ * moment this returns, which is exactly what it should say.
+ */
+export async function applySelection(params) {
+    const { filter, items, itemKeys, mode, limiter, ledger, schedule, cohorts, now } = params;
+    const runIdFactory = params.runIdFactory ?? (() => randomUUID());
+    const selected = selectItems(items, itemKeys);
+    // Both numbers from Epic 2, both from the SAME call path that decides what
+    // dispatches. `collapse.groups` and `groups.length` cannot disagree because
+    // `collapseCount` delegates to `groupMatchedItems`.
+    const collapse = collapseCount(selected, filter.groupKey);
+    const groups = groupMatchedItems(selected, filter.groupKey);
+    if (mode === "dry-run") {
+        // Story 5.2 owns the dry-run branch body, admission included: `runDryRun` is
+        // the single admission point for that verb and spends the in-memory tuning
+        // budget, never the on-disk apply budget. This story owns the wire surface
+        // and delegates. A second dry-run path here is how the two would drift.
+        //
+        // (The story's Task 2 names `planDryRun`; the merged Story 5.2 code names
+        // `runDryRun` as the function `applySelection` delegates to, and states so in
+        // its own doc comment. The merged code wins.)
+        const dry = await runDryRun({ filter, groups, limiter, dispatcher: schedule, runIdFactory });
+        return { status: "dispatched", cohortId: null, collapse, report: dry.report };
+    }
+    // THE GATE, in this order, and both refusals return before anything is
+    // claimed, written or spent.
+    if (collapse.groups > BATCH_CONFIRM_THRESHOLD_GROUPS && params.confirmedGroups === undefined) {
+        // Priced with the NON-CONSUMING verb. Using `admit` here would spend the
+        // day's real budget on a plan the user has not agreed to and may cancel.
+        const { report } = limiter.preview(filter.id, groups, filter.cap.runsPerDay);
+        return { status: "needs-confirmation", cohortId: null, collapse, report };
+    }
+    if (params.confirmedGroups !== undefined && params.confirmedGroups !== collapse.groups) {
+        // The world moved between the two round trips. Refusing is the point: a
+        // silent dispatch of the NEW number would be a different batch than the one
+        // the user said yes to, which is precisely the failure this gate exists for.
+        const { report } = limiter.preview(filter.id, groups, filter.cap.runsPerDay);
+        return { status: "stale-plan", cohortId: null, collapse, report };
+    }
+    if (applyInFlightFilterIds.has(filter.id)) {
+        throw new ApplyInFlightError(filter.id);
+    }
+    // CLAIMED IN THE SAME TICK AS THE CHECK, before the first `await`. Adding it
+    // after `cohorts.create` resolved would leave a window in which two concurrent
+    // applies both read an empty set, both awaited, and both dispatched - and this
+    // is the one verb in the product where losing that race means two batches of
+    // outward artifacts for one gesture. Everything below either releases it or
+    // hands it to the background loop's `finally`.
+    applyInFlightFilterIds.add(filter.id);
+    let admission;
+    let cohortId;
+    try {
+        // The limiter admits GROUPS, not items, because `cap.runsPerDay` counts
+        // sessions (D-5.2-E). Group first, admit second: admitting items and then
+        // grouping would let a filter capped at 10 dispatch 10 sessions covering far
+        // more than 10 items, and the number on the confirmation would stop meaning
+        // anything.
+        admission = limiter.admit(filter.id, groups, filter.cap.runsPerDay);
+        if (admission.admitted.length === 0) {
+            // Nothing to dispatch and therefore no cohort. The response still carries
+            // both numbers, so a client can tell an empty selection
+            // (`report.requested === 0`) from a cap that dropped everything
+            // (`requested > 0`, `truncated > 0`) - two states an empty screen would
+            // otherwise render identically.
+            applyInFlightFilterIds.delete(filter.id);
+            return { status: "dispatched", cohortId: null, collapse, report: admission.report };
+        }
+        cohortId = await cohorts.create({
+            filterId: filter.id,
+            mode,
+            createdAt: now().getTime(),
+            groups: admission.admitted.map((group) => ({
+                key: group.key,
+                itemKeys: group.items.map((item) => item.key),
+            })),
+            // DISPATCHED, never conflated with succeeded. At the instant this row is
+            // written, zero of these groups have succeeded, and the record says so by
+            // not carrying a success count at all.
+            dispatched: admission.admitted.length,
+            report: admission.report,
+        });
+    }
+    catch (error) {
+        // Nothing has been dispatched, so the guard has no owner yet. Reachable only
+        // before the background loop starts; once it does, its `finally` owns the
+        // release and this block cannot run.
+        applyInFlightFilterIds.delete(filter.id);
+        throw error;
+    }
+    // Deliberately NOT awaited - see the doc comment. `void` plus a `.catch` that
+    // cannot itself throw: an unhandled rejection here would take the daemon down
+    // long after the caller stopped listening.
+    void (async () => {
+        let succeeded = 0;
+        let failed = 0;
+        try {
+            // SEQUENTIAL, one session at a time, never a parallel fan-out: an admitted
+            // batch of ten must not open ten provider sessions in one working
+            // directory. Awaiting each dispatch is what bounds concurrency, and a
+            // group that fails does NOT abort the rest - one bad group is one failed
+            // row, not nine lost runs.
+            for (const group of admission.admitted) {
+                const ok = await dispatchGroup({
+                    filter,
+                    group,
+                    runId: runIdFactory(),
+                    ledger,
+                    schedule,
+                    cohorts,
+                    cohortId,
+                    limiter,
+                });
+                if (ok) {
+                    succeeded += 1;
+                }
+                else {
+                    failed += 1;
+                }
+            }
+        }
+        finally {
+            applyInFlightFilterIds.delete(filter.id);
+            // A throwing `onSettled` must not become the unhandled rejection either.
+            try {
+                params.onSettled?.({ cohortId, succeeded, failed });
+            }
+            catch {
+                // The notification is not the work. Losing it costs a test its wake-up;
+                // rethrowing it would cost the daemon its process.
+            }
+        }
+    })().catch(() => {
+        // Unreachable while `dispatchGroup` swallows its own failures, and kept as
+        // the backstop precisely because "unreachable" is a claim about today's code
+        // and this promise has no owner to reject to.
+    });
+    return { status: "dispatched", cohortId, collapse, report: admission.report };
+}
+//# sourceMappingURL=apply.js.map