@getvitops/utils 8.2.0-alpha.0 → 8.3.0-alpha.0

package/CHANGELOG.md

@@ -1,5 +1,389 @@
 # @getvitops/utils
 
+## 8.3.0-alpha.0
+
+### Minor Changes
+
+- 161c7f3: A contact form that works end to end: `vitops setup turnstile`, `<wc-turnstile>`, the `vitops.form` EmDash block, and the route the emdash template ships to receive it.
+
+  **CSS, all formats** (no existing class changes): `forms.css` gains `.form-notice--target:not(:target)` (a message revealed only when the URL fragment names it, which is how a prerendered page shows a no-JS form's result) and `:where(wc-turnstile) { display: block }`.
+
+  **`@getvitops/core`:** new `<wc-turnstile sitekey="…">` in `elements.js`. It loads Cloudflare Turnstile on the first interaction with its form (no request to `challenges.cloudflare.com` for a visitor who only reads the page), holds an early submit until the token arrives, and leaves its slotted no-JS explanation in place until JS takes over. Turnstile is category `necessary`, so it is not behind the consent banner.
+
+  **`@getvitops/utils` / `@getvitops/cli`:** new `@getvitops/utils/turnstile` and `vitops setup turnstile [--dry] [--check] [--no-write] [--no-secret]`. It plans from the site's hostnames, creates a managed widget unless one already covers them (an existing widget is adopted, never edited, rotated or deleted), writes the public key to `site.security.turnstile.siteKey`, and pipes the one-time secret to `wrangler secret put VITOPS_TURNSTILE_SECRET` without writing it to any file. Needs `CLOUDFLARE_API_TOKEN` with **Account > Turnstile > Edit** and `CLOUDFLARE_ACCOUNT_ID`.
+
+  **`@getvitops/astro`:** `virtual:getvitops/head` gains `turnstileSiteKey` (read from `site.security.turnstile.siteKey`) so blocks can render the widget. No other change.
+
+  **`@getvitops/generator`:** `TIERS` gains a `turnstile` entry (wc-turnstile, claimed by `vitops.form`); `wc-multi-field`'s `emdashExempt` reason is reworded now the form block exists.
+
+  **`@getvitops/emdash`:** new `vitops.form` block: a field repeater (text, email, phone, long text, choose one, tick box), required flags, help text, success/error messages, optional Turnstile. It renders a semantic `<form method="post">` that works with no JavaScript, with a honeypot named per `createConversionRoute`'s defaults. A field named `phone` submits as `tel`, because the route reserves `phone` and `event`.
+
+  **`@getvitops/create`:** the emdash template ships `src/pages/api/track.ts` (`prerender = false`, `createConversionRoute()`), a seeded contact form, and `challenges.cloudflare.com` in both templates' Report-Only CSP (`script-src`, `frame-src`). The route refuses a post with nowhere to deliver and fails closed when a site key exists without `VITOPS_TURNSTILE_SECRET`. SETUP.html gains the Turnstile step. Existing sites: copy the route and the CSP change, then run `vitops setup turnstile`.
+
+- 175d16e: **Added: `vitops.reviews` and `vitops.nav` EmDash blocks.** Non-breaking.
+
+  - **`vitops.reviews`** renders Google reviews from the committed `.vitops/reviews.json` cache (`vitops reviews`) as a grid, carousel or marquee of `<ReviewCard>`. Fields: location key, layout, columns, limit, lowest rating, order, featured ids, reviewer photos (off by default), tone/colour. Which reviews show is `selectReviews()`, the one shared decision. Review JSON-LD is not offered (Google treats self-marked-up reviews as ineligible for rich results). A new review reaches the page after `vitops reviews` is re-run, committed and the site rebuilt, not when an editor saves; with no cache file the block renders nothing (a note in `astro dev`).
+  - **`vitops.nav`** renders a named EmDash menu inside page content (site map, section links, footer-style columns), never the header. Fields: menu (picked from the site's menus via a new `menus/list` plugin route, with `footer-sitemap`/`footer-legal`/`primary` as the static fallback), accessible name, visible heading and level, layout `list | inline | columns | sitenav`, depth 1-3, tone/colour. It is a `<nav>` with a name that is never `Primary`, `Site map` or `Legal` (the layout's landmarks), `aria-current="page"`, no runtime JS; a missing or empty menu renders nothing.
+  - `@getvitops/astro`: **`virtual:getvitops/reviews`**, served by `vitops()`, is `.vitops/reviews.json` as a build-time import (an empty cache when absent or unreadable), because a Worker cannot read the file. `<ReviewCard>` now renders the review's source link (`.review__source`, `rel="nofollow noopener noreferrer"`), which the pattern already styled. **Fix:** `src/json-ld.ts` was missing from the published `files`, so any consumer importing `<ReviewCard>` (which composes `schemas/Review.astro`) failed to build with an unresolved import. `@getvitops/emdash` now needs this version of `@getvitops/astro` for the `vitops.reviews` block.
+  - `@getvitops/utils`: new Worker-safe subpath **`@getvitops/utils/reviews/select`** (`selectReviews` and the review types, no `node:fs`). `selectReviews` now takes only the display fields (`featured`, `minRating`, `limit`, `sort`), so a caller with no configured `locationId` can use it; existing calls are unchanged.
+  - `@getvitops/core`: new `.navlist` pattern in `patterns/sitenav.css` (`.navlist`, `__item`, `__link`, `__label`, `__sub`, `--inline`, `--columns`). **All formats** (css, bricks, tailwind). No existing class changes.
+  - `@getvitops/generator`: `TIERS.review` lists `vitops.reviews` and `TIERS.sitenav` lists `vitops.nav` (and `.navlist`), so `vitops docs components` and the docsite show them.
+
+- 83d6f3c: Theming escape hatches, so a real palette builds without raw ramp steps. All additive; existing configs build unchanged.
+
+  - **Dark-only sites.** `designSystem.defaultColorScheme: "dark"` (accepted by the schema before, but ignored) now makes the dark tokens the `:root` appearance with `color-scheme: dark`, emits no light block or `data-theme` flip, and skips light-mode contrast checks. Reaches css, bricks and tailwind formats. Do not ship `<wc-color-scheme-toggle>` on such a site.
+  - **Role solid step and foreground.** `colors.roles.<role>` may be `{ hue, kind?, solid?, foreground? }`. `solid: 400` starts the solid family at step 400 (bold and x-bold walk one and two rungs darker); `foreground: "dark" | "light"` pins `text-on-<role>`. The APCA check (Lc 60) still runs on the pair emitted. The string shorthand is unchanged. All formats. The live editor's `roleTokens` still assume the default 600 family when re-pointing a role.
+  - **Split shadows.** `shadows.<name>` may be `{ box?, drop? }`: `box` (spread, inset, layers) is `--shadow-<name>`; `drop` is `--shadow-<name>-drop` and feeds `.drop-shadow-<name>` and the `shadow:` state shortcut. The string form is unchanged. css/bricks emit `.drop-shadow-*`; tailwind emits the `-drop` token only.
+  - **Layout tokens.** New optional `layout` block (`widths.{measure,breakout,spotlight,nav}`, `regionSpace.{min,preferred,max}`) emitted as `--width-*` / `--region-space*` on `:root` in css, bricks and tailwind formats, and exposed in `design-manifest.json` (`layout`, `reverseIndex`). Keys you omit keep the framework defaults.
+  - **`acknowledgeOffLadder: true`** on a palette hue silences that hue's off-ladder anchor warnings.
+  - **Typography:** `transform` and `decoration` are now accepted as aliases of `text-transform` and `text-decoration` (canonical wins when both are present) instead of warning and being dropped.
+  - **Docs strings** (`authoring.md`, JSON Schema hovers) state the Lc 60 muted-text requirement against the page plane and give a type-scale recipe for marketing headings.
+  - `@getvitops/utils`: `pickOn` takes an optional `prefer: 'light' | 'dark'`.
+
+- b47df4d: **Added: `vitops audit` — Lighthouse + axe budgets over a built site.** Non-breaking, opt-in.
+
+  `vitops audit [--build] [--url <base>] [--pages /a,/b] [--warn] [--out <dir>]` serves the existing build with `astro preview` on a dedicated port (4398; it aborts rather than attach to something else already there), audits `/` plus `/privacy`, `/terms`, `/cookies`, `/contact` and every link in `seed/seed.json`'s `primary*`/`footer*` menus, and skips any route that 404s (a 404 on `/` fails the run). Per page it runs axe (tags wcag2a, wcag2aa, wcag21a, wcag21aa) and Lighthouse on the same Chromium. Default budgets: LCP < 2500 ms, CLS < 0.1, TBT < 200 ms (the INP proxy), no serious or critical axe violations; override with `--lcp`, `--cls`, `--tbt`, `--impact`. Writes `report.json`, `report.md` and `pages/<page>.{json,md}` to `.vitops/audit/`; exits non-zero on failure unless `--warn`. Every report states that a pass is **not** AODA certification and lists the manual checks.
+
+  `playwright`, `@axe-core/playwright` and `lighthouse` are **optional peer dependencies** of `@getvitops/utils`, loaded lazily — nothing is installed or loaded unless you run the command, and a missing one fails with the install command. Pure planner and report rendering are `@getvitops/utils/audit` (new subpath).
+
+  CI: the reusable `site-ci.yml` gains opt-in `run-audit` (default `false`) and `audit-args` inputs; callers pinned to `@v1` that pass neither are unaffected.
+
+### Patch Changes
+
+- @getvitops/config@8.3.0-alpha.0
+
+## 8.2.0
+
+### Minor Changes
+
+- 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.
+
+- 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: Add `vitops email setup|check` — connect `site.notifications.email.from` to whether its domain is
+  actually onboarded onto an outbound email provider.
+
+  Before this, nothing checked that. `EMAIL.send()` throws `E_SENDER_NOT_VERIFIED` at runtime with no
+  build or deploy-time warning — the failure mode is silent and production-only.
+
+  `vitops email setup [domain]` onboards a sending domain (currently Cloudflare Email Sending only)
+  and polls DNS until its SPF/DKIM/DMARC records resolve or a timeout is reached; `vitops email
+  check` is the non-blocking deploy guard both `@getvitops/create` templates' `deploy`/`deploy:dev`
+  scripts now run first (`--strict` makes it a real gate; opt out per-site with
+  `site.notifications.email.verifySender: false`, or globally with `--skip` /
+  `VITOPS_SKIP_EMAIL_CHECK`).
+
+  Two things worth knowing before running it:
+
+  - **The onboarded entity is an exact name, and it is usually a subdomain**
+    (`send.yourdomain.com`), never the apex your `from` address names. When the exact domain isn't
+    onboarded but a sibling in the same zone already is, the command reports that as the fix — send
+    from the onboarded subdomain — rather than silently trying to onboard the apex, which rewrites
+    `_dmarc.<domain>` and can tighten DMARC policy on every other mail your domain sends.
+  - Candidates come from `site.notifications.email.from` (or its derived `noreply@<domains
+    .canonical>` default) first; a best-effort scan of `--src` only supplements it, and never guesses
+    at a computed `from` value.
+
+  New `@getvitops/utils/email` subpath and `site.notifications.email.verifySender` config field.
+  Needs `CLOUDFLARE_API_TOKEN` with an Email Sending scope in addition to the `Zone:Read` other
+  commands already use.
+
+- 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.
+
+- 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.
+
+- 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.
+- ceb8310: **`@getvitops/utils/notify` is Worker-safe again.** It re-exports the Google Ads offline-conversion
+  upload, which reached `google/token.ts` and its `node:crypto` import, so the subpath could not load in
+  a bare Worker. The service-account JWT is now signed with Web Crypto (`crypto.subtle`, RS256) — same
+  token, same PKCS#8 key Google issues, no Node builtin. A new `worker-safe.test.ts` walks each Worker
+  subpath's import graph and fails on any `node:` specifier.
+
+  **Breaking, narrow:** `@getvitops/utils/ads` no longer re-exports `createApexTxt`, `findZoneId` and
+  `listApexTxt`. Import them from `@getvitops/utils/onboarding`, where they were always defined. The
+  re-export tied the ad-platform capability table (imported by the generator and by Worker code) to the
+  Cloudflare network executors. `vitops` itself already imported them from `onboarding`.
+
+  Other packages in the `fixed` group: No consumer-facing change in this package.
+
+### Patch Changes
+
+- 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.
+
+- Updated dependencies [89265af]
+- Updated dependencies [7fd5f8f]
+  - @getvitops/config@8.2.0
+
 ## 8.2.0-alpha.0
 
 ### Minor Changes
@@ -14,7 +398,7 @@
 
   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`
+  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.
 
@@ -59,8 +443,8 @@ timeoutMs? }`); credentials arrive as a function of `locals`, exactly like the e
   tailwind outputs are unaffected.
 
 - 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
