botmux 3.12.1 → 3.13.0

package/dist/core/config-dir.d.ts

@@ -0,0 +1,167 @@
+/**
+ * Resolve Botmux's configuration directory (`~/.botmux`) and the bots.json
+ * registry inside it, from ONE canonical precedence rule that matches the
+ * registry loader: `BOTS_CONFIG` (exact file) > `os.homedir()/.botmux/bots.json`.
+ *
+ * The home half is `os.homedir()` — deliberately the SAME single semantic
+ * `cli.ts` uses — NOT a hand-rolled `HOME`/`USERPROFILE` read, which forks from
+ * `cli.ts` on win32. See {@link resolveBotmuxConfigDir} for the platform contract.
+ *
+ * ── The bug this closes ──────────────────────────────────────────────────────
+ * `HOME=~/alt botmux start` makes the daemon load `~/alt/.botmux/bots.json`, but
+ * the daemon injects only `cwd` and the `BOTMUX_*` family into CLI children —
+ * never `HOME`. The child therefore resolves `homedir()/.botmux/bots.json` (the
+ * *default* home), does not find the bot it is running as, and every
+ * `botmux send` / `botmux history` from inside that session fails with
+ * `Bot not registered: <appId>`.
+ *
+ * ── Why the child is pinned to a FILE, not a DIRECTORY ───────────────────────
+ * The registry's real precedence is `BOTS_CONFIG` > `<config dir>/bots.json`,
+ * and `BOTS_CONFIG` may name an ARBITRARY file (`/srv/fleet-a.json`). A
+ * directory-shaped hint therefore cannot express what the daemon actually
+ * loaded: `dirname` + a hardcoded `bots.json` guesses wrong for every custom
+ * filename, and it sits BELOW `BOTS_CONFIG` in precedence, so a stale ambient
+ * `BOTS_CONFIG` in a shared tmux server's global env would silently outrank it
+ * and hand the child a foreign registry (verified: the child loaded the stale
+ * file while the daemon had the correct one).
+ *
+ * So the daemon pins the EXACT path it loaded — `getLoadedConfigPath()`, already
+ * frozen into `loadedBotsConfigPath` for the sandbox fs-policy — into the
+ * child's `BOTS_CONFIG`. That is one authority, at the TOP of the precedence
+ * chain, and file-shaped so any filename survives. `BOTS_CONFIG` is also
+ * reserved from per-bot `env` and scrubbed off the pane/tmux paths, because a
+ * bot must not be able to redirect the registry that defines it.
+ *
+ * Injecting `HOME` into children was considered and rejected: `HOME` also
+ * anchors the CLI's own config discovery (Claude Code falls back to
+ * `$HOME/.claude` when `CLAUDE_CONFIG_DIR` is unset), so overriding it to point
+ * at the fleet home silently relocates skills/settings for the spawned agent.
+ *
+ * ── Scope (deliberately narrow) ──────────────────────────────────────────────
+ * This is an INTERNAL daemon→child propagation fix, not a new public
+ * "relocate botmux" knob. `os.homedir()` already follows `$HOME`, so
+ * `HOME=~/alt botmux start` ALREADY relocates cli.ts's `CONFIG_DIR` / `DATA_DIR`
+ * / `PM2_HOME` / `BOTS_JSON_FILE`, the dashboard's write path and setup —
+ * verified: `HOME=<fleet> botmux setup list` reads the fleet registry with no
+ * code change. The daemon-spawned CLI child was the ONLY process that diverged,
+ * precisely because it is the only one that does not inherit `HOME`. Introducing
+ * a second, dir-shaped public variable would have created a rival source of
+ * truth that governs the registry but not the data dir, pm2 home or dashboard
+ * writes — half-relocated deployments — so no public variable is added.
+ */
+export interface ResolveBotmuxConfigDirOptions {
+    /**
+     * Consulted for `BOTS_CONFIG` ONLY (see {@link resolveBotsConfigFile}) —
+     * never to derive the home directory. Reading `HOME`/`USERPROFILE` here would
+     * fork the config dir away from `cli.ts`'s `join(homedir(), '.botmux')` on
+     * win32; see {@link resolveBotmuxConfigDir}.
+     */
+    env?: NodeJS.ProcessEnv;
+    /** Test seam ONLY (production passes nothing); defaults to os.homedir(). */
+    homeDir?: string;
+}
+/**
+ * The env var naming the EXACT bots.json to load. Top of the registry's
+ * precedence chain, and the channel the daemon uses to pin its own loaded path
+ * onto a spawned CLI child.
+ *
+ * Reserved from per-bot `env` (see core/per-bot-env.ts) and stripped from the
+ * tmux client env + pane wrapper (see utils/child-env.ts): a bot must not be
+ * able to redirect the registry that defines it, and a stale value in a shared
+ * tmux server's global env must not reach a pane.
+ */
+export declare const BOTS_CONFIG_ENV = "BOTS_CONFIG";
+/**
+ * `<home>/.botmux`, where `<home>` is `os.homedir()` — the SAME single semantic
+ * `cli.ts` uses for `CONFIG_DIR` / `DATA_DIR` / `PM2_HOME` / `BOTS_JSON_FILE`
+ * and the dashboard write path (`cli.ts`: `join(homedir(), '.botmux')`).
+ *
+ * ── Why NOT `env.HOME ?? env.USERPROFILE ?? homedir()` ───────────────────────
+ * Because `os.homedir()` is ALREADY the env-following rule, per platform, and
+ * re-deriving it by hand gets the platform wrong. Node's contract
+ * (https://nodejs.org/api/os.html#oshomedir):
+ *   · POSIX — uses `$HOME` when set, else getpwuid(). So `HOME=~/alt botmux …`
+ *     relocates the config dir with NO extra code; the hand-rolled `HOME` arm
+ *     buys nothing here.
+ *   · win32 — uses `%USERPROFILE%`; `HOME` is NOT consulted.
+ * A HOME-first rule therefore FORKS from `cli.ts` on win32 whenever `HOME` and
+ * `USERPROFILE` are both set to different values (Git-for-Windows/MSYS shells set
+ * `HOME`): `setup`/`start`/PM2 would write `%USERPROFILE%\.botmux` while the
+ * daemon's registry read `%HOME%\.botmux` — reconstructing the very daemon/child
+ * registry split this module exists to close, on a platform the repo supports
+ * (win32 PM2 / Task Scheduler / `.cmd` wrapper paths). master's bot-registry used
+ * bare `homedir()` and agreed with `cli.ts`, so a HOME-first rule here would be a
+ * REGRESSION, not a new feature.
+ *
+ * A hand-rolled env read is also wrong in a platform-INDEPENDENT way: `??` is
+ * nullish, so `HOME=''` (which does occur in stripped service environments) is
+ * accepted as a real value and `join('', '.botmux')` yields the RELATIVE,
+ * cwd-dependent `.botmux`. `homedir()` has no such hole on POSIX — an empty
+ * `$HOME` falls through to getpwuid().
+ *
+ * Custom homes in TESTS go through the `homeDir` seam, never through env.
+ *
+ * Note this resolves the DIRECTORY only, and is therefore NOT the whole story
+ * for the registry: `BOTS_CONFIG` may point at an arbitrary file outside this
+ * dir. Use {@link resolveBotsConfigFile} whenever you need the registry path.
+ */
+export declare function resolveBotmuxConfigDir(options?: ResolveBotmuxConfigDirOptions): string;
+/**
+ * The bots.json path implied by the environment: `BOTS_CONFIG` (absolute-ized
+ * against cwd, exactly as the loader does) else `<config dir>/bots.json`.
+ *
+ * `env` is consulted for `BOTS_CONFIG` ONLY. The home half comes from
+ * {@link resolveBotmuxConfigDir} (i.e. `os.homedir()`), so this never re-derives
+ * a home from `HOME`/`USERPROFILE` and cannot fork from `cli.ts` on win32.
+ *
+ * Existence is NOT checked here — callers differ on what an absent file means
+ * (the loader throws for an explicit `BOTS_CONFIG`, degrades for the default).
+ */
+export declare function resolveBotsConfigFile(options?: ResolveBotmuxConfigDirOptions): string;
+/**
+ * Where a `loadedBotsConfigPath` came from. This is the PROVENANCE the pin
+ * decision turns on, and it is carried explicitly because it is NOT derivable
+ * from the path or from the filesystem:
+ *
+ *  · `'loaded'`  — the daemon actually opened and parsed this exact file
+ *                  (`resolveBotConfigPath` set it). It is the registry authority.
+ *  · `'synthetic'` — nothing was parsed. Core-only synthesis
+ *                  (`maybeSynthesizeCoreOnlyConfig`) pins the DEFAULT
+ *                  `<config dir>/bots.json` purely so the no-transport fs-policy
+ *                  sees the config inside the default authority root; that file
+ *                  is ignored by design and may not even exist.
+ *
+ * An `existsSync` probe cannot stand in for this:
+ * existence and provenance are independent, so the probe is wrong in BOTH
+ * directions. A real loaded file that later vanished reads as "absent" and the
+ * pin gets dropped (the child then silently loads a FOREIGN registry from its own
+ * HOME); a synthetic placeholder that happens to exist reads as "present" and
+ * gets pinned even though the daemon never parsed it.
+ */
+export type BotsConfigProvenance = 'loaded' | 'synthetic';
+/**
+ * Decide the `BOTS_CONFIG` value to pin onto a spawned CLI child.
+ *
+ * The rule is provenance-driven, NOT existence-driven:
+ *
+ *  · provenance `'loaded'` → pin UNCONDITIONALLY (absolute-ized, since daemon /
+ *    worker / pane share no cwd). Even if the file has since vanished, the pin
+ *    stays: the child must then FAIL LOUDLY in the loader
+ *    (`BOTS_CONFIG file not found`, bot-registry.ts) rather than silently switch
+ *    authority to whatever `<its own HOME>/.botmux/bots.json` contains. Under a
+ *    multi-fleet non-default HOME that fallback is a DIFFERENT registry — same
+ *    appId can carry another fleet's secret and another oncall routing — so
+ *    "fail closed" is strictly correct and "degrade gracefully" is the bug.
+ *    (A read-ISOLATED child still works: Seatbelt allows the metadata read, so
+ *    the loader's `existsSync` passes and its `EPERM + underReadIsolation`
+ *    branch takes over.)
+ *
+ *  · provenance `'synthetic'` (or no path at all) → return null, and the caller
+ *    must DELETE `BOTS_CONFIG` from the child env rather than leave an inherited
+ *    value: `BOTS_CONFIG` is the TOP of the precedence chain, so a stale ambient
+ *    value would outrank the on-disk default and hand the child a foreign
+ *    registry. Omitting it is right here precisely because nothing was parsed —
+ *    there is no authority to propagate.
+ */
+export declare function resolveChildBotsConfig(loadedConfigPath: string | undefined, provenance: BotsConfigProvenance | undefined): string | null;
+//# sourceMappingURL=config-dir.d.ts.map

