astroidjs 0.12.1 → 0.13.0

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;

package/dist/components/sections.js

@@ -5,8 +5,8 @@
 //
 // This file used to define a parallel universe: a `SectionProps` union
 // discriminated on `kind`, with `colorway`/`align` as component props. Louise's
-// actual model — the one the on-canvas editor and the write-time validator both
-// read — is different in every particular, and it is the one that wins:
+// actual model—the one the on-canvas editor and the write-time validator both
+// read—is different in every particular, and it is the one that wins:
 //
 //   • a section is a stored `SectionItem`: `{ _type, blocks?, _layout?,
 //     _settings?, ...fields }`. The discriminant is `_type`, not `kind`.
@@ -16,7 +16,7 @@
 //     or validated-but-uneditable.
 //   • presentation choices are `_settings` / `_layout` **tokens**. Louise stores
 //     the token; the site maps it to CSS. That's why COLORWAY_CLASS below stays
-//     — it is exactly the site-owned half of that contract — while `colorway`
+//: it is exactly the site-owned half of that contract—while `colorway`
 //     stops being a prop and becomes a stored setting.
 //
 // ADR 0005 §2 names this file's job outright: "<Section> reads `_layout` /
@@ -26,7 +26,7 @@
 //
 // Self-contained on purpose: this module ships as SOURCE (the `.astro` files
 // beside it import it directly), so it must not reach back into astroid's built
-// `src/*` — only siblings and external packages. The `louise-toolkit/content`
+// `src/*`—only siblings and external packages. The `louise-toolkit/content`
 // import is TYPE-ONLY, so it erases at build and never drags the validator (or
 // drizzle, which that entry pulls in) into a page bundle.
 /**
@@ -73,7 +73,7 @@ const tokenOptions = (map) => Object.keys(map).map((value) => ({ value, label: l
  *
  * 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.
  */
@@ -83,7 +83,7 @@ export const SECTION_SETTINGS = {
         label: "Colorway",
         inline: false,
         options: tokenOptions(COLORWAY_CLASS),
-        // An opaque hint — the schema layer doesn't know what a swatch looks like;
+        // An opaque hint—the schema layer doesn't know what a swatch looks like;
         // a renderer that doesn't support it just shows a normal picker.
         display: "swatch",
     },
@@ -124,7 +124,7 @@ export function itemField(row, key) {
  *
  * 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.
@@ -139,7 +139,7 @@ export function mediaAlt(mediaMeta, src, override) {
     return (src ? mediaMeta?.[src]?.alt : undefined) ?? "";
 }
 /** 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 function mediaCaption(mediaMeta, src, override) {
     if (override !== undefined && override !== "")
         return override;
@@ -154,7 +154,7 @@ export function mediaCaption(mediaMeta, src, override) {
  * `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.
@@ -167,7 +167,7 @@ export const astroidSectionCatalog = {
             heading: { type: "text", label: "Heading", validation: (r) => r.required().max(120) },
             subheading: { type: "textarea", label: "Subheading" },
             // A link URL is something you can't point at on the page, so it is not
-            // inline — it belongs in the inspector, which is what `inline: false` says.
+            // inline—it belongs in the inspector, which is what `inline: false` says.
             ctaLabel: { type: "text", label: "Button label" },
             ctaHref: { type: "text", label: "Button link", inline: false },
         },
@@ -312,7 +312,7 @@ export const astroidSectionCatalog = {
                     name: { type: "text", label: "Name", validation: (r) => r.required() },
                     price: { type: "text", label: "Price" },
                     period: { type: "text", label: "Period (e.g. /mo)" },
-                    // A list of strings isn't expressible — array items are objects — so
+                    // A list of strings isn't expressible—array items are objects—so
                     // each feature is a one-field row. That also leaves room to add an
                     // `included` flag later without a data migration.
                     features: {
@@ -368,7 +368,7 @@ export const astroidSectionCatalog = {
             heading: { type: "text", label: "Heading" },
             // Deliberately hand-authored rows rather than a live catalog read. A
             // section is stored content, and the commerce mirror is a separate
-            // concern with its own loader — a site that wants the live catalog renders
+            // concern with its own loader—a site that wants the live catalog renders
             // `readCatalog` in its own page, not through the page-builder.
             items: {
                 type: "array",