@integrity-labs/agt-cli 0.28.875 → 0.28.877

package/dist/{chunk-6MGKXGCE.js → chunk-GYCS2NTY.js}

@@ -16,7 +16,7 @@ import {
   parseEnvIntegrations,
   shellQuote,
   summarizeUnanswerablePane
-} from "./chunk-SQ7PB5A6.js";
+} from "./chunk-CA46EUVN.js";
 import {
   BIND_FAILURE_QUARANTINE_THRESHOLD,
   INTEGRATIONS_SECTION_END,
@@ -76,7 +76,7 @@ import {
   sessionTranscriptDir,
   worseConnectivityOutcome,
   wrapScheduledTaskPrompt
-} from "./chunk-Q2OVEMUG.js";
+} from "./chunk-EARM456T.js";
 import {
   parsePsRows
 } from "./chunk-XWVM4KPK.js";
@@ -6771,7 +6771,7 @@ function exchangeFailureKind(err) {
 }
 
 // src/lib/api-client.ts
-var agtCliVersion = true ? "0.28.875" : "dev";
+var agtCliVersion = true ? "0.28.877" : "dev";
 var lastConfigHash = null;
 function setConfigHash(hash) {
   lastConfigHash = hash && hash.length > 0 ? hash : null;
@@ -11381,4 +11381,4 @@ export {
   managerInstallSystemUnitCommand,
   managerUninstallSystemUnitCommand
 };
-//# sourceMappingURL=chunk-6MGKXGCE.js.map
+//# sourceMappingURL=chunk-GYCS2NTY.js.map

package/dist/{claude-pair-runtime-GRZ2EHHR.js → claude-pair-runtime-G3SEYGH6.js}

@@ -100,7 +100,7 @@ async function spawnPairSession(session) {
     return { ok: true };
   } catch {
   }
-  const { resolveClaudeBinary } = await import("./persistent-session-MG6FEYRY.js");
+  const { resolveClaudeBinary } = await import("./persistent-session-XQG5H4KI.js");
   const claudeBin = resolveClaudeBinary();
   const pairEnv = {
     ...process.env,
@@ -373,4 +373,4 @@ export {
   startClaudePair,
   submitClaudePairCode
 };
-//# sourceMappingURL=claude-pair-runtime-GRZ2EHHR.js.map
+//# sourceMappingURL=claude-pair-runtime-G3SEYGH6.js.map

package/dist/lib/manager-worker.js

@@ -63,7 +63,7 @@ import {
   safeWriteJsonAtomic,
   setConfigHash,
   tripClass
-} from "../chunk-6MGKXGCE.js";
+} from "../chunk-GYCS2NTY.js";
 import {
   getProjectDir as getProjectDir2,
   getReadyTasks,
@@ -129,7 +129,7 @@ import {
   takeZombieDetection,
   toOpencodeModel,
   writeEgressAllowlist
-} from "../chunk-SQ7PB5A6.js";
+} from "../chunk-CA46EUVN.js";
 import {
   ACCOUNT_ENFORCEMENT_MARKER_FILENAME,
   AnchorSessionClient,
@@ -224,7 +224,7 @@ import {
   subagentActivityAgeSeconds,
   sumTranscriptUsageInWindow,
   transcriptActivityAgeSeconds
-} from "../chunk-Q2OVEMUG.js";
+} from "../chunk-EARM456T.js";
 import {
   reapOrphanChannelMcps
 } from "../chunk-XWVM4KPK.js";
@@ -13016,7 +13016,7 @@ var pendingDayRolloverReset = /* @__PURE__ */ new Set();
 var dayRolloverInboundHold = /* @__PURE__ */ new Map();
 var INBOUND_HOLD_EPISODE_GAP_MS = 12e4;
 async function channelInboundActivityAgeSecondsFor(codeName) {
-  const { newestPendingInboundActivityMtimeMs } = await import("../responsiveness-probe-2OGWHDXE.js");
+  const { newestPendingInboundActivityMtimeMs } = await import("../responsiveness-probe-LA4VGH5W.js");
   const newest = newestPendingInboundActivityMtimeMs(dirname11(paneLogPath(codeName)));
   if (newest === null) return null;
   return Math.max(0, Math.floor((Date.now() - newest) / 1e3));
@@ -13684,7 +13684,7 @@ var agentRestartTimezoneInputs = /* @__PURE__ */ new Map();
 var lastVersionCheckAt = 0;
 var VERSION_CHECK_INTERVAL_MS = 5 * 60 * 1e3;
 var lastResponsivenessProbeAt = 0;
-var agtCliVersion = true ? "0.28.875" : "dev";
+var agtCliVersion = true ? "0.28.877" : "dev";
 function resolveBrewPath(execFileSync2) {
   try {
     const out = execFileSync2("which", ["brew"], { timeout: 5e3 }).toString().trim();
@@ -15274,7 +15274,7 @@ function flushRestartedAgentDiagnostics(hostId, codeNames) {
   if (codeNames.length === 0) return;
   void (async () => {
     try {
-      const { collectDiagnostics } = await import("../persistent-session-MG6FEYRY.js");
+      const { collectDiagnostics } = await import("../persistent-session-XQG5H4KI.js");
       await api.post("/host/heartbeat", {
         host_id: hostId,
         agent_diagnostics: collectDiagnostics(codeNames, quarantineEntriesFor, claudeMdSizeFor, spawnOutcomeForDiagnostics, pidPressureFor, forwardedToolsFor)
@@ -15416,7 +15416,7 @@ async function pollCycleInner() {
     }
     try {
       const { detectHostSecurity } = await import("../host-security-6PDFG7F5.js");
-      const { collectDiagnostics } = await import("../persistent-session-MG6FEYRY.js");
+      const { collectDiagnostics } = await import("../persistent-session-XQG5H4KI.js");
       const diagCodeNames = [...agentState.persistentSessionAgents];
       const agentDiagnostics = diagCodeNames.length > 0 ? collectDiagnostics(diagCodeNames, quarantineEntriesFor, claudeMdSizeFor, spawnOutcomeForDiagnostics, pidPressureFor, forwardedToolsFor) : void 0;
       let tailscaleHostname;
@@ -15585,7 +15585,7 @@ async function pollCycleInner() {
         collectPanelessActivityProbes,
         getResponsivenessIntervalMs,
         occupancyQualificationClassifications
-      } = await import("../responsiveness-probe-2OGWHDXE.js");
+      } = await import("../responsiveness-probe-LA4VGH5W.js");
       const probeIntervalMs = getResponsivenessIntervalMs();
       if (now - lastResponsivenessProbeAt > probeIntervalMs) {
         const probeCodeNames = [...agentState.persistentSessionAgents];
@@ -15702,7 +15702,7 @@ async function pollCycleInner() {
           collectResponsivenessProbes,
           livePendingInboundOldestAgeSeconds,
           parkPendingInbound
-        } = await import("../responsiveness-probe-2OGWHDXE.js");
+        } = await import("../responsiveness-probe-LA4VGH5W.js");
         const { getProjectDir: wedgeProjectDir } = await import("../scheduler-engine-NDP36U7O.js");
         const wedgeNow = /* @__PURE__ */ new Date();
         const liveAgents = agentState.persistentSessionAgents;
@@ -15858,7 +15858,7 @@ async function pollCycleInner() {
     }
     try {
       const { scrapeMcpFailedBannerCount } = await import("../pane-mcp-banner-scraper-JA437JIB.js");
-      const { probeSessionAuth } = await import("../session-auth-dead-AHL6D3CM.js");
+      const { probeSessionAuth } = await import("../session-auth-dead-DFLSWVAQ.js");
       const observations = [];
       const pendingCacheCommits = [];
       const modelApiErrorReportingOn = hostFlagStore().getBoolean("model-api-error-reporting");
@@ -20103,7 +20103,7 @@ async function handleRestartDoorbell(agentId, requestedAt, restartReason) {
       try {
         const freshId = rotateSessionForWedge(codeName);
         consecutiveWedgeCycles.delete(codeName);
-        const { parkPendingInbound: parkForRestart } = await import("../responsiveness-probe-2OGWHDXE.js");
+        const { parkPendingInbound: parkForRestart } = await import("../responsiveness-probe-LA4VGH5W.js");
         const { parked, deadLettered } = parkForRestart(codeName, /* @__PURE__ */ new Date());
         const parkNote = parked > 0 ? `, ${parked} inbound parked` : "";
         const deadNote = deadLettered > 0 ? `, ${deadLettered} undeliverable dead-lettered` : "";
@@ -20141,7 +20141,7 @@ async function handleRestartDoorbell(agentId, requestedAt, restartReason) {
     void api.post("/host/restart-ack", { host_id: hostId, agent_id: agentId, restart_requested_at: requestedAt }).catch((err) => log(`[restart-lane] ack failed for '${codeName}': ${err.message}`));
     void (async () => {
       try {
-        const { collectDiagnostics } = await import("../persistent-session-MG6FEYRY.js");
+        const { collectDiagnostics } = await import("../persistent-session-XQG5H4KI.js");
         await api.post("/host/heartbeat", {
           host_id: hostId,
           agent_diagnostics: collectDiagnostics([codeName], quarantineEntriesFor, claudeMdSizeFor, spawnOutcomeForDiagnostics, pidPressureFor, forwardedToolsFor)
@@ -20187,7 +20187,7 @@ async function respawnAgentAfterMcpStop(codeName, reason) {
     }
     try {
       const hostId = await getHostId();
-      const { collectDiagnostics } = await import("../persistent-session-MG6FEYRY.js");
+      const { collectDiagnostics } = await import("../persistent-session-XQG5H4KI.js");
       await api.post("/host/heartbeat", {
         host_id: hostId,
         agent_diagnostics: collectDiagnostics([codeName], quarantineEntriesFor, claudeMdSizeFor, spawnOutcomeForDiagnostics, pidPressureFor, forwardedToolsFor)
@@ -20823,7 +20823,7 @@ async function processClaudePairSessions(agents) {
     killPairSession,
     pairTmuxSession,
     finalizeClaudePairOnboarding
-  } = await import("../claude-pair-runtime-GRZ2EHHR.js");
+  } = await import("../claude-pair-runtime-G3SEYGH6.js");
   for (const pairId of pendingResp.cancelled_pair_ids ?? []) {
     log(`[claude-pair] sweeping orphan tmux session for pair ${pairId.slice(0, 8)}`);
     const killed = await killPairSession(pairTmuxSession(pairId));

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

@@ -35096,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",