@lssm-tech/lib.notification
Library-first notification helpers for ContractSpec applications.
This package owns reusable notification entities, schema contributions, channels, templates, and i18n catalogs. Canonical notification contracts, capability metadata, and feature metadata are re-exported from @lssm-tech/lib.contracts-spec/notifications.
Compatibility
notificationsSchemaContribution.moduleId is @lssm-tech/lib.notification.legacyNotificationsSchemaContribution.moduleId is @lssm-tech/module.notifications.- The deprecated
@lssm-tech/module.notifications package remains available as a compatibility shim for existing consumers.
CommunicationOS migration
./legacy-preferences converts legacy notification JSON into sealed CommunicationOS preference sets while preserving the complete source snapshot and every unmapped value. Enabled external routes without a consent reference require review instead of silently becoming deliverable.
./communication-os compiles a legacy notification request into the canonical CommunicationOS routing input through an injected port. It returns a prepared or blocked decision only: the facade has no provider dependency, credential, send tool, fallback authority, or external-effect authority. Existing channel and template helpers remain available during the compatibility window.
Product channel composition
./product-channels composes a product's notification preference center and producer on CommunicationOS routing. A product binding (PACTENA_NOTIFICATION_BINDING_V1, HCIRCLE_NOTIFICATION_BINDING_V1,
PERSONALOS_NOTIFICATION_BINDING_V1) names the product, application, agent, policy and feature refs and the channels it offers; in_app is mandatory as the durable fallback terminal.
createProductNotificationPreferenceCenterV1 reads and commits one person's explicit choices through a revision-CAS store. An unset record reads as in-app only, external channels need an explicit consent ref, and disabling a channel drops its consent.createProductNotificationProducerV1 turns those choices into host-resolved opaque routes, a platform -> person -> product preference chain and a sealed profile, prepares the delivery through the CommunicationOS facade and hands the authority-free prepared delivery to the host admission port. A requested channel without an enabled, consented route degrades to the in-app terminal. The request's scope must name the person notified (subjectRef equals
userRef), otherwise it is blocked with scope_mismatch.
Preference records are keyed by product, person and full scope (productNotificationPreferenceKeyV1): a person in several tenants, workspaces or spaces holds one independent record per scope, and a store's
load and compareAndSet must use that key. Hosts mint consent evidence from the authenticated session with mintProductNotificationConsentRefV1 (product, channel, person and the revision at which consent was affirmed) instead of storing client-supplied text.
The host (ProductNotificationHostV1) supplies CommunicationOS routing, the route directory, eligibility evidence and Runtime Node delivery admission. Without a host or store every call returns a no-detail unavailable outcome; the producer never dispatches a provider. ./product-channels/testing is a local fake host and scope-keyed in-memory store for tests and must not be bound in a deployed host.
