@12-apps/notifications 2.1.0 → 4.0.0

package/ADOPTING.md

@@ -20,7 +20,7 @@ sweep — endpoints and screens included.
 | **Core** | `@12-apps/notifications` | Nothing to wire — the framework-free, storage-free vocabulary both halves share: types, the generator registry, the preference policy, the phone rules, the copy table, the inbox wire shape. Safe in a browser. |
 | **Server** | `@12-apps/notifications/server` | Call `createApiNotifications({ db, contacts, transports })` and mount the `routes` it returns — the nine inbox / preferences / push-subscription endpoints, with parsing, statuses and the `{ data }` envelope inside. It also returns `notify` (the emit front door), `notifyByPermission`, `dispatchDeliveries`, `drainPending` and the three stores. |
 | **Hono** | `@12-apps/notifications/hono` | `const notifications = notificationsRouter({ ...serverConfig, resolveActor }); app.route('/api/account', notifications.router)`. A one-call mount; `hono` is an OPTIONAL peer, so importing the root, `/server` or `/react` never resolves it. |
-| **React** | `@12-apps/notifications/react` | Call `createWebNotifications({ apiBase })`. `BellWithPanel` is the whole feature as one element; `BellButton` + `Panel` are the pair for a host with its own chrome; `page` is the preferences screen you route to. pt-BR product copy and the future-pay test ids ship inside. |
+| **React** | `@12-apps/notifications/react` | Call `createWebNotifications({ apiBase })`. `BellWithPanel` is the whole feature as one element; `BellButton` + `Panel` are the pair for a host with its own chrome; `page` is the preferences screen you route to. pt-BR product copy and the origin host's test ids ship inside. |
 | **Web Push** | `@12-apps/notifications/web-push` | `sender: vapidPushSender({ subject, publicKey, privateKey })` on the `WEB_PUSH` declaration. Its own subpath because it is the only piece that needs `web-push` — an OPTIONAL peer a host that never enables the channel never installs. |
 | **Prisma** | `prisma/notifications.prisma` + `prisma/migrations/*` | Run `pnpm --filter @12-apps/notifications prisma:sync -- <host schema dir>`: the partial is **COPIED** into the host's multi-file schema folder — never symlinked (a symlinked migration is silently skipped by Prisma; a symlinked partial dangles under `turbo prune`). Migrations are discovered structurally from the installed package's `prisma/migrations` by the host's plugin-migration sync. |
 
@@ -35,7 +35,7 @@ sweep — endpoints and screens included.
    someone else's inbox would be a different surface with a different actor.
 
 2. **`contacts` is not optional, and it is not the `users` table.** A transport
-   needs an address: `getContact(userId) → { email, phone } | null`. future-pay's
+   needs an address: `getContact(userId) → { email, phone } | null`. The origin host's
    router read `users.email` / `users.phone` directly, which is the one thing in
    the pipeline that was always the host's — a package cannot know the shape of
    an identity table, and a host with phone VERIFICATION wants to answer the
@@ -105,8 +105,8 @@ sweep — endpoints and screens included.
    it with hand-written SQL. The argument shapes are CLOSED (documented in
    `src/server/db.ts`), so a non-Prisma host has a finite surface to fill.
 
-5. **`categories` is product vocabulary.** The default is future-pay's four
-   (`orders` / `payments` / `stock` / `system`) and the preferences screen
+5. **`categories` is product vocabulary, and REQUIRED.** There is no default:
+   the host declares its own taxonomy, and the preferences screen
    renders whatever the api half was given — the taxonomy travels on the
    `GET /notification-preferences` payload, so the two halves cannot disagree
    about it. The packaged migration deliberately puts **no CHECK** on
@@ -115,7 +115,7 @@ sweep — endpoints and screens included.
 6. **`generators` are registered from the OUTSIDE, and stay the host's.** A
    generator maps a domain event to `{ title, body, link, data }`, and the
    events are exactly what does not port: `order.paid`, `stock.low` and
-   `short-payment` are Future Pay's, not any host's. Pass them in `generators`,
+   `short-payment` are the origin host's, not any host's. Pass them in `generators`,
    or call `registerGenerator` for a module imported later. The generator's
    `category` is what the router gates fan-out on.
 
@@ -184,7 +184,7 @@ sweep — endpoints and screens included.
     notified — and the log line that tells "nobody holds it" apart from "every
     dispatch failed". Two rules for your implementation:
 
