@company-semantics/contracts 42.1.0 → 44.0.0

package/src/user-events/schemas.ts

@@ -0,0 +1,214 @@
+/**
+ * The user-scoped push envelope — every frame the server sends to ONE
+ * authenticated user on a long-lived connection, regardless of domain.
+ *
+ * WHY THIS IS NOT A FIFTH `<Domain>SseEvent`. `ChatSseEvent`,
+ * `ExecutionSseEvent`, `CompanyMdCollabSseEvent` and `ImpersonationSseEvent`
+ * each describe ONE domain's traffic on ONE route. This union describes the
+ * frames any domain may put on the user's connection WITHOUT owning a route or
+ * a union of its own — which is exactly what `resource.invalidated` has been
+ * doing unpublished (backend `src/chat/execution/resource-invalidation.ts`,
+ * redeclared structurally in app `src/hooks/useChatEvents.ts`) since before
+ * there was a place to put it.
+ *
+ * WHAT THIS STREAM IS, STATED SO NOBODY ASSUMES MORE:
+ *
+ *   It is a wake-up channel plus ephemeral cache hints. It is NOT a general
+ *   ordered event log. Publishing a user event grants NO replay guarantee.
+ *
+ * Two rules encode that, and both are load-bearing:
+ *
+ * - **No frame carries an SSE `id:` line.** An id implies a resumable position;
+ *   there is no log behind this stream, so an id would be a lie. (Contrast
+ *   `ExecutionSseEvent`, whose `eventSequence` doubles as `Last-Event-ID`
+ *   because it projects a durable `execution_events` row — ADR-CONT-066.)
+ * - **Delivery is edge-triggered only.** Missing a frame may leave caches stale
+ *   until the next authoritative refresh. That is acceptable because NO
+ *   CORRECTNESS DEPENDS ON INVALIDATIONS — every frame means "re-read this",
+ *   and the read is the authority. Nothing durable may ever be hung off this
+ *   stream without first giving it a real commit-ordered log.
+ */
+import { z } from "zod";
+import type { ResourceKey } from "../resource-keys";
+import { isResourceKeyShape } from "../resource-keys";
+
+/**
+ * Local, not chat's. `chat/schemas.ts` owns a structurally identical helper;
+ * importing it would make a chat frame change a user-events breaking change.
+ */
+const IsoDateString = z.string().datetime();
+
+/**
+ * Fields every frame carries.
+ *
+ * Structurally identical to chat's `BaseEventSchema` on purpose, so folding
+ * chat onto this envelope later is a no-op — but deliberately NOT the same
+ * object, for the reason above.
+ */
+export const UserEventBaseSchema = z.object({
+  v: z.literal(1),
+  timestamp: IsoDateString,
+});
+
+// =============================================================================
+// resource.invalidated — promoted verbatim from the ad-hoc backend interface
+// =============================================================================
+
+/** Upper bound on keys per frame. Keeps the envelope far under NOTIFY's limit. */
+export const MAX_INVALIDATION_KEYS = 16;
+
+/**
+ * A cache-staleness signal. The client refreshes the named keys and shows the
+ * user nothing.
+ *
+ * `keys` validates SHAPE, not VOCABULARY — see `isResourceKeyShape` for why a
+ * vocabulary-strict gate here would reject whole frames on version skew.
+ *
+ * `v` and `timestamp` are OPTIONAL HERE AND NOWHERE ELSE. The frame already on
+ * the wire carries neither; requiring them would make promotion a breaking
+ * change dressed up as a tidy-up. Same carve-out, same reason, as
+ * `CompanyMdCollabConnectedEventSchema`.
+ */
+export const ResourceInvalidatedEventSchema = UserEventBaseSchema.partial({
+  v: true,
+  timestamp: true,
+}).extend({
+  type: z.literal("resource.invalidated"),
+  keys: z
+    .array(z.custom<ResourceKey>(isResourceKeyShape))
+    .min(1)
+    .max(MAX_INVALIDATION_KEYS),
+  /** Correlates the frame with the mutation that caused it. */
+  traceId: z.string().optional(),
+  /**
+   * Entity version — MUST be the entity's own `updatedAt`/`resolvedAt` as epoch
+   * ms, NEVER request time. The client's version gate compares it against the
+   * cached payload's `version`; a request-time value silently re-opens the race
+   * the gate exists to close. (The invariant the backend module already states,
+   * published here so it binds the wire rather than one emitter.)
+   */
+  version: z.number().int().nonnegative(),
+});
+export type ResourceInvalidatedEvent = z.infer<
+  typeof ResourceInvalidatedEventSchema
+>;
+
+// =============================================================================
+// resync — freshness when precision is unavailable
+// =============================================================================
+
+/**
+ * Why the server could not name what changed.
+ *
+ * - `listen-recovered` — the LISTEN connection was down and frames were missed.
+ * - `payload-over-cap`  — a single frame exceeded the NOTIFY payload limit.
+ */
+export const USER_EVENT_RESYNC_REASONS = [
+  "listen-recovered",
+  "payload-over-cap",
+] as const;
+export const UserEventResyncReasonSchema = z.enum(USER_EVENT_RESYNC_REASONS);
+export type UserEventResyncReason = z.infer<typeof UserEventResyncReasonSchema>;
+
+/**
+ * "I could not tell you precisely what changed; re-read everything."
+ *
+ * The client invalidates every resource it subscribes to. One frame type covers
+ * both reasons because they mean the same thing to a client, and because the
+ * alternative in each case is worse:
+ *
+ * - Truncating an over-cap frame yields a SHORTENED `keys` array — a stale
+ *   cache that looks fresh, which is undetectable downstream.
+ * - Dropping it instead leaves that user stale until their next reconnect,
+ *   which may be hours away.
+ *
+ * **Precision is expendable; freshness is not.** A resync costs one refetch
+ * wave and is always correct.
+ */
+export const UserEventResyncSchema = UserEventBaseSchema.partial({
+  v: true,
+  timestamp: true,
+}).extend({
+  type: z.literal("resync"),
+  reason: UserEventResyncReasonSchema,
+});
+export type UserEventResync = z.infer<typeof UserEventResyncSchema>;
+
+// =============================================================================
+// notification.created — an ACCELERATOR, never the source of truth
+// =============================================================================
+
+/**
+ * A durable notification row was written for this user.
+ *
+ * AN ACCELERATOR ONLY. The row is already committed and the inbox
+ * (`GET /api/me/feed`) is the authority; this frame exists so a connected
+ * client sees it without waiting for a refetch. A client that misses it loses
+ * nothing — the row is still there on the next read, which is exactly why this
+ * stream is allowed to stay best-effort.
+ *
+ * That is also why it carries only the id and the unread count, not the
+ * rendered notification. Rendering happens at READ TIME under the reader's
+ * current authority (see `UserNotificationSchema`); a pre-rendered payload on
+ * the wire would be a snapshot of authority taken at write time, which is the
+ * one thing that must not be cached. It would also put entity content on a
+ * `pg_notify` payload, which the transport forbids for its own reasons.
+ *
+ * There is deliberately NO `notification.read` counterpart. Read state is a
+ * mutable column on a row whose id was allocated at creation, so a read event
+ * has no valid position in a stream ordered by anything — it would either move
+ * an id backwards or reuse one already observed. Read state is reconciled from
+ * the authoritative query instead.
+ */
+export const NotificationCreatedEventSchema = UserEventBaseSchema.partial({
+  v: true,
+  timestamp: true,
+}).extend({
+  type: z.literal("notification.created"),
+  /** The row id, so a client that already has it can dedupe. */
+  notificationId: z.string(),
+  /** Total unread after this write, so the badge updates without a fetch. */
+  unreadCount: z.number().int().nonnegative(),
+});
+export type NotificationCreatedEvent = z.infer<
+  typeof NotificationCreatedEventSchema
+>;
+
+// =============================================================================
+// connected — transport-level
+// =============================================================================
+
+/**
+ * The stream is open.
+ *
+ * Modeled for the same reason `CompanyMdCollabConnectedEventSchema` is: without
+ * it, a client that validates EVERY frame logs a parse error on a perfectly
+ * normal connect.
+ */
+export const UserEventConnectedSchema = UserEventBaseSchema.partial({
+  v: true,
+  timestamp: true,
+}).extend({ type: z.literal("connected") });
+export type UserEventConnected = z.infer<typeof UserEventConnectedSchema>;
+
+// =============================================================================
+// The union
+// =============================================================================
+
+/**
+ * Every frame the user-scoped stream emits.
+ *
+ * Registered as the OpenAPI component `UserSseEvent`, per the `ChatSseEvent` /
+ * `ExecutionSseEvent` / `CompanyMdCollabSseEvent` precedent.
+ *
+ * `server_drain` is deliberately NOT modeled: the stream already emits it under
+ * its own SSE `event:` name and the client binds a dedicated out-of-band
+ * listener for it. Adding it here would create two handling paths for one frame.
+ */
+export const UserSseEventSchema = z.discriminatedUnion("type", [
+  ResourceInvalidatedEventSchema,
+  NotificationCreatedEventSchema,
+  UserEventResyncSchema,
+  UserEventConnectedSchema,
+]);
+export type UserSseEvent = z.infer<typeof UserSseEventSchema>;

