@integrity-labs/agt-cli 0.28.503 → 0.28.504

package/dist/{chunk-GBSMIV4P.js → chunk-HEUDF73X.js}

@@ -4977,7 +4977,36 @@ var OAUTH_PROVIDERS = {
     // products/commerce/analytics per CS-1427). Best-effort + idempotent: an
     // unknown/unscoped name is logged and skipped by the proxy, and the
     // toolAllowlist above still caps what is actually callable.
-    preEnableToolsets: ["courses", "products", "commerce", "analytics", "pages", "themes"]
+    //
+    // ENG-8392: `contacts` + `emails` were missing, so thirteen allowlisted
+    // tools were unreachable by construction — list_tags, create_tag,
+    // tag_contact, untag_contact, list_segments, create_segment,
+    // update_segment (contacts) and list_broadcasts, get_broadcast,
+    // create_broadcast, list_sequences, get_sequence, create_sequence
+    // (emails). A customer agent was blocked on exactly those.
+    //
+    // These two ids are Kajabi's OWN spelling, not ours: the server names the
+    // toolset in its rejection, e.g. `list_tags` returns
+    //   "The 'contacts' toolset is not active. Call enable_toolset with
+    //    name: 'contacts' to activate it first."
+    // and `list_sequences` returns the same with 'emails'. Sourced that way
+    // deliberately — a wrong id here is logged and SKIPPED by the proxy, so a
+    // guess would look applied and change nothing.
+    //
+    // Why this went unnoticed for four rounds: `get_contacts_analytics` lives
+    // in the `analytics` group, which we already pre-enable. So the contacts
+    // family read as partly alive (you could see a site's contact count and
+    // growth curve) while every tag and segment call failed.
+    preEnableToolsets: [
+      "courses",
+      "products",
+      "commerce",
+      "analytics",
+      "pages",
+      "themes",
+      "contacts",
+      "emails"
+    ]
   },
   "notion-cli": {
     // Notion's public OAuth app. Tokens are workspace-scoped and long-lived —
@@ -9961,6 +9990,23 @@ var FLAG_REGISTRY = [
     // safety control, so mutations require explicit confirmation.
     sensitive: true
   },
+  {
+    key: "docker-hygiene",
+    description: "Manager-side docker hygiene on Docker-isolated hosts (ENG-8401): off = no-op, reap-superseded = after a successful agt-runtime retag, remove the prior untagged agt-runtime images that retag orphaned (Layer 1), full = reap-superseded plus a daily dangling-only image+builder prune (Layer 2). agt-runtime:latest and the just-pulled image are never removed and -a/--volumes are never used. Read host-side via hostFlagStore (getString); ships dark.",
+    flagType: "enum",
+    allowedValues: ["off", "reap-superseded", "full"],
+    // Declared safe value is `off`: this flag introduces NEW janitorial behaviour
+    // (the pre-flag compiled behaviour is "never reap"), so off preserves fleet
+    // behaviour on rollout. Not `sensitive` — weakening it (full → off) only stops
+    // cleanup; it relaxes no safety/enforcement control. No envVar by design: this
+    // gate is flag-managed only, with no operator env override.
+    defaultValue: "off",
+    // New host-side reader (ENG-8401): its consumer lands in the agt-cli build
+    // this PR publishes (auto-publish patch-bumps from npm's current 0.28.503 →
+    // 0.28.504), so a flip only takes effect on hosts running >= that version.
+    // Best-effort reach estimate only; not part of the schema fingerprint.
+    since: "0.28.504"
+  },
   {
     key: "composio-hitl-mode",
     description: "Composio managed-toolkits HITL gate (ENG-6027): off = kill switch, shadow = resolve + audit the tier decision but never block, enforce = block write_high_risk+ calls and route them to Human Approval (an Approve/Deny card). Since ENG-7828 enforce ALWAYS routes to a Human Approval card by default; set hitl-approval-routing=off to make enforce a hard block with no approval instead. Per-org rollout from the admin Feature Flags page; ENG-7672 migrated this off the fleet-wide COMPOSIO_HITL_MODE env var.",
@@ -14778,4 +14824,4 @@ export {
   stopAllSessionsAndWait,
   getProjectDir
 };
-//# sourceMappingURL=chunk-GBSMIV4P.js.map
+//# sourceMappingURL=chunk-HEUDF73X.js.map