agent-tempo 1.7.0-beta.12 → 1.7.0-beta.13

package/dashboard/package.json

@@ -1,7 +1,7 @@
 {
   "name": "agent-tempo-dashboard",
   "private": true,
-  "version": "1.7.0-beta.12",
+  "version": "1.7.0-beta.13",
   "type": "module",
   "description": "Web dashboard for agent-tempo. Bundled into the npm package; served by the daemon at /dashboard/*.",
   "scripts": {

package/dist/activities/outbox.js

@@ -46,6 +46,7 @@ const git_info_1 = require("../git-info");
 const spawn_1 = require("../spawn");
 const config_2 = require("../config");
 const resolve_1 = require("./resolve");
+const visibility_deadline_1 = require("../utils/visibility-deadline");
 const action_counters_1 = require("../utils/action-counters");
 const search_attributes_1 = require("../utils/search-attributes");
 const agent_types_1 = require("../ensemble/agent-types");
@@ -86,6 +87,15 @@ function isRetryableTemporalError(err) {
     // to call unconditionally.
     if (err instanceof activity_1.ApplicationFailure)
         return false;
+    // #845 Mode A: a truncated visibility scan (resolveSession's deadline
+    // tripped mid-scan, #336/#529) is a LATENCY failure — the target may well
+    // exist; the scan just didn't finish. Treat it as transient so the
+    // activity retry policy re-runs resolveSession with a fresh 10s deadline
+    // (backoff-bounded) instead of collapsing it into a permanent
+    // "No active session found". This must NOT re-add an in-resolver retry
+    // loop — the bounding lives in Temporal's policy, not a hot-path scan.
+    if ((0, visibility_deadline_1.isVisibilityTimeout)(err))
+        return true;
     const e = err;
     const name = e?.name ?? '';
     const msg = e?.message ?? '';

package/dist/activities/resolve.d.ts

@@ -1,5 +1,13 @@
 import { Client, WorkflowHandle } from '@temporalio/client';
 import { AttachmentPhase } from '../types';
+/**
+ * Mode-B describe-by-id timeout (#845). The strongly-consistent
+ * `describe()` fallback on `resolveSession`'s not-found branch is a single
+ * O(1) RPC; 2s mirrors {@link DEFAULT_QUERY_TIMEOUT_MS} — two orders of
+ * magnitude over a healthy describe — so a wedged frontend can't re-hang
+ * the outbox loop the visibility deadline (#336/#529) was added to bound.
+ */
+export declare const RESOLVE_DESCRIBE_TIMEOUT_MS = 2000;
 /** Shared query for listing running session workflows. Exported for the
  *  ensemble-scoped variants in `client/core.ts` (#751). */
 export declare const SESSION_LIST_QUERY = "WorkflowType = \"agentSessionWorkflow\" AND ExecutionStatus = \"Running\"";
@@ -18,15 +26,36 @@ export declare const SESSION_LIST_QUERY = "WorkflowType = \"agentSessionWorkflow
  * in `scanEnsembleSessionsCloud`. Enforced by
  * tests/conformance/decision-path-fence.test.ts.
  *
- * **Deadline (#336/#529):** the visibility iterator is bounded by
- * `VISIBILITY_DEADLINES_MS.resolveSession` (default 10s). On timeout,
- * throws `VisibilityIteratorTimeoutError` rather than returning `null`
- * — silent `null` on a partially-scanned set would be indistinguishable
- * from "definitely not found," producing false "Player not found" errors
- * upstream. Every existing caller wraps this in a try/catch (outbox
- * activities, MCP tools' `defineTool` helper, CLI dev-verbs); the throw
- * propagates as a retryable / user-visible "lookup timed out" rather
- * than the misleading "player not found."
+ * **Mode A — deadline truncation (#336/#529):** the visibility iterator is
+ * bounded by `VISIBILITY_DEADLINES_MS.resolveSession` (default 10s). On
+ * timeout it throws `VisibilityIteratorTimeoutError` rather than returning
+ * `null` — silent `null` on a partially-scanned set would be
+ * indistinguishable from "definitely not found." The throw is classified
+ * **retryable** by the outbox activity (`isRetryableTemporalError`), so
+ * Temporal's activity retry policy re-runs the lookup with a fresh
+ * deadline rather than collapsing it to a permanent "player not found."
+ * Synchronous tool/CLI callers surface it as a distinct "resolution
+ * incomplete — retry," never "not found."
+ *
+ * **Mode B — visibility-index lag (#845):** `list()` can complete normally
+ * (no throw) yet miss a freshly-started workflow because the visibility
+ * index trails the workflow store (observed live as a 3/8→8/8 roster
+ * during post-restart worker warmup). An early-exhausting scan is NOT
+ * proof of absence. So on the not-found branch we do **exactly one**
+ * strongly-consistent `describe()` against the *derived* workflow id —
+ * an O(1) read by primary key that bypasses the lagging index. This is a
+ * point lookup, NOT a re-scan: it cannot re-introduce the unbounded-scan
+ * hang the deadline guard was added to prevent.
+ *
+ * **Documented Mode-B limitation:** the derived id
+ * `agent-session-{ensemble}-{playerName}` is minted from a player's
+ * INITIAL name at spawn; `set_name` does not change the workflow id. So
+ * describe-by-derived-id false-negatives for a player that was both
+ * RENAMED and is currently index-lagged — it falls back to `null` (looks
+ * absent) for that narrow intersection. Accepted by design: it closes the
+ * gap for the cold-boot/warmup incident class (nobody renames mid-boot),
+ * and a second full re-scan to cover renamed∩lagged would put scan cost on
+ * every genuine typo'd-name lookup. See issue #845.
  */
 export declare function resolveSession(client: Client, ensemble: string, playerName: string): Promise<WorkflowHandle | null>;
 /** Info returned for each session by scanEnsembleSessions. */
@@ -82,19 +111,55 @@ export interface EnsembleSessionInfo {
  */
 export declare function scanEnsembleSessionsCloud(client: Client, ensemble: string, log?: (...args: unknown[]) => void): Promise<EnsembleSessionInfo[]>;
 /**
- * Scan all running session workflows in an ensemble.
- * Returns metadata + part for each session. Shared by the ensemble MCP tool
- * and the Maestro refresh activity.
+ * Result of {@link scanEnsembleSessionsWithStatus} — the session rows plus
+ * whether the visibility scan completed or was cut short (#845).
+ *
+ * `truncated` is the Mode-A signal: a `VisibilityIteratorTimeoutError`
+ * fired (the wall-clock deadline tripped mid-scan), so `sessions` is a
+ * partial snapshot, NOT the full roster. Callers that render a roster (the
+ * `ensemble` tool) MUST surface this so a partial set is never mistaken
+ * for a complete one. NOTE: this does NOT cover Mode B (visibility-index
+ * lag) — there the scan completes normally and `truncated` is `false` even
+ * though a freshly-started workflow may be missing; that's best-effort by
+ * design and self-heals on the next tick.
+ *
+ * `scanned` is the number of running workflows the iterator visited before
+ * completing or timing out — useful for warn logs ("partial: 3 of ≥N").
+ */
+export interface EnsembleScanResult {
+    sessions: EnsembleSessionInfo[];
+    truncated: boolean;
+    scanned: number;
+}
+/**
+ * Scan all running session workflows in an ensemble, reporting whether the
+ * scan completed or was truncated by the visibility deadline (#845).
+ *
+ * This is the single source of truth for the local-profile ensemble scan;
+ * {@link scanEnsembleSessions} is a thin array-facade over it that drops
+ * the status fields for the many callers that don't need them.
  *
  * **Deadline (#336/#529):** the iterator is bounded by
- * `VISIBILITY_DEADLINES_MS.scanEnsembleSessions` (default 15s). On
- * timeout, returns the partial result accumulated so far and emits a
- * warn log. This site is **partial-tolerant by design** — the caller
- * (maestro refresh, ensemble MCP tool) treats the result as a
- * best-effort snapshot that the next tick / re-invocation will fill in.
+ * `VISIBILITY_DEADLINES_MS.scanEnsembleSessions` (default 15s). On timeout
+ * the accumulated rows are returned with `truncated: true` and a warn log
+ * — the scan is **partial-tolerant by design**, but the truncation is now
+ * SIGNALLED rather than silent so a roster renderer can flag it.
  *
  * T0.1 (#748): this legacy shape is the `costProfile: 'local'` path —
- * byte-identical to pre-#748 behavior. The cloud profile uses
+ * byte-identical row data to pre-#748 behavior. The cloud profile uses
  * {@link scanEnsembleSessionsCloud}.
  */
+export declare function scanEnsembleSessionsWithStatus(client: Client, ensemble: string, log?: (...args: unknown[]) => void): Promise<EnsembleScanResult>;
+/**
+ * Scan all running session workflows in an ensemble — array facade over
+ * {@link scanEnsembleSessionsWithStatus}.
+ *
+ * Returns just the session rows; the truncation/scan-status fields are
+ * dropped. This is the byte-identical shape the maestro refresh activity,
+ * the #785 upgrade-snapshot, and the other roster consumers already depend
+ * on — keeping it a thin delegate means the truncation-signalling work
+ * (#845) does NOT ripple through those call sites. Callers that need to
+ * know whether the scan was complete (the `ensemble` tool) call the rich
+ * sibling directly.
+ */
 export declare function scanEnsembleSessions(client: Client, ensemble: string, log?: (...args: unknown[]) => void): Promise<EnsembleSessionInfo[]>;

package/dist/activities/resolve.js

@@ -1,13 +1,23 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.SESSION_LIST_QUERY = void 0;
+exports.SESSION_LIST_QUERY = exports.RESOLVE_DESCRIBE_TIMEOUT_MS = void 0;
 exports.resolveSession = resolveSession;
 exports.scanEnsembleSessionsCloud = scanEnsembleSessionsCloud;
+exports.scanEnsembleSessionsWithStatus = scanEnsembleSessionsWithStatus;
 exports.scanEnsembleSessions = scanEnsembleSessions;
+const config_1 = require("../config");
 const search_attributes_1 = require("../utils/search-attributes");
 const signals_1 = require("../workflows/signals");
 const query_timeout_1 = require("../utils/query-timeout");
 const visibility_deadline_1 = require("../utils/visibility-deadline");
+/**
+ * Mode-B describe-by-id timeout (#845). The strongly-consistent
+ * `describe()` fallback on `resolveSession`'s not-found branch is a single
+ * O(1) RPC; 2s mirrors {@link DEFAULT_QUERY_TIMEOUT_MS} — two orders of
+ * magnitude over a healthy describe — so a wedged frontend can't re-hang
+ * the outbox loop the visibility deadline (#336/#529) was added to bound.
+ */
+exports.RESOLVE_DESCRIBE_TIMEOUT_MS = 2000;
 /** Shared query for listing running session workflows. Exported for the
  *  ensemble-scoped variants in `client/core.ts` (#751). */
 exports.SESSION_LIST_QUERY = `WorkflowType = "agentSessionWorkflow" AND ExecutionStatus = "Running"`;
@@ -26,15 +36,36 @@ exports.SESSION_LIST_QUERY = `WorkflowType = "agentSessionWorkflow" AND Executio
  * in `scanEnsembleSessionsCloud`. Enforced by
  * tests/conformance/decision-path-fence.test.ts.
  *
- * **Deadline (#336/#529):** the visibility iterator is bounded by
- * `VISIBILITY_DEADLINES_MS.resolveSession` (default 10s). On timeout,
- * throws `VisibilityIteratorTimeoutError` rather than returning `null`
- * — silent `null` on a partially-scanned set would be indistinguishable
- * from "definitely not found," producing false "Player not found" errors
- * upstream. Every existing caller wraps this in a try/catch (outbox
- * activities, MCP tools' `defineTool` helper, CLI dev-verbs); the throw
- * propagates as a retryable / user-visible "lookup timed out" rather
- * than the misleading "player not found."
+ * **Mode A — deadline truncation (#336/#529):** the visibility iterator is
+ * bounded by `VISIBILITY_DEADLINES_MS.resolveSession` (default 10s). On
+ * timeout it throws `VisibilityIteratorTimeoutError` rather than returning
+ * `null` — silent `null` on a partially-scanned set would be
+ * indistinguishable from "definitely not found." The throw is classified
+ * **retryable** by the outbox activity (`isRetryableTemporalError`), so
+ * Temporal's activity retry policy re-runs the lookup with a fresh
+ * deadline rather than collapsing it to a permanent "player not found."
+ * Synchronous tool/CLI callers surface it as a distinct "resolution
+ * incomplete — retry," never "not found."
+ *
+ * **Mode B — visibility-index lag (#845):** `list()` can complete normally
+ * (no throw) yet miss a freshly-started workflow because the visibility
+ * index trails the workflow store (observed live as a 3/8→8/8 roster
+ * during post-restart worker warmup). An early-exhausting scan is NOT
+ * proof of absence. So on the not-found branch we do **exactly one**
+ * strongly-consistent `describe()` against the *derived* workflow id —
+ * an O(1) read by primary key that bypasses the lagging index. This is a
+ * point lookup, NOT a re-scan: it cannot re-introduce the unbounded-scan
+ * hang the deadline guard was added to prevent.
+ *
+ * **Documented Mode-B limitation:** the derived id
+ * `agent-session-{ensemble}-{playerName}` is minted from a player's
+ * INITIAL name at spawn; `set_name` does not change the workflow id. So
+ * describe-by-derived-id false-negatives for a player that was both
+ * RENAMED and is currently index-lagged — it falls back to `null` (looks
+ * absent) for that narrow intersection. Accepted by design: it closes the
+ * gap for the cold-boot/warmup incident class (nobody renames mid-boot),
+ * and a second full re-scan to cover renamed∩lagged would put scan cost on
+ * every genuine typo'd-name lookup. See issue #845.
  */
 async function resolveSession(client, ensemble, playerName) {
     for await (const wf of (0, visibility_deadline_1.iterateWithDeadline)(client.workflow.list({ query: exports.SESSION_LIST_QUERY }), visibility_deadline_1.VISIBILITY_DEADLINES_MS.resolveSession, 'resolveSession')) {
@@ -49,16 +80,77 @@ async function resolveSession(client, ensemble, playerName) {
             }
         }
         catch (err) {
-            // Re-throw deadline timeouts — callers that wrap us in try/catch
-            // already treat unknown throws as a soft "lookup failed" path,
-            // and the typed error name makes the failure mode legible in
-            // outbox logs / user-facing tool errors.
+            // Re-throw deadline timeouts (Mode A) — callers that wrap us in
+            // try/catch treat the typed throw as a soft "lookup timed out" path,
+            // distinct from the not-found `null` below.
             if ((0, visibility_deadline_1.isVisibilityTimeout)(err))
                 throw err;
             // Workflow may have just completed, or worker is wedged (#433) — skip
         }
     }
-    return null;
+    // Mode B (#845): the scan completed without a match, but the visibility
+    // index may simply be lagging a just-started workflow. One strongly-
+    // consistent describe-by-derived-id disambiguates "index lag" from
+    // "genuinely absent" without a second scan.
+    return resolveByDerivedId(client, ensemble, playerName);
+}
+/**
+ * Mode-B (#845) strongly-consistent fallback for {@link resolveSession}.
+ *
+ * Reads the session workflow by its *derived* id
+ * (`agent-session-{ensemble}-{playerName}`) via a single bounded
+ * `describe()` — a primary-key lookup that bypasses the eventually-
+ * consistent visibility index. Returns the handle whenever the execution
+ * is `RUNNING`; otherwise `null` (genuinely absent, terminated/completed,
+ * renamed-false-negative, or describe timed out).
+ *
+ * Deliberately RUNNING-only — NO attachment-phase filter (#845 JC2): a
+ * `gone` player has a LIVE workflow with a terminal adapter, which the
+ * #822/#834 deliverability contract handles as warn-but-queue, not
+ * "not found". Filtering it here would regress #834 for the lagged-gone
+ * window and diverge from the main scan loop (which has no phase filter).
+ */
+async function resolveByDerivedId(client, ensemble, playerName) {
+    let timer;
+    try {
+        // `getHandle` is a lazy, no-RPC handle construction in the real client;
+        // kept inside the try purely so a defensive throw can never escape the
+        // fallback (it must only ever upgrade a null to a handle, never error).
+        const handle = client.workflow.getHandle((0, config_1.sessionWorkflowId)(ensemble, playerName));
+        const timeout = new Promise((_, reject) => {
+            timer = setTimeout(() => reject(new Error('describe-by-id timed out')), exports.RESOLVE_DESCRIBE_TIMEOUT_MS);
+            timer.unref?.();
+        });
+        const desc = await Promise.race([handle.describe(), timeout]);
+        // Only a live (RUNNING) execution is a valid resolve target. A
+        // COMPLETED/TERMINATED latest run at this id means the player is gone,
+        // or the id was reused by a since-closed run → null. A RUNNING run
+        // under a reused id is legitimately the current player → return it.
+        //
+        // No attachment-phase filter (#845 JC2, architect ruling): the main
+        // scan loop returns the handle for ANY running session — phase=`gone`
+        // included — and #822/#834 treat `gone` as warn-but-QUEUE (the cue
+        // durably queues and auto-redelivers on re-attach), NOT "not found".
+        // Returning null for a lagged-`gone` player would bypass #822, re-
+        // introduce the false-not-found #834 fixed, and make resolution depend
+        // on visibility-index timing. The "don't deliver to a torn-down
+        // adapter" concern lives at the deliverability layer, not here.
+        if (desc.status.name !== 'RUNNING')
+            return null;
+        return handle;
+    }
+    catch {
+        // NotFound → genuinely absent (or the renamed∩lagged false-negative
+        // documented on resolveSession). Timeout/other → treat as absent; the
+        // caller's not-found path (or the activity retry policy for Mode A)
+        // handles it. We never throw from the fallback — it can only upgrade a
+        // null to a found handle, never turn a clean lookup into an error.
+        return null;
+    }
+    finally {
+        if (timer)
+            clearTimeout(timer);
+    }
 }
 /**
  * T0.1 (#748) — cloud-profile ensemble scan. Observation path ONLY (see the
@@ -162,25 +254,30 @@ async function scanEnsembleSessionsCloud(client, ensemble, log = () => { }) {
     return sessions;
 }
 /**
- * Scan all running session workflows in an ensemble.
- * Returns metadata + part for each session. Shared by the ensemble MCP tool
- * and the Maestro refresh activity.
+ * Scan all running session workflows in an ensemble, reporting whether the
+ * scan completed or was truncated by the visibility deadline (#845).
+ *
+ * This is the single source of truth for the local-profile ensemble scan;
+ * {@link scanEnsembleSessions} is a thin array-facade over it that drops
+ * the status fields for the many callers that don't need them.
  *
  * **Deadline (#336/#529):** the iterator is bounded by
- * `VISIBILITY_DEADLINES_MS.scanEnsembleSessions` (default 15s). On
- * timeout, returns the partial result accumulated so far and emits a
- * warn log. This site is **partial-tolerant by design** — the caller
- * (maestro refresh, ensemble MCP tool) treats the result as a
- * best-effort snapshot that the next tick / re-invocation will fill in.
+ * `VISIBILITY_DEADLINES_MS.scanEnsembleSessions` (default 15s). On timeout
+ * the accumulated rows are returned with `truncated: true` and a warn log
+ * — the scan is **partial-tolerant by design**, but the truncation is now
+ * SIGNALLED rather than silent so a roster renderer can flag it.
  *
  * T0.1 (#748): this legacy shape is the `costProfile: 'local'` path —
- * byte-identical to pre-#748 behavior. The cloud profile uses
+ * byte-identical row data to pre-#748 behavior. The cloud profile uses
  * {@link scanEnsembleSessionsCloud}.
  */
-async function scanEnsembleSessions(client, ensemble, log = () => { }) {
+async function scanEnsembleSessionsWithStatus(client, ensemble, log = () => { }) {
     const sessions = [];
+    let truncated = false;
+    let scanned = 0;
     try {
         for await (const workflow of (0, visibility_deadline_1.iterateWithDeadline)(client.workflow.list({ query: exports.SESSION_LIST_QUERY }), visibility_deadline_1.VISIBILITY_DEADLINES_MS.scanEnsembleSessions, 'scanEnsembleSessions')) {
+            scanned++;
             try {
                 const handle = client.workflow.getHandle(workflow.workflowId);
                 // Issue #433 — bound the metadata + part queries so a single wedged
@@ -234,11 +331,27 @@ async function scanEnsembleSessions(client, ensemble, log = () => { }) {
     }
     catch (err) {
         if ((0, visibility_deadline_1.isVisibilityTimeout)(err)) {
+            truncated = true;
             log(`scanEnsembleSessions: ${err.message} — returning partial (${sessions.length} sessions)`);
         }
         else {
             throw err;
         }
     }
-    return sessions;
+    return { sessions, truncated, scanned };
+}
+/**
+ * Scan all running session workflows in an ensemble — array facade over
+ * {@link scanEnsembleSessionsWithStatus}.
+ *
+ * Returns just the session rows; the truncation/scan-status fields are
+ * dropped. This is the byte-identical shape the maestro refresh activity,
+ * the #785 upgrade-snapshot, and the other roster consumers already depend
+ * on — keeping it a thin delegate means the truncation-signalling work
+ * (#845) does NOT ripple through those call sites. Callers that need to
+ * know whether the scan was complete (the `ensemble` tool) call the rich
+ * sibling directly.
+ */
+async function scanEnsembleSessions(client, ensemble, log = () => { }) {
+    return (await scanEnsembleSessionsWithStatus(client, ensemble, log)).sessions;
 }

package/dist/cli/commands.js

@@ -65,6 +65,7 @@ const croner_1 = require("croner");
 const client_1 = require("@temporalio/client");
 const spawn_1 = require("../spawn");
 const probe_1 = require("../pi/probe");
+const install_1 = require("../pi/install");
 const config_1 = require("../config");
 const git_info_1 = require("../git-info");
 const connection_1 = require("../connection");
@@ -1318,10 +1319,33 @@ async function up(opts) {
         if (!process.env.ANTHROPIC_API_KEY) {
             out.warn('ANTHROPIC_API_KEY is not set — the Pi conductor will fall back to Pi\'s own auth/default model. Set it if Pi needs an Anthropic key.');
         }
+        // #825 — extension-registration guard (mirrors command-center's #820 Bug-2
+        // guard). `up --agent pi` no longer passes an inline `-e` (that risked a
+        // divergent-copy double-load, #825); it now relies on the player extension
+        // being registered in Pi's settings.json. On a box that never ran `install-pi`,
+        // a plain `pi` would launch with NO extension — no claim/heartbeat, a silent
+        // non-conductor (the #820 Bug-2 failure, transplanted to the conductor). So
+        // auto-install idempotently before spawning; fail loud with the manual command
+        // if the write fails. (Checks the GLOBAL settings.json, like command-center; a
+        // user who ran `install-pi --project` still works — `pi` loads the project
+        // path and the same realpath dedupes, so the redundant global install is a
+        // harmless idempotent write, never a second load.)
+        if (!(0, install_1.arePiExtensionsRegistered)()) {
+            try {
+                const result = (0, install_1.installPiExtensions)();
+                out.log(out.dim(`  Registered the Pi extensions in ${result.settingsPath} (first-run install-pi).`));
+            }
+            catch (err) {
+                out.error('Cannot start Pi conductor — the Pi extensions are not registered and auto-install failed: ' +
+                    `${err instanceof Error ? err.message : String(err)}. Run \`agent-tempo install-pi\` manually, then retry.`);
+                process.exit(1);
+            }
+        }
         let piSpawn;
         try {
-            // resolvePiInteractiveBinary / resolvePiExtensionPath throw fail-clean
-            // (Pi CLI missing / extension unbuilt) — caught here, no terminal launched.
+            // resolvePiInteractiveBinary throws fail-clean (Pi CLI missing) — caught
+            // here, no terminal launched. #825: no more `-e`/extension resolution — the
+            // player extension loads from settings.json, registered + guarded just above.
             piSpawn = (0, spawn_1.buildPiConductorSpawn)({
                 ensemble: opts.ensemble,
                 sessionName,

package/dist/spawn.d.ts

@@ -129,18 +129,6 @@ export declare function resolvePiInteractiveBinary(deps?: {
     cmd: string;
     args: string[];
 };
-/**
- * Resolve the absolute path to the BUNDLED `dist/pi/extension.js` for `pi -e <abs>`
- * (#666). Pi loads the BUILT CommonJS extension even in dev. Mirrors
- * {@link resolvePiPath}'s dev/prod `__dirname` split: prod `__dirname` = `dist/`
- * (→ `dist/pi/extension.js`); dev `__dirname` = `src/` (→ sibling `dist/pi/…`).
- * Existence-checked + fail-clean ("run npm run build"). Injectable for tests.
- */
-export declare function resolvePiExtensionPath(deps?: {
-    exists?: (p: string) => boolean;
-    isDev?: boolean;
-    baseDir?: string;
-}): string;
 /** Inputs for {@link buildPiConductorSpawn} (pure — unit-tested without spawning). */
 export interface PiConductorSpawnOpts {
     ensemble: string;
@@ -154,20 +142,28 @@ export interface PiConductorSpawnOpts {
     conductorTypeName?: string;
     /** Forwarded if set (warn-not-fail upstream when unset). */
     anthropicApiKey?: string;
-    /** Injectable resolvers (default to the real ones, which fail-clean on miss). */
+    /** Injectable binary resolver (defaults to the real one, which fails-clean on miss). */
     resolveBinary?: () => {
         cmd: string;
         args: string[];
     };
-    resolveExtension?: () => string;
 }
 /**
  * Build the interactive Pi conductor spawn spec — `{ cmd, args, env }` for
  * {@link launchInTerminal} (#666 C3). PURE + injectable so the env/args mapping is
- * unit-tested. The default resolvers THROW fail-clean (binary missing / extension
- * unbuilt) BEFORE a terminal is launched. `args` = `[...binArgs, '-e', <ext>]`;
- * conductor INSTRUCTIONS arrive via the lineup-baked workflow messages → cue pump
- * (no `--system-prompt` for the MVP).
+ * unit-tested. The default binary resolver THROWS fail-clean (binary missing)
+ * BEFORE a terminal is launched.
+ *
+ * #825 — NO inline `-e <ext>`. `up --agent pi` now relies on the player extension
+ * being registered in Pi's `settings.json` (by `installPiExtensions`, guarded
+ * before launch in the `up` pi branch) + the `resolvePiRole`→`'player'` gate
+ * (`PLAYER_NAME` is set in the env below). This collapses the two Pi-launch paths
+ * onto ONE registration source, so no divergent on-disk copy (e.g. dev `node
+ * dist/cli.js`'s repo `dist/pi/extension.js` vs the global settings.json copy) can
+ * escape Pi's realpath-dedup and double-load the player factory. Mirrors
+ * {@link buildPiCommandCenterSpawn}. `args` = `[...binArgs]`; conductor
+ * INSTRUCTIONS arrive via the lineup-baked workflow messages → cue pump (no
+ * `--system-prompt` for the MVP).
  */
 export declare function buildPiConductorSpawn(opts: PiConductorSpawnOpts): {
     cmd: string;
@@ -196,11 +192,19 @@ export interface PiCommandCenterSpawnOpts {
  * Build the interactive Pi COMMAND-CENTER (mission-control) spawn spec —
  * `{ cmd, args, env }` for {@link launchInTerminal} (#729). PURE + injectable.
  *
- * Unlike {@link buildPiConductorSpawn}, this passes NO `-e <ext>`: install-pi
- * registers BOTH Pi extensions in `~/.pi/agent/settings.json`, so a plain `pi`
- * auto-loads them and {@link resolvePiRole} (via the env below) picks exactly one.
- * Passing `-e` here would DOUBLE-LOAD mission-control (settings.json + `-e`) → a
- * command re-registration error. The env carries the OPERATOR subset only:
+ * Like {@link buildPiConductorSpawn} (post-#825), this passes NO `-e <ext>`:
+ * install-pi registers BOTH Pi extensions in `~/.pi/agent/settings.json`, so a
+ * plain `pi` auto-loads them and {@link resolvePiRole} (via the env below) picks
+ * exactly one.
+ *
+ * #825 (comment correction): a SAME-path `-e` would NOT cause a re-registration
+ * error — the #825 spike found Pi realpath-dedupes CLI `-e` paths against
+ * `settings.json` (`mergePaths` → `canonicalizePath`/`realpathSync`), and even an
+ * un-deduped duplicate is first-registration-wins at the tool layer (no throw,
+ * Pi 0.79.x). The real reason both spawn specs OMIT `-e` is a SINGLE registration
+ * source: it prevents a DIVERGENT on-disk copy (a different physical path that
+ * escapes realpath-dedup) from double-loading the extension factory. The env
+ * carries the OPERATOR subset only:
  *   - `AGENT_TEMPO_PI_ROLE=command-center` → the DETERMINISTIC role force (top of
  *     {@link resolvePiRole}'s precedence — beats an inherited `PLAYER_NAME`).
  *   - `AGENT_TEMPO_MISSION_CONTROL=1` → the role opt-in (kept for legacy parity /

package/dist/spawn.js

@@ -14,7 +14,6 @@ exports.buildTerminalCommand = buildTerminalCommand;
 exports.launchInTerminal = launchInTerminal;
 exports.spawnInTerminal = spawnInTerminal;
 exports.resolvePiInteractiveBinary = resolvePiInteractiveBinary;
-exports.resolvePiExtensionPath = resolvePiExtensionPath;
 exports.buildPiConductorSpawn = buildPiConductorSpawn;
 exports.buildPiCommandCenterSpawn = buildPiCommandCenterSpawn;
 exports.spawnCopilotBridge = spawnCopilotBridge;
@@ -305,7 +304,18 @@ function writeSecretEnvFile(secretEnv, opts) {
         content = keys.map((k) => `set -gx ${k} ${fishQuote(secretEnv[k])}`).join('\n') + '\n';
     }
     else if (opts.syntax === 'cmd') {
-        content = keys.map((k) => `set "${k}=${cmdEscape(secretEnv[k])}"`).join('\r\n') + '\r\n';
+        // #847 — `@`-prefix EVERY line at the GENERATOR level (a structural map, not a
+        // per-line author choice). cmd `call`s this file into the persistent `cmd /k`
+        // session under its default echo-ON, which echoes each line of a called batch
+        // FILE to the terminal — so an un-prefixed `set "ANTHROPIC_API_KEY=…"` printed
+        // the SECRET VALUE to scrollback (the #847 leak; #689 had closed only the
+        // command-line/history vector). The per-line `@` is self-contained: unlike
+        // `@echo off`, it does NOT persist echo state to the caller (`call` shares the
+        // parent echo scope, and neither `call` nor `setlocal` scopes echo), so the
+        // trailing `del`, the bin launch, and the user's prompt still echo normally.
+        // Mapping at the generator means any FUTURE non-`set` line is suppressed too.
+        const lines = keys.map((k) => `set "${k}=${cmdEscape(secretEnv[k])}"`);
+        content = lines.map((line) => `@${line}`).join('\r\n') + '\r\n';
     }
     else {
         content = keys.map((k) => `export ${k}=${shellQuote(secretEnv[k])}`).join('\n') + '\n';
@@ -627,37 +637,27 @@ function resolvePiInteractiveBinary(deps = {}) {
     throw new Error('Pi CLI not found. Install it with `npm install -g pi-ai` and ensure `pi` is on PATH ' +
         '(or add the @earendil-works/pi-coding-agent package). The conductor needs the interactive Pi CLI.');
 }
-/**
- * Resolve the absolute path to the BUNDLED `dist/pi/extension.js` for `pi -e <abs>`
- * (#666). Pi loads the BUILT CommonJS extension even in dev. Mirrors
- * {@link resolvePiPath}'s dev/prod `__dirname` split: prod `__dirname` = `dist/`
- * (→ `dist/pi/extension.js`); dev `__dirname` = `src/` (→ sibling `dist/pi/…`).
- * Existence-checked + fail-clean ("run npm run build"). Injectable for tests.
- */
-function resolvePiExtensionPath(deps = {}) {
-    const exists = deps.exists ?? fs_1.existsSync;
-    const isDev = deps.isDev ?? __filename.endsWith('.ts');
-    const base = deps.baseDir ?? __dirname;
-    const extPath = isDev
-        ? (0, path_1.resolve)(base, '..', 'dist', 'pi', 'extension.js') // dev: src/ → repo/dist/pi/extension.js
-        : (0, path_1.resolve)(base, 'pi', 'extension.js'); // prod: dist/ → dist/pi/extension.js
-    if (!exists(extPath)) {
-        throw new Error(`Pi conductor extension not found at ${extPath}. Run \`npm run build\` first.`);
-    }
-    return extPath;
-}
 /**
  * Build the interactive Pi conductor spawn spec — `{ cmd, args, env }` for
  * {@link launchInTerminal} (#666 C3). PURE + injectable so the env/args mapping is
- * unit-tested. The default resolvers THROW fail-clean (binary missing / extension
- * unbuilt) BEFORE a terminal is launched. `args` = `[...binArgs, '-e', <ext>]`;
- * conductor INSTRUCTIONS arrive via the lineup-baked workflow messages → cue pump
- * (no `--system-prompt` for the MVP).
+ * unit-tested. The default binary resolver THROWS fail-clean (binary missing)
+ * BEFORE a terminal is launched.
+ *
+ * #825 — NO inline `-e <ext>`. `up --agent pi` now relies on the player extension
+ * being registered in Pi's `settings.json` (by `installPiExtensions`, guarded
+ * before launch in the `up` pi branch) + the `resolvePiRole`→`'player'` gate
+ * (`PLAYER_NAME` is set in the env below). This collapses the two Pi-launch paths
+ * onto ONE registration source, so no divergent on-disk copy (e.g. dev `node
+ * dist/cli.js`'s repo `dist/pi/extension.js` vs the global settings.json copy) can
+ * escape Pi's realpath-dedup and double-load the player factory. Mirrors
+ * {@link buildPiCommandCenterSpawn}. `args` = `[...binArgs]`; conductor
+ * INSTRUCTIONS arrive via the lineup-baked workflow messages → cue pump (no
+ * `--system-prompt` for the MVP).
  */
 function buildPiConductorSpawn(opts) {
     const { cmd, args: binArgs } = (opts.resolveBinary ?? resolvePiInteractiveBinary)();
-    const extPath = (opts.resolveExtension ?? resolvePiExtensionPath)();
-    const args = [...binArgs, '-e', extPath];
+    // #825 — single registration source: no inline `-e` (see the doc-comment above).
+    const args = [...binArgs];
     const env = {
         ...opts.temporalEnvVars,
         [config_1.ENV.TASK_QUEUE]: opts.taskQueue,
@@ -678,11 +678,19 @@ function buildPiConductorSpawn(opts) {
  * Build the interactive Pi COMMAND-CENTER (mission-control) spawn spec —
  * `{ cmd, args, env }` for {@link launchInTerminal} (#729). PURE + injectable.
  *
- * Unlike {@link buildPiConductorSpawn}, this passes NO `-e <ext>`: install-pi
- * registers BOTH Pi extensions in `~/.pi/agent/settings.json`, so a plain `pi`
- * auto-loads them and {@link resolvePiRole} (via the env below) picks exactly one.
- * Passing `-e` here would DOUBLE-LOAD mission-control (settings.json + `-e`) → a
- * command re-registration error. The env carries the OPERATOR subset only:
+ * Like {@link buildPiConductorSpawn} (post-#825), this passes NO `-e <ext>`:
+ * install-pi registers BOTH Pi extensions in `~/.pi/agent/settings.json`, so a
+ * plain `pi` auto-loads them and {@link resolvePiRole} (via the env below) picks
+ * exactly one.
+ *
+ * #825 (comment correction): a SAME-path `-e` would NOT cause a re-registration
+ * error — the #825 spike found Pi realpath-dedupes CLI `-e` paths against
+ * `settings.json` (`mergePaths` → `canonicalizePath`/`realpathSync`), and even an
+ * un-deduped duplicate is first-registration-wins at the tool layer (no throw,
+ * Pi 0.79.x). The real reason both spawn specs OMIT `-e` is a SINGLE registration
+ * source: it prevents a DIVERGENT on-disk copy (a different physical path that
+ * escapes realpath-dedup) from double-loading the extension factory. The env
+ * carries the OPERATOR subset only:
  *   - `AGENT_TEMPO_PI_ROLE=command-center` → the DETERMINISTIC role force (top of
  *     {@link resolvePiRole}'s precedence — beats an inherited `PLAYER_NAME`).
  *   - `AGENT_TEMPO_MISSION_CONTROL=1` → the role opt-in (kept for legacy parity /

package/dist/tools/cue.js

@@ -10,6 +10,7 @@ const resolve_1 = require("./resolve");
 const resolve_2 = require("../activities/resolve");
 const signals_1 = require("../workflows/signals");
 const query_timeout_1 = require("../utils/query-timeout");
+const visibility_deadline_1 = require("../utils/visibility-deadline");
 const descriptor_1 = require("./descriptor");
 const validation_1 = require("../utils/validation");
 const suspension_1 = require("../utils/suspension");
@@ -139,6 +140,17 @@ function buildCueTool(client, config, getPlayerId, handle) {
                 return (0, descriptor_1.ok)(`Message sent to ${playerId}. (outbox: ${entryId})`);
             }
             catch (err) {
+                // #845 Mode A: a truncated roster scan is NOT "player not found" —
+                // the target may exist; the visibility scan just hit its deadline
+                // (e.g. post-restart worker warmup). Surface a DISTINCT, actionable
+                // "resolution incomplete — retry" so the operator doesn't conclude
+                // the player vanished. (The `if (!resolved)` not-found path above
+                // only fires on a clean `null`; the timeout throws past it to here.)
+                if ((0, visibility_deadline_1.isVisibilityTimeout)(err)) {
+                    return (0, descriptor_1.fail)(`Could not resolve "${playerId}": roster resolution incomplete — the ` +
+                        `visibility scan hit its deadline (likely worker warmup), not a ` +
+                        `"player not found". Retry in a moment.`);
+                }
                 return (0, descriptor_1.fail)(`Failed to send message to ${playerId}: ${(0, descriptor_1.formatError)(err)}`);
             }
         },

package/dist/tools/ensemble.js

@@ -42,6 +42,7 @@ const resolve_1 = require("../activities/resolve");
 const descriptor_1 = require("./descriptor");
 const duration_1 = require("../utils/duration");
 const suspension_1 = require("../utils/suspension");
+const visibility_deadline_1 = require("../utils/visibility-deadline");
 /**
  * Default dormancy threshold (1 hour). Per #563: a `detached` player whose
  * last activity is older than this is considered dormant. `phase === 'gone'`
@@ -102,12 +103,29 @@ function buildEnsembleTool(client, config, getPlayerId, ownWorkflowId) {
                 self: client.workflow.getHandle(ownWorkflowId),
             });
             let sessions;
+            let truncated = false;
+            let scanned = 0;
             try {
-                sessions = await (0, resolve_1.scanEnsembleSessions)(client, config.ensemble);
+                const scan = await (0, resolve_1.scanEnsembleSessionsWithStatus)(client, config.ensemble);
+                sessions = scan.sessions;
+                truncated = scan.truncated;
+                scanned = scan.scanned;
             }
             catch (err) {
                 return (0, descriptor_1.fail)(`Error listing workflows: ${(0, descriptor_1.formatError)(err)}`);
             }
+            // #845 Mode A — when the visibility scan hit its wall-clock deadline,
+            // `sessions` is a PARTIAL roster. Surface that explicitly so an
+            // operator never mistakes a mid-scan snapshot for the full ensemble
+            // (the incident: a 3/8 roster read as "5 players vanished"). Report
+            // `scanned` (workflows enumerated before the deadline) rather than the
+            // shown-row count — the shown count is post scope/dormancy filtering,
+            // so "N shown" would understate how far the scan actually got.
+            const partialBanner = truncated
+                ? `⚠ partial roster — ${scanned} workflow(s) enumerated before the ` +
+                    `${Math.round(visibility_deadline_1.VISIBILITY_DEADLINES_MS.scanEnsembleSessions / 1000)}s visibility deadline ` +
+                    `(likely worker warmup); some players may be missing — re-run to refresh.`
+                : undefined;
             // Apply scope filters
             let ownGitRoot;
             if (scope === 'repo') {
@@ -138,12 +156,25 @@ function buildEnsembleTool(client, config, getPlayerId, ownWorkflowId) {
             // #752: PAUSED/HELD banner leads the output so it can't be missed.
             const banner = (0, suspension_1.formatSuspensionBanner)(await suspensionPromise, config.ensemble);
             if (active.length === 0 && dormant.length === 0) {
+                // #845 CRITICAL: check truncation FIRST. A truncated scan that
+                // yielded zero rows must NOT render as "No active sessions found" —
+                // false-empty is the most dangerous case (an operator concludes the
+                // whole ensemble died and takes destructive action). Surface the
+                // partial banner instead.
+                if (partialBanner) {
+                    return (0, descriptor_1.ok)([banner, partialBanner].filter(Boolean).join('\n\n'));
+                }
                 return (0, descriptor_1.ok)(banner ? `${banner}\n\nNo active sessions found.` : 'No active sessions found.');
             }
             // #563 summary line — surface both counts so operators can see what's
             // being hidden behind the dormant filter without re-running.
             const summary = `**${config.ensemble}**: ${active.length} active, ${dormant.length} dormant`;
-            const sections = banner ? [banner, summary] : [summary];
+            // Lead banners (suspension #752 + partial-roster #845) precede the
+            // summary so neither can be missed above the roster.
+            const sections = [
+                ...[banner, partialBanner].filter(Boolean),
+                summary,
+            ];
             const showActive = dormantFilter !== 'show-only';
             const showDormant = dormantFilter !== 'hide';
             if (showActive) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-tempo",
-  "version": "1.7.0-beta.12",
+  "version": "1.7.0-beta.13",
   "description": "Many agents, one tempo. Durable coordination for multi-agent work via Temporal.",
   "keywords": [
     "mcp",