@mohasinac/appkit 4.62.1 → 4.63.1

package/dist/_internal/shared/features/admin/integrations.d.ts

@@ -104,6 +104,36 @@ export declare function readIntegrationStates(settings: Partial<SiteSettingsDocu
  * Returned as a nested partial rather than applied here, so the caller does
  * one write and the audit log records one action.
  */
-export declare function integrationPatch(id: IntegrationId, enabled: boolean): Record<string, unknown>;
+/**
+ * The settings groups an integration switch may write, and nothing else.
+ *
+ * 🛑 Deliberately a LOCAL shape rather than `Partial<SiteSettingsDocument>`.
+ * This module sits in `_internal/shared` and the settings schema pulls in the
+ * whole admin feature; importing it here to describe four booleans would add
+ * an edge `audit-import-cycles` exists to keep out. The four groups below are
+ * the entire surface these two functions write, so a local type is both
+ * narrower and honest.
+ *
+ * It replaces `Record<string, unknown>`, which said "some object" and
+ * therefore type-checked a patch that wrote a misspelled group or the wrong
+ * value shape — on a function whose whole job is flipping production kill
+ * switches.
+ */
+export interface IntegrationPatch {
+    payment?: {
+        razorpayEnabled?: boolean;
+        phonepeEnabled?: boolean;
+    };
+    messaging?: {
+        emailEnabled: boolean;
+    };
+    shipping?: {
+        provider: "manual" | "shiprocket";
+    };
+    support?: {
+        enabled: boolean;
+    };
+}
+export declare function integrationPatch(id: IntegrationId, enabled: boolean): IntegrationPatch;
 /** Every patch for a bulk enable/disable, merged into one object. */
-export declare function allIntegrationsPatch(enabled: boolean): Record<string, unknown>;
+export declare function allIntegrationsPatch(enabled: boolean): IntegrationPatch;

package/dist/_internal/shared/features/admin/integrations.js

@@ -190,12 +190,6 @@ export function readIntegrationStates(settings) {
         support: { enabled: settings?.support?.enabled !== false },
     };
 }
