@integrity-labs/agt-cli 0.20.3 → 0.20.6

package/dist/bin/agt.js

@@ -50,7 +50,7 @@ import {
   success,
   table,
   warn
-} from "../chunk-INN5PXU3.js";
+} from "../chunk-SOYIZEZG.js";
 
 // src/bin/agt.ts
 import { join as join10 } from "path";
@@ -3734,7 +3734,7 @@ import { execFileSync, execSync } from "child_process";
 import { existsSync as existsSync5, realpathSync } from "fs";
 import chalk17 from "chalk";
 import ora15 from "ora";
-var cliVersion = true ? "0.20.3" : "dev";
+var cliVersion = true ? "0.20.6" : "dev";
 async function fetchLatestVersion() {
   const host2 = getHost();
   if (!host2) return null;
@@ -4266,7 +4266,7 @@ function handleError(err) {
 }
 
 // src/bin/agt.ts
-var cliVersion2 = true ? "0.20.3" : "dev";
+var cliVersion2 = true ? "0.20.6" : "dev";
 var program = new Command();
 program.name("agt").description("Augmented CLI \u2014 agent provisioning and management").version(cliVersion2).option("--json", "Emit machine-readable JSON output (suppress spinners and colors)").option("--skip-update-check", "Skip the automatic update check on startup");
 program.hook("preAction", (thisCommand) => {

package/dist/{chunk-INN5PXU3.js → chunk-SOYIZEZG.js}

@@ -3307,6 +3307,60 @@ are defined in \`CHARTER.md\`.
 - Enforcement: Follow CHARTER.md constraints strictly.
 - Tools: MCP tools available in your session are authorized. Call them when the task needs them. If a tool returns a **permission denial** (explicit "not authorized" / 403-with-policy-message), don't retry it \u2014 that's a guardrail signal. Every other error (timeout, 401, 5xx, "expired", "stale", network, "cache", "auth refresh needed") MUST be re-confirmed by an actual fresh tool call before you tell the user about it. See \xA7 Integration trust calibration.
 
+## Approval acknowledgements
+
+This rule applies to **any** deferred-approval tool you call \u2014 anything that
+can return \`pending\` and resolve later via a notification rather than
+inline (AWS access grants, channel posts that need a human OK, deploy
+gates, budget overrides, and any future broker that follows the same
+shape). Skill bodies and individual tool descriptions repeat the rule
+for their own surface; this section is the always-on version that
+covers every broker without exception.
+
+**Acknowledge before acting \u2014 on both sides of the round-trip.**
+
+1. **On the initial \`pending\` response.** Post a brief, jargon-free
+   one-liner in the user's channel that names the task and what is being
+   waited on ("Requesting access to the prod-data account so I can pull
+   that report \u2014 pinged an admin to approve, will resume the moment it
+   lands"). Save whatever id the tool returned, return control, **do
+   not poll**. The broker will push the resolution to you.
+
+2. **When the resolution notification arrives.** The notification lands
+   in direct-chat, but the body will include an \`Original
+   conversation:\` line naming the channel/thread the user kicked the
+   request off in. Before you call any follow-up tool \u2014 credential
+   fetch, deploy execute, message send, etc. \u2014 post a single short line
+   **in that original conversation** acknowledging the outcome:
+
+   - On approve: name the task and signal you're about to act \u2014
+     "Approval came through \u2014 kicking off <the task> now."
+   - On deny: name the task, paraphrase the reason, and ask how the
+     user wants to proceed \u2014 "Couldn't get approval for <the task>:
+     <paraphrased reason> \u2014 let me know how you'd like to proceed."
+
+   Only after that ack do you call the follow-up tool (approve case) or
+   stop (deny case). If the notification body has no
+   \`Original conversation:\` line, fall back to direct-chat.
+
+**Rules of thumb across all approval flows:**
+
+- No broker vocabulary in user messages. "Grant", "grant_id",
+  "broker", "secret_ref", "approval_request_id", "STS", any
+  underlying tool name \u2014 none of these reach the user. Talk about the
+  task and the resource (account name, channel name, service name),
+  not the plumbing.
+- Never paste a request/grant UUID into user-facing prose. It's
+  operator metadata; users can't act on it.
+- If the broker also reports a notification-delivery failure
+  (\`notification_status: failed\` or equivalent \u2014 meaning no human
+  was paged), surface that as its own problem in plain language, not
+  as a silent assumption that approval will eventually arrive.
+- Going silent between the request and the resolution \u2014 or between the
+  resolution and the work \u2014 defeats the human-in-the-loop signal the
+  broker pattern is meant to preserve. Lead with the outcome before
+  doing the work.
+
 ## Integration trust calibration
 
 **This rule overrides everything except the FIRST ACTION dispatch decision.** Whenever you
@@ -9327,4 +9381,4 @@ export {
   managerInstallSystemUnitCommand,
   managerUninstallSystemUnitCommand
 };
-//# sourceMappingURL=chunk-INN5PXU3.js.map
+//# sourceMappingURL=chunk-SOYIZEZG.js.map