astroidjs 0.12.1 → 0.13.0

package/dist/astro/index.js

@@ -1,6 +1,6 @@
 // Copyright (c) 2026 BowenLabs. Astroid is MIT licensed.
 //
-// `astroidjs/astro` — the BUILD-TIME surface, imported from `astro.config.mjs`.
+// `astroidjs/astro`—the BUILD-TIME surface, imported from `astro.config.mjs`.
 // Kept off the main entry on purpose: it reaches for `node:crypto` and
 // `solid-js/web`, neither of which belongs in the Worker bundle the generated
 // `worker.ts` produces.

package/dist/auth/index.d.ts

@@ -1,6 +1,6 @@
 import type { AstroidConfig } from "../config.js";
 /**
- * The editor Better Auth instance's table prefix — `louise_user`,
+ * The editor Better Auth instance's table prefix—`louise_user`,
  * `louise_session`, … The unprefixed names are left free for a second (portal)
  * instance. Consumed by the generated `editorsRoute` and mirrored by the
  * scaffolded `src/auth.ts` (`getLouiseAuth({ tablePrefix })`) + its migration.
@@ -12,7 +12,7 @@ export declare const ASTROID_EDITOR_TABLE_PREFIX = "louise_";
  * reject a portal that would collide with it.
  */
 export declare const ASTROID_EDITOR_COOKIE_PREFIX = "better-auth";
-/** The editor's Better Auth table name for a given model (e.g. `louise_user`). */
+/** The editor's Better Auth table name for a given model (for example, `louise_user`). */
 export declare function astroidEditorTable(model: string): string;
 /**
  * Reject a portal whose isolation would collide with the editor instance on the

package/dist/auth/index.js

@@ -3,12 +3,12 @@
 // Editor-auth convention + the two-instance isolation guard.
 //
 // Astroid runs up to TWO Better Auth instances on one origin: the EDITOR (the
-// studio — magic-link + passkey, a DB-managed admin allowlist) and, optionally, a
-// second PORTAL instance (customers/members/a shop account — see `portal/`). The
+// studio—magic-link + passkey, a DB-managed admin allowlist) and, optionally, a
+// second PORTAL instance (customers/members/a shop account—see `portal/`). The
 // editor owns Better Auth's default mount (`/api/auth`) and cookie because the
 // Louise editor client hardcodes them; its tables are namespaced with the
 // `louise_` prefix so a second instance can take the unprefixed `user`/`session`
-// tables without collision. The portal is the one that MOVES — a distinct mount,
+// tables without collision. The portal is the one that MOVES—a distinct mount,
 // cookie prefix, and (by default) table prefix.
 //
 // The failure this guards against is subtle and intermittent: two instances that
@@ -18,7 +18,7 @@
 import { AstroidConfigError } from "../errors.js";
 import { astroidPortal } from "../portal/config.js";
 /**
- * The editor Better Auth instance's table prefix — `louise_user`,
+ * The editor Better Auth instance's table prefix—`louise_user`,
  * `louise_session`, … The unprefixed names are left free for a second (portal)
  * instance. Consumed by the generated `editorsRoute` and mirrored by the
  * scaffolded `src/auth.ts` (`getLouiseAuth({ tablePrefix })`) + its migration.
@@ -30,7 +30,7 @@ export const ASTROID_EDITOR_TABLE_PREFIX = "louise_";
  * reject a portal that would collide with it.
  */
 export const ASTROID_EDITOR_COOKIE_PREFIX = "better-auth";
-/** The editor's Better Auth table name for a given model (e.g. `louise_user`). */
+/** The editor's Better Auth table name for a given model (for example, `louise_user`). */
 export function astroidEditorTable(model) {
     return `${ASTROID_EDITOR_TABLE_PREFIX}${model}`;
 }

package/dist/commerce/adapters.d.ts

