@mohasinac/appkit 4.30.18 → 4.31.0

package/dist/_internal/server/jobs/core/pageViewPrune.js

@@ -0,0 +1,44 @@
+/*
+ * WHY: `pageViews` writes one document per entity per day and had NO prune.
+ *      Twenty-seven scheduled functions existed — `cartPrune`,
+ *      `notificationPrune`, `draftPrune`, `dailyDataCleanup` — and not one of
+ *      them touched this collection, so it was the only unbounded writer in the
+ *      system. Its size was capped by nothing except how many distinct pages
+ *      the catalogue had, multiplied by how long the site had been running.
+ *
+ * WHAT: Delete day-buckets older than the retention window. Shaped after
+ *       `notificationPrune`, which is the smallest correct prune in the repo.
+ *
+ * The daily rows are the raw material; `pageViewRollup` keeps the long-run
+ * totals, so deleting the buckets loses granularity past the window and not the
+ * history itself.
+ *
+ * EXPORTS: PAGE_VIEW_TTL_DAYS, runPageViewPrune
+ *
+ * @tag domain:analytics
+ * @tag layer:job
+ * @tag pattern:none
+ * @tag access:server-only
+ * @tag consumers:pageViewPrune scheduled function
+ * @tag sideEffects:deletes pageViews documents
+ */
+import { pageViewsRepository } from "../../../../features/analytics/repository/page-views.repository";
+import { batchDelete } from "../handlers/_helpers";
+/**
+ * 90 days.
+ *
+ * Long enough for a quarter-over-quarter comparison in the admin report, which
+ * is the longest range that screen offers, and short enough that the collection
+ * reaches a steady state instead of growing forever.
+ */
+export const PAGE_VIEW_TTL_DAYS = 90;
+export async function runPageViewPrune(ctx) {
+    ctx.logger.info(`Pruning page-view buckets older than ${PAGE_VIEW_TTL_DAYS} days`);
+    const refs = await pageViewsRepository.getOlderThanRefs(PAGE_VIEW_TTL_DAYS);
+    if (refs.length === 0) {
+        ctx.logger.info("No stale page-view buckets found");
+        return;
+    }
+    const deleted = await batchDelete(ctx, refs);
+    ctx.logger.info("Page-view prune complete", { deleted });
+}

package/dist/_internal/server/jobs/core/pageViewRollup.d.ts

@@ -0,0 +1,2 @@
+import type { JobContext } from "../runtime/types";
+export declare function runPageViewRollup(ctx: JobContext): Promise<void>;

package/dist/_internal/server/jobs/core/pageViewRollup.js