package/src/user-notifications/README.md

@@ -0,0 +1,72 @@
+# user-notifications/
+
+## Purpose
+
+The published shapes of the **durable in-app inbox** — informational facts
+addressed to one user, which they can only look at — and of the **merged feed**
+that renders them alongside action items at the top of `/me/work`.
+
+## Invariants
+
+- **A stored row holds IDENTIFIERS ONLY**: `kind` plus a `ref` of ids. No
+  titles, no paths, no names, no bodies. Everything in `UserNotificationSchema`
+  that reads like prose is produced at READ TIME by the producing domain's
+  renderer, under the reader's CURRENT authority.
+- **A stored row therefore never contains protected content**, so a stale row
+  cannot leak one. This is the invariant the whole design turns on: it is what
+  makes copy evolution a renderer change rather than a migration, and what makes
+  revocation a re-check rather than a backfill.
+- **`href` is nullable and a tombstone is a legitimate render.** A reader who
+  lost access, or whose client cannot decode the stored `ref_version`, still
+  sees that the thing happened — it simply does not link anywhere. "You were
+  granted access to something you can no longer see" is true and worth saying.
+- **Feed ordering is grouped, not chronologically interleaved.** Actionable rows
+  first, then informational rows newest-first. "Merged feed" names one visual
+  surface, not one timeline.
+- **Only notifications paginate.** Action items are already bounded and are
+  standing state, not a timeline. Page 1 = all action items + the first page of
+  notifications; every later page is notifications only. Paginating two
+  independent sources against one cursor is where merged feeds go wrong.
+- **`unreadCount` is total, never windowed.** A windowed count under-reports the
+  moment the inbox exceeds one page, and it drives a badge whose whole job is to
+  be trusted.
+- **The cursor encodes `(createdAt, id)`.** The id breaks ties so two rows
+  written in one transaction cannot straddle a page boundary and be served twice
+  or skipped.
+
+## Public API
+
+| Export                      | Description                                                    |
+| --------------------------- | -------------------------------------------------------------- |
+| `UserNotificationSchema`    | One informational row, as rendered                             |
+| `USER_NOTIFICATION_KINDS`   | The closed kind vocabulary                                     |
+| `FeedItemSchema`            | `actionable` \| `informational`, discriminated on `row`        |
+| `FeedListResponseSchema`    | `GET /api/me/feed` — items, nextCursor, unreadCount, truncated |
+| `FeedMarkReadRequestSchema` | `POST /api/me/feed/read`                                       |
+
+## Dependencies
+
+- `zod` — schemas are canonical, types are inferred.
+- `../action-items` — `ActionItemSchema`, `ActionItemTargetSchema`. The feed
+  UNIONS with action items; it does not redefine them, and it does not modify
+  them.
+
+## How this differs from the two vocabularies beside it
+
+Three things in this package look like "a notification". ADR-CONT-104 forbids
+collapsing the first two; this adds a third rather than bending either:
+
+- **`NotificationKind`** (`../notifications`) names a message that **leaves the
+  building** — composed into prose, delivered once to an address, lifecycle over
+  at send.
+- **`ActionItemKind`** (`../action-items`) names **standing state** — a decision
+  you owe, re-derived on every read, gone the moment anyone resolves it. Never
+  stored, no read state.
+- **`UserNotificationKind`** names a **stored fact about the past**, addressed to
+  one person, that they can only look at. `action-items/kinds.ts` named this gap
+  itself: _"a kind whose item cannot be acted on is not an action item — that is
+  the informational feed, which this layer does not model (yet)."_
+
+They are not in bijection. `companyMd.access_request_pending` is an action item
+and deliberately has **no** member here: the owner can resolve it, so modelling
+it in both places would give one fact two lifecycles that could disagree.