package/dist/core/config-dir.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"config-dir.d.ts","sourceRoot":"","sources":["../../src/core/config-dir.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkDG;AAKH,MAAM,WAAW,6BAA6B;IAC5C;;;;;OAKG;IACH,GAAG,CAAC,EAAE,MAAM,CAAC,UAAU,CAAC;IACxB,4EAA4E;IAC5E,OAAO,CAAC,EAAE,MAAM,CAAC;CAClB;AAED;;;;;;;;;GASG;AACH,eAAO,MAAM,eAAe,gBAAgB,CAAC;AAE7C;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAiCG;AACH,wBAAgB,sBAAsB,CACpC,OAAO,GAAE,6BAAkC,GAC1C,MAAM,CAER;AAED;;;;;;;;;;GAUG;AACH,wBAAgB,qBAAqB,CACnC,OAAO,GAAE,6BAAkC,GAC1C,MAAM,CAKR;AAED;;;;;;;;;;;;;;;;;;;GAmBG;AACH,MAAM,MAAM,oBAAoB,GAAG,QAAQ,GAAG,WAAW,CAAC;AAE1D;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,wBAAgB,sBAAsB,CACpC,gBAAgB,EAAE,MAAM,GAAG,SAAS,EACpC,UAAU,EAAE,oBAAoB,GAAG,SAAS,GAC3C,MAAM,GAAG,IAAI,CAKf"}