@@ -0,0 +1,87 @@
+/*
+ * WHY: `pageViewPrune` deletes day-buckets past the retention window. Without a
+ *      rollup that would also delete the only record that those views ever
+ *      happened — the admin's lifetime total would silently walk backwards as
+ *      the prune caught up with it.
+ *
+ * WHAT: Fold each new day-bucket into a singleton total before the prune can
+ *       reach it. Modelled on `revenueRollup`: scan → one small doc → the API
+ *       route reads a single document instead of the collection.
+ *
+ * EXPORTS: runPageViewRollup
+ *
+ * @tag domain:analytics
+ * @tag layer:job
+ * @tag pattern:none
+ * @tag access:server-only
+ * @tag consumers:pageViewRollup scheduled function
+ * @tag sideEffects:writes analytics/pageViewRollup
+ */
+import { pageViewsRepository } from "../../../../features/analytics/repository/page-views.repository";
+import { pageViewRollupRepository } from "../../../../features/admin/repository/analytics-rollup.repository";
+/** The earliest date this rollup will fold in on a cold start. */
+const EPOCH_DATE = "2020-01-01";
+function dayKey(offsetDays) {
+    const d = new Date();
+    d.setUTCDate(d.getUTCDate() + offsetDays);
+    return d.toISOString().slice(0, 10);
+}
+export async function runPageViewRollup(ctx) {
+    const existing = await pageViewRollupRepository.get();
+    /*
+     * 🛑 `throughDate` is what makes this job re-runnable.
+     *
+     * The rollup ACCUMULATES rather than recomputing — the day-buckets it has
+     * already folded in get deleted by `pageViewPrune`, so a recompute-from-
+     * scratch would produce a total that shrinks every time the prune runs. So it
+     * must only ever read buckets it has not seen, and `throughDate` is the
+     * boundary. Running this twice in one day is a no-op; running it after a
+     * missed day still catches up.
+     */
+    const from = existing?.throughDate
+        ? dayKey(0) === existing.throughDate
+            ? null // already folded in today — nothing new to read
+            : nextDay(existing.throughDate)
+        : EPOCH_DATE;
+    if (from === null) {
+        ctx.logger.info("pageViewRollup: already current", {
+            throughDate: existing?.throughDate ?? "",
+        });
+        return;
+    }
+    // Yesterday, not today: today's buckets are still being written to, and
+    // folding a partial day in would make it uncountable tomorrow.
+    const through = dayKey(-1);
+    if (from > through) {
+        ctx.logger.info("pageViewRollup: nothing to fold", { from, through });
+        return;
+    }
+    /*
+     * No `.catch(() => [])`. An empty range is a legitimate zero, so a swallowed
+     * query failure would write a confident "no views" the dashboard cannot tell
+     * from the real thing — and unlike `revenueRollup`, this one ACCUMULATES, so
+     * a bad read would also advance `throughDate` past days it never counted and
+     * lose them permanently. Let it throw; the runner records the failure and the
+     * stale-but-correct singleton stays.
+     */
+    const buckets = await pageViewsRepository.listInRange(from, through);
+    const byEntityType = { ...(existing?.byEntityType ?? {}) };
+    let totalViews = existing?.totalViews ?? 0;
+    for (const b of buckets) {
+        const n = Number(b.count) || 0;
+        totalViews += n;
+        byEntityType[b.entityType] = (byEntityType[b.entityType] ?? 0) + n;
+    }
+    await pageViewRollupRepository.set({ totalViews, byEntityType, throughDate: through });
+    ctx.logger.info("pageViewRollup: complete", {
+        from,
+        through,
+        bucketsFolded: buckets.length,
+        totalViews,
+    });
+}
+function nextDay(dateKey) {
+    const d = new Date(`${dateKey}T00:00:00.000Z`);
+    d.setUTCDate(d.getUTCDate() + 1);
+    return d.toISOString().slice(0, 10);
+}

package/dist/_internal/server/jobs/core/revenueRollup.js

