@dynamicagents/plugins 0.13.0 → 0.15.0

package/dist/workspace/open.d.ts

@@ -1,95 +0,0 @@
-import type { WorkspaceClient, WorkspaceStub } from "@cloudflare/computer";
-import type { WorkspaceAdvisory } from "./advisory.js";
-/**
- * Reaching a workspace: which one a call names, and the two ways to open it.
- *
- * A leaf, so the object, `/computer`'s tools and its proxy in
- * `../computer/proxy.ts` can import it without
- * going through the barrel that re-exports them.
- */
-/**
- * Where a parent puts the workspace name so its sub-agents reach the same one.
- *
- * A sub-agent cannot compute this itself. The name is derived from the caller
- * and the repository, and the checkout it should work in is one its parent
- * chose — so a sub-agent that named its own would land beside the parent's
- * checkout, in a workspace with nothing in it.
- *
- * A spec's `prepare` runs on the parent, where the name resolves, and its
- * return value reaches the sub-agent's plugins as `runtime()`. That is the
- * channel core built for exactly this, and it is emphatically *not* the
- * sub-agent's input, which the parent's model writes — a workspace name there
- * would be model-authored, and a model naming another caller's workspace would
- * get that caller's files.
- */
-export declare const WORKSPACE_RUNTIME_KEY = "workspaceName";
-/**
- * Read a parent-resolved workspace name off a sub-agent's `runtime()`.
- *
- * Returns `undefined` rather than throwing on anything unexpected: a parent has
- * no runtime at all, and falling back to the configured thunk is right there.
- */
-export declare function workspaceNameFromRuntime(runtime: unknown): string | undefined;
-/**
- * The Durable Object the workspace lives in, as this plugin needs to see it.
- *
- * Structural rather than imported: the class is the host's — it owns the
- * container binding, the alarm and the install job — and a plugin that imported
- * it would stop a second host from bringing its own. `__getWorkspaceStub` is the
- * one method `getWorkspace()` calls across the boundary, and it is what
- * `withWorkspace` installs (or what a host that constructs `Workspace` itself
- * reimplements, which is the same three lines).
- */
-export interface WorkspaceHost extends Rpc.DurableObjectBranded {
-    __getWorkspaceStub(): Promise<WorkspaceStub>;
-    /**
-     * The same workspace for filesystem-only work, which the host must serve
-     * **without starting a container**.
-     *
-     * The filesystem is the Durable Object's own SQLite, while the first command
-     * in a fresh container waits for the whole tree to be pushed into it — so a
-     * file tool served the other way waits minutes for a local `readdir`. See
-     * `WorkspaceObjectBase.__getWorkspaceFsStub` in `./object.ts`.
-     *
-     * Required rather than optional, for the reason {@link advisories} gives. A
-     * host with nothing to distinguish returns its own `__getWorkspaceStub()`.
-     */
-    __getWorkspaceFsStub(): Promise<WorkspaceStub>;
-    /**
-     * Everything currently true about the workspace that a caller must not assume
-     * away — see {@link file://./advisory.ts}. An empty array is the good case.
-     *
-     * Required rather than optional, and not only because Workers RPC types an
-     * optional method as a union nothing can call. A host with nothing to report
-     * returns `[]` in one line; a host that forgot to expose it gets a compile
-     * error instead of a `bash` that silently runs against a half-built
-     * `node_modules`, or against a workspace whose writes are being dropped.
-     *
-     * `deriveAdvisories` builds the array from what the host already knows, so
-     * implementing this is gathering what the host has rather than writing policy.
-     */
-    advisories(): Promise<readonly WorkspaceAdvisory[]>;
-}
-/**
- * Open the workspace behind a Durable Object stub.
- *
- * The cast is unavoidable, and narrow enough to be worth isolating here rather
- * than repeating. `getWorkspace` wants a handle whose `__getWorkspaceStub()`
- * resolves to a `WorkspaceStub` — the concrete class, private fields and all.
- * Across a Durable Object boundary Workers RPC hands back a structural
- * `Stub<WorkspaceStub>`, which forwards every method faithfully but carries none
- * of the class's private brand: runtime-compatible, type-incompatible. This is
- * the only place in the plugin that gap is crossed.
- */
-export declare function openWorkspace(host: DurableObjectStub<WorkspaceHost>): Promise<WorkspaceClient>;
-/**
- * The same workspace, opened for filesystem work alone.
- *
- * `getWorkspace` calls exactly one method on what it is handed, so the host is
- * wrapped in an object answering it from the other side of the seam — see
- * {@link WorkspaceHost.__getWorkspaceFsStub}. Everything past that is identical.
- *
- * **Only the file tools take this.** `bash` and `workspaceExec` need the
- * container started and its CA installed, so they open it the other way.
- */
-export declare function openWorkspaceFs(host: DurableObjectStub<WorkspaceHost>): Promise<WorkspaceClient>;

