@integrity-labs/agt-cli 0.28.722 → 0.28.724

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

@@ -36563,6 +36563,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.",

package/dist/mcp/index.js

@@ -43524,6 +43524,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.",

package/dist/mcp/origami.js

@@ -42295,6 +42295,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.",

package/dist/mcp/slack-channel.js

@@ -36815,6 +36815,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.",

package/dist/mcp/telegram-channel.js

@@ -36971,6 +36971,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.",
@@ -38970,6 +38991,7 @@ var TELEGRAM_EGRESS_TOOLS = /* @__PURE__ */ new Set([
   "telegram.send_message",
   "telegram.react",
   "telegram.upload_file",
+  "telegram.consume",
   "channel_request_input"
 ]);
 
@@ -42037,6 +42059,20 @@ function clearTelegramMarkerFileWithHeal(fullPath) {
   } catch {
   }
 }
+function clearTelegramMarkerFileSilently(fullPath) {
+  let marker = null;
+  try {
+    marker = JSON.parse(readFileSync14(fullPath, "utf-8"));
+  } catch {
+  }
+  if (marker?.chat_id) {
+    cancelScheduledUndeliverableNotice(marker.chat_id);
+  }
+  try {
+    if (existsSync9(fullPath)) unlinkSync8(fullPath);
+  } catch {
+  }
+}
 function markTelegramMarkerSeenInPlace(fullPath) {
   markTelegramMarkerEngagedInPlace(fullPath, { promise: false });
 }
@@ -42853,6 +42889,15 @@ function clearPendingMessage(chatId, cutoffMs = Number.POSITIVE_INFINITY) {
     cutoffMs
   );
 }
+function consumePendingMessage(chatId, cutoffMs = Number.POSITIVE_INFINITY) {
+  if (!PENDING_INBOUND_DIR || !existsSync9(PENDING_INBOUND_DIR)) return;
+  clearAllTelegramPendingMarkersForChat(
+    PENDING_INBOUND_DIR,
+    chatId,
+    clearTelegramMarkerFileSilently,
+    cutoffMs
+  );
+}
 function markSeenPendingMessage(chatId, cutoffMs = Number.POSITIVE_INFINITY) {
   if (!PENDING_INBOUND_DIR || !existsSync9(PENDING_INBOUND_DIR)) return;
   markSeenAllTelegramPendingMarkersForChat(
@@ -42969,6 +43014,24 @@ mcp.setRequestHandler(ListToolsRequestSchema, async () => ({
         required: ["chat_id", "text"]
       }
     },
+    {
+      name: "telegram.consume",
+      description: "Acknowledge Telegram message(s) you handled WITHOUT sending a reply \u2014 a message you deliberately did not answer because a standing rule forbids engaging in that chat, or one that only updated state. Pass the chat_id from the <channel> tag. If you send a telegram.reply you do NOT also need to consume: the reply already acknowledges the message. Without one of the two, a silently-handled message is treated as undelivered and is re-delivered to you indefinitely. Clears the chat, not one message \u2014 that is Telegram's conversation grain \u2014 and only messages received up to the one you are answering, so an inbound that arrives while you are deciding is never discarded unseen.",
+      inputSchema: {
+        type: "object",
+        properties: {
+          chat_id: {
+            type: "string",
+            description: "Telegram chat ID (from the chat_id attribute in the <channel> tag)"
+          },
+          reason: {
+            type: "string",
+            description: 'Short note on WHY no reply was sent (e.g. "owner restricts replies to his own chat"). Logged, not sent to the chat. A consume with no reason is indistinguishable from a dropped message when someone reads the log later.'
+          }
+        },
+        required: ["chat_id"]
+      }
+    },
     {
       name: "telegram.send_message",
       description: "Send a new Telegram message to an arbitrary chat (agent-initiated, not a reply)",
@@ -43181,6 +43244,29 @@ mcp.setRequestHandler(CallToolRequestSchema, async (req) => {
       return { content: [{ type: "text", text: `Telegram ${method} error: ${err.message}` }], isError: true };
     }
   }
+  if (name === "telegram.consume") {
+    const { chat_id, reason } = args;
+    if (!chat_id) {
+      return {
+        content: [{ type: "text", text: "telegram.consume requires chat_id (from the <channel> tag)." }],
+        isError: true
+      };
+    }
+    const cutoffMs = Date.now();
+    consumePendingMessage(chat_id, cutoffMs);
+    process.stderr.write(
+      `telegram-channel(${AGENT_CODE_NAME}): consumed chat=${redactId(chat_id)} cutoff=${new Date(cutoffMs).toISOString()} reason=${reason ? JSON.stringify(reason) : "(none given)"}
+`
+    );
+    return {
+      content: [
+        {
+          type: "text",
+          text: `Acknowledged chat ${chat_id} without replying. Its pending inbounds up to now are settled, so they will not be re-delivered. Anything that arrives from here is still delivered normally.`
+        }
+      ]
+    };
+  }
   if (name === "telegram.reply" || name === "telegram.send_message") {
     const { chat_id, text, reply_to_message_id, interim } = args;
     if (ALLOWED_CHATS.size > 0 && !ALLOWED_CHATS.has(chat_id)) {

package/dist/{persistent-session-7NXQBNZB.js → persistent-session-CEC5KESY.js}

@@ -46,8 +46,8 @@ import {
   writeDirectChatSessionState,
   writeEgressAllowlist,
   writePersistentClaudeWrapper
-} from "./chunk-E3WGN4GX.js";
-import "./chunk-32WU3HBU.js";
+} from "./chunk-ATJU3SDV.js";
+import "./chunk-IXGIGDJG.js";
 import "./chunk-XWVM4KPK.js";
 export {
   EGRESS_BASELINE_DOMAINS,
@@ -98,4 +98,4 @@ export {
   writeEgressAllowlist,
   writePersistentClaudeWrapper
 };
-//# sourceMappingURL=persistent-session-7NXQBNZB.js.map
+//# sourceMappingURL=persistent-session-CEC5KESY.js.map

package/dist/{responsiveness-probe-UDFTVXOW.js → responsiveness-probe-J3VB4U4W.js}

@@ -1,7 +1,7 @@
 import {
   paneLogPath
-} from "./chunk-E3WGN4GX.js";
-import "./chunk-32WU3HBU.js";
+} from "./chunk-ATJU3SDV.js";
+import "./chunk-IXGIGDJG.js";
 import "./chunk-XWVM4KPK.js";
 
 // src/lib/responsiveness-probe.ts
@@ -745,4 +745,4 @@ export {
   readAndResetSlackReplyBindingClassifications,
   readAndResetSlackReplyTargetClassifications
 };
-//# sourceMappingURL=responsiveness-probe-UDFTVXOW.js.map
+//# sourceMappingURL=responsiveness-probe-J3VB4U4W.js.map

package/dist/{session-auth-dead-DQW6NXDX.js → session-auth-dead-YQHE3WKV.js}

@@ -1,6 +1,6 @@
 import {
   sessionTranscriptDir
-} from "./chunk-32WU3HBU.js";
+} from "./chunk-IXGIGDJG.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-DQW6NXDX.js.map
+//# sourceMappingURL=session-auth-dead-YQHE3WKV.js.map

package/package.json

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