@integrity-labs/agt-cli 0.28.974 → 0.28.976

package/dist/{chunk-PHPOHMSK.js → chunk-KTFN2AIB.js}

@@ -20,7 +20,7 @@ import {
   rotateDailySession,
   sessionFileExists,
   todayLocalIso
-} from "./chunk-HRHDATT5.js";
+} from "./chunk-VF5BT7BP.js";
 import {
   classifyUnanswerablePane,
   findUsageLimitResetHint,
@@ -5575,4 +5575,4 @@ export {
   stopAllSessionsAndWait,
   getProjectDir
 };
-//# sourceMappingURL=chunk-PHPOHMSK.js.map
+//# sourceMappingURL=chunk-KTFN2AIB.js.map

package/dist/{chunk-HRHDATT5.js → chunk-VF5BT7BP.js}

@@ -1303,8 +1303,8 @@ ${desc}
 
 **The delivery rule, true of every reply below:** the ONLY way a channel user
 (Slack, Telegram, Microsoft Teams, Direct Chat) receives anything from you is a
-channel reply tool call - \`slack.reply\`, \`telegram.reply\`, \`teams.reply\`,
-or \`direct_chat.reply\`. Plain text you write in your turn is NOT delivered to
+channel reply tool call - \`slack_reply\`, \`telegram_reply\`, \`teams_reply\`,
+or \`direct_chat_reply\`. Plain text you write in your turn is NOT delivered to
 the user; it goes only to your local session log. So always reply on the channel
 the message arrived on, and never answer a channel message with plain text
 alone: if you did not call a reply tool, the user received nothing.
@@ -1412,17 +1412,17 @@ ${resolvedChannels?.includes("slack") ? `
 ## Slack
 
 Slack MCP server connected. Triage per \xA7 FIRST ACTION on
-every channel message; acknowledge before slow work. Only a \`slack.reply\`
+every channel message; acknowledge before slow work. Only a \`slack_reply\`
 call reaches the user; plain text does not. Tools:
 
-- **slack.reply** \u2014 reply in a channel/thread
-- **slack.react** \u2014 an emoji reaction (sparingly \u2014 see taxonomy)
+- **slack_reply** \u2014 reply in a channel/thread
+- **slack_react** \u2014 an emoji reaction (sparingly \u2014 see taxonomy)
 - **slack_read_thread** / **slack_read_history** \u2014 re-read a thread, or a
   channel's recent messages (\xA7 Reading a conversation back)
 
 Inbound gets an automatic \u{1F440}; don't duplicate it. Prefer a reply to a reaction.
 
-**Reaction taxonomy (the only emoji for slack.react):**
+**Reaction taxonomy (the only emoji for slack_react):**
 - \u2705 (\`white_check_mark\`) \u2014 done, and a text reply isn't warranted.
 - \u274C (\`x\`) \u2014 **execution failure only**: you tried it and it errored. Never for
   "skipped", "disagree", "not addressed to me", "n/a" or "noted".
@@ -1641,7 +1641,7 @@ When you reply to a user via any channel (Slack, Telegram, direct chat, schedule
 - **Match the scope of the request.** A yes/no question gets a one-line answer; a "quick summary" gets a summary, not a dissertation. Cut any section, caveat, or restatement that doesn't directly answer what was asked.
 - **Never reference internal state.** Memory files, \`/tmp/\` paths, kanban task IDs, filesystem locations, "saved to \u2026" / "logged to \u2026" notes \u2014 these are invisible to the recipient and waste their attention. Only the deliverable content belongs in your reply.
 - **Put the full deliverable in the reply itself.** Don't tease ("I've prepared a detailed brief"), don't point "above" or "attached", and don't assume the recipient can see intermediate tool output. If they asked for a brief, the brief goes verbatim into your reply.
-- **If the deliverable is a file** (PDF, CSV, screenshot, export, report), upload it with the channel's file-upload tool (e.g. \`slack.upload_file\`) rather than describing its path. The recipient cannot access your filesystem.
+- **If the deliverable is a file** (PDF, CSV, screenshot, export, report), upload it with the channel's file-upload tool (e.g. \`slack_upload_file\`) rather than describing its path. The recipient cannot access your filesystem.
 
 ## Standards
 
@@ -7378,11 +7378,18 @@ var FLAG_REGISTRY = [
   },
   {
     key: "ip-allowlist-enforce-admin-debug",
-    description: "ENG-10594 - whether the IP allowlist on the admin-debug surface (/admin/debug/*, including the deliberately unauthenticated POST /admin/debug/token that exchanges a tlk_ key) REFUSES, or merely observes. OFF (default) = shadow: every request is still evaluated and logged with verdict=admit or verdict=would-refuse, and nothing is ever rejected. ON = a caller whose platform-attested source address is outside AGT_IP_ALLOWLIST_ADMIN_DEBUG gets a bare 403. THE SSM PARAMETER IS A SECOND LEVER AND BOTH ARE NEEDED: with the list unset this flag does nothing, because an unconfigured allowlist admits everyone by design. Arm in that order - populate the list, read the shadow logs until the would-refuse set is understood, then flip this. Deliberately global (evaluated with an empty context): the middleware runs BEFORE authentication, so there is no verified org to scope by, and taking one from an unverified request would let a caller choose its own enforcement posture. Separate from the mcp flag on purpose - see that entry.",
+    description: "ENG-10594 - whether the IP allowlist on the admin-debug surface (/admin/debug/*, including the deliberately unauthenticated POST /admin/debug/token that exchanges a tlk_ key) REFUSES, or merely observes. OFF (default) = shadow: every request is still evaluated and logged with verdict=admit or verdict=would-refuse, and nothing is ever rejected. ON = a caller whose platform-attested source address is outside AGT_IP_ALLOWLIST_ADMIN_DEBUG gets a bare 403. THE SSM PARAMETER IS A SECOND LEVER AND BOTH ARE NEEDED: with the list unset this flag does nothing, because an unconfigured allowlist admits everyone by design. Arm in that order - populate the list, read the shadow logs until the would-refuse set is understood, then flip this. Deliberately global (evaluated with an empty context): the middleware runs BEFORE authentication, so there is no verified org to scope by, and taking one from an unverified request would let a caller choose its own enforcement posture. There is deliberately NO counterpart flag for the per-agent MCP surface: that one is shadow-only structurally (its ENFORCE_FLAG entry is null), so arming this one does not and cannot arm that one. See the comment below this entry for why.",
     flagType: "boolean",
-    // Shadow. The measurement comes first: nobody yet knows the real set of
-    // staff addresses, and arming against a guess locks you out of the very
-    // tool you would use to diagnose the lockout.
+    // Shadow. The measurement comes first - and ENG-10664 corrected what the
+    // measurement is OF. This comment used to say "nobody yet knows the real set
+    // of staff addresses": there is no such set. Measured over 48h, all 315
+    // requests to this surface came from ONE address, the agt-hosts AZ-2a NAT
+    // EIP - an AGENT calling the debug_* tools, not a person. The decided policy
+    // is that it stays that way (admin-debug is only ever reached from our own
+    // NAT gateways). So the pre-arm check is not "does my laptop appear" but
+    // "is every NAT EIP in the list", because an AZ whose NAT has not yet
+    // carried a debug_* call is absent from the log and would be refused the
+    // instant this flips. See docs/runbooks/ip-allowlist-rollout.md step 3.
     defaultValue: false,
     // Arming it changes who can reach production diagnostics. Worth one
     // confirmation.
@@ -7397,20 +7404,34 @@ var FLAG_REGISTRY = [
   // ENFORCE_FLAG (packages/api/src/middleware/ip-allowlist.ts) is null, so no
   // flag is consulted and no flag flip can arm it.
   //
-  // Why it is not simply a second flag defaulting false: most of that surface's
-  // callers have no allowlistable address at all. Per ADR-0032 only hosts in the
-  // agt-hosts account egress through stable NAT EIPs; a host with
-  // provision_source `self` or `customer-ec2`, or any BYO account, egresses from
-  // an address the control plane cannot know. Arming against that population
-  // black-holes a customer's whole fleet, and per
-  // docs/runbooks/composio-allowlist-rollout.md this class of change has no
+  // Why it is not simply a second flag defaulting false (CORRECTED, ENG-10664):
+  //
+  // This comment used to say the callers are agent HOSTS, most of which have no
+  // allowlistable address per ADR-0032. That is the wrong caller. Agent hosts do
+  // not call this surface at all: its handler's first act is
+  // validateMcpAccessToken() against `mcp_oauth_tokens` (routes/mcp.ts:87, token
+  // check at :91), so a host JWT is rejected outright - routes/host-runtime.ts
+  // :33421 says so in as many words, which is why the ENG-4724 /host/* twins
+  // exist. The caller set is remote MCP OAuth clients, structurally.
+  //
+  // The conclusion is unchanged and ONLY the reason has moved. Allowlisting this
+  // surface would mean pinning a THIRD PARTY's egress ranges rather than our own
+  // NAT EIPs - a different control, a different owner, a different failure mode:
+  // they move a range and agent MCP access breaks with no signal on our side.
+  // Per docs/runbooks/composio-allowlist-rollout.md this class of change has no
   // fleet-level undo. A flag would leave that one toggle away during an
   // incident, from someone who had just armed the admin-debug surface and
   // reasonably assumed the pair moved together. Requiring a code change puts
   // review in front of an irreversible action, which is the right price.
   //
-  // If the shadow data ever shows the population IS allowlistable, adding the
-  // flag here and a key in ENFORCE_FLAG is a small, deliberate diff.
+  // Keeping the false rationale would have been worse than having none: a reader
+  // who checked it would find it does not hold and might "fix" it by adding the
+  // flag. That is the failure this rewrite exists to prevent.
+  //
+  // If we ever DECIDE to take on that third-party dependency deliberately,
+  // adding the flag here and a key in ENFORCE_FLAG is a small diff - but it is a
+  // decision to own someone else's egress, not a discovery that the population
+  // was allowlistable all along.
 ];
 var REGISTRY_BY_KEY = new Map(FLAG_REGISTRY.map((definition) => [definition.key, definition]));
 function getFlagDefinition(key) {
@@ -15179,4 +15200,4 @@ export {
   peekCurrentSession,
   readDailySessionPin
 };
-//# sourceMappingURL=chunk-HRHDATT5.js.map
+//# sourceMappingURL=chunk-VF5BT7BP.js.map