@integrity-labs/agt-cli 0.27.51 → 0.27.53

package/dist/{chunk-5S322IC7.js → chunk-4ZKBMJ3Y.js}

@@ -1,7 +1,7 @@
 import {
   claudeModelAlias,
   isClaudeFastMode
-} from "./chunk-UOHGOS3O.js";
+} from "./chunk-2NOH5XB5.js";
 import {
   reapOrphanChannelMcps
 } from "./chunk-XWVM4KPK.js";
@@ -1125,4 +1125,4 @@ export {
   stopAllSessionsAndWait,
   getProjectDir
 };
-//# sourceMappingURL=chunk-5S322IC7.js.map
+//# sourceMappingURL=chunk-4ZKBMJ3Y.js.map

package/dist/{chunk-Y4KVZGPE.js → chunk-GPBGRRCV.js}

@@ -9,7 +9,7 @@ import {
   parseDeliveryTarget,
   registerFramework,
   wrapScheduledTaskPrompt
-} from "./chunk-UOHGOS3O.js";
+} from "./chunk-2NOH5XB5.js";
 
 // ../../packages/core/dist/integrations/registry.js
 var INTEGRATION_REGISTRY = [
@@ -3068,33 +3068,46 @@ acknowledge before you start.
 - **FAST (< 60s):** handle inline. Reply via the channel tool
   (slack.reply / telegram.reply / directchat.reply) and end your turn.
 
-- **SLOW (\u2265 60s):** dispatch.
+- **SLOW (\u2265 60s):** acknowledge first, then handle inline.
   1. Send a one-line acknowledgement via the channel tool \u2014 short, warm,
      and tell the user you'll come back. Example shape (don't copy verbatim,
      match your voice): "On it \u2014 this'll take a minute or two, I'll ping
      when it's done."
-  2. Invoke the \`channel-message-handler\` subagent (Task tool, with
-     \`subagent_type: channel-message-handler\`) with the full original
-     message text plus the **channel-specific routing keys** the reply
-     tool needs: Slack threads \u2192 \`{ channel_id, thread_ts }\`; Slack
-     non-thread DMs \u2192 \`{ channel_id }\`; Telegram \u2192 \`{ chat_id, message_id }\`;
-     Direct Chat \u2192 \`{ conversation_id }\`. Pass these verbatim from the
-     inbound \`<channel>\` tag \u2014 don't substitute a generic \`message_ts\`,
-     since only Slack threads use it. The subagent will do the actual
-     work and post the real reply itself.
-  3. End your turn. **Do NOT call slack.reply / telegram.reply with the
-     full result yourself** \u2014 that's the subagent's job.
-
-**Why this matters more than any other instruction below:** if you handle
-slow requests inline, you go silent for 60+ seconds while operators send
-follow-up messages that queue behind you. Dispatching keeps you free to
-acknowledge new pings. The kanban-tracking-link convention, work-management
-"create a task" guidance, and Slack reply patterns ALL apply to fast
-inline replies \u2014 they do NOT replace this dispatch decision.
-
-If the work turns out to be unexpectedly slow after you started inline,
-finish the current sub-step, then dispatch the rest. Don't apologise for
-mid-task switching \u2014 operators care about responsiveness, not consistency.
+  2. Do the work yourself in this same session. Use whatever tools you
+     need (MCP, skills, file reads, etc.) \u2014 your parent session has the
+     full MCP surface bound.
+  3. Reply with the result via the channel tool (\`slack.reply\` /
+     \`telegram.reply\` / \`directchat.reply\`), addressing the same thread
+     / chat / conversation you acknowledged in step 1.
+
+> **Why inline and not sub-agent dispatch right now:** there is an
+> upstream Claude Code bug
+> ([anthropics/claude-code#64909](https://github.com/anthropics/claude-code/issues/64909))
+> where sub-agents dispatched via the Task tool with an explicit
+> \`tools:\` allowlist (which is the shape \`channel-message-handler\`
+> uses) get an **empty MCP tool registry** \u2014 every \`mcp__*\` call
+> returns "No such tool available", including the channel reply tools.
+> Dispatching a slow channel reply to \`channel-message-handler\` will
+> therefore silently fail to land: you'd post the one-line ack, the
+> sub-agent would do the analysis fine, but its \`slack.reply\` call
+> would error and the user would never see the substantive reply.
+> Empirically confirmed 2026-06-03 with a 6-tool probe: 0/6 MCP tools
+> bound inside \`channel-message-handler\`. Until Anthropic ships the
+> fix, handling slow channel replies inline is the only working path.
+
+**Why this triage decision still matters more than any other instruction
+below:** if you skip the acknowledgement and just dive into slow work
+silently, operators send follow-up messages that queue behind you
+wondering whether you got the original. The ack-first-then-work pattern
+keeps users oriented. The kanban-tracking-link convention,
+work-management "create a task" guidance, and Slack reply patterns ALL
+apply to whatever you post \u2014 the ack and the eventual full reply alike.
+
+If the work turns out to be unexpectedly slow after you started inline
+without acknowledging (because you thought it was a FAST request), post
+a quick "this is taking longer than I expected, still working" line
+rather than going silent. Operators care about responsiveness, not
+consistency.
 
 ## Background dispatch for non-channel work
 
@@ -3113,13 +3126,14 @@ Once Anthropic ships the fix, \`augmented-worker\` becomes preferred again
 (restricted tool surface for safety + working MCP binding); the dispatch
 recommendation here will flip back automatically.
 
-The channel-message triage above is **not** changed by this note \u2014 slow
-channel replies still dispatch via \`channel-message-handler\` per
-\xA7 FIRST ACTION. Be aware that \`channel-message-handler\` shares the
-explicit-allowlist shape and so is subject to the same upstream bug; if
-you observe a dispatched channel reply silently failing to land,
-acknowledge the original message inline yourself and surface the gap
-rather than attempting another sub-agent dispatch.
+For slow **channel** replies, see \xA7 FIRST ACTION above \u2014 those are
+currently handled inline (not dispatched) because \`channel-message-handler\`
+shares the explicit-allowlist shape and so suffers the same upstream
+bug. Empirically confirmed 2026-06-03 on agt-aws-1 with a 6-tool probe:
+0/6 MCP tools bound inside \`channel-message-handler\` (matching the
+\`augmented-worker\` result). When Anthropic ships the upstream fix, both
+named sub-agents will work again and the FIRST ACTION triage will switch
+back to dispatch.
 
 ${activeTasksSection}${personalitySection}## Identity
 
@@ -3149,8 +3163,10 @@ ${resolvedChannels?.includes("slack") ? `
 
 You have a Slack MCP server connected. **First, see \xA7 FIRST ACTION on
 every channel message: triage** at the top of this document \u2014 decide
-fast vs slow before anything else, and dispatch slow work via
-\`channel-message-handler\` rather than handling it inline.
+fast vs slow before anything else, then acknowledge inline before
+diving into slow work (sub-agent dispatch for channel replies is
+currently disabled due to an upstream Claude Code bug; see the FIRST
+ACTION section for the full rationale).
 
 For fast requests, respond directly in the conversation. You can also
 proactively use:
@@ -7147,4 +7163,4 @@ export {
   managerInstallSystemUnitCommand,
   managerUninstallSystemUnitCommand
 };
-//# sourceMappingURL=chunk-Y4KVZGPE.js.map
+//# sourceMappingURL=chunk-GPBGRRCV.js.map