@integrity-labs/agt-cli 0.28.736 → 0.28.738

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",
@@ -36748,6 +36757,18 @@ var FLAG_REGISTRY = [
     public: true,
     defaultValue: false
   },
+  {
+    key: "ninjafy-notes-menu",
+    description: 'Show the "Notes" nav item in the webapp, linking to the Ninja Notes landing surface (ENG-9676). The landing page tailors itself to the org: an Opt-in / request-enablement flow when Ninja Notes (the `ninjafy-notes` premium integration) is not yet opted in, or the Mac app DMG download once it is. Per-org rollout gate, sibling to `projects-menu`.',
+    flagType: "boolean",
+    // PUBLIC (ADR-0022 §2): a UI-rollout flag the browser needs (the nav shells
+    // read it via usePublicBooleanFlag), so it's serialized to the client via
+    // GET /flags and evaluated per the caller's active org. Flip it on per-org
+    // from the admin Feature Flags page. No env override (UI flag, not an
+    // operator gate). Ships dark (default false).
+    public: true,
+    defaultValue: false
+  },
   {
     key: "platform-maintenance-mode",
     description: 'Platform-wide maintenance mode (ENG-6506): when on, every agent across every team/org auto-replies to admitted human inbound with a "we are offline for maintenance" notice instead of dispatching to the agent \u2014 for whole-platform downtime such as DB upgrades. Read host-side per inbound from the flags cache (no MCP restart). Boolean gate; ships dark \u2014 when off, channels behave exactly as today. (Proactive "back online" follow-up is the ENG-6508 fast-follow, not this flag.)',

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",
@@ -43701,6 +43710,18 @@ var FLAG_REGISTRY = [
     public: true,
     defaultValue: false
   },
+  {
+    key: "ninjafy-notes-menu",
+    description: 'Show the "Notes" nav item in the webapp, linking to the Ninja Notes landing surface (ENG-9676). The landing page tailors itself to the org: an Opt-in / request-enablement flow when Ninja Notes (the `ninjafy-notes` premium integration) is not yet opted in, or the Mac app DMG download once it is. Per-org rollout gate, sibling to `projects-menu`.',
+    flagType: "boolean",
+    // PUBLIC (ADR-0022 §2): a UI-rollout flag the browser needs (the nav shells
+    // read it via usePublicBooleanFlag), so it's serialized to the client via
+    // GET /flags and evaluated per the caller's active org. Flip it on per-org
+    // from the admin Feature Flags page. No env override (UI flag, not an
+    // operator gate). Ships dark (default false).
+    public: true,
+    defaultValue: false
+  },
   {
     key: "platform-maintenance-mode",
     description: 'Platform-wide maintenance mode (ENG-6506): when on, every agent across every team/org auto-replies to admitted human inbound with a "we are offline for maintenance" notice instead of dispatching to the agent \u2014 for whole-platform downtime such as DB upgrades. Read host-side per inbound from the flags cache (no MCP restart). Boolean gate; ships dark \u2014 when off, channels behave exactly as today. (Proactive "back online" follow-up is the ENG-6508 fast-follow, not this flag.)',

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",
@@ -42472,6 +42481,18 @@ var FLAG_REGISTRY = [
     public: true,
     defaultValue: false
   },
+  {
+    key: "ninjafy-notes-menu",
+    description: 'Show the "Notes" nav item in the webapp, linking to the Ninja Notes landing surface (ENG-9676). The landing page tailors itself to the org: an Opt-in / request-enablement flow when Ninja Notes (the `ninjafy-notes` premium integration) is not yet opted in, or the Mac app DMG download once it is. Per-org rollout gate, sibling to `projects-menu`.',
+    flagType: "boolean",
+    // PUBLIC (ADR-0022 §2): a UI-rollout flag the browser needs (the nav shells
+    // read it via usePublicBooleanFlag), so it's serialized to the client via
+    // GET /flags and evaluated per the caller's active org. Flip it on per-org
+    // from the admin Feature Flags page. No env override (UI flag, not an
+    // operator gate). Ships dark (default false).
+    public: true,
+    defaultValue: false
+  },
   {
     key: "platform-maintenance-mode",
     description: 'Platform-wide maintenance mode (ENG-6506): when on, every agent across every team/org auto-replies to admitted human inbound with a "we are offline for maintenance" notice instead of dispatching to the agent \u2014 for whole-platform downtime such as DB upgrades. Read host-side per inbound from the flags cache (no MCP restart). Boolean gate; ships dark \u2014 when off, channels behave exactly as today. (Proactive "back online" follow-up is the ENG-6508 fast-follow, not this flag.)',

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",
@@ -36995,6 +37004,18 @@ var FLAG_REGISTRY = [
     public: true,
     defaultValue: false
   },
+  {
+    key: "ninjafy-notes-menu",
+    description: 'Show the "Notes" nav item in the webapp, linking to the Ninja Notes landing surface (ENG-9676). The landing page tailors itself to the org: an Opt-in / request-enablement flow when Ninja Notes (the `ninjafy-notes` premium integration) is not yet opted in, or the Mac app DMG download once it is. Per-org rollout gate, sibling to `projects-menu`.',
+    flagType: "boolean",
+    // PUBLIC (ADR-0022 §2): a UI-rollout flag the browser needs (the nav shells
+    // read it via usePublicBooleanFlag), so it's serialized to the client via
+    // GET /flags and evaluated per the caller's active org. Flip it on per-org
+    // from the admin Feature Flags page. No env override (UI flag, not an
+    // operator gate). Ships dark (default false).
+    public: true,
+    defaultValue: false
+  },
   {
     key: "platform-maintenance-mode",
     description: 'Platform-wide maintenance mode (ENG-6506): when on, every agent across every team/org auto-replies to admitted human inbound with a "we are offline for maintenance" notice instead of dispatching to the agent \u2014 for whole-platform downtime such as DB upgrades. Read host-side per inbound from the flags cache (no MCP restart). Boolean gate; ships dark \u2014 when off, channels behave exactly as today. (Proactive "back online" follow-up is the ENG-6508 fast-follow, not this flag.)',

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",
@@ -37153,6 +37162,18 @@ var FLAG_REGISTRY = [
     public: true,
     defaultValue: false
   },
+  {
+    key: "ninjafy-notes-menu",
+    description: 'Show the "Notes" nav item in the webapp, linking to the Ninja Notes landing surface (ENG-9676). The landing page tailors itself to the org: an Opt-in / request-enablement flow when Ninja Notes (the `ninjafy-notes` premium integration) is not yet opted in, or the Mac app DMG download once it is. Per-org rollout gate, sibling to `projects-menu`.',
+    flagType: "boolean",
+    // PUBLIC (ADR-0022 §2): a UI-rollout flag the browser needs (the nav shells
+    // read it via usePublicBooleanFlag), so it's serialized to the client via
+    // GET /flags and evaluated per the caller's active org. Flip it on per-org
+    // from the admin Feature Flags page. No env override (UI flag, not an
+    // operator gate). Ships dark (default false).
+    public: true,
+    defaultValue: false
+  },
   {
     key: "platform-maintenance-mode",
     description: 'Platform-wide maintenance mode (ENG-6506): when on, every agent across every team/org auto-replies to admitted human inbound with a "we are offline for maintenance" notice instead of dispatching to the agent \u2014 for whole-platform downtime such as DB upgrades. Read host-side per inbound from the flags cache (no MCP restart). Boolean gate; ships dark \u2014 when off, channels behave exactly as today. (Proactive "back online" follow-up is the ENG-6508 fast-follow, not this flag.)',

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

@@ -49,8 +49,8 @@ import {
   writeDirectChatSessionState,
   writeEgressAllowlist,
   writePersistentClaudeWrapper
-} from "./chunk-6J6G4HOG.js";
-import "./chunk-IBBBIE4K.js";
+} from "./chunk-JDNULCLF.js";
+import "./chunk-MAXKAS4Q.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-E7TUUVAI.js.map

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

@@ -1,7 +1,7 @@
 import {
   paneLogPath
-} from "./chunk-6J6G4HOG.js";
-import "./chunk-IBBBIE4K.js";
+} from "./chunk-JDNULCLF.js";
+import "./chunk-MAXKAS4Q.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-PXXWLOML.js.map

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

@@ -1,6 +1,6 @@
 import {
   sessionTranscriptDir
-} from "./chunk-IBBBIE4K.js";
+} from "./chunk-MAXKAS4Q.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-HZZJK37X.js.map

package/package.json

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