package/dist/workspace/open.js

@@ -1,63 +0,0 @@
-import { getWorkspace } from "@cloudflare/computer";
-/**
- * Reaching a workspace: which one a call names, and the two ways to open it.
- *
- * A leaf, so the object, `/computer`'s tools and its proxy in
- * `../computer/proxy.ts` can import it without
- * going through the barrel that re-exports them.
- */
-/**
- * Where a parent puts the workspace name so its sub-agents reach the same one.
- *
- * A sub-agent cannot compute this itself. The name is derived from the caller
- * and the repository, and the checkout it should work in is one its parent
- * chose — so a sub-agent that named its own would land beside the parent's
- * checkout, in a workspace with nothing in it.
- *
- * A spec's `prepare` runs on the parent, where the name resolves, and its
- * return value reaches the sub-agent's plugins as `runtime()`. That is the
- * channel core built for exactly this, and it is emphatically *not* the
- * sub-agent's input, which the parent's model writes — a workspace name there
- * would be model-authored, and a model naming another caller's workspace would
- * get that caller's files.
- */
-export const WORKSPACE_RUNTIME_KEY = "workspaceName";
-/**
- * Read a parent-resolved workspace name off a sub-agent's `runtime()`.
- *
- * Returns `undefined` rather than throwing on anything unexpected: a parent has
- * no runtime at all, and falling back to the configured thunk is right there.
- */
-export function workspaceNameFromRuntime(runtime) {
-    const value = runtime?.[WORKSPACE_RUNTIME_KEY];
-    return typeof value === "string" && value.length > 0 ? value : undefined;
-}
-/**
- * Open the workspace behind a Durable Object stub.
- *
- * The cast is unavoidable, and narrow enough to be worth isolating here rather
- * than repeating. `getWorkspace` wants a handle whose `__getWorkspaceStub()`
- * resolves to a `WorkspaceStub` — the concrete class, private fields and all.
- * Across a Durable Object boundary Workers RPC hands back a structural
- * `Stub<WorkspaceStub>`, which forwards every method faithfully but carries none
- * of the class's private brand: runtime-compatible, type-incompatible. This is
- * the only place in the plugin that gap is crossed.
- */
-export function openWorkspace(host) {
-    return getWorkspace(host);
-}
-/**
- * The same workspace, opened for filesystem work alone.
- *
- * `getWorkspace` calls exactly one method on what it is handed, so the host is
- * wrapped in an object answering it from the other side of the seam — see
- * {@link WorkspaceHost.__getWorkspaceFsStub}. Everything past that is identical.
- *
- * **Only the file tools take this.** `bash` and `workspaceExec` need the
- * container started and its CA installed, so they open it the other way.
- */
-export function openWorkspaceFs(host) {
-    return getWorkspace({
-        __getWorkspaceStub: () => host.__getWorkspaceFsStub()
-    });
-}

package/dist/workspace/read.d.ts