@@ -12,7 +12,13 @@
 import { orderRepository } from "../../../../repositories";
 import { analyticsRollupRepository } from "../../../../repositories";
 export async function runRevenueRollup(ctx) {
-    const deliveredOrders = await orderRepository.findByStatus("delivered").catch(() => []);
+    // No `.catch(() => [])` here on purpose: an empty list is a legitimate
+    // outcome that writes `totalRevenue: 0`, so swallowing a query failure would
+    // overwrite yesterday's correct rollup with a confident zero that the
+    // dashboard has no way to distinguish from "no delivered orders". Let it
+    // throw — the job runner records the failure and the stale-but-correct
+    // singleton stays put.
+    const deliveredOrders = await orderRepository.findByStatus("delivered");
     const totalRevenue = deliveredOrders.reduce((sum, order) => sum + (Number(order.totalPrice ?? 0) || 0), 0);
     await analyticsRollupRepository.setDashboardRollup({
         totalRevenue,

package/dist/_internal/server/jobs/handlers/index.d.ts

@@ -28,6 +28,8 @@ export { hardBanReinstatementHandler } from "./hardBanReinstatement";
 export { paymentReviewAutoApproveHandler } from "./paymentReviewAutoApprove";
 export { productStatsSyncHandler } from "./productStatsSync";
 export { revenueRollupHandler } from "./revenueRollup";
+export { pageViewRollupHandler } from "./pageViewRollup";
+export { pageViewPruneHandler } from "./pageViewPrune";
 export { dailyStatusDigestHandler } from "./dailyStatusDigest";
 export { positionsReconcileHandler } from "./positionsReconcile";
 export { payoutBatchHandler } from "./payoutBatch";

package/dist/_internal/server/jobs/handlers/index.js

@@ -28,6 +28,8 @@ export { hardBanReinstatementHandler } from "./hardBanReinstatement";
 export { paymentReviewAutoApproveHandler } from "./paymentReviewAutoApprove";
 export { productStatsSyncHandler } from "./productStatsSync";
 export { revenueRollupHandler } from "./revenueRollup";
+export { pageViewRollupHandler } from "./pageViewRollup";
+export { pageViewPruneHandler } from "./pageViewPrune";
 export { dailyStatusDigestHandler } from "./dailyStatusDigest";
 export { positionsReconcileHandler } from "./positionsReconcile";
 export { payoutBatchHandler } from "./payoutBatch";

package/dist/_internal/server/jobs/handlers/pageViewPrune.d.ts

@@ -0,0 +1,2 @@
+import type { ScheduleHandler } from "../runtime/types";
+export declare const pageViewPruneHandler: ScheduleHandler;

package/dist/_internal/server/jobs/handlers/pageViewPrune.js

@@ -0,0 +1,2 @@
+import { runPageViewPrune } from "../core/pageViewPrune";
+export const pageViewPruneHandler = runPageViewPrune;

package/dist/_internal/server/jobs/handlers/pageViewRollup.d.ts

@@ -0,0 +1,2 @@
+import type { ScheduleHandler } from "../runtime/types";
+export declare const pageViewRollupHandler: ScheduleHandler;

package/dist/_internal/server/jobs/handlers/pageViewRollup.js

@@ -0,0 +1,2 @@
+import { runPageViewRollup } from "../core/pageViewRollup";
+export const pageViewRollupHandler = runPageViewRollup;

package/dist/_internal/shared/actions/action-registry.d.ts

@@ -29,7 +29,7 @@ import type { IconKey } from "../../../ui/icons/icon-registry";
 /** What KIND of action — drives default UI affordance (link vs button vs danger). */
 export type ActionKind = "primary" | "secondary" | "danger" | "ghost" | "link" | "chip";
 /** Resource bucket — keyed top-level in the ACTIONS tree. */
-export type ActionResource = "PRODUCT" | "AUCTION" | "PRE_ORDER" | "PRIZE_DRAW" | "CLASSIFIED" | "DIGITAL_CODE" | "LIVE" | "BUNDLE" | "GROUP" | "CATEGORY" | "BRAND" | "SUBLISTING" | "STORE" | "BLOG" | "EVENT" | "SHIPMENT" | "CATALOGUE" | "USER" | "SELLER" | "ADMIN" | "CART" | "CHECKOUT" | "NAV" | "MEDIA" | "SUPPORT" | "LOTTERY" | "TESTER";
+export type ActionResource = "PRODUCT" | "AUCTION" | "PRE_ORDER" | "PRIZE_DRAW" | "DIGITAL_CODE" | "BUNDLE" | "GROUP" | "CATEGORY" | "BRAND" | "SUBLISTING" | "STORE" | "BLOG" | "EVENT" | "SHIPMENT" | "CATALOGUE" | "USER" | "SELLER" | "ADMIN" | "CART" | "CHECKOUT" | "NAV" | "MEDIA" | "SUPPORT" | "LOTTERY" | "TESTER";
 /** Confirmation modal config — when set, <Button action={...}> opens
  *  a confirm dialog before firing the actual handler. */
 export interface ActionConfirmation {

package/dist/_internal/shared/actions/action-registry.js

@@ -172,9 +172,17 @@ export const ACTIONS = {
             iconKey: "message",
             id: "product.make-offer",
             label: "Make an offer",
-            description: "Propose a price to the seller for a classified listing.",
+            /*
+             * Scope corrected 2026-08-31: this was `["classified"]`, but the button it
+             * labels (`MakeOfferButton`) mounts on every type whose capability says
+             * `canMakeOffer` — which is standard, art and stickers as well. On
+             * classified specifically it is the ONLY purchase path, and a seller who
+             * has not opted into haggling receives a request to buy at the asking
+             * price rather than a lower offer.
+             */
+            description: "Propose a price to the seller, or request to buy at the asking price.",
             kind: "secondary",
-            listingTypeScope: ["classified"],
+            listingTypeScope: ["standard", "classified", "art", "stickers"],
         },
     },
     AUCTION: {
@@ -271,16 +279,15 @@ export const ACTIONS = {
             listingTypeScope: ["prize-draw"],
         },
     },
-    CLASSIFIED: {
-        "contact-seller": {
-            iconKey: "message",
-            id: "classified.contact-seller",
-            label: "Contact seller",
-            description: "Open a conversations thread with the seller — classified flow (SB-UNI-M).",
-            kind: "primary",
-            listingTypeScope: ["classified"],
-        },
-    },
+    /*
+     * `CLASSIFIED` held one entry, "contact-seller", whose description read
+     * "Open a conversations thread with the seller". It had ZERO consumers — the
+     * button on the classified PDP was hand-written — and the feature it named was
+     * deleted 2026-08-31. `PRODUCT["make-offer"]` below is the action that is
+     * actually wired (`MakeOfferButton`), and on a classified it is now the only
+     * purchase path, so a second bucket duplicating it would be exactly the drift
+     * Rule #7 exists to prevent.
+     */
     DIGITAL_CODE: {
         "claim-code": {
             iconKey: "confirm",
@@ -291,16 +298,12 @@ export const ACTIONS = {
             listingTypeScope: ["digital-code"],
         },
     },
-    LIVE: {
-        "inquire": {
-            iconKey: "message",
-            id: "live.inquire",
-            label: "Inquire",
-            description: "Open a conversation with the seller about a live-item listing.",
-            kind: "primary",
-            listingTypeScope: ["live"],
-        },
-    },
+    /*
+     * `LIVE.inquire` ("Open a conversation with the seller about a live-item
+     * listing") went the same way and for the same two reasons: no consumer, and
+     * the conversations feature is gone. It was never needed either — a live item
+     * has `canAddToCart: true`, so unlike classified it has a real checkout.
+     */
     BUNDLE: {
         "buy-now": {
             iconKey: "cart",
@@ -879,6 +882,26 @@ export const ACTIONS = {
                 confirmKind: "danger",
             },
         },
+        /*
+         * The alerts list rendered a bare `<Button variant="ghost">Delete</Button>`
+         * with a raw onClick — no ActionDef, so no confirmation, so one misplaced
+         * click silently removed an alert with nothing to undo it (Rule #7).
+         */
+        "delete-analytics-alert": {
+            iconKey: "delete",
+            id: "store.delete-analytics-alert",
+            label: "Delete",
+            ariaLabel: "Delete this analytics alert",
+            description: "Permanently removes this alert rule. Past notifications are unaffected.",
+            kind: "danger",
+            permissions: ["seller", "admin"],
+            confirmation: {
+                title: "Delete this alert?",
+                body: "You will stop being notified when this rule matches. Alerts already sent are unaffected. This cannot be undone.",
+                confirmLabel: "Delete alert",
+                confirmKind: "danger",
+            },
+        },
         "cancel-form": {
             iconKey: "cancel",
             id: "store.cancel-form",
@@ -1197,6 +1220,30 @@ export const ACTIONS = {
                 confirmKind: "danger",
             },
         },
+        /*
+         * A LOT, not the whole shipment.
+         *
+         * The lot row's delete button used `shipment.delete`, so the dialog asked
+         * "Delete this shipment?" and warned about removing every lot — while the
+         * handler deleted one lot. A confirmation that names the wrong object is
+         * worse than none: it is either ignored, or it stops someone doing
+         * something harmless.
+         */
+        "delete-lot": {
+            iconKey: "delete",
+            id: "shipment.delete-lot",
+            label: "Delete",
+            ariaLabel: "Delete this lot and its items",
+            description: "Permanently deletes this lot and every item in it.",
+            kind: "danger",
+            permissions: ["admin"],
+            confirmation: {
+                title: "Delete this lot?",
+                body: "This permanently removes the lot and every item in it. The rest of the shipment is untouched. Items still linked to a product must be unlinked first.",
+                confirmLabel: "Delete lot",
+                confirmKind: "danger",
+            },
+        },
     },
     CATALOGUE: {
         "list-item": {

package/dist/_internal/shared/checkout/rules/classified.rule.d.ts

@@ -1,9 +1,14 @@
 /**
- * Classified listing rule — chat-only, no checkout.
+ * Classified listing rule — no cart, no checkout; the offer IS the purchase path.
  *
- * Classified listings (OLX / Facebook Marketplace pattern) surface a
- * "Contact Seller" CTA that opens a conversations thread.  No cart, no
- * payment, no order. SB-UNI-M will wire the full flow.
+ * Classified listings (OLX / Facebook Marketplace pattern) never reach cart or
+ * order creation. The buyer transacts through Make-an-Offer: the seller accepts,
+ * which produces a locked cart line in the offer lane, and checkout proceeds
+ * from there like any other accepted offer.
+ *
+ * A seller who has not set `allowOffers` still receives requests to buy at their
+ * asking price — see `resolveOfferBounds` in the offers config. Without that,
+ * unchecking one flag would make the listing untransactable.
  */
 import type { ListingCheckoutRule } from "./types";
 export declare const classifiedRule: ListingCheckoutRule;

package/dist/_internal/shared/checkout/rules/classified.rule.js

@@ -1,9 +1,14 @@
 import { DEFAULT_LISTING_RULE } from "./_defaults";
 export const classifiedRule = {
     ...DEFAULT_LISTING_RULE,
-    orderType: "standard", // placeholder — classified never reaches order creation
+    orderType: "standard", // placeholder — a classified reaches order creation only via an accepted offer
     purchaseable: false,
     cartEligible: false,
-    cartIneligibleHint: 'Use "Contact Seller" to arrange a meetup.',
+    /*
+     * Names the control the page actually has. It read 'Use "Contact Seller" to
+     * arrange a meetup' until 2026-08-31, and that button opened a conversations
+     * thread which no longer exists.
+     */
+    cartIneligibleHint: "Make an offer to buy this — classified listings are arranged with the seller.",
     requiresShippingAddress: false,
 };

package/dist/_internal/shared/features/layout/matchesNavQuery.d.ts

@@ -0,0 +1,14 @@
+/** The fields the matcher reads. Everything is optional but `label`. */
+export interface NavSearchable {
+    label: string;
+    description?: string;
+    keywords?: string[];
+}
+/**
+ * How well `item` answers `query`. `0` when it does not.
+ *
+ * The query is matched whole rather than tokenised: "prize draws" should find
+ * Prize Draws, and splitting on spaces would also match anything containing
+ * "draws" on its own, which for a two-word query is nearly everything.
+ */
+export declare function matchesNavQuery(item: NavSearchable, query: string): number;

package/dist/_internal/shared/features/layout/matchesNavQuery.js

@@ -0,0 +1,72 @@
+/*
+ * WHY: The sidebar search was `item.label.toLowerCase().includes(q)` — so it
+ *      could only ever find a screen by the name it already shows you. Typing
+ *      "refund" found nothing, because the screen is called "Payouts"; typing
+ *      "postcode" found nothing, because the field is called PIN code; typing
+ *      "maintenance" found nothing, because the toggle lives inside "Site
+ *      Settings". A search that only matches what is already on screen is a
+ *      filter, not a search.
+ * WHAT: One matcher over label + description + keywords, shared by the sidebar
+ *       search and (in W7) the action index.
+ *
+ * ## Ranking, not just filtering
+ *
+ * A label hit and a keyword hit are not equally good answers. "orders" should
+ * put **Orders** first and "Orders & Finance" (a guide that mentions orders)
+ * second — so the matcher returns a SCORE and the caller sorts by it. Without
+ * that, alphabetical order decides, and the exact match can land ninth.
+ *
+ * EXPORTS: matchesNavQuery, type NavSearchable
+ *
+ * @tag domain:layout
+ * @tag layer:shared
+ * @tag pattern:none
+ * @tag access:isomorphic
+ * @tag consumers:useSidebarSearch,action index
+ * @tag sideEffects:none
+ */
+/** Higher is a better answer. `0` means no match at all. */
+const SCORE = {
+    labelExact: 100,
+    labelPrefix: 80,
+    labelSubstring: 60,
+    keywordExact: 50,
+    keywordSubstring: 30,
+    description: 10,
+};
+/**
+ * How well `item` answers `query`. `0` when it does not.
+ *
+ * The query is matched whole rather than tokenised: "prize draws" should find
+ * Prize Draws, and splitting on spaces would also match anything containing
+ * "draws" on its own, which for a two-word query is nearly everything.
+ */
+export function matchesNavQuery(item, query) {
+    const q = query.trim().toLowerCase();
+    if (!q)
+        return 0;
+    const label = item.label.toLowerCase();
+    if (label === q)
+        return SCORE.labelExact;
+    if (label.startsWith(q))
+        return SCORE.labelPrefix;
+    if (label.includes(q))
+        return SCORE.labelSubstring;
+    for (const keyword of item.keywords ?? []) {
+        const k = keyword.toLowerCase();
+        if (k === q)
+            return SCORE.keywordExact;
+        if (k.includes(q) || q.includes(k))
+            return SCORE.keywordSubstring;
+    }
+    /*
+     * The description is matched LAST and scores lowest on purpose: it is a
+     * sentence, so it contains common words, and letting it outrank a keyword
+     * would mean "shipping" surfaced every screen whose description happens to
+     * mention shipping ahead of the one actually called Shipping.
+     */
+    if (item.description && item.description.toLowerCase().includes(q)) {
+        return SCORE.description;
+    }
+    return 0;
+}

package/dist/_internal/shared/features/layout/types.d.ts

@@ -25,12 +25,48 @@ export interface SidebarNavItem {
     badge?: number;
     /**
      * Stable nav-* slug used as the key in siteSettings.navConfig.
-     * If absent, item is always visible (no admin toggle, no permission check).
+     *
+     * 🛑 **Derived from the href, never hand-written** — `navItemId(portal, href)`.
+     * A hand-written id drifts from the route it names, and because it is also
+     * the `navConfig` key, a drifted id silently un-toggles the item: the admin
+     * hides "Payouts", the toggle writes a key nothing reads, and the entry
+     * stays.
+     *
+     * If absent, the item is always visible — no admin toggle and **no
+     * permission check**, which is why every admin item having no id meant
+     * `requiredPermission` had never once been enforced.
      */
     id?: string;
     /** RBAC permission key — item only shows to users with this permission. */
     requiredPermission?: string;
+    /**
+     * One sentence on what this screen is FOR, in the user's words rather than
+     * the entity's. "Refund a buyer, or check why a payout is late" finds its
+     * screen; "Payouts" only finds itself.
+     *
+     * Consumed by the sidebar search and, in W7, by the action index.
+     */
+    description?: string;
+    /**
+     * Words someone might search for that are not in the label — synonyms
+     * ("postcode" for PIN), the old name of a renamed screen, the noun the rest
+     * of the industry uses.
+     */
+    keywords?: string[];
+    /** Which dashboard this belongs to. Set by the helper alongside `id`. */
+    portal?: NavPortal;
 }
+/** The three dashboards a sidebar item can belong to. */
+export type NavPortal = "admin" | "store" | "user";
+/**
+ * The `navConfig` key for a nav item: `nav-{portal}-{slug-of-href}`.
+ *
+ * Derived rather than authored so an id cannot disagree with the route it
+ * points at. Locale prefixes and dynamic segments are stripped, so
+ * `/en/admin/orders` and `/admin/orders` produce the same key — otherwise a
+ * localised build would write a second set of toggles nobody can find.
+ */
+export declare function navItemId(portal: NavPortal, href: string): string;
 /** Sidebar group with title + items + default-open state. */
 export interface SidebarNavGroup {
     title: string;

package/dist/_internal/shared/features/layout/types.js

@@ -10,4 +10,22 @@
  *  2. render-prop slots on each section (defined on the section component itself).
  *  3. Section replacement via AppShell named slots.
  */
-export {};
+/**
+ * The `navConfig` key for a nav item: `nav-{portal}-{slug-of-href}`.
+ *
+ * Derived rather than authored so an id cannot disagree with the route it
+ * points at. Locale prefixes and dynamic segments are stripped, so
+ * `/en/admin/orders` and `/admin/orders` produce the same key — otherwise a
+ * localised build would write a second set of toggles nobody can find.
+ */
+export function navItemId(portal, href) {
+    const path = href
+        .replace(/^https?:\/\/[^/]+/, "")
+        .replace(/^\/[a-z]{2}(-[A-Z]{2})?(?=\/)/, "")
+        .replace(/[?#].*$/, "")
+        .replace(/^\/+|\/+$/g, "")
+        .replace(/[^a-zA-Z0-9/-]+/g, "-")
+        .replace(/\//g, "-")
+        .toLowerCase();
+    return `nav-${portal}-${path || "root"}`;
+}

package/dist/_internal/shared/features/notifications/action-url.d.ts

@@ -25,7 +25,7 @@
  * When those pages are built, change the entry here and all 40 call sites
  * follow. That is the whole point of the indirection.
  */
-import type { NotificationRelatedType } from "../../../../features/admin/schemas/firestore";
+import type { NotificationRelatedType, NotificationType } from "../../../../features/admin/schemas/firestore";
 /**
  * Which portal the recipient reads this in.
  *
@@ -45,3 +45,11 @@ export type NotificationAudience = "buyer" | "seller" | "admin";
  * looking at.
  */
 export declare function resolveNotificationActionUrl(relatedType: NotificationRelatedType | undefined, relatedId: string | undefined, audience: NotificationAudience): string | undefined;
+/**
+ * Which portal each notification type belongs to.
+ *
+ * `Record<NotificationType, …>`, so a new type cannot compile without an
+ * answer — the same discipline `typeToPrefsKey` needed after it silently
+ * omitted three types and ignored those users' opt-outs.
+ */
+export declare const TYPE_AUDIENCE: Record<NotificationType, NotificationAudience>;

package/dist/_internal/shared/features/notifications/action-url.js

@@ -109,3 +109,50 @@ export function resolveNotificationActionUrl(relatedType, relatedId, audience) {
         }
     }
 }
+/*
+ * Moved here from `features/admin/actions/notification-actions.ts` 2026-08-31.
+ * It belongs beside the resolver it feeds, and being module-private in a
+ * `"use server"` file meant the SEED could not use it — so seeded notifications
+ * carried no `actionUrl` and rendered unclickable, the exact defect the central
+ * resolver was built to end.
+ */
+/**
+ * Which portal each notification type belongs to.
+ *
+ * `Record<NotificationType, …>`, so a new type cannot compile without an
+ * answer — the same discipline `typeToPrefsKey` needed after it silently
+ * omitted three types and ignored those users' opt-outs.
+ */
+export const TYPE_AUDIENCE = {
+    // Buyer-facing: the order lifecycle they are waiting on.
+    order_placed: "buyer",
+    order_confirmed: "buyer",
+    order_shipped: "buyer",
+    order_delivered: "buyer",
+    order_cancelled: "buyer",
+    refund_initiated: "buyer",
+    payment_review: "buyer",
+    emi_installment_due_soon: "buyer",
+    emi_installment_overdue: "buyer",
+    prize_won: "buyer",
+    prize_reveal_expired: "buyer",
+    product_available: "buyer",
+    bid_placed: "buyer",
+    bid_outbid: "buyer",
+    bid_won: "buyer",
+    bid_lost: "buyer",
+    offer_responded: "buyer",
+    offer_counter_accepted: "buyer",
+    offer_expired: "buyer",
+    review_replied: "buyer",
+    catalogue_images_stale: "buyer",
+    // Seller-facing.
+    auction_ended: "seller", // "your auction closed with no winner"
+    offer_received: "seller",
+    review_approved: "seller",
+    // Account-level, which lives in the user portal for everyone.
+    welcome: "buyer",
+    account_action: "buyer",
+    system: "buyer",
+    promotion: "buyer",
+};