package/dist/core/config-dir.js

@@ -0,0 +1,152 @@
+/**
+ * Resolve Botmux's configuration directory (`~/.botmux`) and the bots.json
+ * registry inside it, from ONE canonical precedence rule that matches the
+ * registry loader: `BOTS_CONFIG` (exact file) > `os.homedir()/.botmux/bots.json`.
+ *
+ * The home half is `os.homedir()` — deliberately the SAME single semantic
+ * `cli.ts` uses — NOT a hand-rolled `HOME`/`USERPROFILE` read, which forks from
+ * `cli.ts` on win32. See {@link resolveBotmuxConfigDir} for the platform contract.
+ *
+ * ── The bug this closes ──────────────────────────────────────────────────────
+ * `HOME=~/alt botmux start` makes the daemon load `~/alt/.botmux/bots.json`, but
+ * the daemon injects only `cwd` and the `BOTMUX_*` family into CLI children —
+ * never `HOME`. The child therefore resolves `homedir()/.botmux/bots.json` (the
+ * *default* home), does not find the bot it is running as, and every
+ * `botmux send` / `botmux history` from inside that session fails with
+ * `Bot not registered: <appId>`.
+ *
+ * ── Why the child is pinned to a FILE, not a DIRECTORY ───────────────────────
+ * The registry's real precedence is `BOTS_CONFIG` > `<config dir>/bots.json`,
+ * and `BOTS_CONFIG` may name an ARBITRARY file (`/srv/fleet-a.json`). A
+ * directory-shaped hint therefore cannot express what the daemon actually
+ * loaded: `dirname` + a hardcoded `bots.json` guesses wrong for every custom
+ * filename, and it sits BELOW `BOTS_CONFIG` in precedence, so a stale ambient
+ * `BOTS_CONFIG` in a shared tmux server's global env would silently outrank it
+ * and hand the child a foreign registry (verified: the child loaded the stale
+ * file while the daemon had the correct one).
+ *
+ * So the daemon pins the EXACT path it loaded — `getLoadedConfigPath()`, already
+ * frozen into `loadedBotsConfigPath` for the sandbox fs-policy — into the
+ * child's `BOTS_CONFIG`. That is one authority, at the TOP of the precedence
+ * chain, and file-shaped so any filename survives. `BOTS_CONFIG` is also
+ * reserved from per-bot `env` and scrubbed off the pane/tmux paths, because a
+ * bot must not be able to redirect the registry that defines it.
+ *
+ * Injecting `HOME` into children was considered and rejected: `HOME` also
+ * anchors the CLI's own config discovery (Claude Code falls back to
+ * `$HOME/.claude` when `CLAUDE_CONFIG_DIR` is unset), so overriding it to point
+ * at the fleet home silently relocates skills/settings for the spawned agent.
+ *
+ * ── Scope (deliberately narrow) ──────────────────────────────────────────────
+ * This is an INTERNAL daemon→child propagation fix, not a new public
+ * "relocate botmux" knob. `os.homedir()` already follows `$HOME`, so
+ * `HOME=~/alt botmux start` ALREADY relocates cli.ts's `CONFIG_DIR` / `DATA_DIR`
+ * / `PM2_HOME` / `BOTS_JSON_FILE`, the dashboard's write path and setup —
+ * verified: `HOME=<fleet> botmux setup list` reads the fleet registry with no
+ * code change. The daemon-spawned CLI child was the ONLY process that diverged,
+ * precisely because it is the only one that does not inherit `HOME`. Introducing
+ * a second, dir-shaped public variable would have created a rival source of
+ * truth that governs the registry but not the data dir, pm2 home or dashboard
+ * writes — half-relocated deployments — so no public variable is added.
+ */
+import { homedir } from 'node:os';
+import { isAbsolute, join, resolve } from 'node:path';
+/**
+ * The env var naming the EXACT bots.json to load. Top of the registry's
+ * precedence chain, and the channel the daemon uses to pin its own loaded path
+ * onto a spawned CLI child.
+ *
+ * Reserved from per-bot `env` (see core/per-bot-env.ts) and stripped from the
+ * tmux client env + pane wrapper (see utils/child-env.ts): a bot must not be
+ * able to redirect the registry that defines it, and a stale value in a shared
+ * tmux server's global env must not reach a pane.
+ */
+export const BOTS_CONFIG_ENV = 'BOTS_CONFIG';
+/**
+ * `<home>/.botmux`, where `<home>` is `os.homedir()` — the SAME single semantic
+ * `cli.ts` uses for `CONFIG_DIR` / `DATA_DIR` / `PM2_HOME` / `BOTS_JSON_FILE`
+ * and the dashboard write path (`cli.ts`: `join(homedir(), '.botmux')`).
+ *
+ * ── Why NOT `env.HOME ?? env.USERPROFILE ?? homedir()` ───────────────────────
+ * Because `os.homedir()` is ALREADY the env-following rule, per platform, and
+ * re-deriving it by hand gets the platform wrong. Node's contract
+ * (https://nodejs.org/api/os.html#oshomedir):
+ *   · POSIX — uses `$HOME` when set, else getpwuid(). So `HOME=~/alt botmux …`
+ *     relocates the config dir with NO extra code; the hand-rolled `HOME` arm
+ *     buys nothing here.
+ *   · win32 — uses `%USERPROFILE%`; `HOME` is NOT consulted.
+ * A HOME-first rule therefore FORKS from `cli.ts` on win32 whenever `HOME` and
+ * `USERPROFILE` are both set to different values (Git-for-Windows/MSYS shells set
+ * `HOME`): `setup`/`start`/PM2 would write `%USERPROFILE%\.botmux` while the
+ * daemon's registry read `%HOME%\.botmux` — reconstructing the very daemon/child
+ * registry split this module exists to close, on a platform the repo supports
+ * (win32 PM2 / Task Scheduler / `.cmd` wrapper paths). master's bot-registry used
+ * bare `homedir()` and agreed with `cli.ts`, so a HOME-first rule here would be a
+ * REGRESSION, not a new feature.
+ *
+ * A hand-rolled env read is also wrong in a platform-INDEPENDENT way: `??` is
+ * nullish, so `HOME=''` (which does occur in stripped service environments) is
+ * accepted as a real value and `join('', '.botmux')` yields the RELATIVE,
+ * cwd-dependent `.botmux`. `homedir()` has no such hole on POSIX — an empty
+ * `$HOME` falls through to getpwuid().
+ *
+ * Custom homes in TESTS go through the `homeDir` seam, never through env.
+ *
+ * Note this resolves the DIRECTORY only, and is therefore NOT the whole story
+ * for the registry: `BOTS_CONFIG` may point at an arbitrary file outside this
+ * dir. Use {@link resolveBotsConfigFile} whenever you need the registry path.
+ */
+export function resolveBotmuxConfigDir(options = {}) {
+    return join(options.homeDir ?? homedir(), '.botmux');
+}
+/**
+ * The bots.json path implied by the environment: `BOTS_CONFIG` (absolute-ized
+ * against cwd, exactly as the loader does) else `<config dir>/bots.json`.
+ *
+ * `env` is consulted for `BOTS_CONFIG` ONLY. The home half comes from
+ * {@link resolveBotmuxConfigDir} (i.e. `os.homedir()`), so this never re-derives
+ * a home from `HOME`/`USERPROFILE` and cannot fork from `cli.ts` on win32.
+ *
+ * Existence is NOT checked here — callers differ on what an absent file means
+ * (the loader throws for an explicit `BOTS_CONFIG`, degrades for the default).
+ */
+export function resolveBotsConfigFile(options = {}) {
+    const env = options.env ?? process.env;
+    const explicit = env[BOTS_CONFIG_ENV]?.trim();
+    if (explicit)
+        return resolve(explicit);
+    return join(resolveBotmuxConfigDir(options), 'bots.json');
+}
+/**
+ * Decide the `BOTS_CONFIG` value to pin onto a spawned CLI child.
+ *
+ * The rule is provenance-driven, NOT existence-driven:
+ *
+ *  · provenance `'loaded'` → pin UNCONDITIONALLY (absolute-ized, since daemon /
+ *    worker / pane share no cwd). Even if the file has since vanished, the pin
+ *    stays: the child must then FAIL LOUDLY in the loader
+ *    (`BOTS_CONFIG file not found`, bot-registry.ts) rather than silently switch
+ *    authority to whatever `<its own HOME>/.botmux/bots.json` contains. Under a
+ *    multi-fleet non-default HOME that fallback is a DIFFERENT registry — same
+ *    appId can carry another fleet's secret and another oncall routing — so
+ *    "fail closed" is strictly correct and "degrade gracefully" is the bug.
+ *    (A read-ISOLATED child still works: Seatbelt allows the metadata read, so
+ *    the loader's `existsSync` passes and its `EPERM + underReadIsolation`
+ *    branch takes over.)
+ *
+ *  · provenance `'synthetic'` (or no path at all) → return null, and the caller
+ *    must DELETE `BOTS_CONFIG` from the child env rather than leave an inherited
+ *    value: `BOTS_CONFIG` is the TOP of the precedence chain, so a stale ambient
+ *    value would outrank the on-disk default and hand the child a foreign
+ *    registry. Omitting it is right here precisely because nothing was parsed —
+ *    there is no authority to propagate.
+ */
+export function resolveChildBotsConfig(loadedConfigPath, provenance) {
+    if (provenance !== 'loaded')
+        return null;
+    const trimmed = loadedConfigPath?.trim();
+    if (!trimmed)
+        return null;
+    return isAbsolute(trimmed) ? trimmed : resolve(trimmed);
+}
+//# sourceMappingURL=config-dir.js.map