@@ -1,16 +0,0 @@
-import type { WorkspaceClient } from "@cloudflare/computer";
-/**
- * Does this path exist?
- *
- * `getWorkspace()` types `fs` as the in-process `WorkspaceFilesystem`, but the
- * value on the far side of a Durable Object boundary is a
- * `WorkspaceFilesystemStub`, which carries a few methods the local class does
- * not — `exists` among them. So the fast path is asked for rather than cast to,
- * and `stat` is the fallback for a host that hands back a local workspace.
- *
- * The fallback treats *any* `stat` failure as absence, which is the honest
- * reading for a tool whose entire answer is a boolean: there is no error channel
- * to distinguish "missing" from "unreadable", and the caller's next move — look
- * somewhere else — is the same either way.
- */
-export declare function pathExists(fs: WorkspaceClient["fs"], path: string): Promise<boolean>;

package/dist/workspace/read.js

@@ -1,22 +0,0 @@
-/**
- * Does this path exist?
- *
- * `getWorkspace()` types `fs` as the in-process `WorkspaceFilesystem`, but the
- * value on the far side of a Durable Object boundary is a
- * `WorkspaceFilesystemStub`, which carries a few methods the local class does
- * not — `exists` among them. So the fast path is asked for rather than cast to,
- * and `stat` is the fallback for a host that hands back a local workspace.
- *
- * The fallback treats *any* `stat` failure as absence, which is the honest
- * reading for a tool whose entire answer is a boolean: there is no error channel
- * to distinguish "missing" from "unreadable", and the caller's next move — look
- * somewhere else — is the same either way.
- */
-export async function pathExists(fs, path) {
-    // Called as a method, never through `.call`: on an RPC stub `.call` is read as
-    // a remote method, and the stub it would pass as `this` cannot be serialised.
-    const remote = fs;
-    if (typeof remote.exists === "function")
-        return remote.exists(path);
-    return fs.stat(path).then(() => true, () => false);
-}

package/dist/workspace/shell.d.ts

@@ -1,45 +0,0 @@
-/**
- * Run a command under {@link file://./exec.ts WorkspaceClientConfig.shell} with its
- * two output streams left as they are, or hand it back untouched when no shell
- * is configured.
- *
- * This is the variant for a caller that **reads the result in code**: `stdout` is
- * a data channel it compares or parses, and `stderr` is a separate diagnostic.
- * {@link file://./exec.ts workspaceExec} is that caller, on behalf of
- * `@dynamicagents/plugins/repo`, which asks git questions like
- * `symbolic-ref --short refs/remotes/origin/HEAD` and `rev-list --count` and
- * needs the answer alone.
- *
- * Two functions rather than one with a flag, because the difference is a change
- * to the *output contract* and a boolean hides it at the call site. Merging the
- * streams here would give every `/repo` git command an empty `stderr` and a
- * `stdout` that is a transcript rather than an answer — which fails silently,
- * since the commands `/repo` parses are quiet ones and a single `warning:` is
- * enough to skip the empty-branch guard.
- */
-export declare function withShell(command: string, shell: string | undefined): string;
-/**
- * Run a command under {@link file://./exec.ts WorkspaceClientConfig.shell} with its
- * two output streams merged into one transcript, in the order they were
- * written.
- *
- * This is the variant for a caller whose consumer is **a model reading output**.
- * `bash` is that caller. A project's check is a chain — `wrangler types &&
- * prettier && eslint && tsc` — and *which tool spoke last* is how you know which
- * one failed. A stdout block and a separate stderr block destroy that ordering,
- * and a model that wants it back re-runs the whole gate as
- * `npm run check > /tmp/out 2>&1; cat /tmp/out`. This is that workaround, done
- * once, for free.
- *
- * The redirect binds to the wrapper process, so it applies to everything the
- * command writes however deeply nested — and there is no inner brace group or
- * subshell to mis-parse a command that already contains `&&`, quotes or redirects
- * of its own.
- *
- * With no shell configured there is no wrapper process to redirect, so the
- * command goes to the runtime untouched and the two streams arrive separate.
- * That is not a gap: {@link file://../computer/render.ts renderResult} renders them as a
- * labelled `--- stderr ---` block for exactly this case. The transcript is the
- * better answer, not the only supported one.
- */
-export declare function withShellTranscript(command: string, shell: string | undefined): string;

