@mohasinac/appkit 4.30.19 → 4.31.0

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",
+};

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

@@ -1,3 +1,4 @@
+import type { ListingType } from "../../../../features/products/types/index";
 /**
  * The floor, as a percentage of the listed price, below which an offer is
  * rejected — used whenever a listing does not set its own `minOfferPercent`.
@@ -28,3 +29,67 @@ export declare function minOfferAmount(listedPrice: number, percent?: number | n
  * below the floor the seller has said they don't want to hear it.
  */
 export declare function isOfferAmountValid(amount: number, listedPrice: number, percent?: number | null): boolean;
+/**
+ * Is Make-an-Offer the only way to buy this listing type?
+ *
+ * True exactly when the type can be offered on but has no cart line — today
+ * that is `classified` alone (`canAddToCart: false`, `canMakeOffer: true`).
+ *
+ * Derived from the capability registry rather than testing for `"classified"`,
+ * so a future type that lands in the same shape inherits the rule instead of
+ * silently becoming unbuyable. That is not hypothetical: this function exists
+ * because classified's actual purchase path was a `conversations` chat thread,
+ * and when that feature was deleted the listing type would have been left with
+ * no way to transact at all.
+ */
+export declare function offerIsOnlyPurchasePath(listingType: ListingType): boolean;
+/**
+ * May a buyer send an offer on this listing at all?
+ *
+ * The two ordinary gates are the type's `canMakeOffer` capability and the
+ * seller's own `allowOffers` opt-in. The third clause is the point:
+ *
+ * 🛑 **`allowOffers` is an opt-in to NEGOTIATION, not to being contactable.**
+ * On a listing with no cart, unchecking it would mean the buyer has no way to
+ * transact whatsoever — the page would render a price and no path to it. So
+ * where the offer IS the purchase path, an offer is always permitted; what
+ * `allowOffers` then controls is whether the buyer may propose a price *below*
+ * the asking one. See `resolveOfferBounds`.
+ */
+export declare function offersEnabledFor(listingType: ListingType, allowOffers?: boolean): boolean;
+export interface OfferBounds {
+    /** Lowest legal amount, inclusive. */
+    min: number;
+    /** Highest legal amount, inclusive. */
+    max: number;
+    /**
+     * The offer is pinned to the asking price — the buyer is requesting to buy,
+     * not negotiating. True when the offer is the only purchase path and the
+     * seller has not opted into haggling.
+     *
+     * Callers use this for COPY, never for a second bounds calculation: `min`
+     * and `max` are already equal when it is true.
+     */
+    isBuyRequest: boolean;
+}
+/**
+ * The amounts this listing will accept, as one answer for the form, the schema
+ * and the server.
+ *
+ * Two cases beyond the ordinary one, both driven by there being no cart:
+ *
+ * - **No haggling opted in** → `min === max === listedPrice`. A "request to buy".
+ * - **Haggling opted in** → the usual floor, but the ceiling is the asking price
+ *   **inclusive**. On a cartable listing an offer at full price is rejected with
+ *   "use Add to Cart instead", which on a classified is advice the buyer cannot
+ *   take — there is no cart button to use. That rejection was already a dead end
+ *   before this change.
+ */
+export declare function resolveOfferBounds(opts: {
+    listingType: ListingType;
+    listedPrice: number;
+    minOfferPercent?: number | null;
+    allowOffers?: boolean;
+}): OfferBounds;
+/** Whether `amount` falls within `bounds`. The one comparison, shared. */
+export declare function isWithinOfferBounds(amount: number, bounds: OfferBounds): boolean;

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

@@ -11,15 +11,18 @@
  *       Same discipline as `resolveMinBid` in the auctions config next door.
  *
  * EXPORTS:
- *   DEFAULT_MIN_OFFER_PERCENT, minOfferAmount, isOfferAmountValid
+ *   DEFAULT_MIN_OFFER_PERCENT, minOfferAmount, isOfferAmountValid,
+ *   offerIsOnlyPurchasePath, offersEnabledFor, resolveOfferBounds,
+ *   type OfferBounds
  *
  * @tag domain:offers,seller
  * @tag layer:shared
  * @tag pattern:none
  * @tag access:isomorphic