-    - `listCandidates` must be **bounded to people who hold a role**. future-pay's
+    - `listCandidates` must be **bounded to people who hold a role**. The origin host's
       requires a role grant, which keeps a store's storefront BUYERS out of a loop
       that resolves permissions one user at a time.
     - `getPermissions` must be **scoped to the tenant**. Unioning a user's grants
@@ -222,7 +222,7 @@ sweep — endpoints and screens included.
 
 13. **These endpoints are cookie-authenticated WRITES. CSRF is yours.** Eight of
     the nine change state, and `resolveActor` typically reads a session cookie —
-    so the host, not this package, owns the cross-site question. In future-pay it
+    so the host, not this package, owns the cross-site question. In the origin host it
     is fully mitigated by the Auth.js cookie's `SameSite=Lax`; a host
     authenticating with `SameSite=None`, or one whose `resolveActor` trusts a
     header a proxy sets, inherits an unguarded write surface. The one that matters

package/README.md

@@ -79,7 +79,7 @@ which no sweep selects again.
 
 ## The endpoints
 
-Mounted under whatever prefix the host chooses (future-pay: `/api/account`):
+Mounted under whatever prefix the host chooses (the origin host: `/api/account`):
 
 | | |
 |---|---|

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@12-apps/notifications",
-  "version": "2.1.0",
+  "version": "4.0.0",
   "type": "module",
   "description": "Plug-and-play notification system (12-15): an always-on in-app inbox, per-user × per-category channel preferences, and email / SMS / WhatsApp / web-push transports behind vendor DRIVERS so a second provider is a config entry. Framework-free core (.), host-mounted backend surface (./server: inbox / preferences / push-subscription endpoints, the channel router with delivery records + retry sweep, the permission fan-out, duck-typed Prisma seam), Hono adapter (./hono), React surface (./react: bell + badge, inbox drawer, preferences screen), VAPID sender (./web-push) and the package-owned Prisma partial + migrations. Standardized adoption contract in ADOPTING.md.",
   "exports": {
@@ -22,7 +22,7 @@
     "prisma:sync:check": "node scripts/sync-notifications-schema.mjs --check"
   },
   "dependencies": {
-    "@12-apps/ui": "^4.1.0"
+    "@12-apps/ui": "^5.0.0"
   },
   "peerDependencies": {
     "hono": ">=4.0.0",

package/prisma/migrations/20260813140000_add_notification_tables/migration.sql

@@ -24,7 +24,7 @@
 --
 -- ============================ REPLAY SAFETY ================================
 -- Every statement is guarded, because the first adopters ALREADY HAVE these
--- tables: future-pay created them by hand before the package existed, so this
+-- tables: the origin host created them by hand before the package existed, so this
 -- migration must be a no-op there and correct on an empty database.
 --
 -- The guards are per COLUMN, not per table. `CREATE TABLE IF NOT EXISTS` alone

package/prisma/notifications.prisma

@@ -22,7 +22,7 @@
 // and for a stronger reason: the category set is HOST vocabulary (`categories`
 // on the server config), so a closed set in the schema would be wrong for every
 // adopter but the first. A host that wants its own taxonomy enforced adds the
-// CHECK in a migration of its own — future-pay does. Only `channel` and `status`
+// CHECK in a migration of its own — the origin host does. Only `channel` and `status`
 // on the delivery row are closed here, because those two are the LIBRARY's.
 model Notification {
   id        String    @id @default(uuid())

package/scripts/sync-notifications-schema.mjs

@@ -20,7 +20,7 @@
  * The host package that owns the schema folder MUST also declare this package
  * as a dependency, so the source of the copy is present in every build context.
  *
- * Default host path follows the future-pay layout
+ * Default host path follows the origin host layout
  * (`packages/prisma/prisma/schema/`); another repo passes its own schema folder
  * as the positional argument, or sets NOTIFICATIONS_HOST_SCHEMA_DIR.
  */

package/src/generators.ts

@@ -4,7 +4,7 @@ import type { NotificationGenerator } from './types';
 /**
  * Generator registry: one {@link NotificationGenerator} per event `type`.
  *
- * INSTANCE state, not a module-level Map. future-pay's original was
+ * INSTANCE state, not a module-level Map. the origin's own was
  * process-wide, which is what a package of loose functions forces; a factory
  * config does not need it, and one registry per mount is what makes a test (or
  * a second mount) able to hold its own set without clearing anyone else's.

package/src/index.ts

@@ -59,8 +59,8 @@ export {
 export { normalizePhoneE164, type PhoneNormalizeOptions } from './phone';
 
 export {
-  DEFAULT_NOTIFICATION_MESSAGES,
   messagesOf,
+  type NotificationWireMessages,
   type NotificationMessages,
 } from './messages';
 

package/src/messages.ts

@@ -1,21 +1,47 @@
 /**
- * Every sentence this package can say to a USER, in one table.
+ * Every sentence this package can say to a USER, stated by the HOST.
  *
- * pt-BR by default because that is the product copy the surface shipped with
- * (future-pay's storefront and backoffice are Brazilian); a host in another
- * market passes `messages` and overrides the subset it cares about. The copy
- * lives HERE rather than in each screen so the api half and the react half can
- * never disagree about a sentence — the 401 body the wire returns and the
- * error the panel renders come from the same key.
+ * The copy lives in ONE table rather than in each screen so the api half and
+ * the react half can never disagree about a sentence — the 401 body the wire
+ * returns and the error the panel renders come from the same key.
+ *
+ * THE pt-BR TABLE THAT USED TO BE THE DEFAULT IS GONE. Its own docstring said
+ * what it was: "the product copy the surface shipped with", labelled in the
+ * source as one named application's "exact copy". A description of one adopter,
+ * shipped inside the package every other adopter installs, and reached by
+ * saying nothing.
+ *
+ * `categoryLabels` is the sharpest of the forty. The categories themselves
+ * became required config in the release before this one, precisely because
+ * WHICH categories exist is product vocabulary — and their LABELS kept
+ * defaulting, so a host that declared `['loans', 'fines']` got a labels map
+ * describing somebody else's four. Required categories with defaulted labels
+ * for a different host's categories is not a smaller version of the bug; it is
+ * the same bug with a compile-time gesture in front of it.
+ *
+ * So `messages` is REQUIRED and whole. The interface is the checklist, and the
+ * compiler names the sentences a host has not written yet.
+ */
+/**
+ * The sentences the SERVER half renders — and the whole of what a backend mount
+ * has to state.
+ *
+ * Split out when `messages` became required. Requiring the full forty on a
+ * server config would have made a backend-only adopter write three dozen
+ * sentences for screens it does not serve, which is the kind of tax that gets a
+ * required-config migration reverted rather than adopted. These four are the
+ * ones the router and the route descriptors actually put on a wire.
  */
-export interface NotificationMessages {
-  // --- the wire ------------------------------------------------------------
+export interface NotificationWireMessages {
   unauthenticated: string;
   invalidBody: string;
   operationFailed: string;
   /** `POST /notifications/mark-read` with neither `ids` nor `all`. */
   markReadTargetRequired: string;
+}
 
+/** Every sentence, wire and screen — what the REACT half needs. */
+export interface NotificationMessages extends NotificationWireMessages {
   // --- the inbox panel -----------------------------------------------------
   panelTitle: string;
   markAllRead: string;
@@ -58,99 +84,20 @@ export interface NotificationMessages {
   devicePushEnabling: string;
 }
 
-/** future-pay's exact copy — the product default. */
-export const DEFAULT_NOTIFICATION_MESSAGES: NotificationMessages = {
-  unauthenticated: 'Não autenticado.',
-  invalidBody: 'Dados inválidos.',
-  operationFailed: 'Não foi possível concluir a operação.',
-  markReadTargetRequired: 'Informe `ids` ou `all: true` (exatamente um).',
-
-  panelTitle: 'Notificações',
-  markAllRead: 'Marcar todas como lidas',
-  loading: 'Carregando notificações...',
-  loadMore: 'Carregar mais',
-  loadingMore: 'Carregando...',
-  loadFailedTitle: 'Não foi possível carregar',
-  loadFailedBody: 'Tente novamente em instantes.',
-  retry: 'Tentar novamente',
-  emptyTitle: 'Nenhuma notificação',
-  emptyBody: 'Você está em dia — novidades aparecem aqui.',
-  openBell: 'Abrir notificações',
-  openBellWithUnread: (count) => `Abrir notificações (${count} não lidas)`,
-  unreadSuffix: 'não lida',
-  deleteOne: (title) => `Excluir notificação: ${title}`,
-
-  justNow: 'agora',
-  minutesAgo: (minutes) => `há ${minutes} min`,
-  hoursAgo: (hours) => `há ${hours} h`,
-  daysAgo: (days) => (days === 1 ? 'há 1 dia' : `há ${days} dias`),
-  dateLocale: 'pt-BR',
-
-  preferencesTitle: 'Notificações',
-  preferencesLead:
-    'Escolha como quer ser avisado, por tipo de assunto. O sino do app sempre recebe tudo.',
-  channelLabels: {
-    EMAIL: 'E-mail',
-    SMS: 'SMS',
-    WHATSAPP: 'WhatsApp',
-    WEB_PUSH: 'Navegador',
-  },
-  channelUnavailableHints: {
-    EMAIL: 'Envio de e-mail não está configurado neste ambiente.',
-    SMS: 'Cadastre um telefone no seu perfil para receber SMS.',
-    WHATSAPP: 'Cadastre um telefone no seu perfil para receber WhatsApp.',
-    WEB_PUSH: 'Alertas do navegador não estão configurados neste ambiente.',
-  },
-  categoryLabels: {
-    orders: {
-      title: 'Pedidos',
-      description: 'Confirmações e andamento dos seus pedidos.',
-    },
-    payments: {
-      title: 'Pagamentos',
-      description: 'Cobranças, comprovantes e falhas de pagamento.',
-    },
-    stock: {
-      title: 'Estoque',
-      description: 'Alertas de estoque das lojas que você administra.',
-    },
-    system: {
-      title: 'Sistema',
-      description: 'Avisos da sua conta e da plataforma.',
-    },
-  },
-  categoryFallbackTitle: (category) => category,
-  devicePushTitle: 'Alertas neste navegador',
-  devicePushIdle: 'Permita notificações para receber alertas mesmo com o site fechado.',
-  devicePushOn: 'Este navegador está recebendo alertas.',
-  devicePushDenied:
-    'Permissão negada — habilite notificações nas configurações do navegador.',
-  devicePushFailed: 'Não foi possível ativar. Tente novamente.',
-  devicePushEnable: 'Ativar',
-  devicePushEnabling: 'Ativando...',
-};
-
-/** The messages in force, defaulted to the pt-BR product copy. */
-export function messagesOf(config: {
-  messages?: Partial<NotificationMessages>;
-}): NotificationMessages {
-  const overrides = config.messages ?? {};
-  return {
-    ...DEFAULT_NOTIFICATION_MESSAGES,
-    ...overrides,
-    // Nested records merge per KEY. A host relabelling one channel must not
-    // erase the labels for the other three, which a shallow spread would do.
-    channelLabels: {
-      ...DEFAULT_NOTIFICATION_MESSAGES.channelLabels,
-      ...overrides.channelLabels,
-    },
-    channelUnavailableHints: {
-      ...DEFAULT_NOTIFICATION_MESSAGES.channelUnavailableHints,
-      ...overrides.channelUnavailableHints,
-    },
-    categoryLabels: {
-      ...DEFAULT_NOTIFICATION_MESSAGES.categoryLabels,
-      ...overrides.categoryLabels,
-    },
-  };
+/**
+ * The messages in force.
+ *
+ * A pass-through rather than a merge: there is nothing left to merge WITH, and
+ * that is the point of the change. The old version spread the host's table over
+ * the origin's, including PER KEY inside `channelLabels`,
+ * `channelUnavailableHints` and `categoryLabels` — so a host that relabelled one
+ * channel kept the origin's wording for the other three, and a host that
+ * labelled its own two categories kept the origin's four sitting beside them in
+ * the same screen.
+ *
+ * Kept as a function because all three mounts read it off a config object, and
+ * because a later rule (a blank-string refusal, say) belongs in one place.
+ */
+export function messagesOf<T extends NotificationWireMessages>(config: { messages: T }): T {
+  return config.messages;
 }

package/src/phone.ts

@@ -13,7 +13,7 @@
  * `4155552671` into `+554155552671` — a plausible Brazilian mobile — and sent a
  * stranger the customer's order details. There is no country this package could
  * assume that is not wrong for every other adopter, so it assumes none and the
- * omission is a compile error rather than a wrong number. future-pay passes
+ * omission is a compile error rather than a wrong number. the origin passes
  * `'55'` explicitly.
  *
  * NOTE: "verified phone" is approximated by "has a normalizable phone on

package/src/react/create-web-notifications.tsx

@@ -37,7 +37,7 @@ export interface NotificationsWebConfig {
   /** How the surface reaches its data. Default: same-origin fetch. */
   transport?: NotificationsTransport;
   /** User-facing copy overrides (pt-BR product copy by default). */
-  messages?: Partial<NotificationMessages>;
+  messages: NotificationMessages;
   /**
    * How the surface learns an inbox changed without asking — the host's message
    * bus. Without it the badge keeps its 60 s poll, which is the standing

package/src/react/inbox-state.ts

@@ -7,7 +7,7 @@ import type { NotificationsApiClient } from './api';
  *
  * They have to share it: marking a row read in the panel must move the badge in
  * the same tick, and an arrival must add a row to the list AND to the count.
- * future-pay got that for free from a react-query cache the host had already
+ * the origin got that for free from a react-query cache the host had already
  * mounted; a published package cannot assume one — a query client is a host
  * decision, and requiring a particular one (or a particular version of one) is
  * the kind of dependency that keeps a package out of a host that made the other

package/src/react/web-push-setup.tsx

@@ -33,7 +33,7 @@ export interface WebPushSetupConfig {
    * asks no permission, creates no subscription, and fails with nothing a user
    * could act on. The check is a config seam rather than a dependency because
    * "is this an installable iOS browser" is a question a host's PWA layer
-   * already answers (future-pay passes
+   * already answers (the origin passes
    * `() => isIosInstallable() && !isStandalone()` from `@12-apps/pwa`).
    */
   needsInstallFirst?: () => boolean;

package/src/server/by-permission.ts

@@ -24,7 +24,7 @@ import type { NotificationRouter } from './router';
  * wrong.
  *
  * The two QUERIES are the host's, through {@link NotificationAudienceDirectory}
- * — because an authorization engine is host machinery. In future-pay this
+ * — because an authorization engine is host machinery. In the extraction origin this
  * module could not live in a package at all: it needed `notify()` AND the RBAC
  * engine, and neither package could see the other. Inverting the dependency
  * (the host answers, the package asks) is what makes it portable.
@@ -34,7 +34,7 @@ import type { NotificationRouter } from './router';
  * The host's authorization engine, as this fan-out needs it.
  *
  * `listCandidates` must be BOUNDED to people who actually hold a role at the
- * tenant. future-pay's implementation requires a role grant, which is what
+ * tenant. that host's implementation requires a role grant, which is what
  * keeps a store's storefront BUYERS — who all carry a default membership — out
  * of a loop that resolves permissions one user at a time.
  *

package/src/server/context.ts

@@ -1,4 +1,4 @@
-import type { NotificationMessages } from '../messages';
+import type { NotificationWireMessages } from '../messages';
 import { NOTIFICATION_CHANNELS, type NotificationChannel } from '../types';
 
 /**
@@ -96,7 +96,7 @@ export function guarded(
 // Body / query parsing — the request contract, in the package
 // ---------------------------------------------------------------------------
 
-function asRecord(body: unknown, messages: NotificationMessages): Record<string, unknown> {
+function asRecord(body: unknown, messages: NotificationWireMessages): Record<string, unknown> {
   if (typeof body !== 'object' || body === null || Array.isArray(body)) {
     throw new NotificationsApiError(400, messages.invalidBody);
   }
@@ -104,7 +104,7 @@ function asRecord(body: unknown, messages: NotificationMessages): Record<string,
 }
 
 /** 1..100 non-empty string ids. */
-function parseIds(value: unknown, messages: NotificationMessages): string[] {
+function parseIds(value: unknown, messages: NotificationWireMessages): string[] {
   if (!Array.isArray(value) || value.length === 0 || value.length > 100) {
     throw new NotificationsApiError(400, messages.invalidBody);
   }
@@ -120,7 +120,7 @@ function parseIds(value: unknown, messages: NotificationMessages): string[] {
  * Query strings arrive as strings; the store clamps, but a non-number is a
  * client bug and must not silently read as "the default page".
  */
-function parseLimit(raw: string | undefined, messages: NotificationMessages): number | undefined {
+function parseLimit(raw: string | undefined, messages: NotificationWireMessages): number | undefined {
   if (raw === undefined || raw === '') return undefined;
   const limit = Number(raw);
   if (!Number.isInteger(limit) || limit < 1 || limit > 100) {
@@ -131,7 +131,7 @@ function parseLimit(raw: string | undefined, messages: NotificationMessages): nu
 
 function parseFilter(
   raw: string | undefined,
-  messages: NotificationMessages,
+  messages: NotificationWireMessages,
 ): 'all' | 'unread' | undefined {
   if (raw === undefined) return undefined;
   if (raw !== 'all' && raw !== 'unread') {
@@ -143,7 +143,7 @@ function parseFilter(
 /** `GET <mount>/notifications` — `filter`, `cursor`, `limit`. */
 export function parseListQuery(
   query: Record<string, string | undefined>,
-  messages: NotificationMessages,
+  messages: NotificationWireMessages,
 ): { filter?: 'all' | 'unread'; cursor?: string; limit?: number } {
   const filter = parseFilter(query.filter, messages);
   const limit = parseLimit(query.limit, messages);
@@ -157,7 +157,7 @@ export function parseListQuery(
 /** `POST <mount>/notifications/mark-read` — explicit ids, or `all: true`. */
 export function parseMarkReadBody(
   body: unknown,
-  messages: NotificationMessages,
+  messages: NotificationWireMessages,
 ): { all: true } | { ids: string[] } {
   const record = asRecord(body, messages);
   const wantsAll = record.all === true;
@@ -171,7 +171,7 @@ export function parseMarkReadBody(
 }
 
 /** `POST <mount>/notifications/delete` — 1..100 ids. */
-export function parseDeleteBody(body: unknown, messages: NotificationMessages): string[] {
+export function parseDeleteBody(body: unknown, messages: NotificationWireMessages): string[] {
   return parseIds(asRecord(body, messages).ids, messages);
 }
 
@@ -181,7 +181,7 @@ export function parseDeleteBody(body: unknown, messages: NotificationMessages):
  */
 export function parsePreferencesBody(
   body: unknown,
-  messages: NotificationMessages,
+  messages: NotificationWireMessages,
 ): Record<string, Partial<Record<NotificationChannel, boolean>>> {
   const record = asRecord(body, messages);
   const parsed: Record<string, Partial<Record<NotificationChannel, boolean>>> = {};
@@ -194,7 +194,7 @@ export function parsePreferencesBody(
 /** One category's toggles, narrowed onto the closed channel set. */
 function parseToggles(
   value: unknown,
-  messages: NotificationMessages,
+  messages: NotificationWireMessages,
 ): Partial<Record<NotificationChannel, boolean>> {
   const toggles = asRecord(value, messages);
   const row: Partial<Record<NotificationChannel, boolean>> = {};
@@ -210,7 +210,7 @@ function parseToggles(
 const MAX_ENDPOINT_CHARS = 2000;
 const MAX_KEY_CHARS = 500;
 
-function parseEndpoint(value: unknown, messages: NotificationMessages): string {
+function parseEndpoint(value: unknown, messages: NotificationWireMessages): string {
   if (typeof value !== 'string' || value.length === 0 || value.length > MAX_ENDPOINT_CHARS) {
     throw new NotificationsApiError(400, messages.invalidBody);
   }
@@ -231,7 +231,7 @@ function parseEndpoint(value: unknown, messages: NotificationMessages): string {
 /** `POST <mount>/push-subscriptions` — `PushSubscription.toJSON()`. */
 export function parsePushSubscriptionBody(
   body: unknown,
-  messages: NotificationMessages,
+  messages: NotificationWireMessages,
 ): { endpoint: string; keys: { p256dh: string; auth: string } } {
   const record = asRecord(body, messages);
   const keys = asRecord(record.keys, messages);
@@ -248,7 +248,7 @@ export function parsePushSubscriptionBody(
 }
 
 /** `DELETE <mount>/push-subscriptions` — by endpoint. */
-export function parsePushEndpointBody(body: unknown, messages: NotificationMessages): string {
+export function parsePushEndpointBody(body: unknown, messages: NotificationWireMessages): string {
   return parseEndpoint(asRecord(body, messages).endpoint, messages);
 }
 
@@ -262,7 +262,7 @@ export function parsePushEndpointBody(body: unknown, messages: NotificationMessa
  */
 export function parsePushEndpointQuery(
   query: Record<string, string | undefined>,
-  messages: NotificationMessages,
+  messages: NotificationWireMessages,
 ): string | undefined {
   if (query.endpoint === undefined || query.endpoint === '') return undefined;
   return parseEndpoint(query.endpoint, messages);

package/src/server/create-api-notifications.ts

@@ -1,5 +1,5 @@
 import { createGeneratorRegistry, type NotificationGeneratorRegistry } from '../generators';
-import { messagesOf, type NotificationMessages } from '../messages';
+import { messagesOf, type NotificationWireMessages } from '../messages';
 import type { ChannelRow } from '../preferences-core';
 import {
   taxonomyOf,
@@ -105,7 +105,7 @@ export interface NotificationsServerConfig {
   /** The host's authorization engine, for `notifyByPermission`. */
   audience?: NotificationAudienceDirectory;
   /** User-facing copy overrides (pt-BR product copy by default). */
-  messages?: Partial<NotificationMessages>;
+  messages: NotificationWireMessages;
   /** The host's logger. Defaults to the console. */
   logger?: NotificationLogger;
 }
@@ -133,7 +133,7 @@ export interface ApiNotifications {
   /** The declared transports, for diagnostics and availability probes. */
   transports: TransportRegistry;
   /** The copy in force, so a host's own screens can reuse a sentence. */
-  messages: NotificationMessages;
+  messages: NotificationWireMessages;
 }
 
 /** Drop the keys the host left unset, so an absent seam stays absent. */

package/src/server/db.ts

@@ -9,7 +9,7 @@
  * own stores actually pass — so a non-Prisma implementation has a finite,
  * documented surface to satisfy instead of "all of Prisma".
  *
- * What is NOT here: the `users` table. future-pay's router read
+ * What is NOT here: the `users` table. the origin's router read
  * `users.email/phone` directly to answer "can this channel reach them", which
  * is the one thing in the pipeline that belonged to the host all along — a
  * package cannot know the shape of a host's identity table, and a host with

package/src/server/routes.ts

@@ -1,4 +1,4 @@
-import type { NotificationMessages } from '../messages';
+import type { NotificationWireMessages } from '../messages';
 import { NOTIFICATION_CHANNELS, type NotificationChannel } from '../types';
 
 import {
@@ -25,7 +25,7 @@ import type { TransportRegistry } from './transports/registry';
  * Nine routes, and the paths are the PACKAGE's: the shipped react client
  * builds these URLs, so a host that renamed one would be a host whose own bell
  * stopped working. The host names only where the whole block is mounted
- * (future-pay: `/api/account`).
+ * (the origin mounts it at `/api/account`).
  *
  * Route ORDER is preserved by every adapter. Nothing here is shaped `/:id`, so
  * no sibling can capture a literal — but the order is still the contract,
@@ -40,7 +40,7 @@ interface NotificationRoutesDeps {
   transports: TransportRegistry;
   contacts: NotificationContactDirectory;
   categories: readonly string[];
-  messages: NotificationMessages;
+  messages: NotificationWireMessages;
   /** Told when a write actually changed something (for a realtime hint). */
   onInboxChanged?: (userId: string) => void;
 }

package/src/server/transports/drivers.ts

@@ -2,7 +2,7 @@
  * The DRIVER port — the reason a host adds a vendor with a config entry and no
  * code (12-15).
  *
- * future-pay's transports each read `process.env` directly:
+ * the origin's transports each read `process.env` directly:
  * `NOTIFICATIONS_EMAIL_PROVIDER=resend` plus `RESEND_API_KEY`, and a second
  * vendor meant editing the package. That is exactly backwards for a published
  * package — it cannot know a host's variable names, and it must not be the
@@ -101,7 +101,7 @@ export function resolveDriver<TDeclaration extends DriverDeclarationBase, TDrive
  *
  * A relative path is useless in an inbox and a fabricated localhost link is
  * worse than none, so with no `appUrl` configured the link is simply dropped —
- * future-pay's rule, kept.
+ * The origin's rule, kept.
  */
 export function absoluteLink(link: string | undefined, appUrl: string | undefined): string | null {
   if (!link || !appUrl) return null;

package/src/server/transports/registry.ts

@@ -19,7 +19,7 @@ import { whatsAppTransport } from './whatsapp';
  * transports are untouched (open/closed).
  *
  * A mount declares its channels and gets a registry; nothing is process-wide.
- * future-pay registered its four transports as an IMPORT SIDE EFFECT of the
+ * The origin registered its four transports as an IMPORT SIDE EFFECT of the
  * package's root entry, which made "which channels are on" a property of the
  * module graph rather than of any configuration — importing the inbox helpers
  * in a unit test silently armed four transports.