package/src/user-notifications/__tests__/README.md

@@ -0,0 +1,43 @@
+# user-notifications/\_\_tests\_\_/
+
+## Purpose
+
+Locks the claims `../README.md` and ADR-CONT-108 make that the compiler cannot.
+
+- `vocabulary.test.ts` — four things a type signature does not say:
+  1. **The three vocabularies stay disjoint.** `UserNotificationKind`,
+     `ActionItemKind` and `NotificationKind` overlap in subject matter and look
+     mergeable; they are not, because a notification's lifecycle ends at send, an
+     action item's ends when anyone resolves it, and one of these ends never.
+     Specifically: `companyMd.access_request_pending` must NOT appear here — it
+     is resolvable, so modelling it in both places would give one fact two
+     lifecycles that could disagree.
+  2. **A tombstone parses.** `href: null` is a legitimate render, not a
+     degenerate one: a reader who lost access still learns the thing happened.
+     If this stops parsing, revocation silently becomes an error path.
+  3. **`FeedItem` discriminates on `row`, not on field-sniffing.** A client must
+     never have to infer "informational" from the presence of `readAt`.
+  4. **The response carries no field named `version`.** The app's
+     `invalidateResource` probes cached payloads for that name structurally and
+     SKIPS the invalidation when the cached value is at least as new — the same
+     trap `action-items/__tests__` guards, and it would wedge the feed badge
+     with no error anywhere.
+
+## Invariants
+
+- These assert VOCABULARY and SHAPE, never behaviour. Anything needing a
+  renderer, a database or an authority gate belongs in backend's
+  `src/user-notifications/__tests__/`.
+- The disjointness test reads the real kind arrays rather than restating them. A
+  hand-copied list drifts and starts passing vacuously.
+- Negative cases mutate ONE field of a well-formed fixture. A hand-built broken
+  object can pass for the wrong reason.
+
+## Public API
+
+None — test-only.
+
+## Dependencies
+
+`vitest`, the sibling modules under test, and `../../action-items` /
+`../../notifications` for the real kind lists.

