@vellumai/assistant 0.12.1 → 0.12.2-staging.1

package/src/notifications/conversation-pairing.ts

@@ -130,6 +130,7 @@ export interface PairingOptions {
  * transactional request or a system alert.
  */
 const ASSISTANT_SHARE_EVENT = "assistant.share";
+const ASSISTANT_REPLY_EVENT = "chat.assistant_reply";
 
 /**
  * Promote a background share into an assistant-initiated thread, under the
@@ -263,7 +264,25 @@ export async function pairDeliveryWithConversation(
     // notification can appear. The home feed aims its "Go to Conversation"
     // button at the same row whenever it mirrors the signal.
     //
-    // So this is deliberately not gated on home-feed eligibility: a signal the
+    // `chat.assistant_reply` already has its complete reply in that transcript.
+    // Its notification body is a lock-screen preview, so appending it would
+    // create a second, truncated assistant row. Keep the conversation target
+    // for deep links without writing the preview into the transcript.
+    if (
+      strategy === "start_new_conversation" &&
+      !signal.requiresConversation &&
+      signal.sourceEventName === ASSISTANT_REPLY_EVENT
+    ) {
+      return {
+        conversationId: resolveSourceConversationId(signal),
+        messageId: null,
+        strategy,
+        createdNewConversation: false,
+        conversationFallbackUsed: false,
+      };
+    }
+
+    // This is deliberately not gated on home-feed eligibility: a signal the
     // feed declines to mirror still reaches the user through the banner, and
     // this row is what makes that landing honest.
     if (strategy === "start_new_conversation" && !signal.requiresConversation) {
@@ -748,44 +767,45 @@ async function resolveChannelDeliveryHome(params: {
  * Indexing is skipped for parity with the other notification write paths:
  * notification copy is delivery audit, not conversational memory.
  */
-async function appendBodyToSourceConversation(
-  signal: NotificationSignal,
-  channel: NotificationChannel,
-  messageContent: string,
-): Promise<{ conversationId: string; messageId: string } | null> {
-  const sourceContextId = signal.sourceContextId;
-  if (!sourceContextId) {
+function resolveSourceConversationId(signal: NotificationSignal): string | null {
+  if (!signal.sourceContextId) {
     return null;
   }
-
-  let existing: ReturnType<typeof getConversation>;
   try {
-    existing = getConversation(sourceContextId);
+    return getConversation(signal.sourceContextId)?.id ?? null;
   } catch {
     return null;
   }
-  if (!existing) {
+}
+
+async function appendBodyToSourceConversation(
+  signal: NotificationSignal,
+  channel: NotificationChannel,
+  messageContent: string,
+): Promise<{ conversationId: string; messageId: string } | null> {
+  const conversationId = resolveSourceConversationId(signal);
+  if (!conversationId) {
     return null;
   }
 
-  const message = await addMessage(existing.id, "assistant", messageContent, {
+  const message = await addMessage(conversationId, "assistant", messageContent, {
     skipIndexing: true,
   });
   // `addMessage` projects attention metadata alone, so a client with this
   // conversation open needs the messages tag to refetch the transcript. A
   // notification the user taps through to has every chance of landing on an
   // already-open conversation.
-  publishConversationMessagesChanged(existing.id);
+  publishConversationMessagesChanged(conversationId);
 
   log.info(
     {
       signalId: signal.signalId,
       channel,
-      conversationId: existing.id,
+      conversationId,
       messageId: message.id,
     },
     "Appended notification body to producing conversation",
   );
 
-  return { conversationId: existing.id, messageId: message.id };
+  return { conversationId, messageId: message.id };
 }

package/src/notifications/delivered-post-record.ts

@@ -39,6 +39,12 @@ export interface DeliveredChannelPost {
   text: string;
   /** The message id the channel assigned when it acknowledged the post. */
   providerMessageId: string;
+  /**
+   * The ids of the further posts the same text became when the channel
+   * split it, in send order. Each is reconciled onto the row like the first,
+   * so a reaction, edit, or delete naming any chunk resolves to this row.
+   */
+  additionalProviderMessageIds?: readonly string[];
   /**
    * The conversation whose turn made the post, when a different one from
    * the home it is recorded in (the messaging tool sending from a scheduled
@@ -75,7 +81,11 @@ export async function recordDeliveredChannelPost(
         : {}),
     },
   });
-  await makeSentMessageIdReconciler(row.id)(post.providerMessageId);
+  const reconcile = makeSentMessageIdReconciler(row.id);
+  await reconcile(post.providerMessageId);
+  for (const id of post.additionalProviderMessageIds ?? []) {
+    await reconcile(id);
+  }
   // A resident conversation reloads its history on the next turn so the
   // post is in context; the client refetches the transcript.
   findConversation(post.conversationId)?.markHistoryStale();

package/src/notifications/guardian-feed-projection.ts

@@ -31,6 +31,10 @@ import {
   patchFeedItemContent,
   readHomeFeed,
 } from "../home/feed-writer.js";
+import {
+  getMemoryCheckpoint,
+  setMemoryCheckpoint,
+} from "../persistence/checkpoints.js";
 import { getLogger } from "../util/logger.js";
 import {
   buildToolApprovalSourceView,
@@ -166,11 +170,17 @@ export interface GuardianFeedReceiptParams {
  *
  * The item keeps its title and summary; `guardianRequest` flips to the
  * terminal status (which is what removes the client's action buttons),
- * and urgency drops to `medium` so the item leaves the protected
- * "Needs attention" treatment and becomes an ordinary clearable
- * notification. Returns false only when the write itself failed, so the
- * withdrawal fan-out can hold its per-request receipt back and retry
- * (same contract as the other surfaces it settles). A request with no
+ * urgency drops to `medium` so the item leaves the protected "Needs
+ * attention" treatment and becomes an ordinary clearable notification,
+ * and an item still marked `new` is marked `seen`: a request settled on
+ * any surface is no longer something the user has to review, and leaving
+ * it unread is a false attention signal. That clear happens only on the
+ * edge into terminal, so a status the user set later (including marking
+ * the receipt unread again) survives a caller that receipts twice.
+ *
+ * Returns false only when the write itself failed, so the withdrawal
+ * fan-out can hold its per-request receipt back and retry (same
+ * contract as the other surfaces it settles). A request with no
  * projection item resolves true: the pending writer converges the
  * write-vs-resolve race by re-checking canonical status after its
  * append, so there is nothing here for a retry to fix.
@@ -197,6 +207,15 @@ export async function writeGuardianFeedReceipt(
     }
     const updated = await patchFeedItemContent(itemId, {
       urgency: "medium",
+      // Only on the pending-to-terminal edge. A later receipt for the
+      // same request (the fan-out retries per surface, reconciliation
+      // heals drift) must not undo a user who marked the receipt unread
+      // again; from `new` specifically, because a pending item the user
+      // dismissed outright stays dismissed.
+      status: (existing) =>
+        existing.status === "new" && isPendingGuardianFeedItem(existing)
+          ? "seen"
+          : existing.status,
       guardianRequest: (existing) => ({
         ...existing,
         status: params.status,
@@ -268,6 +287,103 @@ export async function receiptGuardianFeedItemIfRequestTerminal(
  */
 const RECONCILE_BACKFILL_LIMIT = 50;
 
+/** Ceiling on rows healed per round, mirroring the backfill bound. */
+const LEGACY_UNREAD_HEAL_LIMIT = 50;
+
+/**
+ * Completion sentinel for the one-time heal below, in the daemon's
+ * checkpoint ledger (the same shape as the lexical backfill's
+ * `lexical:messages:backfill_complete`). It is the only thing that
+ * separates the two kinds of terminal receipt stored at `status: "new"`:
+ * one that never passed the pending-to-terminal edge, and one the user
+ * marked unread after it did. The rows are byte-identical (terminal
+ * projection, urgency `medium`), so the boundary is recorded rather
+ * than inferred.
+ */
+const LEGACY_UNREAD_HEAL_COMPLETE_KEY =
+  "guardian_feed:receipt_unread_heal_complete";
+
+/**
+ * Clear unread on terminal guardian receipts that never passed the
+ * pending-to-terminal edge in `writeGuardianFeedReceipt`.
+ *
+ * Nothing else reaches those rows: the edge runs only while a
+ * projection still reads pending, reconciliation skips items whose
+ * projection is already terminal, and guardian items carry no
+ * `expiresAt`. Without this pass they read unread indefinitely.
+ *
+ * Runs once per assistant, not once per boot. A recurring pass would
+ * take back a deliberate "mark unread" every minute, and a per-boot pass
+ * would take it back on the next restart; the sentinel is what makes a
+ * later `new` unambiguously the user's, so it is never touched.
+ *
+ * Same user-choice semantics as the edge, enforced the same way: the
+ * transition is re-evaluated inside the writer's coalescing queue, moves
+ * only `new`, and leaves `seen`, `acted_on` and `dismissed` alone.
+ * Bounded per round, and the sentinel is written only once a round drains
+ * with nothing left and nothing failed, so an interrupted pass resumes.
+ */
+export async function healLegacyGuardianReceiptUnread(): Promise<void> {
+  try {
+    if (getMemoryCheckpoint(LEGACY_UNREAD_HEAL_COMPLETE_KEY) === "1") {
+      return;
+    }
+  } catch (err) {
+    // A DB that cannot answer skips the round rather than risk re-healing
+    // a row the user has since marked unread.
+    log.warn({ err }, "Guardian receipt unread heal: checkpoint unreadable");
+    return;
+  }
+
+  const stale = readHomeFeed().items.filter(
+    (item) =>
+      item.guardianRequest !== undefined &&
+      !isPendingGuardianFeedItem(item) &&
+      item.status === "new",
+  );
+
+  const batch = stale.slice(0, LEGACY_UNREAD_HEAL_LIMIT);
+  let failed = 0;
+  for (const item of batch) {
+    // Re-tested at write time rather than trusted from the read above,
+    // so a row the edge transition or the user changed in between keeps
+    // whatever it was given.
+    const updated = await patchFeedItemContent(item.id, {
+      status: (existing) =>
+        existing.status === "new" && !isPendingGuardianFeedItem(existing)
+          ? "seen"
+          : existing.status,
+    });
+    if (!updated) {
+      failed++;
+    }
+  }
+
+  if (batch.length > 0) {
+    log.info(
+      {
+        healed: batch.length - failed,
+        failed,
+        remaining: stale.length - batch.length,
+      },
+      "Cleared unread on terminal guardian receipts that never passed the edge",
+    );
+  }
+
+  if (failed > 0 || stale.length > batch.length) {
+    // Not finished: leave the sentinel unset so the next round resumes.
+    return;
+  }
+
+  try {
+    setMemoryCheckpoint(LEGACY_UNREAD_HEAL_COMPLETE_KEY, "1");
+  } catch (err) {
+    // The heal itself landed; only the sentinel is missing, so the next
+    // round repeats a pass that now has nothing to do.
+    log.warn({ err }, "Guardian receipt unread heal: checkpoint not persisted");
+  }
+}
+
 /**
  * Converge the feed against canonical guardian state. Run from the
  * guardian expiry sweep, so drift heals on the same cadence expiry does:
@@ -285,6 +401,10 @@ const RECONCILE_BACKFILL_LIMIT = 50;
  * not be mistaken for "everything resolved".
  */
 export async function reconcileGuardianFeedProjections(): Promise<void> {
+  // Ahead of the gateway read: the heal heads off stored rows alone and
+  // must not be held up by an unreachable gateway.
+  await healLegacyGuardianReceiptUnread();
+
   let pending: GuardianRequestWire[];
   try {
     pending = await listGuardianRequests({ status: "pending" });

package/src/notifications/home-feed-side-effect.ts

@@ -23,7 +23,10 @@ import {
   getMessageById,
   updateMessageContent,
 } from "../persistence/conversation-crud.js";
-import { isBackgroundConversationType } from "../persistence/conversation-types.js";
+import {
+  ASSISTANT_INITIATED_SOURCE,
+  isBackgroundConversationType,
+} from "../persistence/conversation-types.js";
 import { publishConversationMessagesChanged } from "../runtime/sync/resource-sync-events.js";
 import { getLogger } from "../util/logger.js";
 import { normalizeTitle, stripMarkdown } from "../util/short-title.js";
@@ -272,6 +275,11 @@ async function resolveOwnedConversationMessageId(
   sourceConversationId: string | undefined,
   summary: string,
 ): Promise<string | undefined> {
+  // The completed reply is already the source conversation's canonical row.
+  // This signal's body is a compact push preview, not conversation content.
+  if (signal.sourceEventName === "chat.assistant_reply") {
+    return undefined;
+  }
   if (vellumDelivery?.conversationId) {
     return vellumDelivery.conversationId === sourceConversationId
       ? vellumDelivery.messageId
@@ -495,6 +503,18 @@ function deriveDetailPanelKind(
  * `isAsyncBackground` hint. `chat.assistant_reply` also mirrors: it is the
  * durable in-app record for the push sent after a user leaves a chat, while
  * retaining the normal interactive conversation as its navigation target.
+ *
+ * A delivery that materialized an assistant-initiated thread never mirrors.
+ * Under the `assistant-initiated-threads` flag, `conversation-pairing.ts`
+ * promotes a background `assistant.share` into a standard conversation
+ * stamped {@link ASSISTANT_INITIATED_SOURCE}, and that thread's row in the
+ * sidebar's assistant section is the share's one surface. Mirroring it here
+ * as well put the same share in the bell a second time, labeled by its
+ * source channel ("Heartbeat"). The check reads the paired conversation's
+ * `source` rather than re-deriving the promotion rule, so it holds however
+ * that rule narrows or widens. Guardian requests are checked first on
+ * purpose: the bell is their canonical home whatever conversation they pair
+ * with.
  */
 function resolveHomeFeedMirror(
   signal: NotificationSignal,
@@ -525,6 +545,15 @@ function resolveHomeFeedMirror(
     : fallbackConversationId;
   const sourceScheduleJobId = sourceRow?.scheduleJobId ?? undefined;
 
+  // Guardian requests always project into the feed: the "Needs
+  // attention" item is the request's canonical home, and the request
+  // blocks on the guardian whatever kind of conversation raised it.
+  if (isGuardianRequestSignalEvent(signal.sourceEventName)) {
+    return { mirror: true, sourceConversationId, sourceScheduleJobId };
+  }
+  if (isAssistantInitiatedThreadDelivery(fallbackConversationId)) {
+    return { mirror: false };
+  }
   if (
     signal.sourceChannel === "assistant_tool" ||
     signal.sourceEventName === "chat.assistant_reply"
@@ -534,18 +563,37 @@ function resolveHomeFeedMirror(
   if (signal.attentionHints.isAsyncBackground) {
     return { mirror: true, sourceConversationId, sourceScheduleJobId };
   }
-  // Guardian requests always project into the feed: the "Needs
-  // attention" item is the request's canonical home, and the request
-  // blocks on the guardian whatever kind of conversation raised it.
-  if (isGuardianRequestSignalEvent(signal.sourceEventName)) {
-    return { mirror: true, sourceConversationId, sourceScheduleJobId };
-  }
   if (isBackgroundConversationType(sourceRow?.conversationType)) {
     return { mirror: true, sourceConversationId, sourceScheduleJobId };
   }
   return { mirror: false };
 }
 
+/**
+ * Whether the vellum delivery this signal produced landed in a thread the
+ * sidebar's assistant section already shows.
+ *
+ * Best-effort like the source lookup above: a missing id, a missing row, or
+ * a lookup failure all read as "not an assistant thread", so a storage
+ * hiccup degrades to the pre-existing behavior (a bell row) rather than
+ * dropping the notification everywhere.
+ */
+function isAssistantInitiatedThreadDelivery(
+  deliveryConversationId: string | undefined,
+): boolean {
+  if (!deliveryConversationId) {
+    return false;
+  }
+  try {
+    return (
+      getConversation(deliveryConversationId)?.source ===
+      ASSISTANT_INITIATED_SOURCE
+    );
+  } catch {
+    return false;
+  }
+}
+
 /**
  * Routing-intent enforcement can prune `selectedChannels` without also
  * pruning `renderedCopy`, so iterating `renderedCopy` directly risks

package/src/notifications/schedule-result-producer.ts

@@ -32,6 +32,7 @@ import { getAttentionStateByConversationIds } from "../persistence/conversation-
 import {
   getAssistantMessageIdsInTurn,
   getMessageById,
+  getMessagesAfter,
   type MessageRow,
 } from "../persistence/conversation-crud.js";
 import { stringifyMessageContent } from "../persistence/message-content.js";
@@ -39,7 +40,6 @@ import {
   isPrivateAssistantText,
   projectPersistedAssistantContent,
 } from "../persistence/user-facing-content.js";
-import type { ContentBlock } from "../providers/types.js";
 import { emitNotificationSignal } from "./emit-signal.js";
 import { hasNotifiedSourceContextSince } from "./events-store.js";
 import {
@@ -79,28 +79,72 @@ export interface ScheduleResultNotificationParams {
 }
 
 /**
- * Whether a tool call in the run's turn delivered the result somewhere the
- * user will see it, outside the notification pipeline.
+ * Whether the run delivered its result through the messaging tool, and the
+ * call succeeded.
  *
- * The schedule skill prescribes two such routes for rich content — the
- * messaging tool for email, and the Slack Web API's `chat.postMessage` through
- * bash — and neither writes a `notification_events` row, so the pipeline probe
- * cannot see them. Without this check a well-authored Slack digest would post
+ * The messaging tool is the route the schedule skill prescribes for rich
+ * content, and it writes no `notification_events` row, so the pipeline probe
+ * cannot see it. Without this check a well-authored Slack digest would post
  * its summary and then get a second notification whose body is "Posted the
- * digest to #general." This is a recognized-routes list, not a general "did
- * the run do anything?" heuristic: a route that is not here gets the fallback,
- * which is the safe failure.
+ * digest to #general."
+ *
+ * Both conditions are load-bearing. The route has to be recognized, because
+ * this is a known-routes list rather than a general "did the run do anything?"
+ * heuristic. And the call has to have succeeded: a `tool_use` block records
+ * only that the model called the tool, so a send the channel refused leaves
+ * the same block as one that landed, and suppressing on it costs the user both
+ * the digest and the run's explanation of the failure. The executor's verdict
+ * is on the `tool_result` the call produced, so success is read from there,
+ * and a call with no result counts as undelivered. Either condition unmet gets
+ * the fallback, which is the safe failure.
+ *
+ * The result read starts at the run's first row, so it covers the results
+ * interleaved through the turn. Rows from a later turn in a reused
+ * conversation can come back too and are harmless, because only this run's
+ * own call ids are matched.
+ *
+ * A Slack Web API post through bash is deliberately not a route, because its
+ * success proves nothing about the post. Slack refuses a call with HTTP 200
+ * and `ok: false` in the body, and the authenticated-request command fails
+ * only on a non-2xx status, so a post Slack refused still leaves a successful
+ * tool result. A run that posts that way gets the fallback too: at worst a
+ * duplicate, never a silence.
  */
-function isDirectDelivery(block: ContentBlock): boolean {
-  if (block.type !== "tool_use") {
-    return false;
+function deliveredThroughMessagingTool(
+  conversationId: string,
+  runRows: readonly MessageRow[],
+): boolean {
+  const callIds = new Set<string>();
+  for (const row of runRows) {
+    for (const block of row.content) {
+      if (block.type === "tool_use" && block.name === "messaging_send") {
+        callIds.add(block.id);
+      }
+    }
   }
-  if (block.name === "messaging_send") {
-    return true;
+  if (callIds.size === 0) {
+    return false;
   }
-  if (block.name === "bash") {
-    const command = (block.input as { command?: unknown } | undefined)?.command;
-    return typeof command === "string" && command.includes("chat.postMessage");
+  const [firstRunRow] = runRows;
+  for (const row of getMessagesAfter(conversationId, {
+    id: firstRunRow.id,
+    createdAt: firstRunRow.createdAt,
+  })) {
+    if (row.role !== "user") {
+      continue;
+    }
+    for (const block of row.content) {
+      // guard:allow-tool-result-only: the local executor's verdict on a
+      // delivery it ran. A server-side `web_search_tool_result` carries no
+      // `is_error` and never delivers anything.
+      if (
+        block.type === "tool_result" &&
+        block.is_error !== true &&
+        callIds.has(block.tool_use_id)
+      ) {
+        return true;
+      }
+    }
   }
   return false;
 }
@@ -237,11 +281,11 @@ export async function emitScheduleResultNotification(
       return;
     }
 
-    // The run delivered around the pipeline — an email through the messaging
-    // tool, a Slack post through the Web API. The user has the result; a
-    // notification reading "posted it" on top would be the duplicate.
+    // The run delivered around the pipeline through the messaging tool, and
+    // the call succeeded. The user has the result; a notification reading
+    // "posted it" on top would be the duplicate.
     const runRows = collectRunRows(latestRow, conversationId, runStartedAt);
-    if (runRows.some((row) => row.content.some(isDirectDelivery))) {
+    if (deliveredThroughMessagingTool(conversationId, runRows)) {
       return;
     }
 

package/src/oauth/AGENTS.md

@@ -8,6 +8,8 @@ When introducing a new built-in OAuth integration (one that appears in `seed-pro
 
 Add an entry to `PROVIDER_SEED_DATA`. Required fields: `provider`, `authorizeUrl`, `tokenExchangeUrl`, `defaultScopes`, `displayLabel`, `description`, `dashboardUrl`, `clientIdPlaceholder`, `logoUrl`, and `injectionTemplates`. Optional: `availableScopes` — either a structured array of `{scope, description?}` objects or a URL string pointing to the provider's scope documentation. See existing entries for the full shape. The `provider` key must be snake_case and is used as the canonical identifier everywhere else.
 
+`injectionTemplates` is also a security boundary, not only an injection rule. `assistant oauth request` and `assistant channels request` accept an absolute URL only when its host matches one of the entry's `hostPattern` values (`assertOAuthRequestUrlAllowed` in `../runtime/routes/oauth-commands-routes.ts`), so that list is the full set of hosts the credential may be sent to. A pattern matches exactly unless it starts with `*.`; reserve the wildcard for per-tenant hosts that cannot be enumerated (`*.salesforce.com`), and name a fixed host the provider documents (`files.slack.com`) by name. The guard sees only the URL the caller passes: the connection follows a redirect itself, and a cross-origin hop carries no `Authorization`, so a redirect target never receives the credential and never needs listing.
+
 If the provider will support managed mode, set `managedServiceConfigKey` to a slug matching the key you will add to `ServicesSchema` (e.g. `"acme-oauth"`).
 
 ### 2. _(managed only)_ Add a service schema — `../config/schemas/services.ts`

package/src/oauth/__tests__/seed-providers-managed.test.ts

@@ -127,6 +127,60 @@ describe("PROVIDER_SEED_DATA managed mode wiring", () => {
     expect(figma.featureFlag).toBe("figma-oauth");
   });
 
+  test("shopify keeps its per-tenant URL templates", () => {
+    // Shopify has no global OAuth host: every endpoint lives on the
+    // merchant's own domain. Hardcoding any host here would send every
+    // merchant's authorization to the wrong store, so the {tenant_host}
+    // placeholder the platform substitutes must survive.
+    const shopify = PROVIDER_SEED_DATA.shopify;
+    expect(shopify).toBeDefined();
+    for (const url of [
+      shopify.authorizeUrl,
+      shopify.tokenExchangeUrl,
+      shopify.refreshUrl,
+      shopify.baseUrl,
+      shopify.identityUrl,
+    ]) {
+      expect(url).toContain("{tenant_host}");
+    }
+  });
+
+  test("shopify requests comma-separated scopes", () => {
+    // Shopify parses `scope` as a comma-separated list; the OAuth2 default
+    // space separator is read as one malformed scope and the whole
+    // authorization request is rejected.
+    expect(PROVIDER_SEED_DATA.shopify.scopeSeparator).toBe(",");
+  });
+
+  test("shopify does not request approval-gated scopes", () => {
+    // Shopify rejects the entire authorization request when the app cannot
+    // grant a requested scope -- the same failure that broke monday and
+    // Figma. These scopes all require Shopify's prior approval.
+    const gated = [
+      "read_all_orders",
+      "read_customer_payment_methods",
+      "read_own_subscription_contracts",
+      "write_own_subscription_contracts",
+      "read_shopify_payments_dispute_evidences",
+      "write_shopify_payments_dispute_evidences",
+    ];
+    for (const scope of gated) {
+      expect(PROVIDER_SEED_DATA.shopify.defaultScopes).not.toContain(scope);
+    }
+  });
+
+  test("shopify injects the Admin API's own auth header", () => {
+    // The Admin API reads X-Shopify-Access-Token and ignores an
+    // Authorization: Bearer header entirely, so a Bearer template here would
+    // make every proxied request unauthenticated.
+    const templates = PROVIDER_SEED_DATA.shopify.injectionTemplates;
+    expect(templates).toBeDefined();
+    const [template] = templates ?? [];
+    expect(template?.headerName).toBe("X-Shopify-Access-Token");
+    expect(template?.valuePrefix).toBe("");
+    expect(template?.hostPattern).toBe("*.myshopify.com");
+  });
+
   test("every managedServiceConfigKey resolves to a ServicesSchema key", () => {
     // Cross-repo invariant: a provider with managedServiceConfigKey but no
     // matching ServicesSchema entry silently falls back to BYO mode in