@integrity-labs/agt-cli 0.28.736 → 0.28.737

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

@@ -36591,22 +36591,31 @@ var FLAG_REGISTRY = [
     // seeding code, so `listNewOrgFlagOverrides()` is the one answer to "which flags
     // does a new org get". `defaultValue` stays false so the ~4 months of orgs already
     // carrying an inert enforce-level email.require_approval row are NOT armed on deploy.
-    newOrgOverride: true,
-    // ENG-9630: API-created organizations only, and this is a deliberate,
-    // reviewed asymmetry rather than an oversight.
+    // ENG-9675: EVERY creation path, self-serve included.
     //
-    // Arming this holds EVERY dispatching send for human approval. The hold
-    // itself works fine on a self-serve org — `hitl-approval-routing` has
-    // defaulted to 'on' since ENG-7828, so a real Human Approval card is minted
-    // and it is actionable at /organization/approvals. What a self-serve org
-    // does NOT have is any means of being TOLD: no Slack alert channel is wired
-    // at signup, so the card sits in a console surface nobody has pointed the
-    // user at, and their agent's first email silently waits on it.
+    // ENG-9630 had restricted this to API-created orgs on the grounds that a
+    // self-serve org has no way of being TOLD about a held send — no Slack
+    // alert channel is wired at signup. That reasoning was wrong, and the check
+    // behind it was incomplete: it confirmed an in-console page exists at
+    // /organization/approvals and stopped, without looking at the dispatch path.
     //
-    // So the blocker is the notification path, not the control. Whoever revisits
-    // this should treat "a self-serve org actually receives the card" as the
-    // prerequisite and then drop this line — do not simply widen it.
-    newOrgOverrideOrigins: ["api"]
+    // `routeBlockedCallToApproval` has three dispatchers, and the Direct Chat
+    // one (lib/integration-broker-approval-direct-chat.ts, ENG-7680) is the
+    // universal fallback — "every managed agent always has a Direct Chat session
+    // its operator/manager watches in the Console ... usable out of the box with
+    // no per-org approval-route setup and no Slack dependency". It posts into a
+    // thread keyed on the approval_requests.id and correlates the manager's
+    // reply back through tryCaptureDirectChatApproval, so a self-serve org has
+    // both a zero-config delivery channel AND a reply path.
+    //
+    // With the stated blocker gone, the guardrail's own promise — "before
+    // sending any email" — applies to the organizations with the LEAST operator
+    // oversight exactly as it does to the rest.
+    //
+    // Existing self-serve orgs are deliberately NOT armed by this: newOrgOverride
+    // is applied at creation, and nothing backfills. Extending it to them is a
+    // separate decision with a comms obligation.
+    newOrgOverride: true
   },
   {
     key: "mail-rule-control-enforcement",

package/dist/mcp/index.js

@@ -43544,22 +43544,31 @@ var FLAG_REGISTRY = [
     // seeding code, so `listNewOrgFlagOverrides()` is the one answer to "which flags
     // does a new org get". `defaultValue` stays false so the ~4 months of orgs already
     // carrying an inert enforce-level email.require_approval row are NOT armed on deploy.
-    newOrgOverride: true,
-    // ENG-9630: API-created organizations only, and this is a deliberate,
-    // reviewed asymmetry rather than an oversight.
+    // ENG-9675: EVERY creation path, self-serve included.
     //
-    // Arming this holds EVERY dispatching send for human approval. The hold
-    // itself works fine on a self-serve org — `hitl-approval-routing` has
-    // defaulted to 'on' since ENG-7828, so a real Human Approval card is minted
-    // and it is actionable at /organization/approvals. What a self-serve org
-    // does NOT have is any means of being TOLD: no Slack alert channel is wired
-    // at signup, so the card sits in a console surface nobody has pointed the
-    // user at, and their agent's first email silently waits on it.
+    // ENG-9630 had restricted this to API-created orgs on the grounds that a
+    // self-serve org has no way of being TOLD about a held send — no Slack
+    // alert channel is wired at signup. That reasoning was wrong, and the check
+    // behind it was incomplete: it confirmed an in-console page exists at
+    // /organization/approvals and stopped, without looking at the dispatch path.
     //
-    // So the blocker is the notification path, not the control. Whoever revisits
-    // this should treat "a self-serve org actually receives the card" as the
-    // prerequisite and then drop this line — do not simply widen it.
-    newOrgOverrideOrigins: ["api"]
+    // `routeBlockedCallToApproval` has three dispatchers, and the Direct Chat
+    // one (lib/integration-broker-approval-direct-chat.ts, ENG-7680) is the
+    // universal fallback — "every managed agent always has a Direct Chat session
+    // its operator/manager watches in the Console ... usable out of the box with
+    // no per-org approval-route setup and no Slack dependency". It posts into a
+    // thread keyed on the approval_requests.id and correlates the manager's
+    // reply back through tryCaptureDirectChatApproval, so a self-serve org has
+    // both a zero-config delivery channel AND a reply path.
+    //
+    // With the stated blocker gone, the guardrail's own promise — "before
+    // sending any email" — applies to the organizations with the LEAST operator
+    // oversight exactly as it does to the rest.
+    //
+    // Existing self-serve orgs are deliberately NOT armed by this: newOrgOverride
+    // is applied at creation, and nothing backfills. Extending it to them is a
+    // separate decision with a comms obligation.
+    newOrgOverride: true
   },
   {
     key: "mail-rule-control-enforcement",

package/dist/mcp/origami.js

@@ -42315,22 +42315,31 @@ var FLAG_REGISTRY = [
     // seeding code, so `listNewOrgFlagOverrides()` is the one answer to "which flags
     // does a new org get". `defaultValue` stays false so the ~4 months of orgs already
     // carrying an inert enforce-level email.require_approval row are NOT armed on deploy.
-    newOrgOverride: true,
-    // ENG-9630: API-created organizations only, and this is a deliberate,
-    // reviewed asymmetry rather than an oversight.
+    // ENG-9675: EVERY creation path, self-serve included.
     //
-    // Arming this holds EVERY dispatching send for human approval. The hold
-    // itself works fine on a self-serve org — `hitl-approval-routing` has
-    // defaulted to 'on' since ENG-7828, so a real Human Approval card is minted
-    // and it is actionable at /organization/approvals. What a self-serve org
-    // does NOT have is any means of being TOLD: no Slack alert channel is wired
-    // at signup, so the card sits in a console surface nobody has pointed the
-    // user at, and their agent's first email silently waits on it.
+    // ENG-9630 had restricted this to API-created orgs on the grounds that a
+    // self-serve org has no way of being TOLD about a held send — no Slack
+    // alert channel is wired at signup. That reasoning was wrong, and the check
+    // behind it was incomplete: it confirmed an in-console page exists at
+    // /organization/approvals and stopped, without looking at the dispatch path.
     //
-    // So the blocker is the notification path, not the control. Whoever revisits
-    // this should treat "a self-serve org actually receives the card" as the
-    // prerequisite and then drop this line — do not simply widen it.
-    newOrgOverrideOrigins: ["api"]
+    // `routeBlockedCallToApproval` has three dispatchers, and the Direct Chat
+    // one (lib/integration-broker-approval-direct-chat.ts, ENG-7680) is the
+    // universal fallback — "every managed agent always has a Direct Chat session
+    // its operator/manager watches in the Console ... usable out of the box with
+    // no per-org approval-route setup and no Slack dependency". It posts into a
+    // thread keyed on the approval_requests.id and correlates the manager's
+    // reply back through tryCaptureDirectChatApproval, so a self-serve org has
+    // both a zero-config delivery channel AND a reply path.
+    //
+    // With the stated blocker gone, the guardrail's own promise — "before
+    // sending any email" — applies to the organizations with the LEAST operator
+    // oversight exactly as it does to the rest.
+    //
+    // Existing self-serve orgs are deliberately NOT armed by this: newOrgOverride
+    // is applied at creation, and nothing backfills. Extending it to them is a
+    // separate decision with a comms obligation.
+    newOrgOverride: true
   },
   {
     key: "mail-rule-control-enforcement",

package/dist/mcp/slack-channel.js

@@ -36838,22 +36838,31 @@ var FLAG_REGISTRY = [
     // seeding code, so `listNewOrgFlagOverrides()` is the one answer to "which flags
     // does a new org get". `defaultValue` stays false so the ~4 months of orgs already
     // carrying an inert enforce-level email.require_approval row are NOT armed on deploy.
-    newOrgOverride: true,
-    // ENG-9630: API-created organizations only, and this is a deliberate,
-    // reviewed asymmetry rather than an oversight.
+    // ENG-9675: EVERY creation path, self-serve included.
     //
-    // Arming this holds EVERY dispatching send for human approval. The hold
-    // itself works fine on a self-serve org — `hitl-approval-routing` has
-    // defaulted to 'on' since ENG-7828, so a real Human Approval card is minted
-    // and it is actionable at /organization/approvals. What a self-serve org
-    // does NOT have is any means of being TOLD: no Slack alert channel is wired
-    // at signup, so the card sits in a console surface nobody has pointed the
-    // user at, and their agent's first email silently waits on it.
+    // ENG-9630 had restricted this to API-created orgs on the grounds that a
+    // self-serve org has no way of being TOLD about a held send — no Slack
+    // alert channel is wired at signup. That reasoning was wrong, and the check
+    // behind it was incomplete: it confirmed an in-console page exists at
+    // /organization/approvals and stopped, without looking at the dispatch path.
     //
-    // So the blocker is the notification path, not the control. Whoever revisits
-    // this should treat "a self-serve org actually receives the card" as the
-    // prerequisite and then drop this line — do not simply widen it.
-    newOrgOverrideOrigins: ["api"]
+    // `routeBlockedCallToApproval` has three dispatchers, and the Direct Chat
+    // one (lib/integration-broker-approval-direct-chat.ts, ENG-7680) is the
+    // universal fallback — "every managed agent always has a Direct Chat session
+    // its operator/manager watches in the Console ... usable out of the box with
+    // no per-org approval-route setup and no Slack dependency". It posts into a
+    // thread keyed on the approval_requests.id and correlates the manager's
+    // reply back through tryCaptureDirectChatApproval, so a self-serve org has
+    // both a zero-config delivery channel AND a reply path.
+    //
+    // With the stated blocker gone, the guardrail's own promise — "before
+    // sending any email" — applies to the organizations with the LEAST operator
+    // oversight exactly as it does to the rest.
+    //
+    // Existing self-serve orgs are deliberately NOT armed by this: newOrgOverride
+    // is applied at creation, and nothing backfills. Extending it to them is a
+    // separate decision with a comms obligation.
+    newOrgOverride: true
   },
   {
     key: "mail-rule-control-enforcement",

package/dist/mcp/telegram-channel.js

@@ -36996,22 +36996,31 @@ var FLAG_REGISTRY = [
     // seeding code, so `listNewOrgFlagOverrides()` is the one answer to "which flags
     // does a new org get". `defaultValue` stays false so the ~4 months of orgs already
     // carrying an inert enforce-level email.require_approval row are NOT armed on deploy.
-    newOrgOverride: true,
-    // ENG-9630: API-created organizations only, and this is a deliberate,
-    // reviewed asymmetry rather than an oversight.
+    // ENG-9675: EVERY creation path, self-serve included.
     //
-    // Arming this holds EVERY dispatching send for human approval. The hold
-    // itself works fine on a self-serve org — `hitl-approval-routing` has
-    // defaulted to 'on' since ENG-7828, so a real Human Approval card is minted
-    // and it is actionable at /organization/approvals. What a self-serve org
-    // does NOT have is any means of being TOLD: no Slack alert channel is wired
-    // at signup, so the card sits in a console surface nobody has pointed the
-    // user at, and their agent's first email silently waits on it.
+    // ENG-9630 had restricted this to API-created orgs on the grounds that a
+    // self-serve org has no way of being TOLD about a held send — no Slack
+    // alert channel is wired at signup. That reasoning was wrong, and the check
+    // behind it was incomplete: it confirmed an in-console page exists at
+    // /organization/approvals and stopped, without looking at the dispatch path.
     //
-    // So the blocker is the notification path, not the control. Whoever revisits
-    // this should treat "a self-serve org actually receives the card" as the
-    // prerequisite and then drop this line — do not simply widen it.
-    newOrgOverrideOrigins: ["api"]
+    // `routeBlockedCallToApproval` has three dispatchers, and the Direct Chat
+    // one (lib/integration-broker-approval-direct-chat.ts, ENG-7680) is the
+    // universal fallback — "every managed agent always has a Direct Chat session
+    // its operator/manager watches in the Console ... usable out of the box with
+    // no per-org approval-route setup and no Slack dependency". It posts into a
+    // thread keyed on the approval_requests.id and correlates the manager's
+    // reply back through tryCaptureDirectChatApproval, so a self-serve org has
+    // both a zero-config delivery channel AND a reply path.
+    //
+    // With the stated blocker gone, the guardrail's own promise — "before
+    // sending any email" — applies to the organizations with the LEAST operator
+    // oversight exactly as it does to the rest.
+    //
+    // Existing self-serve orgs are deliberately NOT armed by this: newOrgOverride
+    // is applied at creation, and nothing backfills. Extending it to them is a
+    // separate decision with a comms obligation.
+    newOrgOverride: true
   },
   {
     key: "mail-rule-control-enforcement",

package/dist/{persistent-session-GJMGXFF2.js → persistent-session-NE6DCBFD.js}

@@ -49,8 +49,8 @@ import {
   writeDirectChatSessionState,
   writeEgressAllowlist,
   writePersistentClaudeWrapper
-} from "./chunk-6J6G4HOG.js";
-import "./chunk-IBBBIE4K.js";
+} from "./chunk-MV3QBGO4.js";
+import "./chunk-WB2E236K.js";
 import "./chunk-XWVM4KPK.js";
 export {
   EGRESS_BASELINE_DOMAINS,
@@ -104,4 +104,4 @@ export {
   writeEgressAllowlist,
   writePersistentClaudeWrapper
 };
-//# sourceMappingURL=persistent-session-GJMGXFF2.js.map
+//# sourceMappingURL=persistent-session-NE6DCBFD.js.map

package/dist/{responsiveness-probe-34ECZDWQ.js → responsiveness-probe-VN4OPV56.js}

@@ -1,7 +1,7 @@
 import {
   paneLogPath
-} from "./chunk-6J6G4HOG.js";
-import "./chunk-IBBBIE4K.js";
+} from "./chunk-MV3QBGO4.js";
+import "./chunk-WB2E236K.js";
 import "./chunk-XWVM4KPK.js";
 
 // src/lib/responsiveness-probe.ts
@@ -745,4 +745,4 @@ export {
   readAndResetSlackReplyBindingClassifications,
   readAndResetSlackReplyTargetClassifications
 };
-//# sourceMappingURL=responsiveness-probe-34ECZDWQ.js.map
+//# sourceMappingURL=responsiveness-probe-VN4OPV56.js.map

package/dist/{session-auth-dead-TK3KNAH4.js → session-auth-dead-TI6JWW4G.js}

@@ -1,6 +1,6 @@
 import {
   sessionTranscriptDir
-} from "./chunk-IBBBIE4K.js";
+} from "./chunk-WB2E236K.js";
 
 // src/lib/session-auth-dead.ts
 import { closeSync, openSync, readSync, readdirSync, statSync } from "fs";
@@ -203,4 +203,4 @@ export {
   decideSessionAuthState,
   probeSessionAuth
 };
-//# sourceMappingURL=session-auth-dead-TK3KNAH4.js.map
+//# sourceMappingURL=session-auth-dead-TI6JWW4G.js.map

package/package.json

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