@mohasinac/appkit 4.62.0 → 4.63.0

package/dist/server.js

@@ -861,7 +861,7 @@ export { reasonToHttp, EVENT_DRAW_REASON, } from "./_internal/server/jobs/core/e
 // [SERVER-ONLY] S-SBUNI-RULES — refund action (Razorpay + manual paths)
 export { processRefundAction, } from "./_internal/server/features/refunds/actions.js";
 // [SERVER-ONLY] Shared fee calculator — platform/gateway/GST/COD handling/addon fee math.
-export { computeCheckoutFees, computePayoutDeduction, computeCodHandlingFee, computeGiftWrapFee, computeShipmentProtectionFee, computeSaleProtectionFee, } from "./_internal/shared/fees/calculator.js";
+export { computeCheckoutFees, allocateCheckoutFees, computePayoutDeduction, computeCodHandlingFee, computeGiftWrapFee, computeShipmentProtectionFee, computeSaleProtectionFee, } from "./_internal/shared/fees/calculator.js";
 // C5e buyer protections — the pure three-tier gate plus the one fee pair
 // every money path must agree on. Public API because the capture route
 // (/api/payment/create-order) is one of the three sites that must agree.
@@ -1327,6 +1327,7 @@ export { piiBlindIndex } from "./security/index.js";
 export { piiIndicesFor } from "./security/index.js";
 export { reserveUserSlug, userSlugBase, USER_SLUGS_COLLECTION } from "./features/auth/actions/user-slug.js";
 export { resolveProfileUser } from "./features/auth/actions/profile-actions.js";
+export { getBuyerActivityStats, getProfileStats, } from "./features/auth/actions/profile-actions.js";
 export { getPiiConfigError } from "./security/index.js";
 export { encryptPayoutDetails } from "./security/index.js";
 export { decryptPayoutDetails } from "./security/index.js";
@@ -1539,6 +1540,17 @@ export { REFUND_COPY } from "./_internal/shared/features/orders/refund-copy.js";
 // See the module docstring for why the exempt set is "seller or carrier fault"
 // rather than "serious reasons".
 export { RETURN_REASON, FINAL_SALE_EXEMPT_REASONS, RETURN_REASON_LABEL, RETURN_REASON_GROUP_LABEL, isFinalSaleExempt, isReturnReason, selectableReturnReasons, } from "./_internal/shared/features/orders/return-reasons.js";
+/*
+ * The integration switches, SERVER side — this is the half the route guards
+ * use. `readIntegrationStates` is the one expression that answers "is this
+ * integration on", and both the admin page (via `client.ts`) and every guard
+ * resolve through it so they cannot disagree.
+ *
+ * `IntegrationDescriptor.failClosed` is what a guard reads to decide which way
+ * to fail when the settings read itself throws. It differs per integration on
+ * purpose: closed for money, open for support.
+ */
+export { INTEGRATIONS, INTEGRATION_ORDER, readIntegrationStates, integrationPatch, allIntegrationsPatch, } from "./_internal/shared/features/admin/integrations.js";
 // Seller listing form draft <-> product write payload. The flat form keys and
 // the nested document blocks are different shapes, and nothing translated
 // between them — see the module docstring.
@@ -1638,3 +1650,173 @@ export { GRIEVANCE_PERIODS } from "./features/support/schemas/firestore.js";
  * obligation early opens the payout gate early as a consequence.
  */
 export { getRateableItemsAction, rateOrderItemAction, markOrderCompleteAction, } from "./_internal/server/features/order-completion/index.js";