package/dist/workspace/shell.js

@@ -1,80 +0,0 @@
-import { shellQuote } from "@cloudflare/computer";
-/** How a command reaches the shell, and what its two output streams do there. */
-/**
- * The shell wrapper both variants share, minus the choice they differ on.
- *
- * One quoted argument, not string concatenation: the command is model-authored
- * and routinely contains quotes of its own (`git commit -m "…"`), so anything
- * less than `shellQuote` re-parses the model's quoting and mangles it.
- *
- * ## Why `-o pipefail`
- *
- * Without it a pipeline's exit status is its **last** stage's, so
- * `npm run check | tail -100` reports `exit 0` for a gate that failed outright —
- * and models pipe into `tail` constantly. A tool that reports success for a
- * failed build is worse than one that reports nothing. It also costs a re-run
- * every time: a model that cannot trust a piped exit code runs the whole thing
- * again unpiped to get one.
- *
- * The trade is worth stating. `pipefail` surfaces SIGPIPE too, so
- * `ls big-dir | head -1` reports 141 rather than 0 — noisy, but *visible*, where
- * the alternative is a failing gate that looks clean. The tool description tells
- * the model not to pipe into `head`/`tail` at all, since output is already
- * truncated with both ends kept.
- *
- * Requires a shell that implements it — `bash`, `zsh`, `ksh`, not `sh`/dash. A
- * host setting {@link file://./exec.ts WorkspaceClientConfig.shell} is choosing that
- * shell explicitly.
- */
-function wrapped(command, shell) {
-    return `${shell} -o pipefail -c ${shellQuote(command)}`;
-}
-/**
- * Run a command under {@link file://./exec.ts WorkspaceClientConfig.shell} with its
- * two output streams left as they are, or hand it back untouched when no shell
- * is configured.
- *
- * This is the variant for a caller that **reads the result in code**: `stdout` is
- * a data channel it compares or parses, and `stderr` is a separate diagnostic.
- * {@link file://./exec.ts workspaceExec} is that caller, on behalf of
- * `@dynamicagents/plugins/repo`, which asks git questions like
- * `symbolic-ref --short refs/remotes/origin/HEAD` and `rev-list --count` and
- * needs the answer alone.
- *
- * Two functions rather than one with a flag, because the difference is a change
- * to the *output contract* and a boolean hides it at the call site. Merging the
- * streams here would give every `/repo` git command an empty `stderr` and a
- * `stdout` that is a transcript rather than an answer — which fails silently,
- * since the commands `/repo` parses are quiet ones and a single `warning:` is
- * enough to skip the empty-branch guard.
- */
-export function withShell(command, shell) {
-    return shell ? wrapped(command, shell) : command;
-}
-/**
- * Run a command under {@link file://./exec.ts WorkspaceClientConfig.shell} with its
- * two output streams merged into one transcript, in the order they were
- * written.
- *
- * This is the variant for a caller whose consumer is **a model reading output**.
- * `bash` is that caller. A project's check is a chain — `wrangler types &&
- * prettier && eslint && tsc` — and *which tool spoke last* is how you know which
- * one failed. A stdout block and a separate stderr block destroy that ordering,
- * and a model that wants it back re-runs the whole gate as
- * `npm run check > /tmp/out 2>&1; cat /tmp/out`. This is that workaround, done
- * once, for free.
- *
- * The redirect binds to the wrapper process, so it applies to everything the
- * command writes however deeply nested — and there is no inner brace group or
- * subshell to mis-parse a command that already contains `&&`, quotes or redirects
- * of its own.
- *
- * With no shell configured there is no wrapper process to redirect, so the
- * command goes to the runtime untouched and the two streams arrive separate.
- * That is not a gap: {@link file://../computer/render.ts renderResult} renders them as a
- * labelled `--- stderr ---` block for exactly this case. The transcript is the
- * better answer, not the only supported one.
- */
-export function withShellTranscript(command, shell) {
-    return shell ? `${wrapped(command, shell)} 2>&1` : command;
-}

