@businessdash/sdk 0.9.81 → 0.9.90

package/README.md

@@ -1,6 +1,6 @@
 # `@businessdash/sdk`
 
-> Formerly published as `@biab-dev/sdk` (≤0.9.53) — same API, new name.
+> Formerly published as `@businessdash/sdk` (≤0.9.53) — same API, new name.
 
 **Alpha — 0.9.53.** This package declares, validates, and orchestrates your application's database schema, form layout, and type-safe field rules in a single declarative pipeline — and ships the answer-engine surface (llms.txt + product feed, MCP connector proxy, AI-crawler analytics) that makes the site you build with it legible to AI assistants.
 
@@ -425,8 +425,8 @@ the org curates it. `@businessdash/sdk/distribution` proxies the two together:
 import { llmsTxtHandler } from '@businessdash/sdk/distribution'
 
 export const GET = llmsTxtHandler({
-  siteId: process.env.BIAB_SITE_ID!,
-  baseUrl: process.env.NEXT_PUBLIC_BIAB_APP_URL!, // e.g. https://www.biab.app
+  siteId: process.env.BD_SITE_ID!,
+  baseUrl: process.env.NEXT_PUBLIC_BD_APP_URL!, // e.g. https://www.biab.app
 })
 ```
 
@@ -434,7 +434,7 @@ export const GET = llmsTxtHandler({
   domain root, with a 5-minute `s-maxage` + `stale-while-revalidate`. An
   upstream 404 (feed disabled or entitlement lapsed) passes through untouched;
   network failure returns a plain 503 — it never throws into the framework.
-- **`productFeedUrl(options)` / `llmsTxtUrl(options)`** build the public BIAB
+- **`productFeedUrl(options)` / `llmsTxtUrl(options)`** build the public BD
   feed URLs. The product feed needs no proxy — submit its BusinessDash URL directly to
   merchant/feed programs; `productFeedUrl` builds it for display/submission.
 
@@ -453,15 +453,15 @@ so the URL an org hands to Claude / ChatGPT / Gemini is their own site:
 // app/api/mcp/route.ts
 import { mcpHandler } from '@businessdash/sdk/mcp'
 export const { POST, GET } = mcpHandler({
-  siteId: process.env.BIAB_SITE_ID!,
-  baseUrl: process.env.NEXT_PUBLIC_BIAB_APP_URL!, // https://www.biab.app
+  siteId: process.env.BD_SITE_ID!,
+  baseUrl: process.env.NEXT_PUBLIC_BD_APP_URL!, // https://www.biab.app
 })
 
 // app/.well-known/mcp.json/route.ts
 import { mcpManifestHandler } from '@businessdash/sdk/mcp'
 export const GET = mcpManifestHandler({
-  siteId: process.env.BIAB_SITE_ID!,
-  baseUrl: process.env.NEXT_PUBLIC_BIAB_APP_URL!,
+  siteId: process.env.BD_SITE_ID!,
+  baseUrl: process.env.NEXT_PUBLIC_BD_APP_URL!,
 })
 ```
 
