@sonordev/contracts 2.1.0 → 2.1.1

package/CHANGELOG.md

@@ -1,5 +1,9 @@
 # Changelog
 
+## 2.1.1
+
+- Docs only: the README names the Sonor API and the dashboard where it named internal repositories. No code changes.
+
 ## 2.1.0
 
 A minor release: one new entry, `@sonordev/contracts/voice`. Every other entry is unchanged.
@@ -69,7 +73,7 @@ A major for one entry, `slots`, plus three new entries; every other entry is unc
   `slots` re-exports all of it.
 - **New entry `@sonordev/contracts/site-cache`**: how Sonor refreshes a
   site's cached pages. `SITE_CACHE_TAGS` (the tag names site-kit's fetches
-  carry and sonor-api expires), `SITE_REVALIDATE_PATH`, the webhook payload
+  carry and the Sonor API expires), `SITE_REVALIDATE_PATH`, the webhook payload
   and its `ping`, and `isSiteRevalidatePong`.
 - **New entry `@sonordev/contracts/site-edit`**: Sonor's Edit on page. The
   messages between a framed site and the dashboard, which origins may drive
@@ -80,5 +84,5 @@ A major for one entry, `slots`, plus three new entries; every other entry is unc
 
 First release. The rules site-kit 6.x published as `@sonordev/site-kit/*/contract`
 (website, color, sites, seo-pages, seo-meta, llms, forms, fleet, slots,
-portfolio), as a dependency-free package, so sonor-api, signal-api and the
-dashboard import them instead of keeping mirrors.
+portfolio), as a dependency-free package, so the Sonor APIs and the
+dashboard import them instead of keeping copies.

package/README.md

@@ -9,19 +9,19 @@ pnpm add @sonordev/contracts
 
 | Entry | What it decides | Who reads it |
 |---|---|---|
-| `@sonordev/contracts/website` | A site's design tokens and what a popup is made of (blocks, limits, the text sanitizer) | site-kit renders them, sonor-api validates every write, the dashboard previews them, Signal's agents send them |
+| `@sonordev/contracts/website` | A site's design tokens and what a popup is made of (blocks, limits, the text sanitizer) | site-kit renders them, the Sonor API validates every write, the dashboard previews them, Signal's agents send them |
 | `@sonordev/contracts/color` | Reading a CSS color, WCAG luminance and contrast | `website`, site-kit's brand extraction |
 | `@sonordev/contracts/sites` | The canonical shape of a site host (the multi-site `site` dimension) | every ingest and read that filters by site |
-| `@sonordev/contracts/seo-pages` | Which `seo_pages` row a path resolves to on a multi-site project | sonor-api, Signal, site-kit's sitemap sync |
+| `@sonordev/contracts/seo-pages` | Which `seo_pages` row a path resolves to on a multi-site project | the Sonor API, Signal, site-kit's sitemap sync |
 | `@sonordev/contracts/seo-meta` | Whether a title or description is fit to ship | site-kit, Signal's SEO gate |
-| `@sonordev/contracts/llms` | llms.txt sanitizers and contract version | site-kit, sonor-api, Signal's schema validation |
-| `@sonordev/contracts/forms` | The honeypot policy | site-kit forms, sonor-api intake |
-| `@sonordev/contracts/fleet` | The fleet heartbeat's wire shape | site-kit, sonor-api |
-| `@sonordev/contracts/slots` | Slot payload signing, contract v2 (HMAC; Node only). Signs and verifies v1 for older site-kit releases | sonor-api, site-kit on the server |
-| `@sonordev/contracts/slot-content` | What a slot of each kind may hold (`normalizeSlotValue`), safe links, the rich-text parser. No `crypto`, so browsers can import it | sonor-api, site-kit, the dashboard editor |
-| `@sonordev/contracts/site-cache` | The cache tags a site's Sonor fetches carry and the revalidation route's path, payload and ping | site-kit tags and serves the route, sonor-api calls it |
+| `@sonordev/contracts/llms` | llms.txt sanitizers and contract version | site-kit, the Sonor API, Signal's schema validation |
+| `@sonordev/contracts/forms` | The honeypot policy | site-kit forms, the Sonor API's form intake |
+| `@sonordev/contracts/fleet` | The fleet heartbeat's wire shape | site-kit, the Sonor API |
+| `@sonordev/contracts/slots` | Slot payload signing, contract v2 (HMAC; Node only). Signs and verifies v1 for older site-kit releases | the Sonor API, site-kit on the server |
+| `@sonordev/contracts/slot-content` | What a slot of each kind may hold (`normalizeSlotValue`), safe links, the rich-text parser. No `crypto`, so browsers can import it | the Sonor API, site-kit, the dashboard editor |
+| `@sonordev/contracts/site-cache` | The cache tags a site's Sonor fetches carry and the revalidation route's path, payload and ping | site-kit tags and serves the route, the Sonor API calls it |
 | `@sonordev/contracts/site-edit` | Edit on page: the messages between a framed site and the dashboard, trusted origins, how a slot is found on the page | site-kit's overlay, the dashboard's visual editor |