package/src/user-notifications/__tests__/vocabulary.test.ts

@@ -0,0 +1,170 @@
+/**
+ * The inbox vocabulary's invariants, as tests rather than prose (ADR-CONT-108).
+ */
+import { describe, it, expect } from "vitest";
+import { USER_NOTIFICATION_KINDS } from "../kinds.js";
+import {
+  FeedItemSchema,
+  FeedListResponseSchema,
+  UserNotificationSchema,
+} from "../schemas.js";
+import { ACTION_ITEM_KINDS } from "../../action-items/index.js";
+import { NOTIFICATION_DEFINITIONS } from "../../notifications/index.js";
+
+const ORG_DOC = "22222222-2222-4222-8222-222222222222";
+
+function makeNotification(over: Record<string, unknown> = {}) {
+  return {
+    id: "n-1",
+    kind: "companyMd.access_request_approved",
+    target: { type: "company_md", id: ORG_DOC },
+    unitPath: "acme.sales",
+    title: "Dev Patel approved your request",
+    detail: null,
+    contextLabel: "Q3 OKRs",
+    href: "/@acme/md/doc-1",
+    createdAt: "2026-07-30T12:00:00.000Z",
+    readAt: null,
+    ...over,
+  };
+}
+
+describe("the three vocabularies stay disjoint", () => {
+  it("shares no member with ActionItemKind", () => {
+    // They overlap in SUBJECT MATTER and look mergeable. They are not: an
+    // action item is standing state that ends when anyone resolves it; one of
+    // these is a stored fact that ends never.
+    const actionItems = new Set<string>(ACTION_ITEM_KINDS);
+    for (const kind of USER_NOTIFICATION_KINDS) {
+      expect(actionItems.has(kind)).toBe(false);
+    }
+  });
+
+  it("does NOT model the pending request, which is resolvable", () => {
+    // The load-bearing case. `companyMd.access_request_pending` is an ACTION
+    // ITEM — the owner can settle it. A durable twin would give one fact two
+    // lifecycles that could disagree: resolve the action item and the stored
+    // row would still claim something is pending.
+    expect(USER_NOTIFICATION_KINDS).not.toContain(
+      "companyMd.access_request_pending",
+    );
+  });
+
+  it("names kinds in {domain}.{type} form, matching both siblings", () => {
+    for (const kind of USER_NOTIFICATION_KINDS) {
+      expect(kind).toMatch(/^[a-z][a-zA-Z0-9]*\.[a-z][a-z0-9_]*$/);
+    }
+  });
+
+  it("overlaps NotificationKind by NAME without inheriting its lifecycle", () => {
+    // Reading the real definitions rather than restating them, so this cannot
+    // pass vacuously. An overlap here is EXPECTED and fine — the email and the
+    // stored row are two different things about one event. What must not happen
+    // is one union being derived from the other.
+    const sent = new Set(Object.keys(NOTIFICATION_DEFINITIONS));
+    const shared = USER_NOTIFICATION_KINDS.filter((k) => sent.has(k));
+    expect(shared.length).toBeGreaterThan(0);
+    expect(USER_NOTIFICATION_KINDS.length).not.toBe(sent.size);
+  });
+});
+
+describe("UserNotificationSchema", () => {
+  it("parses a well-formed row", () => {
+    expect(UserNotificationSchema.safeParse(makeNotification()).success).toBe(
+      true,
+    );
+  });
+
+  it("parses a TOMBSTONE — href null is a legitimate render", () => {
+    // A reader who lost access, or whose client cannot decode the stored
+    // ref_version, still learns the thing happened. If this stops parsing,
+    // revocation silently becomes an error path instead of a render.
+    expect(
+      UserNotificationSchema.safeParse(makeNotification({ href: null }))
+        .success,
+    ).toBe(true);
+  });
+
+  it("carries read state, unlike an action item", () => {
+    const read = UserNotificationSchema.parse(
+      makeNotification({ readAt: "2026-07-30T13:00:00.000Z" }),
+    );
+    expect(read.readAt).not.toBeNull();
+  });
+
+  it("rejects an unknown kind", () => {
+    expect(
+      UserNotificationSchema.safeParse(makeNotification({ kind: "made.up" }))
+        .success,
+    ).toBe(false);
+  });
+});
+
+describe("FeedItem discriminates on `row`", () => {
+  it("accepts an informational row", () => {
+    const parsed = FeedItemSchema.safeParse({
+      row: "informational",
+      notification: makeNotification(),
+    });
+    expect(parsed.success).toBe(true);
+  });
+
+  it("accepts an actionable row", () => {
+    const parsed = FeedItemSchema.safeParse({
+      row: "actionable",
+      item: {
+        id: "companyMd.access_request_pending:req-1",
+        kind: "companyMd.access_request_pending",
+        target: { type: "company_md", id: ORG_DOC },
+        unitPath: null,
+        title: "Maya Chen wants access",
+        detail: null,
+        contextLabel: "Q3 OKRs",
+        href: "/@acme/md/doc-1?share=1&request=req-1",
+        createdAt: "2026-07-30T12:00:00.000Z",
+      },
+    });
+    expect(parsed.success).toBe(true);
+  });
+
+  it("cannot be satisfied by field-sniffing — the tag is required", () => {
+    // A client must never infer "informational" from the presence of `readAt`.
+    expect(
+      FeedItemSchema.safeParse({ notification: makeNotification() }).success,
+    ).toBe(false);
+  });
+});
+
+describe("FeedListResponse", () => {
+  const base = {
+    items: [],
+    nextCursor: null,
+    unreadCount: 0,
+    truncated: false,
+  };
+
+  it("parses an empty feed", () => {
+    expect(FeedListResponseSchema.safeParse(base).success).toBe(true);
+  });
+
+  it("carries a cursor for the next page of informational rows", () => {
+    expect(
+      FeedListResponseSchema.safeParse({ ...base, nextCursor: "opaque" })
+        .success,
+    ).toBe(true);
+  });
+
+  it("has NO field named `version`", () => {
+    // The app's invalidateResource probes cached payloads for that name
+    // structurally and SKIPS the invalidation when the cached value is at least
+    // as new. A field of that name here would wedge the feed badge with no
+    // error anywhere. Same trap `action-items/__tests__` guards.
+    expect(Object.keys(FeedListResponseSchema.shape)).not.toContain("version");
+  });
+
+  it("rejects a negative unread count", () => {
+    expect(
+      FeedListResponseSchema.safeParse({ ...base, unreadCount: -1 }).success,
+    ).toBe(false);
+  });
+});