@@ -62,7 +62,7 @@ export interface FourthwallProductLike {
  * Is this item sold at `locationId` at all?
  *
  * Exported because a location-scoped sync needs to SKIP items the merchant
- * doesn't carry, and `squareToCatalogItem` can't do that for you — it returns
+ * doesn't carry, and `squareToCatalogItem` can't do that for you—it returns
  * one item, and "don't store this row" isn't a `CatalogItem`. Without the guard
  * an unstocked item mirrors as a $0 card with no variants, which looks like a
  * pricing bug rather than a catalog decision.
@@ -79,7 +79,7 @@ export declare function squareItemSoldAt(item: SquareItemLike, locationId: strin
  *
  * `price` is the LOWEST variation price. A Square item is a family ("Bag of
  * beans" with 12oz and 2lb variations), so a single headline number has to mean
- * "from" — taking the first variation's price instead would change with Square's
+ * "from"—taking the first variation's price instead would change with Square's
  * ordering and quietly misprice the card.
  *
  * ## Scoping to one merchant
@@ -90,22 +90,22 @@ export declare function squareItemSoldAt(item: SquareItemLike, locationId: strin
  *
  * The headline number has to be scoped for the same reason the variants are.
  * "From $8" computed over the whole catalog, on a page where the $8 size isn't
- * stocked, advertises a price this merchant will never honour — and because the
+ * stocked, advertises a price this merchant will never honour—and because the
  * dropped variation is usually the cheap one, the error runs in the direction a
  * customer notices at the till.
  *
  * Unscoped behaviour is unchanged: no `locationId` means base prices and every
  * variation, which is correct for a single-location account.
  *
- * An item sold nowhere at `locationId` yields no variants and a price of 0 —
- * filter with {@link squareItemSoldAt} before calling rather than storing that.
+ * An item sold nowhere at `locationId` yields no variants and a price of 0—filter
+ * with {@link squareItemSoldAt} before calling rather than storing that.
  */
 export declare function squareToCatalogItem(item: SquareItemLike, options?: SquareAdapterOptions): CatalogItem;
 /**
  * Fourthwall product → `CatalogItem`. Same "lowest variant wins" rule as Square,
  * for the same reason.
  *
- * Fourthwall already prices in major units, so there's no conversion — mirroring
+ * Fourthwall already prices in major units, so there's no conversion—mirroring
  * `lowestPrice` in `louise-toolkit/commerce/fourthwall`.
  */
 export declare function fourthwallToCatalogItem(product: FourthwallProductLike): CatalogItem;

package/dist/commerce/adapters.js

@@ -4,20 +4,20 @@
 //
 // This is the file the whole module exists for. themidwestartist.com's loader
 // says it outright: coracle runs the same helper over Square, "only the
-// content/repo reads differ — issue: repo drift." Two sites, one intent, two
+// content/repo reads differ—issue: repo drift." Two sites, one intent, two
 // hand-written translations that drifted apart. The translation is mechanical,
 // so it belongs here once.
 //
 // Each provider's client already returns a normalized-for-that-provider shape
 // (`SquareCatalogItem`, `FwProduct`); these functions take that last step to the
-// shape the mirror stores. Deliberately pure — they take the provider's objects,
+// shape the mirror stores. Deliberately pure—they take the provider's objects,
 // not credentials or an `env`, so they're trivially testable and the caller
 // keeps control of how the fetch happens (cached, paged, rate-limited).
 /**
  * Is this object sold at `locationId`?
  *
  * Mirrors `presentAt` in `louise-toolkit/commerce/square`, but tolerant of the
- * fields being absent. The two lists are NOT symmetric — `presentAtLocationIds`
+ * fields being absent. The two lists are NOT symmetric—`presentAtLocationIds`
  * is a whitelist consulted when `presentAtAllLocations` is false,
  * `absentAtLocationIds` a blacklist consulted when it is true. Reading them the
  * other way round shows a merchant products they do not carry.
@@ -40,7 +40,7 @@ const toMajor = (cents) => Math.round(cents) / 100;
  * Is this item sold at `locationId` at all?
  *
  * Exported because a location-scoped sync needs to SKIP items the merchant
- * doesn't carry, and `squareToCatalogItem` can't do that for you — it returns
+ * doesn't carry, and `squareToCatalogItem` can't do that for you—it returns
  * one item, and "don't store this row" isn't a `CatalogItem`. Without the guard
  * an unstocked item mirrors as a $0 card with no variants, which looks like a
  * pricing bug rather than a catalog decision.
@@ -61,7 +61,7 @@ export function squareItemSoldAt(item, locationId) {
  *
  * `price` is the LOWEST variation price. A Square item is a family ("Bag of
  * beans" with 12oz and 2lb variations), so a single headline number has to mean
- * "from" — taking the first variation's price instead would change with Square's
+ * "from"—taking the first variation's price instead would change with Square's
  * ordering and quietly misprice the card.
  *
  * ## Scoping to one merchant
@@ -72,15 +72,15 @@ export function squareItemSoldAt(item, locationId) {
  *
  * The headline number has to be scoped for the same reason the variants are.
  * "From $8" computed over the whole catalog, on a page where the $8 size isn't
- * stocked, advertises a price this merchant will never honour — and because the
+ * stocked, advertises a price this merchant will never honour—and because the
  * dropped variation is usually the cheap one, the error runs in the direction a
  * customer notices at the till.
  *
  * Unscoped behaviour is unchanged: no `locationId` means base prices and every
  * variation, which is correct for a single-location account.
  *
- * An item sold nowhere at `locationId` yields no variants and a price of 0 —
- * filter with {@link squareItemSoldAt} before calling rather than storing that.
+ * An item sold nowhere at `locationId` yields no variants and a price of 0—filter
+ * with {@link squareItemSoldAt} before calling rather than storing that.
  */
 export function squareToCatalogItem(item, options = {}) {
     const locationId = options.locationId;
@@ -117,7 +117,7 @@ export function squareToCatalogItem(item, options = {}) {
  * Fourthwall product → `CatalogItem`. Same "lowest variant wins" rule as Square,
  * for the same reason.
  *
- * Fourthwall already prices in major units, so there's no conversion — mirroring
+ * Fourthwall already prices in major units, so there's no conversion—mirroring
  * `lowestPrice` in `louise-toolkit/commerce/fourthwall`.
  */
 export function fourthwallToCatalogItem(product) {

package/dist/commerce/checkout-scaffold.d.ts

@@ -2,7 +2,7 @@ import type { AstroidConfig } from "../config.js";
 /** Does this project take card payments in-page? Square storefront only. */
 export declare function usesCardCheckout(config: AstroidConfig): boolean;
 /**
- * `src/pages/api/checkout.ts` — the server-authoritative payment route.
+ * `src/pages/api/checkout.ts`—the server-authoritative payment route.
  *
  * Scaffold-once: a real store adds shipping, tax, an order record, a receipt
  * email. What Astroid fixes is the sequence, because every step of it is a place
@@ -12,7 +12,7 @@ export declare function usesCardCheckout(config: AstroidConfig): boolean;
  */
 export declare function generateAstroidCheckoutRoute(config: AstroidConfig): string | null;
 /**
- * `src/components/SquareCard.astro` — the card input.
+ * `src/components/SquareCard.astro`—the card input.
  *
  * Square's Web Payments SDK renders the field in an iframe from their CDN and
  * hands back a single-use token, so the raw card number never touches the Worker
@@ -29,13 +29,13 @@ export declare function generateAstroidSquareCard(config: AstroidConfig): string
  * application id is shipped to the browser by design, and the environment is a
  * choice, not a credential. Putting them in `credentials` would also fold them
  * into the dormancy gate, which is about whether the module can safely CALL
- * Square — a different question from whether the card field can render.
+ * Square—a different question from whether the card field can render.
  *
  * The two vars are gated SEPARATELY, and that split is load-bearing.
  * `SQUARE_ENVIRONMENT` selects the API HOST for every Square call, so it belongs
  * to any project that talks to Square at all; `SQUARE_APP_ID` only mounts the
- * browser card field. Gating both on card checkout — as this did until
- * `invoicing: "square"` became expressible — left a site that runs Square for
+ * browser card field. Gating both on card checkout—as this did until
+ * `invoicing: "square"` became expressible—left a site that runs Square for
  * invoicing alone with no `SQUARE_ENVIRONMENT`, and `SquareConfig.environment`
  * defaults to "sandbox". Every production invoice would have been created
  * against the sandbox: no error, no warning, just money that never arrives.

package/dist/commerce/checkout-scaffold.js

@@ -1,6 +1,6 @@
 // Copyright (c) 2026 BowenLabs. Astroid is MIT licensed.
 //
-// The checkout SEAM — the piece that made `archetype: "storefront"` a storefront
+// The checkout SEAM—the piece that made `archetype: "storefront"` a storefront
 // that couldn't take a card.
 //
 // Everything around this already existed: `verifyCheckout` re-prices server-side,
@@ -10,7 +10,7 @@
 // missing was the route in the middle, so none of it was reachable.
 //
 // SCOPE, deliberately narrow. This generates the server-authoritative PAYMENT
-// path and a card input — not a cart, not a checkout page, not shipping or tax.
+// path and a card input—not a cart, not a checkout page, not shipping or tax.
 // Where a cart lives (localStorage, D1, a portal session), what it holds, and how
 // it renders are project decisions Astroid has no business making, and a
 // half-opinionated cart is worse than none. What is NOT a project decision is the
@@ -26,7 +26,7 @@ export function usesCardCheckout(config) {
     return astroidCommerceRoles(config.commerce).storefront === "square";
 }
 /**
- * `src/pages/api/checkout.ts` — the server-authoritative payment route.
+ * `src/pages/api/checkout.ts`—the server-authoritative payment route.
  *
  * Scaffold-once: a real store adds shipping, tax, an order record, a receipt
  * email. What Astroid fixes is the sequence, because every step of it is a place
@@ -319,7 +319,7 @@ export function generateAstroidCheckoutRoute(config) {
         .join("\n");
 }
 /**
- * `src/components/SquareCard.astro` — the card input.
+ * `src/components/SquareCard.astro`—the card input.
  *
  * Square's Web Payments SDK renders the field in an iframe from their CDN and
  * hands back a single-use token, so the raw card number never touches the Worker
@@ -417,7 +417,7 @@ export function generateAstroidSquareCard(config) {
         .filter((line) => line !== null)
         .join("\n");
 }
-/** Does this project talk to Square in ANY role — storefront, invoicing, or
+/** Does this project talk to Square in ANY role—storefront, invoicing, or
  *  otherwise? Distinct from {@link usesCardCheckout}, which asks the narrower
  *  question of whether the in-page card field renders. */
 function usesSquare(config) {
@@ -430,13 +430,13 @@ function usesSquare(config) {
  * application id is shipped to the browser by design, and the environment is a
  * choice, not a credential. Putting them in `credentials` would also fold them
  * into the dormancy gate, which is about whether the module can safely CALL
- * Square — a different question from whether the card field can render.
+ * Square—a different question from whether the card field can render.
  *
  * The two vars are gated SEPARATELY, and that split is load-bearing.
  * `SQUARE_ENVIRONMENT` selects the API HOST for every Square call, so it belongs
  * to any project that talks to Square at all; `SQUARE_APP_ID` only mounts the
- * browser card field. Gating both on card checkout — as this did until
- * `invoicing: "square"` became expressible — left a site that runs Square for
+ * browser card field. Gating both on card checkout—as this did until
+ * `invoicing: "square"` became expressible—left a site that runs Square for
  * invoicing alone with no `SQUARE_ENVIRONMENT`, and `SquareConfig.environment`
  * defaults to "sandbox". Every production invoice would have been created
  * against the sandbox: no error, no warning, just money that never arrives.
@@ -459,7 +459,7 @@ export function astroidCheckoutVars(config) {
  * substitutes into `src/env.d.ts`. Empty without card checkout.
  */
 export function generateAstroidCheckoutEnv(config) {
-    // Mirrors the gating in `astroidCheckoutVars` — the app id is card-checkout
+    // Mirrors the gating in `astroidCheckoutVars`—the app id is card-checkout
     // only, the environment belongs to any project that calls Square at all.
     const lines = [];
     if (usesCardCheckout(config)) {

package/dist/commerce/checkout.d.ts

@@ -28,13 +28,13 @@ export interface VerifiedLine {
  * worth a notify-me. Collapsing them tells someone to remove an item the shop
  * will restock on Tuesday.
  *
- * A lookup can only produce `"out-of-stock"` by saying so — see
- * {@link ScopedPriceLookup} — because a bare `Map` has no way to distinguish
+ * A lookup can only produce `"out-of-stock"` by saying so—see
+ * {@link ScopedPriceLookup}—because a bare `Map` has no way to distinguish
  * them and guessing would put the wrong sentence on the screen.
  */
 export type CheckoutRefusal = "empty" | "unavailable" | "out-of-stock" | "price-changed" | "invalid";
 /**
- * One way the cart disagrees with the live catalog — the toolkit's
+ * One way the cart disagrees with the live catalog—the toolkit's
  * `CartIssue`, less the add-on case (checkout lines carry no add-ons yet).
  * Hand the list to `repairCart` from `louise-toolkit/commerce` to fix the cart
  * in one step.
@@ -52,7 +52,7 @@ export type CheckoutVerification = {
     reason: CheckoutRefusal;
     message: string;
     /**
-     * Every problem, in cart order, with what the catalog says now — empty
+     * Every problem, in cart order, with what the catalog says now—empty
      * for `"empty"` and `"invalid"`, which are about the request, not the
      * catalog.
      */
@@ -62,7 +62,7 @@ export type CheckoutVerification = {
  *  map omits is treated as no longer purchasable. */
 export type PriceLookup = (variantIds: string[]) => Promise<Map<string, number>>;
 /** Where the sale is happening. Optional, and providers without a location
- *  dimension ignore it — a single-merchant Square account or Fourthwall store
+ *  dimension ignore it—a single-merchant Square account or Fourthwall store
  *  passes nothing and behaves exactly as before. */
 export interface CheckoutScope {
     /** Provider location id (Square) or equivalent merchant key. */
@@ -86,13 +86,13 @@ export interface ScopedPrices {
  * A price lookup that knows WHERE the sale is happening.
  *
  * This is the multi-merchant checkout guard. One shared catalog sold through
- * several merchants carries a different price per location — each shop's
- * commission is absorbed in its own override — so re-pricing a cart against
+ * several merchants carries a different price per location—each shop's
+ * commission is absorbed in its own override—so re-pricing a cart against
  * base prices lets a customer pay the cheapest merchant's price at the dearest
  * merchant's storefront. That is not a rounding error; it is the same class of
  * bug as trusting the client's `unitPriceCents`, just one level further back.
  *
- * `scope` is optional so a {@link PriceLookup} is still assignable here — an
+ * `scope` is optional so a {@link PriceLookup} is still assignable here—an
  * existing single-location lookup simply ignores the extra argument, which is
  * exactly what a function of lower arity does in JavaScript.
  *
@@ -131,7 +131,7 @@ export declare function verifyCheckout(lines: unknown, lookup: ScopedPriceLookup
 /**
  * A deterministic idempotency key for one buyer's checkout attempt.
  *
- * Providers dedupe on this, so the same key must mean the same charge — which
+ * Providers dedupe on this, so the same key must mean the same charge—which
  * cuts both ways, and the second direction is the one that costs money. It is
  * derived from the verified cart *and* `identity`, not from a random value or a
  * timestamp: a customer double-clicking Pay sends the same key twice and is
@@ -141,18 +141,18 @@ export declare function verifyCheckout(lines: unknown, lookup: ScopedPriceLookup
  * **`identity` is required, and it is what makes the key safe.** Without it the
  * key was a pure function of the cart contents, so two DIFFERENT customers
  * buying the same thing for the same price produced byte-identical keys. Stripe
- * and Square scope idempotency keys per account and retain them for ~24h, so the
+ * and Square scope idempotency keys per account and retain them for about 24 hours, so the
  * provider replayed the first customer's PaymentIntent instead of creating the
  * second's: the second buyer was never charged, no second order existed, and the
  * site reported success. On a single-SKU storefront that is ordinary traffic,
  * not an edge case.
  *
  * Pass something stable across a retry of THIS attempt and distinct between
- * buyers — a cart id, a checkout-session id, or a portal user id. Do not pass a
+ * buyers—a cart id, a checkout-session id, or a portal user id. Do not pass a
  * value that varies per request (a fresh uuid defeats the dedupe and a
  * double-click charges twice), and do not pass a constant.
  *
- * `scope` remains the OPERATION — `"order"` vs `"refund"` — so the two can never
+ * `scope` remains the OPERATION—`"order"` vs `"refund"`—so the two can never
  * collide for one buyer. It is not an identity and never was.
  */
 export declare function checkoutIdempotencyKey(verified: {

package/dist/commerce/checkout.js

@@ -3,7 +3,7 @@
 // Server-authoritative checkout.
 //
 // A cart arrives from the browser, so every number in it is a claim, not a fact.
-// The rule this encodes — taken from coracle.coffee's working checkout — is that
+// The rule this encodes—taken from coracle.coffee's working checkout—is that
 // the client's price is a **staleness check**, never an input to the charge:
 // look the price up server-side, and if it disagrees with what the customer was
 // shown, refuse rather than silently charging a different amount. Refusing is
@@ -16,7 +16,7 @@
 // The comparison itself is the toolkit's `cartIssues`, which reports EVERY
 // stale line rather than the first: a refusal that names one problem at a time
 // is how a customer ends up fixing a line, retrying, and being refused over the
-// next. What this adds is the opinion — policing the untrusted body, and the
+// next. What this adds is the opinion—policing the untrusted body, and the
 // sentence a customer sees.
 import { cartIssues } from "louise-toolkit/commerce";
 import { AstroidUsageError } from "../errors.js";
@@ -91,7 +91,7 @@ lookup, options = {}) {
     }
     const { prices, outOfStock } = normalizeLookup(await lookup([...new Set(parsed.map((l) => l.variantId))], options.scope));
     // No `liveModifierIds`, so the add-on check is skipped and every issue is a
-    // variant one — which is what makes the narrowing to CheckoutIssue true.
+    // variant one—which is what makes the narrowing to CheckoutIssue true.
     const issues = cartIssues(parsed, { prices, outOfStock });
     const [first] = issues;
     if (first)
@@ -109,7 +109,7 @@ lookup, options = {}) {
 /**
  * A deterministic idempotency key for one buyer's checkout attempt.
  *
- * Providers dedupe on this, so the same key must mean the same charge — which
+ * Providers dedupe on this, so the same key must mean the same charge—which
  * cuts both ways, and the second direction is the one that costs money. It is
  * derived from the verified cart *and* `identity`, not from a random value or a
  * timestamp: a customer double-clicking Pay sends the same key twice and is
@@ -119,18 +119,18 @@ lookup, options = {}) {
  * **`identity` is required, and it is what makes the key safe.** Without it the
  * key was a pure function of the cart contents, so two DIFFERENT customers
  * buying the same thing for the same price produced byte-identical keys. Stripe
- * and Square scope idempotency keys per account and retain them for ~24h, so the
+ * and Square scope idempotency keys per account and retain them for about 24 hours, so the
  * provider replayed the first customer's PaymentIntent instead of creating the
  * second's: the second buyer was never charged, no second order existed, and the
  * site reported success. On a single-SKU storefront that is ordinary traffic,
  * not an edge case.
  *
  * Pass something stable across a retry of THIS attempt and distinct between
- * buyers — a cart id, a checkout-session id, or a portal user id. Do not pass a
+ * buyers—a cart id, a checkout-session id, or a portal user id. Do not pass a
  * value that varies per request (a fresh uuid defeats the dedupe and a
  * double-click charges twice), and do not pass a constant.
  *
- * `scope` remains the OPERATION — `"order"` vs `"refund"` — so the two can never
+ * `scope` remains the OPERATION—`"order"` vs `"refund"`—so the two can never
  * collide for one buyer. It is not an identity and never was.
  */
 export async function checkoutIdempotencyKey(verified, scope, identity) {

package/dist/commerce/loader.d.ts

@@ -1,7 +1,7 @@
 import type { CatalogItem } from "./sync.js";
 /** A product as the site renders it: the mirror row, decoded. */
 export interface CatalogProduct extends CatalogItem {
-    /** Public URL segment — owner-owned, stable across provider renames. */
+    /** Public URL segment—owner-owned, stable across provider renames. */
     slug: string;
     status: "draft" | "published";
     sortOrder: number;
@@ -55,7 +55,7 @@ export declare function readCatalogItem(slug: string, options: CatalogReadOption
  * );
  * ```
  *
- * Identical for every provider — which is the whole point.
+ * Identical for every provider—which is the whole point.
  */
 export declare function astroidCatalogLoaderConfig(options: CatalogReadOptions & {
     name?: string;

package/dist/commerce/loader.js

@@ -3,8 +3,8 @@
 // The catalog read, and the Live Content Collection loader over it.
 //
 // `defineCatalogLoader` (@louise-toolkit/astro) already owns the Astro-facing
-// plumbing. What each site then hand-wrote was the layer underneath — "read my
-// catalog out of D1" — and because that layer was per-site, so was the drift.
+// plumbing. What each site then hand-wrote was the layer underneath—"read my
+// catalog out of D1"—and because that layer was per-site, so was the drift.
 // It doesn't need to be: once the mirror table's shape is fixed (see mirror.ts),
 // reading it is the same query whatever provider filled it in.
 //
@@ -73,7 +73,7 @@ export async function readCatalogItem(slug, options) {
  * );
  * ```
  *
- * Identical for every provider — which is the whole point.
+ * Identical for every provider—which is the whole point.
  */
 export function astroidCatalogLoaderConfig(options) {
     return {

package/dist/commerce/mirror.d.ts

@@ -25,8 +25,8 @@ export interface CatalogMirrorConfig {
 }
 /**
  * Columns Astroid always PULLS, overwriting each sync. Fixed rather than
- * configurable because they're the intersection of what every provider returns —
- * a project that wants a provider-specific field puts it in `owned` and fills it
+ * configurable because they're the intersection of what every provider returns—a
+ * project that wants a provider-specific field puts it in `owned` and fills it
  * itself, which also stops the sync from clobbering it.
  */
 export declare const PULLED_COLUMNS: readonly ["name", "price", "images", "variants", "externalSlug", "syncedAt"];
@@ -44,7 +44,7 @@ export declare function astroidCatalogMirror(config: AstroidConfig): Required<Pi
 /**
  * Drizzle source for the catalog table.
  *
- * `externalId` is unique — it's the sync's idempotency key, so a webhook and the
+ * `externalId` is unique—it's the sync's idempotency key, so a webhook and the
  * cron re-sync racing on the same product can only ever collide into one row.
  */
 export declare function generateCatalogTable(config: AstroidConfig): string | null;
@@ -57,7 +57,7 @@ export declare function generateCatalogTable(config: AstroidConfig): string | nu
  *
  * It has to exist at all because nothing else creates this table. `--commerce`
  * put `products` in `src/schema.ts` and the queue seam told you to sync into it,
- * but no migration anywhere in the toolkit created it — so the first catalog
+ * but no migration anywhere in the toolkit created it—so the first catalog
  * sync hit a missing table, and (because `astroidCatalogSync` swallows per-item
  * errors) reported success while writing nothing. The documented fallback,
  * `drizzle-kit generate`, could not help: the template ships a hand-authored

package/dist/commerce/mirror.js

@@ -3,7 +3,7 @@
 // The catalog mirror: an external provider is the source of truth, D1 is the
 // editable overlay on top of it.
 //
-// Every consuming site landed on the same split — a set of fields PULLED from
+// Every consuming site landed on the same split—a set of fields PULLED from
 // the provider and overwritten on every sync, and a disjoint set the owner edits
 // which must survive every sync. Get that boundary wrong in either direction and
 // you either clobber the owner's copy on the next cron tick, or serve a price
@@ -12,13 +12,13 @@
 // What the sites did NOT agree on is how much to store, and it turns out to be
 // one primitive with two settings rather than two designs:
 //
-//   mirror   — pulled + owned columns both live in D1 (themidwestartist.com).
+//   mirror: pulled + owned columns both live in D1 (themidwestartist.com).
 //              Reads are one local query. The catalog can be stale between syncs.
-//   overlay  — only the owned columns live in D1, keyed by the provider's id.
+//   overlay: only the owned columns live in D1, keyed by the provider's id.
 //              The catalog is read live from the provider and joined at read
 //              time: never stale, but every read costs a provider round-trip
 //              (cache accordingly).
-//   live     — Astroid manages NO catalog table at all: the catalog is read live
+//   live: Astroid manages NO catalog table at all: the catalog is read live
 //              from the provider (cached), and any owner-side overlay table is
 //              the SITE's own (coracle.coffee's `product_display_meta`, declared
 //              in schema.site.ts and joined in the site's loader). Use when the
@@ -28,8 +28,8 @@
 // nor migration. One generator serves all three and a project switches by one word.
 /**
  * Columns Astroid always PULLS, overwriting each sync. Fixed rather than
- * configurable because they're the intersection of what every provider returns —
- * a project that wants a provider-specific field puts it in `owned` and fills it
+ * configurable because they're the intersection of what every provider returns—a
+ * project that wants a provider-specific field puts it in `owned` and fills it
  * itself, which also stops the sync from clobbering it.
  */
 export const PULLED_COLUMNS = [
@@ -66,7 +66,7 @@ export function astroidCatalogMirror(config) {
     return {
         mode: mirror.mode ?? "mirror",
         table: mirror.table ?? "products",
-        // Built-ins first so a project can override one (e.g. widen `status`)
+        // Built-ins first so a project can override one (for example, widen `status`)
         // without restating the rest.
         owned: { ...BUILT_IN_OWNED, ...mirror.owned },
     };
@@ -99,7 +99,7 @@ function ownedColumnSource(key, col) {
 /**
  * Drizzle source for the catalog table.
  *
- * `externalId` is unique — it's the sync's idempotency key, so a webhook and the
+ * `externalId` is unique—it's the sync's idempotency key, so a webhook and the
  * cron re-sync racing on the same product can only ever collide into one row.
  */
 export function generateCatalogTable(config) {
@@ -172,7 +172,7 @@ function ownedColumnSql(key, col) {
  *
  * It has to exist at all because nothing else creates this table. `--commerce`
  * put `products` in `src/schema.ts` and the queue seam told you to sync into it,
- * but no migration anywhere in the toolkit created it — so the first catalog
+ * but no migration anywhere in the toolkit created it—so the first catalog
  * sync hit a missing table, and (because `astroidCatalogSync` swallows per-item
  * errors) reported success while writing nothing. The documented fallback,
  * `drizzle-kit generate`, could not help: the template ships a hand-authored

package/dist/commerce/roles.d.ts

@@ -3,14 +3,14 @@ import type { CommerceConfig, CommerceProvider } from "../config.js";
 export type CommerceRole = "storefront" | "invoicing" | "pos";
 /**
  * Which roles each provider can serve, derived from the surface its
- * `louise-toolkit/commerce/*` client actually exposes — not from what the
+ * `louise-toolkit/commerce/*` client actually exposes—not from what the
  * vendor's full API could theoretically do.
  *
  *   square      catalog + orders + payments, `createInvoice`/`publishInvoice`,
  *               AND locations + per-location price overrides + inventory counts
  *   stripe      invoices + payment intents; NO catalog
- *   fourthwall  catalog + cart; NO invoicing, and NO locations or inventory —
- *               its Platform API is create-only for products, so it cannot
+ *   fourthwall  catalog + cart; NO invoicing, and NO locations or inventory—*
+               its Platform API is create-only for products, so it cannot
  *               model stock held at a place
  *
  * Square alone can serve `pos`, and that is a fact about the clients rather than
@@ -27,8 +27,8 @@ export interface ResolvedCommerceRoles {
 /**
  * Resolve a `commerce` block into role assignments.
  *
- * The `provider` shorthand assigns to the provider's *natural* role — the one it
- * can serve — so `{ provider: "square" }` is a storefront and
+ * The `provider` shorthand assigns to the provider's *natural* role—the one it
+ * can serve—so `{ provider: "square" }` is a storefront and
  * `{ provider: "stripe" }` is invoicing. Guessing "storefront" for both would
  * produce a storefront with no catalog API behind it.
  */
@@ -36,17 +36,17 @@ export declare function astroidCommerceRoles(commerce: CommerceConfig | undefine
 /** Every distinct provider this project talks to, in a stable order. */
 export declare function astroidCommerceProviders(commerce: CommerceConfig | undefined): CommerceProvider[];
 /**
- * True when this project sells in person — the switch for locations,
+ * True when this project sells in person—the switch for locations,
  * per-location pricing and inventory.
  */
 export declare const hasPos: (commerce: CommerceConfig | undefined) => boolean;
 /**
- * True when Square is used with more than one Location, i.e. the location id
+ * True when Square is used with more than one Location, that is, the location id
  * comes from the request rather than the environment.
  *
  * Deliberately independent of which ROLE Square fills: a project could run
- * multi-location invoicing without a `pos` storefront, and the consequence —
- * no ambient `SQUARE_LOCATION_ID` — is the same either way.
+ * multi-location invoicing without a `pos` storefront, and the consequence—no
+ * ambient `SQUARE_LOCATION_ID`—is the same either way.
  */
 export declare const hasMultiLocation: (commerce: CommerceConfig | undefined) => boolean;
 /** True when this project sells anything at all. */
@@ -54,7 +54,7 @@ export declare const hasStorefront: (commerce: CommerceConfig | undefined) => bo
 /**
  * Reject a role assignment the provider's client cannot serve. Called from
  * `defineAstroid`, so `invoicing: "fourthwall"` fails at config load with a
- * message naming the alternatives — rather than at runtime, on the first
+ * message naming the alternatives—rather than at runtime, on the first
  * invoice, as a missing function.
  */
 export declare function assertCommerceRoles(commerce: CommerceConfig | undefined): void;