-| `@sonordev/contracts/portfolio` | Where a portfolio number comes from and which may headline; the live-frame message | sonor-api, Signal, agency-site-kit |
+| `@sonordev/contracts/portfolio` | Where a portfolio number comes from and which may headline; the live-frame message | the Sonor API, Signal, agency-site-kit |
 | `@sonordev/contracts/voice` | The house voice's contraction rule. `findUncontracted` and `contractText` find and apply full forms that should be contractions; `findContracted` finds the contractions a question-form heading should expand | anything that checks or rewrites copy: Sonor's APIs and dashboard |
 
 ## The voice contract
@@ -137,10 +137,8 @@ pinned by a test, so changing it later is a visible change.
 
 ## Why it exists
 
-Before this package, each API kept a byte-identical copy of the rules it
-shared with site-kit, plus a drift test to catch the copies diverging. Ten
-parallel copies of a rule is how two of them end up disagreeing. Now there's
-one: the source is `src/contracts/` in the site-kit repo, site-kit bundles it
+A rule that lives in several copies is how two of them end up disagreeing.
+This package means there's one: the source is `src/contracts/` in the site-kit repo, site-kit bundles it
 into its own `*/contract` entries, and this package publishes the same files
 for everyone else.
 

package/dist/fleet.d.ts

@@ -2,13 +2,13 @@
  * @sonordev/contracts/fleet — Fleet heartbeat wire contract (v1)
  *
  * Single source of truth for the heartbeat payload shape, shared by site-kit
