@mohasinac/appkit 4.63.5 → 4.64.0

package/dist/.build-stamp.json

@@ -1,8 +1,8 @@
 {
   "stampVersion": 1,
-  "version": "4.63.5",
-  "head": "6eff0d768f87f31fafd2ca5a5af8868622f94228",
+  "version": "4.64.0",
+  "head": "51ae7f86674aba82540dc018d8baa92064719f20",
   "branch": "main",
   "dirty": false,
-  "builtAt": "2026-10-23T20:06:38.671Z"
+  "builtAt": "2026-10-24T02:32:37.960Z"
 }

package/dist/_internal/server/features/categories/adapters.d.ts

@@ -36,7 +36,7 @@ export declare const PUBLIC_CATEGORY_FIELDS: readonly ["id", "name", "slug", "de
  * Fields withheld, each with the reason. Never remove one without replacing
  * the reason — "it seemed unused" is how a field ends up public by accident.
  */
-export declare const PRIVATE_CATEGORY_FIELDS: readonly ["position", "subtreeSize", "createdBy", "createdByType", "createdByStoreId", "createdByStoreName", "viewCount", "isBrand", "showOnHomepage", "isSearchable", "searchTxt", "aliases", "brandSlug", "bundleKind", "bundlePrice", "bundleStockStatus", "bundleProductIds", "bundleCategorySlugs", "bundleOriginalTotal", "bundleItemDetails", "contentBody", "descriptionTemplates", "productDefaults", "isTestData", "testDataExpiresAt", "bundleQueryRule", "bundleQueryResolvedAt"];
+export declare const PRIVATE_CATEGORY_FIELDS: readonly ["seoCanonicalPath", "position", "subtreeSize", "createdBy", "createdByType", "createdByStoreId", "createdByStoreName", "viewCount", "isBrand", "showOnHomepage", "isSearchable", "searchTxt", "aliases", "brandSlug", "bundleKind", "bundlePrice", "bundleStockStatus", "bundleProductIds", "bundleCategorySlugs", "bundleOriginalTotal", "bundleItemDetails", "contentBody", "descriptionTemplates", "productDefaults", "isTestData", "testDataExpiresAt", "bundleQueryRule", "bundleQueryResolvedAt"];
 /**
  * Project a stored category into the public shape.
  *

package/dist/_internal/server/features/categories/adapters.js

@@ -55,6 +55,19 @@ export const PUBLIC_CATEGORY_FIELDS = [
  * the reason — "it seemed unused" is how a field ends up public by accident.
  */
 export const PRIVATE_CATEGORY_FIELDS = [
+    /*
+     * The canonical path this category's page declares to crawlers.
+     *
+     * 🛑 Triaged PRIVATE as the default, because nothing emits it: it is
+     * consumed SERVER-side by the metadata builder, which reads the document
+     * rather than this projection, and `toCategoryListItem` does not carry it.
+     * A client reader would be a second place the canonical is decided, which
+     * is the drift `audit-seo-canonical-host` exists to prevent (Root Cause
+     * #81 — two owners of the canonical host cost the site its indexing).
+     *
+     * Move it to PUBLIC only alongside a named client reader.
+     */
+    "seoCanonicalPath",
     // Internal DFS coordinates. Useful only to `onCategoryWrite` and
     // `positionsReconcile`; publishing them invites a client to depend on an
     // ordering we renumber on every reseed.

package/dist/_internal/server/features/events/like-actions.d.ts

@@ -0,0 +1,25 @@
+/**
+ * Event like actions — the write path, and the paged read for the modal.
+ *
+ * @tag domain:events
+ * @tag layer:server
+ * @tag access:server-only
+ */
+import { type ActionResult } from "../../../shared/types/action-result";
+import { type EventLikersPage } from "./likes";
+export declare function toggleEventLikeAction(idOrSlug: string, userId: string): Promise<ActionResult<{
+    liked: boolean;
+    likeCount: number;
+}>>;
+/**
+ * One page of likers, plus whether THIS viewer has liked it.
+ *
+ * 🛑 `viewerLiked` rides along here rather than having its own endpoint
+ * because the event page cannot resolve it server-side: that page is
+ * publicly CDN-cached, so a session read there would let one visitor's
+ * state be served to the next (audit-cdn-cache-headers R3). The client
+ * asks once after hydration, and this saves it a second round trip.
+ */
+export declare function getEventLikersAction(idOrSlug: string, offset?: number, limit?: number, viewerId?: string): Promise<ActionResult<EventLikersPage & {
+    viewerLiked: boolean;
+}>>;

package/dist/_internal/server/features/events/like-actions.js

@@ -0,0 +1,67 @@
+/**
+ * Event like actions — the write path, and the paged read for the modal.
+ *
+ * @tag domain:events
+ * @tag layer:server
+ * @tag access:server-only
+ */
+import { wrapAction } from "../../../shared/types/action-result.js";
+import { eventLikesRepository } from "../../../../features/events/repository/event-likes.repository.js";
+import { resolveEventIdAction } from "../raffle/actions.js";
+import { getEventLikers, viewerHasLiked } from "./likes.js";
+import { NotFoundError } from "../../../../errors/index.js";
+import { LIKERS_PAGE_SIZE } from "../../../../features/events/schemas/likes.js";
+/**
+ * Resolve whatever the URL carried into the canonical document id.
+ *
+ * 🛑 THIS IS LOAD-BEARING, NOT DEFENSIVE. Public event URLs link by SLUG
+ * (`/events/festive-cashback-10`), so the route param is usually a slug while
+ * the like row's id is `{eventId}__{userId}` and the counter lives at
+ * `events/{docId}.stats.likeCount`.
+ *
+ * Without this, the same person liking from the slug URL and from an id URL
+ * would write TWO like rows and increment a counter on a document that may
+ * not exist — the same two-identities-for-one-event defect the spin route
+ * records as a silent `spinMaxPerUser` bypass. There it was a free reset;
+ * here it would be a double-counted like and an orphaned row the tester
+ * cascade cannot match.
+ */
+async function canonicalEventId(idOrSlug) {
+    const resolved = await resolveEventIdAction(idOrSlug);
+    const id = resolved.ok ? resolved.data : null;
+    if (!id)
+        throw new NotFoundError(`Event not found: ${idOrSlug}`);
+    return id;
+}
+export async function toggleEventLikeAction(idOrSlug, userId) {
+    return wrapAction(async () => {
+        const eventId = await canonicalEventId(idOrSlug);
+        return eventLikesRepository.toggle(eventId, userId);
+    });
+}
+/**
+ * One page of likers, plus whether THIS viewer has liked it.
+ *
+ * 🛑 `viewerLiked` rides along here rather than having its own endpoint
+ * because the event page cannot resolve it server-side: that page is
+ * publicly CDN-cached, so a session read there would let one visitor's
+ * state be served to the next (audit-cdn-cache-headers R3). The client
+ * asks once after hydration, and this saves it a second round trip.
+ */
+export async function getEventLikersAction(idOrSlug, offset = 0, limit = LIKERS_PAGE_SIZE, viewerId) {
+    return wrapAction(async () => {
+        const eventId = await canonicalEventId(idOrSlug);
+        /*
+         * Clamped, because `limit` arrives from a query string. An unclamped
+         * caller-supplied page size is an unbounded read against Rule #6's
+         * budget — `?limit=100000` would be a full-collection scan plus one user
+         * lookup per row.
+         */
+        const safeLimit = Math.min(Math.max(1, limit), LIKERS_PAGE_SIZE);
+        const [page, viewerLiked] = await Promise.all([
+            getEventLikers(eventId, safeLimit, Math.max(0, offset)),
+            viewerHasLiked(eventId, viewerId),
+        ]);
+        return { ...page, viewerLiked };
+    });
+}

package/dist/_internal/server/features/events/likes.d.ts

@@ -0,0 +1,65 @@
+/**
+ * Event likes — the server read path, and the only place a liker's identity
+ * is assembled.
+ *
+ * @tag domain:events
+ * @tag layer:server
+ * @tag access:server-only
+ */
+import { type PublicLiker } from "../../../../features/events/schemas/likes";
+export interface EventLikersPage {
+    likers: PublicLiker[];
+    /** True when more rows exist past this page. */
+    hasMore: boolean;
+}
+/**
+ * The most recent likers, resolved to names and faces.
+ *
+ * Two hops, both bounded: one indexed query for the ids, then one batched
+ * lookup for the profiles. The join is why the like row stores no name — see
+ * `schemas/likes.ts`.
+ *
+ * A user that cannot be resolved (deleted account, say) is DROPPED rather
+ * than rendered as a placeholder: a face with no person behind it is worse
+ * than a shorter rail.
+ */
+export declare function getEventLikers(eventId: string, limit?: number, offset?: number): Promise<EventLikersPage>;
+/**
+ * Cached for the page+metadata pair. `React.cache` memoises per argument
+ * list, so the default-arguments call site here and any explicit-limit call
+ * site would be two entries — which is why every caller on a page should use
+ * the same shape.
+ */
+export declare const getEventLikersCached: typeof getEventLikers;
+/** Has the viewer liked it? `false` for a signed-out visitor, with no read. */
+export declare function viewerHasLiked(eventId: string, userId?: string): Promise<boolean>;
+export declare const viewerHasLikedCached: typeof viewerHasLiked;
+/** Days plotted by the engagement chart. */
+export declare const LIKE_TREND_DAYS = 14;
+/**
+ * Below this many likes the chart renders NOTHING.
+ *
+ * 🛑 This threshold is the honest half of the feature. A brand-new event has
+ * two likes, and plotting them produces a flat line with a y-axis and a date
+ * range — which looks like a measurement and carries no information. An
+ * absent chart says "not enough data yet"; a flat one says "we measured, and
+ * this is the result", which is a different and false claim.
+ */
+export declare const LIKE_TREND_MIN_POINTS = 5;
+export interface LikeTrend {
+    /** Day labels, oldest first, e.g. "6 Nov". */
+    categories: string[];
+    /** Likes received on each of those days. Same length as `categories`. */
+    values: number[];
+}
+/**
+ * Likes per day over the last `LIKE_TREND_DAYS`, oldest first.
+ *
+ * Returns `null` — not an empty chart — when there is too little to plot.
+ *
+ * Bounded by `recentLikeTimes`' own 200-row cap: that is far more than 14
+ * days of a realistic event, and it means this cannot become an unbounded
+ * collection scan on a popular one (Rule #6).
+ */
+export declare function getLikeTrend(eventId: string): Promise<LikeTrend | null>;
+export declare const getLikeTrendCached: typeof getLikeTrend;

package/dist/_internal/server/features/events/likes.js

@@ -0,0 +1,146 @@
+/**
+ * Event likes — the server read path, and the only place a liker's identity
+ * is assembled.
+ *
+ * @tag domain:events
+ * @tag layer:server
+ * @tag access:server-only
+ */
+import { cache } from "react";
+import { eventLikesRepository } from "../../../../features/events/repository/event-likes.repository.js";
+import { userRepository } from "../../../../features/auth/repository/user.repository.js";
+import { LIKERS_PREVIEW_LIMIT, } from "../../../../features/events/schemas/likes.js";
+import { normalizeError } from "../../../../errors/normalize.js";
+import { serverLogger } from "../../../../monitoring/index.js";
+/**
+ * Project a user document down to the three fields a face needs.
+ *
+ * 🛑 AN ALLOW-LIST, NEVER A SPREAD. The user document carries email, phone,
+ * role, store ownership and encrypted PII; a spread-and-delete publishes
+ * every field nobody thought to remove, including fields the interface does
+ * not declare — which is precisely how `adSettings.providerCredentials` ended
+ * up on a public endpoint (Root Cause #70).
+ *
+ * 🛑 AND NOT `maskPii`. The obvious-looking alternative is to read the name
+ * off the event ENTRY and mask it, which is what the leaderboard and the spin
+ * results do. That renders "A*** K***" — correct for a leaderboard, useless
+ * as a face. `displayName` and `photoURL` are in `USER_PUBLIC_FIELDS`, are
+ * absent from `USER_PII_FIELDS`, and already render on public profile pages,
+ * so taking them from the user document publishes nothing new.
+ */
+function toPublicLiker(doc) {
+    const uid = doc?.uid ?? doc?.id;
+    if (!uid)
+        return null;
+    return {
+        uid: String(uid),
+        // A real account with no display name renders as a person, not a blank.
+        displayName: doc?.displayName?.trim() || "A collector",
+        photoURL: doc?.photoURL || undefined,
+    };
+}
+/**
+ * The most recent likers, resolved to names and faces.
+ *
+ * Two hops, both bounded: one indexed query for the ids, then one batched
+ * lookup for the profiles. The join is why the like row stores no name — see
+ * `schemas/likes.ts`.
+ *
+ * A user that cannot be resolved (deleted account, say) is DROPPED rather
+ * than rendered as a placeholder: a face with no person behind it is worse
+ * than a shorter rail.
+ */
+export async function getEventLikers(eventId, limit = LIKERS_PREVIEW_LIMIT, offset = 0) {
+    try {
+        // One extra row is the cheapest possible "is there a next page" — it
+        // avoids a count query, which Firestore bills per matched document.
+        const ids = await eventLikesRepository.recentLikerIds(eventId, limit + 1, offset);
+        const hasMore = ids.length > limit;
+        const pageIds = hasMore ? ids.slice(0, limit) : ids;
+        const docs = await Promise.all(pageIds.map((uid) => userRepository
+            .findByUid(uid)
+            .catch(() => null)));
+        return {
+            likers: docs
+                .map((d) => toPublicLiker(d))
+                .filter((l) => l !== null),
+            hasMore,
+        };
+    }
+    catch (err) {
+        const e = normalizeError(err);
+        serverLogger.warn("getEventLikers failed", { eventId, message: e.message });
+        // An empty rail is a degraded page; a thrown error is a dead one. The
+        // count beside it comes from the event document and still renders.
+        return { likers: [], hasMore: false };
+    }
+}
+/**
+ * Cached for the page+metadata pair. `React.cache` memoises per argument
+ * list, so the default-arguments call site here and any explicit-limit call
+ * site would be two entries — which is why every caller on a page should use
+ * the same shape.
+ */
+export const getEventLikersCached = cache(getEventLikers);
+/** Has the viewer liked it? `false` for a signed-out visitor, with no read. */
+export async function viewerHasLiked(eventId, userId) {
+    if (!userId)
+        return false;
+    return eventLikesRepository.hasLiked(eventId, userId);
+}
+export const viewerHasLikedCached = cache(viewerHasLiked);
+/** Days plotted by the engagement chart. */
+export const LIKE_TREND_DAYS = 14;
+/**
+ * Below this many likes the chart renders NOTHING.
+ *
+ * 🛑 This threshold is the honest half of the feature. A brand-new event has
+ * two likes, and plotting them produces a flat line with a y-axis and a date
+ * range — which looks like a measurement and carries no information. An
+ * absent chart says "not enough data yet"; a flat one says "we measured, and
+ * this is the result", which is a different and false claim.
+ */
+export const LIKE_TREND_MIN_POINTS = 5;
+/**
+ * Likes per day over the last `LIKE_TREND_DAYS`, oldest first.
+ *
+ * Returns `null` — not an empty chart — when there is too little to plot.
+ *
+ * Bounded by `recentLikeTimes`' own 200-row cap: that is far more than 14
+ * days of a realistic event, and it means this cannot become an unbounded
+ * collection scan on a popular one (Rule #6).
+ */
+export async function getLikeTrend(eventId) {
+    const times = await eventLikesRepository.recentLikeTimes(eventId);
+    if (times.length < LIKE_TREND_MIN_POINTS)
+        return null;
+    const now = new Date();
+    const buckets = [];
+    const index = new Map();
+    for (let i = LIKE_TREND_DAYS - 1; i >= 0; i -= 1) {
+        const d = new Date(now);
+        d.setDate(d.getDate() - i);
+        const key = d.toISOString().slice(0, 10);
+        index.set(key, buckets.length);
+        buckets.push({
+            label: d.toLocaleDateString("en-IN", { day: "numeric", month: "short" }),
+            count: 0,
+        });
+    }
+    for (const t of times) {
+        const slot = index.get(t.toISOString().slice(0, 10));
+        // Older than the window — `recentLikeTimes` returns newest-first over a
+        // 200-row cap, so this is the normal case for a long-running event.
+        if (slot !== undefined)
+            buckets[slot].count += 1;
+    }
+    // Every like could be older than the window even though the count cleared
+    // the threshold, which would plot fourteen zeroes.
+    if (buckets.every((b) => b.count === 0))
+        return null;
+    return {
+        categories: buckets.map((b) => b.label),
+        values: buckets.map((b) => b.count),
+    };
+}
+export const getLikeTrendCached = cache(getLikeTrend);

package/dist/_internal/server/features/seo/index.d.ts

@@ -6,3 +6,6 @@ export { buildSitemap } from "./sitemap";
 export type { SitemapOptions } from "./sitemap";
 export { buildDefaultOgImage, DEFAULT_OG_SIZE, resolveOgImageUrl } from "./og";
 export type { DefaultOgOptions } from "./og";
+export { productDetailSlugs, brandDetailSlugs, franchiseDetailSlugs, blogPostSlugs, beyDetailSlugs, partDetailParams, } from "./static-params";
+export { brandLinks, franchiseLinks, categoryRootLinks } from "./taxonomy-links";
+export type { TaxonomyLink } from "./taxonomy-links";

package/dist/_internal/server/features/seo/index.js

@@ -2,3 +2,5 @@ export { buildRobots } from "./robots.js";
 export { buildManifest } from "./manifest.js";
 export { buildSitemap } from "./sitemap.js";
 export { buildDefaultOgImage, DEFAULT_OG_SIZE, resolveOgImageUrl } from "./og.js";
+export { productDetailSlugs, brandDetailSlugs, franchiseDetailSlugs, blogPostSlugs, beyDetailSlugs, partDetailParams, } from "./static-params.js";
+export { brandLinks, franchiseLinks, categoryRootLinks } from "./taxonomy-links.js";

package/dist/_internal/server/features/seo/product-detail-types.d.ts

@@ -0,0 +1 @@
+export declare const PRODUCT_DETAIL_LISTING_TYPES: readonly string[];

package/dist/_internal/server/features/seo/product-detail-types.js

@@ -0,0 +1,26 @@
+/**
+ * Which listing types actually RENDER at `/products/{slug}`.
+ *
+ * DERIVED from each plugin's own `detailRoute`, never hand-written. Two SEO
+ * surfaces need this set — the sitemap (what to submit) and
+ * `generateStaticParams` (what to prerender) — and a third, the page itself,
+ * enforces it by `permanentRedirect`ing a non-standard type away.
+ *
+ * 🛑 It used to be a literal `["standard", "art", "stickers"]` in `sitemap.ts`.
+ * When `spares` was added as a tenth listing type pointing at the same route,
+ * that literal was not updated, so the product became renderable at
+ * `/products/{slug}` and was never submitted — measured 2026-10-24, 14 product
+ * URLs in the sitemap against 15 that resolve. That is Root Cause #61's shape
+ * (N hand-written enumerations of one union, only the compile-checked ones
+ * staying correct), and deriving is the documented fix.
+ *
+ * Comparing rendered routes rather than naming types keeps it honest: a
+ * plugin that is repointed at its own page leaves this set automatically.
+ */
+import { ALL_LISTING_TYPES } from "../../../shared/listing-types/feature-flags.js";
+import { pluginFor } from "../../../shared/listing-types/_registry.js";
+import { ROUTES } from "../../../../next/routing/route-map.js";
+/** An arbitrary probe slug — only the SHAPE of the resolved route matters. */
+const PROBE = "__route_probe__";
+const PRODUCT_DETAIL_ROUTE = String(ROUTES.PUBLIC.PRODUCT_DETAIL(PROBE));
+export const PRODUCT_DETAIL_LISTING_TYPES = ALL_LISTING_TYPES.filter((type) => pluginFor(type).detailRoute(PROBE) === PRODUCT_DETAIL_ROUTE);

package/dist/_internal/server/features/seo/robots.js

@@ -36,7 +36,26 @@ export function buildRobots({ siteUrl }) {
                     "/preview/",
                     "/track/",
                     "/unauthorized/",
-                    "/_next/",
+                    /*
+                     * 🛑 `/_next/` IS DELIBERATELY NOT DISALLOWED — do not re-add it.
+                     *
+                     * It was here until 2026-10-24 and it was blocking Googlebot from
+                     * fetching the app's own JS and CSS chunks, i.e. from RENDERING the
+                     * page at all. Google's guidance is explicit that blocking resources
+                     * needed for rendering harms how a page is understood.
+                     *
+                     * It was actively load-bearing here rather than merely untidy: every
+                     * dynamic route streams its metadata late, so the `<title>` lands
+                     * inside `<body>` (measured at byte 563,190 of a 747 KB document,
+                     * with the `<head>` ending at 8,180 carrying no title at all). The
+                     * one mechanism that recovers it is React hoisting those tags into
+                     * `<head>` during hydration — which cannot happen if the crawler is
+                     * forbidden from downloading the script that performs the hoist.
+                     *
+                     * Blocking it buys nothing: these are immutable, content-hashed
+                     * static assets that are not indexable documents, and Google does not
+                     * list them as search results.
+                     */
                     "/profile/*/edit",
                 ],
             },