@integrity-labs/agt-cli 0.28.874 → 0.28.876

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

@@ -34161,6 +34161,97 @@ var INTEGRATION_REGISTRY = [
       ]
     }
   },
+  {
+    id: "origami",
+    name: "origami.chat",
+    category: "crm",
+    description: "Lead data + outbound: build and enrich lead lists, drive origami's AI worker from a natural-language brief, and read the tables it builds. Available on the platform-managed account, or with your own origami key.",
+    // ENG-7423: origami migrates from a customer-key-only integration to a
+    // PREMIUM one that ALSO keeps BYO — the Firecrawl / ADR-0055 model, with one
+    // structural difference that drives most of the design.
+    //
+    // Firecrawl's premium tier is a single platform account key that every
+    // customer's calls bill back to, and isolation is not a concern because a
+    // scrape has no tenancy. origami is the opposite: it stores the customer's
+    // LEAD LISTS, tables, chats and campaigns. Putting every customer on one
+    // parent org would make every customer's data mutually readable, so the
+    // managed tier gives each ORGANIZATION its own origami project (child org)
+    // and mints a key BOUND to that project (`POST /account/keys` with
+    // `project_id`, v3). See `packages/core/src/origami/provision.ts` for why a
+    // bound key rather than the `x-origami-project` header — in short, the
+    // header is a per-call assertion and the tool argument is deliberately
+    // nullable, so under a shared parent an ordinary tool call could reach it.
+    //
+    // ── auth types, and the ENG-9235 trap this deliberately re-enters ─────────
+    // Both are offered, unlike Firecrawl, which PARKED `api_key` down to
+    // `['none']` because a 2+-auth-type wizard renders a picker that is not
+    // entitlement-aware: a customer picks BYO, goes and fetches a vendor key,
+    // and is then rejected with `byo_not_entitled_by_plan` (BYO on a premium def
+    // needs `plans.byo_credentials`, enterprise-only today).
+    //
+    // origami cannot take that exit. BYO is the INCUMBENT here — every existing
+    // install is a customer's own key — so dropping `api_key` would remove the
+    // only mode its current customers use. The known gap is therefore accepted
+    // and pointed at its owner: the picker will still let a non-entitled org
+    // choose BYO and reject it afterwards. ENG-9236 (entitlement-aware wizard)
+    // is the fix; until it lands the rejection is at least loud, specific, and
+    // ahead of any charge.
+    //
+    // EXISTING installs are unaffected by that gate: the premium migration
+    // backfills them to `credential_source='byo'` AND stamps
+    // `config.byo_grandfathered_at`, which the call-time resolver honours in
+    // place of the plan check. Grandfathering is per-install and set only by
+    // that one migration — a NEW BYO install still needs the entitlement.
+    //
+    // KEEP IN LOCKSTEP with the `origami` rows in
+    // packages/supabase/seeds/integration-definitions.json and
+    // toolkit-definitions.json: those seeds carry their own auth types and are
+    // what `db:catalog:seed` upserts on every prod deploy, so editing this array
+    // alone changes nothing a customer can see.
+    supported_auth_types: ["none", "api_key"],
+    capabilities: [
+      { id: "origami:read", name: "Read Lists & Runs", description: "Discover projects and tables, read built tables and rows, poll runs/batches, and check credit balance. Credit-free.", access: "read" },
+      { id: "origami:write", name: "Enrich Leads", description: "Insert raw rows into an enrichment table (submit_enrichment). Consumes credits.", access: "write" },
+      { id: "origami:agent", name: "Drive the AI Worker", description: "Create an origami agent, send follow-up runs, cancel a run, archive an agent. Consumes credits.", access: "write" }
+    ],
+    docs_url: "https://docs.origami.chat/v3/overview",
+    // ENG-7423: premium (billable). origami bills internally in CREDITS, so the
+    // integration is usage-priced on one meter whose unit is the vendor's own
+    // billing unit. Priced at 2.0 c USD / 3.5 c AUD per credit by
+    // `20260907000050_origami_credits_rate_card.sql`, against a retail cost of
+    // 1.29-1.43 c/credit depending on which origami tier we hold.
+    //
+    // The note deliberately does NOT say "at cost". origami sells a
+    // SUBSCRIPTION WITH AN INCLUDED BUNDLE while this meters PER CREDIT
+    // CONSUMED, so a per-credit price recovers the subscription only at full
+    // utilisation — around 72% of the bundle at this rate. Calling that "at
+    // cost" in a customer-facing pricing string would be a claim about our
+    // margin that is only true at one utilisation level we do not control.
+    //
+    // ONE meter, not one per tool, because of where the number comes from. Every
+    // other premium integration meters at a server-side broker chokepoint, which
+    // sees each call and can attribute it. origami's agent surface is a
+    // host-resident stdio MCP server (ADR-0040) that calls origami.chat DIRECTLY
+    // — the control plane never sees the tool call, so there is no per-operation
+    // quantity to meter. What the control plane CAN see is the project's own
+    // spend (`GET /account/projects/{id}` → `usage.spent`), which the credit
+    // reconciler polls and meters as a delta. That is a per-project total, so it
+    // can only ever be one meter; splitting it per tool would require the vendor
+    // to break spend down by operation, which v3 does not expose.
+    //
+    // `unit_label` is set because the machine unit is the vendor's internal
+    // billing unit rather than a thing the customer asked for — "(per credit)"
+    // is the honest rendering, in the ADR-0053 cost-pass-through spirit.
+    //
+    // Only a MANAGED install is metered. A BYO install spends the customer's own
+    // origami credits on their own bill (`isBilledInstall` → false), which is why
+    // the reconciler polls only projects it provisioned.
+    premium: {
+      pricing: "usage",
+      note: "Billed per origami credit the agent consumes. Bring your own origami key instead and usage is billed to you by origami directly.",
+      meters: [{ event_type: "credits", unit: "credit", label: "origami credits", unit_label: "credit" }]
+    }
+  },
   {
     id: "ayrshare",
     name: "Ayrshare",

package/dist/mcp/index.js

@@ -26735,6 +26735,97 @@ var INTEGRATION_REGISTRY = [
       ]
     }
   },