@@ -477,7 +477,7 @@ export const GET = mcpManifestHandler({
 ## AI-Crawler Visibility (AEO Analytics)
 
 AI crawlers (GPTBot, ClaudeBot, PerplexityBot, …) fetch your HTML without
-executing JavaScript, so `<BIABAnalytics />` never sees them. Your server does
+executing JavaScript, so `<BDAnalytics />` never sees them. Your server does
 — report them from middleware via `@businessdash/sdk/analytics-server`:
 
 ```ts
@@ -489,9 +489,9 @@ export function middleware(request: Request) {
   if (isAiCrawlerUserAgent(ua)) {
     // Fire-and-forget — never block or fail the crawler's request.
     void reportAiCrawlerHit({
-      siteId: process.env.BIAB_SITE_ID!,
-      baseUrl: process.env.NEXT_PUBLIC_BIAB_API_URL!,
-      apiKey: process.env.NEXT_PUBLIC_BIAB_PUBLISHABLE_KEY!,
+      siteId: process.env.BD_SITE_ID!,
+      baseUrl: process.env.NEXT_PUBLIC_BD_API_URL!,
+      apiKey: process.env.NEXT_PUBLIC_BD_PUBLISHABLE_KEY!,
       userAgent: ua,
       path: new URL(request.url).pathname,
     });
@@ -499,7 +499,7 @@ export function middleware(request: Request) {
 }
 ```
 
-Read it back with `biab.site(siteId).analytics.aiVisibility({ days: 30 })` —
+Read it back with `bd.site(siteId).analytics.aiVisibility({ days: 30 })` —
 per-crawler fetch counts, distinct pages read, vendor, intent
 (`training` / `search` / `user`), and last-seen timestamps. Branch on
 `.available`; same plan gating as `pageViews()`.
@@ -517,27 +517,27 @@ per-crawler fetch counts, distinct pages read, vendor, intent
 | `@businessdash/sdk/forms` | Form layout + runtime — `layoutContainers`, `createFormSchemaOrchestrator()`, `createSingleResourceForm()`, controller, formula engine |
 | `@businessdash/sdk/static` | Static data — `Enums()`, enum types |
 | `@businessdash/sdk/react` | React bindings — **the full UI surface**: forms, chat, auth, storefront, cart, checkout, blog, customer portal, marketing pages, followers, social links, verification |
-| `@businessdash/sdk/vue` | Vue binding — `<BiabForm>` + shared client |
-| `@businessdash/sdk/svelte` | Svelte binding — `<BiabForm>` + shared client |
-| `@businessdash/sdk/solid` | Solid binding — `<BiabForm>` + shared client |
-| `@businessdash/sdk/qwik` | Qwik binding — `<BiabForm>` |
-| `@businessdash/sdk/angular` | Angular binding — `<biab-form>` component + shared client |
-| `@businessdash/sdk/element` | `<biab-form>` custom element — drop-in web component |
-| `@businessdash/sdk/vanilla` | Framework-free imperative DOM binding — `mountBiabForm()` |
-| `@businessdash/sdk/react-analytics` | `<BIABAnalytics />` — browser page-view tracker for React |
+| `@businessdash/sdk/vue` | Vue binding — `<BdForm>` + shared client |
+| `@businessdash/sdk/svelte` | Svelte binding — `<BdForm>` + shared client |
+| `@businessdash/sdk/solid` | Solid binding — `<BdForm>` + shared client |
+| `@businessdash/sdk/qwik` | Qwik binding — `<BdForm>` |
+| `@businessdash/sdk/angular` | Angular binding — `<bd-form>` component + shared client |
+| `@businessdash/sdk/element` | `<bd-form>` custom element — drop-in web component |
+| `@businessdash/sdk/vanilla` | Framework-free imperative DOM binding — `mountBdForm()` |
+| `@businessdash/sdk/react-analytics` | `<BDAnalytics />` — browser page-view tracker for React |
 | `@businessdash/sdk/react-attribution` | "Powered by BusinessDash" attribution badge |
-| `@businessdash/sdk/analytics-core` | Framework-agnostic analytics core — `initBiabAnalytics()` |
+| `@businessdash/sdk/analytics-core` | Framework-agnostic analytics core — `initBdAnalytics()` |
 | `@businessdash/sdk/analytics-server` | Server-side AEO reporting — `isAiCrawlerUserAgent()`, `reportAiCrawlerHit()` |
 | `@businessdash/sdk/distribution` | llms.txt proxy + feed URLs — `llmsTxtHandler()`, `productFeedUrl()`, `llmsTxtUrl()` |
 | `@businessdash/sdk/mcp` | MCP connector proxy — `mcpHandler()`, `mcpManifestHandler()` |
-| `@businessdash/sdk/proxy` | `BiabDevClient` / customer-portal client re-exports for proxy setups |
+| `@businessdash/sdk/proxy` | `BdApiClient` / customer-portal client re-exports for proxy setups |
 | `@businessdash/sdk/seo` | JSON-LD builders — `localBusiness()`, `product()`, … |
 | `@businessdash/sdk/data-model-schema` | `defineDataModel` — org custom database (tables + enums) as code |
 | `@businessdash/sdk/alpha` | Legacy/deprecated pre-0.9 schema API, re-exported for compatibility |
 | `@businessdash/sdk/marketing-schema` | `defineSiteMarketingSchema()` — schema-driven marketing-page flow |
 | `@businessdash/sdk/next/revalidate` | One-line Next.js route handler for BusinessDash revalidation webhooks |
 | `@businessdash/sdk/adapters/revalidate` | Framework-agnostic revalidation handler builder |
-| `@businessdash/sdk/biab-forms.css` | Default form stylesheet |
+| `@businessdash/sdk/bd-forms.css` | Default form stylesheet |
 
 ### Framework parity — read this before picking a stack
 
@@ -588,7 +588,7 @@ approval, so watch `reviewAwaitingModeration` rather than expecting it in
 **React remains ahead on `<ChatbotInline>`** — a rendered chat UI over the same
 shared controller.
 
-For anything a binding lacks, `BiabClient` from the root export is
+For anything a binding lacks, `BdClient` from the root export is
 framework-agnostic: `client.storefront()`, `client.cart()`,
 `client.customerPortal()` and the rest work anywhere JavaScript runs. You write
 the markup; the data layer is already there.
@@ -615,7 +615,7 @@ a native component.
 >
 > **0.8.x = schema-driven marketing flow.** Major surface bump (still
 > alpha). New entrypoints: `defineSiteMarketingSchema()`,
-> `@biab-dev/sdk/seo` for typed JSON-LD builders, and a `biab-dev` CLI.
+> `@businessdash/sdk/seo` for typed JSON-LD builders, and a `bd` CLI.
 >
 > **0.9.x = full programmatic consumer surface.** The largest expansion
 > yet: native storefront / cart / checkout / coupons / subscriptions,
@@ -623,23 +623,104 @@ a native component.
 > `<SignIn/>` `<SignUp/>` `<SignOut/>` `useUser`), blog, a paginated
 > reviews wall, address autocomplete + shipping, programmatic local SEO
 > (`defineParallelPage()`), the revalidation webhook channel
-> (`@biab-dev/sdk/next/revalidate` + `@biab-dev/sdk/adapters/revalidate`),
-> privacy-conscious analytics (`@biab-dev/sdk/react-analytics` +
-> `@biab-dev/sdk/analytics-core`), and a three-state billing-lifecycle
+> (`@businessdash/sdk/next/revalidate` + `@businessdash/sdk/adapters/revalidate`),
+> privacy-conscious analytics (`@businessdash/sdk/react-analytics` +
+> `@businessdash/sdk/analytics-core`), and a three-state billing-lifecycle
 > degradation contract. Detailed per-version notes below.
 
 The 3 most recent releases are below. **For the complete release
 history, see the [changelog](https://www.biab.app/docs/developer/changelog).**
 
+### 0.9.90
+
+#### Every `Biab*` export is now `Bd*` — a breaking rename with no aliases
+
+`biab` was the old application name (Business In A Box). The product is
+BusinessDash, and the old name survived across the SDK's whole public
+surface long after that stopped being true.
+
+Renamed as a clean break rather than with a deprecation layer, because
+nothing outside this repo consumes these names yet. Waiting would only have
+made the alias layer larger.
+
+```
+BiabDevClient          -> BdApiClient      (the HTTP transport)
+BiabClient             -> BdClient         (the composed client interface)
+BiabForm, BiabProvider -> BdForm, BdProvider
+BiabApiError and every other error class
+createBiabClient, initBiabAnalytics, mountBiabForm, getBiabEnv, …
+.biab-* CSS classes    -> .bd-*            (54 of them)
+BIAB_* env vars        -> BD_*
+@biab-dev/* packages   -> @businessdash/*
+```
+
+Two names needed a decision rather than a pattern. `BiabClient` (the
+interface a consumer holds) and `BiabDevClient` (the HTTP transport under it)
+would both have become `BdClient`; the interface keeps the plain name and the
+transport is now **`BdApiClient`**.
+
+**Upgrading.** Every rename is mechanical — a find-and-replace of `Biab` to
+`Bd` and `biab` to `bd` covers all of it except `BiabDevClient`, which
+becomes `BdApiClient`. If you style the form components, the CSS hooks moved
+from `.biab-*` to `.bd-*` in the same way.
+
+**`./biab-forms.css` still resolves.** The stylesheet subpath is exported
+under both names, so a stylesheet import does not have to move in lockstep
+with the code.
+
+Three things deliberately did NOT change. `biab.app` is the API host and is
+served forever. The `biab.app/schemas/*` URLs are JSON-Schema `$id`s —
+identifiers rather than addresses — so changing one would break validation
+for anything pinned to it. And the historical note that this was formerly
+Business In A Box stays true.
+
+#### Proposals: the document a customer is sent, not just the quote
+
+`customerProposalSchema`, `listProposals()` and `getProposal()`.
+
+A proposal is the document built around a quote — either a rendered PDF or a
+live page — and `kind` tells you which, so a UI can offer a download or frame
+a page rather than guessing and being wrong half the time. Only rendered
+proposals appear: before that it is a rep's working copy, possibly at a price
+nobody has agreed, and a customer refreshing the list should not watch it
+take shape.
+
+It carries no template, bindings or resolved snapshot. Those describe how an
+org builds proposals; a customer's client has no business reading them.
+
+#### The customer quote detail carries the proposal narrative
+
+`customerQuoteDetailSchema` was dropping `sections` — the cover letter, scope
+of work and terms that make a quote a proposal — so a consumer could fetch
+one and receive only line items. It now carries them, along with the decision
+state (`canAccept`, `expired`, and the sent/accepted/rejected timestamps) so
+a client does not have to re-derive whether accepting is still possible.
+
+`items` was `z.array(z.unknown())`. It is typed now: no consumer should have
+to guess a line item's shape before rendering a row.
+
+#### React's marketing pages run on the shared core
+
+`useMarketingPage`, `useMarketingPagesList` and `useMarketingPagePreloader`
+reimplemented the fetch, the status flag and the in-flight guard that
+`marketing-core` already had, so a fix in the core never reached React. They
+are thin shells over `createMarketingController` now, with the
+snapshot-to-view derivation moved into the core as `marketingPageView()` and
+`marketingListView()` for every binding to share.
+
+Public signatures are unchanged. The synchronous cache read stays in React,
+because the controller does not duplicate the client's cache and without that
+read an already-cached page flashes "loading".
+
 ### 0.9.81
 
-#### The `createBiabClient` facade serves the legal and sitemap routes
+#### The `createBdClient` facade serves the legal and sitemap routes
 
 The facade lacked `legal` and `site`, so any starter handing it to
 `resolveLegalPage()` or `buildSitemap()` failed to typecheck against the
 published package — the template fleet caught T3-App, Qwik and Svelte on
 0.9.80. `client.legal` and `client.site(siteId)` now exist on the facade,
-mirroring the raw `BiabDevClient`, and compile-time contract guards in
+mirroring the raw `BdApiClient`, and compile-time contract guards in
 `sdk.ts` fail `typecheck` if a helper-required surface is ever dropped
 again.
 
@@ -662,7 +743,7 @@ on TS 5.7+ — consumers whose toolchains typecheck the shipped source
 
 #### Tracking consent — `@businessdash/sdk/consent`
 
-There was no consent mechanism anywhere: `initBiabAnalytics()` started
+There was no consent mechanism anywhere: `initBdAnalytics()` started
 unconditionally and analytics, attribution and AEO all collected regardless.
 
 `loadConsent()` returns what a visitor currently allows, at THIS org, and
@@ -670,11 +751,11 @@ unconditionally and analytics, attribution and AEO all collected regardless.
 
 ```ts
 const consent = await loadConsent({ client })
-if (consent.allows('analytics')) initBiabAnalytics({ siteId, baseUrl, apiKey })
+if (consent.allows('analytics')) initBdAnalytics({ siteId, baseUrl, apiKey })
 if (consent.mustAsk) showYourBanner(consent)
 ```
 
-`initBiabAnalytics` is deliberately NOT made to call this itself — a gate that
+`initBdAnalytics` is deliberately NOT made to call this itself — a gate that
 fires implicitly is one nobody can see in review, and what happens before
 consent (render nothing, render a placeholder, collect essential-only) is the
 site's decision, not ours.
@@ -693,874 +774,6 @@ incident.
 Also ships `client.consent.get()` / `.record()` as the transport underneath,
 and `browserOptOut()` for DNT and Global Privacy Control.
 
-### 0.9.70
-
-#### 3D product models — `@businessdash/sdk/model3d`
-
-Schema columns and a three.js viewer for `model3dUrl` / `model3dUsdzUrl` shipped
-in migration 0162 and reached the BusinessDash-hosted storefront only. Nothing
-was typed in the SDK, nothing was gated, and STEP was unsupported.
-
-`planProductModel()` decides which of three surfaces applies and hands back the
-facts. **No renderer ships** — three.js is ~600KB and `<model-viewer>` ~300KB,
-and the choice of engine should be yours.
-
-- **AR Quick Look** (`.usdz`) — an `<a rel="ar">` opens the model in the room on
-  iOS/iPadOS/visionOS with no JavaScript at all. Feature-detected via
-  `relList.supports("ar")` rather than user-agent sniffing.
-- **Web viewer** (`.glb`/`.gltf`/`.obj`/`.stl`) — `neutralMaterial` flags the
-  geometry-only formats, which render as a black silhouette in a viewer that
-  lights them like a `.glb`.
-- **CAD download** (`.step`/`.iges`) — deliberately not rendered. STEP needs a
-  geometry kernel, and the browser WASM builds are 10–30MB. It is also the wrong
-  shape for who asks: an engineer wants the file in their own CAD package.
-
-Gated behind the new `ecommerce.product_3d` add-on (bundled at Scale). The gate
-is PARTIAL — an unentitled org's products still return, minus four fields.
-Failing the whole request would take a catalog offline over a lapsed $5.
-
-The CAD URL never appears in a payload. `client.storefront.getCadDownload(id)`
-issues it from a route that requires a `biab_cad` cookie, rate-limits 10/min per
-IP, and re-checks the entitlement — a catalog of naked URLs is a machine shop's
-design library published to anyone willing to write a loop.
-
-#### Legal pages — `@businessdash/sdk/legal`
-
-Privacy policy, terms and refund policy written once in the dashboard and served
-on the org's own domain. The SDK never claims a literal path: it exposes a
-resolver for a catch-all, and every file-based framework resolves a static
-segment first — so your own `/privacy` shadows ours with no build conflict.
-
-#### Sitemaps — `@businessdash/sdk/sitemap`
-
-`buildSitemap()` merges your own routes, what the platform owns the shape of,
-and platform content mapped onto paths you declare. Opt-in per content type:
-declare nothing and nothing is emitted, which is right for a business without
-that surface. Never emits the customer portal or other token-gated paths.
-
-#### Browser push — `@businessdash/sdk/push-core` and `/notifications`
-
-`enablePush()` handles the whole service-worker dance; `createNotificationFeed()`
-gives one handler for every notification, deduplicated across push and polling,
-with no toast UI of its own.
-
-#### Scheduling and conference calls on the main client
-
-Booking lived on `sdk.ts`'s separate scheduling resource. The OpenAPI generator
-reads `client.ts`, so it never saw any of it: all seven scheduling routes sat in
-the recorded spec gap, and no non-JS starter had scheduling at all.
-
-`client.site(siteId).scheduling` now covers event types, slots, booking, and
-reading/rescheduling/cancelling with the invitee's signed token — plus a new
-**staff** path (`rescheduleBookingAsStaff` / `cancelBookingAsStaff`) so an org
-can move a booking with its API key rather than a token from someone's email.
-
-Both sides call the same service, which is what keeps them honest: the invitee
-**and every host** are notified either way, the reminders queued against the old
-time are cancelled either way, and the booking records which side changed it.
-`actorUserId` is what lets a customer's history say "they rescheduled" rather
-than leaving an unexplained change.
-
-The staff route needs `scheduling:write`, mapped to the same `scheduling.manage`
-permission the dashboard requires and deliberately **not publishable** — a
-browser token able to cancel any booking by id would let anyone reading the page
-source cancel every meeting the org has.
-
-Two generator bugs surfaced while wiring this up, both the same class as the
-nested-template one fixed earlier: it could not see paths built through a
-`this.path()` helper, and it was letting query strings leak into path templates
-(`bookings/{token}?type={type}` was being emitted as a path). Both fixed; the
-corrupt-path gate stays green and the recorded spec gap dropped from 39 routes
-to 33.
-
-All six non-JS starters gained the full surface, including both paths — parity
-is 19/19 each.
-
-
-#### SEO reaches the page, on every framework — `@businessdash/sdk/seo-core`
-
-The platform has always produced per-page SEO — every marketing page bundle
-carries title, description, canonical, `noIndex`, Open Graph, Twitter card,
-keywords, JSON-LD and hreflang. The SDK re-exported that as a TYPE and stopped
-there, so every consumer hand-mapped eleven fields into their framework's
-metadata shape, along with the fallbacks, the absolute-URL rules and the robots
-string.
-
-Eleven fields is enough that everyone does four. The two people skip are
-`noIndex` and `canonical` — the two where being wrong costs something and says
-nothing.
-
-**Layout and page compose.** Precedence runs layout defaults → the platform's
-page SEO → overrides in code, because a developer has context the CMS does not.
-An omitted field inherits; an explicit `null` clears. JSON-LD accumulates
-rather than replaces, since a layout's `Organization` node and a page's
-`Product` node both belong in the document.
-
-**Every framework, no framework imports.** `toNextMetadata`, `toRemixMeta`,
-`toNuxtHead`, `toQwikDocumentHead`, `toTanStackHead`, `toHeadTags`,
-`renderHeadTags` and `applyToDocument` each return the plain shape their
-framework expects, so the module works in all of them and depends on none.
-
-Two rules are enforced rather than left to the caller. A **relative canonical
-is dropped** instead of emitted — crawlers resolve it against whatever URL they
-fetched, and a wrong canonical consolidates ranking onto the wrong page while a
-missing one is recoverable. And **`robots` is always emitted, both ways**,
-because absence means "index" and relying on absence to express `noindex` is
-how a hidden page gets published.
-
-#### SEO for blogs and storefronts
-
-`blogPostSeo` emits `BlogPosting` with dates, byline, tags and breadcrumbs, plus
-`og:type: article` and the `article:*` meta that make a shared link render as a
-dated card rather than a bare URL.
-
-**Gated posts stay indexed and say so.** A subscriber-only post should be
-findable — discoverability is how anyone subscribes — but serving the full
-article to a crawler and a paywall to a reader is cloaking. So a gated post
-carries schema.org's paywall markup (`isAccessibleForFree: false` plus a
-`hasPart` naming the region), which declares the difference rather than hiding
-it. Anything not `public` counts as gated, including unrecognised access
-levels: failing the other way would declare open access for restricted content.
-
-`productListingSeo` emits `CollectionPage` + `ItemList`, and canonicalises
-filtered views to the unfiltered category — faceted URLs multiply into thousands
-of near-identical pages that eat crawl budget and split ranking.
-`transactionalPageSeo` keeps cart, checkout and order confirmations out of the
-index; confirmations have been indexed with customer details in the query
-string by more than one large retailer.
-
-`productPageSeo` gained `aggregateRating` and `AggregateOffer`. The rating is
-emitted **only** when `reviewCount > 0`, because an `AggregateRating` with zero
-reviews is invalid and Google rejects the whole Product node for it — a product
-with no reviews yet would lose its price and availability too.
-
-Archive and listing pages past the first are `noindex`: the posts and products
-are what should rank, and a thin page 7 competes with them.
-
-#### Local SEO: service areas × services, and products
-
-`servicesTimesAreas()` expands the Cartesian product into page plans, each with
-its own canonical and a `Service` node scoped with `areaServed` to that place.
-Without those two, near-identical pages are deduplicated away and the node is
-indistinguishable from the generic services page.
-
-`describe` is a callback rather than a template on purpose: pages differing only
-by a swapped town name are doorway pages, which are penalised rather than
-ranked. `include` skips combinations the org does not actually cover, so it does
-not rank for work it has to turn down.
-
-`productPageSeo()` emits `Product` + `Offer` + `BreadcrumbList`, money as
-integer cents. It pairs with the AI Distribution product feed — the feed gets
-the product into the engines' catalogues, this markup is what their crawlers
-verify on the landing page.
-
-All six non-JS starters gained the same surface, with the same rules. Swift's
-`JSONValue` gained `Encodable` on the way: it could decode the org's JSON-LD
-and had no way to render it back out.
-
-
-#### Subscriptions in the customer portal — and the entitlement check that was a stub
-
-`hasActiveSubscription()` returned `true`. For everyone. Every
-`accessLevel: "subscribers"` gate called it, so subscriber-only content was
-readable by anyone signed in.
-
-That was survivable while nothing was gated, and it stopped being survivable
-the moment the portal grew a surface that advertises "your subscriber content":
-a page promising an entitlement check that does not perform one is worse than
-no page. It now reads `user_subscriptions` for real. There were 0
-subscriptions, 0 offerings and 0 subscriber-gated posts in production when this
-landed, so switching it on changed nothing anyone could see — which is the
-cheapest possible moment to fix an access-control default.
-
-Three cases grant access, and two of them a `status === "active"` check gets
-wrong in the direction that takes something from a customer who paid:
-
-- **lifetime** has no period, so an expiry check must not be applied to it;
-- **cancelled but paid through** keeps access until the period ends;
-- `failed` (dunning) and `pending` (incomplete) do not grant — a payment that
-  has not succeeded has not bought anything.
-
-The rule lives in `subscription-access-rules.ts` with no database import, so it
-is unit-tested directly — the same split, for the same reason, as
-`connect-subscription-mapping.ts`.
-
-**The portal surface**: `getSubscription()` returns state plus the org's live
-offerings (a portal reporting "not subscribed" and nothing else is a dead end),
-`cancelSubscription()` / `resumeSubscription()`, and `getSubscriberContent()`.
-
-Cancelling ends the RENEWAL, not the access: `cancel_at_period_end` only, with
-`accessUntil` in the response. The customer paid for the period they are in,
-and ending access on the click is the most common way a subscription flow feels
-like a trap. The route deliberately writes no local status — the provider's
-webhook owns it, and racing that would leave the row disagreeing with the
-money — and the controller re-reads rather than guessing what the webhook will
-write.
-
-`getSubscriberContent()` answers "what am I actually getting for this?", which
-is the question asked right before someone cancels. When `entitled` is false it
-returns LOCKED previews rather than an empty list: titles and excerpts, never
-bodies. An empty list would hide the offer at exactly the moment it is most
-relevant.
-
-**Found while building it**: `org_blog_posts.access_level` is a TEXT column
-with two vocabularies written into it — `public|members|subscribers` by the
-gate and the create route, `public|followers|paid` by the public reads. Nothing
-reconciles or constrains them. Both subscriber spellings now gate and anything
-unrecognised gates too, because an access check must fail closed. Converging
-the column is a migration and a naming decision, not something to settle in a
-read path.
-
-All six non-JS starters gained the same four calls.
-
-
-#### Notification settings, per company
-
-A customer who buys from three businesses has three independent preference
-matrices — they are stored per `(org, customer)` and always have been. What did
-not exist was a way to reach more than one of them: `createPortalController`
-built its client once, pinned to the API key's org, for its whole life. A
-dashboard could LIST the customer's other companies and change nothing about
-them, so muting marketing email meant muting it for whichever company the
-portal happened to be pointed at.
-
-`loadNotificationPreferencesFor(orgId)` and
-`updateNotificationPreferencesFor(orgId, input)` close that, with
-`notificationPreferencesByOrg` on the snapshot keyed by org id — separate from
-this org's, so the current company renders without waiting on companies the
-customer has not expanded. Pinned clients are memoised per org, because a
-dashboard listing five companies would otherwise build one per render.
-
-Writes stay sparse and merged, and the controller stores what the server
-ANSWERED rather than what was sent: the server merges into the stored matrix,
-so echoing the request would show the customer a matrix it never agreed to.
-
-Every non-JS starter gained the same surface.
-
-#### Non-JS starters reach every surface — and are now measured
-
-Swift, Kotlin, Dart, PHP and Elixir consumers do not import this package; each
-starter carries a hand-written client. Nothing that keeps the JS bindings
-honest said anything about them, so they fell behind quietly and the only
-record of how far was an estimate that turned out to be wrong in both
-directions.
-
-Measured, then closed:
-
-| Starter | Before | After |
-|---|---|---|
-| Swift | 11/15 | **15/15** |
-| Phoenix | 12/15 | **15/15** |
-| Flutter | 11/15 | **15/15** |
-| Laravel | 11/15 | **15/15** |
-| Kotlin | 10/15 | **15/15** |
-| Vapor | 9/15 | **15/15** |
-
-The shared gap was social links and the two verification kinds — surfaces added
-to the JS side and never carried across. Laravel also lacked the chatbot;
-Kotlin, Flutter and Vapor lacked the customer portal; Vapor lacked customer
-auth; Kotlin lacked the data model.
-
-`non-js-parity.test.ts` measures this every run by matching **request paths**,
-the one thing six languages have in common — a Swift `func reviews(_ id:)` and
-an Elixir `product_reviews/2` share no convention, but both must contain
-`storefront/products`. The baseline may only grow.
-
-Two detector bugs were found and fixed while writing it, both the same shape:
-social links have no endpoint at all (they are derived from the branding
-bundle), and the two verification kinds share one endpoint separated by a
-`kind` field. Both would have reported "missing" forever no matter what anyone
-built. **A gate that cannot pass is worse than no gate** — it teaches people to
-ignore it.
-
-Full coverage means every surface is REACHABLE from every language. It does not
-mean the ergonomics match, and the gate cannot tell you that.
-
-#### The social-platform table is generated, not copied
-
-31 platforms — key, label, icon slug, URL prefix — emitted from
-`src/socials.ts` into all six languages by `pnpm gen:socials`, with
-`gen:socials:check` failing CI when they drift. Six hand-maintained copies
-would separate the first time a platform was added, and the copy that drifted
-would be whichever language nobody was using that week.
-
-The resolver around the table stays hand-written per language, because that is
-what a developer reads. Generate the data, hand-write the idiom — the same
-split the whole non-JS plan uses.
-
-
-#### Exchanges, "it never arrived", and verified-buyer product reviews
-
-Three gaps in the post-purchase surface, each of which the customer could
-experience but not report.
-
-**Exchanges.** A return request could only ask for money back. Customers asked
-for replacements in the free-text `reason`, where nothing could act on it — the
-org read prose, then refunded and re-ordered by hand. Return requests now carry
-`kind` (`refund` | `exchange`), plus the variant wanted and the shipment that
-eventually carries it. `portal.submitExchangeRequest()` routes through the same
-call as a return, because an exchange is a return request with a different ask
-rather than a separate flow. `kind` defaults to `refund`, so existing callers
-mean exactly what they meant. The staff notification now names the actual ask,
-since staff reaching for a refund when the customer wanted a replacement is the
-miscommunication the field exists to remove.
-
-**"It never arrived."** `portal.reportNotReceived(shipmentId)` records the
-claim — and deliberately does **not** touch the shipment's status.
-
-The carrier scanned the parcel delivered; the customer says otherwise. Both are
-facts, and the carrier's is the more valuable one right then: it is what the org
-disputes with, and what decides who absorbs the loss. Overwriting it would
-destroy that evidence, quietly redefine "delivered" as "delivered and
-undisputed" in the org's own analytics, and lose the race anyway — `status` is
-webhook-driven, so a customer-written value survives until the next carrier
-event and then looks like the report vanished.
-
-So the claim sits in its own columns and the result carries both sides, with
-`contested: true` when they disagree. A static gate now fails the build if that
-route ever assigns a carrier-owned field, because this is a mistake that arrives
-by refactor rather than by decision.
-
-**Product reviews.** The portal could review the ORG but not a PRODUCT, despite
-`org_product_reviews` already existing and the storefront already reading it.
-`submitProductReview` / `listProductReviews` close that, and require a matching
-order: the portal is standing inside the customer's purchase history, which the
-public storefront is not. Verified-buyer reviews are the ones worth surfacing,
-and it stops a competitor one-starring a catalogue they never bought. Approval
-comes from the org's own moderation policy — the same call the storefront makes,
-so an org that holds reviews does not find portal reviews bypassing it.
-
-
-#### The customer portal can list what a customer has, and talk to staff
-
-Invoices, quotes, contracts and shipments were **detail-by-id only**. Work
-carried the counts, so a customer could be told they had three unpaid invoices
-and had no call that would name them. "Show me everything I owe" was
-unanswerable without faking a list from repeated detail fetches, which is a
-different bug wearing a list's clothes.
-
-Four list routes close it: `loadInvoices({ unpaid })`,
-`loadQuotes({ status })`, `loadContracts({ status })` and
-`loadShipments({ active })`. `unpaid` filters on the computed **balance**, not
-the status string, because a partially-paid invoice still owes money whatever
-it is called. Shipments list **stored** carrier status; `trackShipment(id)`
-still spends a live carrier request, because that is one parcel the customer
-deliberately opened rather than every parcel in their history on every page
-load.
-
-Staff chat lands in the portal too — `loadMessages`, `postMessage`,
-`markMessagesRead`, with `unreadMessageCount` on the snapshot. Both directions
-write the same table the CRM timeline reads, so a customer's question appears
-beside everything else known about them instead of in a parallel inbox nobody
-opens.
-
-Return requests read back on the order, `resolutionNote` included: when staff
-deny a return, their reason *is* the answer, and withholding it turns a decision
-into silence.
-
-#### Products and blog posts can be seeded — the last two things you had to hand-enter
-
-Seeding could push a schema, its records, static collections and coupons. It
-could not create a **product** or a **blog post**, because no package-API route
-existed for either — the dashboard created them over tRPC. So an org could build
-its entire site from code and still had to hand-enter its catalogue, which made
-"seed your site" a half-answer precisely where the content mattered most.
-
-Two routes now exist, and `@businessdash/sdk/seed` exposes them as
-`seedProducts` and `seedBlogPosts`:
-
-- `POST storefront/products` — scope `storefront:write`. Takes the whole tree,
-  product plus variants plus cross-variants, and writes it in **one
-  transaction**. The dashboard does this in four dependent round trips; making
-  a seed script replay that means threading ids by hand with no way to recover
-  halfway through. Either the product exists complete, or it does not exist.
-- `POST blog/posts` — scope `blog:write`, a new scope that is deliberately
-  **not publishable**: authoring a post is an operator action, never something
-  a browser token should be able to do.
-
-Both create **unpublished** by default (`isLive` / `publishNow` are opt-in).
-A seed that silently pushed a half-configured catalogue to a live storefront —
-or drafts to every follower's inbox — is worse than one that needs a second,
-deliberate step.
-
-Products land in your own tables, **not in Stripe**. Pushing the catalogue to
-your Stripe account stays a separate explicit call, because it mints objects in
-an external account you are billed against and that should never be a side
-effect of a seed script.
-
-#### `businessdash seed` — one command for the whole seed
-
-```bash
-npx tsx node_modules/@businessdash/sdk/dist/cli.js seed [--dry-run] [--yes]
-```
-
-Reads `businessdash.seed.ts` and runs schema → records → collections →
-products → posts → coupons in dependency order. It calls the same `runSeed`
-the programmatic API exposes rather than reimplementing it, so CI and a Nuxt
-module behave identically — including the refusal on a destructive schema plan,
-which `--yes` overrides.
-
-#### Fixed: `seedTargetFromEnv()` read a variable nobody sets
-
-It looked for `BIAB_PACKAGE_API_KEY`. The CLI reads `BIAB_API_KEY`, and so does
-every starter's `.env.example` — all fifteen. A project whose CLI worked fine
-would fail to seed from a build step, and fail naming a variable the consumer
-had never seen. It now reads `BIAB_API_KEY` first and falls back to
-`NEXT_PUBLIC_BIAB_PACKAGE_API_BASE_URL` for the base URL, exactly as the CLI
-does. A test pins the two together.
-
-#### The MCP connector mounts on every framework
-
-`mcpHandler` returns Web-standard `(Request) => Promise<Response>`, which is
-right for Next, Astro, Remix and TanStack Start and wrong for everything else:
-SvelteKit hands you `{ request }`, Nitro an H3 event, Qwik City a `RequestEvent`
-you answer by *calling* `send()`, and Express Node's `req`/`res`. Four of eight
-frameworks had to work that out themselves, for a surface whose whole point is
-an org handing Claude or ChatGPT a URL on their own domain.
-
-`@businessdash/sdk/mcp-adapters` ships that bridging: `sveltekitMcpHandler`
-(aliased `astroMcpHandler`), `nitroMcpHandler`, `qwikMcpHandler` and
-`expressMcpHandler`, each with a manifest counterpart. Every one is a
-shape-change over the same handler — none reimplements the proxy, the error
-mapping or the manifest caching, so a fix lands everywhere at once. On Node the
-manifest origin is rebuilt from `Host` and `x-forwarded-proto`, because
-advertising the wrong domain is the one failure this surface cannot tolerate.
-
-#### `@businessdash/sdk/react` now carries its own `"use client"` boundary
-
-React Server Components frameworks treat a module without the directive as
-server code. `react.tsx` holds every stateful component in the SDK and did not
-have it, so importing `<BiabForm>` into a Next App Router page threw *"you're
-importing a component that needs useState"*. The only workaround was a
-hand-written `"use client"` wrapper per component — the Next starter in this
-repo carries sixteen of them.
-
-The directive is now on `react.tsx` and `react-marketing.tsx`, so components
-import directly into a server-rendered page. Every export in those files is
-browser-only anyway: the components hold state, and the four programmatic
-helpers (`signIn`, `signUp`, `signOut`, `requestPasswordReset`) each return
-early on `typeof window === "undefined"` because they navigate.
-
-Existing wrappers keep working — this removes the need for new ones, it does
-not invalidate old ones. Bundlers that don't implement the directive treat it
-as an inert string expression.
-
-#### Preact is supported, and verified rather than assumed
-
-`@businessdash/sdk/react` runs unmodified under Preact via the standard
-`preact/compat` alias, which means Preact gets the **full fourteen-capability
-surface** — not the forms-only subset every non-React binding has — for the
-cost of a bundler alias rather than a port.
-
-Two properties make it work, and both are now gated. The binding imports nine
-runtime symbols from `react` (`createContext`, `Fragment`, `useCallback`,
-`useContext`, `useEffect`, `useMemo`, `useRef`, `useState`,
-`useSyncExternalStore`), all present in `preact/compat`; and it never imports
-`react-dom`, so nothing pulls in React's reconciler.
-
-`test/preact-compat.test.ts` bundles the real source twice through esbuild —
-once against React, once with `react` aliased to `preact/compat` — renders the
-same trees on both and asserts identical markup, covering the pure-render path,
-the context path and the `useSyncExternalStore` subscription path. The only
-tolerated difference is inline-style serialisation (`margin:0` vs
-`margin:0px`), which computes identically.
-
-`preact` and `preact-render-to-string` are devDependencies; nothing new ships.
-
-#### The customer portal, natively, on every framework
-
-`@businessdash/sdk/portal` — `createPortalController` over the portal's 34
-methods: work, jobs, quotes, contracts, invoices, orders, downloads, shipping,
-reviews, referrals, profile and notification preferences. Until now the only
-way to render any of it was `<Dashboard>`, a hosted page in an iframe, so a
-business could not put their own customer portal on their own domain.
-
-Four properties of the surface shape the controller, all from the audit in
-`Resources/BIAB-Customer-Portal-SDK-Audit.md`:
-
-- **`sessionToken` is required.** Every route is scoped to the signed-in
-  customer, and without one the calls are unauthenticated — which fails quietly
-  enough to look like an empty portal rather than a signed-out one. The
-  controller takes the token up front and calls `withSession` itself.
-- **There are no list endpoints** for invoices, quotes, contracts or shipments.
-  `work` carries the counts and each opens by id. The controller does NOT fake
-  a list from repeated detail fetches; the gap stays visible where someone can
-  decide to close it in the API.
-- **Nothing can be deleted.** There is no delete action anywhere, because there
-  is none in the API — and a test asserts the controller never grows one.
-- **A submitted review is queued for moderation.** It is deliberately not added
-  to `reviews`; `reviewAwaitingModeration` is set instead, so a portal can say
-  "awaiting review" rather than implying it is live.
-
-Supporting detail never blanks the thing the customer asked for: a job renders
-even when its activity, ETA and comments all fail, and an order renders when it
-has no digital downloads (which most orders don't).
-
-#### Social links on every framework
-
-The last gap, and the only one that was never about logic — every binding
-already had `resolveSocialProfiles`. What was missing was markup, which cannot
-be shared the way a controller can.
-
-`@businessdash/sdk/social` shares everything up to the markup: the resolved
-rows, the icon URL and the handful of layout styles the list needs. Each
-binding writes the six elements around it — a render function for Vue (rather
-than an SFC, which would put it back outside the typechecker), a standalone
-component for Angular, an SFC for Svelte, JSX for React, Solid and Qwik, an
-imperative `mountSocialLinks` for plain DOM, and `<biab-social-links>` for the
-web-component entry.
-
-React and Solid were refactored onto it, so the CDN path and colour convention
-now live in one place rather than three.
-
-#### Marketing pages and verification on every framework
-
-Two final cores. Twelve of the fourteen capabilities are now native on all
-eight bindings, and Solid joins React at the full fourteen.
-
-**`@businessdash/sdk/marketing`** — `createMarketingController` holds the page
-index and loads one page at a time, because a site can have many marketing
-pages and a visitor reads one. `prefetch()` warms a page you expect next; its
-failures are swallowed, since a wrong guess must never surface as an error on
-the page actually being read.
-
-**`@businessdash/sdk/verify`** — `createVerifyController` is the email/phone
-state machine: request a token, confirm it, handle it being wrong. One
-controller serves both kinds; `kind` selects which.
-
-Two details the React components had buried and that are now explicit:
-
-- **`flow` is on the snapshot.** The server decides per request whether to send
-  a one-time code or an emailed link. A binding that assumes a code field would
-  leave every link-flow visitor staring at a box waiting for a code that is
-  never coming.
-- **A rejected code is retryable, not fatal.** The confirm endpoint answers
-  `{ ok: true }` or rejects, so a rejection is the ordinary wrong-code path: the
-  step stays `awaiting-code` and the visitor can try again.
-
-The resend cooldown lives in the controller rather than the binding. Left to
-eight bindings, one of them gets it wrong and a visitor can spam themselves
-with texts.
-
-#### Checkout, customer auth and followers on every framework
-
-Two more cores and bindings for all eight adapters, taking the count of
-capabilities every binding has natively from six to nine.
-
-**`@businessdash/sdk/checkout`** — `createCheckoutController` mints a Stripe
-session and resolves the outcome. `start()` deliberately does NOT navigate; it
-returns the session and leaves `redirect()` as a separate call, because the
-previous React component set `window.location.href` itself, which is fine in a
-browser and wrong in a native app, an SSR render or a test.
-
-`resolve(sessionId)` reads the payment status from the server. A `session_id`
-in the return URL proves the customer came back, not that they paid — that
-distinction is the point of the method and has its own test.
-
-**`@businessdash/sdk/account`** — `createUserController` (the signed-in
-customer, via the auth handler's `/me`, never an API key) and
-`createFollowersController` (subscribe/unsubscribe plus the local
-already-subscribed hint, which is a convenience for hiding a footer form and
-explicitly not authority — `me()` is).
-
-Sign-in / sign-up / sign-out are navigations rather than requests, so they ship
-as `signIn` / `signUp` / `signOut` plus `signInHref` / `signUpHref` /
-`signOutHref` for bindings that render their own links. All of them no-op
-outside a browser rather than throwing.
-
-React and Solid were REFACTORED onto these rather than left alone, so all eight
-bindings share one implementation. That removed 104 lines of hand-rolled fetch
-and local-storage handling from the Solid binding alone.
-
-#### Native blog on every framework — nothing is iframe-only any more
-
-`@businessdash/sdk/blog` — `createBlogController` owns the post list, paging,
-category filtering, the active post, comments and likes. Bindings on all eight
-adapters: React/Vue/Qwik `useBlog`, Solid/Svelte/Angular/vanilla/element
-`createBlog`.
-
-Blog was the last surface with no native path anywhere, React included — the
-worst place to lose control of markup, since the content is what readers and
-search engines came for and an iframe hides it.
-
-Two behaviours worth calling out, both tested:
-
-- **Posting a comment re-reads the thread instead of inserting locally.** A
-  comment may be held for moderation, and splicing a local copy in would show
-  its author an approved-looking comment nobody else can see.
-- **A likes outage never blanks the article.** Like state is fetched after the
-  post and its failure is swallowed, because a decoration must not take down
-  the thing it decorates.
-
-#### Every framework binding is now typechecked
-
-`@builder.io/qwik` is a devDependency and `tsconfig.qwik.json` checks the Qwik
-binding, which closes the last hole: Solid, Qwik, Vue, Svelte and Angular were
-all excluded from tsc and therefore never verified. `pnpm typecheck` runs four
-configs.
-
-Qwik's first run found two real pre-existing errors, both
-`exactOptionalPropertyTypes` violations where an optional JSX attribute was
-passed as `undefined` rather than omitted.
-
-#### Native storefront, cart and chat on EVERY framework
-
-Two new framework-agnostic cores, and a binding for each of the eight adapters.
-Storefront, cart and chat are no longer iframe-only anywhere.
-
-**`@businessdash/sdk/store`** — `createStoreController` owns products,
-pagination, category filtering, the product detail, the cart, quantities and
-coupons. Prices cross the boundary as integer minor units and are never
-divided, rounded or formatted by the controller.
-
-**`@businessdash/sdk/chat`** — `createChatController` owns the transcript,
-pending state, UI actions, availability and the human-escalation call. Lifted
-out of React's `useChatbot` rather than rewritten, so React's behaviour is
-preserved and now backs every other binding.
-
-Both follow the `createFormController` contract exactly: `snapshot()`,
-`subscribe()` (which does NOT replay), `destroy()`, and actions.
-
-Per-framework bindings, all thin views over those cores:
-
-| Framework | Storefront | Chat |
-|---|---|---|
-| React | `useStorefront` | `useChatbot` (now core-backed) |
-| Solid | `createStorefront` | `createChat` |
-| Vue | `useStorefront` | `useChat` |
-| Svelte | `createStorefront` | `createChat` |
-| Qwik | `useStorefront` | `useChat` |
-| Angular | `createStorefront` | `createChat` |
-| Vanilla / element | `createStorefront` | `createChat` |
-
-The vanilla binding is the controllers themselves — there is no reactivity
-system to bridge — which makes it the reference the other seven wrap.
-
-Qwik's controllers are wrapped in `noSerialize` and created inside
-`useVisibleTask$`. That is not stylistic: a controller holds a client, a
-subscriber set and timers, and Qwik would otherwise try to serialise it into
-the HTML on pause and throw.
-
-#### The parity gate now checks HOW a capability is delivered
-
-`capabilities` in `framework-support.ts` records `native`, `embed` or `both`
-per capability, and the gate derives the same levels from the source by reading
-implementations rather than export names. Recorded as booleans, an iframe
-wrapper looked identical to real components.
-
-It also asserts each binding REACHES the core behind every capability it claims
-— level-aware, so the iframe path requires `embed-protocol` and the native path
-requires `store-core` / `chat-core` — and that the postMessage origin check
-exists in exactly one file. A second, subtly weaker copy of that check would be
-a security bug affecting one framework's users only.
-
-#### Vue, Svelte and Angular headless bindings are typechecked
-
-Those bindings are excluded from the main tsconfig because of SFC and decorator
-syntax. Their new headless modules are plain `.ts`, so `tsconfig.headless.json`
-checks them properly; `pnpm typecheck` now runs the main, Solid and headless
-configs. It caught a real generic-inference bug on the first run: the
-snapshot type was resolving to `unknown`, which would have stripped types from
-every Vue and Angular consumer.
-
-#### Solid gains most of the product surface
-
-`@businessdash/sdk/solid` went from forms-only to eleven of fourteen surfaces:
-storefront, cart, checkout, blog, the customer portal, the chat widget, tenant
-auth, followers and social links, alongside the forms binding it already had.
-
-Most of that was cheap for a reason worth knowing: `Storefront`, `Cart`,
-`Checkout`, `Blog`, `Chatbot` and `Dashboard` are BusinessDash-hosted pages in a
-sandboxed iframe, in React exactly as in Solid. Two primitives —
-`createEmbedSession` and an internal `EmbedIframe` — carry all six, and each
-surface is a dozen lines on top of them.
-
-New Solid exports: `Storefront`, `Cart`, `Checkout`, `CheckoutResult`, `Blog`,
-`Chatbot`, `Dashboard`, `DashboardProvider`, `useDashboardSession`, `SignIn`,
-`SignUp`, `SignOut`, `signIn`, `signUp`, `signOut`, `createUser`,
-`createFollowers`, `SocialLinks`, `createEmbedSession`.
-
-Not ported: marketing pages, and the email/phone verification flows. The
-headless chat pair (`useChatbot` + `<ChatbotInline>`) also remains React-only —
-Solid gets the iframe widget, not the build-your-own-UI surface.
-
-#### The Solid binding is typechecked for the first time
-
-Source-shipped bindings are excluded from the main `tsconfig`, because tsc here
-is configured for React's JSX dialect. Excluded also meant never checked.
-`tsconfig.solid.json` now typechecks it under Solid's own pragma, and `pnpm
-typecheck` runs both — so it is a release gate.
-
-It found two real errors on its first run, both in the pre-existing forms
-binding and both the same Solid hazard: calling an accessor twice inside a
-ternary, so the guard narrows the first read and the second is still
-possibly-undefined. One of them could have passed an undefined client into
-`createFormController`.
-
-#### Shared cores extracted, so bindings cannot fork
-
-`embed-protocol.ts` and `auth-links.ts` now own the postMessage protocol and
-origin check, the session-refresh schedule, the auth-handler URL contract and
-the follower storage format. React was refactored onto them rather than the
-Solid binding copying them across.
-
-The origin check is the reason this matters: it decides whether a message from
-an arbitrary window may drive a cart or a checkout. A second, subtly weaker copy
-would be a security bug affecting one framework's users only, so a release gate
-asserts it exists in exactly one file.
-
-#### The parity matrix now records HOW, not just whether
-
-`capabilities` changed from a list to a map of capability to level: `native`
-(components in your DOM), `embed` (a hosted page in an iframe) or `both`.
-
-The distinction is not cosmetic. Recorded as booleans, Solid's iframe chat
-widget looked equal to React's, which additionally ships ~1,200 lines of
-headless chat UI. It also surfaces something that reads the other way: storefront,
-cart and blog are `embed` on **every** binding including React, so on those
-surfaces the non-React bindings were never behind.
-
-The release gate derives the level from the source — it reads implementations,
-not export names — and asserts the manifest and the published docs table agree.
-
-#### Framework capability matrix is now published data
-
-`@businessdash/sdk/framework-support` gained a `capabilities` field per adapter
-plus `CAPABILITY_LABELS`, `ALL_CAPABILITIES` and `REACT_TARGETS`. This makes an
-uncomfortable fact discoverable instead of implicit: **`react` exposes all 14
-capability areas and every other binding exposes forms**, plus in most cases a
-shared client. Chat, customer auth, storefront, cart, checkout, blog, the
-customer portal, marketing pages, followers, social links and the verification
-flows are React-only.
-
-`REACT_TARGETS` documents that Next, Astro, Remix / React Router 7 and TanStack
-Start are not lesser targets — they render React, import
-`@businessdash/sdk/react`, and get the full surface. React Native uses
-`@businessdash/sdk/native`.
-
-A release gate now asserts the code, the manifest and the published docs table
-all agree, so the framework page cannot advertise a capability an adapter
-doesn't export.
-
-#### Contract fixes found by auditing the SDK against the platform
-
-Four places where the SDK's schemas disagreed with what the platform actually
-sends. All are fixes to existing behaviour, not new surface.
-
-**Form definitions were losing most of their render contract.**
-`biab.chatbot.getForm()` / `getChatForm()` stripped `settings`, `orgIcon`,
-`actions` and `businessFunctions` — the server sent all four, the schema
-declared none of them. Anyone building a form UI on the typed client got a
-bare field list with no animation, no multi-step or progress configuration, no
-exit confirmation, no branded header, and no way to compute `calculation`
-fields. All four are now declared, and the schema passes unknown fields
-through so the next server addition reaches you instead of vanishing.
-
-**Dry-run submissions threw.** A validate-only submit legitimately returns
-`submissionId: null`, but the schema required a string, so every test submit
-raised a parse error. It is nullable now, `dryRun` is returned alongside it,
-and the submit input accepts `dryRun`, `source`, `referrer` and `metadata` —
-all of which the route already supported and the typed client could not send.
-
-**Gallery items were losing their description** through the marketing bundle.
-
-Docs: **Developer → By feature → Framework Support**.
-
-#### Coupons from the SDK, live in your Stripe account
-
-`biab.coupons.create()` makes a discount code and mints it in **your own**
-Stripe account in the same call — a Coupon plus a Promotion Code, so the same
-string works on your storefront and on Stripe-hosted Checkout.
-
-```ts
-const { coupon, stripeSynced } = await biab.coupons.create({
-  code: 'WELCOME10',
-  discountType: 'percent',
-  value: 10,
-})
-```
-
-Creation and the Stripe sync are one operation deliberately. A coupon that
-exists locally but not in Stripe is the failure worth designing out: your
-storefront accepts the code and Stripe rejects it, stranding the customer at
-payment. If the sync fails the coupon is still created and `stripeSynced` comes
-back `false` with the reason, rather than pretending it is live.
-
-`biab.coupons.list()` returns every coupon with its redemption count and Stripe
-ids. Both need a **secret** key holding the new `storefront:write` scope —
-`validate()` is unchanged and still works with a publishable token.
-
-Buy-X-get-Y and bundle-gift coupons stay dashboard-only: Stripe has no native
-BXGY, so they run through our own cart math and need offer rows the API
-doesn't collect.
-
-Docs: **Developer → By feature → Store → Coupons**.
-
-#### Framework version support is now declared, not implied
-
-The SDK ships form bindings for eight targets, and until now said nothing
-about which versions of those frameworks it was built for — `package.json`
-declared peer ranges for React only. A developer on a brand-new framework
-major got no signal either way.
-
-Every adapter now declares its range as an optional peer dependency, so your
-package manager warns on a mismatch instead of failing later with a confusing
-build error. The same data is importable:
-
-```ts
-import { FRAMEWORK_SUPPORT, supportFor } from '@businessdash/sdk/framework-support'
-```
-
-Each entry also names the framework APIs its binding depends on, which is how
-we assess whether a framework's major actually breaks us — a diff against a
-list rather than a reread of the adapter.
-
-**When a framework ships a breaking major, we add a second adapter for it
-rather than replacing the first.** Both ship, the docs show both, and code on
-either major keeps working.
-
-**Solid 2.0 (August 2026)** reworked a substantial part of the framework API.
-`@businessdash/sdk/solid` is written against the **1.x** dialect and is not yet
-verified on 2.x; a `v2` dialect is planned alongside it. On Solid 2.0 today,
-`@businessdash/sdk/element` or `@businessdash/sdk/vanilla` give you the same
-form behaviour with no framework dependency.
-
-Docs: **Developer → By feature → Framework Support**.
-
-
-#### Push your catalog to your own Stripe account
-
-`biab.storefront.syncToStripe()` takes the products you manage in
-BusinessDash and creates them in **your own** Stripe account — each product as
-a Stripe Product, each variant combination as a Price. It is the same operation
-as the dashboard's "Sync to Stripe" button, now available to your code, so you
-can run it on your own schedule, in a deploy step, or immediately after
-creating a product.
-
-```ts
-const result = await biab.storefront.syncToStripe()
-console.log(result.synced)    // [{ productId, stripeProductId, combinationsSynced }]
-console.log(result.remaining) // products still awaiting a sync
-```
-
-Pass `productId` to sync one product; omit it to sync everything not yet
-pushed, in bounded batches — check `remaining` and call again until it reaches
-zero. Large catalogs are paged deliberately rather than risking a timeout
-halfway through.
-
-Re-running is safe. An existing Stripe Product is updated rather than
-duplicated, and a new Price is minted only when the amount actually changed
-(Stripe Prices are immutable on amount). A product that fails comes back in
-`failed` with its reason instead of abandoning the rest of the batch.
-
-Requires a **secret** key holding the new `storefront:write` scope — never a
-publishable token, because this spends against Stripe on your behalf — plus
-the `ecommerce.storefront` entitlement and a connected Stripe account. The
-endpoint is rate-limited more tightly than the rest of the package API for the
-same reason.
-
-Docs: **Developer → By feature → Store → Sync to Stripe**.
-
 ## Legacy Docs
 
 The 0.9.35 docs are archived at [`docs-legacy/0.9.35/`](./docs-legacy/0.9.35/).