@integrity-labs/agt-cli 0.28.572 → 0.28.573

package/dist/{chunk-NG2MFOSH.js → chunk-GW2JI7NO.js}

@@ -46,7 +46,7 @@ import {
   resolveConnectivityProbe,
   worseConnectivityOutcome,
   wrapScheduledTaskPrompt
-} from "./chunk-72K46XUZ.js";
+} from "./chunk-5Z6RJ3RX.js";
 import {
   parsePsRows
 } from "./chunk-XWVM4KPK.js";
@@ -5646,7 +5646,7 @@ function exchangeFailureKind(err) {
 }
 
 // src/lib/api-client.ts
-var agtCliVersion = true ? "0.28.572" : "dev";
+var agtCliVersion = true ? "0.28.573" : "dev";
 var lastConfigHash = null;
 function setConfigHash(hash) {
   lastConfigHash = hash && hash.length > 0 ? hash : null;
@@ -9011,4 +9011,4 @@ export {
   managerInstallSystemUnitCommand,
   managerUninstallSystemUnitCommand
 };
-//# sourceMappingURL=chunk-NG2MFOSH.js.map
+//# sourceMappingURL=chunk-GW2JI7NO.js.map

package/dist/{claude-pair-runtime-XTRJNDP2.js → claude-pair-runtime-T4ZR7AJU.js}

@@ -100,7 +100,7 @@ async function spawnPairSession(session) {
     return { ok: true };
   } catch {
   }
-  const { resolveClaudeBinary } = await import("./persistent-session-74MH2XTM.js");
+  const { resolveClaudeBinary } = await import("./persistent-session-6UGFGI6J.js");
   const claudeBin = resolveClaudeBinary();
   const pairEnv = {
     ...process.env,
@@ -373,4 +373,4 @@ export {
   startClaudePair,
   submitClaudePairCode
 };
-//# sourceMappingURL=claude-pair-runtime-XTRJNDP2.js.map
+//# sourceMappingURL=claude-pair-runtime-T4ZR7AJU.js.map

package/dist/lib/manager-worker.js

@@ -53,7 +53,7 @@ import {
   safeWriteJsonAtomic,
   setConfigHash,
   tripClass
-} from "../chunk-NG2MFOSH.js";
+} from "../chunk-GW2JI7NO.js";
 import {
   getProjectDir as getProjectDir2,
   getReadyTasks,
@@ -182,7 +182,7 @@ import {
   toOpencodeModel,
   transcriptActivityAgeSeconds,
   writeEgressAllowlist
-} from "../chunk-72K46XUZ.js";
+} from "../chunk-5Z6RJ3RX.js";
 import {
   reapOrphanChannelMcps
 } from "../chunk-XWVM4KPK.js";
@@ -11588,7 +11588,7 @@ var agentRestartTimezoneInputs = /* @__PURE__ */ new Map();
 var lastVersionCheckAt = 0;
 var VERSION_CHECK_INTERVAL_MS = 5 * 60 * 1e3;
 var lastResponsivenessProbeAt = 0;
-var agtCliVersion = true ? "0.28.572" : "dev";
+var agtCliVersion = true ? "0.28.573" : "dev";
 function resolveBrewPath(execFileSync2) {
   try {
     const out = execFileSync2("which", ["brew"], { timeout: 5e3 }).toString().trim();
@@ -12895,7 +12895,7 @@ function flushRestartedAgentDiagnostics(hostId, codeNames) {
   if (codeNames.length === 0) return;
   void (async () => {
     try {
-      const { collectDiagnostics } = await import("../persistent-session-74MH2XTM.js");
+      const { collectDiagnostics } = await import("../persistent-session-6UGFGI6J.js");
       await api.post("/host/heartbeat", {
         host_id: hostId,
         agent_diagnostics: collectDiagnostics(codeNames, quarantineEntriesFor, claudeMdSizeFor, spawnOutcomeForDiagnostics)
@@ -13003,7 +13003,7 @@ async function pollCycle() {
     }
     try {
       const { detectHostSecurity } = await import("../host-security-6PDFG7F5.js");
-      const { collectDiagnostics } = await import("../persistent-session-74MH2XTM.js");
+      const { collectDiagnostics } = await import("../persistent-session-6UGFGI6J.js");
       const diagCodeNames = [...agentState.persistentSessionAgents];
       const agentDiagnostics = diagCodeNames.length > 0 ? collectDiagnostics(diagCodeNames, quarantineEntriesFor, claudeMdSizeFor, spawnOutcomeForDiagnostics) : void 0;
       let tailscaleHostname;
@@ -13126,7 +13126,7 @@ async function pollCycle() {
         collectPanelessActivityProbes,
         getResponsivenessIntervalMs,
         occupancyQualificationClassifications
-      } = await import("../responsiveness-probe-5VNQQZNJ.js");
+      } = await import("../responsiveness-probe-O7AVC73R.js");
       const probeIntervalMs = getResponsivenessIntervalMs();
       if (now - lastResponsivenessProbeAt > probeIntervalMs) {
         const probeCodeNames = [...agentState.persistentSessionAgents];
@@ -13217,7 +13217,7 @@ async function pollCycle() {
           collectResponsivenessProbes,
           livePendingInboundOldestAgeSeconds,
           parkPendingInbound
-        } = await import("../responsiveness-probe-5VNQQZNJ.js");
+        } = await import("../responsiveness-probe-O7AVC73R.js");
         const { getProjectDir: wedgeProjectDir } = await import("../scheduler-engine-NDP36U7O.js");
         const wedgeNow = /* @__PURE__ */ new Date();
         const liveAgents = agentState.persistentSessionAgents;
@@ -16787,7 +16787,7 @@ async function handleRestartDoorbell(agentId, requestedAt, restartReason) {
     void api.post("/host/restart-ack", { host_id: hostId, agent_id: agentId, restart_requested_at: requestedAt }).catch((err) => log(`[restart-lane] ack failed for '${codeName}': ${err.message}`));
     void (async () => {
       try {
-        const { collectDiagnostics } = await import("../persistent-session-74MH2XTM.js");
+        const { collectDiagnostics } = await import("../persistent-session-6UGFGI6J.js");
         await api.post("/host/heartbeat", {
           host_id: hostId,
           agent_diagnostics: collectDiagnostics([codeName], quarantineEntriesFor, claudeMdSizeFor, spawnOutcomeForDiagnostics)
@@ -16838,7 +16838,7 @@ async function respawnAgentAfterMcpStop(codeName, reason) {
     }
     try {
       const hostId = await getHostId();
-      const { collectDiagnostics } = await import("../persistent-session-74MH2XTM.js");
+      const { collectDiagnostics } = await import("../persistent-session-6UGFGI6J.js");
       await api.post("/host/heartbeat", {
         host_id: hostId,
         agent_diagnostics: collectDiagnostics([codeName], quarantineEntriesFor, claudeMdSizeFor, spawnOutcomeForDiagnostics)
@@ -17416,7 +17416,7 @@ async function processClaudePairSessions(agents) {
     killPairSession,
     pairTmuxSession,
     finalizeClaudePairOnboarding
-  } = await import("../claude-pair-runtime-XTRJNDP2.js");
+  } = await import("../claude-pair-runtime-T4ZR7AJU.js");
   for (const pairId of pendingResp.cancelled_pair_ids ?? []) {
     log(`[claude-pair] sweeping orphan tmux session for pair ${pairId.slice(0, 8)}`);
     const killed = await killPairSession(pairTmuxSession(pairId));

package/dist/mcp/direct-chat-channel.js

@@ -35213,7 +35213,7 @@ var FLAG_REGISTRY = [
   },
   {
     key: "direct-chat-per-user",
-    description: "Scope a STANDARD agent's Direct Chat to the user who had the conversation (ENG-8712). Today two teammates who open the same agent land in the same thread and read each other's messages: the /recent and per-session reads carry no user predicate unless the agent is the per-org system_support concierge. When on, both reads return only sessions the requester authored in PLUS sessions no user has authored in \u2014 the second arm is load-bearing, since every server-originated row (kanban and scheduled-task nudges, integration failures, HITL approvals, degradation alerts) is written as role=user with no user_id and would otherwise vanish from every console (ENG-8431). Does NOT make the thread private in the live direction: assistant replies still fan out on the per-TEAM realtime topic direct-chat-agent:{agentId}, so a teammate holding the drawer open still receives them. Narrowing that topic is follow-up work.",
+    description: "Scope a STANDARD agent's Direct Chat to the user who had the conversation (ENG-8712). Today two teammates who open the same agent land in the same thread and read each other's messages: the /recent and per-session reads carry no user predicate unless the agent is the per-org system_support concierge. When on, both reads return only sessions the requester authored in PLUS sessions no user has authored in \u2014 the second arm is load-bearing, since every server-originated row (kanban and scheduled-task nudges, integration failures, HITL approvals, degradation alerts) is written as role=user with no user_id and would otherwise vanish from every console (ENG-8431). Does NOT by itself make the thread private in the live direction: assistant replies fan out on the per-TEAM realtime topic direct-chat-agent:{agentId}, so a teammate holding the drawer open still receives them. That half is direct-chat-live-per-user (ENG-8760), which is a SEPARATE flag on purpose \u2014 turn both on for a private thread.",
     flagType: "boolean",
     // Declared safe value is `false` — today's team-wide thread. Server-side only
     // (the two reads in routes/agents.ts); the browser needs no knowledge of it,
@@ -35226,6 +35226,27 @@ var FLAG_REGISTRY = [
     // backfill in migration 20260812000006 is not reversed by the flag.
     defaultValue: false
   },
+  {
+    key: "direct-chat-live-per-user",
+    description: "The LIVE half of per-user Direct Chat (ENG-8760). direct-chat-per-user scoped the two REST reads; assistant replies kept fanning out on the per-TEAM realtime topic direct-chat-agent:{agentId}, whose RLS (20260804000003) has no session and no user predicate \u2014 so a teammate holding the drawer open still received another member's replies live, and only a reload hid them. When on, a reply in a session a human has authored in is broadcast to direct-chat-user:{agentId}:{userId} instead, whose policy (20260812000009) pins the third segment to auth.uid(). Sessions NO human has authored in \u2014 the agent's inbound work queue: kanban and scheduled-task nudges, integration failures, HITL approvals, degradation alerts \u2014 keep going to the per-TEAM topic, matching arm 2 of the REST read, or this would repeat ENG-8431 in the live lane. Also admits the system_support concierge to the per-user topic, which the per-TEAM topic denies outright (its live delivery is additive here, never narrowed).",
+    flagType: "boolean",
+    // Declared safe value is `false` — today's per-TEAM fan-out, byte for byte,
+    // for every agent kind including the concierge. Server-side only: the browser
+    // subscribes to BOTH topics unconditionally and needs no knowledge of the
+    // flag, so NOT public — which is also what keeps client and server from
+    // disagreeing about it. No envVar: an org/team-scoped rollout gate with no
+    // host-side consumer, and a declared envVar pinned in sst.config.ts would
+    // make every admin-UI override unreachable (ENG-8303).
+    //
+    // DELIBERATELY INDEPENDENT of direct-chat-per-user. The two are separable in
+    // both directions and neither ordering is unsafe: this one alone narrows live
+    // delivery below what the REST read still serves (a teammate can load the
+    // thread but stops receiving it live), and that one alone is the state
+    // ENG-8712 shipped. Coupling them into one switch would have removed the
+    // ability to soak the live change on an org that is already comfortable with
+    // the read change.
+    defaultValue: false
+  },
   {
     key: "onboarding-auto-deploy",
     description: `Auto-deploy the first agent during onboarding (ENG-7378): the agent edit page's Deploy & Test tab fires the existing deploy (draft -> active) automatically once the agent's host is fully deployed (active + manager heartbeating, not provisioning) AND Claude-authenticated (claude_auth_status=valid), replacing the manual "Deploy Agent" click in the recruit funnel. Only draft, non-system_support agents; a failed or timed-out attempt falls back to the manual button (no auto-retry loop).`,

package/dist/mcp/origami.js

@@ -41104,7 +41104,7 @@ var FLAG_REGISTRY = [
   },
   {
     key: "direct-chat-per-user",
-    description: "Scope a STANDARD agent's Direct Chat to the user who had the conversation (ENG-8712). Today two teammates who open the same agent land in the same thread and read each other's messages: the /recent and per-session reads carry no user predicate unless the agent is the per-org system_support concierge. When on, both reads return only sessions the requester authored in PLUS sessions no user has authored in \u2014 the second arm is load-bearing, since every server-originated row (kanban and scheduled-task nudges, integration failures, HITL approvals, degradation alerts) is written as role=user with no user_id and would otherwise vanish from every console (ENG-8431). Does NOT make the thread private in the live direction: assistant replies still fan out on the per-TEAM realtime topic direct-chat-agent:{agentId}, so a teammate holding the drawer open still receives them. Narrowing that topic is follow-up work.",
+    description: "Scope a STANDARD agent's Direct Chat to the user who had the conversation (ENG-8712). Today two teammates who open the same agent land in the same thread and read each other's messages: the /recent and per-session reads carry no user predicate unless the agent is the per-org system_support concierge. When on, both reads return only sessions the requester authored in PLUS sessions no user has authored in \u2014 the second arm is load-bearing, since every server-originated row (kanban and scheduled-task nudges, integration failures, HITL approvals, degradation alerts) is written as role=user with no user_id and would otherwise vanish from every console (ENG-8431). Does NOT by itself make the thread private in the live direction: assistant replies fan out on the per-TEAM realtime topic direct-chat-agent:{agentId}, so a teammate holding the drawer open still receives them. That half is direct-chat-live-per-user (ENG-8760), which is a SEPARATE flag on purpose \u2014 turn both on for a private thread.",
     flagType: "boolean",
     // Declared safe value is `false` — today's team-wide thread. Server-side only
     // (the two reads in routes/agents.ts); the browser needs no knowledge of it,
@@ -41117,6 +41117,27 @@ var FLAG_REGISTRY = [
     // backfill in migration 20260812000006 is not reversed by the flag.
     defaultValue: false
   },
+  {
+    key: "direct-chat-live-per-user",
+    description: "The LIVE half of per-user Direct Chat (ENG-8760). direct-chat-per-user scoped the two REST reads; assistant replies kept fanning out on the per-TEAM realtime topic direct-chat-agent:{agentId}, whose RLS (20260804000003) has no session and no user predicate \u2014 so a teammate holding the drawer open still received another member's replies live, and only a reload hid them. When on, a reply in a session a human has authored in is broadcast to direct-chat-user:{agentId}:{userId} instead, whose policy (20260812000009) pins the third segment to auth.uid(). Sessions NO human has authored in \u2014 the agent's inbound work queue: kanban and scheduled-task nudges, integration failures, HITL approvals, degradation alerts \u2014 keep going to the per-TEAM topic, matching arm 2 of the REST read, or this would repeat ENG-8431 in the live lane. Also admits the system_support concierge to the per-user topic, which the per-TEAM topic denies outright (its live delivery is additive here, never narrowed).",
+    flagType: "boolean",
+    // Declared safe value is `false` — today's per-TEAM fan-out, byte for byte,
+    // for every agent kind including the concierge. Server-side only: the browser
+    // subscribes to BOTH topics unconditionally and needs no knowledge of the
+    // flag, so NOT public — which is also what keeps client and server from
+    // disagreeing about it. No envVar: an org/team-scoped rollout gate with no
+    // host-side consumer, and a declared envVar pinned in sst.config.ts would
+    // make every admin-UI override unreachable (ENG-8303).
+    //
+    // DELIBERATELY INDEPENDENT of direct-chat-per-user. The two are separable in
+    // both directions and neither ordering is unsafe: this one alone narrows live
+    // delivery below what the REST read still serves (a teammate can load the
+    // thread but stops receiving it live), and that one alone is the state
+    // ENG-8712 shipped. Coupling them into one switch would have removed the
+    // ability to soak the live change on an org that is already comfortable with
+    // the read change.
+    defaultValue: false
+  },
   {
     key: "onboarding-auto-deploy",
     description: `Auto-deploy the first agent during onboarding (ENG-7378): the agent edit page's Deploy & Test tab fires the existing deploy (draft -> active) automatically once the agent's host is fully deployed (active + manager heartbeating, not provisioning) AND Claude-authenticated (claude_auth_status=valid), replacing the manual "Deploy Agent" click in the recruit funnel. Only draft, non-system_support agents; a failed or timed-out attempt falls back to the manual button (no auto-retry loop).`,

package/dist/mcp/slack-channel.js

@@ -35549,7 +35549,7 @@ var FLAG_REGISTRY = [
   },
   {
     key: "direct-chat-per-user",
-    description: "Scope a STANDARD agent's Direct Chat to the user who had the conversation (ENG-8712). Today two teammates who open the same agent land in the same thread and read each other's messages: the /recent and per-session reads carry no user predicate unless the agent is the per-org system_support concierge. When on, both reads return only sessions the requester authored in PLUS sessions no user has authored in \u2014 the second arm is load-bearing, since every server-originated row (kanban and scheduled-task nudges, integration failures, HITL approvals, degradation alerts) is written as role=user with no user_id and would otherwise vanish from every console (ENG-8431). Does NOT make the thread private in the live direction: assistant replies still fan out on the per-TEAM realtime topic direct-chat-agent:{agentId}, so a teammate holding the drawer open still receives them. Narrowing that topic is follow-up work.",
+    description: "Scope a STANDARD agent's Direct Chat to the user who had the conversation (ENG-8712). Today two teammates who open the same agent land in the same thread and read each other's messages: the /recent and per-session reads carry no user predicate unless the agent is the per-org system_support concierge. When on, both reads return only sessions the requester authored in PLUS sessions no user has authored in \u2014 the second arm is load-bearing, since every server-originated row (kanban and scheduled-task nudges, integration failures, HITL approvals, degradation alerts) is written as role=user with no user_id and would otherwise vanish from every console (ENG-8431). Does NOT by itself make the thread private in the live direction: assistant replies fan out on the per-TEAM realtime topic direct-chat-agent:{agentId}, so a teammate holding the drawer open still receives them. That half is direct-chat-live-per-user (ENG-8760), which is a SEPARATE flag on purpose \u2014 turn both on for a private thread.",
     flagType: "boolean",
     // Declared safe value is `false` — today's team-wide thread. Server-side only
     // (the two reads in routes/agents.ts); the browser needs no knowledge of it,
@@ -35562,6 +35562,27 @@ var FLAG_REGISTRY = [
     // backfill in migration 20260812000006 is not reversed by the flag.
     defaultValue: false
   },
+  {
+    key: "direct-chat-live-per-user",
+    description: "The LIVE half of per-user Direct Chat (ENG-8760). direct-chat-per-user scoped the two REST reads; assistant replies kept fanning out on the per-TEAM realtime topic direct-chat-agent:{agentId}, whose RLS (20260804000003) has no session and no user predicate \u2014 so a teammate holding the drawer open still received another member's replies live, and only a reload hid them. When on, a reply in a session a human has authored in is broadcast to direct-chat-user:{agentId}:{userId} instead, whose policy (20260812000009) pins the third segment to auth.uid(). Sessions NO human has authored in \u2014 the agent's inbound work queue: kanban and scheduled-task nudges, integration failures, HITL approvals, degradation alerts \u2014 keep going to the per-TEAM topic, matching arm 2 of the REST read, or this would repeat ENG-8431 in the live lane. Also admits the system_support concierge to the per-user topic, which the per-TEAM topic denies outright (its live delivery is additive here, never narrowed).",
+    flagType: "boolean",
+    // Declared safe value is `false` — today's per-TEAM fan-out, byte for byte,
+    // for every agent kind including the concierge. Server-side only: the browser
+    // subscribes to BOTH topics unconditionally and needs no knowledge of the
+    // flag, so NOT public — which is also what keeps client and server from
+    // disagreeing about it. No envVar: an org/team-scoped rollout gate with no
+    // host-side consumer, and a declared envVar pinned in sst.config.ts would
+    // make every admin-UI override unreachable (ENG-8303).
+    //
+    // DELIBERATELY INDEPENDENT of direct-chat-per-user. The two are separable in
+    // both directions and neither ordering is unsafe: this one alone narrows live
+    // delivery below what the REST read still serves (a teammate can load the
+    // thread but stops receiving it live), and that one alone is the state
+    // ENG-8712 shipped. Coupling them into one switch would have removed the
+    // ability to soak the live change on an org that is already comfortable with
+    // the read change.
+    defaultValue: false
+  },
   {
     key: "onboarding-auto-deploy",
     description: `Auto-deploy the first agent during onboarding (ENG-7378): the agent edit page's Deploy & Test tab fires the existing deploy (draft -> active) automatically once the agent's host is fully deployed (active + manager heartbeating, not provisioning) AND Claude-authenticated (claude_auth_status=valid), replacing the manual "Deploy Agent" click in the recruit funnel. Only draft, non-system_support agents; a failed or timed-out attempt falls back to the manual button (no auto-retry loop).`,

package/dist/mcp/telegram-channel.js

@@ -35708,7 +35708,7 @@ var FLAG_REGISTRY = [
   },
   {
     key: "direct-chat-per-user",
-    description: "Scope a STANDARD agent's Direct Chat to the user who had the conversation (ENG-8712). Today two teammates who open the same agent land in the same thread and read each other's messages: the /recent and per-session reads carry no user predicate unless the agent is the per-org system_support concierge. When on, both reads return only sessions the requester authored in PLUS sessions no user has authored in \u2014 the second arm is load-bearing, since every server-originated row (kanban and scheduled-task nudges, integration failures, HITL approvals, degradation alerts) is written as role=user with no user_id and would otherwise vanish from every console (ENG-8431). Does NOT make the thread private in the live direction: assistant replies still fan out on the per-TEAM realtime topic direct-chat-agent:{agentId}, so a teammate holding the drawer open still receives them. Narrowing that topic is follow-up work.",
+    description: "Scope a STANDARD agent's Direct Chat to the user who had the conversation (ENG-8712). Today two teammates who open the same agent land in the same thread and read each other's messages: the /recent and per-session reads carry no user predicate unless the agent is the per-org system_support concierge. When on, both reads return only sessions the requester authored in PLUS sessions no user has authored in \u2014 the second arm is load-bearing, since every server-originated row (kanban and scheduled-task nudges, integration failures, HITL approvals, degradation alerts) is written as role=user with no user_id and would otherwise vanish from every console (ENG-8431). Does NOT by itself make the thread private in the live direction: assistant replies fan out on the per-TEAM realtime topic direct-chat-agent:{agentId}, so a teammate holding the drawer open still receives them. That half is direct-chat-live-per-user (ENG-8760), which is a SEPARATE flag on purpose \u2014 turn both on for a private thread.",
     flagType: "boolean",
     // Declared safe value is `false` — today's team-wide thread. Server-side only
     // (the two reads in routes/agents.ts); the browser needs no knowledge of it,
@@ -35721,6 +35721,27 @@ var FLAG_REGISTRY = [
     // backfill in migration 20260812000006 is not reversed by the flag.
     defaultValue: false
   },
+  {
+    key: "direct-chat-live-per-user",
+    description: "The LIVE half of per-user Direct Chat (ENG-8760). direct-chat-per-user scoped the two REST reads; assistant replies kept fanning out on the per-TEAM realtime topic direct-chat-agent:{agentId}, whose RLS (20260804000003) has no session and no user predicate \u2014 so a teammate holding the drawer open still received another member's replies live, and only a reload hid them. When on, a reply in a session a human has authored in is broadcast to direct-chat-user:{agentId}:{userId} instead, whose policy (20260812000009) pins the third segment to auth.uid(). Sessions NO human has authored in \u2014 the agent's inbound work queue: kanban and scheduled-task nudges, integration failures, HITL approvals, degradation alerts \u2014 keep going to the per-TEAM topic, matching arm 2 of the REST read, or this would repeat ENG-8431 in the live lane. Also admits the system_support concierge to the per-user topic, which the per-TEAM topic denies outright (its live delivery is additive here, never narrowed).",
+    flagType: "boolean",
+    // Declared safe value is `false` — today's per-TEAM fan-out, byte for byte,
+    // for every agent kind including the concierge. Server-side only: the browser
+    // subscribes to BOTH topics unconditionally and needs no knowledge of the
+    // flag, so NOT public — which is also what keeps client and server from
+    // disagreeing about it. No envVar: an org/team-scoped rollout gate with no
+    // host-side consumer, and a declared envVar pinned in sst.config.ts would
+    // make every admin-UI override unreachable (ENG-8303).
+    //
+    // DELIBERATELY INDEPENDENT of direct-chat-per-user. The two are separable in
+    // both directions and neither ordering is unsafe: this one alone narrows live
+    // delivery below what the REST read still serves (a teammate can load the
+    // thread but stops receiving it live), and that one alone is the state
+    // ENG-8712 shipped. Coupling them into one switch would have removed the
+    // ability to soak the live change on an org that is already comfortable with
+    // the read change.
+    defaultValue: false
+  },
   {
     key: "onboarding-auto-deploy",
     description: `Auto-deploy the first agent during onboarding (ENG-7378): the agent edit page's Deploy & Test tab fires the existing deploy (draft -> active) automatically once the agent's host is fully deployed (active + manager heartbeating, not provisioning) AND Claude-authenticated (claude_auth_status=valid), replacing the manual "Deploy Agent" click in the recruit funnel. Only draft, non-system_support agents; a failed or timed-out attempt falls back to the manual button (no auto-retry loop).`,

package/dist/{persistent-session-74MH2XTM.js → persistent-session-6UGFGI6J.js}

@@ -41,7 +41,7 @@ import {
   writeDirectChatSessionState,
   writeEgressAllowlist,
   writePersistentClaudeWrapper
-} from "./chunk-72K46XUZ.js";
+} from "./chunk-5Z6RJ3RX.js";
 import "./chunk-XWVM4KPK.js";
 export {
   EGRESS_BASELINE_DOMAINS,
@@ -87,4 +87,4 @@ export {
   writeEgressAllowlist,
   writePersistentClaudeWrapper
 };
-//# sourceMappingURL=persistent-session-74MH2XTM.js.map
+//# sourceMappingURL=persistent-session-6UGFGI6J.js.map

package/dist/{responsiveness-probe-5VNQQZNJ.js → responsiveness-probe-O7AVC73R.js}

@@ -1,6 +1,6 @@
 import {
   paneLogPath
-} from "./chunk-72K46XUZ.js";
+} from "./chunk-5Z6RJ3RX.js";
 import "./chunk-XWVM4KPK.js";
 
 // src/lib/responsiveness-probe.ts
@@ -689,4 +689,4 @@ export {
   readAndResetSlackReplyBindingClassifications,
   readAndResetSlackReplyTargetClassifications
 };
-//# sourceMappingURL=responsiveness-probe-5VNQQZNJ.js.map
+//# sourceMappingURL=responsiveness-probe-O7AVC73R.js.map

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@integrity-labs/agt-cli",
-  "version": "0.28.572",
+  "version": "0.28.573",
   "description": "Augmented Team CLI — agent provisioning and management",
   "type": "module",
   "engines": {