+  {
+    id: "origami",
+    name: "origami.chat",
+    category: "crm",
+    description: "Lead data + outbound: build and enrich lead lists, drive origami's AI worker from a natural-language brief, and read the tables it builds. Available on the platform-managed account, or with your own origami key.",
+    // ENG-7423: origami migrates from a customer-key-only integration to a
+    // PREMIUM one that ALSO keeps BYO — the Firecrawl / ADR-0055 model, with one
+    // structural difference that drives most of the design.
+    //
+    // Firecrawl's premium tier is a single platform account key that every
+    // customer's calls bill back to, and isolation is not a concern because a
+    // scrape has no tenancy. origami is the opposite: it stores the customer's
+    // LEAD LISTS, tables, chats and campaigns. Putting every customer on one
+    // parent org would make every customer's data mutually readable, so the
+    // managed tier gives each ORGANIZATION its own origami project (child org)
+    // and mints a key BOUND to that project (`POST /account/keys` with
+    // `project_id`, v3). See `packages/core/src/origami/provision.ts` for why a
+    // bound key rather than the `x-origami-project` header — in short, the
+    // header is a per-call assertion and the tool argument is deliberately
+    // nullable, so under a shared parent an ordinary tool call could reach it.
+    //
+    // ── auth types, and the ENG-9235 trap this deliberately re-enters ─────────
+    // Both are offered, unlike Firecrawl, which PARKED `api_key` down to
+    // `['none']` because a 2+-auth-type wizard renders a picker that is not
+    // entitlement-aware: a customer picks BYO, goes and fetches a vendor key,
+    // and is then rejected with `byo_not_entitled_by_plan` (BYO on a premium def
+    // needs `plans.byo_credentials`, enterprise-only today).
+    //
+    // origami cannot take that exit. BYO is the INCUMBENT here — every existing
+    // install is a customer's own key — so dropping `api_key` would remove the
+    // only mode its current customers use. The known gap is therefore accepted
+    // and pointed at its owner: the picker will still let a non-entitled org
+    // choose BYO and reject it afterwards. ENG-9236 (entitlement-aware wizard)
+    // is the fix; until it lands the rejection is at least loud, specific, and
+    // ahead of any charge.
+    //
+    // EXISTING installs are unaffected by that gate: the premium migration
+    // backfills them to `credential_source='byo'` AND stamps
+    // `config.byo_grandfathered_at`, which the call-time resolver honours in
+    // place of the plan check. Grandfathering is per-install and set only by
+    // that one migration — a NEW BYO install still needs the entitlement.
+    //
+    // KEEP IN LOCKSTEP with the `origami` rows in
+    // packages/supabase/seeds/integration-definitions.json and
+    // toolkit-definitions.json: those seeds carry their own auth types and are
+    // what `db:catalog:seed` upserts on every prod deploy, so editing this array
+    // alone changes nothing a customer can see.
+    supported_auth_types: ["none", "api_key"],
+    capabilities: [
+      { id: "origami:read", name: "Read Lists & Runs", description: "Discover projects and tables, read built tables and rows, poll runs/batches, and check credit balance. Credit-free.", access: "read" },
+      { id: "origami:write", name: "Enrich Leads", description: "Insert raw rows into an enrichment table (submit_enrichment). Consumes credits.", access: "write" },
+      { id: "origami:agent", name: "Drive the AI Worker", description: "Create an origami agent, send follow-up runs, cancel a run, archive an agent. Consumes credits.", access: "write" }
+    ],
+    docs_url: "https://docs.origami.chat/v3/overview",
+    // ENG-7423: premium (billable). origami bills internally in CREDITS, so the
+    // integration is usage-priced on one meter whose unit is the vendor's own
+    // billing unit. Priced at 2.0 c USD / 3.5 c AUD per credit by
+    // `20260907000050_origami_credits_rate_card.sql`, against a retail cost of
+    // 1.29-1.43 c/credit depending on which origami tier we hold.
+    //
+    // The note deliberately does NOT say "at cost". origami sells a
+    // SUBSCRIPTION WITH AN INCLUDED BUNDLE while this meters PER CREDIT
+    // CONSUMED, so a per-credit price recovers the subscription only at full
+    // utilisation — around 72% of the bundle at this rate. Calling that "at
+    // cost" in a customer-facing pricing string would be a claim about our
+    // margin that is only true at one utilisation level we do not control.
+    //
+    // ONE meter, not one per tool, because of where the number comes from. Every
+    // other premium integration meters at a server-side broker chokepoint, which
+    // sees each call and can attribute it. origami's agent surface is a
+    // host-resident stdio MCP server (ADR-0040) that calls origami.chat DIRECTLY
+    // — the control plane never sees the tool call, so there is no per-operation
+    // quantity to meter. What the control plane CAN see is the project's own
+    // spend (`GET /account/projects/{id}` → `usage.spent`), which the credit
+    // reconciler polls and meters as a delta. That is a per-project total, so it
+    // can only ever be one meter; splitting it per tool would require the vendor
+    // to break spend down by operation, which v3 does not expose.
+    //
+    // `unit_label` is set because the machine unit is the vendor's internal
+    // billing unit rather than a thing the customer asked for — "(per credit)"
+    // is the honest rendering, in the ADR-0053 cost-pass-through spirit.
+    //
+    // Only a MANAGED install is metered. A BYO install spends the customer's own
+    // origami credits on their own bill (`isBilledInstall` → false), which is why
+    // the reconciler polls only projects it provisioned.
+    premium: {
+      pricing: "usage",
+      note: "Billed per origami credit the agent consumes. Bring your own origami key instead and usage is billed to you by origami directly.",
+      meters: [{ event_type: "credits", unit: "credit", label: "origami credits", unit_label: "credit" }]
+    }
+  },
   {
     id: "ayrshare",
     name: "Ayrshare",

package/dist/mcp/origami.js

@@ -40866,6 +40866,97 @@ var INTEGRATION_REGISTRY = [
       ]
     }
   },