+/*
+ * [SERVER-ONLY] Phase 7 invoicing (D12) — the two gapless FY series.
+ *
+ * Exported here because `_internal/*` is NOT a published subpath (appkit has 46
+ * export keys and none of them is `./_internal/*`), so a consumer route cannot
+ * deep-import these. That is the same wall `cancelOrderWithRefund` and
+ * `adjustUserPoints` hit; `server.ts` is the sanctioned door.
+ *
+ * 🛑 `allocateSeriesNumber` is exported deliberately and should be reached for
+ * rarely: it CONSUMES a number from a gapless series, and a number cannot be
+ * withdrawn without leaving a gap an auditor will ask about. The two callers
+ * that should exist are the paid-transition trigger and the refund settle path,
+ * both already wired. A backfill is the only other legitimate use.
+ */
+export { allocateSeriesNumber, } from "./_internal/server/features/invoicing/allocate.js";
+export { issueInvoiceForOrder, readStoredInvoice, storeRenderedInvoice, INVOICE_PREFIX_PATH, } from "./_internal/server/features/invoicing/issue.js";
+export { issueCreditNoteForRefund, CREDIT_NOTE_PREFIX_PATH, } from "./_internal/server/features/invoicing/credit-note.js";
+export { financialYearLabel, formatSeriesNumber, INVOICE_PREFIX, CREDIT_NOTE_PREFIX, } from "./features/invoicing/utils/financial-year.js";
+export { buildGstr1Export, gstr1ToCsv, } from "./_internal/server/features/invoicing/gstr1.js";
+/*
+ * [SERVER-ONLY] S5a shared purchase — one payer, N destinations.
+ *
+ * Exported for the capture route, which is the FOURTH money path and the one
+ * D37 proves gets left behind. Pure arithmetic with no Firestore and no
+ * settings read; the rates are passed in snapshotted.
+ */
+export { quoteSharedPurchase, countDestinations, } from "./_internal/shared/features/shipping/shared-purchase.js";
+/*
+ * [SERVER-ONLY] The pricing registry and its one write path.
+ *
+ * 🛑 The REGISTRY is pure data with no Firestore and no `node:` import, so it
+ * could sit in the main barrel — and deliberately does not. Its only consumer
+ * outside appkit is `/api/admin/pricing`, and putting it in `index.ts` would
+ * add sixteen descriptors and four symbols to every client bundle that imports
+ * anything at all, to serve one route (Root Cause #18 — a re-export is a
+ * public API contract, not a convenience).
+ *
+ * `applyRateChange` belongs here regardless: it reaches firebase-admin.
+ */
+export { RATE_REGISTRY, RATE_TIER_ORDER, rateByPath, canEditRate, rejectRateChange, } from "./_internal/shared/features/pricing/rate-registry.js";
+export { applyRateChange, RATE_CHANGE_LOG_MAX, } from "./_internal/server/features/pricing/actions.js";
+/*
+ * [SERVER-ONLY] Coordinated purchase — a SPECIALISED OFFER, not a new flow.
+ *
+ * `assertOwnedAddresses` is the one piece that must run server-side: a
+ * destination is a REFERENCE, and an id is guessable in a way an address is
+ * not, so an unverified one ships a parcel to a stranger's house with nothing
+ * erroring. The shared half (the member shape, the member-count rule) is pure
+ * and could sit in the main barrel — it stays here beside its checker so a
+ * caller cannot reach for one without meeting the other.
+ */
+export { SHARED_PURCHASE_MAX_MEMBERS, rejectCoordination, destinationIds, } from "./_internal/shared/features/offers/coordination.js";
+export { assertOwnedAddresses } from "./_internal/server/features/offers/destinations.js";
+/*
+ * S5a — N destinations is N parcels, so N carrier quotes.
+ *
+ * 🛑 `checkDestinations` + `assertAllServiceable` are a PRE-FLIGHT and are
+ * exported as a pair for that reason: booking as you go and failing on the
+ * fourth leaves three parcels the carrier has already accepted and the
+ * coordinator cannot undo. It is not a transaction — a booking has no
+ * rollback — it just moves the common failure to the point where rolling
+ * back is still free.
+ */
+export { checkDestinations, assertAllServiceable, planParcels, } from "./_internal/server/features/shipping/book-split.js";
+/*
+ * [SERVER-ONLY] Part 14 — the delivery snapshot and its corrections.
+ *
+ * `amendDeliveryAddress` is server-only (Firestore + the addresses
+ * repository). The pure readers ship with it rather than from the main
+ * barrel so a caller cannot reach `deliveryPartyFor` without the module that
+ * explains why it reads the amendment while `placeOfSupplyFrom` reads the
+ * snapshot — getting those two the wrong way round sends a parcel to the old
+ * address, or restates tax on a filed invoice.
+ */
+export { snapshotDeliveryAddress, deliveryPartyFor, placeOfSupplyFrom, } from "./_internal/shared/features/orders/delivery-snapshot.js";
+export { amendDeliveryAddress, revealAmendments, DELIVERY_AMENDMENT_MAX, } from "./_internal/server/features/orders/amend-delivery.js";
+/*
+ * [SERVER-ONLY] Part 1′ — parcel booking.
+ *
+ * 🛑 Exported for the ENQUEUE route only. The booking itself runs in the
+ * `bookShipment` job runner, because a carrier call on a 10s sync ceiling
+ * times out in the one way that cannot be retried safely: the carrier may
+ * have accepted, so a retry double-books and a non-retry leaves a parcel
+ * nobody collects.
+ */
+export { bookShipment, } from "./_internal/server/features/shipping/book.js";
+/*
+ * [SERVER-ONLY] Part 4 — the double-entry books.
+ *
+ * 🛑 The repository is server-only (Firestore), and the posting rules ship
+ * beside it rather than from the main barrel even though they are pure: a
+ * caller who can reach `assertBalanced` without reaching `journalRepository`
+ * can compute a balanced entry and write it some other way, which is exactly
+ * the "every entry is machine-generated through one path" constraint the
+ * whole design rests on. Same stance `assertOwnedAddresses` takes.
+ *
+ * 🛑 The LEDGER IS A PROJECTION. Orders, payouts and expenses are truth —
+ * never read a balance to make an operational decision.
+ */
+export { journalRepository, JournalRepository, JOURNAL_PERIOD_SCAN_LIMIT } from "./features/ledger/repository/journal.repository.js";
+export { assertBalanced, buildReversal, resolvePostingPeriod, periodOf, UnbalancedEntryError, BALANCE_TOLERANCE, } from "./_internal/shared/features/ledger/posting.js";
+export { trialBalance, profitAndLoss, signedBalance, } from "./_internal/shared/features/ledger/reports.js";
+/*
+ * The per-event posting rules. These are WHERE the "every entry is
+ * machine-generated" constraint lives — a caller posts an order by handing
+ * `orderPlacedPosting(order)` to `journalRepository.post`, never by writing
+ * legs. A backwards entry balances, so nothing downstream would object;
+ * `verify-posting-rules` R7 checks the SIDES, with controls proving it
+ * catches a credited bank, an un-reclaimed refund GST and an inverted
+ * output-GST liability.
+ */
+export { ACCOUNT, orderPlacedPosting, settlementPosting, payoutPosting, refundPosting, expensePosting, } from "./_internal/shared/features/ledger/rules.js";
+/*
+ * Vendors and expenses. `ShipmentDocument.supplierId` joins to a vendor row;
+ * `supplierName` stays as typed, because deriving the name on read would let
+ * a vendor rename rewrite what every past shipment says it was bought from.
+ */
+export { VENDORS_COLLECTION, EXPENSES_COLLECTION, EXPENSE_FIELDS, } from "./features/ledger/schemas/expenses.js";
+/*
+ * [SERVER-ONLY] D55 — the pre-order balance collector.
+ *
+ * `balanceDue` has been computed and rendered since Part 2 with nothing to
+ * collect it. These three are the whole collection path: the seller opens it
+ * when stock lands, the buyer submits a proof, staff review it. Manual only —
+ * the auto path is blocked on RBI mandate requirements, not on effort.
+ */
+export { BALANCE_WINDOW_DAYS, balanceDueOn, openBalanceCollection, submitBalanceProof, reviewBalanceProof, } from "./_internal/server/features/orders/balance.js";
+/*
+ * [SERVER-ONLY] Stock reservation with a TTL.
+ *
+ * A hold on units that is NOT an order. The only mechanism before this was
+ * `onOrderCreate`'s decrement plus `pendingOrderTimeout`'s 15-minute restore,
+ * both keyed to an order — which cannot serve a multi-day shared purchase
+ * without either starting a payment clock on day one or letting an ordinary
+ * buyer take the item out from under the arrangement.
+ *
+ * 🛑 Every one of these moves the reservation row and `availableQuantity`
+ * inside ONE transaction. A caller that writes either half itself has
+ * reintroduced exactly the drift this primitive exists to remove.
+ */
+export { reserveStock, releaseReservation, releaseReservationsForHolder, consumeReservation, expireDueReservations, activeReservationsForProduct, } from "./_internal/server/features/inventory/reservations.js";
+export { RESERVATION_DEFAULT_TTL_HOURS, RESERVATION_MAX_TTL_HOURS, RESERVATION_HOLDER_KINDS, RESERVATION_STATUSES, STOCK_RESERVATION_COLLECTION, isReservationActive, } from "./features/inventory/schemas/stock-reservation.js";
+/*
+ * [SERVER-ONLY] The high-value checkout OTP gate.
+ *
+ * 🛑 It takes the AMOUNT it judges. There were two hand-rolled copies of
+ * this rule — `createOrderForGroup` summing the cart, the gateway route
+ * using its own `subtotalRs` — which is Root Cause #75's shape, and they
+ * had already drifted on what they measured.
+ *
+ * Taking the amount is also Part 6's prerequisite: `otpCheckoutThreshold`
+ * is per CHECKOUT, so an N-party arrangement clears ₹12,000 in three
+ * ₹4,000 pieces with no OTP unless it can present its own total.
+ */
+export { assertCheckoutValueOtp } from "./_internal/server/features/checkout/value-otp-gate.js";
+/*
+ * [SERVER-ONLY] D56 — self-serve ad bookings.
+ *
+ * 🛑 Availability is a DOCUMENT COLLISION, never a query. The booking id
+ * is `${placementId}__${period}` and creation uses `tx.create`, so a second
+ * booking of the same slot fails on an existing document inside its own
+ * transaction. Query-then-write would let two concurrent requests both read
+ * "free" and sell the slot twice, with nothing erroring.
+ *
+ * 🛑 Flat fee per period, explicitly NOT CPM — impression counting is a
+ * write per page view, which is the cost pattern that suspended this
+ * project (Root Cause #104).
+ */
+export { bookAdSlot, moderateAdCreative, resubmitAdCreative, cancelAdBooking, releaseAdSlot, liveBookingForPlacement, pendingAdBookings, adBookingsForAdvertiser, adSlotOffers, } from "./_internal/server/features/ads/booking.js";
+export { AD_BOOKING_COLLECTION, AD_BOOKING_PAYMENT_STATES, AD_MODERATION_STATES, adBookingId, adPeriodOf, adPeriodStart, adPeriodEnd, isAdPeriod, isAdBookingLive, } from "./features/ads/schemas/firestore.js";