@integrity-labs/agt-cli 0.28.721 → 0.28.723

package/dist/{chunk-E3WGN4GX.js → chunk-ATJU3SDV.js}

@@ -17,7 +17,7 @@ import {
   rotateDailySession,
   sessionFileExists,
   todayLocalIso
-} from "./chunk-32WU3HBU.js";
+} from "./chunk-IXGIGDJG.js";
 import {
   reapOrphanChannelMcps
 } from "./chunk-XWVM4KPK.js";
@@ -4694,4 +4694,4 @@ export {
   stopAllSessionsAndWait,
   getProjectDir
 };
-//# sourceMappingURL=chunk-E3WGN4GX.js.map
+//# sourceMappingURL=chunk-ATJU3SDV.js.map

package/dist/{chunk-32WU3HBU.js → chunk-IXGIGDJG.js}

@@ -5476,6 +5476,27 @@ var FLAG_REGISTRY = [
     // carrying an inert enforce-level email.require_approval row are NOT armed on deploy.
     newOrgOverride: true
   },
+  {
+    key: "mail-rule-control-enforcement",
+    description: "Enforcement gate for the `email.mail_rules` guardrail (ENG-9640). A mail RULE is not a send: the agent installs a standing server-side instruction and the PROVIDER acts on it from then on \u2014 on mail that has not arrived yet, after the session ends, after the agent is paused or revoked, and after the integration is disconnected. So no fix to the send registry can reach it (ENG-9607 / ENG-9633 both closed the send surface), and before this guardrail NOTHING read the five rule-mutation tools at all. When ON for an org, a rule mutation whose classified disposition is held (egress / suppression / opaque) routes to Human Approval; a label-only filter passes untouched, which is what keeps the control from becoming a click-through. Deliberately separate from the guardrail row, for the ENG-9611 reason one step earlier: `email.mail_rules` is `default_for_new_orgs`, and org seeding writes those rows at `enforcement: 'enforce'`, so reading the row alone would arm a brand-new blocking control on deploy for every org created after it lands. Evaluated per-org. Ships dark.",
+    flagType: "boolean",
+    // Declared safe value is `false` (no hold). A flag-DB read error degrades here, matching
+    // `email-require-approval-enforcement`: a control that cannot verify itself must not start
+    // holding real customer traffic. Note this is the opposite of the CLASSIFIER's posture
+    // inside mail-rule-tools.ts, which fails CLOSED on an unreadable rule — the two are
+    // consistent, not contradictory. The classifier answers "is this rule dangerous?" and
+    // resolves doubt towards held; the flag answers "is this org opted in at all?" and an
+    // infrastructure blip is not an opt-in.
+    defaultValue: false,
+    // Turning it on holds real customer mail-rule changes pending a human tap, so it is a
+    // deliberate, audited per-org flip (ADR-0022 §4).
+    sensitive: true
+    // NO newOrgOverride, unlike email-require-approval-enforcement. That flag armed new orgs
+    // because its guardrail row had already sat inert for ~4 months, so the behaviour was
+    // known. This control is net-new with no soak: arming it for every new org on deploy would
+    // put a first-of-its-kind classifier in front of real customer traffic with nothing
+    // observed. Arm per-org, then revisit once there is evidence.
+  },
   {
     key: "email-guard-require-approval-enabled",
     description: "Platform enable-gate for the email-domain guardrail REQUIRE_APPROVAL stage (ENG-7939). When ON for an org, a scope at email_guard_stage=require_approval routes a send to a non-allowed domain into Human Approval (an Approve/Deny card) instead of a hard block: the rollout UI unlocks the option and the write routes accept require_approval. When OFF (default) the write routes reject require_approval and the UI shows it as not yet available, so no scope can select it. Structurally also depends on hitl-approval-routing being on (the approval broker fails closed to a hard block when routing is off). Evaluated per-org. Ships dark.",
@@ -12966,4 +12987,4 @@ export {
   peekCurrentSession,
   readDailySessionPin
 };
-//# sourceMappingURL=chunk-32WU3HBU.js.map
+//# sourceMappingURL=chunk-IXGIGDJG.js.map