+  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
@@ -107,7 +491,7 @@ designSystemEditor: { config } })` (`config` is your `site.json`, e.g. `import c
 
   `vitops email setup [domain]` onboards a sending domain (currently Cloudflare Email Sending only)
   and polls DNS until its SPF/DKIM/DMARC records resolve or a timeout is reached; `vitops email
-check` is the non-blocking deploy guard both `@getvitops/create` templates' `deploy`/`deploy:dev`
+  check` is the non-blocking deploy guard both `@getvitops/create` templates' `deploy`/`deploy:dev`
   scripts now run first (`--strict` makes it a real gate; opt out per-site with
   `site.notifications.email.verifySender: false`, or globally with `--skip` /
   `VITOPS_SKIP_EMAIL_CHECK`).
@@ -119,7 +503,7 @@ check` is the non-blocking deploy guard both `@getvitops/create` templates' `dep
     from the onboarded subdomain — rather than silently trying to onboard the apex, which rewrites
     `_dmarc.<domain>` and can tighten DMARC policy on every other mail your domain sends.
   - Candidates come from `site.notifications.email.from` (or its derived `noreply@<domains
-.canonical>` default) first; a best-effort scan of `--src` only supplements it, and never guesses
+    .canonical>` default) first; a best-effort scan of `--src` only supplements it, and never guesses
     at a computed `from` value.
 
   New `@getvitops/utils/email` subpath and `site.notifications.email.verifySender` config field.
@@ -151,8 +535,8 @@ check` is the non-blocking deploy guard both `@getvitops/create` templates' `dep
   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