package/src/user-notifications/index.ts

@@ -0,0 +1,25 @@
+/**
+ * user-notifications/ — the durable in-app inbox, and the merged feed that
+ * renders it alongside action items.
+ *
+ * See ./README.md for the domain, and ADR-CONT-108 for why this is a third
+ * vocabulary rather than a bend in either of the two beside it.
+ */
+
+export { USER_NOTIFICATION_KINDS } from "./kinds";
+export type { UserNotificationKind } from "./kinds";
+
+export {
+  FeedItemSchema,
+  FeedListResponseSchema,
+  FeedMarkReadRequestSchema,
+  UserNotificationKindSchema,
+  UserNotificationSchema,
+} from "./schemas";
+
+export type {
+  FeedItem,
+  FeedListResponse,
+  FeedMarkReadRequest,
+  UserNotification,
+} from "./schemas";

package/src/user-notifications/kinds.ts

@@ -0,0 +1,69 @@
+/**
+ * What kinds of durable in-app notification exist.
+ *
+ * A user notification is an INFORMATIONAL row addressed to one user: something
+ * that happened which they should know about and cannot act on. It is stored,
+ * it has read state, and it survives the user being offline.
+ *
+ * WHY THIS IS A THIRD VOCABULARY, alongside `NotificationKind` and
+ * `ActionItemKind` (ADR-CONT-104 forbids collapsing those two; this adds a
+ * third rather than bending either):
+ *
+ * - `NotificationKind` names a message that LEAVES THE BUILDING — an email or a
+ *   Slack post, composed by a render pipeline into prose carrying a brand and a
+ *   year, delivered once to an address. Its lifecycle ends at send.
+ * - `ActionItemKind` names STANDING STATE — a decision you owe, re-derived from
+ *   its domain's pending rows on every read, which stops existing the moment
+ *   anyone resolves it. It is never stored and has no read state, because
+ *   "resolved" is the only clearing mechanism it needs.
+ * - A user notification is neither. It is a FACT about the past, addressed to
+ *   one person, which they can only look at. `action-items/kinds.ts` already
+ *   named this gap: "a kind whose item cannot be acted on is not an action item
+ *   — that is the informational feed, which this layer does not model (yet)."
+ *   This is that layer.
+ *
+ * The three are not in bijection and never will be. `auth.otp` is a
+ * notification and can be neither of the others. `execution.confirmation_pending`
+ * is an action item with no notification. `companyMd.access_request_approved` is
+ * all three shapes' subject matter and gets a member in each, because the email,
+ * the (now absent) pending decision, and the durable "you were granted access"
+ * row are three different things with three different lifecycles.
+ *
+ * INVARIANTS:
+ * - `{domain}.{type}` dot notation, matching both sibling unions.
+ * - These strings go on the wire AND into a database column. Renaming one is a
+ *   migration, not a tidy-up.
+ * - A kind earns membership by being something a user should be able to come
+ *   back to. If it is only worth seeing while connected, it is a transient
+ *   frame on the user-event stream, not a row here.
+ * - A kind's row stores IDENTIFIERS ONLY (see `./schemas`). Copy lives in the
+ *   producing domain's renderer and is resolved at read time.
+ */
+
+// =============================================================================
+// UserNotificationKind Union
+// =============================================================================
+
+/**
+ * New kinds MUST be added to:
+ * 1. This union
+ * 2. A `NotificationRenderer` in the PRODUCING domain, which applies that
+ *    domain's own authority gate in bulk and returns a tombstone when the
+ *    reader may no longer see the referenced entity
+ *
+ * The three members below are the informational half of the company.md
+ * request-access lifecycle. Note what is NOT here:
+ * `companyMd.access_request_pending` is an ACTION ITEM — the owner can resolve
+ * it, so it is standing state, and modelling it here as well would give one
+ * fact two lifecycles that could disagree.
+ */
+export const USER_NOTIFICATION_KINDS = [
+  /** Someone asked for access to a doc you own. Informational twin of the action item. */
+  "companyMd.access_requested",
+  /** Your request was approved — you now have access. */
+  "companyMd.access_request_approved",
+  /** Your request was declined. */
+  "companyMd.access_request_denied",
+] as const;
+
+export type UserNotificationKind = (typeof USER_NOTIFICATION_KINDS)[number];