package/dist/workspace/sync.d.ts

@@ -1,111 +0,0 @@
-import type { Workspace } from "@cloudflare/computer";
-import type { Deadline } from "@dynamicagents/core/alarm";
-/**
- * The host's half of syncing: moving what the container wrote into the object.
- *
- * ## Why the host has a half at all
- *
- * Every command is bracketed by a sync — a push before it runs, a pull after it
- * exits — and the pull is what carries its writes back into this object's
- * SQLite. That pull can fail while the command itself succeeds: a transport that
- * dropped, a container replaced underneath it. The library reports that on the
- * command's result and schedules nothing of its own afterwards. What it does
- * keep is the cursor, so a later `pull()` resumes the same operation rather than
- * starting one.
- *
- * That later `pull()` is this. Without it the workspace silently lags the
- * container: the file tools read a tree missing the last command's work, and git
- * — which runs on this side — would commit and push it that way.
- */
-/**
- * How long one drain spends moving blocks before it comes back.
- *
- * The alarm is shared. Every other reason a workspace wakes is queued behind
- * whatever the alarm is doing, so a drain that ran to completion in one
- * invocation would hold the object for as long as the pull takes. A minute
- * finishes an ordinary pull outright and keeps a large one from starving the
- * install watchdog.
- */
-export declare const SYNC_DRAIN_BUDGET_MS = 60000;
-/** How soon a drain that is making progress comes back for the next block. */
-export declare const SYNC_DRAIN_RESUME_MS = 1000;
-/**
- * The ceiling on the wait after a pull that failed.
- *
- * A failure is not a slow success: whatever broke — a container that stopped
- * answering, a transport that will not open — is usually still broken a second
- * later, and coming back at the resume interval would be an alarm and an error
- * line every second for as long as the workspace stays up. Backing off turns
- * that into a handful of attempts an hour, which is the rate a recoverable
- * fault actually clears at.
- *
- * Bounded rather than abandoned, because the cursor is durable and the cost of
- * one more attempt is one round trip: a container that comes back should be
- * drained without anyone asking.
- */
-export declare const SYNC_DRAIN_MAX_BACKOFF_MS: number;
-/** How long to wait before a retry, after this many consecutive failures. */
-export declare function syncRetryDelayMs(attempt: number): number;
-/**
- * What one drain achieved.
- *
- * `incomplete` and `failed` are separated because they want opposite responses.
- * `incomplete` is a healthy drain that ran out of budget with the cursor moved,
- * and the right answer is to come straight back. `failed` is a pull that threw
- * with nothing to show for it, and coming straight back would spin against
- * whatever is broken — see {@link syncRetryDelayMs}.
- *
- * `unavailable` is not a failure either: it is the answer when there is no
- * container to pull from, which also means there is nothing outstanding that
- * could still be recovered. Kept distinct from `complete` so a caller deciding
- * whether to act on the workspace — a git push, say — can tell "nothing to move"
- * from "nothing reachable".
- */
-export type DrainOutcome = "complete" | "incomplete" | "failed" | "unavailable";
-/**
- * What a schedule waiting on a pull carries: how many times it has failed in a
- * row. Both the drain's own deadline and the container-idle deferral that waits
- * for one hold it, since both have to back off against the same fault.
- */
-export interface SyncDrainIntent {
-    attempt: number;
-}
-export interface WorkspaceSyncDeps {
-    workspace: () => Workspace;
-    /** Whether a container is up. A drain must never start one — see {@link drain}. */
-    containerRunning: () => boolean;
-    /** Where the next block is scheduled. */
-    deadline: () => Deadline<SyncDrainIntent | undefined>;
-    tag: () => string;
-    id: () => string;
-}
-export declare class WorkspaceSync {
-    private readonly deps;
-    constructor(deps: WorkspaceSyncDeps);
-    /**
-     * Come back shortly and move what is still outstanding.
-     *
-     * A deadline rather than an immediate drain, because the caller is usually
-     * holding something that should not wait on a pull — an install's drain, or a
-     * request. `set` replaces whatever stood before, so arming twice is one
-     * schedule rather than two.
-     */
-    arm(attempt?: number): Promise<void>;
-    /**
-     * Move what the container has written into this object's storage.
-     *
-     * One block per `next()`, under a budget rather than to completion, because
-     * the iterator is disposable by design: the durable state is the cursor the
-     * block just committed, so stopping is a normal thing to do and a recreated
-     * iterable picks up where this one stopped.
-     *
-     * **Never starts a container.** Opening a backend handle would launch one, and
-     * a pull against a replacement finds an empty filesystem rather than the
-     * writes it was after — the library fences that to the runtime that ran the
-     * command, but launching a container to discover so is pure cost. A stopped
-     * container also means there is nothing left to pull: whatever it held that
-     * never arrived is gone, which is why a drain runs *before* an idle deadline
-     * stops one.
-     */
-    drain(budgetMs: number): Promise<DrainOutcome>;
-}