package/dist/core/config-dir.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"config-dir.js","sourceRoot":"","sources":["../../src/core/config-dir.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkDG;AAEH,OAAO,EAAE,OAAO,EAAE,MAAM,SAAS,CAAC;AAClC,OAAO,EAAE,UAAU,EAAE,IAAI,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AActD;;;;;;;;;GASG;AACH,MAAM,CAAC,MAAM,eAAe,GAAG,aAAa,CAAC;AAE7C;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAiCG;AACH,MAAM,UAAU,sBAAsB,CACpC,UAAyC,EAAE;IAE3C,OAAO,IAAI,CAAC,OAAO,CAAC,OAAO,IAAI,OAAO,EAAE,EAAE,SAAS,CAAC,CAAC;AACvD,CAAC;AAED;;;;;;;;;;GAUG;AACH,MAAM,UAAU,qBAAqB,CACnC,UAAyC,EAAE;IAE3C,MAAM,GAAG,GAAG,OAAO,CAAC,GAAG,IAAI,OAAO,CAAC,GAAG,CAAC;IACvC,MAAM,QAAQ,GAAG,GAAG,CAAC,eAAe,CAAC,EAAE,IAAI,EAAE,CAAC;IAC9C,IAAI,QAAQ;QAAE,OAAO,OAAO,CAAC,QAAQ,CAAC,CAAC;IACvC,OAAO,IAAI,CAAC,sBAAsB,CAAC,OAAO,CAAC,EAAE,WAAW,CAAC,CAAC;AAC5D,CAAC;AAwBD;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,MAAM,UAAU,sBAAsB,CACpC,gBAAoC,EACpC,UAA4C;IAE5C,IAAI,UAAU,KAAK,QAAQ;QAAE,OAAO,IAAI,CAAC;IACzC,MAAM,OAAO,GAAG,gBAAgB,EAAE,IAAI,EAAE,CAAC;IACzC,IAAI,CAAC,OAAO;QAAE,OAAO,IAAI,CAAC;IAC1B,OAAO,UAAU,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,OAAO,CAAC,OAAO,CAAC,CAAC;AAC1D,CAAC"}