- * @tag consumers:offer-actions,MakeOfferButton,ProductDetailPageView,ProductForm,SellerProductShell
+ * @tag consumers:offer-actions,MakeOfferButton,ProductDetailPageView,ClassifiedDetailPageView,ProductForm,SellerProductShell
  * @tag sideEffects:none
  */
+import { canAddToCart, canMakeOffer, } from "../../listing-types/capabilities";
 /**
  * The floor, as a percentage of the listed price, below which an offer is
  * rejected — used whenever a listing does not set its own `minOfferPercent`.
@@ -57,3 +60,71 @@ export function minOfferAmount(listedPrice, percent) {
 export function isOfferAmountValid(amount, listedPrice, percent) {
     return amount >= minOfferAmount(listedPrice, percent) && amount < listedPrice;
 }
+/* -------------------------------------------------------------------------
+ * Listings whose ONLY purchase path is an offer
+ * ---------------------------------------------------------------------- */
+/**
+ * Is Make-an-Offer the only way to buy this listing type?
+ *
+ * True exactly when the type can be offered on but has no cart line — today
+ * that is `classified` alone (`canAddToCart: false`, `canMakeOffer: true`).
+ *
+ * Derived from the capability registry rather than testing for `"classified"`,
+ * so a future type that lands in the same shape inherits the rule instead of
+ * silently becoming unbuyable. That is not hypothetical: this function exists
+ * because classified's actual purchase path was a `conversations` chat thread,
+ * and when that feature was deleted the listing type would have been left with
+ * no way to transact at all.
+ */
+export function offerIsOnlyPurchasePath(listingType) {
+    return canMakeOffer(listingType) && !canAddToCart(listingType);
+}
+/**
+ * May a buyer send an offer on this listing at all?
+ *
+ * The two ordinary gates are the type's `canMakeOffer` capability and the
+ * seller's own `allowOffers` opt-in. The third clause is the point:
+ *
+ * 🛑 **`allowOffers` is an opt-in to NEGOTIATION, not to being contactable.**
+ * On a listing with no cart, unchecking it would mean the buyer has no way to
+ * transact whatsoever — the page would render a price and no path to it. So
+ * where the offer IS the purchase path, an offer is always permitted; what
+ * `allowOffers` then controls is whether the buyer may propose a price *below*
+ * the asking one. See `resolveOfferBounds`.
+ */
+export function offersEnabledFor(listingType, allowOffers) {
+    if (!canMakeOffer(listingType))
+        return false;
+    return allowOffers === true || offerIsOnlyPurchasePath(listingType);
+}
+/**
+ * The amounts this listing will accept, as one answer for the form, the schema
+ * and the server.
+ *
+ * Two cases beyond the ordinary one, both driven by there being no cart:
+ *
+ * - **No haggling opted in** → `min === max === listedPrice`. A "request to buy".
+ * - **Haggling opted in** → the usual floor, but the ceiling is the asking price
+ *   **inclusive**. On a cartable listing an offer at full price is rejected with
+ *   "use Add to Cart instead", which on a classified is advice the buyer cannot
+ *   take — there is no cart button to use. That rejection was already a dead end
+ *   before this change.
+ */
+export function resolveOfferBounds(opts) {
+    const { listingType, listedPrice, minOfferPercent, allowOffers } = opts;
+    const onlyPath = offerIsOnlyPurchasePath(listingType);
+    if (onlyPath && allowOffers !== true) {
+        return { min: listedPrice, max: listedPrice, isBuyRequest: true };
+    }
+    return {
+        min: minOfferAmount(listedPrice, minOfferPercent),
+        // `- 0.01` and not `- 1`: money is decimal rupees, and this is the exact
+        // ceiling `makeOfferFormSchema` has always enforced.
+        max: onlyPath ? listedPrice : Math.round((listedPrice - 0.01) * 100) / 100,
+        isBuyRequest: false,
+    };
+}
+/** Whether `amount` falls within `bounds`. The one comparison, shared. */
+export function isWithinOfferBounds(amount, bounds) {
+    return amount >= bounds.min && amount <= bounds.max;
+}

package/dist/_internal/shared/features/orders/schema.d.ts