-}`.
+  '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
@@ -218,7 +602,7 @@ check` is the non-blocking deploy guard both `@getvitops/create` templates' `dep
     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.
+    <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).
@@ -432,7 +816,7 @@ check` is the non-blocking deploy guard both `@getvitops/create` templates' `dep
   It is **required for a user credential and wrong for a service account**, which is why it is not
   sent unconditionally. A user credential authenticates through a shared OAuth client that owns no
   project, so Google refuses the call outright — measured: `403 "requires a quota project, which is
-not set by default"`. A service account already belongs to a project, and pointing it at a
+  not set by default"`. A service account already belongs to a project, and pointing it at a
   different one would newly require `serviceusage.services.use` there, turning a working CI
   credential into a 403 for no benefit.
 
@@ -457,7 +841,7 @@ not set by default"`. A service account already belongs to a project, and pointi
   **Fixed: an ADC file in `GOOGLE_APPLICATION_CREDENTIALS` no longer hard-exits.** That variable is
   Google's own convention _and_ where gcloud writes ADC, so the same variable carries two kinds of
   credential. Parsing an `authorized_user` file as a service account failed with `service account
-JSON is missing client_email or private_key` — while holding a credential the command already knew
+  JSON is missing client_email or private_key` — while holding a credential the command already knew
   how to use. It is now discriminated on `type`, the field Google's own libraries switch on.
 
   **Also fixed — `search setup --dry` and `--check` are not offline.** The docs implied otherwise. The
@@ -794,28 +1178,20 @@ here changed, and no code that imports `@getvitops/utils` needs editing.
   {
     "designSystem": {
       "themes": {
-        "default": {
-          /* … */
-        },
+        "default": {/* … */},
       },
     },
     "organization": {
       "name": "Acme",
       "contact": "hq",
       "locations": {
-        "hq": {
-          /* … */
-        },
+        "hq": {/* … */},
       },
     },
     "site": {
       "defaultLocale": "en",
-      "domains": {
-        /* … */
-      },
-      "analytics": {
-        /* … */
-      },
+      "domains": {/* … */},
+      "analytics": {/* … */},
     },
   }
   ```