- * (send side, `@sonordev/site-kit/fleet/contract`) and sonor-api (ingest
+ * (send side, `@sonordev/site-kit/fleet/contract`) and the Sonor API (ingest
  * side: its DTO is type-checked against FleetHeartbeatPayload).
  *
- * Why it exists: ~24+ client sites run site-kit at wildly drifted versions and
- * the platform could not answer "which version / modules / key state is each
- * site running" without shelling into every local repo. The heartbeat answers
- * that from live traffic. It is fire-and-forget, deferred to idle (never in the
+ * Why it exists: sites run whatever site-kit version they last deployed, and
+ * Sonor should be able to answer "which version / modules / key state is each
+ * site running" without anyone opening each repo. The heartbeat answers that
+ * from live traffic. It is fire-and-forget, deferred to idle (never in the
  * hydration path), and carries NO visitor data — only the site's own build
  * fingerprint. Project identity is resolved server-side from the x-api-key
  * header, exactly like every other /api/public/* endpoint; sites never send
@@ -56,7 +56,7 @@ export interface FleetHeartbeatPayload {
     next_version?: string | null;
     /** Client-observable active modules — deduped, validated, canonical order. */
     modules: FleetModule[];
-    /** Normalized lowercase host (multi-site sub-dimension; see CLAUDE.md). */
+    /** Normalized lowercase host (multi-site sub-dimension). */
     site?: string | null;
     /** 'client' (runtime boot) or 'build' (CI/build step). Default 'client'. */
     source?: FleetHeartbeatSource;
@@ -77,9 +77,9 @@ export declare function normalizeFleetModules(input: unknown): FleetModule[];
 export declare function sanitizeFleetVersion(raw: unknown): string | null;
 /**
  * Light client-side site normalization to the canonical host shape (lowercase,
- * no protocol/path/port). sonor-api's IngestService.normalizeSite is the
- * AUTHORITATIVE normalizer and re-runs on ingest — this just avoids sending
- * obvious noise. Keep the two shapes aligned (see CLAUDE.md "site" convention).
+ * no protocol/path/port). The Sonor API's normalizer is AUTHORITATIVE and
+ * re-runs on ingest; this just avoids sending obvious noise. Keep the two
+ * shapes aligned.
  */
 export declare function normalizeFleetSite(raw: unknown): string | null;
 /**

package/dist/forms.d.ts

@@ -1,17 +1,11 @@
 /**
  * @sonordev/contracts/forms — managed-form honeypot policy (v1)
  *
- * Single source of truth for the honeypot trap-field naming + server-side
- * detection policy, shared by the client (site-kit emits the trap field) and
- * the server (sonor-api names the trap in the form config it returns AND
- * detects hits on intake). Both import this: site-kit as
- * `@sonordev/site-kit/forms/contract`, sonor-api through
- * `src/modules/forms/honeypot-contract.ts`.
+ * Single source of truth for the honeypot field's naming, shared by site-kit
+ * (which renders the field, as `@sonordev/site-kit/forms/contract`) and Sonor.
  *
- * The default field name (`_sk_hp_url`) is deliberately obscure: a common name
- * like "website" collides with real form fields and flags genuine submissions
- * as spam, so generic names are only trusted when they DON'T match a real
- * field of the form (see `resolveHoneypotFieldNames`).
+ * The default field name is deliberately unlike a real field's, so it never
+ * collides with a form's own fields (see `resolveHoneypotFieldNames`).
  */
 /** Bump on breaking changes to the honeypot policy. */
 export declare const FORMS_HONEYPOT_CONTRACT_VERSION: 1;

package/dist/llms.d.ts

@@ -14,7 +14,7 @@ export declare const LLMS_PUBLIC_SUMMARY_MAX_LENGTH = 400;
 /** Max length for optional llms.txt blockquote disclaimer line. */
 export declare const LLMS_DISCLAIMER_MAX_LENGTH = 280;
 /**
- * Optional keys we allow inside managed_llm_schema JSON from Portal.
+ * Optional keys we allow inside managed_llm_schema JSON from Sonor.
  * Values outside this set should not be relied on by consumers; strip unknown keys when emitting JSON-LD.
  */
 export declare const MANAGED_LLM_SCHEMA_KNOWN_KEYS: Set<string>;

package/dist/portfolio.d.ts

@@ -2,13 +2,9 @@
  * @sonordev/contracts/portfolio — portfolio proof display policy (v1)
  *
  * Single source of truth for the Lighthouse-KPI collapse policy shared by the
- * content side (signal-api generation) and the render side (agency-site-kit
- * display):
- *  - agency-site-kit imports it (`@sonordev/site-kit/portfolio/contract`)
- *    from `src/portfolio/curate-proof.ts`, which keeps the render-only
- *    primitives that bind to its section types.
- *  - signal-api imports it through
- *    `src/modules/skills/portfolio/portfolio-kpi-policy.util.ts`.
+ * content side (Signal's case-study generation) and the render side
+ * (agency-site-kit, which imports it as `@sonordev/site-kit/portfolio/contract`
+ * and keeps the render-only primitives that bind to its section types).
  *
  * Why it exists: generated case studies arrived with four "100/100 Lighthouse X"
  * KPIs repeated across hero, results cards, and a Performance section. One
@@ -17,8 +13,8 @@
  *
  * It is also the single source of truth for METRIC PROVENANCE (below): the
  * three sources a portfolio number can have, what a client-reported number
- * must carry, and which numbers may headline. sonor-api imports those
- * through `src/modules/portfolio/portfolio-metric-source.util.ts`.
+ * must carry, and which numbers may headline. The Sonor API applies the same
+ * rules.
  */
 /** The message a cross-origin-framed site-kit page posts to its embedder once it has painted. */
 export declare const FRAME_READY_MESSAGE: 'sonor:frame-ready';
@@ -109,11 +105,11 @@ export declare const METRIC_SOURCES: readonly ['measured', 'reported', 'estimate
 export type MetricSource = (typeof METRIC_SOURCES)[number];
 /** Who stands behind a client-reported number. */
 export interface MetricAttribution {
-    /** The person, e.g. "Scott Mann". */
+    /** The person, e.g. "Dana Reyes". */
     name: string;
-    /** Their title, e.g. "Director of Business Development". */
+    /** Their title, e.g. "Director of Operations". */
     role?: string;
-    /** Where they work: almost always the client, e.g. "True Power Systems". */
+    /** Where they work: almost always the client, e.g. "Northwind Engineering". */
     organization: string;
     /** The day they reported it, YYYY-MM-DD. */
     date: string;
@@ -140,12 +136,12 @@ export declare function isHeadlineMetric(metric: SourcedMetric): boolean;
 /** The badge a display shows, or null for a missing or unknown source (show nothing rather than guess). */
 export declare function metricSourceLabel(source: unknown): string | null;
 /**
- * The full credit: "Reported by Scott Mann, Director of Business Development,
- * True Power Systems, September 25, 2026". The date is read as a plain day,
+ * The full credit: "Reported by Dana Reyes, Director of Operations, Northwind
+ * Engineering, September 25, 2026". The date is read as a plain day,
  * never through a time zone, so it can't slip to the day before.
  */
 export declare function formatAttribution(by: MetricAttribution): string;
-/** The credit for a tight space (a card, a carousel tile): "per True Power Systems". */
+/** The credit for a tight space (a card, a carousel tile): "per Northwind Engineering". */
 export declare function shortAttribution(by: Pick<MetricAttribution, 'organization'>): string;
 /**
  * Carry a person's reported numbers through a regeneration. The generator can

package/dist/seo-meta.d.ts

@@ -4,17 +4,16 @@
  * Single source of truth for "is this machine-generated seo_pages.managed_title
  * / managed_meta_description fit to ship?". site-kit applies it at render time
  * (getManagedMetadata falls back to the page's own title/description), and
- * signal-api imports it (`src/shared/utils/seo-meta-quality.util.ts`) to gate
- * every generated title before it's written, so the two can't disagree.
+ * Signal applies it to every generated title before it's written, so the two
+ * can't disagree.
  *
- * Why it exists (2026-09-15): Signal's meta generator used the raw domain as
- * the brand whenever it could not resolve one, so ~500 managed titles across
- * 20+ projects shipped as "Apartments for Rent | abbeyglenapts.com", were
- * hard-cut at 60 chars ("… | reinhartheatingandcooli"), lost the suffix to a
- * word-boundary cut ("Contact Reinhart Heating and Cooling |"), or had the
- * model rebuild a brand out of the domain ("About SSO Shkosh Apartments | SSO
- * Shkosh" for ssoshkoshapts.com — the brand is SS Oshkosh Apartments). Sites
- * rendered them verbatim.
+ * Why it exists: a meta generator that uses the raw domain as the brand when it
+ * can't resolve one ships titles like "Apartments for Rent |
+ * maplecourtapts.com", hard-cuts them at 60 chars ("… |
+ * brightsideheatingandcooli"), loses the suffix to a word-boundary cut
+ * ("Contact Brightside Heating and Cooling |"), or rebuilds a brand out of the
+ * domain ("About BBE Llis Apartments | BBE Llis" for bbellisapts.com, when the
+ * brand is BB Ellis Apartments). Sites render them verbatim.
  *
  * Every rule derives from the site's own identity (its hosts and brand), so
  * there is no list of bad strings to maintain. Pure string logic — no I/O, no
@@ -24,7 +23,7 @@
 export declare const SEO_META_CONTRACT_VERSION: 1;
 /** Who the site is. Hosts come from the project/site config, the brand from the resolved business name — never from the domain. */
 export interface MetaIdentity {
-    /** The site's brand, e.g. "SS Oshkosh Apartments". */
+    /** The site's brand, e.g. "BB Ellis Apartments". */
     brand?: string | null;
     /** Other correct spellings of the brand. */
     brandAliases?: Array<string | null | undefined>;
@@ -34,7 +33,7 @@ export interface MetaIdentity {
 export type TitleProblem = 'empty' | 'placeholder' | 'dangling-separator' | 'hostname' | 'mangled-brand';
 export type DescriptionProblem = 'empty' | 'hostname' | 'mangled-brand' | 'truncated';
 export type SuffixProblem = 'hostname' | 'mangled-brand';
-/** "https://www.AbbeyGlenApts.com:443/x" → "abbeyglenapts.com". Null for anything that isn't a host (no dot, or words). */
+/** "https://www.MapleCourtApts.com:443/x" → "maplecourtapts.com". Null for anything that isn't a host (no dot, or words). */
 export declare function metaHost(value: string | null | undefined): string | null;
 /** True when the text names the brand (an alias, or either one's core) word for word. */
 export declare function namesBrand(text: string, id: MetaIdentity): boolean;

package/dist/seo-pages.d.ts

@@ -3,13 +3,10 @@
  *
  * Single source of truth for choosing ONE seo_pages row when a (project_id,
  * path/url) lookup matches several, and for scoping a project's rows to one
- * host. site-kit (`@sonordev/site-kit/seo/pages/contract`), sonor-api
- * (`src/modules/seo/seo-page-resolve.util.ts`) and signal-api
- * (`src/shared/utils/seo-page-pick.util.ts`) all import this; none keeps a
- * copy.
+ * host. site-kit (`@sonordev/site-kit/seo/pages/contract`) and both Sonor
+ * APIs import this; none keeps a copy.
  *
- * seo_pages identity became (project_id, site, url) in sonor-api migration
- * 20260702150000_seo_pages_per_site_identity.sql: a multi-site project (one
+ * seo_pages identity is (project_id, site, url): a multi-site project (one
  * Sonor project hosting many domains) keeps one row PER SUB-SITE HOST for
  * shared paths like `/` or `/contact`. Any path/url lookup can therefore match
  * several rows — `.single()`/`.maybeSingle()` error on them (PGRST116) — so
@@ -26,11 +23,9 @@ export declare const SEO_PAGES_CONTRACT_VERSION: 1;
  *
  * Retired pages are kept as tombstones (status='removed') so their history and
  * redirects survive, which means every public read has to opt out of them
- * explicitly. Three reads in llms-content.service.ts never did, and the sitemap
- * sync's removal flag was write-only for as long as the code existed: on
- * 2026-09-20 upforge.io's llms.txt — the file handed straight to AI crawlers —
- * was 32% dead URLs, advertising service areas in Atlanta, Detroit and Tampa
- * that the business has never served.
+ * explicitly. A read that forgets serves dead URLs: an llms.txt, the file
+ * handed straight to AI crawlers, ends up advertising pages the business
+ * retired long ago.
  *
  * Null-safe by design: `status` is nullable with an 'active' default, so a row
  * whose status was explicitly nulled stays live rather than vanishing from the
@@ -80,13 +75,12 @@ export declare function matchSitemapEntryRow<T extends SeoPageRowLike>(candidate
  * that belongs to `site`, keeping at most one row per path.
  *
  * Why this exists: a multi-site project (one Sonor project hosting many
- * domains — bd-aec.com plus 48 sibling domains, truepowersystems.com plus its
- * state microsites) holds one row PER HOST for shared paths like `/` and
- * `/terms`. Any project-wide read that dedupes by path alone therefore keeps an
- * ARBITRARY host's row. Observed 2026-08-25: bd-aec.com's llms.txt described
- * `/` with soqwriters.com's homepage copy and `/terms` with bd-charlotte.com's,
- * and which sibling won changed every time a neighbour rebuilt, because the tie
- * among same-path rows is broken by whatever order Postgres returns.
+ * domains, e.g. example.com plus dozens of city microsites) holds one row PER
+ * HOST for shared paths like `/` and `/terms`. Any project-wide read that
+ * dedupes by path alone therefore keeps an ARBITRARY host's row: example.com's
+ * llms.txt can describe `/` with a sibling's homepage copy, and which sibling
+ * wins changes every time a neighbour rebuilds, because the tie among
+ * same-path rows is broken by whatever order Postgres returns.
  *
  * Rules, per path, via `matchSitemapEntryRow`:
  *  - this host's row wins outright

package/dist/site-cache.d.ts

@@ -2,11 +2,11 @@
  * How Sonor refreshes a site's cached pages when content changes.
  *
  * A site serves cached pages and caches every fetch from Sonor. When someone
- * edits content in Sonor, sonor-api POSTs the paths and cache tags that
+ * edits content in Sonor, Sonor POSTs the paths and cache tags that
  * changed to the site's revalidation route, authenticated with the project's
  * API key, and the site regenerates just those. site-kit tags its fetches with
  * these names and serves the route (`@sonordev/site-kit/revalidate`);
- * sonor-api sends them. Single source of truth for the names on both sides:
+ * Sonor sends them. Single source of truth for the names on both sides:
  * never spell a tag as a string literal in either.
  */
 /** Where the revalidation route lives on every site. */
@@ -29,7 +29,7 @@ export declare const SITE_CACHE_TAGS: {
     readonly portfolio: 'portfolio';
 };
 export type SiteCacheTag = (typeof SITE_CACHE_TAGS)[keyof typeof SITE_CACHE_TAGS];
-/** The body sonor-api POSTs to the revalidation route. */
+/** The body Sonor POSTs to the revalidation route. */
 export interface SiteRevalidatePayload {
     /** Local paths to regenerate, e.g. `['/services/roofing']`. */
     paths?: string[];
@@ -39,7 +39,7 @@ export interface SiteRevalidatePayload {
     revalidateAll?: boolean;
     /**
      * Only check that the route is installed and the key matches; nothing is
-     * regenerated. sonor-api pings after it registers a site's route, so it
+     * regenerated. Sonor pings after it registers a site's route, so it
      * knows whether an edit goes live in seconds or waits for the cache to age out.
      */
     ping?: boolean;

package/dist/sites-normalize.d.ts

@@ -14,9 +14,7 @@
  * pushed those entries over their bundle budgets.
  *
  * `./sites` re-exports this, so `@sonordev/contracts/sites` (and site-kit's
- * `sites/contract`) carry it too. The Nest APIs import it from there
- * (sonor-api `src/common/utils/site-host.ts`, signal-api
- * `src/shared/utils/seo-page-pick.util.ts`).
+ * `sites/contract`) carry it too. The Sonor APIs import it from there.
  *
  * Pure string logic only (no Node built-ins) so it is safe in the browser.
  */
@@ -24,7 +22,7 @@
  * normalizeSiteHost — canonical normalizer for a sub-site host value before it
  * is persisted or used as a filter.
  *
- *   `https://OhioPowerStudies.com:3000/path` → `ohiopowerstudies.com`
+ *   `https://Ohio.Example.com:3000/path` → `ohio.example.com`
  *
  * Lowercases, strips protocol, keeps host only (drops path + query), strips
  * port (rollups span dev/prod) and the FQDN root dot. Returns null for

package/dist/sites.d.ts

@@ -2,10 +2,8 @@
  * @sonordev/contracts/sites — Multi-site "site" dimension host contract (v1)
  *
  * Single source of truth for normalizing and comparing sub-site host values
- * (the multi-site `site` dimension, see CLAUDE.md). site-kit, sonor-api
- * (`src/common/utils/site-host.ts`) and signal-api
- * (`src/shared/utils/seo-page-pick.util.ts`) all import it, so there's no
- * copy to drift.
+ * (the multi-site `site` dimension). site-kit and both Sonor APIs import it,
+ * so there's no copy to drift.
  *
  * Pure string logic only (no Node built-ins) so it is safe in the browser:
  * site-kit itself normalizes `__SITE_KIT_SITE__` with `normalizeSiteHost`.
@@ -28,7 +26,7 @@ export declare function stripWww(host: string): string;
  */
 export declare function sameSite(a: string | null | undefined, b: string | null | undefined): boolean;
 /**
- * Host of a full URL ("https://ohiopowerstudies.com/x" → "ohiopowerstudies.com"),
+ * Host of a full URL ("https://ohio.example.com/x" → "ohio.example.com"),
  * null for site-relative paths ("/services") and unparseable input.
  */
 export declare function hostFromUrl(value: string | null | undefined): string | null;

package/dist/slot-content.d.ts

@@ -4,7 +4,7 @@
  * The pure half of the slots contract: content types, value validation
  * (normalizeSlotValue), safe links, and the rich-text subset parser. No
  * crypto, so the dashboard can import it in the browser to validate and
- * preview exactly what sonor-api will accept and site-kit will render.
+ * preview exactly what the Sonor API will accept and site-kit will render.
  * `@sonordev/contracts/slots` re-exports all of it next to the signing.
  */
 /**
@@ -66,7 +66,7 @@ export type SlotValueResult = {
 /**
  * Validate and normalize what an editor (or Signal) submits for a slot of
  * `type`, returning the canonical `content` + `value` to store and sign.
- * The single rule for "what a valid slot of this type is": sonor-api runs it
+ * The single rule for "what a valid slot of this type is": the Sonor API runs it
  * on every write and verifySlotContent re-runs it on every read.
  */
 export declare function normalizeSlotValue(type: SlotContentType, input: {

package/dist/slots.d.ts

@@ -3,23 +3,23 @@
  *
  * Single source of truth for the slot payload shape, value validation, the
  * rich-text subset, and content signing, shared by site-kit (verify + render),
- * sonor-api (validate + sign) and the dashboard (preview). Node only: it signs
+ * the Sonor API (validate + sign) and the dashboard (preview). Node only: it signs
  * with `crypto`.
  *
  * Security model: every SlotContent is HMAC-signed with the project API key.
  * site-kit verifies before rendering and falls back to the developer's static
  * content on any mismatch, so platform-originated content carries provenance
- * end to end. See docs/SITE-KIT-3.0-SPEC-SLOTS.md and docs/WEBSITE-CMS.md.
+ * end to end.
  *
  * v1 (site-kit ≤ 7.0) is plain text only. v2 adds rich text, links and lists,
- * and signs the structured value too. sonor-api serves both: a v1 request gets
+ * and signs the structured value too. Sonor serves both: a v1 request gets
  * text slots signed the v1 way and null for everything else.
  */
 import { type SlotContentType, type SlotValue } from './slot-content';
 export * from './slot-content';
 /** The version this package speaks. Bump on breaking payload changes. */
 export declare const SLOTS_CONTRACT_VERSION = 2;
-/** Versions sonor-api still serves. */
+/** Versions Sonor still serves. */
 export declare const SUPPORTED_SLOTS_CONTRACT_VERSIONS: readonly number[];
 export interface SlotContent {
     slot_id: string;
@@ -63,7 +63,7 @@ export interface SlotResolveRequestEntry {
 export interface SlotsResolveRequest {
     contract_version: number;
     slots: SlotResolveRequestEntry[];
-    /** Multi-site sub-dimension: normalized lowercase host (see CLAUDE.md "site" convention). */
+    /** Multi-site sub-dimension: normalized lowercase host. */
     site?: string;
 }
 export interface SlotsResolveResponse {
@@ -83,7 +83,7 @@ type Signable = Pick<SlotContent, 'slot_id' | 'type' | 'content'> & {
  */
 export declare function slotSigningPayload(content: Signable, version?: number): string;
 /**
- * Sign slot content with the project API key (sonor-api side).
+ * Sign slot content with the project API key (Sonor's side).
  * Returns the hex HMAC-SHA256 signature.
  */
 export declare function signSlotContent(content: Signable, apiKey: string, version?: number): string;

package/dist/website.d.ts

@@ -5,14 +5,14 @@
  * SINGLE SOURCE OF TRUTH shared by every side of the Website module's popups:
  *  - the site (site-kit measures its own rendered design and reports it,
  *    publishes it as `--sk-site-*` CSS variables, and renders popup blocks),
- *  - sonor-api (validates the design report and every popup write with these
+ *  - the Sonor API (validates the design report and every popup write with these
  *    normalizers, so a popup can't be saved in a shape the site can't draw),
  *  - the dashboard (the builder's preview reads the same tokens through the
  *    same CSS-variable mapping, so it looks like the site),
  *  - Signal's agents (the block shapes an MCP `propose_site_popup` sends).
  *
  * All four import it: site-kit as `@sonordev/site-kit/website/contract`,
- * sonor-api and the dashboard as `@sonordev/contracts/website`.
+ * the API and the dashboard as `@sonordev/contracts/website`.
  *
  * Why popups carry blocks and the site carries tokens: a popup should look
  * like the site it's on. It says WHAT (a heading, some formatted text, an

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sonordev/contracts",
-  "version": "2.1.0",
+  "version": "2.1.1",
   "description": "The rules Sonor's sites, APIs and dashboard share: popup blocks and site design tokens, site hosts, SEO page identity, title quality, llms.txt sanitizers, the forms honeypot, fleet heartbeats, slot content and signing, site cache tags, portfolio metrics and the house voice's contraction rule. Pure functions, no dependencies.",
   "license": "MIT",
   "repository": {