package/dist/core/dashboard-ipc-server.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"dashboard-ipc-server.d.ts","sourceRoot":"","sources":["../../src/core/dashboard-ipc-server.ts"],"names":[],"mappings":"AACA,OAAO,EAAgB,KAAK,eAAe,EAAE,KAAK,cAAc,EAAe,MAAM,WAAW,CAAC;AA+DjG,OAAO,EAAE,0BAA0B,EAAE,MAAM,iCAAiC,CAAC;AAyE7E,OAAO,EAGL,KAAK,0BAA0B,EAChC,MAAM,8BAA8B,CAAC;AAGtC,4FAA4F;AAC5F,wBAAgB,wBAAwB,CAAC,OAAO,EAAE,OAAO,0BAA0B,GAAG,IAAI,GAAG,IAAI,CAEhG;AAID,MAAM,MAAM,gBAAgB,GACxB;IAAE,EAAE,EAAE,IAAI,CAAC;IAAC,IAAI,EAAE,MAAM,CAAA;CAAE,GAC1B;IAAE,EAAE,EAAE,KAAK,CAAC;IAAC,MAAM,EAAE,MAAM,CAAC;IAAC,OAAO,EAAE,MAAM,CAAA;CAAE,CAAC;AAEnD,wBAAgB,aAAa,CAAC,EAAE,EAAE,CAAC,CAAC,OAAO,EAAE,MAAM,KAAK,OAAO,CAAC,gBAAgB,CAAC,CAAC,GAAG,IAAI,GAAG,IAAI,CAE/F;AAID,MAAM,MAAM,gBAAgB,GACxB;IAAE,EAAE,EAAE,IAAI,CAAC;IAAC,SAAS,EAAE,MAAM,CAAC;IAAC,SAAS,CAAC,EAAE,MAAM,CAAA;CAAE,GACnD;IAAE,EAAE,EAAE,KAAK,CAAC;IAAC,MAAM,EAAE,MAAM,CAAC;IAAC,OAAO,EAAE,MAAM,CAAA;CAAE,CAAC;AAEnD,wBAAgB,mBAAmB,CAAC,EAAE,EAAE,CAAC,CAAC,KAAK,EAAE,MAAM,KAAK,OAAO,CAAC,gBAAgB,CAAC,CAAC,GAAG,IAAI,GAAG,IAAI,CAEnG;AAED,KAAK,8BAA8B,GAAG,0BAA0B,GAAG;IACjE,QAAQ,EAAE,MAAM,OAAO,CAAC,IAAI,CAAC,CAAC;CAC/B,CAAC;AAEF,wBAAgB,4BAA4B,CAC1C,YAAY,EAAE,8BAA8B,GAAG,IAAI,GAClD,IAAI,CAEN;AACD,OAAO,EACL,oBAAoB,EACpB,oBAAoB,EACpB,6BAA6B,EAI7B,KAAK,UAAU,EAChB,MAAM,qBAAqB,CAAC;AAU7B,OAAO,KAAK,EAAiC,cAAc,EAAE,yBAAyB,EAAW,MAAM,aAAa,CAAC;AAsBrH,MAAM,WAAW,eAAe;IAC9B,IAAI,EAAE,MAAM,CAAC;IACb,KAAK,EAAE,MAAM,OAAO,CAAC,IAAI,CAAC,CAAC;CAC5B;AAED,MAAM,MAAM,OAAO,GAAG,CACpB,GAAG,EAAE,eAAe,EACpB,GAAG,EAAE,cAAc,EACnB,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,KAC3B,OAAO,CAAC,IAAI,CAAC,GAAG,IAAI,CAAC;AAe1B,wBAAgB,uBAAuB,CAAC,GAAG,EAAE,eAAe,GAAG,OAAO,CAErE;AAED,0FAA0F;AAC1F,wBAAgB,QAAQ,CAAC,MAAM,EAAE,MAAM,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,OAAO,GAAG,IAAI,CAM7E;AAED,wBAAgB,OAAO,CAAC,GAAG,EAAE,cAAc,EAAE,MAAM,EAAE,MAAM,EAAE,IAAI,EAAE,OAAO,GAAG,IAAI,CAGhF;AAwED,qBAAa,qBAAsB,SAAQ,KAAK;IAClC,QAAQ,CAAC,QAAQ,EAAE,MAAM;gBAAhB,QAAQ,EAAE,MAAM;CAItC;AAED,qBAAa,kBAAmB,SAAQ,KAAK;IAEzC,QAAQ,CAAC,KAAK,EAAE,MAAM;IACtB,QAAQ,CAAC,SAAS,EAAE,MAAM;gBADjB,KAAK,EAAE,MAAM,EACb,SAAS,EAAE,MAAM;CAK7B;AAED,gDAAgD;AAChD,wBAAgB,oBAAoB,CAClC,KAAK,EAAE,OAAO,EACd,YAAY,EAAE,SAAS,MAAM,EAAE,GAC9B,KAAK,IAAI,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAWlC;AAED;;;GAGG;AACH,wBAAsB,oBAAoB,CAAC,CAAC,EAC1C,KAAK,EAAE,MAAM,EACb,SAAS,EAAE,MAAM,EACjB,IAAI,EAAE,CAAC,MAAM,EAAE,WAAW,EAAE,UAAU,EAAE,MAAM,KAAK,OAAO,CAAC,CAAC,CAAC,GAC5D,OAAO,CAAC,CAAC,CAAC,CAoBZ;AAED,wBAAsB,YAAY,CAAC,CAAC,GAAG,OAAO,EAC5C,GAAG,EAAE,eAAe,EACpB,QAAQ,CAAC,EAAE,MAAM,GAChB,OAAO,CAAC,CAAC,CAAC,CAuEZ;AA6FD,sEAAsE;AACtE,wBAAgB,gBAAgB,CAAC,MAAM,EAAE,MAAM,GAAG,IAAI,GAAG,IAAI,CAAgC;AAM7F;;;wBAGwB;AACxB,wBAAgB,iBAAiB,CAAC,GAAG,EAAE,eAAe,EAAE,IAAI,CAAC,EAAE,MAAM,GAAG,OAAO,CAS9E;AA4GD,wBAAgB,wBAAwB,IAAI,IAAI,CAAkC;AAClF,wBAAgB,gBAAgB,IAAI,IAAI,CAA0B;AAClE,6EAA6E;AAC7E,wBAAgB,iCAAiC,IAAI,IAAI,CAA0D;AAuLnH,YAAY,EAAE,UAAU,EAAE,CAAC;AAC3B,OAAO,EAAE,oBAAoB,EAAE,oBAAoB,EAAE,6BAA6B,EAAE,CAAC;AAMrF,wBAAgB,UAAU,CAAC,IAAI,EAAE,MAAM,GAAG,IAAI,CAA0B;AAkBxE,wBAAgB,YAAY,CAAC,EAAE,EAAE,MAAM,GAAG,IAAI,CAA0B;AA24CxE,MAAM,WAAW,WAAW;IAC1B,EAAE,EAAE,MAAM,CAAC;IACX,IAAI,EAAE,MAAM,CAAC;IACb,QAAQ,EAAE,MAAM,CAAC;IACjB,MAAM,EAAE,cAAc,CAAC;IACvB,MAAM,EAAE,MAAM,CAAC;IACf,UAAU,EAAE,MAAM,CAAC;IACnB,MAAM,EAAE,MAAM,CAAC;IACf,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB,KAAK,CAAC,EAAE,QAAQ,GAAG,MAAM,CAAC;IAC1B,iBAAiB,CAAC,EAAE,yBAAyB,CAAC;IAC9C,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,OAAO,EAAE,OAAO,CAAC;IACjB,SAAS,EAAE,MAAM,CAAC;IAClB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,UAAU,CAAC,EAAE,IAAI,GAAG,OAAO,CAAC;IAC5B,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,MAAM,CAAC,EAAE;QAAE,KAAK,EAAE,MAAM,GAAG,IAAI,CAAC;QAAC,SAAS,EAAE,MAAM,CAAA;KAAE,CAAC;IACrD,OAAO,CAAC,EAAE,QAAQ,GAAG,OAAO,GAAG,WAAW,CAAC;IAC3C,MAAM,CAAC,EAAE,OAAO,CAAC;IACjB,cAAc,EAAE,MAAM,CAAC;CACxB;AAw4ED,wBAAgB,cAAc,CAAC,IAAI,EAAE;IACnC,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,EAAE,MAAM,CAAC;IACb;;;+EAG2E;IAC3E,YAAY,CAAC,EAAE,OAAO,CAAC;IACvB;;sDAEkD;IAClD,KAAK,CAAC,EAAE,OAAO,CAAC,IAAI,CAAC,CAAC;IACtB;;;;wCAIoC;IACpC,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB;;kFAE8E;IAC9E,oBAAoB,CAAC,EAAE,OAAO,CAAC;CAChC,GAAG,OAAO,CAAC,eAAe,CAAC,CA8D3B"}
+{"version":3,"file":"dashboard-ipc-server.d.ts","sourceRoot":"","sources":["../../src/core/dashboard-ipc-server.ts"],"names":[],"mappings":"AACA,OAAO,EAAgB,KAAK,eAAe,EAAE,KAAK,cAAc,EAAe,MAAM,WAAW,CAAC;AA+DjG,OAAO,EAAE,0BAA0B,EAAE,MAAM,iCAAiC,CAAC;AAyE7E,OAAO,EAGL,KAAK,0BAA0B,EAChC,MAAM,8BAA8B,CAAC;AAGtC,4FAA4F;AAC5F,wBAAgB,wBAAwB,CAAC,OAAO,EAAE,OAAO,0BAA0B,GAAG,IAAI,GAAG,IAAI,CAEhG;AAID,MAAM,MAAM,gBAAgB,GACxB;IAAE,EAAE,EAAE,IAAI,CAAC;IAAC,IAAI,EAAE,MAAM,CAAA;CAAE,GAC1B;IAAE,EAAE,EAAE,KAAK,CAAC;IAAC,MAAM,EAAE,MAAM,CAAC;IAAC,OAAO,EAAE,MAAM,CAAA;CAAE,CAAC;AAEnD,wBAAgB,aAAa,CAAC,EAAE,EAAE,CAAC,CAAC,OAAO,EAAE,MAAM,KAAK,OAAO,CAAC,gBAAgB,CAAC,CAAC,GAAG,IAAI,GAAG,IAAI,CAE/F;AAID,MAAM,MAAM,gBAAgB,GACxB;IAAE,EAAE,EAAE,IAAI,CAAC;IAAC,SAAS,EAAE,MAAM,CAAC;IAAC,SAAS,CAAC,EAAE,MAAM,CAAA;CAAE,GACnD;IAAE,EAAE,EAAE,KAAK,CAAC;IAAC,MAAM,EAAE,MAAM,CAAC;IAAC,OAAO,EAAE,MAAM,CAAA;CAAE,CAAC;AAEnD,wBAAgB,mBAAmB,CAAC,EAAE,EAAE,CAAC,CAAC,KAAK,EAAE,MAAM,KAAK,OAAO,CAAC,gBAAgB,CAAC,CAAC,GAAG,IAAI,GAAG,IAAI,CAEnG;AAED,KAAK,8BAA8B,GAAG,0BAA0B,GAAG;IACjE,QAAQ,EAAE,MAAM,OAAO,CAAC,IAAI,CAAC,CAAC;CAC/B,CAAC;AAEF,wBAAgB,4BAA4B,CAC1C,YAAY,EAAE,8BAA8B,GAAG,IAAI,GAClD,IAAI,CAEN;AACD,OAAO,EACL,oBAAoB,EACpB,oBAAoB,EACpB,6BAA6B,EAI7B,KAAK,UAAU,EAChB,MAAM,qBAAqB,CAAC;AAU7B,OAAO,KAAK,EAAiC,cAAc,EAAE,yBAAyB,EAAW,MAAM,aAAa,CAAC;AAsBrH,MAAM,WAAW,eAAe;IAC9B,IAAI,EAAE,MAAM,CAAC;IACb,KAAK,EAAE,MAAM,OAAO,CAAC,IAAI,CAAC,CAAC;CAC5B;AAED,MAAM,MAAM,OAAO,GAAG,CACpB,GAAG,EAAE,eAAe,EACpB,GAAG,EAAE,cAAc,EACnB,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,KAC3B,OAAO,CAAC,IAAI,CAAC,GAAG,IAAI,CAAC;AAe1B,wBAAgB,uBAAuB,CAAC,GAAG,EAAE,eAAe,GAAG,OAAO,CAErE;AAED,0FAA0F;AAC1F,wBAAgB,QAAQ,CAAC,MAAM,EAAE,MAAM,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,OAAO,GAAG,IAAI,CAM7E;AAED,wBAAgB,OAAO,CAAC,GAAG,EAAE,cAAc,EAAE,MAAM,EAAE,MAAM,EAAE,IAAI,EAAE,OAAO,GAAG,IAAI,CAGhF;AAwED,qBAAa,qBAAsB,SAAQ,KAAK;IAClC,QAAQ,CAAC,QAAQ,EAAE,MAAM;gBAAhB,QAAQ,EAAE,MAAM;CAItC;AAED,qBAAa,kBAAmB,SAAQ,KAAK;IAEzC,QAAQ,CAAC,KAAK,EAAE,MAAM;IACtB,QAAQ,CAAC,SAAS,EAAE,MAAM;gBADjB,KAAK,EAAE,MAAM,EACb,SAAS,EAAE,MAAM;CAK7B;AAED,gDAAgD;AAChD,wBAAgB,oBAAoB,CAClC,KAAK,EAAE,OAAO,EACd,YAAY,EAAE,SAAS,MAAM,EAAE,GAC9B,KAAK,IAAI,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAWlC;AAED;;;GAGG;AACH,wBAAsB,oBAAoB,CAAC,CAAC,EAC1C,KAAK,EAAE,MAAM,EACb,SAAS,EAAE,MAAM,EACjB,IAAI,EAAE,CAAC,MAAM,EAAE,WAAW,EAAE,UAAU,EAAE,MAAM,KAAK,OAAO,CAAC,CAAC,CAAC,GAC5D,OAAO,CAAC,CAAC,CAAC,CAoBZ;AAED,wBAAsB,YAAY,CAAC,CAAC,GAAG,OAAO,EAC5C,GAAG,EAAE,eAAe,EACpB,QAAQ,CAAC,EAAE,MAAM,GAChB,OAAO,CAAC,CAAC,CAAC,CAuEZ;AA6FD,sEAAsE;AACtE,wBAAgB,gBAAgB,CAAC,MAAM,EAAE,MAAM,GAAG,IAAI,GAAG,IAAI,CAAgC;AAM7F;;;wBAGwB;AACxB,wBAAgB,iBAAiB,CAAC,GAAG,EAAE,eAAe,EAAE,IAAI,CAAC,EAAE,MAAM,GAAG,OAAO,CAS9E;AA4GD,wBAAgB,wBAAwB,IAAI,IAAI,CAAkC;AAClF,wBAAgB,gBAAgB,IAAI,IAAI,CAA0B;AAClE,6EAA6E;AAC7E,wBAAgB,iCAAiC,IAAI,IAAI,CAA0D;AAuLnH,YAAY,EAAE,UAAU,EAAE,CAAC;AAC3B,OAAO,EAAE,oBAAoB,EAAE,oBAAoB,EAAE,6BAA6B,EAAE,CAAC;AAMrF,wBAAgB,UAAU,CAAC,IAAI,EAAE,MAAM,GAAG,IAAI,CAA0B;AAkBxE,wBAAgB,YAAY,CAAC,EAAE,EAAE,MAAM,GAAG,IAAI,CAA0B;AA07CxE,MAAM,WAAW,WAAW;IAC1B,EAAE,EAAE,MAAM,CAAC;IACX,IAAI,EAAE,MAAM,CAAC;IACb,QAAQ,EAAE,MAAM,CAAC;IACjB,MAAM,EAAE,cAAc,CAAC;IACvB,MAAM,EAAE,MAAM,CAAC;IACf,UAAU,EAAE,MAAM,CAAC;IACnB,MAAM,EAAE,MAAM,CAAC;IACf,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB,KAAK,CAAC,EAAE,QAAQ,GAAG,MAAM,CAAC;IAC1B,iBAAiB,CAAC,EAAE,yBAAyB,CAAC;IAC9C,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,OAAO,EAAE,OAAO,CAAC;IACjB,SAAS,EAAE,MAAM,CAAC;IAClB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,UAAU,CAAC,EAAE,IAAI,GAAG,OAAO,CAAC;IAC5B,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,MAAM,CAAC,EAAE;QAAE,KAAK,EAAE,MAAM,GAAG,IAAI,CAAC;QAAC,SAAS,EAAE,MAAM,CAAA;KAAE,CAAC;IACrD,OAAO,CAAC,EAAE,QAAQ,GAAG,OAAO,GAAG,WAAW,CAAC;IAC3C,MAAM,CAAC,EAAE,OAAO,CAAC;IACjB,cAAc,EAAE,MAAM,CAAC;CACxB;AAw4ED,wBAAgB,cAAc,CAAC,IAAI,EAAE;IACnC,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,EAAE,MAAM,CAAC;IACb;;;+EAG2E;IAC3E,YAAY,CAAC,EAAE,OAAO,CAAC;IACvB;;sDAEkD;IAClD,KAAK,CAAC,EAAE,OAAO,CAAC,IAAI,CAAC,CAAC;IACtB;;;;wCAIoC;IACpC,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB;;kFAE8E;IAC9E,oBAAoB,CAAC,EAAE,OAAO,CAAC;CAChC,GAAG,OAAO,CAAC,eAAe,CAAC,CA8D3B"}

