@mohasinac/appkit 4.63.4 → 4.64.0

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

@@ -0,0 +1,12 @@
+import type { ScheduleHandler } from "../runtime/types";
+/**
+ * 🛑 No `force`. The schedule fires on days 28–31 and the core's month-end
+ * guard keeps exactly the real last day — see `isLastDayOfMonth` for why the
+ * cron cannot simply say "31".
+ *
+ * `ScheduleHandler` returns `void`, so the result object is dropped here. It
+ * is not lost: the core logs `granted`/`revoked`/`locked` counts, and it is
+ * returned for the admin recompute path and for verification, which call the
+ * core directly with `{ force: true }`.
+ */
+export declare const sellerStandingRollupHandler: ScheduleHandler;

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

@@ -0,0 +1,14 @@
+import { runSellerStandingRollup } from "../core/sellerStandingRollup.js";
+/**
+ * 🛑 No `force`. The schedule fires on days 28–31 and the core's month-end
+ * guard keeps exactly the real last day — see `isLastDayOfMonth` for why the
+ * cron cannot simply say "31".
+ *
+ * `ScheduleHandler` returns `void`, so the result object is dropped here. It
+ * is not lost: the core logs `granted`/`revoked`/`locked` counts, and it is
+ * returned for the admin recompute path and for verification, which call the
+ * core directly with `{ force: true }`.
+ */
+export const sellerStandingRollupHandler = async (ctx) => {
+    await runSellerStandingRollup(ctx);
+};

package/dist/_internal/server/notifications/channel-health.d.ts

@@ -1,5 +1,5 @@
 /**
- * Circuit breaker for outbound notification channels.
+ * Circuit breaker for outbound notification channels (email, WhatsApp).
  *
  * Persisted as a singleton Firestore doc `system/channelHealth` so the
  * "is this channel currently known-bad" state survives across requests and
@@ -10,9 +10,11 @@
  * its own outcome decides whether the circuit re-closes or re-opens.
  */
 /**
- * Email is the only outbound *notification* channel with a transport.
- * "whatsapp" was the other arm until 2026-10-20, when the Cloud API
- * integration was removed.
+ * Email and WhatsApp are the outbound *notification* channels with a
+ * transport. The WhatsApp arm was removed 2026-10-20 with the Cloud API
+ * integration and restored 2026-10-23; it stays inert until
+ * `siteSettings.whatsapp.enabled` is on AND a number is registered on the
+ * Cloud API, so a breaker on it reports a channel nobody is using until then.
  *
  * ## 🛑 Phase 8 widened this to the RECONCILERS' reads — and only those
  *
@@ -36,7 +38,7 @@
  * backing off costs only freshness. Anything that moves money is not a reader
  * and does not belong in this union.
  */
-export type NotificationChannel = "email" | "razorpay_read" | "shiprocket_read";
+export type NotificationChannel = "email" | "whatsapp" | "razorpay_read" | "shiprocket_read";
 /**
  * Returns false only when the circuit is open and still within its cooldown
  * window. Any other state (closed, or open-but-cooldown-elapsed) is treated
@@ -47,7 +49,7 @@ export declare function recordChannelOutcome(channel: NotificationChannel, succe
 /**
  * Runs `fn` up to 3 times (500ms then 1.5s between attempts) and records the
  * final outcome against the channel's health state. `fn` must throw on
- * failure — for a helper that returns a boolean instead (e.g. a sender
+ * failure — for a helper that returns a boolean instead (e.g. the WhatsApp
  * Cloud API helpers), convert `false` into a thrown error at the call site
  * before passing it in.
  */

package/dist/_internal/server/notifications/channel-health.js

@@ -1,5 +1,5 @@
 /**
- * Circuit breaker for outbound notification channels.
+ * Circuit breaker for outbound notification channels (email, WhatsApp).
  *
  * Persisted as a singleton Firestore doc `system/channelHealth` so the
  * "is this channel currently known-bad" state survives across requests and
@@ -72,7 +72,7 @@ function delay(ms) {
 /**
  * Runs `fn` up to 3 times (500ms then 1.5s between attempts) and records the
  * final outcome against the channel's health state. `fn` must throw on
- * failure — for a helper that returns a boolean instead (e.g. a sender
+ * failure — for a helper that returns a boolean instead (e.g. the WhatsApp
  * Cloud API helpers), convert `false` into a thrown error at the call site
  * before passing it in.
  */