@@ -13,7 +13,7 @@ export declare const createOrderSchema: z.ZodObject<{
         quantity: number;
         productId: string;
     }>, "many">;
-    shippingAddress: z.ZodObject<{
+    shippingAddress: z.ZodEffects<z.ZodObject<{
         fullName: z.ZodString;
         phone: z.ZodString;
         addressLine1: z.ZodString;
@@ -40,6 +40,24 @@ export declare const createOrderSchema: z.ZodObject<{
         pincode: string;
         country?: string | undefined;
         addressLine2?: string | undefined;
+    }>, {
+        country: string;
+        fullName: string;
+        phone: string;
+        addressLine1: string;
+        city: string;
+        state: string;
+        pincode: string;
+        addressLine2?: string | undefined;
+    }, {
+        fullName: string;
+        phone: string;
+        addressLine1: string;
+        city: string;
+        state: string;
+        pincode: string;
+        country?: string | undefined;
+        addressLine2?: string | undefined;
     }>;
     paymentMethod: z.ZodEnum<["razorpay", "cod", "upi"]>;
     couponCode: z.ZodOptional<z.ZodString>;

package/dist/_internal/shared/features/orders/schema.js

@@ -1,5 +1,17 @@
 import { z } from "zod";
+import { DEFAULT_COUNTRY, isValidPostalCode, postalLabelFor, } from "../../../../constants/geo/countries";
 import { ORDER_CANCEL_REASON_MAX_LENGTH, ORDER_NOTE_MAX_LENGTH, ORDER_TRACKING_NUMBER_MAX_LENGTH, } from "./config";
+/*
+ * The order's own SNAPSHOT of where it shipped, denormalised onto the order
+ * document at creation. Its field names (`pincode`) are stored on every
+ * existing order, so renaming them to match `AddressDocument` is a data
+ * migration rather than a refactor — and a snapshot deliberately does NOT
+ * follow the address it was copied from.
+ *
+ * The postal RULE is shared, which is the half that was wrong: `/^\d{6}$/`
+ * is India-only, on an order whose country is whatever the buyer chose.
+ */
+// audit-address-shape-ok: an order's frozen shipping snapshot, not the address entity
 const addressSchema = z.object({
     fullName: z.string().min(1),
     phone: z.string().min(10).max(15),
@@ -7,8 +19,16 @@ const addressSchema = z.object({
     addressLine2: z.string().optional(),
     city: z.string().min(1),
     state: z.string().min(1),
-    pincode: z.string().regex(/^\d{6}$/, "Pincode must be 6 digits"),
-    country: z.string().default("India"),
+    pincode: z.string().trim().min(1, "A postal code is required."),
+    country: z.string().default(DEFAULT_COUNTRY),
+}).superRefine((v, ctx) => {
+    if (!isValidPostalCode(v.country, v.pincode)) {
+        ctx.addIssue({
+            code: z.ZodIssueCode.custom,
+            path: ["pincode"],
+            message: `That is not a valid ${postalLabelFor(v.country)}.`,
+        });
+    }
 });
 export const createOrderSchema = z.object({
     items: z.array(z.object({

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

@@ -25,9 +25,18 @@ export interface PublicSiteSettings {
     payment: {
         otpCheckoutThreshold?: number;
     };
-    /** Deliberately NOT the full `featureFlags` — `adminCheckoutBypass` must never be advertised publicly. */
-    featureFlags: {
-        listingTypes?: SiteSettingsDocument["featureFlags"]["listingTypes"];
+    /**
+     * Which listing types the site offers — the client needs this to avoid
+     * rendering a browse tab for a type nothing will return.
+     *
+     * Deliberately NOT the whole `listings` block: `categoryTypes` has no client
+     * reader. This was `featureFlags.listingTypes` until that group was deleted
+     * on 2026-08-29; the projection stayed narrow for the same reason it always
+     * was — a public payload carries what a client demonstrably reads, nothing
+     * more (Root Cause #70).
+     */
+    listings: {
+        listingTypes?: NonNullable<SiteSettingsDocument["listings"]>["listingTypes"];
     };
     notificationChannels?: NotificationChannelConfig;
     announcementBar?: SiteSettingsDocument["announcementBar"];