+  {
+    id: "origami",
+    name: "origami.chat",
+    category: "crm",
+    description: "Lead data + outbound: build and enrich lead lists, drive origami's AI worker from a natural-language brief, and read the tables it builds. Available on the platform-managed account, or with your own origami key.",
+    // ENG-7423: origami migrates from a customer-key-only integration to a
+    // PREMIUM one that ALSO keeps BYO — the Firecrawl / ADR-0055 model, with one
+    // structural difference that drives most of the design.
+    //
+    // Firecrawl's premium tier is a single platform account key that every
+    // customer's calls bill back to, and isolation is not a concern because a
+    // scrape has no tenancy. origami is the opposite: it stores the customer's
+    // LEAD LISTS, tables, chats and campaigns. Putting every customer on one
+    // parent org would make every customer's data mutually readable, so the
+    // managed tier gives each ORGANIZATION its own origami project (child org)
+    // and mints a key BOUND to that project (`POST /account/keys` with
+    // `project_id`, v3). See `packages/core/src/origami/provision.ts` for why a
+    // bound key rather than the `x-origami-project` header — in short, the
+    // header is a per-call assertion and the tool argument is deliberately
+    // nullable, so under a shared parent an ordinary tool call could reach it.
+    //
+    // ── auth types, and the ENG-9235 trap this deliberately re-enters ─────────
+    // Both are offered, unlike Firecrawl, which PARKED `api_key` down to
+    // `['none']` because a 2+-auth-type wizard renders a picker that is not
+    // entitlement-aware: a customer picks BYO, goes and fetches a vendor key,
+    // and is then rejected with `byo_not_entitled_by_plan` (BYO on a premium def
+    // needs `plans.byo_credentials`, enterprise-only today).
+    //
+    // origami cannot take that exit. BYO is the INCUMBENT here — every existing
+    // install is a customer's own key — so dropping `api_key` would remove the
+    // only mode its current customers use. The known gap is therefore accepted
+    // and pointed at its owner: the picker will still let a non-entitled org
+    // choose BYO and reject it afterwards. ENG-9236 (entitlement-aware wizard)
+    // is the fix; until it lands the rejection is at least loud, specific, and
+    // ahead of any charge.
+    //
+    // EXISTING installs are unaffected by that gate: the premium migration
+    // backfills them to `credential_source='byo'` AND stamps
+    // `config.byo_grandfathered_at`, which the call-time resolver honours in
+    // place of the plan check. Grandfathering is per-install and set only by
+    // that one migration — a NEW BYO install still needs the entitlement.
+    //
+    // KEEP IN LOCKSTEP with the `origami` rows in
+    // packages/supabase/seeds/integration-definitions.json and
+    // toolkit-definitions.json: those seeds carry their own auth types and are
+    // what `db:catalog:seed` upserts on every prod deploy, so editing this array
+    // alone changes nothing a customer can see.
+    supported_auth_types: ["none", "api_key"],
+    capabilities: [
+      { id: "origami:read", name: "Read Lists & Runs", description: "Discover projects and tables, read built tables and rows, poll runs/batches, and check credit balance. Credit-free.", access: "read" },
+      { id: "origami:write", name: "Enrich Leads", description: "Insert raw rows into an enrichment table (submit_enrichment). Consumes credits.", access: "write" },
+      { id: "origami:agent", name: "Drive the AI Worker", description: "Create an origami agent, send follow-up runs, cancel a run, archive an agent. Consumes credits.", access: "write" }
+    ],
+    docs_url: "https://docs.origami.chat/v3/overview",
+    // ENG-7423: premium (billable). origami bills internally in CREDITS, so the
+    // integration is usage-priced on one meter whose unit is the vendor's own
+    // billing unit. Priced at 2.0 c USD / 3.5 c AUD per credit by
+    // `20260907000050_origami_credits_rate_card.sql`, against a retail cost of
+    // 1.29-1.43 c/credit depending on which origami tier we hold.
+    //
+    // The note deliberately does NOT say "at cost". origami sells a
+    // SUBSCRIPTION WITH AN INCLUDED BUNDLE while this meters PER CREDIT
+    // CONSUMED, so a per-credit price recovers the subscription only at full
+    // utilisation — around 72% of the bundle at this rate. Calling that "at
+    // cost" in a customer-facing pricing string would be a claim about our
+    // margin that is only true at one utilisation level we do not control.
+    //
+    // ONE meter, not one per tool, because of where the number comes from. Every
+    // other premium integration meters at a server-side broker chokepoint, which
+    // sees each call and can attribute it. origami's agent surface is a
+    // host-resident stdio MCP server (ADR-0040) that calls origami.chat DIRECTLY
+    // — the control plane never sees the tool call, so there is no per-operation
+    // quantity to meter. What the control plane CAN see is the project's own
+    // spend (`GET /account/projects/{id}` → `usage.spent`), which the credit
+    // reconciler polls and meters as a delta. That is a per-project total, so it
+    // can only ever be one meter; splitting it per tool would require the vendor
+    // to break spend down by operation, which v3 does not expose.
+    //
+    // `unit_label` is set because the machine unit is the vendor's internal
+    // billing unit rather than a thing the customer asked for — "(per credit)"
+    // is the honest rendering, in the ADR-0053 cost-pass-through spirit.
+    //
+    // Only a MANAGED install is metered. A BYO install spends the customer's own
+    // origami credits on their own bill (`isBilledInstall` → false), which is why
+    // the reconciler polls only projects it provisioned.
+    premium: {
+      pricing: "usage",
+      note: "Billed per origami credit the agent consumes. Bring your own origami key instead and usage is billed to you by origami directly.",
+      meters: [{ event_type: "credits", unit: "credit", label: "origami credits", unit_label: "credit" }]
+    }
+  },
   {
     id: "ayrshare",
     name: "Ayrshare",

package/dist/mcp/slack-channel.js

@@ -22960,8 +22960,20 @@ function richTextToString(node, depth = 0) {
     else if (type === "rich_text_table_row") parts.push(children.join(" | "));
     else if (type === "rich_text_list") {
       parts.push(children.map((c) => `- ${c}`).join("\n"));
-    } else if (type === "rich_text_quote" || type === "rich_text_preformatted") {
-      parts.push(children.join("\n"));
+    } else if (type === "rich_text_quote") {
+      parts.push(
+        children.join("\n").split("\n").map((l) => `> ${l}`).join("\n")
+      );
+    } else if (type === "rich_text_preformatted") {
+      const body = children.join("\n");
+      const longestRun = Math.max(
+        0,
+        ...[...body.matchAll(/`+/g)].map((m) => m[0].length)
+      );
+      const fence = "`".repeat(Math.max(3, longestRun + 1));
+      parts.push(`${fence}
+${body}
+${fence}`);
     } else parts.push(children.join(""));
   }
   return parts.join("").trim();
@@ -30374,7 +30386,7 @@ function isAppMentionEcho(evt, botUserId2) {
     return false;
   if (evt.channel?.startsWith("D"))
     return false;
-  return typeof evt.text === "string" && evt.text.includes(`<@${botUserId2}>`);
+  return typeof evt.text === "string" && mentionsUser(evt.text, botUserId2);
 }
 function slackInboundDedupId(evt) {
   if (!evt.channel || !evt.ts)
@@ -30382,12 +30394,82 @@ function slackInboundDedupId(evt) {
   return `${evt.channel}:${evt.ts}:${evt.type ?? "unknown"}`;
 }
 function decideSlackEngagement(input) {
-  const isExplicitMention = input.type === "app_mention" || !!input.botUserId && input.text.includes(`<@${input.botUserId}>`);
+  const isExplicitMention = input.type === "app_mention" || !!input.botUserId && mentionsUser(input.text, input.botUserId);
   return !(input.isAutoFollowed && !isExplicitMention);
 }
 function decideMarkerArm(input) {
+  if (input.addressesAnotherAgent && !input.shouldEngage)
+    return false;
   return input.shouldEngage || input.isAutoFollowed && input.botPostedInThread;
 }
+var MENTION_AT_START = /^<@([A-Z0-9]+)(?:\|[^>]*)?>/;
+function mentionsUser(text, userId) {
+  if (!userId)
+    return false;
+  const escaped = userId.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
+  return new RegExp(`<@${escaped}[|>]`).test(text);
+}
+var GREETING_PREFIX = /^(?:hey|hi|hello|yo|ok|okay|cc|thanks|thx|morning|afternoon)\b[\s,:!.-]*/i;
+var ADDRESSEE_SEPARATOR = /^(?:[\s,:;]+|and\b|&|\+)+/i;
+var BLOCKQUOTE_PREFIX = /^(?:&gt;|>)/;
+function addressRegion(text) {
+  let fenceLen = 0;
+  for (const rawLine of text.split("\n")) {
+    const line = rawLine.trim();
+    const run = /^`{3,}/.exec(line)?.[0].length ?? 0;
+    if (run > 0) {
+      if (fenceLen === 0)
+        fenceLen = run;
+      else if (run >= fenceLen)
+        fenceLen = 0;
+      continue;
+    }
+    if (fenceLen > 0)
+      continue;
+    if (BLOCKQUOTE_PREFIX.test(line))
+      continue;
+    if (line.length === 0)
+      continue;
+    return line;
+  }
+  return "";
+}
+function leadingAddresseeIds(text) {
+  let rest = addressRegion(text);
+  const greeting = GREETING_PREFIX.exec(rest);
+  if (greeting)
+    rest = rest.slice(greeting[0].length);
+  const ids = [];
+  for (; ; ) {
+    const m = MENTION_AT_START.exec(rest);
+    const id = m?.[1];
+    if (!m || !id)
+      break;
+    const after = rest.slice(m[0].length);
+    if (/^['’]/.test(after))
+      break;
+    ids.push(id);
+    if (after.length === 0)
+      break;
+    const sep2 = ADDRESSEE_SEPARATOR.exec(after);
+    if (!sep2)
+      break;
+    rest = after.slice(sep2[0].length);
+  }
+  return ids;
+}
+function addressesAnotherRegisteredAgent(text, botUserId2, registeredAgentIds) {
+  if (!botUserId2)
+    return false;
+  if (!registeredAgentIds || registeredAgentIds.size === 0)
+    return false;
+  if (mentionsUser(text, botUserId2))
+    return false;
+  const addressees = leadingAddresseeIds(text);
+  if (addressees.includes(botUserId2))
+    return false;
+  return addressees.some((id) => id !== botUserId2 && registeredAgentIds.has(id));
+}
 function decideSlackAckReaction(input) {
   return Boolean(input.channel && input.ts);
 }
@@ -35014,6 +35096,97 @@ var INTEGRATION_REGISTRY = [
       ]
     }
   },
+  {
+    id: "origami",
+    name: "origami.chat",
+    category: "crm",
+    description: "Lead data + outbound: build and enrich lead lists, drive origami's AI worker from a natural-language brief, and read the tables it builds. Available on the platform-managed account, or with your own origami key.",
+    // ENG-7423: origami migrates from a customer-key-only integration to a
+    // PREMIUM one that ALSO keeps BYO — the Firecrawl / ADR-0055 model, with one
+    // structural difference that drives most of the design.
+    //
+    // Firecrawl's premium tier is a single platform account key that every
+    // customer's calls bill back to, and isolation is not a concern because a
+    // scrape has no tenancy. origami is the opposite: it stores the customer's
+    // LEAD LISTS, tables, chats and campaigns. Putting every customer on one
+    // parent org would make every customer's data mutually readable, so the
+    // managed tier gives each ORGANIZATION its own origami project (child org)
+    // and mints a key BOUND to that project (`POST /account/keys` with
+    // `project_id`, v3). See `packages/core/src/origami/provision.ts` for why a
+    // bound key rather than the `x-origami-project` header — in short, the
+    // header is a per-call assertion and the tool argument is deliberately
+    // nullable, so under a shared parent an ordinary tool call could reach it.
+    //
+    // ── auth types, and the ENG-9235 trap this deliberately re-enters ─────────
+    // Both are offered, unlike Firecrawl, which PARKED `api_key` down to
+    // `['none']` because a 2+-auth-type wizard renders a picker that is not
+    // entitlement-aware: a customer picks BYO, goes and fetches a vendor key,
+    // and is then rejected with `byo_not_entitled_by_plan` (BYO on a premium def
+    // needs `plans.byo_credentials`, enterprise-only today).
+    //
+    // origami cannot take that exit. BYO is the INCUMBENT here — every existing
+    // install is a customer's own key — so dropping `api_key` would remove the
+    // only mode its current customers use. The known gap is therefore accepted
+    // and pointed at its owner: the picker will still let a non-entitled org
+    // choose BYO and reject it afterwards. ENG-9236 (entitlement-aware wizard)
+    // is the fix; until it lands the rejection is at least loud, specific, and
+    // ahead of any charge.
+    //
+    // EXISTING installs are unaffected by that gate: the premium migration
+    // backfills them to `credential_source='byo'` AND stamps
+    // `config.byo_grandfathered_at`, which the call-time resolver honours in
+    // place of the plan check. Grandfathering is per-install and set only by
+    // that one migration — a NEW BYO install still needs the entitlement.
+    //
+    // KEEP IN LOCKSTEP with the `origami` rows in
+    // packages/supabase/seeds/integration-definitions.json and
+    // toolkit-definitions.json: those seeds carry their own auth types and are
+    // what `db:catalog:seed` upserts on every prod deploy, so editing this array
+    // alone changes nothing a customer can see.
+    supported_auth_types: ["none", "api_key"],
+    capabilities: [
+      { id: "origami:read", name: "Read Lists & Runs", description: "Discover projects and tables, read built tables and rows, poll runs/batches, and check credit balance. Credit-free.", access: "read" },
+      { id: "origami:write", name: "Enrich Leads", description: "Insert raw rows into an enrichment table (submit_enrichment). Consumes credits.", access: "write" },
+      { id: "origami:agent", name: "Drive the AI Worker", description: "Create an origami agent, send follow-up runs, cancel a run, archive an agent. Consumes credits.", access: "write" }
+    ],
+    docs_url: "https://docs.origami.chat/v3/overview",
+    // ENG-7423: premium (billable). origami bills internally in CREDITS, so the
+    // integration is usage-priced on one meter whose unit is the vendor's own
+    // billing unit. Priced at 2.0 c USD / 3.5 c AUD per credit by
+    // `20260907000050_origami_credits_rate_card.sql`, against a retail cost of
+    // 1.29-1.43 c/credit depending on which origami tier we hold.
+    //
+    // The note deliberately does NOT say "at cost". origami sells a
+    // SUBSCRIPTION WITH AN INCLUDED BUNDLE while this meters PER CREDIT
+    // CONSUMED, so a per-credit price recovers the subscription only at full
+    // utilisation — around 72% of the bundle at this rate. Calling that "at
+    // cost" in a customer-facing pricing string would be a claim about our
+    // margin that is only true at one utilisation level we do not control.
+    //
+    // ONE meter, not one per tool, because of where the number comes from. Every
+    // other premium integration meters at a server-side broker chokepoint, which
+    // sees each call and can attribute it. origami's agent surface is a
+    // host-resident stdio MCP server (ADR-0040) that calls origami.chat DIRECTLY
+    // — the control plane never sees the tool call, so there is no per-operation
+    // quantity to meter. What the control plane CAN see is the project's own
+    // spend (`GET /account/projects/{id}` → `usage.spent`), which the credit
+    // reconciler polls and meters as a delta. That is a per-project total, so it
+    // can only ever be one meter; splitting it per tool would require the vendor
+    // to break spend down by operation, which v3 does not expose.
+    //
+    // `unit_label` is set because the machine unit is the vendor's internal
+    // billing unit rather than a thing the customer asked for — "(per credit)"
+    // is the honest rendering, in the ADR-0053 cost-pass-through spirit.
+    //
+    // Only a MANAGED install is metered. A BYO install spends the customer's own
+    // origami credits on their own bill (`isBilledInstall` → false), which is why
+    // the reconciler polls only projects it provisioned.
+    premium: {
+      pricing: "usage",
+      note: "Billed per origami credit the agent consumes. Bring your own origami key instead and usage is billed to you by origami directly.",
+      meters: [{ event_type: "credits", unit: "credit", label: "origami credits", unit_label: "credit" }]
+    }
+  },
   {
     id: "ayrshare",
     name: "Ayrshare",
@@ -48992,7 +49165,17 @@ async function connectSocketMode() {
       });
       const participantEntry = threadKey ? trackedThreads.get(threadKey) : void 0;
       const botPostedInThread = participantEntry?.bot_posted === true || participantEntry?.involvement === "started";
-      const armMarker = decideMarkerArm({ shouldEngage, isAutoFollowed, botPostedInThread });
+      const addressesAnotherAgent = addressesAnotherRegisteredAgent(
+        text,
+        botUserId,
+        SLACK_SENDER_POLICY.registeredAgentSlackUserIds
+      );
+      const armMarker = decideMarkerArm({
+        shouldEngage,
+        isAutoFollowed,
+        botPostedInThread,
+        addressesAnotherAgent
+      });
       const ackProbe = process.env.TMUX && AGENT_CODE_NAME ? probeAgentSessionCached(AGENT_CODE_NAME) : { tmux: "unknown", claude: "unknown" };
       let paneLogFreshAgeMs = null;
       if (SLACK_AGENT_DIR) {

package/dist/mcp/telegram-channel.js

@@ -35146,6 +35146,97 @@ var INTEGRATION_REGISTRY = [
       ]
     }
   },
+  {
+    id: "origami",
+    name: "origami.chat",
+    category: "crm",
+    description: "Lead data + outbound: build and enrich lead lists, drive origami's AI worker from a natural-language brief, and read the tables it builds. Available on the platform-managed account, or with your own origami key.",
+    // ENG-7423: origami migrates from a customer-key-only integration to a
+    // PREMIUM one that ALSO keeps BYO — the Firecrawl / ADR-0055 model, with one
+    // structural difference that drives most of the design.
+    //
+    // Firecrawl's premium tier is a single platform account key that every
+    // customer's calls bill back to, and isolation is not a concern because a
+    // scrape has no tenancy. origami is the opposite: it stores the customer's
+    // LEAD LISTS, tables, chats and campaigns. Putting every customer on one
+    // parent org would make every customer's data mutually readable, so the
+    // managed tier gives each ORGANIZATION its own origami project (child org)
+    // and mints a key BOUND to that project (`POST /account/keys` with
+    // `project_id`, v3). See `packages/core/src/origami/provision.ts` for why a
+    // bound key rather than the `x-origami-project` header — in short, the
+    // header is a per-call assertion and the tool argument is deliberately
+    // nullable, so under a shared parent an ordinary tool call could reach it.
+    //
+    // ── auth types, and the ENG-9235 trap this deliberately re-enters ─────────
+    // Both are offered, unlike Firecrawl, which PARKED `api_key` down to
+    // `['none']` because a 2+-auth-type wizard renders a picker that is not
+    // entitlement-aware: a customer picks BYO, goes and fetches a vendor key,
+    // and is then rejected with `byo_not_entitled_by_plan` (BYO on a premium def
+    // needs `plans.byo_credentials`, enterprise-only today).
+    //
+    // origami cannot take that exit. BYO is the INCUMBENT here — every existing
+    // install is a customer's own key — so dropping `api_key` would remove the
+    // only mode its current customers use. The known gap is therefore accepted
+    // and pointed at its owner: the picker will still let a non-entitled org
+    // choose BYO and reject it afterwards. ENG-9236 (entitlement-aware wizard)
+    // is the fix; until it lands the rejection is at least loud, specific, and
+    // ahead of any charge.
+    //
+    // EXISTING installs are unaffected by that gate: the premium migration
+    // backfills them to `credential_source='byo'` AND stamps
+    // `config.byo_grandfathered_at`, which the call-time resolver honours in
+    // place of the plan check. Grandfathering is per-install and set only by
+    // that one migration — a NEW BYO install still needs the entitlement.
+    //
+    // KEEP IN LOCKSTEP with the `origami` rows in
+    // packages/supabase/seeds/integration-definitions.json and
+    // toolkit-definitions.json: those seeds carry their own auth types and are
+    // what `db:catalog:seed` upserts on every prod deploy, so editing this array
+    // alone changes nothing a customer can see.
+    supported_auth_types: ["none", "api_key"],
+    capabilities: [
+      { id: "origami:read", name: "Read Lists & Runs", description: "Discover projects and tables, read built tables and rows, poll runs/batches, and check credit balance. Credit-free.", access: "read" },
+      { id: "origami:write", name: "Enrich Leads", description: "Insert raw rows into an enrichment table (submit_enrichment). Consumes credits.", access: "write" },
+      { id: "origami:agent", name: "Drive the AI Worker", description: "Create an origami agent, send follow-up runs, cancel a run, archive an agent. Consumes credits.", access: "write" }
+    ],
+    docs_url: "https://docs.origami.chat/v3/overview",
+    // ENG-7423: premium (billable). origami bills internally in CREDITS, so the
+    // integration is usage-priced on one meter whose unit is the vendor's own
+    // billing unit. Priced at 2.0 c USD / 3.5 c AUD per credit by
+    // `20260907000050_origami_credits_rate_card.sql`, against a retail cost of
+    // 1.29-1.43 c/credit depending on which origami tier we hold.
+    //
+    // The note deliberately does NOT say "at cost". origami sells a
+    // SUBSCRIPTION WITH AN INCLUDED BUNDLE while this meters PER CREDIT
+    // CONSUMED, so a per-credit price recovers the subscription only at full
+    // utilisation — around 72% of the bundle at this rate. Calling that "at
+    // cost" in a customer-facing pricing string would be a claim about our
+    // margin that is only true at one utilisation level we do not control.
+    //
+    // ONE meter, not one per tool, because of where the number comes from. Every
+    // other premium integration meters at a server-side broker chokepoint, which
+    // sees each call and can attribute it. origami's agent surface is a
+    // host-resident stdio MCP server (ADR-0040) that calls origami.chat DIRECTLY
+    // — the control plane never sees the tool call, so there is no per-operation
+    // quantity to meter. What the control plane CAN see is the project's own
+    // spend (`GET /account/projects/{id}` → `usage.spent`), which the credit
+    // reconciler polls and meters as a delta. That is a per-project total, so it
+    // can only ever be one meter; splitting it per tool would require the vendor
+    // to break spend down by operation, which v3 does not expose.
+    //
+    // `unit_label` is set because the machine unit is the vendor's internal
+    // billing unit rather than a thing the customer asked for — "(per credit)"
+    // is the honest rendering, in the ADR-0053 cost-pass-through spirit.
+    //
+    // Only a MANAGED install is metered. A BYO install spends the customer's own
+    // origami credits on their own bill (`isBilledInstall` → false), which is why
+    // the reconciler polls only projects it provisioned.
+    premium: {
+      pricing: "usage",
+      note: "Billed per origami credit the agent consumes. Bring your own origami key instead and usage is billed to you by origami directly.",
+      meters: [{ event_type: "credits", unit: "credit", label: "origami credits", unit_label: "credit" }]
+    }
+  },
   {
     id: "ayrshare",
     name: "Ayrshare",

package/dist/{persistent-session-MG6FEYRY.js → persistent-session-XQG5H4KI.js}

@@ -54,8 +54,8 @@ import {
   writeDirectChatSessionState,
   writeEgressAllowlist,
   writePersistentClaudeWrapper
-} from "./chunk-SQ7PB5A6.js";
-import "./chunk-Q2OVEMUG.js";
+} from "./chunk-CA46EUVN.js";
+import "./chunk-EARM456T.js";
 import "./chunk-XWVM4KPK.js";
 export {
   EGRESS_BASELINE_DOMAINS,
@@ -114,4 +114,4 @@ export {
   writeEgressAllowlist,
   writePersistentClaudeWrapper
 };
-//# sourceMappingURL=persistent-session-MG6FEYRY.js.map
+//# sourceMappingURL=persistent-session-XQG5H4KI.js.map