@edspencer/paddock 0.70.1 → 0.71.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@edspencer/paddock",
-  "version": "0.70.1",
+  "version": "0.71.0",
   "description": "Project-first launchpad for Claude Code: server-hosted, persistent, resumable sessions organized by project.",
   "keywords": [
     "claude",
@@ -37,7 +37,7 @@
     "@fastify/swagger-ui": "4.2.0",
     "@fastify/websocket": "10.0.1",
     "@herdctl/chat": "0.8.0",
-    "@herdctl/core": "5.32.0",
+    "@herdctl/core": "5.33.0",
     "@modelcontextprotocol/sdk": "1.29.0",
     "fastify": "4.28.1",
     "jose": "6.2.3",

package/packages/server/dist/background-live.d.ts

@@ -78,6 +78,14 @@ export interface LiveBackgroundTask {
      * carried on the wire and filtered at the point of display.
      */
     skipTranscript?: boolean;
+    /**
+     * Can this task be stopped (#848)? Derived from {@link type} alongside
+     * {@link role}, at the one boundary that owns SDK task-type knowledge — see
+     * {@link UNSTOPPABLE_TASK_TYPES}. Clients gate the stop affordance on this
+     * rather than re-deriving it, so the CLI's kill-strategy table has exactly
+     * one representation in the codebase.
+     */
+    stoppable: boolean;
 }
 export type BackgroundChangeListener = (projectSlug: string, sessionId: string, tasks: LiveBackgroundTask[]) => void;
 /**
@@ -107,6 +115,22 @@ export declare class BackgroundRegistry {
      * stream ends — see the per-process caveat in the module header.
      */
     clear(sessionId: string): void;
+    /**
+     * Drop one task the way a terminal edge would, on the word of an out-of-band
+     * authority rather than the session's own stream (#848).
+     *
+     * The single caller is the stop path, for the case where
+     * `stopTaskInSession` answers `false` — no live session with that id. There
+     * is then no stream left to deliver the `task_notification` this registry
+     * normally evicts on, so without this the row would sit at `stopping…`
+     * forever describing work that is definitively gone.
+     *
+     * Safe against being wrong for the same reason {@link evict} is: the level
+     * signal remains the sole authority on membership, so a task dropped here
+     * that is somehow still running is simply put back by the next
+     * `background_tasks_changed`.
+     */
+    dropTask(sessionId: string, taskId: string): boolean;
     /**
      * Feed one raw SDK message. Returns true when the live set changed, so the
      * caller can avoid re-broadcasting on the overwhelming majority of messages

package/packages/server/dist/background-live.js

@@ -75,6 +75,25 @@ const TASK_ROLES = {
 export function roleForTaskType(type) {
     return TASK_ROLES[type] ?? type;
 }
+/**
+ * Task types the CLI has no kill strategy for, so `stopTask` on one REJECTS
+ * with `unsupported_type` rather than being swallowed (#848).
+ *
+ * Keyed on the RAW discriminant, and {@link TASK_ROLES} directly above is the
+ * proof that it has to be: that map sends BOTH `monitor_mcp` and `monitor_ws`
+ * to the same `monitor` role, and only the MCP flavour is unkillable. A
+ * consumer holding the derived `role` therefore cannot tell the stoppable one
+ * from the unstoppable one — so the answer is resolved here, next to the map
+ * that erases the distinction, and carried on the wire as `stoppable`.
+ *
+ * A DENYLIST, not an allowlist, and deliberately so: a task type the SDK adds
+ * after this was written gets a stop button, and if the CLI turns out not to
+ * support it the rejection surfaces in the row as "can't stop". An allowlist
+ * would silently withhold the button from every new stoppable type instead,
+ * which is the worse failure — the whole point of the issue is that there was
+ * nothing to click.
+ */
+const UNSTOPPABLE_TASK_TYPES = new Set(["monitor_mcp"]);
 const str = (v) => (typeof v === "string" && v ? v : undefined);
 const num = (v) => (typeof v === "number" && Number.isFinite(v) ? v : undefined);
 /**
@@ -134,6 +153,24 @@ export class BackgroundRegistry {
         e.tasks.clear();
         this.emit(sessionId, e);
     }
+    /**
+     * Drop one task the way a terminal edge would, on the word of an out-of-band
+     * authority rather than the session's own stream (#848).
+     *
+     * The single caller is the stop path, for the case where
+     * `stopTaskInSession` answers `false` — no live session with that id. There
+     * is then no stream left to deliver the `task_notification` this registry
+     * normally evicts on, so without this the row would sit at `stopping…`
+     * forever describing work that is definitively gone.
+     *
+     * Safe against being wrong for the same reason {@link evict} is: the level
+     * signal remains the sole authority on membership, so a task dropped here
+     * that is somehow still running is simply put back by the next
+     * `background_tasks_changed`.
+     */
+    dropTask(sessionId, taskId) {
+        return this.evict(sessionId, taskId);
+    }
     /**
      * Feed one raw SDK message. Returns true when the live set changed, so the
      * caller can avoid re-broadcasting on the overwhelming majority of messages
@@ -205,6 +242,7 @@ export class BackgroundRegistry {
                 role: roleForTaskType(type),
                 description: str(rt.description) ?? existing?.description ?? "",
                 startedAt: existing?.startedAt ?? this.now(),
+                stoppable: !UNSTOPPABLE_TASK_TYPES.has(type),
             });
         }
         if (prev && sameSet(prev.tasks, next)) {

package/packages/server/dist/cli/args.d.ts

@@ -71,8 +71,16 @@ export type Command = {
  *   `paddock service install --port 7299` both work, and the flag grammar is
  *   the same one in every position.
  *
- * A verb is only a verb in first position: `paddock --port start` is still a
- * missing-value error, and `paddock start start` is still `unknown option`.
+ * A verb is only a verb in first position: `paddock --port start` is an error
+ * from `--port`, not a `start` invocation, and `paddock start start` is still
+ * `unknown option`.
+ *
+ * That first half used to claim a *missing-value* error, which was wrong (#823):
+ * `next()` only rejects `undefined`, so `start` was happily consumed as the port
+ * and became `NaN` in `config.ts`. It is now a **value** error — `--port needs a
+ * number between 1 and 65535` — which is the behaviour the claim was reaching
+ * for. Corrected rather than deleted because the grammar it documents is real
+ * and load-bearing; it was only the example's error that was misdescribed.
  */
 export declare function parseCommand(argv: string[]): Command;
 export declare function parseArgs(argv: string[]): CliOptions;
@@ -92,4 +100,4 @@ export declare function nodeVersionProblem(nodeVersion: string): string | undefi
  */
 export declare function explainListenError(err: unknown, host: string, port: string): string;
 export declare const USAGE = "paddock \u2014 run a Paddock instance locally\n\nUsage\n  npx @edspencer/paddock [options]        start the server (the default)\n  paddock start [options]                 the same thing, said out loud\n  paddock service <install|uninstall|status>\n                                          run it in the background from login\n                                          (`paddock service --help`)\n\nOptions\n  -p, --port <port>       HTTP/WS port (default 7233, or $PORT)\n      --host <host>       Bind address (default 127.0.0.1)\n  -d, --data-dir <path>   Projects + state (default ~/.paddock, or $PADDOCK_DATA_DIR)\n  -o, --open              Open the app in your browser once it is listening\n      --verbose           Show the server's own logs (quiet by default)\n  -v, --version           Print the Paddock version and exit\n  -h, --help              Show this help\n\nOpening your own directories\n  Where you run this from does not matter \u2014 the instance is decided by its data\n  dir alone. Directories are added inside the app, on the Discover screen: it\n  reads your Claude Code history, lists the directories you have worked in, and\n  links the ones you tick as projects. A new instance opens on it.\n\n  Importing a directory does not write into it. No .paddock/, no .chats/, no\n  .gitignore edits, no CLAUDE.md \u2014 the project record and the copied transcripts\n  both live in the data dir, and the project just points at the path. Your own\n  ~/.claude transcripts are copied, never moved or deleted, so your terminal\n  `claude` keeps working exactly as before.\n\nCredentials\n  Paddock drives Claude Code, so it needs Claude credentials \u2014 and if you\n  already use Claude Code on this machine, it uses the login you already have.\n  That is a macOS Keychain entry on a Mac, or your ~/.claude/.credentials.json\n  elsewhere (symlinked in, never copied). Reading a login writes nothing.\n\n  Otherwise: a CLAUDE_CODE_OAUTH_TOKEN or ANTHROPIC_API_KEY in the environment,\n  or a one-off `CLAUDE_CONFIG_DIR=<data-dir>/claude-home claude login`. With no\n  login at all anywhere, run `claude setup-token`. Paddock says at startup when\n  it can find none.\n\nSharing your Claude Code state\n  Apart from that login, Paddock writes nothing outside its data dir by\n  default: transcripts go to each project's .chats/, and your ~/.claude is read\n  for config only. Each thing it can share is one key in\n  <data-dir>/paddock.config.yaml:\n\n    claude:\n      transcripts: host   # own | host, default own\n      credentials: host   # own | host, default host\n      instructions: host  # own | host, default own\n      hooks: host         # own | host, default own\n      mcpServers: host    # own | host, default own\n\n  transcripts: host makes a chat and a `claude --resume` in the same directory\n  the same file, live in both directions; deleting such a chat in Paddock\n  releases it rather than removing it, because it is your history rather than\n  Paddock's copy. credentials: own is the opt-out from sharing the login above.\n\n  instructions: host loads your ~/.claude CLAUDE.md, agents/, commands/ and\n  plugins/. Off by default, which is a change: your curated CLAUDE.md does not\n  reach Paddock's agents unless you say so. Each project's own CLAUDE.md always\n  does.\n\n  hooks: host runs the shell commands your ~/.claude/settings.json binds to\n  tool use. Off by default \u2014 inheriting someone's hooks is not something to\n  discover after the fact. Its other keys (permissions, model, statusline)\n  apply either way: under hooks: own Paddock writes its own settings.json\n  carrying them with hooks dropped, regenerated at startup.\n\n  mcpServers: host attaches the MCP servers declared in your ~/.claude.json \u2014\n  the top-level ones, plus a project's own when its directory matches. To give\n  this instance a server your machine doesn't have, declare it instead in a\n  sibling mcpServers: block of the same file; use env:VAR_NAME anywhere a\n  string goes so tokens stay out of it. That keeps a token out of the file, not\n  out of `ps`: leave driveMode on its default (session) for a server holding\n  one, since batch passes the definition to claude as a command-line argument.\n\nYour data\n  Everything lives in one directory \u2014 ~/.paddock unless you pass --data-dir.\n  Projects, chat transcripts and settings all persist there between runs. Move\n  that directory to move your instance; delete it to start over. Nothing is\n  stored anywhere else.\n\nNotes\n  Binds loopback with authentication disabled, which is safe for a laptop. To\n  expose it on a network, set PADDOCK_AUTH_MODE first \u2014 Paddock refuses to bind\n  a routable interface wide open. See AUTH.md.\n\nDocs: https://github.com/edspencer/paddock";
-export declare const SERVICE_USAGE = "paddock service \u2014 keep Paddock running in the background\n\nUsage\n  paddock service install [options]   register it and start it now\n  paddock service uninstall           stop it and deregister it\n  paddock service status              is it registered, is it running, where are the logs\n\nOptions (install only \u2014 recorded in the generated unit)\n  -p, --port <port>       HTTP/WS port (default 7233)\n      --host <host>       Bind address (default 127.0.0.1)\n  -d, --data-dir <path>   Only if you want an instance SEPARATE from your\n                          terminal one. Omitted by default on purpose, so\n                          `paddock service` and a bare `paddock` are the same\n                          ~/.paddock instance reached two ways.\n      --verbose           Record the server's own logs, not just warnings\n\nAt login, not at boot\n  This registers a per-USER service \u2014 a launchd LaunchAgent on macOS, a\n  `systemd --user` unit on Linux \u2014 so it runs as you, with your own Claude\n  login. That is not incidental: on macOS your Claude login is a Keychain item\n  that only a logged-in user session can read. A boot-time system daemon has no\n  such session and could not use it.\n\n  So Paddock starts when you LOG IN, not when the machine boots. After a\n  restart that nobody logs into, Paddock is not running. That is the design, not\n  a fault.\n\n  On Linux, a user service is also stopped when you log out. To keep it up:\n\n    loginctl enable-linger $USER\n\nWhere it lives\n  macOS   ~/Library/LaunchAgents/net.edspencer.paddock.plist\n          logs in <data-dir>/service/\n  Linux   ~/.config/systemd/user/paddock.service\n          logs via  journalctl --user -u paddock -f\n\nInstalled from npx?\n  `service install` refuses. An npx cache path is hash-keyed and npm may prune\n  it, so the unit would work until it silently didn't, at some future login.\n  Install properly first:\n\n    npm i -g @edspencer/paddock && paddock service install\n\nA note on access\n  Paddock binds loopback with authentication off, which is right for a laptop.\n  A service is up for as long as you are logged in rather than as long as a\n  terminal tab, so that window is longer \u2014 but it is not wider: any local\n  process that could reach the port could already read the same Claude login as\n  you. Set PADDOCK_AUTH_MODE if you want a credential on it anyway.\n\nDocs: https://github.com/edspencer/paddock";
+export declare const SERVICE_USAGE = "paddock service \u2014 keep Paddock running in the background\n\nUsage\n  paddock service install [options]   register it and start it now\n  paddock service uninstall           stop it and deregister it\n  paddock service status              is it registered, is it running, where are the logs\n\nOptions (install only \u2014 recorded in the generated unit)\n  -p, --port <port>       HTTP/WS port (default 7233)\n      --host <host>       Bind address (default 127.0.0.1)\n  -d, --data-dir <path>   Only if you want an instance SEPARATE from your\n                          terminal one. Left out of the unit when you omit it\n                          AND `PADDOCK_DATA_DIR` is unset in this shell, so\n                          `paddock service` and a bare `paddock` are the same\n                          ~/.paddock instance reached two ways. If\n                          `PADDOCK_DATA_DIR` IS set here, that path is recorded\n                          in the unit \u2014 the service would otherwise point\n                          somewhere your terminal does not.\n      --verbose           Record the server's own logs, not just warnings\n\nAt login, not at boot\n  This registers a per-USER service \u2014 a launchd LaunchAgent on macOS, a\n  `systemd --user` unit on Linux \u2014 so it runs as you, with your own Claude\n  login. That is not incidental: on macOS your Claude login is a Keychain item\n  that only a logged-in user session can read. A boot-time system daemon has no\n  such session and could not use it.\n\n  So Paddock starts when you LOG IN, not when the machine boots. After a\n  restart that nobody logs into, Paddock is not running. That is the design, not\n  a fault.\n\n  On Linux, a user service is also stopped when you log out. To keep it up:\n\n    loginctl enable-linger $USER\n\nWhere it lives\n  macOS   ~/Library/LaunchAgents/net.edspencer.paddock.plist\n          logs in <data-dir>/service/\n  Linux   ~/.config/systemd/user/paddock.service\n          logs via  journalctl --user -u paddock.service -f\n\nInstalled from npx?\n  `service install` refuses. An npx cache path is hash-keyed and npm may prune\n  it, so the unit would work until it silently didn't, at some future login.\n  Install properly first:\n\n    npm i -g @edspencer/paddock && paddock service install\n\nA note on access\n  Paddock binds loopback with authentication off, which is right for a laptop.\n  A service is up for as long as you are logged in rather than as long as a\n  terminal tab, so that window is longer \u2014 but it is not wider: any local\n  process that could reach the port could already read the same Claude login as\n  you. Set PADDOCK_AUTH_MODE if you want a credential on it anyway.\n\nDocs: https://github.com/edspencer/paddock";

package/packages/server/dist/cli/args.js

@@ -49,8 +49,16 @@ function isServiceAction(token) {
  *   `paddock service install --port 7299` both work, and the flag grammar is
  *   the same one in every position.
  *
- * A verb is only a verb in first position: `paddock --port start` is still a
- * missing-value error, and `paddock start start` is still `unknown option`.
+ * A verb is only a verb in first position: `paddock --port start` is an error
+ * from `--port`, not a `start` invocation, and `paddock start start` is still
+ * `unknown option`.
+ *
+ * That first half used to claim a *missing-value* error, which was wrong (#823):
+ * `next()` only rejects `undefined`, so `start` was happily consumed as the port
+ * and became `NaN` in `config.ts`. It is now a **value** error — `--port needs a
+ * number between 1 and 65535` — which is the behaviour the claim was reaching
+ * for. Corrected rather than deleted because the grammar it documents is real
+ * and load-bearing; it was only the example's error that was misdescribed.
  */
 export function parseCommand(argv) {
     const [first, ...rest] = argv;
@@ -96,9 +104,23 @@ export function parseArgs(argv) {
         };
         switch (arg) {
             case "-p":
-            case "--port":
-                opts.port = next();
+            case "--port": {
+                // Validate here rather than letting `Number("start")` become NaN three
+                // files later, in `config.ts`, with nothing between the typo and a
+                // server asked to listen on NaN (#823).
+                //
+                // Scoped to NON-EMPTY values on purpose. `paddock --port "$PORT"` with
+                // PORT unset passes `""`, which is falsy at the one place that reads it
+                // (`paddock.ts`: `if (opts.port)`) and so correctly falls through to the
+                // default — a working invocation that a bare `/^\d+$/` guard would turn
+                // into a hard error.
+                const v = next();
+                if (v !== "" && (!/^\d+$/.test(v) || Number(v) < 1 || Number(v) > 65535)) {
+                    throw new CliError(`${arg} needs a number between 1 and 65535, got: ${v}`);
+                }
+                opts.port = v;
                 break;
+            }
             case "--host":
                 opts.host = next();
                 break;
@@ -261,9 +283,13 @@ Options (install only — recorded in the generated unit)
   -p, --port <port>       HTTP/WS port (default 7233)
       --host <host>       Bind address (default 127.0.0.1)
   -d, --data-dir <path>   Only if you want an instance SEPARATE from your
-                          terminal one. Omitted by default on purpose, so
+                          terminal one. Left out of the unit when you omit it
+                          AND \`PADDOCK_DATA_DIR\` is unset in this shell, so
                           \`paddock service\` and a bare \`paddock\` are the same
-                          ~/.paddock instance reached two ways.
+                          ~/.paddock instance reached two ways. If
+                          \`PADDOCK_DATA_DIR\` IS set here, that path is recorded
+                          in the unit — the service would otherwise point
+                          somewhere your terminal does not.
       --verbose           Record the server's own logs, not just warnings
 
 At login, not at boot
@@ -285,7 +311,7 @@ Where it lives
   macOS   ~/Library/LaunchAgents/net.edspencer.paddock.plist
           logs in <data-dir>/service/
   Linux   ~/.config/systemd/user/paddock.service
-          logs via  journalctl --user -u paddock -f
+          logs via  journalctl --user -u paddock.service -f
 
 Installed from npx?
   \`service install\` refuses. An npx cache path is hash-keyed and npm may prune

package/packages/server/dist/cli/service/index.js

@@ -130,7 +130,18 @@ function status(opts, ctx, backend) {
     const dataDir = dataFromUnit >= 0 && state.argv[dataFromUnit + 1] !== undefined
         ? state.argv[dataFromUnit + 1]
         : defaultDataDir(ctx.homeDir);
-    const { spec } = specFor(opts, { ...ctx, envDataDir: dataDir });
+    // Drop `--data-dir` before building the log-path spec (#824). `resolveDataDir`
+    // gives `opts.dataDir` precedence over `ctx.envDataDir`, which is right for
+    // `install` (see the comment there) and wrong here: this whole block reports
+    // the INSTALLED unit, so letting today's flag through printed the unit's data
+    // dir beside a `Logs:` path under a directory the service never writes to. On
+    // macOS that log path is real and load-bearing, not just cosmetic.
+    //
+    // `--data-dir` is documented as install-only (SERVICE_USAGE), so ignoring it
+    // here matches both the help text and the stated intent of this block.
+    const statusOpts = { ...opts };
+    delete statusOpts.dataDir;
+    const { spec } = specFor(statusOpts, { ...ctx, envDataDir: dataDir });
     const linger = backend.lingerNote();
     console.log([
         "",

package/packages/server/dist/herdctl.d.ts

@@ -79,6 +79,26 @@ export interface ChatDeletion {
     /** The transcript was deliberately left on disk because it is not paddock's. */
     retained: boolean;
 }
+/**
+ * What happened to a request to stop one background task (#848).
+ *
+ * Three cases, kept apart on purpose — see
+ * {@link HerdctlService.stopBackgroundTask} for why only `error` is a failure.
+ */
+export type StopTaskOutcome = 
+/** Accepted. The SDK's own terminal notification is what removes the row. */
+{
+    outcome: "stopping";
+}
+/** No live session — the work died with it. The caller drops the row. */
+ | {
+    outcome: "gone";
+}
+/** The stop did not happen and the task is still running. */
+ | {
+    outcome: "error";
+    message: string;
+};
 /** Options passed through to a streamed trigger. */
 export interface ChatTurnOptions {
     prompt: string;
@@ -768,6 +788,35 @@ export declare class HerdctlService {
      * failure, so a broken Stop looked like a no-op).
      */
     cancel(jobId: string): Promise<boolean>;
+    /**
+     * Stop ONE background task, by session id and SDK task id (issue #848).
+     *
+     * Deliberately keyed on the SESSION, not on {@link liveSessions}. That map is
+     * emptied in a `finally` the moment the primary turn's result lands, while the
+     * background tasks it launched keep running — so a `liveSessions`-keyed stop
+     * would go inert during exactly the phase the running-work bar exists for.
+     * `stopTaskInSession` is herdctl's answer to that gap: the reaper holds the
+     * session across it.
+     *
+     * There is deliberately NO liveness pre-check. A reap landing between render
+     * and click is a routine race, and `false` already describes it precisely.
+     *
+     * The three outcomes are kept DISTINCT all the way to the UI, because they
+     * mean genuinely different things and only one of them is a failure:
+     *
+     *  - `stopping` — the request was accepted. Nothing is evicted here: the SDK
+     *    emits the terminal `task_notification{status:"stopped"}` on the session's
+     *    own stream and {@link BackgroundRegistry} already evicts on it. This is
+     *    also the idempotent case — the CLI answers `not_found` / `not_running`
+     *    with a success, so a click racing a natural completion lands here.
+     *  - `gone` — no live session with that id. NOT a failure: the tasks died with
+     *    the session, so the user's intent is already satisfied. The caller drops
+     *    the row itself, because there is no stream left to notify on.
+     *  - `error` — the stop did NOT happen and the task is still running. Notably
+     *    a `monitor_mcp` task, which the CLI has no kill strategy for and rejects
+     *    with `unsupported_type`. Surfaced rather than reported as success.
+     */
+    stopBackgroundTask(sessionId: string, taskId: string): Promise<StopTaskOutcome>;
     /**
      * End a managed chat SESSION outright, by session id (issue #731). Where
      * {@link cancel} ends the model turn — and on the session runtime deliberately

package/packages/server/dist/herdctl.js

@@ -1397,6 +1397,48 @@ export class HerdctlService {
             return false;
         }
     }
+    /**
+     * Stop ONE background task, by session id and SDK task id (issue #848).
+     *
+     * Deliberately keyed on the SESSION, not on {@link liveSessions}. That map is
+     * emptied in a `finally` the moment the primary turn's result lands, while the
+     * background tasks it launched keep running — so a `liveSessions`-keyed stop
+     * would go inert during exactly the phase the running-work bar exists for.
+     * `stopTaskInSession` is herdctl's answer to that gap: the reaper holds the
+     * session across it.
+     *
+     * There is deliberately NO liveness pre-check. A reap landing between render
+     * and click is a routine race, and `false` already describes it precisely.
+     *
+     * The three outcomes are kept DISTINCT all the way to the UI, because they
+     * mean genuinely different things and only one of them is a failure:
+     *
+     *  - `stopping` — the request was accepted. Nothing is evicted here: the SDK
+     *    emits the terminal `task_notification{status:"stopped"}` on the session's
+     *    own stream and {@link BackgroundRegistry} already evicts on it. This is
+     *    also the idempotent case — the CLI answers `not_found` / `not_running`
+     *    with a success, so a click racing a natural completion lands here.
+     *  - `gone` — no live session with that id. NOT a failure: the tasks died with
+     *    the session, so the user's intent is already satisfied. The caller drops
+     *    the row itself, because there is no stream left to notify on.
+     *  - `error` — the stop did NOT happen and the task is still running. Notably
+     *    a `monitor_mcp` task, which the CLI has no kill strategy for and rejects
+     *    with `unsupported_type`. Surfaced rather than reported as success.
+     */
+    async stopBackgroundTask(sessionId, taskId) {
+        const fleet = this.fleet;
+        if (!fleet)
+            return { outcome: "gone" };
+        try {
+            const stopped = await fleet.stopTaskInSession(sessionId, taskId);
+            return stopped ? { outcome: "stopping" } : { outcome: "gone" };
+        }
+        catch (err) {
+            const message = err instanceof Error ? err.message : String(err);
+            console.warn(`[herdctl] stopTaskInSession failed for ${sessionId}/${taskId}:`, err);
+            return { outcome: "error", message };
+        }
+    }
     /**
      * End a managed chat SESSION outright, by session id (issue #731). Where
      * {@link cancel} ends the model turn — and on the session runtime deliberately

package/packages/server/dist/routes/chats.js

@@ -1436,8 +1436,8 @@ export function registerChatWorkspaceRoutes(app, ctx) {
     app.get("/adoptable-chats", {
         schema: {
             tags: ["Chats"],
-            summary: "Count the native Claude Code chats this project could import",
-            description: "Returns the terminal `claude` sessions that could be imported into this project but are not yet visible in it: the project's own working directory, plus any Claude transcript folder whose recorded working directory matches the project (by checkout name for a repo-backed project, by exact path for a notebook project). Sidechains, already-imported sessions and sessions belonging to a real Paddock run are excluded by the engine; empty transcripts, slash-command-only transcripts and Paddock's own sweeper curation runs (`too-small` / `slash-command-only` / `sweeper-run`) are additionally withheld as noise and reported under `filtered`, so a count lower than the raw total always has an explanation. Response: `{ count, sources: [{ sourceCwd, sessionIds }], filtered: [{ sessionId, sourceCwd, reason }] }`. The count is LIVE — re-read it after an import rather than remembering a dismissal.",
+            summary: "Count the native Claude Code chats this project could adopt",
+            description: "Returns the terminal `claude` sessions that could be adopted into this project but are not yet visible in it: the project's own working directory, plus any Claude transcript folder whose recorded working directory matches the project (by checkout name when the project has a `repo:` key, by exact path otherwise). Sidechains, already-adopted sessions and sessions belonging to a real Paddock run are excluded by the engine; empty transcripts, slash-command-only transcripts and Paddock's own sweeper curation runs (`too-small` / `slash-command-only` / `sweeper-run`) are additionally withheld as noise and reported under `filtered`, so a count lower than the raw total always has an explanation. Response: `{ count, sources: [{ sourceCwd, sessionIds }], filtered: [{ sessionId, sourceCwd, reason }] }`. The count is LIVE — re-read it after an adoption rather than remembering a dismissal.",
             params: {
                 type: "object",
                 properties: {
@@ -1474,8 +1474,8 @@ export function registerChatWorkspaceRoutes(app, ctx) {
     app.post("/adopt-chats", {
         schema: {
             tags: ["Chats"],
-            summary: "Import native Claude Code chats into this project",
-            description: "Imports the terminal `claude` sessions reported by GET …/adoptable-chats. With no body (or no `sourceCwd`) every detected source is imported; with `sourceCwd` only that source is, and it must be one this project actually offers — an unrecognised path is a 400 rather than an invitation to scan arbitrary directories. `sessionIds` narrows the import to a chosen SUBSET of what is on offer (what the confirmation dialog sends); ids that are not on offer are simply not imported, and anything the engine adopts as a side effect of taking a whole source is released again. Transcripts are COPIED, never moved: the user's own `~/.claude` history is left intact and the copies keep their original mtimes, so imported chats sort by when they really happened. Afterwards the session, run-record and detection caches are dropped, so the chats appear on the very next list request with no restart. Response: `{ adopted, skipped }` — `skipped` carries the engine's reason per session (`sidechain`, `already-adopted`, `destination-exists`, `attributed-to-run`, `unreadable`, `placement-failed`, `record-failed`).",
+            summary: "Adopt native Claude Code chats into this project",
+            description: "Adopts the terminal `claude` sessions reported by GET …/adoptable-chats. With no body (or no `sourceCwd`) every detected source is adopted; with `sourceCwd` only that source is, and it must be one this project actually offers — an unrecognised path is a 400 rather than an invitation to scan arbitrary directories. `sessionIds` narrows the adoption to a chosen SUBSET of what is on offer (what the confirmation dialog sends); ids that are not on offer are simply not imported, and anything the engine adopts as a side effect of taking a whole source is released again. Transcripts are COPIED, never moved: the user's own `~/.claude` history is left intact and the copies keep their original mtimes, so imported chats sort by when they really happened. Afterwards the session, run-record and detection caches are dropped, so the chats appear on the very next list request with no restart. Response: `{ adopted, skipped }` — `skipped` carries the engine's reason per session (`sidechain`, `already-adopted`, `destination-exists`, `attributed-to-run`, `unreadable`, `placement-failed`, `record-failed`).",
             params: {
                 type: "object",
                 properties: {
@@ -1500,7 +1500,7 @@ export function registerChatWorkspaceRoutes(app, ctx) {
             },
             response: {
                 200: {
-                    description: "Object `{ adopted, skipped }` describing what was imported.",
+                    description: "Object `{ adopted, skipped }` describing what was adopted.",
                     type: "object",
                     additionalProperties: true,
                 },
@@ -1549,8 +1549,8 @@ export function registerChatWorkspaceRoutes(app, ctx) {
     app.post("/unadopt-chats", {
         schema: {
             tags: ["Chats"],
-            summary: "Undo the most recent native-chat import into this project",
-            description: "Reverses the import this server most recently performed into the workspace: each adoption is released and the copies that import placed are deleted, leaving the user's own `~/.claude` history untouched. `sessionIds` undoes part of that import; omit it to undo all of it. Deliberately scoped to the LAST import and remembered in memory — undo may delete files, so the paths it can touch come from what this process actually did rather than from the request body, and a restart forgets the offer rather than acting on a stale one. Response: `{ released }`, the session ids actually released; an empty array means there was nothing to undo (nothing imported, already undone, or the server restarted since).",
+            summary: "Undo the most recent native-chat adoption into this project",
+            description: "Reverses the adoption this server most recently performed into the workspace: each adoption is released and the copies that adoption placed are deleted, leaving the user's own `~/.claude` history untouched. `sessionIds` undoes part of that adoption; omit it to undo all of it. Deliberately scoped to the LAST adoption and remembered in memory — undo may delete files, so the paths it can touch come from what this process actually did rather than from the request body, and a restart forgets the offer rather than acting on a stale one. Response: `{ released }`, the session ids actually released; an empty array means there was nothing to undo (nothing imported, already undone, or the server restarted since).",
             params: {
                 type: "object",
                 properties: {

package/packages/server/dist/routes/discover.js

@@ -73,7 +73,7 @@ export function registerDiscoverRoutes(app, ctx) {
         schema: {
             tags: ["System"],
             summary: "Directories on this machine that could become projects",
-            description: "Scans `<claudeHome>/projects/*` for directories with existing Claude Code history and returns the ones worth importing, ranked by how many non-noise sessions each holds. Never walks the filesystem: the only directories it can name are ones a transcript already records, and each is put through the same path floor a linked project must clear (no system directories, no temp roots, nothing inside Paddock's own data dir, nothing overlapping an existing project). Two rules are relaxable: `includeNonGit=1` offers directories that are not git checkouts, `includeOutsideHome=1` offers directories outside `$HOME`. `excluded` reports how many folders each rule ate — a container whose Claude home is empty reports `scanned: 0`, which is what distinguishes 'no history' from 'all of it was filtered'. Response: `{ claudeHome, homeDir, scanned, candidates, excluded }`.",
+            description: "Scans `<claudeHome>/projects/*` for directories with existing Claude Code history and returns the ones worth importing, ranked by how many non-noise sessions each holds. Never walks the filesystem: the only directories it can name are ones a transcript already records, and each is put through the same path floor a linked project must clear (no system directories, no temp roots, nothing inside Paddock's own data dir, nothing overlapping an existing project). Two rules are relaxable: `includeNonGit=1` offers directories that are not git checkouts, `includeOutsideHome=1` offers directories outside `$HOME`. Note the two counts are in DIFFERENT units and do not reconcile by subtraction: `scanned` counts transcript FOLDERS, while `excluded` reports how many DIRECTORIES each rule ate — one directory routinely has two transcript folders (the user's own and Paddock's copy), so a rule that ate one directory may account for two scanned folders. The single exception is `no-recorded-cwd`, which is necessarily per-folder: a folder with no recorded cwd has no directory to be counted under. A container whose Claude home is empty reports `scanned: 0`, which is what distinguishes 'no history' from 'all of it was filtered'. Response: `{ claudeHome, homeDir, scanned, candidates, excluded }`.",
             querystring: {
                 type: "object",
                 properties: {

package/packages/server/dist/ws-protocol.d.ts

@@ -159,6 +159,59 @@ export interface ChatCancelMessage {
         jobId: string;
     };
 }
+/**
+ * Stop ONE piece of background work, leaving the session and everything else it
+ * is running alone (issue #848).
+ *
+ * The finer-grained sibling of `chat:cancel`: that ends the model turn (or, in
+ * the background phase, reaps the whole session), this ends a single background
+ * shell / sub-agent / monitor. Keyed on the SESSION id rather than a job or turn
+ * id because background work outlives the turn that started it — which is
+ * exactly the phase in which the running-work bar matters.
+ *
+ * `taskId` is the SDK's own `task_id`, carried to the client on
+ * `chat:background` as {@link LiveBackgroundTaskWire.id}.
+ *
+ * Answered by exactly one {@link ChatStopTaskResultMessage}, to the asking
+ * socket. It does NOT remove the row: the SDK emits its own terminal
+ * `task_notification`, which arrives as an ordinary `chat:background` update.
+ */
+export interface ChatStopTaskMessage {
+    type: "chat:stop_task";
+    payload: {
+        sessionId: string;
+        taskId: string;
+    };
+}
+/**
+ * The answer to one {@link ChatStopTaskMessage} — three outcomes, only one of
+ * which is a failure:
+ *
+ *  - `stopping` — accepted. The row stays, held at `stopping…`, until the SDK's
+ *    terminal notification evicts it. Also the idempotent case: a click that
+ *    raced a natural completion lands here.
+ *  - `gone` — no live session. NOT an error; the work died with the session, so
+ *    the intent is already satisfied. The server has already dropped the task
+ *    from the registry (nothing is left to notify), so a `chat:background`
+ *    update without it accompanies this.
+ *  - `error` — the stop did not happen and the task is STILL RUNNING. Notably a
+ *    `monitor_mcp` task, which the CLI cannot kill. `message` is for display.
+ *
+ * Unicast, not broadcast: it answers one socket's request, and a second viewer
+ * of the same chat should not be shown an error for a click it did not make.
+ * Both viewers still agree on the outcome, because the row's actual removal
+ * travels on the broadcast `chat:background` frame.
+ */
+export interface ChatStopTaskResultMessage {
+    type: "chat:stop_task_result";
+    payload: {
+        sessionId: string;
+        taskId: string;
+        outcome: "stopping" | "gone" | "error";
+        /** Present only on `error`. */
+        message?: string;
+    };
+}
 /**
  * Run a slash command (e.g. `/compact`) in the current chat.
  *
@@ -276,7 +329,7 @@ export interface ChatContinueMessage {
 export interface PingMessage {
     type: "ping";
 }
-export type ClientMessage = ChatSendMessage | ChatCommandMessage | ChatCancelMessage | ChatSubscribeMessage | ChatSetQueueMessage | ChatContinueMessage | PingMessage;
+export type ClientMessage = ChatSendMessage | ChatCommandMessage | ChatCancelMessage | ChatStopTaskMessage | ChatSubscribeMessage | ChatSetQueueMessage | ChatContinueMessage | PingMessage;
 export interface Routing {
     projectSlug: string;
     sessionId: string | null;
@@ -584,6 +637,29 @@ export interface LiveBackgroundTaskWire {
     lastToolName?: string;
     toolUses?: number;
     skipTranscript?: boolean;
+    /**
+     * May this task be stopped via `chat:stop_task` (#848)? Resolved on the
+     * server from the raw {@link type}, and sent rather than left to the client
+     * for two reasons — note that neither is "the client could not tell", since
+     * #846 does carry the raw discriminant here:
+     *
+     *  1. It is a fact about the RUNTIME'S capability, not about rendering. The
+     *     server owns which task types the CLI has a kill strategy for; a second
+     *     copy of that denylist in the client is a second place to forget when
+     *     the SDK gains one.
+     *  2. #846 made {@link role} the thing clients render and {@link type} a
+     *     diagnostic. Having the client branch on `type` for this one decision
+     *     would re-couple its rendering to the discriminant #846 just abstracted
+     *     away — and `role` alone genuinely is not enough, because `monitor_ws`
+     *     and `monitor_mcp` share the `monitor` role and only one is killable.
+     *
+     * REQUIRED on the wire, like {@link role}: the server always resolves it, and
+     * leaving it optional here would let a future producer omit it and still
+     * typecheck — at which point clients read absent as "stoppable" and hand a
+     * `monitor_mcp` row a button that can only ever fail. The tolerance for an
+     * older server belongs on the CLIENT's copy of this type, and lives there.
+     */
+    stoppable: boolean;
 }
 /**
  * A session's live background work (#604) — the tasks still running after the
@@ -626,6 +702,6 @@ export interface ChatNoticeMessage {
 export interface PongMessage {
     type: "pong";
 }
-export type ServerMessage = ChatResponseMessage | ChatToolCallMessage | ChatToolStartMessage | ChatMessageBoundaryMessage | ChatCompleteMessage | ChatErrorMessage | ChatResyncMessage | ChatActiveMessage | ChatQueuedFlushedMessage | ChatQueuedStateMessage | ChatQueuedReturnedMessage | ChatKilledTaskMessage | ChatBackgroundMessage | ChatNoticeMessage | PongMessage;
+export type ServerMessage = ChatResponseMessage | ChatToolCallMessage | ChatToolStartMessage | ChatMessageBoundaryMessage | ChatCompleteMessage | ChatErrorMessage | ChatResyncMessage | ChatActiveMessage | ChatQueuedFlushedMessage | ChatQueuedStateMessage | ChatQueuedReturnedMessage | ChatKilledTaskMessage | ChatBackgroundMessage | ChatStopTaskResultMessage | ChatNoticeMessage | PongMessage;
 export declare function isClientMessage(data: unknown): data is ClientMessage;
 export {};

package/packages/server/dist/ws-protocol.js

@@ -198,6 +198,15 @@ export function isClientMessage(data) {
         const p = m.payload;
         return !!p && typeof p.jobId === "string";
     }
+    if (m.type === "chat:stop_task") {
+        const p = m.payload;
+        // Both ids must be non-empty: an empty session id would reach the fleet as a
+        // lookup miss and report `gone`, quietly telling the user work that is still
+        // running has stopped.
+        if (!p || typeof p.sessionId !== "string" || p.sessionId.length === 0)
+            return false;
+        return typeof p.taskId === "string" && p.taskId.length > 0;
+    }
     if (m.type === "chat:send") {
         const p = m.payload;
         if (!p || typeof p.message !== "string")

package/packages/server/dist/ws.js

@@ -1500,6 +1500,44 @@ export function makeChatHandler(deps) {
                 void deps.herdctl.cancel(parsed.payload.jobId).catch(() => undefined);
                 return;
             }
+            if (parsed.type === "chat:stop_task") {
+                // Stop ONE background task (#848). Unlike `chat:cancel` there is no turn
+                // to note and no queue to hand back — this leaves the session, and every
+                // other task in it, running. The row is NOT removed here: on `stopping`
+                // the SDK's own terminal notification does it, which is what keeps the
+                // bar honest if the kill turns out not to land.
+                const { sessionId, taskId } = parsed.payload;
+                void deps.herdctl.stopBackgroundTask(sessionId, taskId).then((res) => {
+                    // `gone` means no live session, so nothing will ever notify for this
+                    // task — drop it here or the row is stranded at `stopping…` forever.
+                    // The level signal stays the authority and puts it back if wrong.
+                    if (res.outcome === "gone")
+                        background.dropTask(sessionId, taskId);
+                    send({
+                        type: "chat:stop_task_result",
+                        payload: {
+                            sessionId,
+                            taskId,
+                            outcome: res.outcome,
+                            ...(res.outcome === "error" ? { message: res.message } : {}),
+                        },
+                    });
+                }, 
+                // stopBackgroundTask catches its own rejections; this is belt-and-braces
+                // so a future refactor cannot leave the row held with no answer at all.
+                (err) => {
+                    send({
+                        type: "chat:stop_task_result",
+                        payload: {
+                            sessionId,
+                            taskId,
+                            outcome: "error",
+                            message: err instanceof Error ? err.message : String(err),
+                        },
+                    });
+                });
+                return;
+            }
             if (parsed.type === "chat:subscribe") {
                 onSubscribe(parsed);
                 return;

package/packages/server/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@paddock/server",
-  "version": "0.70.1",
+  "version": "0.71.0",
   "private": true,
   "type": "module"
 }

package/packages/web/dist/assets/{Chip-P4n88XYj.js → Chip-5S5MAayn.js}

@@ -1,2 +1,2 @@
-import{j as r,l as t,r as d}from"./index-B-J2K1w2.js";const u=["w-full rounded-lg border border-edge-strong bg-surface-sunken px-3 py-2 text-sm text-fg","outline-none motion-fast transition-[border-color,box-shadow]","focus:border-accent focus:ring-2 focus:ring-accent/25","disabled:cursor-not-allowed disabled:opacity-60","aria-[invalid=true]:border-danger aria-[invalid=true]:focus:ring-danger/25"].join(" ");function p({className:e,...s}){return r.jsx("input",{className:t(u,e),...s})}function m({className:e,...s}){return r.jsx("textarea",{className:t(u,"resize-y",e),...s})}function h({className:e,...s}){return r.jsx("select",{className:t(u,e),...s})}function j({checked:e,onChange:s,label:a,disabled:n,id:o,className:c}){const i=d.useId(),l=o??i;return r.jsxs("label",{htmlFor:l,className:t("relative inline-block shrink-0 cursor-pointer",c),children:[r.jsx("input",{id:l,type:"checkbox","aria-label":a,className:"peer sr-only",checked:e,disabled:n,onChange:x=>s(x.target.checked)}),r.jsx("span",{className:t("block h-[18px] w-8 rounded-full bg-edge-strong","motion-fast transition-colors","after:absolute after:left-0.5 after:top-0.5 after:h-3.5 after:w-3.5 after:rounded-full","after:bg-surface-raised after:shadow-2xs after:transition-transform after:content-['']","peer-checked:bg-accent-solid peer-checked:after:translate-x-3.5","peer-focus-visible:ring-2 peer-focus-visible:ring-accent/50","peer-disabled:opacity-50")})]})}function w({label:e,description:s,indeterminate:a=!1,className:n,...o}){const c=d.useRef(null);d.useEffect(()=>{c.current&&(c.current.indeterminate=a)},[a]);const i=r.jsx("input",{ref:c,type:"checkbox",...a?{"aria-checked":"mixed"}:{},className:t("h-4 w-4 shrink-0 cursor-pointer rounded border-edge-strong accent-[var(--accent-solid)]","disabled:cursor-not-allowed disabled:opacity-50",e?"mt-0.5":"",n),...o});return e?r.jsxs("label",{className:"flex cursor-pointer items-start gap-2 text-sm text-fg",children:[i,r.jsxs("span",{className:"min-w-0",children:[e,s&&r.jsx("span",{className:"block text-xs leading-snug text-fg-muted",children:s})]})]}):i}const f={neutral:"bg-surface-active text-fg-muted",accent:"bg-accent-soft text-accent",success:"bg-success-soft text-success",warn:"bg-warn-soft text-warn",danger:"bg-danger-soft text-danger",info:"bg-info-soft text-info",lineage:"bg-lineage-soft text-lineage"},g={neutral:"bg-fg-subtle",accent:"bg-accent-solid",success:"bg-success-solid",warn:"bg-warn-solid",danger:"bg-danger-solid",info:"bg-info-solid",lineage:"bg-lineage-solid"};function N({tone:e="neutral",shape:s="tag",size:a="md",dot:n=!1,icon:o,title:c,className:i,children:l}){return r.jsxs("span",{title:c,className:t("inline-flex items-center gap-1 font-medium leading-none",s==="pill"?"rounded-full px-2 py-0.5":"rounded-md px-1.5 py-0.5",a==="sm"?"text-3xs":"text-2xs",f[e],i),children:[n&&r.jsx("span",{className:t("h-1.5 w-1.5 shrink-0 rounded-full",g[e])}),o,l]})}function k({tone:e="neutral",pulse:s=!1,className:a}){return r.jsx("span",{className:t("inline-block h-2 w-2 shrink-0 rounded-full",g[e],s&&"animate-pulse",a)})}function y({tone:e="info",icon:s,className:a,children:n}){const o={neutral:"border-edge",accent:"border-accent-edge",success:"border-success-edge",warn:"border-warn-edge",danger:"border-danger-edge",info:"border-info-edge",lineage:"border-lineage-edge"};return r.jsxs("div",{role:e==="danger"?"alert":void 0,className:t("flex items-start gap-2 rounded-lg border px-3 py-2 text-sm",f[e],o[e],a),children:[s&&r.jsx("span",{className:"mt-0.5 shrink-0",children:s}),r.jsx("div",{className:"min-w-0",children:n})]})}export{N as C,p as I,k as S,j as T,y as a,h as b,m as c,w as d};
+import{j as r,l as t,r as d}from"./index-CbqaEg2j.js";const u=["w-full rounded-lg border border-edge-strong bg-surface-sunken px-3 py-2 text-sm text-fg","outline-none motion-fast transition-[border-color,box-shadow]","focus:border-accent focus:ring-2 focus:ring-accent/25","disabled:cursor-not-allowed disabled:opacity-60","aria-[invalid=true]:border-danger aria-[invalid=true]:focus:ring-danger/25"].join(" ");function p({className:e,...s}){return r.jsx("input",{className:t(u,e),...s})}function m({className:e,...s}){return r.jsx("textarea",{className:t(u,"resize-y",e),...s})}function h({className:e,...s}){return r.jsx("select",{className:t(u,e),...s})}function j({checked:e,onChange:s,label:a,disabled:n,id:o,className:c}){const i=d.useId(),l=o??i;return r.jsxs("label",{htmlFor:l,className:t("relative inline-block shrink-0 cursor-pointer",c),children:[r.jsx("input",{id:l,type:"checkbox","aria-label":a,className:"peer sr-only",checked:e,disabled:n,onChange:x=>s(x.target.checked)}),r.jsx("span",{className:t("block h-[18px] w-8 rounded-full bg-edge-strong","motion-fast transition-colors","after:absolute after:left-0.5 after:top-0.5 after:h-3.5 after:w-3.5 after:rounded-full","after:bg-surface-raised after:shadow-2xs after:transition-transform after:content-['']","peer-checked:bg-accent-solid peer-checked:after:translate-x-3.5","peer-focus-visible:ring-2 peer-focus-visible:ring-accent/50","peer-disabled:opacity-50")})]})}function w({label:e,description:s,indeterminate:a=!1,className:n,...o}){const c=d.useRef(null);d.useEffect(()=>{c.current&&(c.current.indeterminate=a)},[a]);const i=r.jsx("input",{ref:c,type:"checkbox",...a?{"aria-checked":"mixed"}:{},className:t("h-4 w-4 shrink-0 cursor-pointer rounded border-edge-strong accent-[var(--accent-solid)]","disabled:cursor-not-allowed disabled:opacity-50",e?"mt-0.5":"",n),...o});return e?r.jsxs("label",{className:"flex cursor-pointer items-start gap-2 text-sm text-fg",children:[i,r.jsxs("span",{className:"min-w-0",children:[e,s&&r.jsx("span",{className:"block text-xs leading-snug text-fg-muted",children:s})]})]}):i}const f={neutral:"bg-surface-active text-fg-muted",accent:"bg-accent-soft text-accent",success:"bg-success-soft text-success",warn:"bg-warn-soft text-warn",danger:"bg-danger-soft text-danger",info:"bg-info-soft text-info",lineage:"bg-lineage-soft text-lineage"},g={neutral:"bg-fg-subtle",accent:"bg-accent-solid",success:"bg-success-solid",warn:"bg-warn-solid",danger:"bg-danger-solid",info:"bg-info-solid",lineage:"bg-lineage-solid"};function N({tone:e="neutral",shape:s="tag",size:a="md",dot:n=!1,icon:o,title:c,className:i,children:l}){return r.jsxs("span",{title:c,className:t("inline-flex items-center gap-1 font-medium leading-none",s==="pill"?"rounded-full px-2 py-0.5":"rounded-md px-1.5 py-0.5",a==="sm"?"text-3xs":"text-2xs",f[e],i),children:[n&&r.jsx("span",{className:t("h-1.5 w-1.5 shrink-0 rounded-full",g[e])}),o,l]})}function k({tone:e="neutral",pulse:s=!1,className:a}){return r.jsx("span",{className:t("inline-block h-2 w-2 shrink-0 rounded-full",g[e],s&&"animate-pulse",a)})}function y({tone:e="info",icon:s,className:a,children:n}){const o={neutral:"border-edge",accent:"border-accent-edge",success:"border-success-edge",warn:"border-warn-edge",danger:"border-danger-edge",info:"border-info-edge",lineage:"border-lineage-edge"};return r.jsxs("div",{role:e==="danger"?"alert":void 0,className:t("flex items-start gap-2 rounded-lg border px-3 py-2 text-sm",f[e],o[e],a),children:[s&&r.jsx("span",{className:"mt-0.5 shrink-0",children:s}),r.jsx("div",{className:"min-w-0",children:n})]})}export{N as C,p as I,k as S,j as T,y as a,h as b,m as c,w as d};
 

package/packages/web/dist/assets/DiscoverPage-CEzcRO7X.js

@@ -0,0 +1,2 @@
+import{j as r}from"./index-CbqaEg2j.js";import{D as o}from"./DiscoverView-CArICIRO.js";import"./Surfaces-DCm19ZAD.js";import"./Chip-5S5MAayn.js";function s(){return r.jsx(o,{})}export{s as DiscoverPage};
+