astroidjs 0.12.1 → 0.14.0

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 = [
@@ -54,7 +54,7 @@ export const BUILT_IN_OWNED = {
         type: "text",
         values: ["draft", "published"],
         default: "draft",
-        note: "New remote items land as draft — nothing goes live until someone says so.",
+        note: "New remote items land as draft—nothing goes live until someone says so.",
     },
     sortOrder: { type: "real", default: 0 },
     featured: { type: "boolean", default: false },
@@ -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) {
@@ -114,11 +114,11 @@ export function generateCatalogTable(config) {
     p(`// The catalog ${mode}. The provider is the source of truth; these rows are`);
     p(mode === "mirror"
         ? "// a local copy plus the owner's edits. Pulled columns are overwritten every"
-        : "// the owner's edits only — catalog fields are read live from the provider.");
+        : "// the owner's edits only—catalog fields are read live from the provider.");
     p("// sync; owned columns are preserved. See astroidCatalogUpsert.");
     p(`export const ${camel(table)} = sqliteTable(${JSON.stringify(table)}, {`);
     p('  id: integer("id").primaryKey({ autoIncrement: true }),');
-    p("  // The provider's id for this item — the sync's idempotency key.");
+    p("  // The provider's id for this item—the sync's idempotency key.");
     p('  externalId: text("external_id").notNull().unique(),');
     if (mode === "mirror") {
         p("  // --- PULLED: overwritten on every sync, never hand-edit ---");
@@ -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;

package/dist/commerce/roles.js

@@ -4,28 +4,28 @@
 //
 // The obvious model is one commerce provider per site. It's wrong, and the
 // toolkit's own clients prove it: `louise-toolkit/commerce/stripe` has no
-// catalog API whatsoever — it exposes invoices, customers, and payment intents.
+// catalog API whatsoever—it exposes invoices, customers, and payment intents.
 // `fourthwall` is the mirror image: a catalog and a cart, no invoicing. Square
 // happens to do both. A single `CommerceProvider` abstraction that assumed
 // catalog + checkout would therefore have a permanent hole wherever Stripe sits.
 //
 // That's not hypothetical. themidwestartist.com runs Stripe for **invoicing**
-// (commissions, originals) alongside Fourthwall for the **storefront** (merch) —
-// two providers, one site, each doing the half it can do.
+// (commissions, originals) alongside Fourthwall for the **storefront**
+// (merch)—two providers, one site, each doing the half it can do.
 //
 // So a project assigns providers to roles, and Astroid validates the assignment
 // against what each provider's client can actually serve.
 import { AstroidConfigError } from "../errors.js";
 /**
  * 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
@@ -40,8 +40,8 @@ export const PROVIDER_ROLES = {
 /**
  * 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.
  */
@@ -69,17 +69,17 @@ export function astroidCommerceProviders(commerce) {
     return [...new Set([storefront, invoicing, pos].filter((p) => !!p))];
 }
 /**
- * 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 const hasPos = (commerce) => Boolean(astroidCommerceRoles(commerce).pos);
 /**
- * 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 const hasMultiLocation = (commerce) => commerce?.square?.locations === "multi";
 /** True when this project sells anything at all. */
@@ -87,7 +87,7 @@ export const hasStorefront = (commerce) => Boolean(astroidCommerceRoles(commerce
 /**
  * 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 function assertCommerceRoles(commerce) {

package/dist/commerce/secrets.d.ts

@@ -6,7 +6,7 @@ import { type CommerceRole } from "./roles.js";
  *
  * `credentials` is what the provider's `louise-toolkit/commerce/*` client needs
  * to make a call at all; `webhook` is the signing secret its receiver verifies
- * with. They're separable on purpose — a site can receive verified webhooks
+ * with. They're separable on purpose—a site can receive verified webhooks
  * before it has finished provisioning API access, and the reverse is the normal
  * state of a brand-new integration.
  *
@@ -32,7 +32,7 @@ export declare const COMMERCE_PROVIDER_SETUP: Record<CommerceProvider, string>;
  * Only Square varies, and only on one name. `SQUARE_LOCATION_ID` is required
  * for a single-location project because Square's orders and payments endpoints
  * refuse a request without one. Under `square.locations: "multi"` the location
- * is a property of the *request* — which merchant's storefront is this? — so an
+ * is a property of the *request*—which merchant's storefront is this?—so an
  * ambient id is not just unnecessary, it is dangerous: any code path that
  * defaulted to it would ring one merchant's sale against another merchant's
  * books, and the sale would look perfectly successful while doing it.
@@ -53,11 +53,11 @@ export declare function commerceSecretNames(commerce: CommerceConfig | undefined
 /** One provider's resolved gate. */
 export interface ProviderStatus {
     provider: CommerceProvider;
-    /** Which role(s) this provider fills for the project. */
+    /** Which roles this provider fills for the project. */
     roles: CommerceRole[];
-    /** API credentials — false means no live call can be made. */
+    /** API credentials—false means no live call can be made. */
     credentials: ModuleSecrets<string>;
-    /** Webhook signing secret — false means the receiver answers 503. */
+    /** Webhook signing secret—false means the receiver answers 503. */
     webhook: ModuleSecrets<string>;
     /** True only when both halves resolved. */
     configured: boolean;
@@ -66,7 +66,7 @@ export interface ProviderStatus {
 export interface CommerceStatus {
     /** True when the project has commerce configured AND every provider is live. */
     configured: boolean;
-    /** True when the project declares no commerce at all — not the same as dormant. */
+    /** True when the project declares no commerce at all—not the same as dormant. */
     enabled: boolean;
     providers: ProviderStatus[];
     /** Every unprovisioned secret name across all providers, in declaration order. */
@@ -93,8 +93,8 @@ export declare function resolveCommerceStatus(commerce: CommerceConfig | undefin
  *
  * `CommerceStatus.configured` is an all-or-nothing aggregate (`every`), which is
  * the right answer for "is the whole module ready" and the wrong one for gating
- * a single call site. A two-provider project — Fourthwall for the storefront,
- * Square for invoicing — reads `configured: false` the moment either half is
+ * a single call site. A two-provider project—Fourthwall for the storefront,
+ * Square for invoicing—reads `configured: false` the moment either half is
  * unprovisioned, so gating the working Fourthwall checkout on the aggregate
  * would silently simulate it because SQUARE's secrets are still placeholders.
  *
@@ -103,7 +103,7 @@ export declare function resolveCommerceStatus(commerce: CommerceConfig | undefin
 export declare function providerConfigured(status: CommerceStatus, provider: CommerceProvider): boolean;
 /**
  * Is the provider filling this ROLE live? The role-shaped question, for code
- * that cares about the capability rather than the vendor — "can I take a
+ * that cares about the capability rather than the vendor—"can I take a
  * checkout?" rather than "is Square up?".
  */
 export declare function roleConfigured(status: CommerceStatus, role: CommerceRole): boolean;

package/dist/commerce/secrets.js

@@ -3,7 +3,7 @@
 // What each commerce provider needs before it can do anything, and the gate
 // derived from it.
 //
-// The rest of this module is deliberately credential-free — the adapters are
+// The rest of this module is deliberately credential-free—the adapters are
 // pure, the mirror and the loader only touch D1, and `verifyCheckout` takes a
 // price lookup rather than a token. That's the right shape: it keeps the parts
 // testable and lets the caller own how the fetch happens.
@@ -13,7 +13,7 @@
 // the commerce half of the dormant-until-provisioned convention (#252): the
 // names below are the single source of truth for what a provider requires, so
 // the wrangler generator can seed them, `astroid doctor` can report them, and a
-// storefront can decide between a live catalog and a simulated one — all from
+// storefront can decide between a live catalog and a simulated one—all from
 // one declaration instead of three hand-maintained lists.
 //
 // The webhook secret lives here too, rather than beside the verifier in
@@ -26,7 +26,7 @@ import { astroidCommerceProviders, astroidCommerceRoles, hasMultiLocation, } fro
  *
  * `credentials` is what the provider's `louise-toolkit/commerce/*` client needs
  * to make a call at all; `webhook` is the signing secret its receiver verifies
- * with. They're separable on purpose — a site can receive verified webhooks
+ * with. They're separable on purpose—a site can receive verified webhooks
  * before it has finished provisioning API access, and the reverse is the normal
  * state of a brand-new integration.
  *
@@ -39,7 +39,7 @@ export const COMMERCE_PROVIDER_SECRETS = {
     // leaves checkout broken rather than dormant. Requiring both is what makes
     // "configured" mean "can actually take money".
     //
-    // UNLESS the project is multi-location — see `commerceProviderCredentials`.
+    // UNLESS the project is multi-location—see `commerceProviderCredentials`.
     square: {
         credentials: ["SQUARE_ACCESS_TOKEN", "SQUARE_LOCATION_ID"],
         webhook: "SQUARE_WEBHOOK_SECRET",
@@ -50,7 +50,7 @@ export const COMMERCE_PROVIDER_SECRETS = {
     },
     // Fourthwall's storefront token is public-safe (it's sent as a query param
     // from the browser in their own SDK), but it is still provisioned, so it
-    // follows the same gate — an absent token means no catalog.
+    // follows the same gate—an absent token means no catalog.
     fourthwall: {
         credentials: ["FOURTHWALL_STOREFRONT_TOKEN"],
         webhook: "FOURTHWALL_WEBHOOK_SECRET",
@@ -75,7 +75,7 @@ export const COMMERCE_PROVIDER_SETUP = {
  * Only Square varies, and only on one name. `SQUARE_LOCATION_ID` is required
  * for a single-location project because Square's orders and payments endpoints
  * refuse a request without one. Under `square.locations: "multi"` the location
- * is a property of the *request* — which merchant's storefront is this? — so an
+ * is a property of the *request*—which merchant's storefront is this?—so an
  * ambient id is not just unnecessary, it is dangerous: any code path that
  * defaulted to it would ring one merchant's sale against another merchant's
  * books, and the sale would look perfectly successful while doing it.
@@ -157,8 +157,8 @@ export async function resolveCommerceStatus(commerce, env) {
  *
  * `CommerceStatus.configured` is an all-or-nothing aggregate (`every`), which is
  * the right answer for "is the whole module ready" and the wrong one for gating
- * a single call site. A two-provider project — Fourthwall for the storefront,
- * Square for invoicing — reads `configured: false` the moment either half is
+ * a single call site. A two-provider project—Fourthwall for the storefront,
+ * Square for invoicing—reads `configured: false` the moment either half is
  * unprovisioned, so gating the working Fourthwall checkout on the aggregate
  * would silently simulate it because SQUARE's secrets are still placeholders.
  *
@@ -169,7 +169,7 @@ export function providerConfigured(status, provider) {
 }
 /**
  * Is the provider filling this ROLE live? The role-shaped question, for code
- * that cares about the capability rather than the vendor — "can I take a
+ * that cares about the capability rather than the vendor—"can I take a
  * checkout?" rather than "is Square up?".
  */
 export function roleConfigured(status, role) {

package/dist/commerce/sync.d.ts

@@ -7,7 +7,7 @@ export interface CatalogItem {
     price: number;
     images?: string[];
     variants?: unknown;
-    /** The provider's own slug, when it has one — for re-fetching a single item. */
+    /** The provider's own slug, when it has one—for re-fetching a single item. */
     externalSlug?: string;
 }
 /** The D1 surface the sync needs. Structural, so a real `D1Database` fits. */
@@ -21,7 +21,7 @@ export interface SyncDatabase {
 }
 export interface CatalogSyncOptions {
     db: SyncDatabase;
-    /** Mirror table name — must match the generated schema. */
+    /** Mirror table name—must match the generated schema. */
     table: string;
     /**
      * `overlay` mode writes only the key and `synced_at`: the catalog fields live
@@ -32,7 +32,7 @@ export interface CatalogSyncOptions {
     slugify?: (item: CatalogItem) => string;
 }
 export interface CatalogSyncResult {
-    /** Rows created — new products, landing as `draft`. */
+    /** Rows created—new products, landing as `draft`. */
     created: number;
     /** Rows whose pulled fields were refreshed. */
     updated: number;
@@ -41,7 +41,7 @@ export interface CatalogSyncResult {
     /**
      * One error per failed item, in order, for logging.
      *
-     * Capped — a catalog-wide failure would otherwise build an array as long as
+     * Capped—a catalog-wide failure would otherwise build an array as long as
      * the catalog just to describe the same fault N times.
      */
     errors: {
@@ -54,7 +54,7 @@ export declare function defaultSlug(value: string): string;
 /**
  * Upsert one item. Returns whether it created a row.
  *
- * The UPDATE branch lists pulled columns ONLY — see the note at the top of this
+ * The UPDATE branch lists pulled columns ONLY—see the note at the top of this
  * file. In `overlay` mode there are no pulled columns, so an existing row is
  * touched only to stamp `synced_at`.
  */
@@ -67,7 +67,7 @@ export declare function astroidCatalogUpsert(item: CatalogItem, options: Catalog
  * Items are written one at a time and a single failure doesn't abandon the rest:
  * a partial catalog is strictly better than a stale one, and the next cron tick
  * retries whatever didn't land. Rows whose product has vanished upstream are
- * left alone — deciding whether a missing item is delisted or just a failed page
+ * left alone—deciding whether a missing item is delisted or just a failed page
  * of an API response is the project's call, not the sync's, and unpublishing
  * someone's whole catalog on a bad response is unrecoverable.
  *
@@ -79,7 +79,7 @@ export declare function astroidCatalogUpsert(item: CatalogItem, options: Catalog
  * with nothing in `wrangler tail`. Throwing when nothing at all landed is what
  * makes the queue's retry and DLQ do their job.
  *
- * Partial failures do NOT throw — they come back in `failed`/`errors` for the
+ * Partial failures do NOT throw—they come back in `failed`/`errors` for the
  * caller to log, because retrying the whole batch to re-attempt a few rows would
  * undo the tolerance this loop exists to provide.
  */

package/dist/commerce/sync.js

@@ -10,7 +10,7 @@
 // the provider's own id (unique in the table) means a re-run is a no-op update
 // rather than a duplicate row.
 //
-// **The owned set is never in an UPDATE.** Not "usually not" — never. A sync
+// **The owned set is never in an UPDATE.** Not "usually not"—never. A sync
 // that writes an owned column is a sync that silently reverts the owner's work,
 // and they find out days later when someone notices the description is back to
 // the vendor's default. So the update statement is built from the pulled set
@@ -51,7 +51,7 @@ async function allocateSlug(db, table, base, externalId) {
 /**
  * Upsert one item. Returns whether it created a row.
  *
- * The UPDATE branch lists pulled columns ONLY — see the note at the top of this
+ * The UPDATE branch lists pulled columns ONLY—see the note at the top of this
  * file. In `overlay` mode there are no pulled columns, so an existing row is
  * touched only to stamp `synced_at`.
  */
@@ -106,7 +106,7 @@ const MAX_RECORDED_ERRORS = 10;
  * Items are written one at a time and a single failure doesn't abandon the rest:
  * a partial catalog is strictly better than a stale one, and the next cron tick
  * retries whatever didn't land. Rows whose product has vanished upstream are
- * left alone — deciding whether a missing item is delisted or just a failed page
+ * left alone—deciding whether a missing item is delisted or just a failed page
  * of an API response is the project's call, not the sync's, and unpublishing
  * someone's whole catalog on a bad response is unrecoverable.
  *
@@ -118,7 +118,7 @@ const MAX_RECORDED_ERRORS = 10;
  * with nothing in `wrangler tail`. Throwing when nothing at all landed is what
  * makes the queue's retry and DLQ do their job.
  *
- * Partial failures do NOT throw — they come back in `failed`/`errors` for the
+ * Partial failures do NOT throw—they come back in `failed`/`errors` for the
  * caller to log, because retrying the whole batch to re-attempt a few rows would
  * undo the tolerance this loop exists to provide.
  */
@@ -133,7 +133,7 @@ export async function astroidCatalogSync(items, options) {
                 result.updated++;
         }
         catch (cause) {
-            // Skip this item; the next run retries it — but record it, so "nothing
+            // Skip this item; the next run retries it—but record it, so "nothing
             // synced" can be told apart from "nothing to sync".
             result.failed++;
             if (result.errors.length < MAX_RECORDED_ERRORS) {

package/dist/components/sections.d.ts

@@ -31,7 +31,7 @@ export declare function alignClass(align?: string | undefined): string;
  *
  * These are closed token sets, declared as `select` (#272) so the inspector
  * renders a picker and an unknown token is rejected on write. They used to be
- * `text` with the valid values stuffed into `placeholder` — which meant a typo
+ * `text` with the valid values stuffed into `placeholder`—which meant a typo
  * wasn't a validation error at all, just a silent fallback to the default
  * inside `colorwayClass` at render time.
  */
@@ -40,8 +40,8 @@ export declare const SECTION_SETTINGS: Record<string, SectionField>;
  * What every section render component receives.
  *
  * `base` is the whole point. It is this item's path within the page's `sections`
- * array — `"2"` for a top-level section, `"2.blocks.0"` for a block inside it —
- * and every marker the component stamps is built from it. Passing it down (rather
+ * array—`"2"` for a top-level section, `"2.blocks.0"` for a block inside it—and
+ * every marker the component stamps is built from it. Passing it down (rather
  * than having each component work out its own depth) is what lets the exact same
  * component render as a section or as a block, and what keeps `data-louise-node`
  * paths correct at any nesting depth.
@@ -53,8 +53,8 @@ export interface SectionRenderProps {
     base: string;
     /** Whether to stamp edit markers. Defaults to `Astro.locals.editMode`. */
     edit?: boolean;
-    /** Alt/caption resolved from the media registry, keyed by public URL —
-     *  looked up once for the whole page by `<Sections>`. */
+    /** Alt/caption resolved from the media registry, keyed by public URL—*
+      looked up once for the whole page by `<Sections>`. */
     mediaMeta?: MediaMeta;
 }
 /** Asset-level `alt`/`caption` from the media registry, keyed by public URL. */
@@ -78,7 +78,7 @@ export declare function itemField(row: Record<string, unknown>, key: string): st
  *
  * The precedence is the whole reason `<Sections>` does its media lookup: a
  * per-usage `alt` on the section wins, because the same photo means something
- * different in a hero than in a thumbnail strip — but when there isn't one, the
+ * different in a hero than in a thumbnail strip—but when there isn't one, the
  * alt an editor typed once in the media library is used. That's what makes
  * fixing alt text a single edit that propagates everywhere the asset appears,
  * instead of a hunt through every page that embeds it.
@@ -89,7 +89,7 @@ export declare function itemField(row: Record<string, unknown>, key: string): st
  */
 export declare function mediaAlt(mediaMeta: MediaMeta | undefined, src: string | undefined, override?: string): string;
 /** Caption for an image, same precedence as {@link mediaAlt}. Undefined when
- *  there is none — a missing caption renders nothing, unlike a missing alt. */
+ *  there is none—a missing caption renders nothing, unlike a missing alt. */
 export declare function mediaCaption(mediaMeta: MediaMeta | undefined, src: string | undefined, override?: string): string | undefined;
 /**
  * Every section type Astroid ships.
@@ -97,7 +97,7 @@ export declare function mediaCaption(mediaMeta: MediaMeta | undefined, src: stri
  * `satisfies` rather than a `: SectionCatalog` annotation, and it matters:
  * `SectionCatalog` is `Record<string, SectionDef>`, so annotating would widen
  * `keyof typeof` to `string` and throw away the literal keys. Those keys are
- * the project's whole section vocabulary — `SectionKind` is derived from them
+ * the project's whole section vocabulary—`SectionKind` is derived from them
  * (config.ts), `isRenderableSection` narrows to them, and `<Section>` indexes
  * its component map with them. Annotate this and all three silently degrade to
  * "any string", which is how the dispatcher lost its type safety once already.
@@ -564,7 +564,7 @@ export declare const astroidSectionCatalog: {
         settings: Record<string, SectionField>;
     };
 };
-/** The `_type`s with a shipped render component — derived from the catalog, so
+/** The `_type`s with a shipped render component—derived from the catalog, so
  *  it can't drift from what `<Section>` actually dispatches. A literal union,
  *  not `string`, because the catalog is declared with `satisfies`. */
 export type RenderableSectionType = keyof typeof astroidSectionCatalog;