-/**
- * Turn a desired state into the settings patch that expresses it.
- *
- * Returned as a nested partial rather than applied here, so the caller does
- * one write and the audit log records one action.
- */
 export function integrationPatch(id, enabled) {
     switch (id) {
         case "payments":
@@ -245,9 +239,25 @@ export function allIntegrationsPatch(enabled) {
     const merged = {};
     for (const id of INTEGRATION_ORDER) {
         const patch = integrationPatch(id, enabled);
-        for (const [group, value] of Object.entries(patch)) {
-            merged[group] = { ...merged[group], ...value };
-        }
+        /*
+         * Merged per GROUP, so two integrations writing different fields of the
+         * same group (none do today, but `payment` already carries two flags)
+         * cannot clobber each other.
+         *
+         * Spelled out per key rather than via `Object.entries`, which erased the
+         * types this patch now carries — and listing the groups is also a forcing
+         * function: a fifth integration writing a NEW group does not silently
+         * vanish from the bulk switch, it fails to merge until someone adds the
+         * line. Same argument as the exhaustive `never` in `integrationPatch`.
+         */
+        if (patch.payment)
+            merged.payment = { ...merged.payment, ...patch.payment };
+        if (patch.messaging)
+            merged.messaging = { ...merged.messaging, ...patch.messaging };
+        if (patch.shipping)
+            merged.shipping = { ...merged.shipping, ...patch.shipping };
+        if (patch.support)
+            merged.support = { ...merged.support, ...patch.support };
     }
     return merged;
 }

package/dist/_internal/shared/features/dashboard/hub-sections.d.ts

@@ -0,0 +1,72 @@
+/**
+ * Dashboard hub sections — one hub per nav group, derived from the nav itself.
+ *
+ * ## What a hub is
+ *
+ * Each dashboard (`/admin`, `/store`, `/user`) has a landing page listing its
+ * SECTIONS, and each section has a hub listing the SCREENS in it. Twelve admin
+ * sections, six store, four user — 22 hubs, served by three dynamic routes
+ * (`/{portal}/sections/[section]`), because a hub has no content of its own
+ * beyond the group it names.
+ *
+ * ## 🛑 Everything here is DERIVED. There is no second list.
+ *
+ * `ADMIN_NAV_GROUPS` / `STORE_NAV_GROUPS` / `USER_NAV_GROUPS` already carry a
+ * title per group and, per item, an href, a label, a `description` ("what this
+ * screen is FOR, in the user's words") and `keywords`. That is the whole card:
+ * a hub needs no copy of its own, and must not have any.
+ *
+ * The alternative was a hand-written array of 22 section descriptors, which is
+ * Root Cause #61 pre-written — ten independent enumerations of one union, nine
+ * of which silently did not grow. `AdminGuideHubView` is the live warning: it
+ * is already a hub, it is the visual pattern this follows, and it hand-writes
+ * its card list, so a guide added to the nav does not appear on it.
+ *
+ * ## The slug
+ *
+ * `hubSectionSlug` is the only mapping between a group title and its URL. It is
+ * lossy by construction ("Trust & Safety" → `trust-safety`), so two titles
+ * CAN collide — and a collision makes one hub permanently unreachable while
+ * the other answers for both, with nothing erroring.
+ *
+ * That is checked statically rather than defended at runtime:
+ * `audit-dashboard-hub-coverage` fails on a duplicate slug within a portal. A
+ * runtime throw would turn a naming choice into a 500 on a live dashboard, and
+ * a silent de-dupe would hide exactly the state the audit exists to name.
+ */
+import type { SidebarNavGroup, SidebarNavItem } from "../layout/types";
+/** One section of a dashboard: a nav group plus the slug its hub answers on. */
+export interface DashboardHubSection {
+    /** URL segment — derived from `title`, never authored. */
+    slug: string;
+    /** The group's own title, rendered verbatim as the section heading. */
+    title: string;
+    /** The screens in this section, already permission-filtered by the caller. */
+    items: SidebarNavItem[];
+}
+/**
+ * A group title as a URL segment.
+ *
+ * Deliberately the same shape as `navItemId`'s path normalisation — lower-case,
+ * non-alphanumerics collapsed to a single hyphen, no leading or trailing
+ * hyphen. `&` and `/` carry no meaning in a slug, so "Trust & Safety" and
+ * "Orders & Reviews" become `trust-safety` and `orders-reviews`.
+ */
+export declare function hubSectionSlug(title: string): string;
+/**
+ * Every section of a dashboard, in nav order.
+ *
+ * 🛑 Pass groups that are ALREADY permission-filtered (`filterNavGroups`). This
+ * function deliberately applies no filter of its own: two places deciding
+ * visibility is how a hub ends up offering a card the sidebar hides, and the
+ * sidebar's answer is the one the route guards agree with.
+ */
+export declare function hubSections(groups: readonly SidebarNavGroup[]): DashboardHubSection[];
+/**
+ * The section a `[section]` route segment names, or `undefined`.
+ *
+ * `undefined` is the caller's cue to `notFound()`. It must not fall back to the
+ * first section: a mistyped or retired slug would then render a real page under
+ * the wrong heading, which is indistinguishable from a working link.
+ */
+export declare function findHubSection(groups: readonly SidebarNavGroup[], slug: string): DashboardHubSection | undefined;

package/dist/_internal/shared/features/dashboard/hub-sections.js

@@ -0,0 +1,75 @@
+/**
+ * Dashboard hub sections — one hub per nav group, derived from the nav itself.
+ *
+ * ## What a hub is
+ *
+ * Each dashboard (`/admin`, `/store`, `/user`) has a landing page listing its
+ * SECTIONS, and each section has a hub listing the SCREENS in it. Twelve admin
+ * sections, six store, four user — 22 hubs, served by three dynamic routes
+ * (`/{portal}/sections/[section]`), because a hub has no content of its own
+ * beyond the group it names.
+ *
+ * ## 🛑 Everything here is DERIVED. There is no second list.
+ *
+ * `ADMIN_NAV_GROUPS` / `STORE_NAV_GROUPS` / `USER_NAV_GROUPS` already carry a
+ * title per group and, per item, an href, a label, a `description` ("what this
+ * screen is FOR, in the user's words") and `keywords`. That is the whole card:
+ * a hub needs no copy of its own, and must not have any.
+ *
+ * The alternative was a hand-written array of 22 section descriptors, which is
+ * Root Cause #61 pre-written — ten independent enumerations of one union, nine
+ * of which silently did not grow. `AdminGuideHubView` is the live warning: it
+ * is already a hub, it is the visual pattern this follows, and it hand-writes
+ * its card list, so a guide added to the nav does not appear on it.
+ *
+ * ## The slug
+ *
+ * `hubSectionSlug` is the only mapping between a group title and its URL. It is
+ * lossy by construction ("Trust & Safety" → `trust-safety`), so two titles
+ * CAN collide — and a collision makes one hub permanently unreachable while
+ * the other answers for both, with nothing erroring.
+ *
+ * That is checked statically rather than defended at runtime:
+ * `audit-dashboard-hub-coverage` fails on a duplicate slug within a portal. A
+ * runtime throw would turn a naming choice into a 500 on a live dashboard, and
+ * a silent de-dupe would hide exactly the state the audit exists to name.
+ */
+/**
+ * A group title as a URL segment.
+ *
+ * Deliberately the same shape as `navItemId`'s path normalisation — lower-case,
+ * non-alphanumerics collapsed to a single hyphen, no leading or trailing
+ * hyphen. `&` and `/` carry no meaning in a slug, so "Trust & Safety" and
+ * "Orders & Reviews" become `trust-safety` and `orders-reviews`.
+ */
+export function hubSectionSlug(title) {
+    return title
+        .toLowerCase()
+        .replace(/[^a-z0-9]+/g, "-")
+        .replace(/^-+|-+$/g, "");
+}
+/**
+ * Every section of a dashboard, in nav order.
+ *
+ * 🛑 Pass groups that are ALREADY permission-filtered (`filterNavGroups`). This
+ * function deliberately applies no filter of its own: two places deciding
+ * visibility is how a hub ends up offering a card the sidebar hides, and the
+ * sidebar's answer is the one the route guards agree with.
+ */
+export function hubSections(groups) {
+    return groups.map((group) => ({
+        slug: hubSectionSlug(group.title),
+        title: group.title,
+        items: group.items,
+    }));
+}
+/**
+ * The section a `[section]` route segment names, or `undefined`.
+ *
+ * `undefined` is the caller's cue to `notFound()`. It must not fall back to the
+ * first section: a mistyped or retired slug would then render a real page under
+ * the wrong heading, which is indistinguishable from a working link.
+ */
+export function findHubSection(groups, slug) {
+    return hubSections(groups).find((section) => section.slug === slug);
+}

package/dist/_internal/shared/features/emi/choice.d.ts

@@ -0,0 +1,98 @@
+/**
+ * EMI is an OPT-IN ON THE ORDER, not a way of paying.
+ *
+ * 🛑 Until 2026-10-22 it was a sixth `paymentMethod`, and that conflated two
+ * independent decisions: *do I want to spread this over months* and *how does
+ * the money reach you*. A buyer who wanted instalments had, by picking "Pay in
+ * EMI", also implicitly chosen the tender — and the tender they got was the
+ * manual bank/UPI proof flow, because `MANUAL_PAYMENT_METHODS` is
+ * `["cash","upi_manual","emi"]` and `hasPaymentWindow` tested for `EMI`
+ * alongside the other two. Nothing in the UI said so.
+ *
+ * The two axes are now separate: `emiOptIn` + `emiTenureMonths` describe the
+ * arrangement, `paymentMethod` describes the tender for the token. Everything
+ * downstream — the schedule, the surcharge, the order fields — keys on
+ * `emiOptIn`, so an EMI order can be paid online or by hand.
+ *
+ * ── Why the legacy value is MAPPED rather than rejected ────────────────────
+ *
+ * A browser tab opened before this change still posts `paymentMethod: "emi"`.
+ * Mapping it to `{ tender: "upi_manual", emiOptIn: true }` is not a guess: it
+ * is exactly what that request did before, measured at
+ * `actions.ts`'s `hasPaymentWindow` (a 15-minute window plus a displayed UPI
+ * id — i.e. the manual-proof flow) and at `MANUAL_PAYMENT_METHODS`. So the
+ * stale tab keeps behaving identically instead of 400ing at the one moment a
+ * buyer is trying to pay.
+ *
+ * ── Why this returns a RESULT rather than throwing ─────────────────────────
+ *
+ * The same answer has to serve two callers with different jobs: the order
+ * action, which must refuse, and the pricing preview, which must still price
+ * *something* rather than 500 while a buyer fiddles with a radio. A plain
+ * value lets each decide.
+ */
+import type { CheckoutPaymentMethod } from "../checkout/config";
+/** The tender — `emi` is excluded by construction, which is the whole point. */
+export type EmiTender = Exclude<CheckoutPaymentMethod, "emi">;
+export interface EmiChoiceRequest {
+    paymentMethod: CheckoutPaymentMethod;
+    /**
+     * The DURABLE selection, read off `CartDocument.emiPlan`.
+     *
+     * 🛑 Not a request-body field, and that is the point: the online path
+     * decides the capture amount in one request and writes the order in
+     * another, so a body-carried choice cannot be read by both. See the schema
+     * note on `CartDocument.emiPlan`.
+     */
+    cartEmiPlan?: {
+        tenureMonths: number;
+    } | null;
+    /**
+     * Legacy only: a tab opened before 2026-10-22 posts
+     * `paymentMethod: "emi"` plus a tenure in the body, with nothing on the
+     * cart. Honoured so that buyer is not 400'd mid-payment, and ignored
+     * whenever the cart carries a plan.
+     */
+    legacyTenureMonths?: number;
+}
+export interface EmiChoice {
+    paymentMethod: EmiTender;
+    emiOptIn: boolean;
+    /**
+     * 🛑 Set ONLY when `emiOptIn` is true. A tenure left over from a radio the
+     * buyer un-ticked must not reach `computeBuyerEmiQuote`, or they are
+     * surcharged for an arrangement they declined.
+     */
+    emiTenureMonths?: number;
+}
+export type EmiChoiceResult = {
+    ok: true;
+    choice: EmiChoice;
+} | {
+    ok: false;
+    reason: string;
+};
+/**
+ * Normalise a checkout request's payment axes. **Every** caller that reads
+ * `paymentMethod` or decides whether to build an EMI schedule must resolve
+ * through this — two copies of "is this an EMI order" is the drift that this
+ * function exists to end (Root Cause #75).
+ */
+/**
+ * The TENDER alone — a pure function of the request, needing no cart.
+ *
+ * Split out because the early checkout guards (is COD enabled, is manual UPI
+ * accepted) run *before* the cart is read and must already be talking about
+ * the real tender. `resolveEmiChoice` calls this, so the legacy mapping has
+ * one definition rather than two that agree today.
+ */
+export declare function emiTenderFor(method: CheckoutPaymentMethod): EmiTender;
+export declare function resolveEmiChoice(request: EmiChoiceRequest): EmiChoiceResult;
+/**
+ * The tenders a buyer may pick while opted in, for disabling a control rather
+ * than letting them pick it and be refused at submit. Derived from the same
+ * map the refusal reads, so the affordance and the rule cannot disagree.
+ */
+export declare function isTenderCompatibleWithEmi(method: EmiTender): boolean;
+/** Why a tender is unavailable while instalments are on. `null` when it is available. */
+export declare function emiTenderBlockReason(method: EmiTender): string | null;

package/dist/_internal/shared/features/emi/choice.js

@@ -0,0 +1,69 @@
+/** The tender a pre-2026-10-22 `paymentMethod: "emi"` request actually got. */
+const EMI_LEGACY_TENDER = "upi_manual";
+/**
+ * Tenders that cannot carry an instalment plan, with the reason stated rather
+ * than the combination silently dropped.
+ *
+ * - `cod` collects the balance at the door; "the balance" is precisely what an
+ *   instalment plan is for. The two describe opposite settlements of the same
+ *   money.
+ * - `admin_bypass` marks an order paid without a payment. The existing order
+ *   writer already nulls every `emi*` field under `adminBypass`, so the
+ *   combination has never produced an EMI order — this refuses it out loud
+ *   instead of producing a plain order that looks like the EMI one the tester
+ *   asked for.
+ */
+const EMI_INCOMPATIBLE = {
+    cod: "Cash on delivery collects the balance when the parcel arrives, so it cannot also be paid in monthly instalments. Pay the token online or by bank/UPI transfer instead.",
+    admin_bypass: "The admin bypass marks an order paid without taking a payment, so there is no token to collect and no instalment plan to start.",
+};
+/**
+ * Normalise a checkout request's payment axes. **Every** caller that reads
+ * `paymentMethod` or decides whether to build an EMI schedule must resolve
+ * through this — two copies of "is this an EMI order" is the drift that this
+ * function exists to end (Root Cause #75).
+ */
+/**
+ * The TENDER alone — a pure function of the request, needing no cart.
+ *
+ * Split out because the early checkout guards (is COD enabled, is manual UPI
+ * accepted) run *before* the cart is read and must already be talking about
+ * the real tender. `resolveEmiChoice` calls this, so the legacy mapping has
+ * one definition rather than two that agree today.
+ */
+export function emiTenderFor(method) {
+    return method === "emi" ? EMI_LEGACY_TENDER : method;
+}
+export function resolveEmiChoice(request) {
+    const legacy = request.paymentMethod === "emi";
+    const paymentMethod = emiTenderFor(request.paymentMethod);
+    /*
+     * The cart WINS. A stale tab's body tenure is a fallback for the one case
+     * where there is nothing on the cart to read — never an override, or a
+     * client could re-price an order the server has already quoted.
+     */
+    const tenureMonths = request.cartEmiPlan?.tenureMonths ?? (legacy ? request.legacyTenureMonths : undefined);
+    const emiOptIn = tenureMonths !== undefined;
+    if (!emiOptIn) {
+        return { ok: true, choice: { paymentMethod, emiOptIn: false } };
+    }
+    const incompatible = EMI_INCOMPATIBLE[paymentMethod];
+    if (incompatible)
+        return { ok: false, reason: incompatible };
+    return {
+        ok: true,
+        choice: { paymentMethod, emiOptIn: true, emiTenureMonths: tenureMonths },
+    };
+}
+/**
+ * The tenders a buyer may pick while opted in, for disabling a control rather
+ * than letting them pick it and be refused at submit. Derived from the same
+ * map the refusal reads, so the affordance and the rule cannot disagree.
+ */
+export function isTenderCompatibleWithEmi(method) {
+    return EMI_INCOMPATIBLE[method] === undefined;
+}
+/** Why a tender is unavailable while instalments are on. `null` when it is available. */
+export function emiTenderBlockReason(method) {
+    return EMI_INCOMPATIBLE[method] ?? null;
+}

package/dist/_internal/shared/features/emi/group.d.ts

@@ -0,0 +1,84 @@
+import { type BuyerEmiQuote, type EmiScheduleResult, type EmiSettings } from "./schedule";
+/** What every caller knows about one seller-group at the moment EMI is priced. */
+export interface GroupEmiInput {
+    /** Already normalised by `resolveEmiChoice` — never derived from a tender. */
+    emiOptIn: boolean;
+    emiTenureMonths?: number;
+    /** The group's GOODS subtotal, before coupon and before any fee. */
+    groupSubtotal: number;
+    /** `StoreDocument.emiEnabled` for this group's seller. */
+    sellerEmiEnabled: boolean;
+}
+/**
+ * The gate, shared so "does EMI apply to this group" is answered identically
+ * everywhere.
+ *
+ * 🛑 Returns a REASON rather than a boolean, because the two callers do
+ * opposite things with it: order creation must refuse (an ineligible EMI order
+ * that silently becomes a full-price order is money the buyer did not agree
+ * to), while the preview must carry on and simply price no surcharge (a
+ * preview that throws blanks the Order Summary while the buyer is still
+ * choosing). A boolean would have forced each to re-derive the reason.
+ */
+export type GroupEmiGate = {
+    applies: true;
+} | {
+    applies: false;
+    reason: "not_opted_in" | "no_tenure" | "no_settings" | string;
+};
+export declare function groupEmiGate(input: GroupEmiInput, settings: Pick<EmiSettings, "enabled" | "minOrderValue"> | null | undefined): GroupEmiGate;
+/**
+ * The buyer-visible quote for one group, or `null` when EMI does not apply.
+ *
+ * For the preview and for the gateway CAPTURE amount — neither needs the
+ * platform/seller surcharge split, and neither should be able to print it.
+ */
+export declare function groupEmiQuote(input: GroupEmiInput, settings: (Pick<EmiSettings, "enabled" | "minOrderValue" | "tokenPercent" | "billingDay" | "surchargePercentPerMonth">) | null | undefined, purchaseDate?: Date): BuyerEmiQuote | null;
+/**
+ * The server-side schedule for one group, including the surcharge split that
+ * is persisted onto the order. For the two order WRITERS only.
+ */
+export declare function groupEmiSchedule(input: GroupEmiInput, settings: EmiSettings | null | undefined, purchaseDate?: Date): EmiScheduleResult | null;
+/**
+ * What is actually collected at checkout: the order total, less any points
+ * tendered, less whatever has been deferred into instalments.
+ *
+ * 🛑 Composes with the points tender rather than replacing it. Both reduce
+ * what is collected and they are independent, so an EMI order part-funded by
+ * points must subtract both — writing `total − remainingBalance` would hand
+ * back the points discount, and `total − pointsApplied` alone is the bug this
+ * function exists to fix. Floored at zero: points can cover at most half an
+ * order, so the sum cannot genuinely go negative, and clamping means a future
+ * change to that cap degrades to "collect nothing" rather than to a refund.
+ */
+export declare function amountDueNow(args: {
+    orderTotal: number;
+    pointsApplied: number;
+    /** `EmiScheduleResult.remainingBalance`, or 0 on a non-EMI order. */
+    emiRemainingBalance: number;
+}): number;
+/**
+ * The `emi*` fields written onto an order document.
+ *
+ * 🛑 One builder for both creation paths. These are eleven fields that have to
+ * be written identically by `createOrderForGroup` and
+ * `createPhonePeGroupOrder`, and the second one carried **none of them** —
+ * every order paid online lost its instalment plan entirely. Two hand-written
+ * copies is the create-vs-create axis of Root Cause #39, and these two
+ * functions have already drifted once before over add-on fees (#65).
+ */
+export declare function emiOrderFields(schedule: EmiScheduleResult | null, emiTenureMonths: number | undefined): {
+    emiEnabled?: true;
+    emiTenureMonths?: number;
+    emiTokenAmount?: number;
+    emiSurchargeAmount?: number;
+    emiSurchargeSellerShare?: number;
+    emiInstallments?: Array<{
+        index: number;
+        dueDate: Date;
+        amount: number;
+        status: "pending";
+    }>;
+    emiRemainingBalance?: number;
+    emiComplete?: false;
+};

package/dist/_internal/shared/features/emi/group.js

@@ -0,0 +1,126 @@
+/**
+ * Per-order-group EMI terms, and the one definition of what is COLLECTED NOW
+ * on an instalment order.
+ *
+ * ── Why this file exists ──────────────────────────────────────────────────
+ *
+ * Four money paths have to agree about an EMI order: the pricing preview (what
+ * the buyer is shown), `createOrderForGroup` (COD/manual), the gateway capture
+ * in `/api/payment/create-order`, and `createPhonePeGroupOrder` (the order
+ * written after that capture). Three of them had no EMI code at all, and the
+ * fourth computed its schedule inline — so adding the online tender by copying
+ * that block would have produced the exact shape Root Cause #75 is about: a
+ * rule reachable by copy-paste, copied, and the copy never learning about the
+ * branch added later. `lineTotalFor` was the last instance; this is the same
+ * fix applied before the divergence rather than after it.
+ *
+ * ── 🛑 THE DEFECT THIS CLOSES, which is larger than the refactor ──────────
+ *
+ * `emiTokenAmount` was written onto every EMI order and had **ZERO readers**,
+ * measured across `src` and `appkit/src`. The buyer's manual-payment page asks
+ * for `order.amountDue ?? order.total`, and `amountDue` was set only when
+ * points applied — so an EMI buyer was asked to transfer the **entire order
+ * total up front** *and* handed a schedule of monthly instalments. The token
+ * percentage was computed, stored, scheduled around, and never charged.
+ *
+ * `amountDueNow` below is that fix, and it is deliberately a SUBTRACTION
+ * rather than a re-derivation:
+ *
+ *     orderTotal − remainingBalance
+ *   = (subtotal + surcharge + fees) − (principalRemaining + surcharge)
+ *   = (subtotal − principalRemaining) + fees
+ *   = token + fees
+ *
+ * Provably the token plus every additive charge, with no second arithmetic to
+ * drift from `computeBuyerEmiQuote`'s own. A function that recomputed
+ * `tokenPercent × subtotal + …` would be a fifth place rounding money.
+ */
+import { roundRupees } from "../../../../utils/number.formatter.js";
+import { checkEmiEligibility, computeBuyerEmiQuote, computeEmiSchedule, } from "./schedule.js";
+export function groupEmiGate(input, settings) {
+    if (!input.emiOptIn)
+        return { applies: false, reason: "not_opted_in" };
+    if (!input.emiTenureMonths)
+        return { applies: false, reason: "no_tenure" };
+    if (!settings)
+        return { applies: false, reason: "no_settings" };
+    const eligibility = checkEmiEligibility(input.groupSubtotal, input.sellerEmiEnabled, settings);
+    if (!eligibility.eligible)
+        return { applies: false, reason: eligibility.reason };
+    return { applies: true };
+}
+/**
+ * The buyer-visible quote for one group, or `null` when EMI does not apply.
+ *
+ * For the preview and for the gateway CAPTURE amount — neither needs the
+ * platform/seller surcharge split, and neither should be able to print it.
+ */
+export function groupEmiQuote(input, settings, purchaseDate) {
+    if (!settings)
+        return null;
+    if (!groupEmiGate(input, settings).applies)
+        return null;
+    return computeBuyerEmiQuote(input.groupSubtotal, input.emiTenureMonths, settings, purchaseDate);
+}
+/**
+ * The server-side schedule for one group, including the surcharge split that
+ * is persisted onto the order. For the two order WRITERS only.
+ */
+export function groupEmiSchedule(input, settings, purchaseDate) {
+    if (!settings)
+        return null;
+    if (!groupEmiGate(input, settings).applies)
+        return null;
+    return computeEmiSchedule(input.groupSubtotal, input.emiTenureMonths, settings, purchaseDate);
+}
+/**
+ * What is actually collected at checkout: the order total, less any points
+ * tendered, less whatever has been deferred into instalments.
+ *
+ * 🛑 Composes with the points tender rather than replacing it. Both reduce
+ * what is collected and they are independent, so an EMI order part-funded by
+ * points must subtract both — writing `total − remainingBalance` would hand
+ * back the points discount, and `total − pointsApplied` alone is the bug this
+ * function exists to fix. Floored at zero: points can cover at most half an
+ * order, so the sum cannot genuinely go negative, and clamping means a future
+ * change to that cap degrades to "collect nothing" rather than to a refund.
+ */
+export function amountDueNow(args) {
+    return roundRupees(Math.max(0, args.orderTotal - args.pointsApplied - args.emiRemainingBalance));
+}
+/**
+ * The `emi*` fields written onto an order document.
+ *
+ * 🛑 One builder for both creation paths. These are eleven fields that have to
+ * be written identically by `createOrderForGroup` and
+ * `createPhonePeGroupOrder`, and the second one carried **none of them** —
+ * every order paid online lost its instalment plan entirely. Two hand-written
+ * copies is the create-vs-create axis of Root Cause #39, and these two
+ * functions have already drifted once before over add-on fees (#65).
+ */
+export function emiOrderFields(schedule, emiTenureMonths) {
+    if (!schedule)
+        return {};
+    return {
+        emiEnabled: true,
+        emiTenureMonths,
+        emiTokenAmount: schedule.tokenAmount,
+        emiSurchargeAmount: schedule.surchargeAmount,
+        /*
+         * Persisted even though it moves no money at checkout: it is the
+         * platform/seller split of the surcharge, and the payout run needs it to
+         * credit the seller their share. It was discarded on every EMI order until
+         * it was added here. 🛑 It is `PRIVATE_*_FIELDS` — it belongs on the
+         * document and must never reach a buyer-facing projection.
+         */
+        emiSurchargeSellerShare: schedule.surchargeSellerShare,
+        emiInstallments: schedule.installments.map((i) => ({
+            index: i.index,
+            dueDate: i.dueDate,
+            amount: i.amount,
+            status: "pending",
+        })),
+        emiRemainingBalance: schedule.remainingBalance,
+        emiComplete: false,
+    };
+}