@integrity-labs/agt-cli 0.28.572 → 0.28.574

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-2ESCLFCK.js}

@@ -41,7 +41,7 @@ import {
   writeDirectChatSessionState,
   writeEgressAllowlist,
   writePersistentClaudeWrapper
-} from "./chunk-72K46XUZ.js";
+} from "./chunk-E3KBX3UW.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-2ESCLFCK.js.map

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

@@ -1,6 +1,6 @@
 import {
   paneLogPath
-} from "./chunk-72K46XUZ.js";
+} from "./chunk-E3KBX3UW.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-YCUDUCAS.js.map

package/package.json

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