package/dist/_internal/server/notifications/send-guard.d.ts

@@ -15,7 +15,7 @@
  * message.
  *
  * The guarantee that nothing bypasses this is STRUCTURAL instead: the guard
- * argument is REQUIRED on `sendEmail`, so an
+ * argument is REQUIRED on `sendEmail` and on both WhatsApp senders, so an
  * unguarded send does not typecheck, and `scripts/audit-unguarded-send.mjs`
  * fails the build on a raw `createResendProvider().send()`. Make the wrong
  * thing unrepresentable rather than adding a second layer of defence that has

package/dist/_internal/server/notifications/send-guard.js

@@ -15,7 +15,7 @@
  * message.
  *
  * The guarantee that nothing bypasses this is STRUCTURAL instead: the guard
- * argument is REQUIRED on `sendEmail`, so an
+ * argument is REQUIRED on `sendEmail` and on both WhatsApp senders, so an
  * unguarded send does not typecheck, and `scripts/audit-unguarded-send.mjs`
  * fails the build on a raw `createResendProvider().send()`. Make the wrong
  * thing unrepresentable rather than adding a second layer of defence that has
@@ -69,7 +69,9 @@ export async function guardSend(ctx) {
     if (ctx.audience === "user" && !ctx.transactional) {
         const channelEnabled = ctx.channel === "email"
             ? (messaging?.emailEnabled ?? MESSAGE_BUDGET_DEFAULTS.emailEnabled)
-            : false; // sms has no sender; if one appears it starts disabled.
+            : ctx.channel === "whatsapp"
+                ? (messaging?.whatsappEnabled ?? MESSAGE_BUDGET_DEFAULTS.whatsappEnabled)
+                : false; // sms has no sender; if one appears it starts disabled.
         if (!channelEnabled) {
             return {
                 allow: false,

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

@@ -771,6 +771,22 @@ export const ACTIONS = {
         },
     },
     STORE: {
+        /*
+         * Open a storefront — the submit button for the store-creation form.
+         *
+         * No `confirmation`: creating a store is additive, reversible by the
+         * seller, and produces a `pending` / non-public document that no buyer can
+         * see until an admin approves it. A dialog here would be friction on the
+         * one step the seller came to perform.
+         */
+        "create-store": {
+            iconKey: "create",
+            id: "store.create-store",
+            label: "Create my store",
+            ariaLabel: "Create your store",
+            description: "Create the seller's storefront. The store starts pending and private until an admin approves it.",
+            kind: "primary",
+        },
         "follow": {
             iconKey: "wishlist",
             id: "store.follow",
@@ -919,6 +935,34 @@ export const ACTIONS = {
             kind: "ghost",
             permissions: ["seller", "admin"],
         },
+        // ── WhatsApp integration ────────────────────────────────────────────
+        "whatsapp-connect": {
+            iconKey: "link",
+            id: "store.whatsapp-connect",
+            label: "Save & Connect",
+            ariaLabel: "Save WhatsApp credentials and connect",
+            description: "Save WhatsApp Business credentials and establish connection.",
+            kind: "primary",
+            permissions: ["seller", "admin"],
+        },
+        "whatsapp-catalog-sync": {
+            iconKey: "retry",
+            id: "store.whatsapp-catalog-sync",
+            label: "Push to WhatsApp",
+            ariaLabel: "Sync products to WhatsApp catalog",
+            description: "Push published standard products to WhatsApp Business Catalog.",
+            kind: "secondary",
+            permissions: ["seller", "admin"],
+        },
+        "whatsapp-catalog-import": {
+            iconKey: "upload",
+            id: "store.whatsapp-catalog-import",
+            label: "Import from WhatsApp",
+            ariaLabel: "Import products from WhatsApp catalog",
+            description: "Import products from WhatsApp Catalog as drafts.",
+            kind: "secondary",
+            permissions: ["seller", "admin"],
+        },
         // ── Google Reviews integration ──────────────────────────────────────
         "google-reviews-sync": {
             iconKey: "retry",
@@ -2200,6 +2244,51 @@ export const ACTIONS = {
                 confirmKind: "danger",
             },
         },
+        /*
+         * 🛑 Approve/reject a seller's PENDING store — the step that was missing.
+         *
+         * A store is created `status: "pending"`, `isPublic: false`, and until
+         * 2026-10-24 nothing in any admin UI could move it: `AdminStoresView` had
+         * verify and suspend row actions only, and the one action named for this
+         * job (`adminUpdateStoreStatus`) writes the USER-level `storeStatus`
+         * mirror and never touches the store document — so wiring that would have
+         * marked the applicant approved while leaving their store invisible, with
+         * no error. Both of these go through the store PATCH route, i.e. through
+         * `storeRepository.setStatus`, which is the only writer that keeps
+         * `status` and `isPublic` in step (Root Cause #42).
+         *
+         * Approve carries a confirmation despite being `primary`: it is what makes
+         * a storefront publicly visible, and that is outward-facing.
+         */
+        "approve-store": {
+            iconKey: "approve",
+            id: "admin.approve-store",
+            label: "Approve store",
+            ariaLabel: "Approve this store and make it public",
+            description: "Approve a pending store — sets it active and makes its listings visible to buyers.",
+            kind: "primary",
+            permissions: ["admin"],
+            confirmation: {
+                title: "Approve this store?",
+                body: "The store becomes active and its listings become visible to buyers. The seller will be notified.",
+                confirmLabel: "Approve store",
+            },
+        },
+        "reject-store": {
+            iconKey: "reject",
+            id: "admin.reject-store",
+            label: "Reject store",
+            ariaLabel: "Reject this store application",
+            description: "Reject a pending store application — the store stays hidden from buyers.",
+            kind: "danger",
+            permissions: ["admin"],
+            confirmation: {
+                title: "Reject this store application?",
+                body: "The store will not be published and the seller will be notified. You can approve it later if they resolve the issue.",
+                confirmLabel: "Reject store",
+                confirmKind: "danger",
+            },
+        },
         // ── Review moderation ──────────────────────────────────────────────────
         "approve-review": {
             iconKey: "approve",

package/dist/_internal/shared/checkout/order-math.d.ts

@@ -227,7 +227,7 @@ export interface PayableOrderLike {
  * money bug in all four payout paths (`autoPayoutEligibility`,
  * `weeklyPayoutEligibility`, and both `seller-actions` entry points). That
  * field is the GRAND TOTAL — `checkout/actions.ts` builds it as
- * `goods − coupon + shipping + codHandling + giftWrap +
+ * `goods − coupon + shipping + codHandling + whatsappNotify + giftWrap +
  * shipmentProtection + platformFee + platformFeeGst + emiSurcharge + gstAmount`
  * — so using it as the payout base did three wrong things at once:
  *

package/dist/_internal/shared/checkout/order-math.js

@@ -412,7 +412,7 @@ export function allocateAcrossMembers(total, weights) {
  * money bug in all four payout paths (`autoPayoutEligibility`,
  * `weeklyPayoutEligibility`, and both `seller-actions` entry points). That
  * field is the GRAND TOTAL — `checkout/actions.ts` builds it as
- * `goods − coupon + shipping + codHandling + giftWrap +
+ * `goods − coupon + shipping + codHandling + whatsappNotify + giftWrap +
  * shipmentProtection + platformFee + platformFeeGst + emiSurcharge + gstAmount`
  * — so using it as the payout base did three wrong things at once:
  *

package/dist/_internal/shared/features/checkout/config.d.ts

@@ -6,6 +6,8 @@ export declare const CHECKOUT_DEFAULT_COMMISSIONS: {
     readonly codDepositPercent: 10;
     readonly codHandlingFeeCap: 200;
     readonly codHandlingFeePercent: 10;
+    readonly whatsappNotifyFeeEnabled: true;
+    readonly whatsappNotifyFee: 10;
     readonly giftWrapFeeEnabled: true;
     readonly giftWrapFee: 49;
     readonly shipmentProtectionFeeEnabled: true;

package/dist/_internal/shared/features/checkout/config.js

@@ -13,6 +13,8 @@ export const CHECKOUT_DEFAULT_COMMISSIONS = {
     // Mirrors the SiteSettingsDocument defaults, which enable every add-on.
     // Consequence of the mirror: if the settings read fails, an add-on already
     // ticked on the cart document is still billed rather than silently dropped.
+    whatsappNotifyFeeEnabled: true,
+    whatsappNotifyFee: 10,
     giftWrapFeeEnabled: true,
     giftWrapFee: 49,
     shipmentProtectionFeeEnabled: true,

package/dist/_internal/shared/features/messaging/config.d.ts

@@ -16,12 +16,7 @@
  * and find the budget already covers them. A channel that is born capped
  * cannot repeat what email did.
  */
-/**
- * `whatsapp` was removed 2026-10-20 with the Cloud API integration. `sms`
- * stays declared with no sender — the ceiling exists so one cannot ship
- * uncapped — and `email` is the only channel with a live transport.
- */
-export type MessageChannel = "email" | "sms";
+export type MessageChannel = "email" | "whatsapp" | "sms";
 /**
  * Who the message is FOR — which is what the kill switch keys on.
  *
@@ -81,12 +76,13 @@ export type SendDecision = {
 /**
  * Defaults, mirrored into `DEFAULT_SITE_SETTINGS_DATA.messaging`.
  *
- * 🛑 `emailEnabled` defaults to FALSE. An install that
+ * 🛑 `emailEnabled` and `whatsappEnabled` default to FALSE. An install that
  * has not made a decision should be quiet, not loud — the opposite default is
  * how a fresh deploy mails real people from a half-configured site.
  */
 export declare const MESSAGE_BUDGET_DEFAULTS: {
     readonly emailEnabled: false;
+    readonly whatsappEnabled: false;
     readonly dailyCeiling: {
         /**
          * Resend's free tier is 100/day. 80 is not timidity — the counter is
@@ -96,6 +92,8 @@ export declare const MESSAGE_BUDGET_DEFAULTS: {
          * headroom is what stops "at the limit" from becoming "over it".
          */
         readonly email: 80;
+        /** Meta's pricing is per-conversation, not per-message; this is a sanity bound, not a tier limit. */
+        readonly whatsapp: 200;
         /** No sender exists yet. Present so one cannot ship uncapped. */
         readonly sms: 50;
     };

package/dist/_internal/shared/features/messaging/config.js

@@ -9,12 +9,13 @@
 /**
  * Defaults, mirrored into `DEFAULT_SITE_SETTINGS_DATA.messaging`.
  *
- * 🛑 `emailEnabled` defaults to FALSE. An install that
+ * 🛑 `emailEnabled` and `whatsappEnabled` default to FALSE. An install that
  * has not made a decision should be quiet, not loud — the opposite default is
  * how a fresh deploy mails real people from a half-configured site.
  */
 export const MESSAGE_BUDGET_DEFAULTS = {
     emailEnabled: false,
+    whatsappEnabled: false,
     dailyCeiling: {
         /**
          * Resend's free tier is 100/day. 80 is not timidity — the counter is
@@ -24,6 +25,8 @@ export const MESSAGE_BUDGET_DEFAULTS = {
          * headroom is what stops "at the limit" from becoming "over it".
          */
         email: 80,
+        /** Meta's pricing is per-conversation, not per-message; this is a sanity bound, not a tier limit. */
+        whatsapp: 200,
         /** No sender exists yet. Present so one cannot ship uncapped. */
         sms: 50,
     },

package/dist/_internal/shared/features/seller-standing/config.d.ts

@@ -0,0 +1,130 @@
+/**
+ * Seller standing — the ONE definition of what earns the Trusted Seller tier.
+ *
+ * ## Why this is a single pure module
+ *
+ * Four surfaces must agree about the criteria: the monthly rollup job that
+ * grants and revokes, the seller's in-dashboard progress panel, the public
+ * `/seller-guide` criteria table, and the admin trust guide. Four hand-written
+ * copies of "25 delivered orders in 90 days" is Root Cause #73/#75's shape —
+ * the copy that gets fixed is never the copy the reader believes. So the
+ * thresholds, the predicate AND the display rows all come from here.
+ *
+ * 🛑 It had a fifth copy before this existed, and it was prose:
+ * `AdminStoresGuideView` told admins the verified badge was "awarded when the
+ * store has a consistent track record (>=20 delivered orders, >=4.0 rating, 3+
+ * months active)" — numbers no code has ever read, attached to a field nothing
+ * computes. That sentence is what the whole feature was remembered as being.
+ *
+ * ## Pure, and that is load-bearing
+ *
+ * No Firestore, no clock, no `Date.now()`. The job passes in metrics it has
+ * already measured and the UI passes in metrics it has already loaded, so the
+ * same input always produces the same verdict and the panel can never disagree
+ * with the grant.
+ */
+/**
+ * 🛑 A `Record<Criterion, true>`, not a string array.
+ *
+ * Adding a criterion then becomes a COMPILE error at every site that must
+ * display or evaluate it — the thresholds, the labels, the verdict's `met`
+ * map. An array lets a new criterion be evaluated while silently rendering
+ * nowhere, which is how ten hand-maintained enumerations of one union drifted
+ * in Root Cause #61.
+ */
+declare const SELLER_STANDING_CRITERION_MAP: {
+    readonly deliveredOrders: true;
+    readonly distinctBuyers: true;
+    readonly distinctAddresses: true;
+    readonly ratedOrders: true;
+    readonly averageRating: true;
+};
+export type SellerStandingCriterion = keyof typeof SELLER_STANDING_CRITERION_MAP;
+export declare const SELLER_STANDING_CRITERIA: SellerStandingCriterion[];
+/** The two tiers. Ordered: `trusted` is strictly above `seller`. */
+export type SellerTier = "seller" | "trusted";
+export declare const SELLER_TIER: {
+    readonly SELLER: "seller";
+    readonly TRUSTED: "trusted";
+};
+export interface SellerStandingThresholds {
+    /** The rolling window every metric is measured over. */
+    windowDays: number;
+    minDeliveredOrders: number;
+    minDistinctBuyers: number;
+    minDistinctAddresses: number;
+    minRatedOrders: number;
+    /** A mean, 1–5. Compared with `>=`. */
+    minAverageRating: number;
+}
+/**
+ * The shipped defaults.
+ *
+ * 🛑 Every count is measured INSIDE `windowDays`, not lifetime. That is the
+ * strict reading and it was chosen deliberately: the tier grants early payout,
+ * so it has to describe a seller who is shipping reliably *now*, not one who
+ * did two years ago. The consequence worth knowing up front is that on a
+ * freshly seeded catalogue **nobody qualifies**, and that is the correct
+ * result rather than a broken job.
+ *
+ * Admin-overridable via `siteSettings.sellerStanding` so the bar can be tuned
+ * once real volume exists, without a deploy.
+ */
+export declare const SELLER_STANDING_DEFAULTS: SellerStandingThresholds;
+export interface SellerStandingMetrics {
+    /** Delivered orders inside the window, excluding self-bought and test rows. */
+    deliveredOrders: number;
+    /** Distinct buyer uids across those orders. */
+    distinctBuyers: number;
+    /** Distinct shipping-address fingerprints across those orders. */
+    distinctAddresses: number;
+    /** Approved reviews inside the window. */
+    ratedOrders: number;
+    /** Mean of those reviews' ratings, 1–5. `0` when there are none. */
+    averageRating: number;
+}
+export interface SellerStandingVerdict {
+    tier: SellerTier;
+    met: Record<SellerStandingCriterion, boolean>;
+    /** How many criteria are still short — drives "1 criterion to go". */
+    unmetCount: number;
+}
+/**
+ * Does this seller currently meet the bar?
+ *
+ * 🛑 ALL criteria must hold. There is no scoring and no partial credit: the
+ * reward is being paid before delivery, so "mostly reliable" is not a state
+ * this can grant on.
+ */
+export declare function evaluateSellerStanding(metrics: SellerStandingMetrics, thresholds?: SellerStandingThresholds): SellerStandingVerdict;
+export declare const SELLER_STANDING_CRITERION_LABELS: Record<SellerStandingCriterion, string>;
+/**
+ * Why each criterion exists, in the seller's words. Rendered on the guide
+ * pages — a bar with no stated reason reads as arbitrary, and two of these
+ * exist specifically to make the tier hard to manufacture.
+ */
+export declare const SELLER_STANDING_CRITERION_WHY: Record<SellerStandingCriterion, string>;
+export type SellerStandingRowKind = "count" | "rating";
+export interface SellerStandingRow {
+    criterion: SellerStandingCriterion;
+    label: string;
+    why: string;
+    kind: SellerStandingRowKind;
+    /** The seller's current figure. `null` when standing has never been computed. */
+    actual: number | null;
+    target: number;
+    met: boolean;
+}
+/**
+ * One row per criterion, for rendering.
+ *
+ * `metrics` may be null — a store whose standing has never been computed shows
+ * every target with no figure beside it, which is honest. 🛑 It must NOT show
+ * zeros: a confident "0 of 25" on a store that simply has not been measured
+ * yet is the same lie as a counter that has never been written reading as 0
+ * (Root Cause #72).
+ */
+export declare function sellerStandingRows(metrics: SellerStandingMetrics | null | undefined, thresholds?: SellerStandingThresholds): SellerStandingRow[];
+/** `4` → `"4.0"`, `25` → `"25"`. Keeps rating and count formatting in one place. */
+export declare function formatSellerStandingValue(value: number, kind: SellerStandingRowKind): string;
+export {};

package/dist/_internal/shared/features/seller-standing/config.js

@@ -0,0 +1,153 @@
+/**
+ * Seller standing — the ONE definition of what earns the Trusted Seller tier.
+ *
+ * ## Why this is a single pure module
+ *
+ * Four surfaces must agree about the criteria: the monthly rollup job that
+ * grants and revokes, the seller's in-dashboard progress panel, the public
+ * `/seller-guide` criteria table, and the admin trust guide. Four hand-written
+ * copies of "25 delivered orders in 90 days" is Root Cause #73/#75's shape —
+ * the copy that gets fixed is never the copy the reader believes. So the
+ * thresholds, the predicate AND the display rows all come from here.
+ *
+ * 🛑 It had a fifth copy before this existed, and it was prose:
+ * `AdminStoresGuideView` told admins the verified badge was "awarded when the
+ * store has a consistent track record (>=20 delivered orders, >=4.0 rating, 3+
+ * months active)" — numbers no code has ever read, attached to a field nothing
+ * computes. That sentence is what the whole feature was remembered as being.
+ *
+ * ## Pure, and that is load-bearing
+ *
+ * No Firestore, no clock, no `Date.now()`. The job passes in metrics it has
+ * already measured and the UI passes in metrics it has already loaded, so the
+ * same input always produces the same verdict and the panel can never disagree
+ * with the grant.
+ */
+// ---------------------------------------------------------------------------
+// Criteria
+// ---------------------------------------------------------------------------
+/**
+ * 🛑 A `Record<Criterion, true>`, not a string array.
+ *
+ * Adding a criterion then becomes a COMPILE error at every site that must
+ * display or evaluate it — the thresholds, the labels, the verdict's `met`
+ * map. An array lets a new criterion be evaluated while silently rendering
+ * nowhere, which is how ten hand-maintained enumerations of one union drifted
+ * in Root Cause #61.
+ */
+const SELLER_STANDING_CRITERION_MAP = {
+    deliveredOrders: true,
+    distinctBuyers: true,
+    distinctAddresses: true,
+    ratedOrders: true,
+    averageRating: true,
+};
+export const SELLER_STANDING_CRITERIA = Object.keys(SELLER_STANDING_CRITERION_MAP);
+export const SELLER_TIER = {
+    SELLER: "seller",
+    TRUSTED: "trusted",
+};
+/**
+ * The shipped defaults.
+ *
+ * 🛑 Every count is measured INSIDE `windowDays`, not lifetime. That is the
+ * strict reading and it was chosen deliberately: the tier grants early payout,
+ * so it has to describe a seller who is shipping reliably *now*, not one who
+ * did two years ago. The consequence worth knowing up front is that on a
+ * freshly seeded catalogue **nobody qualifies**, and that is the correct
+ * result rather than a broken job.
+ *
+ * Admin-overridable via `siteSettings.sellerStanding` so the bar can be tuned
+ * once real volume exists, without a deploy.
+ */
+export const SELLER_STANDING_DEFAULTS = {
+    windowDays: 90,
+    minDeliveredOrders: 25,
+    minDistinctBuyers: 25,
+    minDistinctAddresses: 25,
+    minRatedOrders: 25,
+    minAverageRating: 4,
+};
+/**
+ * Does this seller currently meet the bar?
+ *
+ * 🛑 ALL criteria must hold. There is no scoring and no partial credit: the
+ * reward is being paid before delivery, so "mostly reliable" is not a state
+ * this can grant on.
+ */
+export function evaluateSellerStanding(metrics, thresholds = SELLER_STANDING_DEFAULTS) {
+    const met = {
+        deliveredOrders: metrics.deliveredOrders >= thresholds.minDeliveredOrders,
+        distinctBuyers: metrics.distinctBuyers >= thresholds.minDistinctBuyers,
+        distinctAddresses: metrics.distinctAddresses >= thresholds.minDistinctAddresses,
+        ratedOrders: metrics.ratedOrders >= thresholds.minRatedOrders,
+        averageRating: metrics.averageRating >= thresholds.minAverageRating,
+    };
+    const unmetCount = SELLER_STANDING_CRITERIA.filter((c) => !met[c]).length;
+    return {
+        tier: unmetCount === 0 ? SELLER_TIER.TRUSTED : SELLER_TIER.SELLER,
+        met,
+        unmetCount,
+    };
+}
+// ---------------------------------------------------------------------------
+// Display — so the panel, the public guide and the admin guide agree
+// ---------------------------------------------------------------------------
+export const SELLER_STANDING_CRITERION_LABELS = {
+    deliveredOrders: "Delivered orders",
+    distinctBuyers: "Different buyers",
+    distinctAddresses: "Different delivery addresses",
+    ratedOrders: "Rated orders",
+    averageRating: "Average rating",
+};
+/**
+ * Why each criterion exists, in the seller's words. Rendered on the guide
+ * pages — a bar with no stated reason reads as arbitrary, and two of these
+ * exist specifically to make the tier hard to manufacture.
+ */
+export const SELLER_STANDING_CRITERION_WHY = {
+    deliveredOrders: "Enough completed sales to show a pattern, not a one-off.",
+    distinctBuyers: "Sales to real, different customers.",
+    distinctAddresses: "Orders going to different places, not the same one repeatedly.",
+    ratedOrders: "Enough ratings for the average below to mean something.",
+    averageRating: "Buyers are consistently happy with what arrives.",
+};
+function targetFor(criterion, t) {
+    switch (criterion) {
+        case "deliveredOrders":
+            return t.minDeliveredOrders;
+        case "distinctBuyers":
+            return t.minDistinctBuyers;
+        case "distinctAddresses":
+            return t.minDistinctAddresses;
+        case "ratedOrders":
+            return t.minRatedOrders;
+        case "averageRating":
+            return t.minAverageRating;
+    }
+}
+/**
+ * One row per criterion, for rendering.
+ *
+ * `metrics` may be null — a store whose standing has never been computed shows
+ * every target with no figure beside it, which is honest. 🛑 It must NOT show
+ * zeros: a confident "0 of 25" on a store that simply has not been measured
+ * yet is the same lie as a counter that has never been written reading as 0
+ * (Root Cause #72).
+ */
+export function sellerStandingRows(metrics, thresholds = SELLER_STANDING_DEFAULTS) {
+    const verdict = metrics ? evaluateSellerStanding(metrics, thresholds) : null;
+    return SELLER_STANDING_CRITERIA.map((criterion) => ({
+        criterion,
+        label: SELLER_STANDING_CRITERION_LABELS[criterion],
+        why: SELLER_STANDING_CRITERION_WHY[criterion],
+        kind: criterion === "averageRating" ? "rating" : "count",
+        actual: metrics ? metrics[criterion] : null,
+        target: targetFor(criterion, thresholds),
+        met: verdict ? verdict.met[criterion] : false,
+    }));
+}
+/** `4` → `"4.0"`, `25` → `"25"`. Keeps rating and count formatting in one place. */
+export function formatSellerStandingValue(value, kind) {
+    return kind === "rating" ? value.toFixed(1) : String(value);
+}

package/dist/_internal/shared/features/site-settings/fees.d.ts

@@ -27,6 +27,8 @@ import type { EmiSettings } from "../emi/schedule";
  * and each `compute*Fee` helper carries its own default.
  */
 export interface BuyerFacingFees {
+    whatsappNotifyFeeEnabled?: boolean;
+    whatsappNotifyFee?: number;
     giftWrapFeeEnabled?: boolean;
     giftWrapFee?: number;
     shipmentProtectionFeeEnabled?: boolean;

package/dist/_internal/shared/features/site-settings/fees.js

@@ -13,6 +13,8 @@ export function toBuyerFacingFees(commissions) {
     if (!commissions)
         return null;
     return {
+        whatsappNotifyFeeEnabled: commissions.whatsappNotifyFeeEnabled,
+        whatsappNotifyFee: commissions.whatsappNotifyFee,
         giftWrapFeeEnabled: commissions.giftWrapFeeEnabled,
         giftWrapFee: commissions.giftWrapFee,
         shipmentProtectionFeeEnabled: commissions.shipmentProtectionFeeEnabled,