@getvitops/astro 8.1.0 → 8.2.0

package/CHANGELOG.md

@@ -1,5 +1,799 @@
 # @getvitops/astro
 
+## 8.2.0
+
+### Minor Changes
+
+- 65a13cc: **New: `site.experiments`** — runtime, per-visitor A/B content experiments for a page that
+  must stay at one URL (unlike `site.abTesting`'s existing build-time variant merge, which is
+  for a full design-system/CSS-level test via two manual deploys — `site.experiments` is the
+  opposite granularity: one page, one cookie, content branched in the page itself). Keyed by
+  an open experiment name, so more than one can run at once, each with its own consent
+  category, cookie name/lifetime, split ratio and pair of variant names.
+
+  **New `vitopsAbTesting()` middleware** (`@getvitops/astro/middleware`) — the first Astro
+  middleware this toolchain ships. Wire it into your own `src/middleware.ts`:
+
+  ```ts
+  import { vitopsAbTesting } from '@getvitops/astro/middleware';
+  import config from '../site.json' with { type: 'json' };
+
+  export const onRequest = vitopsAbTesting({
+    experiments: config.site.experiments ?? {},
+  });
+  ```
+
+  It assigns and cookie-pins a visitor to one of an experiment's two variants on first visit,
+  by weighted random (`splitRatio`) — and never touches an already-set cookie, so a recognized
+  query parameter named after the cookie itself (`?_ab_<key>=<variant>`) reliably forces that
+  variant, even overriding an existing assignment. Combined with `splitRatio: 0`, this is a
+  blue/green-style "100% on control, but a shared link reveals the other variant" mode with no
+  special-cased logic.
+
+  A page reads its own experiment's cookie (`Astro.cookies.get(cookieName)?.value`) and
+  renders whichever of its two hand-written blocks matches — there's no config-schema
+  representation of "the variant content," which is what keeps this lightweight regardless of
+  how many experiments are configured.
+
+  **`<Analytics />` gained a reporting hook**: each configured provider's bootstrap now
+  attaches an enabled experiment's assignment to the real pageview via that provider's own
+  mechanism — Plausible via `plausible.init({customProperties})`, Matomo via
+  `setCustomDimension` (needs a new `site.analytics.matomo.abVariantDimensions` entry — the
+  dimension must exist in your Matomo instance first), GA4 via a runtime-merged
+  `gtag('config', …)` call. A no-op when `site.experiments` is unset — zero behavior change
+  for every existing site.
+
+  Also new: `experimentDimensionWarnings(site)` (`@getvitops/generator`) — a build-time warning
+  (not a hard error) when an enabled experiment's site also configures Matomo but has no
+  matching `abVariantDimensions` entry.
+
+  **Not included in this pass, deliberately**: a mechanism for a fully prerendered
+  (`output: 'static'`) page — this needs a genuinely separate Cloudflare Worker Route + two
+  pre-built static variants, real but bounded follow-up work. Everything above applies to an
+  on-demand-rendered page (the current EmDash templates' default), which needs zero new
+  deploy infrastructure.
+
+- 89265af: **New package: `@getvitops/config`** — the site-config provider blocks (`site.crm`, `site.ads`,
+  `site.reviews`, `site.seo.indexing`, `site.searchConsole`, `site.notifications`, `site.tracking`,
+  `site.security`, `site.deployment`) as zod schemas and inferred types, with the closed provider lists
+  (`AD_PROVIDERS`, `CRM_PROVIDERS`, `BIGIN_DATA_CENTERS`) on a zod-free `./providers` entry. It joins the
+  `fixed` group.
+
+  Why: `@getvitops/utils` holds the provider code but could not import its configuration types — the schema
+  lived in `@getvitops/generator`, a layer above — so it kept a hand-copied mirror beside each module,
+  an adapter converting into it, and a test holding the copy to the schema. The mirrors are gone.
+
+  - **`@getvitops/generator`**: `AD_PROVIDERS`, `CRM_PROVIDERS`, `BIGIN_DATA_CENTERS`, `AdProvider` and
+    `CrmProviderConfig` are re-exported unchanged. No import path changes.
+  - **`@getvitops/utils`**: the config types in `./crm`, `./ads`, `./indexing`, `./onboarding`, `./reviews`,
+    `./tracking` and `./notify` (`CrmConfig`, `HubSpotConfig`, `BiginConfig`, `JobberConfig`,
+    `IndexNowConfig`, `SearchConsoleConfig`, `ReviewsConfig`, `ReviewLocationConfig`, `TrackingConfig`,
+    `NotificationsConfig`, `EmailChannelConfig`, `DomainSetup`, `AdPropertySetup`) are now inferred from the
+    schema. Same names, same fields, but **optional fields now follow zod's inference**, so a hand-written
+    object literal typed against them may need `| undefined` handled. `AdPropertySetup` gains the fields the
+    schema always had (`conversionActionId`, `reporting`).
+  - **`@getvitops/astro`**: `GetvitopsAdProperty` and `GetvitopsTrackingOptions` are aliases of the schema
+    types. `toCrmConfig()` and `toGoogleAdsConfig()` are **deprecated** — they returned their argument's
+    field unchanged; pass `config.site.crm` / `config.site.ads?.google` directly.
+  - **`@getvitops/cli`**: `vitops ads` now passes `conversionActionId` and `reporting` through to the planner;
+    it previously copied a hand-picked subset of the block and dropped them.
+
+  Formats reached: none — no CSS change.
+
+- 0574388: Add `site.crm` — push form submissions into HubSpot, Zoho Bigin, or Jobber.
+
+  Client sites need form submissions to land in the client's CRM. The options available before this
+  — a HubSpot/Bigin/Jobber iframe or JS embed — fail on three counts: the markup can't be
+  white-labelled against this design system, nothing can operate on the submission before it leaves
+  the page, and the submission never touched `createConversionRoute()`, so `_ac` ad-click attribution
+  was lost and no conversion notification was planned.
+
+  This adds one server-side path for all three CRMs, hung off the conversion route that already
+  exists. `createConversionRoute()` gets a new `crm` option (`{ config, credentials, fetch?,
+  timeoutMs? }`); credentials arrive as a function of `locals`, exactly like the existing `binding`
+  option, and are never config. A failed CRM write never fails the request and is folded into the
+  notification email's new "Delivery" section, so a broken CRM token is never silent.
+
+  New `@getvitops/utils/crm` subpath: `deliverToCrm()`, `mapSubmission()`, `deriveLastName()` (Bigin
+  requires a last name; this derives one from an explicit field, a full name, or an email address,
+  refusing rather than fabricating one), `submitToHubSpot()`, `submitToBigin()`, `submitToJobber()`.
+  `identifySubmitter()` was promoted out of `notify`'s private name-guessing cascade into
+  `@getvitops/utils/tracking`, since the CRM mapper needed the whole identity (first/last name,
+  email, phone, company), not just a display name.
+
+  Jobber is GraphQL, not REST, and answers `200 OK` for failures — a rejected `clientCreate` returns
+  `userErrors[]`, a malformed request returns top-level `errors[]`. `submitToJobber()` classifies on
+  the response body, not just the status. Its refresh tokens also rotate by default: **Refresh Token
+  Rotation must be turned off** in the app's Developer Center settings, since a Worker reading a
+  static `VITOPS_JOBBER_REFRESH_TOKEN` cannot persist a rotated one — a rotated token is detected at
+  exchange time and reported with the fix, rather than surfacing an hour later as an opaque 401.
+  Attribution and unmapped extra fields render into a best-effort note by default (works on every
+  Jobber plan); a resubmitting visitor creates a second Jobber client unless `crm.jobber.dedupe: true`
+  is set once its lookup query has been verified against a live account (defaults `false` pending
+  that verification — see `jobber.ts`'s docblock).
+
+  New `site.crm` config block (`provider`, `hubspot`/`bigin`/`jobber`, `fieldMap`, `trackingFields`)
+  and two CLI commands: `vitops crm check` (fetches the live HubSpot property list or Bigin field
+  list and reports every mapped name that doesn't exist there — HubSpot rejects an unknown field
+  outright, Bigin silently drops it; Jobber has nothing live to check yet, since its mapped values
+  currently render as note text) and `vitops crm setup` (creates missing HubSpot properties; Bigin
+  and Jobber have no such API, so both always print a manual reminder).
+
+  The generated privacy policy now names HubSpot, Zoho Bigin, or Jobber when `site.crm` configures
+  one. Bigin gets the same cross-border-transfer derivation Matomo Cloud already gets: a
+  `dataCenter: 'ca'` asserts no transfer outside Canada, any other data centre does. Jobber's
+  operator (Octopusapp Inc. d/b/a Jobber) is Canadian, but its own privacy policy names the United
+  States as a processing location too, so the policy always asserts a cross-border transfer for
+  Jobber regardless of config — a Canadian operator is not read as Canadian-only storage.
+
+  Credentials: `VITOPS_HUBSPOT_ACCESS_TOKEN` for HubSpot; `VITOPS_ZOHO_CLIENT_ID` /
+  `VITOPS_ZOHO_CLIENT_SECRET` / `VITOPS_ZOHO_REFRESH_TOKEN` for Bigin; `VITOPS_JOBBER_CLIENT_ID` /
+  `VITOPS_JOBBER_CLIENT_SECRET` / `VITOPS_JOBBER_REFRESH_TOKEN` for Jobber. Never config.
+
+  No consumer-facing change in `@getvitops/astro` beyond the new `crm` route option and a build
+  warning when `site.crm` is configured with no route answering `TRACKING_ENDPOINT` — CSS/Bricks/
+  tailwind outputs are unaffected.
+
+- 8d8aad7: **New: server-side Google Ads offline conversion upload.** Set
+  `site.ads.google.reporting: "server"` and a matching
+  `conversionActionId` (a numeric id or full
+  `customers/…/conversionActions/…` resource name — **not** the same value
+  as `conversionLabel`, which is the opaque label the web tag uses and
+  which the Ads API's upload endpoint doesn't accept) and
+  `createConversionRoute`'s new `googleAdsOffline` option uploads the
+  conversion via `ConversionUploadService.UploadClickConversions` instead
+  of relying on the visitor's browser to fire `gtag.js`. An action with no
+  matching `conversionActionId` keeps firing client-side regardless of
+  `reporting`, so turning it on before the id is filled in never silently
+  drops a conversion. `@getvitops/astro/routes` exports a matching
+  `toGoogleAdsConfig(config)` adapter, alongside `toCrmConfig`.
+
+  Structurally typed against Google's documented REST shape, not verified
+  against a live Ads account — no developer-token/MCC access exists
+  anywhere in this toolchain's own setup to test against. Wrapped so a
+  wrong guess degrades to a stated failure reason (folded into the
+  conversion email's "Delivery" section, same as a failed CRM write) rather
+  than breaking, the same caveat `@getvitops/utils/crm`'s Jobber executor
+  already carries for its own unverified surfaces.
+
+  `vitops ads lint` now flags a `reporting: "server"` property whose
+  configured actions have no matching `conversionActionId` — not a
+  failure, since that action keeps firing client-side, but worth surfacing
+  rather than leaving someone to wonder why nothing changed.
+
+  Not built: `vitops ads provision` (upserting conversion actions via
+  `ConversionActionService` and printing back both the label and the
+  resource id) — same credential blocker, and deliberately left unscoped
+  until there's a live account to verify the request/response shape
+  against.
+
+- 0574388: Fire a Google Ads conversion on a tel:/mailto: click, and fix a rate-limit bug on the conversion
+  route that could silently drop one of the two.
+
+  `site.ads.google.conversionLabel` used to be accepted by the config schema and typed all the way
+  through to the rendered tag, but nothing actually read it — no `gtag('event', 'conversion', …)`
+  was ever emitted. When set, the click tracker `<Tracking />` inlines now fires the conversion at
+  the moment a visitor taps a `tel:` or `mailto:` link, using the `AW-…/label` target Google Ads
+  expects. A `conversionLabel` that can't safely land inside the inline bootstrap script (the same
+  check `pixelId`/`accountId` already get) is dropped with a warning rather than firing something
+  malformed — the ad tag itself still loads.
+
+  Also: `createConversionRoute()`'s rate limiter previously keyed on IP address alone, so a call
+  beacon and an email-click beacon from the same visitor, seconds apart, competed for one window —
+  the second could 429 and vanish with no error anywhere. It's now keyed on IP _and_ event type, so
+  distinct conversion types never starve each other; repeats of the same type are still throttled
+  exactly as before.
+
+  No config changes — a site with `site.ads.google.conversionLabel` already set picks this up
+  automatically on the next build.
+
+- 2a0a559: The Astro integration now warns when `site.locales`/`site.defaultLocale` disagree with
+  `astro.config.mjs`'s own `i18n` block — naming which locale codes are missing from each side, and
+  when the two `defaultLocale`s differ. EmDash reads its locale list straight from `i18n`, while our
+  own SEO/legal code reads `site.locales`, so the two had no way to notice they'd drifted apart. A
+  warning, not a build error — like the existing ads/analytics/consent consistency checks, either
+  side can legitimately be configured without the other, so only a genuine disagreement is flagged.
+- 0574388: Track `mailto:` link clicks as conversions, alongside the existing `tel:` link tracking.
+
+  Before this, the capture script only beaconed `tel:` clicks; a `mailto:` link on the same page was
+  invisible to attribution — a visitor who emailed the business instead of calling generated no
+  conversion event at all. `<Tracking />`'s inlined script now listens for both, sending `{ event:
+  'email', email }` via `navigator.sendBeacon` the same way it already sends `{ event: 'call', phone
+  }`.
+
+  `ConversionEvent['type']` gains an `'email'` member alongside `'form'`/`'call'`, with a new
+  `email` field. `createConversionRoute()` handles it exactly like a call: no honeypot, Turnstile or
+  CRM checks (there are no form fields to validate or map), a 204 response, and a notification email
+  subject reading `[Email Click] Visitor emailing ...`.
+
+  No config changes and no new options — a site with `<Tracking />` already mounted picks this up
+  automatically the next time it rebuilds.
+
+- dde3df3: **`site.ads.google.conversionLabel` now accepts a per-action map** —
+  `{ call?, email?, form? }` — instead of one bare string shared by every
+  interaction. A bare string still works (back-compat, treated as `call`), but a
+  call and an email click used to report as the **same** Google Ads conversion
+  action, indistinguishable in the account; each action now gets its own
+  `send_to` target.
+
+  **New: `vitopsFormConversion(formEl)`**, exposed as `window.vitopsFormConversion`
+  by `<Tracking />`'s capture script — call it from your own fetch-based form
+  submit handler once the POST to `createConversionRoute()` succeeds, to fire the
+  `form` Google Ads conversion action client-side (mirroring the existing
+  tel:/mailto: click handler, which now fires `call`/`email` instead of sharing
+  one label). Idempotent per form element. There's deliberately no server-side
+  equivalent for a no-JS `<form method="post">` submission — that's a full-page
+  redirect with no script to fire from, and a real server-side Google Ads
+  conversion needs the Ads API's click-conversion upload (developer token + MCC
+  access), tracked separately in the vNext backlog.
+
+  **Fixed: the conversion route's rate limiter no longer trusts the client's
+  raw `event` field.** It used to key on whatever string a client sent
+  (`` `${ip}:${body.event}` ``), so varying that value on every request let a
+  form submission dodge the per-IP rate limit entirely — only `'call'`/`'email'`
+  were ever recognized, and anything else got its own fresh bucket. The key now
+  uses the server's own classification (`call` | `email` | `form`), closing that
+  bypass without changing the existing call-vs-email-don't-compete behavior.
+
+  **New: `site.notifications.actionUrl`** — an optional action-link template
+  added to the conversion-notification email as an "Actions" section.
+  `{clickId}` is replaced with the ad click ID captured on `_ac` (gclid, fbclid,
+  etc.); the section is omitted when the event has no click ID to interpolate,
+  rather than emailing a broken link.
+
+- e5bc937: **Security: JSON-LD can no longer break out of its `<script>` tag.** All 24 `schemas/*.astro`
+  components inlined `JSON.stringify(jsonLd)` as-is, so a review, FAQ answer or forum post containing
+  `</script><script>…` ran as script on the page. They now go through `jsonLdScript()`, which escapes
+  `<`, `>`, `&`, U+2028 and U+2029 (still valid JSON — consumers and search engines parse the same
+  document). Sites rendering any user-supplied text through a schema component should upgrade promptly.
+
+  **`createConversionRoute()` hardening** — behaviour changes:
+
+  - The body-size cap is now enforced on the stream itself, not only on `Content-Length`; a chunked
+    request with no header is refused with 413 once it passes `maxBodyBytes`.
+  - **Breaking for non-Cloudflare hosts:** `X-Forwarded-For` is no longer used as the rate-limit key by
+    default, since off Cloudflare a client can set it freely and mint a new bucket per request. Pass
+    `trustForwardedFor: true` when running behind a proxy that overwrites it. Without
+    `CF-Connecting-IP` or that opt-in there is no IP and rate limiting is skipped. No change on
+    Cloudflare Workers.
+
+  `@getvitops/emdash`: the link/button block (`vitops.actionLink`) drops hrefs with a scheme other
+  than `http`, `https`, `mailto` or `tel` (e.g. `javascript:`, `data:`) and renders nothing for them.
+
+  Formats reached: none — no CSS change. Other packages in the `fixed` group: No consumer-facing
+  change in this package.
+
+- 7fd5f8f: **`site.seo` is now the single source of site-level SEO defaults** (ADR-0002). Until now `site.seo`
+  declared `titleTemplate`, verification tokens, `openGraph` and `twitter` that nothing read, while
+  `<Seo />` took a second, differently-shaped vocabulary through `vitops({ seo })` that no other stack
+  could see.
+
+  - `SeoSchema` moves to `@getvitops/config` and gains what only the integration had: `siteName`,
+    `defaultTitle`, `defaultDescription`, `openGraph.localeAlternates` and `openGraph.image` as
+    `{ src, alt, width, height, type }`. Text fields are localisable.
+  - `@getvitops/astro` exports `resolveSeoDefaults(config, { locale, env })`. The integration reads
+    `site.seo` from the site config it already loads; `siteName` falls back to `organization.name`, and
+    the environment's `robots` wins over `site.seo.robots`, the same fact `vitops robots` and
+    `search notify` read.
+  - `vitops({ seo })` keeps working unchanged and is now an **override** merged over the config, field by
+    field (`openGraph` and `twitter` merge key by key).
+  - **Removed from the config schema** (nothing read them): `descriptionTemplate` → use
+    `defaultDescription`; `openGraph.siteName`/`title`/`description` and
+    `twitter.title`/`description`/`image` → set per page on `<Seo />`, or the site-wide values above.
+    A config that still carries one now fails `vitops validate` with an unrecognised-key error.
+  - `openGraph.type` is now `website | article | profile`.
+
+- 3bbb8c3: Add `toNotifyContext(config, locale?)` and `toCrmConfig(config)`, exported from
+  `@getvitops/astro/routes` beside `createConversionRoute()`. Builds the `context`/`crm.config`
+  options straight from a resolved `Config` instead of hand-writing a `NotifyContext` literal —
+  `conversion.ts`'s own docblock used to state this helper "does not exist."
+
+  `organization.name` is localizable; `toNotifyContext` resolves it for a given locale (default
+  `site.defaultLocale`), falling back to `legalName` when neither locale nor default resolves to
+  anything. `locationEmails` is ordered primary location first, then every other location with an
+  `email` set, in `organization.locations`' own key order.
+
+### Patch Changes
+
+- c3c1bcb: **New: the design-system editor, mounted inside the EmDash admin.** `vitopsEmdash({
+  designSystemEditor: { config } })` (`config` is your `site.json`, e.g. `import config from
+  './site.json' with { type: 'json' }`) adds a `/design-system` admin page mounting
+  `<wc-theme-editor>` — the same live token editor `@getvitops/vite`'s dev server has always
+  offered, now usable by the client directly, no dev server required. An edit is visible
+  site-wide immediately (a runtime `:root` override, served via a new plugin API route and
+  `page:fragments`) and — once `site.deployment.repo`/`branch` and a `VITOPS_GITHUB_TOKEN`
+  secret are set (see the scaffold's `SETUP.html`) — auto-commits to your `dev` branch, so it
+  reaches the git-tracked `site.json` through your repo's normal review path rather than
+  becoming a second, unreviewed source of truth. Until that's configured, the live half still
+  works; only the auto-commit half is skipped (and says so in the admin page). The save route
+  runs the exact same accessibility (APCA contrast) gate `generate()` enforces at build time,
+  synchronously, before persisting — nothing non-compliant ever goes live even momentarily.
+
+  Requires `@astrojs/react` + `react` + `react-dom` (already scaffold dependencies, for
+  EmDash's own admin) and `@getvitops/core` (added as a new scaffold dependency this release).
+  Declares two new plugin capabilities when enabled: `network:request` (for the GitHub
+  auto-commit) and `hooks.page-fragments:register` (for the live override) — reviewed once at
+  plugin-install time.
+
+  **Breaking for `@getvitops/emdash`**: `vitopsEmdash()`'s `hooks.page-fragments:register`
+  capability is now also granted whenever `designSystemEditor` is set, independent of the
+  existing `scripts: 'fragments'` option (which governs something unrelated — web-component
+  script delivery). No change if you don't use `designSystemEditor`.
+
+  Also new, supporting the above:
+
+  - `@getvitops/generator`: `validateColorContract()` and `buildReverseIndex()` (both
+    `/tokens` subpath, Worker-safe) — the monotonicity/contrast gate and the
+    `design-manifest.json` reverse-index, each extracted from `generate()`'s `build()` into
+    standalone, non-throwing functions. `patchToOverrideCss()` turns a design-system patch
+    into the `:root` override `<style>` block. `designSystemPath`/`getAt`/`setAt`/
+    `mergePatch`/`formatConfig` moved from `@getvitops/vite` into `@getvitops/generator/config`
+    (re-exported from `@getvitops/vite` unchanged) — one "patch a config file's design-system
+    subtree" implementation shared by the dev endpoint and the new plugin route. New
+    `site.deployment.repo`/`branch` config fields.
+  - `@getvitops/utils`: new `/git` subpath — `commitFile()`, a Worker-safe (fetch-only)
+    wrapper over GitHub's Contents API.
+  - `@getvitops/core`: `<wc-theme-editor>` gains a `save-endpoint` attribute (default
+    unchanged — `/__vitops/design-system`) so the same element can target the new plugin
+    route instead of the dev-only Vite endpoint.
+
+- 0574388: Bump `emdash`/`@emdash-cms/cloudflare` peers to `>=1.0.0 <2` and `vite-plus` to `^1.0.0`, following
+  both projects' GA releases.
+
+  **Breaking for `@getvitops/emdash` consumers on EmDash 0.x**: the peer range no longer admits
+  `emdash@0.31.x`/`@emdash-cms/cloudflare@0.31.x`. Upgrade `emdash` and `@emdash-cms/cloudflare` to
+  `^1.0.1` first — nothing in `@getvitops/emdash`'s own plugin surface (`admin.portableTextBlocks`,
+  the `hooks.page-fragments:register` capability, `definePlugin()`) changed against EmDash 1.0, so no
+  code here needed to change, only the declared range.
+
+  The `emdash` scaffold template (`vp create @getvitops:emdash`) picks up several fixes alongside
+  the version bump:
+
+  - `tailwindcss`/`@tailwindcss/vite` are now real dependencies — the template selected
+    `css.format: 'tailwind'` without installing either, which threw on build.
+  - `site.json` now sets `site.icons.sprite: true` plus the full `semantic` list the
+    `vitops.actionLink` block's icon picker offers — previously its sprite icons pointed at a file
+    the build never generated.
+  - `astro.config.mjs` sets `migrations: { runtime: 'check', dev: 'auto' }`, and
+    `site-deploy-emdash.yml` runs EmDash 1.0's documented `build → status → apply → deploy → check`
+    migration sequence explicitly, rather than relying solely on first-request auto-migration. This
+    needs a new GitHub Environment variable, `EMDASH_TARGET_FINGERPRINT` (one per environment),
+    which only a human can set — run `emdash migrate --status` against the real deployed database,
+    review the printed identity, then `gh variable set EMDASH_TARGET_FINGERPRINT --env <env> --body
+    <value>`. Deploys fail clearly on the migration-apply step until it's set.
+  - `lint.options.typeAware`/`typeCheck` in the template's own `vite.config.ts` are commented out,
+    not deleted: vite-plus 1.0 only honours that option in a project's actual root config, and hard
+    errors on it in a nested one (which this file is, sitting inside the `design-system` monorepo).
+    Uncomment it once scaffolded into its own repo.
+
+  No config schema changes. `@getvitops/generator` also switches from the `zod/mini` subpath import
+  to the standalone `@zod/mini` package (zod 4.5+; same API) and fixes `validateConfig()` silently
+  losing the offending key name on an `unrecognized_keys` error (e.g. a typo'd `site.ads` platform
+  now names the bad key instead of reporting a bare "Invalid input").
+
+  Also fixed: `vp check`'s `tsconfig-error` for `packages/create/templates/emdash/tsconfig.json`
+  (`extends: "astro/tsconfigs/strict"`, unresolvable from inside this monorepo since the template
+  has no `node_modules` of its own — a pre-existing, structural gap, newly surfaced as a hard error
+  by oxlint 1.85's deeper config discovery, and blocking on every commit since this repo's pre-commit
+  hook runs `vp check --fix`). Fixed with a new `scripts/link-template-deps.mjs`, wired as the root
+  `postinstall` script: symlinks `astro`/`emdash`/`@emdash-cms/cloudflare` into the template's own
+  `node_modules/` (resolved fresh from sibling packages that already depend on them for real, not a
+  hardcoded `.pnpm` hash) and writes a minimal `astro:content` ambient shim at `.astro/types.d.ts`
+  (the same path `astro sync` would generate for real). Both are gitignored and only ever exist
+  inside this monorepo's copy of the template — a real scaffold installs its own real copies instead.
+  Considered and rejected first: inlining astro's strict preset (drift risk against astro's own
+  evolving default) and making the template a real pnpm workspace member (would change how its
+  `@getvitops/*: "latest"` deps resolve locally, which `templates.test.ts` exists to protect).
+
+  **Known gap, not fixed here**: `packages/astro/src/components/container.test.ts` (the
+  `AstroContainer`-based render tests) fails to even load under vite-plus 1.0's Vite 8 — direct
+  `.astro` imports in a Vitest file need the Astro Vite plugin registered, which nothing in this
+  repo's test config actually does (Astro's own docs call for `getViteConfig()`, which doesn't
+  compose with vite-plus's own `defineConfig`). A type-level shim
+  (`packages/astro/src/components/astro-modules.d.ts`) fixes `vp check`'s type-aware pass, but the
+  runtime `vp test` failure for this one file is still open.
+
+- 1a3e811: **Fixed: `<Icon />` no longer crashes a Cloudflare Workers SSR page.** It statically imported
+  `loadIconSvg`/`spriteId` from `@getvitops/generator`'s root entry, which also re-exports
+  `generate.ts` — reaching lightningcss, whose native binary Workers cannot `require()`.
+  Rendering `<Icon>` anywhere in an SSR project 500'd every request, regardless of
+  `icons.engine`, since the import itself (not just calling the function) pulled lightningcss
+  into the bundle. Fixed by publishing a new Worker-safe `@getvitops/generator/icons-sprite`
+  subpath (`buildIconSprite`/`loadIconSvg`/`spriteId`, no lightningcss in its import graph) and
+  switching `<Icon />` to import from there.
+- 0f8c018: **New: `resolveOrganizationName(config, locale?)`**, exported from `@getvitops/astro/routes`
+  alongside `toNotifyContext`/`toCrmConfig` — the same `organization.name` → `legalName` →
+  `undefined` fallback chain `toNotifyContext` already used for its `organizationName` field,
+  now usable standalone anywhere a build-time-only display name is needed (favicon generation,
+  a scaffold's `astro.config.mjs`, a `Layout.astro` fallback). `toNotifyContext` is unchanged —
+  it now delegates to this helper internally.
+
+  The emdash scaffold uses it to remove a three-way duplicated `'My EmDash Site'` string:
+  `astro.config.mjs`'s favicon `name` and `Layout.astro`'s title fallback both previously
+  hardcoded it independently of `site.json`'s `organization.name`. EmDash's own
+  `getSiteSettings().title` (set in the admin) still wins at render time when it's set — it's a
+  runtime-only fact that can't be read at build time at all — this only replaces the two
+  hardcoded _fallback_ strings.
+
+- 7f4f50e: `@getvitops/utils/url` exports `safeHref()` (a Worker-safe scheme allowlist: http, https, mailto, tel and relative), shared by the EmDash blocks and the Astro components. It now also guards the EmDash image-compare block, the review avatar and the cookie-notice policy link. `nodesToHtml`/`toHtml` throw on invalid tag or attribute names and on `on*` event-handler attributes, and drop `href`/`src`-style values that fail `safeHref`. EmDash cards link text now names the card for screen readers.
+- 2ef2d41: **`resolveOrganizationName()` accepts a plain `import site from './site.json'`.** It was typed
+  against the full `Config`, which a JSON import cannot satisfy — TypeScript widens its literals
+  (`colors.utilities` becomes `string[]`, not the schema's union) — so every scaffolded site's
+  `Layout.astro` failed `astro check`. It now takes `OrganizationNameSource`, the slice it actually
+  reads (`organization.name` / `legalName`, `site.defaultLocale`); a resolved `Config` still
+  satisfies it, so nothing that compiled before stops compiling.
+
+  **Both templates now typecheck and lint clean on a fresh scaffold**, found by the new `scaffold`
+  CI job (it installs each template against this checkout's packed packages):
+
+  - `site.json` declares `neutral` and `surface` as `{ "hue": "ink", "kind": "surface" }`. As bare
+    hue strings they were chromatic roles, which emit no bare `bg-neutral` and no
+    `text-neutral-muted`, so the template's own footer class resolved to nothing and `vitops lint
+    --strict` (run by the template's pre-commit hook) failed. **Existing sites are unaffected** —
+    this changes only what a new scaffold starts with; if your own `site.json` has the same two
+    lines and uses `text-neutral-*` or `bg-surface*`, change them the same way.
+  - The `emdash` template's `index.astro` and `[...slug].astro` cast `page.data.title`, which is
+    `unknown` until `emdash types` has run against a live site, so `astro check` passed only after
+    the first `pnpm dev`.
+
+  No consumer-facing change in `@getvitops/core`, `@getvitops/generator`, `@getvitops/utils`,
+  `@getvitops/cli` or `@getvitops/vite`.
+
+- fdc3f7e: `<wc-marquee>` adds a "Pause animation" button beside the track (WCAG 2.2.2), and the marquee also pauses while focus is inside it (`data-paused` and `:focus-within`). Pattern CSS: all formats. `<wc-consent>` moves focus into the banner when a visitor opens it from a settings control and returns it on close; an unprompted banner still doesn't take focus. `<wc-image-compare>`'s before/after panes are `role="group"` so their labels are announced. The conversion route format-checks `phone`/`email` beacon payloads and imports the Worker-safe `@getvitops/utils/content` instead of the utils root barrel.
+- Updated dependencies [65a13cc]
+- Updated dependencies [67e2088]
+- Updated dependencies [89265af]
+- Updated dependencies [0574388]
+- Updated dependencies [c3c1bcb]
+- Updated dependencies [0574388]
+- Updated dependencies [734ab60]
+- Updated dependencies [1a8231d]
+- Updated dependencies [779d22e]
+- Updated dependencies [0574388]
+- Updated dependencies [8d8aad7]
+- Updated dependencies [0574388]
+- Updated dependencies [1a3e811]
+- Updated dependencies [0574388]
+- Updated dependencies [dde3df3]
+- Updated dependencies [d9f213b]
+- Updated dependencies [7f4f50e]
+- Updated dependencies [7fd5f8f]
+- Updated dependencies [ceb8310]
+- Updated dependencies [88b465a]
+- Updated dependencies [fdc3f7e]
+  - @getvitops/generator@8.2.0
+  - @getvitops/config@8.2.0
+  - @getvitops/utils@8.2.0
+  - @getvitops/core@8.2.0
+  - @getvitops/vite@8.2.0
+
+## 8.2.0-alpha.0
+
+### Minor Changes
+
+- 65a13cc: **New: `site.experiments`** — runtime, per-visitor A/B content experiments for a page that
+  must stay at one URL (unlike `site.abTesting`'s existing build-time variant merge, which is
+  for a full design-system/CSS-level test via two manual deploys — `site.experiments` is the
+  opposite granularity: one page, one cookie, content branched in the page itself). Keyed by
+  an open experiment name, so more than one can run at once, each with its own consent
+  category, cookie name/lifetime, split ratio and pair of variant names.
+
+  **New `vitopsAbTesting()` middleware** (`@getvitops/astro/middleware`) — the first Astro
+  middleware this toolchain ships. Wire it into your own `src/middleware.ts`:
+
+  ```ts
+  import { vitopsAbTesting } from '@getvitops/astro/middleware';
+  import config from '../site.json' with { type: 'json' };
+
+  export const onRequest = vitopsAbTesting({
+    experiments: config.site.experiments ?? {},
+  });
+  ```
+
+  It assigns and cookie-pins a visitor to one of an experiment's two variants on first visit,
+  by weighted random (`splitRatio`) — and never touches an already-set cookie, so a recognized
+  query parameter named after the cookie itself (`?_ab_<key>=<variant>`) reliably forces that
+  variant, even overriding an existing assignment. Combined with `splitRatio: 0`, this is a
+  blue/green-style "100% on control, but a shared link reveals the other variant" mode with no
+  special-cased logic.
+
+  A page reads its own experiment's cookie (`Astro.cookies.get(cookieName)?.value`) and
+  renders whichever of its two hand-written blocks matches — there's no config-schema
+  representation of "the variant content," which is what keeps this lightweight regardless of
+  how many experiments are configured.
+
+  **`<Analytics />` gained a reporting hook**: each configured provider's bootstrap now
+  attaches an enabled experiment's assignment to the real pageview via that provider's own
+  mechanism — Plausible via `plausible.init({customProperties})`, Matomo via
+  `setCustomDimension` (needs a new `site.analytics.matomo.abVariantDimensions` entry — the
+  dimension must exist in your Matomo instance first), GA4 via a runtime-merged
+  `gtag('config', …)` call. A no-op when `site.experiments` is unset — zero behavior change
+  for every existing site.
+
+  Also new: `experimentDimensionWarnings(site)` (`@getvitops/generator`) — a build-time warning
+  (not a hard error) when an enabled experiment's site also configures Matomo but has no
+  matching `abVariantDimensions` entry.
+
+  **Not included in this pass, deliberately**: a mechanism for a fully prerendered
+  (`output: 'static'`) page — this needs a genuinely separate Cloudflare Worker Route + two
+  pre-built static variants, real but bounded follow-up work. Everything above applies to an
+  on-demand-rendered page (the current EmDash templates' default), which needs zero new
+  deploy infrastructure.
+
+- 0574388: Add `site.crm` — push form submissions into HubSpot, Zoho Bigin, or Jobber.
+
+  Client sites need form submissions to land in the client's CRM. The options available before this
+  — a HubSpot/Bigin/Jobber iframe or JS embed — fail on three counts: the markup can't be
+  white-labelled against this design system, nothing can operate on the submission before it leaves
+  the page, and the submission never touched `createConversionRoute()`, so `_ac` ad-click attribution
+  was lost and no conversion notification was planned.
+
+  This adds one server-side path for all three CRMs, hung off the conversion route that already
+  exists. `createConversionRoute()` gets a new `crm` option (`{ config, credentials, fetch?,
+  timeoutMs? }`); credentials arrive as a function of `locals`, exactly like the existing `binding`
+  option, and are never config. A failed CRM write never fails the request and is folded into the
+  notification email's new "Delivery" section, so a broken CRM token is never silent.
+
+  New `@getvitops/utils/crm` subpath: `deliverToCrm()`, `mapSubmission()`, `deriveLastName()` (Bigin
+  requires a last name; this derives one from an explicit field, a full name, or an email address,
+  refusing rather than fabricating one), `submitToHubSpot()`, `submitToBigin()`, `submitToJobber()`.
+  `identifySubmitter()` was promoted out of `notify`'s private name-guessing cascade into
+  `@getvitops/utils/tracking`, since the CRM mapper needed the whole identity (first/last name,
+  email, phone, company), not just a display name.
+
+  Jobber is GraphQL, not REST, and answers `200 OK` for failures — a rejected `clientCreate` returns
+  `userErrors[]`, a malformed request returns top-level `errors[]`. `submitToJobber()` classifies on
+  the response body, not just the status. Its refresh tokens also rotate by default: **Refresh Token
+  Rotation must be turned off** in the app's Developer Center settings, since a Worker reading a
+  static `VITOPS_JOBBER_REFRESH_TOKEN` cannot persist a rotated one — a rotated token is detected at
+  exchange time and reported with the fix, rather than surfacing an hour later as an opaque 401.
+  Attribution and unmapped extra fields render into a best-effort note by default (works on every
+  Jobber plan); a resubmitting visitor creates a second Jobber client unless `crm.jobber.dedupe: true`
+  is set once its lookup query has been verified against a live account (defaults `false` pending
+  that verification — see `jobber.ts`'s docblock).
+
+  New `site.crm` config block (`provider`, `hubspot`/`bigin`/`jobber`, `fieldMap`, `trackingFields`)
+  and two CLI commands: `vitops crm check` (fetches the live HubSpot property list or Bigin field
+  list and reports every mapped name that doesn't exist there — HubSpot rejects an unknown field
+  outright, Bigin silently drops it; Jobber has nothing live to check yet, since its mapped values
+  currently render as note text) and `vitops crm setup` (creates missing HubSpot properties; Bigin
+  and Jobber have no such API, so both always print a manual reminder).
+
+  The generated privacy policy now names HubSpot, Zoho Bigin, or Jobber when `site.crm` configures
+  one. Bigin gets the same cross-border-transfer derivation Matomo Cloud already gets: a
+  `dataCenter: 'ca'` asserts no transfer outside Canada, any other data centre does. Jobber's
+  operator (Octopusapp Inc. d/b/a Jobber) is Canadian, but its own privacy policy names the United
+  States as a processing location too, so the policy always asserts a cross-border transfer for
+  Jobber regardless of config — a Canadian operator is not read as Canadian-only storage.
+
+  Credentials: `VITOPS_HUBSPOT_ACCESS_TOKEN` for HubSpot; `VITOPS_ZOHO_CLIENT_ID` /
+  `VITOPS_ZOHO_CLIENT_SECRET` / `VITOPS_ZOHO_REFRESH_TOKEN` for Bigin; `VITOPS_JOBBER_CLIENT_ID` /
+  `VITOPS_JOBBER_CLIENT_SECRET` / `VITOPS_JOBBER_REFRESH_TOKEN` for Jobber. Never config.
+
+  No consumer-facing change in `@getvitops/astro` beyond the new `crm` route option and a build
+  warning when `site.crm` is configured with no route answering `TRACKING_ENDPOINT` — CSS/Bricks/
+  tailwind outputs are unaffected.
+
+- 0574388: Fire a Google Ads conversion on a tel:/mailto: click, and fix a rate-limit bug on the conversion
+  route that could silently drop one of the two.
+
+  `site.ads.google.conversionLabel` used to be accepted by the config schema and typed all the way
+  through to the rendered tag, but nothing actually read it — no `gtag('event', 'conversion', …)`
+  was ever emitted. When set, the click tracker `<Tracking />` inlines now fires the conversion at
+  the moment a visitor taps a `tel:` or `mailto:` link, using the `AW-…/label` target Google Ads
+  expects. A `conversionLabel` that can't safely land inside the inline bootstrap script (the same
+  check `pixelId`/`accountId` already get) is dropped with a warning rather than firing something
+  malformed — the ad tag itself still loads.
+
+  Also: `createConversionRoute()`'s rate limiter previously keyed on IP address alone, so a call
+  beacon and an email-click beacon from the same visitor, seconds apart, competed for one window —
+  the second could 429 and vanish with no error anywhere. It's now keyed on IP _and_ event type, so
+  distinct conversion types never starve each other; repeats of the same type are still throttled
+  exactly as before.
+
+  No config changes — a site with `site.ads.google.conversionLabel` already set picks this up
+  automatically on the next build.
+
+- 2a0a559: The Astro integration now warns when `site.locales`/`site.defaultLocale` disagree with
+  `astro.config.mjs`'s own `i18n` block — naming which locale codes are missing from each side, and
+  when the two `defaultLocale`s differ. EmDash reads its locale list straight from `i18n`, while our
+  own SEO/legal code reads `site.locales`, so the two had no way to notice they'd drifted apart. A
+  warning, not a build error — like the existing ads/analytics/consent consistency checks, either
+  side can legitimately be configured without the other, so only a genuine disagreement is flagged.
+- 0574388: Track `mailto:` link clicks as conversions, alongside the existing `tel:` link tracking.
+
+  Before this, the capture script only beaconed `tel:` clicks; a `mailto:` link on the same page was
+  invisible to attribution — a visitor who emailed the business instead of calling generated no
+  conversion event at all. `<Tracking />`'s inlined script now listens for both, sending `{ event:
+  'email', email }` via `navigator.sendBeacon` the same way it already sends `{ event: 'call', phone
+  }`.
+
+  `ConversionEvent['type']` gains an `'email'` member alongside `'form'`/`'call'`, with a new
+  `email` field. `createConversionRoute()` handles it exactly like a call: no honeypot, Turnstile or
+  CRM checks (there are no form fields to validate or map), a 204 response, and a notification email
+  subject reading `[Email Click] Visitor emailing ...`.
+
+  No config changes and no new options — a site with `<Tracking />` already mounted picks this up
+  automatically the next time it rebuilds.
+
+- dde3df3: **`site.ads.google.conversionLabel` now accepts a per-action map** —
+  `{ call?, email?, form? }` — instead of one bare string shared by every
+  interaction. A bare string still works (back-compat, treated as `call`), but a
+  call and an email click used to report as the **same** Google Ads conversion
+  action, indistinguishable in the account; each action now gets its own
+  `send_to` target.
+
+  **New: `vitopsFormConversion(formEl)`**, exposed as `window.vitopsFormConversion`
+  by `<Tracking />`'s capture script — call it from your own fetch-based form
+  submit handler once the POST to `createConversionRoute()` succeeds, to fire the
+  `form` Google Ads conversion action client-side (mirroring the existing
+  tel:/mailto: click handler, which now fires `call`/`email` instead of sharing
+  one label). Idempotent per form element. There's deliberately no server-side
+  equivalent for a no-JS `<form method="post">` submission — that's a full-page
+  redirect with no script to fire from, and a real server-side Google Ads
+  conversion needs the Ads API's click-conversion upload (developer token + MCC
+  access), tracked separately in the vNext backlog.
+
+  **Fixed: the conversion route's rate limiter no longer trusts the client's
+  raw `event` field.** It used to key on whatever string a client sent
+  (`` `${ip}:${body.event}` ``), so varying that value on every request let a
+  form submission dodge the per-IP rate limit entirely — only `'call'`/`'email'`
+  were ever recognized, and anything else got its own fresh bucket. The key now
+  uses the server's own classification (`call` | `email` | `form`), closing that
+  bypass without changing the existing call-vs-email-don't-compete behavior.
+
+  **New: `site.notifications.actionUrl`** — an optional action-link template
+  added to the conversion-notification email as an "Actions" section.
+  `{clickId}` is replaced with the ad click ID captured on `_ac` (gclid, fbclid,
+  etc.); the section is omitted when the event has no click ID to interpolate,
+  rather than emailing a broken link.
+
+- 3bbb8c3: Add `toNotifyContext(config, locale?)` and `toCrmConfig(config)`, exported from
+  `@getvitops/astro/routes` beside `createConversionRoute()`. Builds the `context`/`crm.config`
+  options straight from a resolved `Config` instead of hand-writing a `NotifyContext` literal —
+  `conversion.ts`'s own docblock used to state this helper "does not exist."
+
+  `organization.name` is localizable; `toNotifyContext` resolves it for a given locale (default
+  `site.defaultLocale`), falling back to `legalName` when neither locale nor default resolves to
+  anything. `locationEmails` is ordered primary location first, then every other location with an
+  `email` set, in `organization.locations`' own key order.
+
+### Patch Changes
+
+- c3c1bcb: **New: the design-system editor, mounted inside the EmDash admin.** `vitopsEmdash({
+  designSystemEditor: { config } })` (`config` is your `site.json`, e.g. `import config from
+  './site.json' with { type: 'json' }`) adds a `/design-system` admin page mounting
+  `<wc-theme-editor>` — the same live token editor `@getvitops/vite`'s dev server has always
+  offered, now usable by the client directly, no dev server required. An edit is visible
+  site-wide immediately (a runtime `:root` override, served via a new plugin API route and
+  `page:fragments`) and — once `site.deployment.repo`/`branch` and a `VITOPS_GITHUB_TOKEN`
+  secret are set (see the scaffold's `SETUP.html`) — auto-commits to your `dev` branch, so it
+  reaches the git-tracked `site.json` through your repo's normal review path rather than
+  becoming a second, unreviewed source of truth. Until that's configured, the live half still
+  works; only the auto-commit half is skipped (and says so in the admin page). The save route
+  runs the exact same accessibility (APCA contrast) gate `generate()` enforces at build time,
+  synchronously, before persisting — nothing non-compliant ever goes live even momentarily.
+
+  Requires `@astrojs/react` + `react` + `react-dom` (already scaffold dependencies, for
+  EmDash's own admin) and `@getvitops/core` (added as a new scaffold dependency this release).
+  Declares two new plugin capabilities when enabled: `network:request` (for the GitHub
+  auto-commit) and `hooks.page-fragments:register` (for the live override) — reviewed once at
+  plugin-install time.
+
+  **Breaking for `@getvitops/emdash`**: `vitopsEmdash()`'s `hooks.page-fragments:register`
+  capability is now also granted whenever `designSystemEditor` is set, independent of the
+  existing `scripts: 'fragments'` option (which governs something unrelated — web-component
+  script delivery). No change if you don't use `designSystemEditor`.
+
+  Also new, supporting the above:
+  - `@getvitops/generator`: `validateColorContract()` and `buildReverseIndex()` (both
+    `/tokens` subpath, Worker-safe) — the monotonicity/contrast gate and the
+    `design-manifest.json` reverse-index, each extracted from `generate()`'s `build()` into
+    standalone, non-throwing functions. `patchToOverrideCss()` turns a design-system patch
+    into the `:root` override `<style>` block. `designSystemPath`/`getAt`/`setAt`/
+    `mergePatch`/`formatConfig` moved from `@getvitops/vite` into `@getvitops/generator/config`
+    (re-exported from `@getvitops/vite` unchanged) — one "patch a config file's design-system
+    subtree" implementation shared by the dev endpoint and the new plugin route. New
+    `site.deployment.repo`/`branch` config fields.
+  - `@getvitops/utils`: new `/git` subpath — `commitFile()`, a Worker-safe (fetch-only)
+    wrapper over GitHub's Contents API.
+  - `@getvitops/core`: `<wc-theme-editor>` gains a `save-endpoint` attribute (default
+    unchanged — `/__vitops/design-system`) so the same element can target the new plugin
+    route instead of the dev-only Vite endpoint.
+
+- 0574388: Bump `emdash`/`@emdash-cms/cloudflare` peers to `>=1.0.0 <2` and `vite-plus` to `^1.0.0`, following
+  both projects' GA releases.
+
+  **Breaking for `@getvitops/emdash` consumers on EmDash 0.x**: the peer range no longer admits
+  `emdash@0.31.x`/`@emdash-cms/cloudflare@0.31.x`. Upgrade `emdash` and `@emdash-cms/cloudflare` to
+  `^1.0.1` first — nothing in `@getvitops/emdash`'s own plugin surface (`admin.portableTextBlocks`,
+  the `hooks.page-fragments:register` capability, `definePlugin()`) changed against EmDash 1.0, so no
+  code here needed to change, only the declared range.
+
+  The `emdash` scaffold template (`vp create @getvitops:emdash`) picks up several fixes alongside
+  the version bump:
+  - `tailwindcss`/`@tailwindcss/vite` are now real dependencies — the template selected
+    `css.format: 'tailwind'` without installing either, which threw on build.
+  - `site.json` now sets `site.icons.sprite: true` plus the full `semantic` list the
+    `vitops.actionLink` block's icon picker offers — previously its sprite icons pointed at a file
+    the build never generated.
+  - `astro.config.mjs` sets `migrations: { runtime: 'check', dev: 'auto' }`, and
+    `site-deploy-emdash.yml` runs EmDash 1.0's documented `build → status → apply → deploy → check`
+    migration sequence explicitly, rather than relying solely on first-request auto-migration. This
+    needs a new GitHub Environment variable, `EMDASH_TARGET_FINGERPRINT` (one per environment),
+    which only a human can set — run `emdash migrate --status` against the real deployed database,
+    review the printed identity, then `gh variable set EMDASH_TARGET_FINGERPRINT --env <env> --body
+    <value>`. Deploys fail clearly on the migration-apply step until it's set.
+  - `lint.options.typeAware`/`typeCheck` in the template's own `vite.config.ts` are commented out,
+    not deleted: vite-plus 1.0 only honours that option in a project's actual root config, and hard
+    errors on it in a nested one (which this file is, sitting inside the `design-system` monorepo).
+    Uncomment it once scaffolded into its own repo.
+
+  No config schema changes. `@getvitops/generator` also switches from the `zod/mini` subpath import
+  to the standalone `@zod/mini` package (zod 4.5+; same API) and fixes `validateConfig()` silently
+  losing the offending key name on an `unrecognized_keys` error (e.g. a typo'd `site.ads` platform
+  now names the bad key instead of reporting a bare "Invalid input").
+
+  Also fixed: `vp check`'s `tsconfig-error` for `packages/create/templates/emdash/tsconfig.json`
+  (`extends: "astro/tsconfigs/strict"`, unresolvable from inside this monorepo since the template
+  has no `node_modules` of its own — a pre-existing, structural gap, newly surfaced as a hard error
+  by oxlint 1.85's deeper config discovery, and blocking on every commit since this repo's pre-commit
+  hook runs `vp check --fix`). Fixed with a new `scripts/link-template-deps.mjs`, wired as the root
+  `postinstall` script: symlinks `astro`/`emdash`/`@emdash-cms/cloudflare` into the template's own
+  `node_modules/` (resolved fresh from sibling packages that already depend on them for real, not a
+  hardcoded `.pnpm` hash) and writes a minimal `astro:content` ambient shim at `.astro/types.d.ts`
+  (the same path `astro sync` would generate for real). Both are gitignored and only ever exist
+  inside this monorepo's copy of the template — a real scaffold installs its own real copies instead.
+  Considered and rejected first: inlining astro's strict preset (drift risk against astro's own
+  evolving default) and making the template a real pnpm workspace member (would change how its
+  `@getvitops/*: "latest"` deps resolve locally, which `templates.test.ts` exists to protect).
+
+  **Known gap, not fixed here**: `packages/astro/src/components/container.test.ts` (the
+  `AstroContainer`-based render tests) fails to even load under vite-plus 1.0's Vite 8 — direct
+  `.astro` imports in a Vitest file need the Astro Vite plugin registered, which nothing in this
+  repo's test config actually does (Astro's own docs call for `getViteConfig()`, which doesn't
+  compose with vite-plus's own `defineConfig`). A type-level shim
+  (`packages/astro/src/components/astro-modules.d.ts`) fixes `vp check`'s type-aware pass, but the
+  runtime `vp test` failure for this one file is still open.
+
+- 1a3e811: **Fixed: `<Icon />` no longer crashes a Cloudflare Workers SSR page.** It statically imported
+  `loadIconSvg`/`spriteId` from `@getvitops/generator`'s root entry, which also re-exports
+  `generate.ts` — reaching lightningcss, whose native binary Workers cannot `require()`.
+  Rendering `<Icon>` anywhere in an SSR project 500'd every request, regardless of
+  `icons.engine`, since the import itself (not just calling the function) pulled lightningcss
+  into the bundle. Fixed by publishing a new Worker-safe `@getvitops/generator/icons-sprite`
+  subpath (`buildIconSprite`/`loadIconSvg`/`spriteId`, no lightningcss in its import graph) and
+  switching `<Icon />` to import from there.
+- 0f8c018: **New: `resolveOrganizationName(config, locale?)`**, exported from `@getvitops/astro/routes`
+  alongside `toNotifyContext`/`toCrmConfig` — the same `organization.name` → `legalName` →
+  `undefined` fallback chain `toNotifyContext` already used for its `organizationName` field,
+  now usable standalone anywhere a build-time-only display name is needed (favicon generation,
+  a scaffold's `astro.config.mjs`, a `Layout.astro` fallback). `toNotifyContext` is unchanged —
+  it now delegates to this helper internally.
+
+  The emdash scaffold uses it to remove a three-way duplicated `'My EmDash Site'` string:
+  `astro.config.mjs`'s favicon `name` and `Layout.astro`'s title fallback both previously
+  hardcoded it independently of `site.json`'s `organization.name`. EmDash's own
+  `getSiteSettings().title` (set in the admin) still wins at render time when it's set — it's a
+  runtime-only fact that can't be read at build time at all — this only replaces the two
+  hardcoded _fallback_ strings.
+
+- Updated dependencies [65a13cc]
+- Updated dependencies [67e2088]
+- Updated dependencies [0574388]
+- Updated dependencies [c3c1bcb]
+- Updated dependencies [0574388]
+- Updated dependencies [0574388]
+- Updated dependencies [0574388]
+- Updated dependencies [1a3e811]
+- Updated dependencies [0574388]
+- Updated dependencies [dde3df3]
+- Updated dependencies [d9f213b]
+  - @getvitops/generator@8.2.0-alpha.0
+  - @getvitops/utils@8.2.0-alpha.0
+  - @getvitops/core@8.2.0-alpha.0
+  - @getvitops/vite@8.2.0-alpha.0
+
 ## 8.1.0
 
 ### Patch Changes
@@ -52,7 +846,6 @@
 
   **Breaking (`css`/`bricks` and `tailwind` formats — `.lightbox-dialog`'s markup
   contract changed):**
-
   - `<Gallery />` now emits ONE `<dialog class="lightbox-dialog">` per gallery,
     wrapping a `<Carousel />`, instead of one dialog per image. A `.gallery__trigger`
     is now a plain `<a href="#slide-id">`, not a `command="show-modal"` button.
@@ -93,7 +886,6 @@
 ### Minor Changes
 
 - Add Google Business Profile reviews: fetch, cache, render.
-
   - **`vitops reviews`** (new CLI command) fetches a client's GBP reviews (legacy v4 API — the only
     one that has them) and writes them to `.vitops/reviews.json`, meant to be committed so a build
     never needs a live Google credential. `--dry` prints the plan; `--check` diffs against the cache
@@ -128,7 +920,6 @@
   `--site` for now.)
 
   **Fixed:**
-
   - `@getvitops/core`'s 12 runtime deps (`lit`, both `@oddbird` polyfills, both
     `@webcomponents` packages, `colorjs.io`, etc.) were listed as `dependencies` despite
     being bundled into `dist/elements.js`/`dist/polyfills.js`/`dist/deferred.js` — a
@@ -274,7 +1065,7 @@
     created, with `patterns/counter.css`'s own reduced-motion query as a second belt.
   - The accessible name stays the final value for the whole animation: `.counter__value` is toggled
     to the framework's `.sr-only` utility while running, never hidden — `display: none`/`visibility:
-hidden` would pull it out of the accessible-name computation along with the visual hiding, and a
+    hidden` would pull it out of the accessible-name computation along with the visual hiding, and a
     screen reader must never be read ~60 intermediate numbers. The animated text lives in a separate
     `aria-hidden` presentation span it never reaches.
   - `data-from` (default `0`), `data-duration` (ms, default `1200`), `data-easing` (`linear` |
@@ -985,7 +1776,7 @@ hidden` would pull it out of the accessible-name computation along with the visu
     `animate-view` / `animate-scroll` / `animate-trigger` / `transition`, and every effect
     gained an `open-<fx>` state variant. Overlays now state _where they start_
     (`--translate-x-from`) instead of owning a keyframe: `class="drawer drawer--right
-open-fade-in"` composes slide and fade. Applied at zero specificity with identity
+    open-fade-in"` composes slide and fade. Applied at zero specificity with identity
     defaults, so a popover that sets no effect vars is unchanged.
   - **One scrim.** `--scrim` / `--scrim-filter` tokens and `.no-scrim` in `popover.css`,
     replacing 18 `::backdrop` blocks across seven partials. `.drawer--modeless` is aliased.
@@ -1060,7 +1851,7 @@ open-fade-in"` composes slide and fade. Applied at zero specificity with identit
   Also new, and worth wiring at the same time — **`gitLastmod()` for real sitemap dates**:
 
   ```js
-  import vitops, { gitLastmod } from "@getvitops/astro";
+  import vitops, { gitLastmod } from '@getvitops/astro';
   vitops({ sitemap: { serialize: await gitLastmod() } });
   ```
 
@@ -1126,7 +1917,7 @@ open-fade-in"` composes slide and fade. Applied at zero specificity with identit
   toolchain bump. Use `--force` when you mean to re-encode.
 
   **`ffmpeg` is an external tool, not an npm dependency** — install it yourself (`brew install
-ffmpeg`, `apt install ffmpeg`, `winget install Gyan.FFmpeg`). The command fails without it rather
+  ffmpeg`, `apt install ffmpeg`, `winget install Gyan.FFmpeg`). The command fails without it rather
   than skipping: a page referencing a video that was never encoded is broken, not degraded.
 
   Two defaults worth knowing about. The MP4 exists because older iOS and the in-app webviews inside
@@ -1160,8 +1951,8 @@ ffmpeg`, `apt install ffmpeg`, `winget install Gyan.FFmpeg`). The command fails
 
   ```js
   vitops({
-    analytics: { googleAnalytics: "G-XXXXXXXXXX", plausible: "acme.com" },
-    consent: { policyUrl: "/legal/cookies" },
+    analytics: { googleAnalytics: 'G-XXXXXXXXXX', plausible: 'acme.com' },
+    consent: { policyUrl: '/legal/cookies' },
   });
   ```
 
@@ -1219,8 +2010,8 @@ ffmpeg`, `apt install ffmpeg`, `winget install Gyan.FFmpeg`). The command fails
   replace it with `--anim-range`. `--stagger-range-step` is now a viewport length (`5vh`) to match.
 
   **Fixed: every journey ran on a truncated range.** The generator emitted `animation-range: entry
-exit`; lightningcss parsed the end of that shorthand as `exit 0%` rather than the spec's `exit
-100%`, so the bundle shipped `entry exit 0%`. Journeys reach their `100%` keyframe — the hidden
+  exit`; lightningcss parsed the end of that shorthand as `exit 0%` rather than the spec's `exit
+  100%`, so the bundle shipped `entry exit 0%`. Journeys reach their `100%` keyframe — the hidden
   `from` state — as the element hits the top of the viewport, which is to say they faded out while
   still fully on screen. Journeys now run `entry calc(50% + 10vh) → exit 100%`: they start on the same
   midpoint pivot as everything else and keep the full entry → hold → exit arc, so the hold sits in the
@@ -1233,7 +2024,7 @@ exit`; lightningcss parsed the end of that shorthand as `exit 0%` rather than th
   so one knob tunes both. If your own config has an empty `slide` base, add the same line.
 
   **Fixed: `reveal-*` on hover was unreachable.** A `hover-reveal-left` element rests at `clip-path:
-inset(0 100% 0 0)`, and `clip-path` clips **hit-testing** as well as painting — so it had zero
+  inset(0 100% 0 0)`, and `clip-path` clips **hit-testing** as well as painting — so it had zero
   hittable area and could never receive the hover that would reveal it. The state variants now match
   the element **or its direct parent**, mirroring what `animation.css` already did for the trigger
   driver (`:is(.is-active, [data-active]) > .animate-trigger`):
@@ -1301,7 +2092,7 @@ inset(0 100% 0 0)`, and `clip-path` clips **hit-testing** as well as painting
 
   ```js
   // astro.config.mjs
-  getvitops({ css: { input: "company.json", format: "css" } });
+  getvitops({ css: { input: 'company.json', format: 'css' } });
   ```
 
   ```
@@ -1400,11 +2191,11 @@ inset(0 100% 0 0)`, and `clip-path` clips **hit-testing** as well as painting
   getvitops({
     fonts: [
       {
-        name: "League Spartan",
-        provider: "fontsource",
-        cssVariable: "--font-league-spartan",
-        weights: ["100 900"],
-        subsets: ["latin"],
+        name: 'League Spartan',
+        provider: 'fontsource',
+        cssVariable: '--font-league-spartan',
+        weights: ['100 900'],
+        subsets: ['latin'],
         preload: true,
       },
     ],
@@ -1584,7 +2375,7 @@ inset(0 100% 0 0)`, and `clip-path` clips **hit-testing** as well as painting
 - bf453b0: Fixed: a site on `css.format: 'css'` failed to build because of Tailwind.
 
   `getvitops()` loads `@tailwindcss/vite` lazily, so a project that never sets `css.format:
-'tailwind'` should never touch it. But the specifier was a literal, which makes it statically
+  'tailwind'` should never touch it. But the specifier was a literal, which makes it statically
   analysable — so the bundler **followed** the import regardless of the branch ever running, down
   through `@tailwindcss/node` to `@tailwindcss/oxide`'s native `.node` binding, which it cannot parse.
   The build died on `[UNLOADABLE_DEPENDENCY] … stream did not contain valid UTF-8`, naming a package
@@ -1632,14 +2423,14 @@ inset(0 100% 0 0)`, and `clip-path` clips **hit-testing** as well as painting
   // astro.config.mjs
   vitops({
     seo: {
-      siteName: "Acme",
-      titleTemplate: "%s · Acme",
-      defaultDescription: "We make the thing.",
+      siteName: 'Acme',
+      titleTemplate: '%s · Acme',
+      defaultDescription: 'We make the thing.',
       openGraph: {
-        locale: "en_CA",
-        image: { url: "/og.png", alt: "Acme", width: 1200, height: 630 },
+        locale: 'en_CA',
+        image: { url: '/og.png', alt: 'Acme', width: 1200, height: 630 },
       },
-      twitter: { site: "@acme" },
+      twitter: { site: '@acme' },
     },
   });
   ```
@@ -1683,7 +2474,7 @@ inset(0 100% 0 0)`, and `clip-path` clips **hit-testing** as well as painting
 
   ```js
   getvitops({ sitemap: true });
-  getvitops({ sitemap: { filter: (page) => !page.includes("/draft/") } });
+  getvitops({ sitemap: { filter: (page) => !page.includes('/draft/') } });
   ```
 
   `@astrojs/sitemap` is an **optional peer** — install it yourself (`pnpm add -D @astrojs/sitemap`) and
@@ -1918,15 +2709,15 @@ inset(0 100% 0 0)`, and `clip-path` clips **hit-testing** as well as painting
   which `@getvitops/astro` re-exports wholesale. So from `astro.config.mjs`:
 
   ```js
-  import { generateIconInclude } from "@getvitops/astro";
-  import icon from "astro-icon";
+  import { generateIconInclude } from '@getvitops/astro';
+  import icon from 'astro-icon';
 
   integrations: [
     icon({
       include: generateIconInclude({
-        ui: "fa7-solid",
-        brand: "simple-icons",
-        semantic: ["menu", "close", "search", "github"],
+        ui: 'fa7-solid',
+        brand: 'simple-icons',
+        semantic: ['menu', 'close', 'search', 'github'],
       }),
     }),
   ];
@@ -1960,7 +2751,7 @@ inset(0 100% 0 0)`, and `clip-path` clips **hit-testing** as well as painting
   ```js
   // astro.config.mjs
   getvitops({
-    css: { input: "design-system.json", format: "css", out: "src/styles" },
+    css: { input: 'design-system.json', format: 'css', out: 'src/styles' },
     editor: true,
   });
   ```
@@ -2071,7 +2862,7 @@ inset(0 100% 0 0)`, and `clip-path` clips **hit-testing** as well as painting
   - `.chip-list__chip` and `.chip-list__chip-remove` are **removed**. A tag list is a list of tags, so
     its items are now the existing `.tag` / `.tag__remove` — which also means they pick up tag role
     variants. **Migration:** replace `<span class="chip-list__chip">x <button
-class="chip-list__chip-remove">` with `<span class="tag">x <button class="tag__remove">`. Note the
+    class="chip-list__chip-remove">` with `<span class="tag">x <button class="tag__remove">`. Note the
     items change appearance: `.tag` is outlined (border + neutral text) where the old chip was filled
     with `--color-surface-muted`.
   - The `radii.chip` primitive is **removed** from the example config; it was only ever an alias of