package/dist/workspace/sync.js

@@ -1,124 +0,0 @@
-/**
- * The host's half of syncing: moving what the container wrote into the object.
- *
- * ## Why the host has a half at all
- *
- * Every command is bracketed by a sync — a push before it runs, a pull after it
- * exits — and the pull is what carries its writes back into this object's
- * SQLite. That pull can fail while the command itself succeeds: a transport that
- * dropped, a container replaced underneath it. The library reports that on the
- * command's result and schedules nothing of its own afterwards. What it does
- * keep is the cursor, so a later `pull()` resumes the same operation rather than
- * starting one.
- *
- * That later `pull()` is this. Without it the workspace silently lags the
- * container: the file tools read a tree missing the last command's work, and git
- * — which runs on this side — would commit and push it that way.
- */
-/**
- * How long one drain spends moving blocks before it comes back.
- *
- * The alarm is shared. Every other reason a workspace wakes is queued behind
- * whatever the alarm is doing, so a drain that ran to completion in one
- * invocation would hold the object for as long as the pull takes. A minute
- * finishes an ordinary pull outright and keeps a large one from starving the
- * install watchdog.
- */
-export const SYNC_DRAIN_BUDGET_MS = 60_000;
-/** How soon a drain that is making progress comes back for the next block. */
-export const SYNC_DRAIN_RESUME_MS = 1_000;
-/**
- * The ceiling on the wait after a pull that failed.
- *
- * A failure is not a slow success: whatever broke — a container that stopped
- * answering, a transport that will not open — is usually still broken a second
- * later, and coming back at the resume interval would be an alarm and an error
- * line every second for as long as the workspace stays up. Backing off turns
- * that into a handful of attempts an hour, which is the rate a recoverable
- * fault actually clears at.
- *
- * Bounded rather than abandoned, because the cursor is durable and the cost of
- * one more attempt is one round trip: a container that comes back should be
- * drained without anyone asking.
- */
-export const SYNC_DRAIN_MAX_BACKOFF_MS = 5 * 60_000;
-/** How long to wait before a retry, after this many consecutive failures. */
-export function syncRetryDelayMs(attempt) {
-    return Math.min(SYNC_DRAIN_RESUME_MS * 2 ** Math.max(0, attempt), SYNC_DRAIN_MAX_BACKOFF_MS);
-}
-export class WorkspaceSync {
-    deps;
-    constructor(deps) {
-        this.deps = deps;
-    }
-    /**
-     * Come back shortly and move what is still outstanding.
-     *
-     * A deadline rather than an immediate drain, because the caller is usually
-     * holding something that should not wait on a pull — an install's drain, or a
-     * request. `set` replaces whatever stood before, so arming twice is one
-     * schedule rather than two.
-     */
-    async arm(attempt = 0) {
-        await this.deps
-            .deadline()
-            .set(new Date(Date.now() + syncRetryDelayMs(attempt)), { attempt });
-    }
-    /**
-     * Move what the container has written into this object's storage.
-     *
-     * One block per `next()`, under a budget rather than to completion, because
-     * the iterator is disposable by design: the durable state is the cursor the
-     * block just committed, so stopping is a normal thing to do and a recreated
-     * iterable picks up where this one stopped.
-     *
-     * **Never starts a container.** Opening a backend handle would launch one, and
-     * a pull against a replacement finds an empty filesystem rather than the
-     * writes it was after — the library fences that to the runtime that ran the
-     * command, but launching a container to discover so is pure cost. A stopped
-     * container also means there is nothing left to pull: whatever it held that
-     * never arrived is gone, which is why a drain runs *before* an idle deadline
-     * stops one.
-     */
-    async drain(budgetMs) {
-        if (!this.deps.containerRunning())
-            return "unavailable";
-        const stopAt = Date.now() + budgetMs;
-        let blocks = 0;
-        let entries = 0;
-        try {
-            for await (const progress of this.deps.workspace().pull()) {
-                blocks += 1;
-                entries += progress.entries;
-                if (progress.complete) {
-                    // Silent for the ordinary case — one empty block, which is what a
-                    // workspace with nothing outstanding returns on every check.
-                    if (blocks > 1 || entries > 0) {
-                        console.info(`[${this.deps.tag()}] pull drained`, {
-                            id: this.deps.id(),
-                            blocks,
-                            entries
-                        });
-                    }
-                    return "complete";
-                }
-                if (Date.now() >= stopAt)
-                    return "incomplete";
-            }
-            // The iterable ended without a block claiming completion, which is what a
-            // backend with nothing to sync returns. Nothing is outstanding either way.
-            return "complete";
-        }
-        catch (err) {
-            // Left outstanding rather than retried here: the cursor is durable, so the
-            // next drain resumes whatever this one committed before it threw.
-            console.error(`[${this.deps.tag()}] a pull could not be drained`, {
-                id: this.deps.id(),
-                blocks,
-                entries,
-                err: String(err)
-            });
-            return "failed";
-        }
-    }
-}

