@integrity-labs/agt-cli 0.28.1054 → 0.28.1056

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

@@ -30595,7 +30595,7 @@ var integration_metadata_v1_default = {
       type: "string",
       format: "uri",
       pattern: "^https://",
-      description: "Absolute HTTPS URL the broker uses as the vendor API root. Required when any tool descriptor relies on http_templater (i.e. whenever `tools[]` is non-empty)."
+      description: "Absolute HTTPS URL the broker uses as the vendor API root. Required when any tool descriptor relies on http_templater (i.e. whenever `tools[]` is non-empty), unless the definition declares a per-install `base_url_template` instead (CS-1863)."
     },
     auth_scheme: {
       type: "string",
@@ -30629,6 +30629,22 @@ var integration_metadata_v1_default = {
         }
       }
     },
+    base_url_template: {
+      type: "object",
+      description: "A PER-INSTALL API host (CS-1863), for vendors with one host per customer (Storrito: https://<ORG_UUID>.storrito.com/api/v1). Used when base_url is absent. `template` holds exactly one `{value}` placeholder in its host; the value is read from the install's config[config_key], must match value_pattern in full, and the built host must be exactly <value>.<host_suffix> over https. Resolved and re-validated at call time by resolveIntegrationBaseUrl.",
+      additionalProperties: false,
+      required: ["template", "config_key", "value_pattern", "host_suffix"],
+      properties: {
+        template: { type: "string", pattern: "^https://\\{value\\}\\.[^{}]+$" },
+        config_key: { type: "string", pattern: "^[a-z][a-z0-9_]*$" },
+        value_pattern: { type: "string", minLength: 1 },
+        host_suffix: { type: "string", pattern: "^[a-z0-9.-]+\\.[a-z]{2,}$" }
+      }
+    },
+    redirect_means_auth_failure: {
+      type: "boolean",
+      description: "The vendor answers a rejected credential with a REDIRECT (Storrito: a 302 to its login page) rather than a 401. A redirected non-GET call is never followed (vendor-fetch.ts) and always fails; with this set, it is also treated like a 401 and the install is flagged for re-auth."
+    },
     tools: {
       type: "array",
       description: "Auto-loaded MCP tool descriptors. Each entry produces one MCP tool entry per supported runtime scope.",
@@ -30640,7 +30656,10 @@ var integration_metadata_v1_default = {
     properties: { tools: { type: "array", minItems: 1 } },
     required: ["tools"]
   },
-  then: { required: ["base_url"] },
+  then: {
+    description: "A tool needs an API root: a fixed base_url, or a per-install base_url_template (CS-1863).",
+    anyOf: [{ required: ["base_url"] }, { required: ["base_url_template"] }]
+  },
   not: {
     description: "auth_scheme and auth_encoding are mutually exclusive (ENG-10524). The templater refuses the combination on every call, so catalog validation refuses it first.",
     required: ["auth_scheme", "auth_encoding"]
@@ -37838,7 +37857,7 @@ var FLAG_REGISTRY = [
   },
   {
     key: "email-require-approval-enforcement",
-    description: 'Enforcement gate for the `email.require_approval` guardrail (ENG-9611). That guardrail has been `default_for_new_orgs` since ~2026-05-03 and its display text promises "Require human approval before sending any email", but nothing ever read it: its only runtime path was toGuardrailForPrompt, i.e. a line in the agent CLAUDE.md. When ON for an org, a DISPATCHING email send (never a draft-create, ENG-7980) is held and routed to Human Approval regardless of recipient domain \u2014 which is what "any email" means, and is what distinguishes it from email-guard-require-approval-enabled, whose require_approval stage only intercepts a would-be DOMAIN block. Deliberately separate from the guardrail row: roughly four months of orgs already carry an inert `enforce`-level row, so reading the row alone would arm a blocking control across all of them on deploy. New orgs are armed by an org-scoped override written at org creation; existing orgs stay off until an operator flips them. Evaluated per-org. Ships dark.',
+    description: 'Enforcement gate for the `email.require_approval` guardrail (ENG-9611). That guardrail has been `default_for_new_orgs` since ~2026-05-03 and its display text promises "Require human approval before sending any email", but nothing ever read it: its only runtime path was toGuardrailForPrompt, i.e. a line in the agent CLAUDE.md. When ON for an org, a DISPATCHING email send (never a draft-create, ENG-7980) is held and routed to Human Approval regardless of recipient domain \u2014 which is what "any email" means, and is what distinguishes it from email-guard-require-approval-enabled, whose require_approval stage only intercepts a would-be DOMAIN block. Deliberately separate from the guardrail row: roughly four months of orgs already carry an inert `enforce`-level row, so reading the row alone would arm a blocking control across all of them on deploy. New orgs are no longer armed (ENG-11234). Orgs created while the ENG-9629/9675 new-org arm was live keep their org-scoped ON override until an operator flips them per org. Evaluated per-org. Ships dark.',
     flagType: "boolean",
     // Declared safe value is `false` (no hold). A flag-DB read error degrades here, so a flags
     // outage can never silently start holding real customer email — the same fail-OPEN posture
@@ -37848,36 +37867,15 @@ var FLAG_REGISTRY = [
     defaultValue: false,
     // Turning it on holds real customer email pending a human tap, so it is a deliberate,
     // audited per-org flip (ADR-0022 §4).
-    sensitive: true,
-    // ENG-9629: NEW orgs are armed on. Declared here rather than hardcoded in the
-    // seeding code, so `listNewOrgFlagOverrides()` is the one answer to "which flags
-    // does a new org get". `defaultValue` stays false so the ~4 months of orgs already
-    // carrying an inert enforce-level email.require_approval row are NOT armed on deploy.
-    // ENG-9675: EVERY creation path, self-serve included.
-    //
-    // ENG-9630 had restricted this to API-created orgs on the grounds that a
-    // self-serve org has no way of being TOLD about a held send — no Slack
-    // alert channel is wired at signup. That reasoning was wrong, and the check
-    // behind it was incomplete: it confirmed an in-console page exists at
-    // /organization/approvals and stopped, without looking at the dispatch path.
-    //
-    // `routeBlockedCallToApproval` has three dispatchers, and the Direct Chat
-    // one (lib/integration-broker-approval-direct-chat.ts, ENG-7680) is the
-    // universal fallback — "every managed agent always has a Direct Chat session
-    // its operator/manager watches in the Console ... usable out of the box with
-    // no per-org approval-route setup and no Slack dependency". It posts into a
-    // thread keyed on the approval_requests.id and correlates the manager's
-    // reply back through tryCaptureDirectChatApproval, so a self-serve org has
-    // both a zero-config delivery channel AND a reply path.
-    //
-    // With the stated blocker gone, the guardrail's own promise — "before
-    // sending any email" — applies to the organizations with the LEAST operator
-    // oversight exactly as it does to the rest.
-    //
-    // Existing self-serve orgs are deliberately NOT armed by this: newOrgOverride
-    // is applied at creation, and nothing backfills. Extending it to them is a
-    // separate decision with a comms obligation.
-    newOrgOverride: true
+    sensitive: true
+    // No newOrgOverride (ENG-11234). ENG-9629/ENG-9675 armed this on EVERY new org at
+    // creation, so every org created since then held each dispatching send, internal
+    // recipients included, behind a human tap. In practice that stalled real work: Pedders
+    // (CS-1904/1908/1910) had an agent's emails to its own principal expire unapproved,
+    // because "any email" includes the person the agent works for. New orgs now start at
+    // `defaultValue` (off) like every other org; turning it on is the deliberate, audited
+    // per-org flip `sensitive: true` already describes. Orgs armed by the old override keep
+    // their override row; nothing here disarms them (that is an operator decision per org).
   },
   {
     key: "mail-rule-control-enforcement",

package/dist/mcp/index.js

@@ -23199,7 +23199,7 @@ var integration_metadata_v1_default = {
       type: "string",
       format: "uri",
       pattern: "^https://",
-      description: "Absolute HTTPS URL the broker uses as the vendor API root. Required when any tool descriptor relies on http_templater (i.e. whenever `tools[]` is non-empty)."
+      description: "Absolute HTTPS URL the broker uses as the vendor API root. Required when any tool descriptor relies on http_templater (i.e. whenever `tools[]` is non-empty), unless the definition declares a per-install `base_url_template` instead (CS-1863)."
     },
     auth_scheme: {
       type: "string",
@@ -23233,6 +23233,22 @@ var integration_metadata_v1_default = {
         }
       }
     },
+    base_url_template: {
+      type: "object",
+      description: "A PER-INSTALL API host (CS-1863), for vendors with one host per customer (Storrito: https://<ORG_UUID>.storrito.com/api/v1). Used when base_url is absent. `template` holds exactly one `{value}` placeholder in its host; the value is read from the install's config[config_key], must match value_pattern in full, and the built host must be exactly <value>.<host_suffix> over https. Resolved and re-validated at call time by resolveIntegrationBaseUrl.",
+      additionalProperties: false,
+      required: ["template", "config_key", "value_pattern", "host_suffix"],
+      properties: {
+        template: { type: "string", pattern: "^https://\\{value\\}\\.[^{}]+$" },
+        config_key: { type: "string", pattern: "^[a-z][a-z0-9_]*$" },
+        value_pattern: { type: "string", minLength: 1 },
+        host_suffix: { type: "string", pattern: "^[a-z0-9.-]+\\.[a-z]{2,}$" }
+      }
+    },
+    redirect_means_auth_failure: {
+      type: "boolean",
+      description: "The vendor answers a rejected credential with a REDIRECT (Storrito: a 302 to its login page) rather than a 401. A redirected non-GET call is never followed (vendor-fetch.ts) and always fails; with this set, it is also treated like a 401 and the install is flagged for re-auth."
+    },
     tools: {
       type: "array",
       description: "Auto-loaded MCP tool descriptors. Each entry produces one MCP tool entry per supported runtime scope.",
@@ -23244,7 +23260,10 @@ var integration_metadata_v1_default = {
     properties: { tools: { type: "array", minItems: 1 } },
     required: ["tools"]
   },
-  then: { required: ["base_url"] },
+  then: {
+    description: "A tool needs an API root: a fixed base_url, or a per-install base_url_template (CS-1863).",
+    anyOf: [{ required: ["base_url"] }, { required: ["base_url_template"] }]
+  },
   not: {
     description: "auth_scheme and auth_encoding are mutually exclusive (ENG-10524). The templater refuses the combination on every call, so catalog validation refuses it first.",
     required: ["auth_scheme", "auth_encoding"]
@@ -30169,7 +30188,7 @@ var FLAG_REGISTRY = [
   },
   {
     key: "email-require-approval-enforcement",
-    description: 'Enforcement gate for the `email.require_approval` guardrail (ENG-9611). That guardrail has been `default_for_new_orgs` since ~2026-05-03 and its display text promises "Require human approval before sending any email", but nothing ever read it: its only runtime path was toGuardrailForPrompt, i.e. a line in the agent CLAUDE.md. When ON for an org, a DISPATCHING email send (never a draft-create, ENG-7980) is held and routed to Human Approval regardless of recipient domain \u2014 which is what "any email" means, and is what distinguishes it from email-guard-require-approval-enabled, whose require_approval stage only intercepts a would-be DOMAIN block. Deliberately separate from the guardrail row: roughly four months of orgs already carry an inert `enforce`-level row, so reading the row alone would arm a blocking control across all of them on deploy. New orgs are armed by an org-scoped override written at org creation; existing orgs stay off until an operator flips them. Evaluated per-org. Ships dark.',
+    description: 'Enforcement gate for the `email.require_approval` guardrail (ENG-9611). That guardrail has been `default_for_new_orgs` since ~2026-05-03 and its display text promises "Require human approval before sending any email", but nothing ever read it: its only runtime path was toGuardrailForPrompt, i.e. a line in the agent CLAUDE.md. When ON for an org, a DISPATCHING email send (never a draft-create, ENG-7980) is held and routed to Human Approval regardless of recipient domain \u2014 which is what "any email" means, and is what distinguishes it from email-guard-require-approval-enabled, whose require_approval stage only intercepts a would-be DOMAIN block. Deliberately separate from the guardrail row: roughly four months of orgs already carry an inert `enforce`-level row, so reading the row alone would arm a blocking control across all of them on deploy. New orgs are no longer armed (ENG-11234). Orgs created while the ENG-9629/9675 new-org arm was live keep their org-scoped ON override until an operator flips them per org. Evaluated per-org. Ships dark.',
     flagType: "boolean",
     // Declared safe value is `false` (no hold). A flag-DB read error degrades here, so a flags
     // outage can never silently start holding real customer email — the same fail-OPEN posture
@@ -30179,36 +30198,15 @@ var FLAG_REGISTRY = [
     defaultValue: false,
     // Turning it on holds real customer email pending a human tap, so it is a deliberate,
     // audited per-org flip (ADR-0022 §4).
-    sensitive: true,
-    // ENG-9629: NEW orgs are armed on. Declared here rather than hardcoded in the
-    // seeding code, so `listNewOrgFlagOverrides()` is the one answer to "which flags
-    // does a new org get". `defaultValue` stays false so the ~4 months of orgs already
-    // carrying an inert enforce-level email.require_approval row are NOT armed on deploy.
-    // ENG-9675: EVERY creation path, self-serve included.
-    //
-    // ENG-9630 had restricted this to API-created orgs on the grounds that a
-    // self-serve org has no way of being TOLD about a held send — no Slack
-    // alert channel is wired at signup. That reasoning was wrong, and the check
-    // behind it was incomplete: it confirmed an in-console page exists at
-    // /organization/approvals and stopped, without looking at the dispatch path.
-    //
-    // `routeBlockedCallToApproval` has three dispatchers, and the Direct Chat
-    // one (lib/integration-broker-approval-direct-chat.ts, ENG-7680) is the
-    // universal fallback — "every managed agent always has a Direct Chat session
-    // its operator/manager watches in the Console ... usable out of the box with
-    // no per-org approval-route setup and no Slack dependency". It posts into a
-    // thread keyed on the approval_requests.id and correlates the manager's
-    // reply back through tryCaptureDirectChatApproval, so a self-serve org has
-    // both a zero-config delivery channel AND a reply path.
-    //
-    // With the stated blocker gone, the guardrail's own promise — "before
-    // sending any email" — applies to the organizations with the LEAST operator
-    // oversight exactly as it does to the rest.
-    //
-    // Existing self-serve orgs are deliberately NOT armed by this: newOrgOverride
-    // is applied at creation, and nothing backfills. Extending it to them is a
-    // separate decision with a comms obligation.
-    newOrgOverride: true
+    sensitive: true
+    // No newOrgOverride (ENG-11234). ENG-9629/ENG-9675 armed this on EVERY new org at
+    // creation, so every org created since then held each dispatching send, internal
+    // recipients included, behind a human tap. In practice that stalled real work: Pedders
+    // (CS-1904/1908/1910) had an agent's emails to its own principal expire unapproved,
+    // because "any email" includes the person the agent works for. New orgs now start at
+    // `defaultValue` (off) like every other org; turning it on is the deliberate, audited
+    // per-org flip `sensitive: true` already describes. Orgs armed by the old override keep
+    // their override row; nothing here disarms them (that is an operator decision per org).
   },
   {
     key: "mail-rule-control-enforcement",

package/dist/mcp/origami.js

@@ -37111,7 +37111,7 @@ var integration_metadata_v1_default = {
       type: "string",
       format: "uri",
       pattern: "^https://",
-      description: "Absolute HTTPS URL the broker uses as the vendor API root. Required when any tool descriptor relies on http_templater (i.e. whenever `tools[]` is non-empty)."
+      description: "Absolute HTTPS URL the broker uses as the vendor API root. Required when any tool descriptor relies on http_templater (i.e. whenever `tools[]` is non-empty), unless the definition declares a per-install `base_url_template` instead (CS-1863)."
     },
     auth_scheme: {
       type: "string",
@@ -37145,6 +37145,22 @@ var integration_metadata_v1_default = {
         }
       }
     },
+    base_url_template: {
+      type: "object",
+      description: "A PER-INSTALL API host (CS-1863), for vendors with one host per customer (Storrito: https://<ORG_UUID>.storrito.com/api/v1). Used when base_url is absent. `template` holds exactly one `{value}` placeholder in its host; the value is read from the install's config[config_key], must match value_pattern in full, and the built host must be exactly <value>.<host_suffix> over https. Resolved and re-validated at call time by resolveIntegrationBaseUrl.",
+      additionalProperties: false,
+      required: ["template", "config_key", "value_pattern", "host_suffix"],
+      properties: {
+        template: { type: "string", pattern: "^https://\\{value\\}\\.[^{}]+$" },
+        config_key: { type: "string", pattern: "^[a-z][a-z0-9_]*$" },
+        value_pattern: { type: "string", minLength: 1 },
+        host_suffix: { type: "string", pattern: "^[a-z0-9.-]+\\.[a-z]{2,}$" }
+      }
+    },
+    redirect_means_auth_failure: {
+      type: "boolean",
+      description: "The vendor answers a rejected credential with a REDIRECT (Storrito: a 302 to its login page) rather than a 401. A redirected non-GET call is never followed (vendor-fetch.ts) and always fails; with this set, it is also treated like a 401 and the install is flagged for re-auth."
+    },
     tools: {
       type: "array",
       description: "Auto-loaded MCP tool descriptors. Each entry produces one MCP tool entry per supported runtime scope.",
@@ -37156,7 +37172,10 @@ var integration_metadata_v1_default = {
     properties: { tools: { type: "array", minItems: 1 } },
     required: ["tools"]
   },
-  then: { required: ["base_url"] },
+  then: {
+    description: "A tool needs an API root: a fixed base_url, or a per-install base_url_template (CS-1863).",
+    anyOf: [{ required: ["base_url"] }, { required: ["base_url_template"] }]
+  },
   not: {
     description: "auth_scheme and auth_encoding are mutually exclusive (ENG-10524). The templater refuses the combination on every call, so catalog validation refuses it first.",
     required: ["auth_scheme", "auth_encoding"]
@@ -44083,7 +44102,7 @@ var FLAG_REGISTRY = [
   },
   {
     key: "email-require-approval-enforcement",
-    description: 'Enforcement gate for the `email.require_approval` guardrail (ENG-9611). That guardrail has been `default_for_new_orgs` since ~2026-05-03 and its display text promises "Require human approval before sending any email", but nothing ever read it: its only runtime path was toGuardrailForPrompt, i.e. a line in the agent CLAUDE.md. When ON for an org, a DISPATCHING email send (never a draft-create, ENG-7980) is held and routed to Human Approval regardless of recipient domain \u2014 which is what "any email" means, and is what distinguishes it from email-guard-require-approval-enabled, whose require_approval stage only intercepts a would-be DOMAIN block. Deliberately separate from the guardrail row: roughly four months of orgs already carry an inert `enforce`-level row, so reading the row alone would arm a blocking control across all of them on deploy. New orgs are armed by an org-scoped override written at org creation; existing orgs stay off until an operator flips them. Evaluated per-org. Ships dark.',
+    description: 'Enforcement gate for the `email.require_approval` guardrail (ENG-9611). That guardrail has been `default_for_new_orgs` since ~2026-05-03 and its display text promises "Require human approval before sending any email", but nothing ever read it: its only runtime path was toGuardrailForPrompt, i.e. a line in the agent CLAUDE.md. When ON for an org, a DISPATCHING email send (never a draft-create, ENG-7980) is held and routed to Human Approval regardless of recipient domain \u2014 which is what "any email" means, and is what distinguishes it from email-guard-require-approval-enabled, whose require_approval stage only intercepts a would-be DOMAIN block. Deliberately separate from the guardrail row: roughly four months of orgs already carry an inert `enforce`-level row, so reading the row alone would arm a blocking control across all of them on deploy. New orgs are no longer armed (ENG-11234). Orgs created while the ENG-9629/9675 new-org arm was live keep their org-scoped ON override until an operator flips them per org. Evaluated per-org. Ships dark.',
     flagType: "boolean",
     // Declared safe value is `false` (no hold). A flag-DB read error degrades here, so a flags
     // outage can never silently start holding real customer email — the same fail-OPEN posture
@@ -44093,36 +44112,15 @@ var FLAG_REGISTRY = [
     defaultValue: false,
     // Turning it on holds real customer email pending a human tap, so it is a deliberate,
     // audited per-org flip (ADR-0022 §4).
-    sensitive: true,
-    // ENG-9629: NEW orgs are armed on. Declared here rather than hardcoded in the
-    // seeding code, so `listNewOrgFlagOverrides()` is the one answer to "which flags
-    // does a new org get". `defaultValue` stays false so the ~4 months of orgs already
-    // carrying an inert enforce-level email.require_approval row are NOT armed on deploy.
-    // ENG-9675: EVERY creation path, self-serve included.
-    //
-    // ENG-9630 had restricted this to API-created orgs on the grounds that a
-    // self-serve org has no way of being TOLD about a held send — no Slack
-    // alert channel is wired at signup. That reasoning was wrong, and the check
-    // behind it was incomplete: it confirmed an in-console page exists at
-    // /organization/approvals and stopped, without looking at the dispatch path.
-    //
-    // `routeBlockedCallToApproval` has three dispatchers, and the Direct Chat
-    // one (lib/integration-broker-approval-direct-chat.ts, ENG-7680) is the
-    // universal fallback — "every managed agent always has a Direct Chat session
-    // its operator/manager watches in the Console ... usable out of the box with
-    // no per-org approval-route setup and no Slack dependency". It posts into a
-    // thread keyed on the approval_requests.id and correlates the manager's
-    // reply back through tryCaptureDirectChatApproval, so a self-serve org has
-    // both a zero-config delivery channel AND a reply path.
-    //
-    // With the stated blocker gone, the guardrail's own promise — "before
-    // sending any email" — applies to the organizations with the LEAST operator
-    // oversight exactly as it does to the rest.
-    //
-    // Existing self-serve orgs are deliberately NOT armed by this: newOrgOverride
-    // is applied at creation, and nothing backfills. Extending it to them is a
-    // separate decision with a comms obligation.
-    newOrgOverride: true
+    sensitive: true
+    // No newOrgOverride (ENG-11234). ENG-9629/ENG-9675 armed this on EVERY new org at
+    // creation, so every org created since then held each dispatching send, internal
+    // recipients included, behind a human tap. In practice that stalled real work: Pedders
+    // (CS-1904/1908/1910) had an agent's emails to its own principal expire unapproved,
+    // because "any email" includes the person the agent works for. New orgs now start at
+    // `defaultValue` (off) like every other org; turning it on is the deliberate, audited
+    // per-org flip `sensitive: true` already describes. Orgs armed by the old override keep
+    // their override row; nothing here disarms them (that is an operator decision per org).
   },
   {
     key: "mail-rule-control-enforcement",

package/dist/mcp/slack-channel.js

@@ -31559,7 +31559,7 @@ var integration_metadata_v1_default = {
       type: "string",
       format: "uri",
       pattern: "^https://",
-      description: "Absolute HTTPS URL the broker uses as the vendor API root. Required when any tool descriptor relies on http_templater (i.e. whenever `tools[]` is non-empty)."
+      description: "Absolute HTTPS URL the broker uses as the vendor API root. Required when any tool descriptor relies on http_templater (i.e. whenever `tools[]` is non-empty), unless the definition declares a per-install `base_url_template` instead (CS-1863)."
     },
     auth_scheme: {
       type: "string",
@@ -31593,6 +31593,22 @@ var integration_metadata_v1_default = {
         }
       }
     },
+    base_url_template: {
+      type: "object",
+      description: "A PER-INSTALL API host (CS-1863), for vendors with one host per customer (Storrito: https://<ORG_UUID>.storrito.com/api/v1). Used when base_url is absent. `template` holds exactly one `{value}` placeholder in its host; the value is read from the install's config[config_key], must match value_pattern in full, and the built host must be exactly <value>.<host_suffix> over https. Resolved and re-validated at call time by resolveIntegrationBaseUrl.",
+      additionalProperties: false,
+      required: ["template", "config_key", "value_pattern", "host_suffix"],
+      properties: {
+        template: { type: "string", pattern: "^https://\\{value\\}\\.[^{}]+$" },
+        config_key: { type: "string", pattern: "^[a-z][a-z0-9_]*$" },
+        value_pattern: { type: "string", minLength: 1 },
+        host_suffix: { type: "string", pattern: "^[a-z0-9.-]+\\.[a-z]{2,}$" }
+      }
+    },
+    redirect_means_auth_failure: {
+      type: "boolean",
+      description: "The vendor answers a rejected credential with a REDIRECT (Storrito: a 302 to its login page) rather than a 401. A redirected non-GET call is never followed (vendor-fetch.ts) and always fails; with this set, it is also treated like a 401 and the install is flagged for re-auth."
+    },
     tools: {
       type: "array",
       description: "Auto-loaded MCP tool descriptors. Each entry produces one MCP tool entry per supported runtime scope.",
@@ -31604,7 +31620,10 @@ var integration_metadata_v1_default = {
     properties: { tools: { type: "array", minItems: 1 } },
     required: ["tools"]
   },
-  then: { required: ["base_url"] },
+  then: {
+    description: "A tool needs an API root: a fixed base_url, or a per-install base_url_template (CS-1863).",
+    anyOf: [{ required: ["base_url"] }, { required: ["base_url_template"] }]
+  },
   not: {
     description: "auth_scheme and auth_encoding are mutually exclusive (ENG-10524). The templater refuses the combination on every call, so catalog validation refuses it first.",
     required: ["auth_scheme", "auth_encoding"]
@@ -38722,7 +38741,7 @@ var FLAG_REGISTRY = [
   },
   {
     key: "email-require-approval-enforcement",
-    description: 'Enforcement gate for the `email.require_approval` guardrail (ENG-9611). That guardrail has been `default_for_new_orgs` since ~2026-05-03 and its display text promises "Require human approval before sending any email", but nothing ever read it: its only runtime path was toGuardrailForPrompt, i.e. a line in the agent CLAUDE.md. When ON for an org, a DISPATCHING email send (never a draft-create, ENG-7980) is held and routed to Human Approval regardless of recipient domain \u2014 which is what "any email" means, and is what distinguishes it from email-guard-require-approval-enabled, whose require_approval stage only intercepts a would-be DOMAIN block. Deliberately separate from the guardrail row: roughly four months of orgs already carry an inert `enforce`-level row, so reading the row alone would arm a blocking control across all of them on deploy. New orgs are armed by an org-scoped override written at org creation; existing orgs stay off until an operator flips them. Evaluated per-org. Ships dark.',
+    description: 'Enforcement gate for the `email.require_approval` guardrail (ENG-9611). That guardrail has been `default_for_new_orgs` since ~2026-05-03 and its display text promises "Require human approval before sending any email", but nothing ever read it: its only runtime path was toGuardrailForPrompt, i.e. a line in the agent CLAUDE.md. When ON for an org, a DISPATCHING email send (never a draft-create, ENG-7980) is held and routed to Human Approval regardless of recipient domain \u2014 which is what "any email" means, and is what distinguishes it from email-guard-require-approval-enabled, whose require_approval stage only intercepts a would-be DOMAIN block. Deliberately separate from the guardrail row: roughly four months of orgs already carry an inert `enforce`-level row, so reading the row alone would arm a blocking control across all of them on deploy. New orgs are no longer armed (ENG-11234). Orgs created while the ENG-9629/9675 new-org arm was live keep their org-scoped ON override until an operator flips them per org. Evaluated per-org. Ships dark.',
     flagType: "boolean",
     // Declared safe value is `false` (no hold). A flag-DB read error degrades here, so a flags
     // outage can never silently start holding real customer email — the same fail-OPEN posture
@@ -38732,36 +38751,15 @@ var FLAG_REGISTRY = [
     defaultValue: false,
     // Turning it on holds real customer email pending a human tap, so it is a deliberate,
     // audited per-org flip (ADR-0022 §4).
-    sensitive: true,
-    // ENG-9629: NEW orgs are armed on. Declared here rather than hardcoded in the
-    // seeding code, so `listNewOrgFlagOverrides()` is the one answer to "which flags
-    // does a new org get". `defaultValue` stays false so the ~4 months of orgs already
-    // carrying an inert enforce-level email.require_approval row are NOT armed on deploy.
-    // ENG-9675: EVERY creation path, self-serve included.
-    //
-    // ENG-9630 had restricted this to API-created orgs on the grounds that a
-    // self-serve org has no way of being TOLD about a held send — no Slack
-    // alert channel is wired at signup. That reasoning was wrong, and the check
-    // behind it was incomplete: it confirmed an in-console page exists at
-    // /organization/approvals and stopped, without looking at the dispatch path.
-    //
-    // `routeBlockedCallToApproval` has three dispatchers, and the Direct Chat
-    // one (lib/integration-broker-approval-direct-chat.ts, ENG-7680) is the
-    // universal fallback — "every managed agent always has a Direct Chat session
-    // its operator/manager watches in the Console ... usable out of the box with
-    // no per-org approval-route setup and no Slack dependency". It posts into a
-    // thread keyed on the approval_requests.id and correlates the manager's
-    // reply back through tryCaptureDirectChatApproval, so a self-serve org has
-    // both a zero-config delivery channel AND a reply path.
-    //
-    // With the stated blocker gone, the guardrail's own promise — "before
-    // sending any email" — applies to the organizations with the LEAST operator
-    // oversight exactly as it does to the rest.
-    //
-    // Existing self-serve orgs are deliberately NOT armed by this: newOrgOverride
-    // is applied at creation, and nothing backfills. Extending it to them is a
-    // separate decision with a comms obligation.
-    newOrgOverride: true
+    sensitive: true
+    // No newOrgOverride (ENG-11234). ENG-9629/ENG-9675 armed this on EVERY new org at
+    // creation, so every org created since then held each dispatching send, internal
+    // recipients included, behind a human tap. In practice that stalled real work: Pedders
+    // (CS-1904/1908/1910) had an agent's emails to its own principal expire unapproved,
+    // because "any email" includes the person the agent works for. New orgs now start at
+    // `defaultValue` (off) like every other org; turning it on is the deliberate, audited
+    // per-org flip `sensitive: true` already describes. Orgs armed by the old override keep
+    // their override row; nothing here disarms them (that is an operator decision per org).
   },
   {
     key: "mail-rule-control-enforcement",

package/dist/mcp/telegram-channel.js

@@ -31671,7 +31671,7 @@ var integration_metadata_v1_default = {
       type: "string",
       format: "uri",
       pattern: "^https://",
-      description: "Absolute HTTPS URL the broker uses as the vendor API root. Required when any tool descriptor relies on http_templater (i.e. whenever `tools[]` is non-empty)."
+      description: "Absolute HTTPS URL the broker uses as the vendor API root. Required when any tool descriptor relies on http_templater (i.e. whenever `tools[]` is non-empty), unless the definition declares a per-install `base_url_template` instead (CS-1863)."
     },
     auth_scheme: {
       type: "string",
@@ -31705,6 +31705,22 @@ var integration_metadata_v1_default = {
         }
       }
     },
+    base_url_template: {
+      type: "object",
+      description: "A PER-INSTALL API host (CS-1863), for vendors with one host per customer (Storrito: https://<ORG_UUID>.storrito.com/api/v1). Used when base_url is absent. `template` holds exactly one `{value}` placeholder in its host; the value is read from the install's config[config_key], must match value_pattern in full, and the built host must be exactly <value>.<host_suffix> over https. Resolved and re-validated at call time by resolveIntegrationBaseUrl.",
+      additionalProperties: false,
+      required: ["template", "config_key", "value_pattern", "host_suffix"],
+      properties: {
+        template: { type: "string", pattern: "^https://\\{value\\}\\.[^{}]+$" },
+        config_key: { type: "string", pattern: "^[a-z][a-z0-9_]*$" },
+        value_pattern: { type: "string", minLength: 1 },
+        host_suffix: { type: "string", pattern: "^[a-z0-9.-]+\\.[a-z]{2,}$" }
+      }
+    },
+    redirect_means_auth_failure: {
+      type: "boolean",
+      description: "The vendor answers a rejected credential with a REDIRECT (Storrito: a 302 to its login page) rather than a 401. A redirected non-GET call is never followed (vendor-fetch.ts) and always fails; with this set, it is also treated like a 401 and the install is flagged for re-auth."
+    },
     tools: {
       type: "array",
       description: "Auto-loaded MCP tool descriptors. Each entry produces one MCP tool entry per supported runtime scope.",
@@ -31716,7 +31732,10 @@ var integration_metadata_v1_default = {
     properties: { tools: { type: "array", minItems: 1 } },
     required: ["tools"]
   },
-  then: { required: ["base_url"] },
+  then: {
+    description: "A tool needs an API root: a fixed base_url, or a per-install base_url_template (CS-1863).",
+    anyOf: [{ required: ["base_url"] }, { required: ["base_url_template"] }]
+  },
   not: {
     description: "auth_scheme and auth_encoding are mutually exclusive (ENG-10524). The templater refuses the combination on every call, so catalog validation refuses it first.",
     required: ["auth_scheme", "auth_encoding"]
@@ -38828,7 +38847,7 @@ var FLAG_REGISTRY = [
   },
   {
     key: "email-require-approval-enforcement",
-    description: 'Enforcement gate for the `email.require_approval` guardrail (ENG-9611). That guardrail has been `default_for_new_orgs` since ~2026-05-03 and its display text promises "Require human approval before sending any email", but nothing ever read it: its only runtime path was toGuardrailForPrompt, i.e. a line in the agent CLAUDE.md. When ON for an org, a DISPATCHING email send (never a draft-create, ENG-7980) is held and routed to Human Approval regardless of recipient domain \u2014 which is what "any email" means, and is what distinguishes it from email-guard-require-approval-enabled, whose require_approval stage only intercepts a would-be DOMAIN block. Deliberately separate from the guardrail row: roughly four months of orgs already carry an inert `enforce`-level row, so reading the row alone would arm a blocking control across all of them on deploy. New orgs are armed by an org-scoped override written at org creation; existing orgs stay off until an operator flips them. Evaluated per-org. Ships dark.',
+    description: 'Enforcement gate for the `email.require_approval` guardrail (ENG-9611). That guardrail has been `default_for_new_orgs` since ~2026-05-03 and its display text promises "Require human approval before sending any email", but nothing ever read it: its only runtime path was toGuardrailForPrompt, i.e. a line in the agent CLAUDE.md. When ON for an org, a DISPATCHING email send (never a draft-create, ENG-7980) is held and routed to Human Approval regardless of recipient domain \u2014 which is what "any email" means, and is what distinguishes it from email-guard-require-approval-enabled, whose require_approval stage only intercepts a would-be DOMAIN block. Deliberately separate from the guardrail row: roughly four months of orgs already carry an inert `enforce`-level row, so reading the row alone would arm a blocking control across all of them on deploy. New orgs are no longer armed (ENG-11234). Orgs created while the ENG-9629/9675 new-org arm was live keep their org-scoped ON override until an operator flips them per org. Evaluated per-org. Ships dark.',
     flagType: "boolean",
     // Declared safe value is `false` (no hold). A flag-DB read error degrades here, so a flags
     // outage can never silently start holding real customer email — the same fail-OPEN posture
@@ -38838,36 +38857,15 @@ var FLAG_REGISTRY = [
     defaultValue: false,
     // Turning it on holds real customer email pending a human tap, so it is a deliberate,
     // audited per-org flip (ADR-0022 §4).
-    sensitive: true,
-    // ENG-9629: NEW orgs are armed on. Declared here rather than hardcoded in the
-    // seeding code, so `listNewOrgFlagOverrides()` is the one answer to "which flags
-    // does a new org get". `defaultValue` stays false so the ~4 months of orgs already
-    // carrying an inert enforce-level email.require_approval row are NOT armed on deploy.
-    // ENG-9675: EVERY creation path, self-serve included.
-    //
-    // ENG-9630 had restricted this to API-created orgs on the grounds that a
-    // self-serve org has no way of being TOLD about a held send — no Slack
-    // alert channel is wired at signup. That reasoning was wrong, and the check
-    // behind it was incomplete: it confirmed an in-console page exists at
-    // /organization/approvals and stopped, without looking at the dispatch path.
-    //
-    // `routeBlockedCallToApproval` has three dispatchers, and the Direct Chat
-    // one (lib/integration-broker-approval-direct-chat.ts, ENG-7680) is the
-    // universal fallback — "every managed agent always has a Direct Chat session
-    // its operator/manager watches in the Console ... usable out of the box with
-    // no per-org approval-route setup and no Slack dependency". It posts into a
-    // thread keyed on the approval_requests.id and correlates the manager's
-    // reply back through tryCaptureDirectChatApproval, so a self-serve org has
-    // both a zero-config delivery channel AND a reply path.
-    //
-    // With the stated blocker gone, the guardrail's own promise — "before
-    // sending any email" — applies to the organizations with the LEAST operator
-    // oversight exactly as it does to the rest.
-    //
-    // Existing self-serve orgs are deliberately NOT armed by this: newOrgOverride
-    // is applied at creation, and nothing backfills. Extending it to them is a
-    // separate decision with a comms obligation.
-    newOrgOverride: true
+    sensitive: true
+    // No newOrgOverride (ENG-11234). ENG-9629/ENG-9675 armed this on EVERY new org at
+    // creation, so every org created since then held each dispatching send, internal
+    // recipients included, behind a human tap. In practice that stalled real work: Pedders
+    // (CS-1904/1908/1910) had an agent's emails to its own principal expire unapproved,
+    // because "any email" includes the person the agent works for. New orgs now start at
+    // `defaultValue` (off) like every other org; turning it on is the deliberate, audited
+    // per-org flip `sensitive: true` already describes. Orgs armed by the old override keep
+    // their override row; nothing here disarms them (that is an operator decision per org).
   },
   {
     key: "mail-rule-control-enforcement",

package/dist/{persistent-session-3WRSJIDM.js → persistent-session-WSJVCGEO.js}

@@ -65,8 +65,8 @@ import {
   writeDirectChatSessionState,
   writeEgressAllowlist,
   writePersistentClaudeWrapper
-} from "./chunk-AT7E625H.js";
-import "./chunk-2SGXGNDW.js";
+} from "./chunk-A7HDJW23.js";
+import "./chunk-P544KDE3.js";
 import "./chunk-OCMJ5E6J.js";
 import "./chunk-XWVM4KPK.js";
 import "./chunk-EL5MWGGH.js";
@@ -139,4 +139,4 @@ export {
   writeEgressAllowlist,
   writePersistentClaudeWrapper
 };
-//# sourceMappingURL=persistent-session-3WRSJIDM.js.map
+//# sourceMappingURL=persistent-session-WSJVCGEO.js.map

package/dist/{responsiveness-probe-2DF6VH7Q.js → responsiveness-probe-7MQI6SUF.js}

@@ -1,7 +1,7 @@
 import {
   paneLogPath
-} from "./chunk-AT7E625H.js";
-import "./chunk-2SGXGNDW.js";
+} from "./chunk-A7HDJW23.js";
+import "./chunk-P544KDE3.js";
 import "./chunk-OCMJ5E6J.js";
 import "./chunk-XWVM4KPK.js";
 import "./chunk-EL5MWGGH.js";
@@ -802,4 +802,4 @@ export {
   readAndResetSlackReplyBindingClassifications,
   readAndResetSlackReplyTargetClassifications
 };
-//# sourceMappingURL=responsiveness-probe-2DF6VH7Q.js.map
+//# sourceMappingURL=responsiveness-probe-7MQI6SUF.js.map

package/dist/{session-auth-dead-GRTHA2Z5.js → session-auth-dead-NFVTUFPI.js}

@@ -1,6 +1,6 @@
 import {
   sessionTranscriptDir
-} from "./chunk-2SGXGNDW.js";
+} from "./chunk-P544KDE3.js";
 import "./chunk-DGUM43GV.js";
 
 // src/lib/session-auth-dead.ts
@@ -204,4 +204,4 @@ export {
   decideSessionAuthState,
   probeSessionAuth
 };
-//# sourceMappingURL=session-auth-dead-GRTHA2Z5.js.map
+//# sourceMappingURL=session-auth-dead-NFVTUFPI.js.map

package/package.json

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