@@ -950,7 +1326,7 @@ here changed, and no code that imports `@getvitops/utils` needs editing.
   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

package/dist/{adc-D6aw2qgq.mjs → adc-BiW9BzqA.mjs}

@@ -1,4 +1,4 @@
-//#region src/google/adc.ts
+// src/google/adc.ts
 /** A parsed ADC user credential, or `undefined` if `raw` is not one. */
 function parseAdcUser(raw) {
 	let parsed;
@@ -40,6 +40,5 @@ function adcCredentialsPath(opts) {
 	return home ? join(home, ".config", "gcloud", "application_default_credentials.json") : void 0;
 }
 
-//#endregion
 export { adcQuotaProject as n, parseAdcUser as r, adcCredentialsPath as t };
-//# sourceMappingURL=adc-D6aw2qgq.mjs.map
+//# sourceMappingURL=adc-BiW9BzqA.mjs.map

package/dist/{adc-D6aw2qgq.mjs.map → adc-BiW9BzqA.mjs.map}

@@ -1 +1 @@
-{"version":3,"file":"adc-D6aw2qgq.mjs","names":[],"sources":["../src/google/adc.ts"],"sourcesContent":["/**\n * Application Default Credentials — recognising a credential gcloud already wrote.\n *\n * `gcloud auth application-default login` writes\n * `{ client_id, client_secret, refresh_token, type: \"authorized_user\" }`, which maps\n * field-for-field onto the refresh-token grant this package already performs. So the\n * only thing that ever stood between \"I'm logged in to gcloud\" and `vitops search`\n * was recognising the shape.\n *\n * Pure, and here rather than in the CLI, for the reason the consent store and the\n * indexing planner are: the decidable part (is this a user credential? where would\n * gcloud have put it?) is worth asserting without a filesystem, and the CLI keeps\n * only the `readFileSync`. `type` is the discriminator Google's own libraries switch\n * on — never the presence of fields, since a service-account JSON also has a `type`.\n */\nimport type { GoogleOAuth } from './token.ts';\n\n/** A parsed ADC user credential, or `undefined` if `raw` is not one. */\nexport function parseAdcUser(raw: string): GoogleOAuth | undefined {\n  let parsed: {\n    type?: string;\n    client_id?: string;\n    client_secret?: string;\n    refresh_token?: string;\n  };\n  try {\n    parsed = JSON.parse(raw) as typeof parsed;\n  } catch {\n    return undefined;\n  }\n  if (parsed.type !== 'authorized_user') return undefined;\n  // A truncated or half-written file is not a credential. Returning a partial one\n  // would defer the failure to a token exchange whose error names the wrong cause.\n  if (!parsed.client_id || !parsed.client_secret || !parsed.refresh_token) return undefined;\n  return {\n    clientId: parsed.client_id,\n    clientSecret: parsed.client_secret,\n    refreshToken: parsed.refresh_token,\n  };\n}\n\n/** The quota project gcloud recorded with an ADC credential, if any. */\nexport function adcQuotaProject(raw: string): string | undefined {\n  try {\n    return (JSON.parse(raw) as { quota_project_id?: string }).quota_project_id || undefined;\n  } catch {\n    return undefined;\n  }\n}\n\n/**\n * Where gcloud keeps ADC when nothing points at it explicitly.\n *\n * Reading the well-known path is what makes \"I'm logged in\" mean something, instead\n * of asking the user to export a variable at a file gcloud already wrote.\n * `CLOUDSDK_CONFIG` wins if set, as it does for gcloud itself.\n *\n * Every input is a parameter so the platform branches are testable on one machine.\n */\nexport function adcCredentialsPath(opts: {\n  env: Record<string, string | undefined>;\n  platform: string;\n  home: string | undefined;\n  join: (...parts: string[]) => string;\n}): string | undefined {\n  const { env, platform, home, join } = opts;\n  const sdk = env.CLOUDSDK_CONFIG;\n  if (sdk) return join(sdk, 'application_default_credentials.json');\n  if (platform === 'win32') {\n    return env.APPDATA\n      ? join(env.APPDATA, 'gcloud', 'application_default_credentials.json')\n      : undefined;\n  }\n  return home ? join(home, '.config', 'gcloud', 'application_default_credentials.json') : undefined;\n}\n"],"mappings":";;AAkBA,SAAgB,aAAa,KAAsC;CACjE,IAAI;CAMJ,IAAI;EACF,SAAS,KAAK,MAAM,GAAG;CACzB,QAAQ;EACN;CACF;CACA,IAAI,OAAO,SAAS,mBAAmB,OAAO;CAG9C,IAAI,CAAC,OAAO,aAAa,CAAC,OAAO,iBAAiB,CAAC,OAAO,eAAe,OAAO;CAChF,OAAO;EACL,UAAU,OAAO;EACjB,cAAc,OAAO;EACrB,cAAc,OAAO;CACvB;AACF;;AAGA,SAAgB,gBAAgB,KAAiC;CAC/D,IAAI;EACF,OAAQ,KAAK,MAAM,GAAG,CAAC,CAAmC,oBAAoB;CAChF,QAAQ;EACN;CACF;AACF;;;;;;;;;;AAWA,SAAgB,mBAAmB,MAKZ;CACrB,MAAM,EAAE,KAAK,UAAU,MAAM,SAAS;CACtC,MAAM,MAAM,IAAI;CAChB,IAAI,KAAK,OAAO,KAAK,KAAK,sCAAsC;CAChE,IAAI,aAAa,SACf,OAAO,IAAI,UACP,KAAK,IAAI,SAAS,UAAU,sCAAsC,IAClE;CAEN,OAAO,OAAO,KAAK,MAAM,WAAW,UAAU,sCAAsC,IAAI;AAC1F"}
+{"version":3,"file":"adc-BiW9BzqA.mjs","names":[],"sources":["../src/google/adc.ts"],"sourcesContent":["/**\n * Application Default Credentials — recognising a credential gcloud already wrote.\n *\n * `gcloud auth application-default login` writes\n * `{ client_id, client_secret, refresh_token, type: \"authorized_user\" }`, which maps\n * field-for-field onto the refresh-token grant this package already performs. So the\n * only thing that ever stood between \"I'm logged in to gcloud\" and `vitops search`\n * was recognising the shape.\n *\n * Pure, and here rather than in the CLI, for the reason the consent store and the\n * indexing planner are: the decidable part (is this a user credential? where would\n * gcloud have put it?) is worth asserting without a filesystem, and the CLI keeps\n * only the `readFileSync`. `type` is the discriminator Google's own libraries switch\n * on — never the presence of fields, since a service-account JSON also has a `type`.\n */\nimport type { GoogleOAuth } from './token.ts';\n\n/** A parsed ADC user credential, or `undefined` if `raw` is not one. */\nexport function parseAdcUser(raw: string): GoogleOAuth | undefined {\n  let parsed: {\n    type?: string;\n    client_id?: string;\n    client_secret?: string;\n    refresh_token?: string;\n  };\n  try {\n    parsed = JSON.parse(raw) as typeof parsed;\n  } catch {\n    return undefined;\n  }\n  if (parsed.type !== 'authorized_user') return undefined;\n  // A truncated or half-written file is not a credential. Returning a partial one\n  // would defer the failure to a token exchange whose error names the wrong cause.\n  if (!parsed.client_id || !parsed.client_secret || !parsed.refresh_token) return undefined;\n  return {\n    clientId: parsed.client_id,\n    clientSecret: parsed.client_secret,\n    refreshToken: parsed.refresh_token,\n  };\n}\n\n/** The quota project gcloud recorded with an ADC credential, if any. */\nexport function adcQuotaProject(raw: string): string | undefined {\n  try {\n    return (JSON.parse(raw) as { quota_project_id?: string }).quota_project_id || undefined;\n  } catch {\n    return undefined;\n  }\n}\n\n/**\n * Where gcloud keeps ADC when nothing points at it explicitly.\n *\n * Reading the well-known path is what makes \"I'm logged in\" mean something, instead\n * of asking the user to export a variable at a file gcloud already wrote.\n * `CLOUDSDK_CONFIG` wins if set, as it does for gcloud itself.\n *\n * Every input is a parameter so the platform branches are testable on one machine.\n */\nexport function adcCredentialsPath(opts: {\n  env: Record<string, string | undefined>;\n  platform: string;\n  home: string | undefined;\n  join: (...parts: string[]) => string;\n}): string | undefined {\n  const { env, platform, home, join } = opts;\n  const sdk = env.CLOUDSDK_CONFIG;\n  if (sdk) return join(sdk, 'application_default_credentials.json');\n  if (platform === 'win32') {\n    return env.APPDATA\n      ? join(env.APPDATA, 'gcloud', 'application_default_credentials.json')\n      : undefined;\n  }\n  return home ? join(home, '.config', 'gcloud', 'application_default_credentials.json') : undefined;\n}\n"],"mappings":";;AAkBA,SAAgB,aAAa,KAAsC;CACjE,IAAI;CAMJ,IAAI;EACF,SAAS,KAAK,MAAM,GAAG;CACzB,QAAQ;EACN;CACF;CACA,IAAI,OAAO,SAAS,mBAAmB,OAAO;CAG9C,IAAI,CAAC,OAAO,aAAa,CAAC,OAAO,iBAAiB,CAAC,OAAO,eAAe,OAAO;CAChF,OAAO;EACL,UAAU,OAAO;EACjB,cAAc,OAAO;EACrB,cAAc,OAAO;CACvB;AACF;;AAGA,SAAgB,gBAAgB,KAAiC;CAC/D,IAAI;EACF,OAAQ,KAAK,MAAM,GAAG,CAAC,CAAmC,oBAAoB;CAChF,QAAQ;EACN;CACF;AACF;;;;;;;;;;AAWA,SAAgB,mBAAmB,MAKZ;CACrB,MAAM,EAAE,KAAK,UAAU,MAAM,SAAS;CACtC,MAAM,MAAM,IAAI;CAChB,IAAI,KAAK,OAAO,KAAK,KAAK,sCAAsC;CAChE,IAAI,aAAa,SACf,OAAO,IAAI,UACP,KAAK,IAAI,SAAS,UAAU,sCAAsC,IAClE;CAEN,OAAO,OAAO,KAAK,MAAM,WAAW,UAAU,sCAAsC,IAAI;AAC1F"}

package/dist/{adc-BoEoogyo.d.mts → adc-DvX3-P7a.d.mts}

@@ -1,5 +1,4 @@
-import { i as GoogleOAuth } from "./token-DmmoQ7um.mjs";
-//#region src/google/adc.d.ts
+import { i as GoogleOAuth } from "./token-CHR1O4w5.mjs";
 /** A parsed ADC user credential, or `undefined` if `raw` is not one. */
 declare function parseAdcUser(raw: string): GoogleOAuth | undefined;
 /** The quota project gcloud recorded with an ADC credential, if any. */
@@ -19,6 +18,5 @@ declare function adcCredentialsPath(opts: {
   home: string | undefined;
   join: (...parts: string[]) => string;
 }): string | undefined;
-//#endregion
 export { adcQuotaProject as n, parseAdcUser as r, adcCredentialsPath as t };
-//# sourceMappingURL=adc-BoEoogyo.d.mts.map
+//# sourceMappingURL=adc-DvX3-P7a.d.mts.map

package/dist/adc-DvX3-P7a.d.mts.map

@@ -0,0 +1 @@
+{"version":3,"file":"adc-DvX3-P7a.d.mts","names":[],"sources":["../src/google/adc.ts"],"mappings":";;iBAkBgB,aAAa,cAAc;;iBAwB3B,gBAAgB;;;;;;;;;;iBAiBhB,mBAAmB;EACjC,KAAK;EACL;EACA;EACA,UAAU"}