package/dist/workspace/wake.d.ts

@@ -1,19 +0,0 @@
-/**
- * What a workspace object wakes for, as one map.
- *
- * Its own module because the object that registers these callbacks and the
- * `JobLifecycle` in `./install-job.ts` that schedules some of them by name both type
- * against it, and neither should own it. A name that exists in one and not the
- * other is then a compile error rather than a schedule that is rejected at
- * runtime.
- */
-import type { SyncDrainIntent } from "./sync.js";
-export type WorkspaceWakeHandlers = {
-    installRun: () => Promise<void>;
-    installWatch: () => Promise<void>;
-    idleReclaim: () => Promise<void>;
-    /** Start a cold container before a command needs it — see `./object.ts`. */
-    containerWarm: () => Promise<void>;
-    containerIdle: (payload?: SyncDrainIntent) => Promise<void>;
-    syncRetry: (payload?: SyncDrainIntent) => Promise<void>;
-};

package/dist/workspace/wake.js

@@ -1,10 +0,0 @@
-/**
- * What a workspace object wakes for, as one map.
- *
- * Its own module because the object that registers these callbacks and the
- * `JobLifecycle` in `./install-job.ts` that schedules some of them by name both type
- * against it, and neither should own it. A name that exists in one and not the
- * other is then a compile error rather than a schedule that is rejected at
- * runtime.
- */
-export {};