@integrity-labs/agt-cli 0.28.1097 → 0.28.1099

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

@@ -38167,6 +38167,17 @@ var FLAG_REGISTRY = [
     // deliberate, audited per-org flip (ADR-0022 §4).
     sensitive: true
   },
+  {
+    key: "email-guard-sole-decider",
+    description: "ENG-11190 PR1: make the email guardrail (`email.domain_restrict`) the ONLY decider for email sends. Today two gates judge every send: the email guard (by its stage) and the Composio tool-tier HITL (OUTLOOK_SEND_EMAIL / GMAIL_SEND_EMAIL resolve to `write_high_risk`, so every send is held whatever the guard says). Brad, 6 Oct (Two Tractors / Horatio): a guard set to Shadow must not still produce an approval card. When ON for an org, the tier gate stops re-deciding a registered composing email send for an agent that HAS an active email guardrail AND whose stage is in force: the guard, which already ran first in callIntegrationTool and holds or blocks by its own stage, is the verdict. A stage whose enable flag is off (Require approval or Block that is not yet enabled for the org) only observes, so it is NOT a verdict and the tier hold stays (Obi Wan on #6816). An agent with no email guardrail (or a disabled one) keeps the tier hold, so turning this on never removes the only hold an org has. Draft-sends (recipients on the stored draft) keep the tier hold in this slice. Every deferred send is still audited. Evaluated per-org. Ships dark.",
+    flagType: "boolean",
+    // Declared safe value is `false` (both gates, today's behaviour). A flag-DB read error
+    // degrades here, so a flags outage keeps the tier hold rather than silently loosening it.
+    defaultValue: false,
+    // Turning it on lets external email go out WITHOUT the tier hold where the guard allows
+    // it (e.g. Shadow), so it is a deliberate, audited per-org flip (ADR-0022 §4).
+    sensitive: true
+  },
   {
     key: "email-require-approval-enforcement",
     description: 'Enforcement gate for the `email.require_approval` guardrail (ENG-9611). That guardrail has been `default_for_new_orgs` since ~2026-05-03 and its display text promises "Require human approval before sending any email", but nothing ever read it: its only runtime path was toGuardrailForPrompt, i.e. a line in the agent CLAUDE.md. When ON for an org, a DISPATCHING email send (never a draft-create, ENG-7980) is held and routed to Human Approval regardless of recipient domain \u2014 which is what "any email" means, and is what distinguishes it from email-guard-require-approval-enabled, whose require_approval stage only intercepts a would-be DOMAIN block. Deliberately separate from the guardrail row: roughly four months of orgs already carry an inert `enforce`-level row, so reading the row alone would arm a blocking control across all of them on deploy. New orgs are no longer armed (ENG-11234). Orgs created while the ENG-9629/9675 new-org arm was live keep their org-scoped ON override until an operator flips them per org. Evaluated per-org. Ships dark.',

package/dist/mcp/index.js

@@ -30385,6 +30385,17 @@ var FLAG_REGISTRY = [
     // deliberate, audited per-org flip (ADR-0022 §4).
     sensitive: true
   },
+  {
+    key: "email-guard-sole-decider",
+    description: "ENG-11190 PR1: make the email guardrail (`email.domain_restrict`) the ONLY decider for email sends. Today two gates judge every send: the email guard (by its stage) and the Composio tool-tier HITL (OUTLOOK_SEND_EMAIL / GMAIL_SEND_EMAIL resolve to `write_high_risk`, so every send is held whatever the guard says). Brad, 6 Oct (Two Tractors / Horatio): a guard set to Shadow must not still produce an approval card. When ON for an org, the tier gate stops re-deciding a registered composing email send for an agent that HAS an active email guardrail AND whose stage is in force: the guard, which already ran first in callIntegrationTool and holds or blocks by its own stage, is the verdict. A stage whose enable flag is off (Require approval or Block that is not yet enabled for the org) only observes, so it is NOT a verdict and the tier hold stays (Obi Wan on #6816). An agent with no email guardrail (or a disabled one) keeps the tier hold, so turning this on never removes the only hold an org has. Draft-sends (recipients on the stored draft) keep the tier hold in this slice. Every deferred send is still audited. Evaluated per-org. Ships dark.",
+    flagType: "boolean",
+    // Declared safe value is `false` (both gates, today's behaviour). A flag-DB read error
+    // degrades here, so a flags outage keeps the tier hold rather than silently loosening it.
+    defaultValue: false,
+    // Turning it on lets external email go out WITHOUT the tier hold where the guard allows
+    // it (e.g. Shadow), so it is a deliberate, audited per-org flip (ADR-0022 §4).
+    sensitive: true
+  },
   {
     key: "email-require-approval-enforcement",
     description: 'Enforcement gate for the `email.require_approval` guardrail (ENG-9611). That guardrail has been `default_for_new_orgs` since ~2026-05-03 and its display text promises "Require human approval before sending any email", but nothing ever read it: its only runtime path was toGuardrailForPrompt, i.e. a line in the agent CLAUDE.md. When ON for an org, a DISPATCHING email send (never a draft-create, ENG-7980) is held and routed to Human Approval regardless of recipient domain \u2014 which is what "any email" means, and is what distinguishes it from email-guard-require-approval-enabled, whose require_approval stage only intercepts a would-be DOMAIN block. Deliberately separate from the guardrail row: roughly four months of orgs already carry an inert `enforce`-level row, so reading the row alone would arm a blocking control across all of them on deploy. New orgs are no longer armed (ENG-11234). Orgs created while the ENG-9629/9675 new-org arm was live keep their org-scoped ON override until an operator flips them per org. Evaluated per-org. Ships dark.',

package/dist/mcp/origami.js

@@ -44331,6 +44331,17 @@ var FLAG_REGISTRY = [
     // deliberate, audited per-org flip (ADR-0022 §4).
     sensitive: true
   },
+  {
+    key: "email-guard-sole-decider",
+    description: "ENG-11190 PR1: make the email guardrail (`email.domain_restrict`) the ONLY decider for email sends. Today two gates judge every send: the email guard (by its stage) and the Composio tool-tier HITL (OUTLOOK_SEND_EMAIL / GMAIL_SEND_EMAIL resolve to `write_high_risk`, so every send is held whatever the guard says). Brad, 6 Oct (Two Tractors / Horatio): a guard set to Shadow must not still produce an approval card. When ON for an org, the tier gate stops re-deciding a registered composing email send for an agent that HAS an active email guardrail AND whose stage is in force: the guard, which already ran first in callIntegrationTool and holds or blocks by its own stage, is the verdict. A stage whose enable flag is off (Require approval or Block that is not yet enabled for the org) only observes, so it is NOT a verdict and the tier hold stays (Obi Wan on #6816). An agent with no email guardrail (or a disabled one) keeps the tier hold, so turning this on never removes the only hold an org has. Draft-sends (recipients on the stored draft) keep the tier hold in this slice. Every deferred send is still audited. Evaluated per-org. Ships dark.",
+    flagType: "boolean",
+    // Declared safe value is `false` (both gates, today's behaviour). A flag-DB read error
+    // degrades here, so a flags outage keeps the tier hold rather than silently loosening it.
+    defaultValue: false,
+    // Turning it on lets external email go out WITHOUT the tier hold where the guard allows
+    // it (e.g. Shadow), so it is a deliberate, audited per-org flip (ADR-0022 §4).
+    sensitive: true
+  },
   {
     key: "email-require-approval-enforcement",
     description: 'Enforcement gate for the `email.require_approval` guardrail (ENG-9611). That guardrail has been `default_for_new_orgs` since ~2026-05-03 and its display text promises "Require human approval before sending any email", but nothing ever read it: its only runtime path was toGuardrailForPrompt, i.e. a line in the agent CLAUDE.md. When ON for an org, a DISPATCHING email send (never a draft-create, ENG-7980) is held and routed to Human Approval regardless of recipient domain \u2014 which is what "any email" means, and is what distinguishes it from email-guard-require-approval-enabled, whose require_approval stage only intercepts a would-be DOMAIN block. Deliberately separate from the guardrail row: roughly four months of orgs already carry an inert `enforce`-level row, so reading the row alone would arm a blocking control across all of them on deploy. New orgs are no longer armed (ENG-11234). Orgs created while the ENG-9629/9675 new-org arm was live keep their org-scoped ON override until an operator flips them per org. Evaluated per-org. Ships dark.',

package/dist/mcp/slack-channel.js

@@ -38938,6 +38938,17 @@ var FLAG_REGISTRY = [
     // deliberate, audited per-org flip (ADR-0022 §4).
     sensitive: true
   },
+  {
+    key: "email-guard-sole-decider",
+    description: "ENG-11190 PR1: make the email guardrail (`email.domain_restrict`) the ONLY decider for email sends. Today two gates judge every send: the email guard (by its stage) and the Composio tool-tier HITL (OUTLOOK_SEND_EMAIL / GMAIL_SEND_EMAIL resolve to `write_high_risk`, so every send is held whatever the guard says). Brad, 6 Oct (Two Tractors / Horatio): a guard set to Shadow must not still produce an approval card. When ON for an org, the tier gate stops re-deciding a registered composing email send for an agent that HAS an active email guardrail AND whose stage is in force: the guard, which already ran first in callIntegrationTool and holds or blocks by its own stage, is the verdict. A stage whose enable flag is off (Require approval or Block that is not yet enabled for the org) only observes, so it is NOT a verdict and the tier hold stays (Obi Wan on #6816). An agent with no email guardrail (or a disabled one) keeps the tier hold, so turning this on never removes the only hold an org has. Draft-sends (recipients on the stored draft) keep the tier hold in this slice. Every deferred send is still audited. Evaluated per-org. Ships dark.",
+    flagType: "boolean",
+    // Declared safe value is `false` (both gates, today's behaviour). A flag-DB read error
+    // degrades here, so a flags outage keeps the tier hold rather than silently loosening it.
+    defaultValue: false,
+    // Turning it on lets external email go out WITHOUT the tier hold where the guard allows
+    // it (e.g. Shadow), so it is a deliberate, audited per-org flip (ADR-0022 §4).
+    sensitive: true
+  },
   {
     key: "email-require-approval-enforcement",
     description: 'Enforcement gate for the `email.require_approval` guardrail (ENG-9611). That guardrail has been `default_for_new_orgs` since ~2026-05-03 and its display text promises "Require human approval before sending any email", but nothing ever read it: its only runtime path was toGuardrailForPrompt, i.e. a line in the agent CLAUDE.md. When ON for an org, a DISPATCHING email send (never a draft-create, ENG-7980) is held and routed to Human Approval regardless of recipient domain \u2014 which is what "any email" means, and is what distinguishes it from email-guard-require-approval-enabled, whose require_approval stage only intercepts a would-be DOMAIN block. Deliberately separate from the guardrail row: roughly four months of orgs already carry an inert `enforce`-level row, so reading the row alone would arm a blocking control across all of them on deploy. New orgs are no longer armed (ENG-11234). Orgs created while the ENG-9629/9675 new-org arm was live keep their org-scoped ON override until an operator flips them per org. Evaluated per-org. Ships dark.',

package/dist/mcp/telegram-channel.js

@@ -39044,6 +39044,17 @@ var FLAG_REGISTRY = [
     // deliberate, audited per-org flip (ADR-0022 §4).
     sensitive: true
   },
+  {
+    key: "email-guard-sole-decider",
+    description: "ENG-11190 PR1: make the email guardrail (`email.domain_restrict`) the ONLY decider for email sends. Today two gates judge every send: the email guard (by its stage) and the Composio tool-tier HITL (OUTLOOK_SEND_EMAIL / GMAIL_SEND_EMAIL resolve to `write_high_risk`, so every send is held whatever the guard says). Brad, 6 Oct (Two Tractors / Horatio): a guard set to Shadow must not still produce an approval card. When ON for an org, the tier gate stops re-deciding a registered composing email send for an agent that HAS an active email guardrail AND whose stage is in force: the guard, which already ran first in callIntegrationTool and holds or blocks by its own stage, is the verdict. A stage whose enable flag is off (Require approval or Block that is not yet enabled for the org) only observes, so it is NOT a verdict and the tier hold stays (Obi Wan on #6816). An agent with no email guardrail (or a disabled one) keeps the tier hold, so turning this on never removes the only hold an org has. Draft-sends (recipients on the stored draft) keep the tier hold in this slice. Every deferred send is still audited. Evaluated per-org. Ships dark.",
+    flagType: "boolean",
+    // Declared safe value is `false` (both gates, today's behaviour). A flag-DB read error
+    // degrades here, so a flags outage keeps the tier hold rather than silently loosening it.
+    defaultValue: false,
+    // Turning it on lets external email go out WITHOUT the tier hold where the guard allows
+    // it (e.g. Shadow), so it is a deliberate, audited per-org flip (ADR-0022 §4).
+    sensitive: true
+  },
   {
     key: "email-require-approval-enforcement",
     description: 'Enforcement gate for the `email.require_approval` guardrail (ENG-9611). That guardrail has been `default_for_new_orgs` since ~2026-05-03 and its display text promises "Require human approval before sending any email", but nothing ever read it: its only runtime path was toGuardrailForPrompt, i.e. a line in the agent CLAUDE.md. When ON for an org, a DISPATCHING email send (never a draft-create, ENG-7980) is held and routed to Human Approval regardless of recipient domain \u2014 which is what "any email" means, and is what distinguishes it from email-guard-require-approval-enabled, whose require_approval stage only intercepts a would-be DOMAIN block. Deliberately separate from the guardrail row: roughly four months of orgs already carry an inert `enforce`-level row, so reading the row alone would arm a blocking control across all of them on deploy. New orgs are no longer armed (ENG-11234). Orgs created while the ENG-9629/9675 new-org arm was live keep their org-scoped ON override until an operator flips them per org. Evaluated per-org. Ships dark.',

package/dist/{persistent-session-VGORZUKN.js → persistent-session-WHEFQHXF.js}

@@ -68,8 +68,8 @@ import {
   writeDirectChatSessionState,
   writeEgressAllowlist,
   writePersistentClaudeWrapper
-} from "./chunk-EGVRUVOF.js";
-import "./chunk-I7XCW4G6.js";
+} from "./chunk-WQQGPPQW.js";
+import "./chunk-AVM2BBSX.js";
 import "./chunk-OCMJ5E6J.js";
 import "./chunk-XWVM4KPK.js";
 import "./chunk-EL5MWGGH.js";
@@ -145,4 +145,4 @@ export {
   writeEgressAllowlist,
   writePersistentClaudeWrapper
 };
-//# sourceMappingURL=persistent-session-VGORZUKN.js.map
+//# sourceMappingURL=persistent-session-WHEFQHXF.js.map

package/dist/{responsiveness-probe-CWOTGPZC.js → responsiveness-probe-WHV2OHXM.js}

@@ -1,7 +1,7 @@
 import {
   paneLogPath
-} from "./chunk-EGVRUVOF.js";
-import "./chunk-I7XCW4G6.js";
+} from "./chunk-WQQGPPQW.js";
+import "./chunk-AVM2BBSX.js";
 import "./chunk-OCMJ5E6J.js";
 import "./chunk-XWVM4KPK.js";
 import "./chunk-EL5MWGGH.js";
@@ -802,4 +802,4 @@ export {
   readAndResetSlackReplyBindingClassifications,
   readAndResetSlackReplyTargetClassifications
 };
-//# sourceMappingURL=responsiveness-probe-CWOTGPZC.js.map
+//# sourceMappingURL=responsiveness-probe-WHV2OHXM.js.map

package/dist/{session-auth-dead-P3AXR4PR.js → session-auth-dead-H3YYJLPC.js}

@@ -1,6 +1,6 @@
 import {
   sessionTranscriptDir
-} from "./chunk-I7XCW4G6.js";
+} from "./chunk-AVM2BBSX.js";
 import "./chunk-DGUM43GV.js";
 
 // src/lib/session-auth-dead.ts
@@ -204,4 +204,4 @@ export {
   decideSessionAuthState,
   probeSessionAuth
 };
-//# sourceMappingURL=session-auth-dead-P3AXR4PR.js.map
+//# sourceMappingURL=session-auth-dead-H3YYJLPC.js.map

package/package.json

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