package/dist/core/dashboard-ipc-server.js

@@ -1418,6 +1418,54 @@ function buildAsyncTriggerLookupResponse(sessionId, triggerId) {
     }
     const memTriggerId = triggerId || ds?.latestAsyncTriggerId;
     const memResult = ds && memTriggerId ? ds.asyncTriggerResults?.get(memTriggerId) : undefined;
+    // Best-effort poll-side convergence for the double-fault turn (codex #818 P1-8):
+    // the CONTRACT is that a double-fault returns 5xx and the caller retries with the
+    // same key (that retry path is the authoritative recovery). This block is only a
+    // bonus for a client that happens to poll first — if this turn is flagged
+    // postBarrierFault (post-barrier throw AND the durable terminalize then threw),
+    // nothing dispatched and no durable result exists, yet a live shared worker keeps
+    // `liveActive` true so resolveAsyncTriggerState would otherwise report `running`.
+    // Re-attempt the strict terminalize opportunistically; a persistent EIO simply
+    // falls through to `running` and is converged by a same-key retry or boot reconcile.
+    if (ds && memTriggerId) {
+        const faultEntry = ds.idempotentAsyncTurns?.get(memTriggerId);
+        if (faultEntry?.postBarrierFault) {
+            // COMPLETED-WINS (codex #818 P1-8 race): the AUTHORITATIVE decision is
+            // recordFailedStrict's IN-LOCK outcome (no TOCTOU). A pre-read fast-path
+            // avoids the write when already visibly completed; else the in-lock return
+            // (`already_completed` vs `written_failed`) decides. Never terminalize over a
+            // completion that landed after the pre-read.
+            const durable = asyncTriggerStore.lookup(sessionId, memTriggerId);
+            const ownedCompleted = durable?.result.status === 'completed'
+                && durable.ownerLarkAppId === faultEntry.ownerLarkAppId;
+            if (ownedCompleted) {
+                ds.idempotentAsyncTurns?.delete(memTriggerId);
+                // fall through to normal resolution → reports completed.
+            }
+            else {
+                try {
+                    const outcome = asyncTriggerStore.recordFailedStrict(sessionId, memTriggerId, Date.now(), faultEntry.ownerLarkAppId, 'dispatch_unknown');
+                    ds.idempotentAsyncTurns?.delete(memTriggerId);
+                    if (outcome === 'written_failed') {
+                        ds.asyncTriggerResults?.delete(memTriggerId);
+                        return {
+                            ok: true, state: 'failed', triggerId: memTriggerId,
+                            target: { kind: 'turn', sessionId, chatId: ds.chatId ?? stored?.chatId },
+                            errorCode: 'no_output',
+                            error: 'previous dispatch was interrupted with unknown outcome; not re-run (at-most-once)',
+                            message: 'async trigger terminated without output',
+                        };
+                    }
+                    // outcome === 'already_completed': a completion was seen under the lock —
+                    // fall through to normal resolution (which reports the completed result).
+                }
+                catch {
+                    // Genuine I/O failure — leave the flag for the next poll / retry / boot
+                    // reconcile; fall through to `running` rather than a phantom terminal.
+                }
+            }
+        }
+    }
     const resolved = resolveAsyncTriggerState({
         sessionId,
         liveActive: !!ds,