@mohasinac/appkit 4.21.0 → 4.23.0

package/dist/features/support/repository/support.repository.d.ts

@@ -1,6 +1,14 @@
 import { BaseRepository } from "../../../providers/db-firebase";
 import type { FirebaseSieveFields, FirebaseSieveResult, SieveModel } from "../../../providers/db-firebase";
 import { type SupportTicketDocument, type SupportTicketCreateInput, type SupportTicketUpdateInput, type TicketMessage, type TicketStatus } from "../schemas/firestore";
+import { type HistoryActor } from "../../../_internal/shared/history/index";
+/** Who/why for a write that lands in `statusHistory`. */
+export interface TicketWriteContext {
+    actor?: HistoryActor;
+    trigger?: string;
+    reason?: string;
+    note?: string;
+}
 export declare class SupportRepository extends BaseRepository<SupportTicketDocument> {
     static readonly SIEVE_FIELDS: FirebaseSieveFields;
     constructor();
@@ -10,9 +18,45 @@ export declare class SupportRepository extends BaseRepository<SupportTicketDocum
     countActiveTickets(userId: string): Promise<number>;
     getActiveOrderTicket(userId: string, orderId: string): Promise<SupportTicketDocument | null>;
     getActiveCategoryTicket(userId: string, category: string): Promise<SupportTicketDocument | null>;
-    updateTicketStatus(ticketId: string, update: SupportTicketUpdateInput): Promise<SupportTicketDocument>;
-    addMessage(ticketId: string, message: TicketMessage, newStatus?: TicketStatus): Promise<void>;
-    assignTicket(ticketId: string, assignedTo: string, assignedToName: string): Promise<SupportTicketDocument>;
+    /**
+     * The single status/assignment write path.
+     *
+     * `prior` is not an optimisation detail — the caller that matters (the admin
+     * PATCH route) already fetches the ticket to 404 on a missing one, so
+     * threading it through means history costs ZERO extra Firestore reads
+     * (Rule #6). Omit it and this falls back to a read, which is correct but
+     * avoidable.
+     */
+    updateTicketStatus(ticketId: string, update: SupportTicketUpdateInput, ctx?: TicketWriteContext, prior?: SupportTicketDocument | null): Promise<SupportTicketDocument>;
+    /**
+     * Stamp `resolvedAt` / `closedAt` on the transition INTO that status.
+     *
+     * Both fields were declared, constant-named and listed in the update input,
+     * and no code path had ever written either (verified 2026-08-26) — so every
+     * resolved ticket in the collection has no resolution time.
+     *
+     * Guarded on the transition, not on the status: re-saving a priority change
+     * on an already-resolved ticket must not move its resolution time forward.
+     * Never fabricated for a ticket resolved before this existed — that one
+     * renders an em-dash, the same rule the offer timeline follows.
+     */
+    private resolutionStamps;
+    /** Append a timeline entry when the patch touches a tracked field. */
+    private withTicketHistory;
+    /**
+     * Append a reply, optionally moving the ticket's status.
+     *
+     * The message itself is NOT history — the thread is already the record of
+     * what was said. Only an accompanying status change earns an entry, and
+     * only then is a read taken, so an ordinary reply still costs one write and
+     * no read.
+     *
+     * `messages` stays an `arrayUnion` (concurrent replies must not clobber one
+     * another); `statusHistory` cannot, because `arrayUnion` has no way to
+     * enforce the FIFO cap — so it is folded in memory and written whole.
+     */
+    addMessage(ticketId: string, message: TicketMessage, newStatus?: TicketStatus, ctx?: TicketWriteContext, prior?: SupportTicketDocument | null): Promise<void>;
+    assignTicket(ticketId: string, assignedTo: string, assignedToName: string, ctx?: TicketWriteContext, prior?: SupportTicketDocument | null): Promise<SupportTicketDocument>;
     listAll(model: SieveModel): Promise<FirebaseSieveResult<SupportTicketDocument>>;
 }
 export declare const supportRepository: SupportRepository;

package/dist/features/support/repository/support.repository.js

@@ -3,7 +3,8 @@ import { BaseRepository, prepareForFirestore, parseSieveDateValue, } from "../..
 import { normalizeError } from "../../../errors/normalize";
 import { DatabaseError } from "../../../errors";
 import { SUPPORT_TICKET_FIELDS } from "../../../constants/field-names";
-import { SUPPORT_TICKET_COLLECTION, ACTIVE_TICKET_STATUSES, } from "../schemas/firestore";
+import { SUPPORT_TICKET_COLLECTION, SUPPORT_TICKET_PII_FIELDS, SUPPORT_TICKET_TRACKED_FIELDS, TicketStatusValues, ACTIVE_TICKET_STATUSES, } from "../schemas/firestore";
+import { withHistory } from "../../../_internal/shared/history/index";
 export class SupportRepository extends BaseRepository {
     constructor() {
         super(SUPPORT_TICKET_COLLECTION);
@@ -73,13 +74,73 @@ export class SupportRepository extends BaseRepository {
         const doc = snap.docs[0];
         return { id: doc.id, ...doc.data() };
     }
-    async updateTicketStatus(ticketId, update) {
-        return this.update(ticketId, {
+    /**
+     * The single status/assignment write path.
+     *
+     * `prior` is not an optimisation detail — the caller that matters (the admin
+     * PATCH route) already fetches the ticket to 404 on a missing one, so
+     * threading it through means history costs ZERO extra Firestore reads
+     * (Rule #6). Omit it and this falls back to a read, which is correct but
+     * avoidable.
+     */
+    async updateTicketStatus(ticketId, update, ctx, prior) {
+        const current = prior !== undefined ? prior : await this.getTicketById(ticketId);
+        const patch = {
             ...update,
+            ...this.resolutionStamps(current, update.status),
             updatedAt: new Date(),
+        };
+        return this.update(ticketId, this.withTicketHistory(current, patch, ctx, "updateTicketStatus"));
+    }
+    /**
+     * Stamp `resolvedAt` / `closedAt` on the transition INTO that status.
+     *
+     * Both fields were declared, constant-named and listed in the update input,
+     * and no code path had ever written either (verified 2026-08-26) — so every
+     * resolved ticket in the collection has no resolution time.
+     *
+     * Guarded on the transition, not on the status: re-saving a priority change
+     * on an already-resolved ticket must not move its resolution time forward.
+     * Never fabricated for a ticket resolved before this existed — that one
+     * renders an em-dash, the same rule the offer timeline follows.
+     */
+    resolutionStamps(current, next) {
+        if (!next || next === current?.status)
+            return {};
+        const now = new Date();
+        if (next === TicketStatusValues.RESOLVED && !current?.resolvedAt)
+            return { resolvedAt: now };
+        if (next === TicketStatusValues.CLOSED && !current?.closedAt)
+            return { closedAt: now };
+        return {};
+    }
+    /** Append a timeline entry when the patch touches a tracked field. */
+    withTicketHistory(current, patch, ctx, defaultTrigger) {
+        const withEntry = withHistory(current, patch, {
+            tracked: SUPPORT_TICKET_TRACKED_FIELDS,
+            actor: ctx?.actor ?? { role: "system" },
+            trigger: ctx?.trigger ?? defaultTrigger,
+            reason: ctx?.reason,
+            note: ctx?.note,
+            // `encryptPiiFields` never descends into arrays, so a PII-named value
+            // reaching `changes` would persist in PLAINTEXT inside statusHistory.
+            piiFields: SUPPORT_TICKET_PII_FIELDS,
         });
+        return withEntry ?? patch;
     }
-    async addMessage(ticketId, message, newStatus) {
+    /**
+     * Append a reply, optionally moving the ticket's status.
+     *
+     * The message itself is NOT history — the thread is already the record of
+     * what was said. Only an accompanying status change earns an entry, and
+     * only then is a read taken, so an ordinary reply still costs one write and
+     * no read.
+     *
+     * `messages` stays an `arrayUnion` (concurrent replies must not clobber one
+     * another); `statusHistory` cannot, because `arrayUnion` has no way to
+     * enforce the FIFO cap — so it is folded in memory and written whole.
+     */
+    async addMessage(ticketId, message, newStatus, ctx, prior) {
         try {
             const ref = this.db
                 .collection(SUPPORT_TICKET_COLLECTION)
@@ -88,8 +149,10 @@ export class SupportRepository extends BaseRepository {
                 messages: firebaseFieldOps.arrayUnion(prepareForFirestore(message)),
                 updatedAt: new Date(),
             };
-            if (newStatus)
-                updateData.status = newStatus;
+            if (newStatus) {
+                const current = prior !== undefined ? prior : await this.getTicketById(ticketId);
+                Object.assign(updateData, this.withTicketHistory(current, { status: newStatus, ...this.resolutionStamps(current, newStatus) }, ctx, "addMessage"));
+            }
             await ref.update(updateData);
         }
         catch (err) {
@@ -97,12 +160,9 @@ export class SupportRepository extends BaseRepository {
             throw new DatabaseError("Failed to add message to ticket", err);
         }
     }
-    async assignTicket(ticketId, assignedTo, assignedToName) {
-        return this.update(ticketId, {
-            assignedTo,
-            assignedToName,
-            updatedAt: new Date(),
-        });
+    async assignTicket(ticketId, assignedTo, assignedToName, ctx, prior) {
+        const current = prior !== undefined ? prior : await this.getTicketById(ticketId);
+        return this.update(ticketId, this.withTicketHistory(current, { assignedTo, assignedToName, updatedAt: new Date() }, ctx, "assignTicket"));
     }
     async listAll(model) {
         return this.sieveQuery(model, SupportRepository.SIEVE_FIELDS, { defaultPageSize: 25, maxPageSize: 100 });

package/dist/features/support/schemas/firestore.d.ts

@@ -15,6 +15,7 @@
  *  - No new ticket in the same category while existing one is waiting_on_user
  */
 import type { BaseDocument } from "../../../_internal/shared/types/base-document";
+import type { StatusChangeEntry } from "../../../_internal/shared/history/types";
 export declare const TicketCategoryValues: {
     readonly ORDER_ISSUE: "order_issue";
     readonly BILLING_PAYMENT: "billing_payment";
@@ -101,11 +102,47 @@ export interface SupportTicketDocument extends BaseDocument {
     internalNotes?: string;
     /** Threaded conversation. Ordered by createdAt asc. */
     messages: TicketMessage[];
+    /**
+     * Stamped by the repository the first time `status` becomes `resolved` /
+     * `closed`. Both were declared, given `SUPPORT_TICKET_FIELDS` constants and
+     * listed in `SupportTicketUpdateInput` — and **nothing ever wrote either**
+     * (verified 2026-08-26), so no resolved ticket in the collection carries a
+     * resolution time and "how long do tickets take" has never been answerable.
+     *
+     * Server-stamped, never client-sent: the same discipline the reports route
+     * adopted after a client-sent `resolvedAt` arrived as a JSON string into a
+     * `Date` field and split the collection into two shapes.
+     */
     resolvedAt?: Date;
     closedAt?: Date;
+    /**
+     * Who changed what, when, and why. See § "Status History" in CLAUDE.md.
+     * Append-only, capped at STATUS_HISTORY_MAX, oldest evicted first.
+     */
+    statusHistory?: StatusChangeEntry[];
+    /** How many entries fell off the front. Never imply "this is all of it". */
+    statusHistoryTruncated?: number;
 }
+/**
+ * The fields whose changes earn a timeline entry.
+ *
+ * Explicit, not a whole-document diff: a diff would record the `updatedAt`
+ * bump on every write and exhaust the 50-entry cap within days. `messages` is
+ * excluded on purpose — the thread is already the conversation, and mirroring
+ * every reply into history would bury the handful of transitions anyone reads.
+ */
+export declare const SUPPORT_TICKET_TRACKED_FIELDS: readonly ["status", "priority", "assignedTo", "resolvedAt", "closedAt"];
+/**
+ * PII on this document, for `withHistory`'s scrub.
+ *
+ * `assignedToName` is a staff display name denormalised for the admin table —
+ * not the ticket author's identity — but it is still a person's name reaching
+ * an array `encryptPiiFields` cannot descend into, so history carries the UID
+ * (`assignedTo`) and never the name.
+ */
+export declare const SUPPORT_TICKET_PII_FIELDS: readonly ["userEmail", "userDisplayName", "assignedToName"];
 export type SupportTicketCreateInput = Pick<SupportTicketDocument, "userId" | "userEmail" | "userDisplayName" | "category" | "subject" | "description" | "orderId">;
-export type SupportTicketUpdateInput = Partial<Pick<SupportTicketDocument, "status" | "priority" | "assignedTo" | "assignedToName" | "internalNotes" | "resolvedAt" | "closedAt" | "relatedParties">>;
+export type SupportTicketUpdateInput = Partial<Pick<SupportTicketDocument, "status" | "priority" | "assignedTo" | "assignedToName" | "internalNotes" | "relatedParties">>;
 export declare const SUPPORT_TICKET_COLLECTION: "supportTickets";
 export declare const SUPPORT_TICKET_ID_PREFIX: "ticket-";
 export declare const SUPPORT_TICKET_INDEXED_FIELDS: readonly ["userId", "status", "category", "priority", "assignedTo", "orderId", "createdAt", "updatedAt"];

package/dist/features/support/schemas/firestore.js

@@ -63,6 +63,40 @@ export const ELIGIBLE_ORDER_STATUSES_FOR_TICKET = [
     "SHIPPED",
     "RETURN_REQUESTED",
 ];
+/**
+ * The fields whose changes earn a timeline entry.
+ *
+ * Explicit, not a whole-document diff: a diff would record the `updatedAt`
+ * bump on every write and exhaust the 50-entry cap within days. `messages` is
+ * excluded on purpose — the thread is already the conversation, and mirroring
+ * every reply into history would bury the handful of transitions anyone reads.
+ */
+export const SUPPORT_TICKET_TRACKED_FIELDS = [
+    "status",
+    "priority",
+    "assignedTo",
+    "resolvedAt",
+    "closedAt",
+];
+/**
+ * PII on this document, for `withHistory`'s scrub.
+ *
+ * `assignedToName` is a staff display name denormalised for the admin table —
+ * not the ticket author's identity — but it is still a person's name reaching
+ * an array `encryptPiiFields` cannot descend into, so history carries the UID
+ * (`assignedTo`) and never the name.
+ */
+export const SUPPORT_TICKET_PII_FIELDS = [
+    "userEmail",
+    "userDisplayName",
+    "assignedToName",
+];
+/*
+ * `resolvedAt` / `closedAt` are deliberately NOT in the update input. They are
+ * events, and the server is the only thing that knows when one happened —
+ * letting a client send them is how the reports collection ended up holding
+ * both Timestamps and ISO strings in one field.
+ */
 // ============================================================================
 // COLLECTION CONSTANTS
 // ============================================================================

package/dist/features/support/schemas/index.d.ts

@@ -182,6 +182,7 @@ export declare const supportTicketFirestoreSchema: z.ZodObject<{
     closedAt?: string | Date | z.objectOutputType<{
         toDate: z.ZodFunction<z.ZodTuple<[], z.ZodUnknown>, z.ZodDate>;
     }, z.ZodTypeAny, "passthrough"> | undefined;
+    assignedToName?: string | undefined;
     relatedParties?: {
         storeId?: string | undefined;
         userId?: string | undefined;
@@ -189,7 +190,6 @@ export declare const supportTicketFirestoreSchema: z.ZodObject<{
         productId?: string | undefined;
         bidId?: string | undefined;
     } | undefined;
-    assignedToName?: string | undefined;
     internalNotes?: string | undefined;
 }, {
     status: "closed" | "open" | "resolved" | "in_progress" | "waiting_on_user";
@@ -225,6 +225,7 @@ export declare const supportTicketFirestoreSchema: z.ZodObject<{
     closedAt?: string | Date | z.objectInputType<{
         toDate: z.ZodFunction<z.ZodTuple<[], z.ZodUnknown>, z.ZodDate>;
     }, z.ZodTypeAny, "passthrough"> | undefined;
+    assignedToName?: string | undefined;
     relatedParties?: {
         storeId?: string | undefined;
         userId?: string | undefined;
@@ -232,7 +233,6 @@ export declare const supportTicketFirestoreSchema: z.ZodObject<{
         productId?: string | undefined;
         bidId?: string | undefined;
     } | undefined;
-    assignedToName?: string | undefined;
     internalNotes?: string | undefined;
 }>;
 export type SupportTicketFromSchema = z.infer<typeof supportTicketFirestoreSchema>;

package/dist/features/tester/seed-data/tester-checklist-seed-data.js

@@ -1156,6 +1156,96 @@ const rawTesterChecklistItems = [
                     description: "The fix had to cover the update path as well as create — a create-only fix would mean the listing saved correctly and then lost its per-type block the first time anyone edited anything else (Root Cause #39).",
                     href: "/store/classified",
                 },
+                {
+                    key: "ticket-resolution-timestamp-stamped",
+                    label: "Resolving a support ticket records WHEN it was resolved",
+                    description: "`resolvedAt` and `closedAt` were declared on the document, had field-name constants, were listed in the update input — and nothing had ever written either (verified 2026-08-26), so no resolved ticket carried a resolution time. Move a ticket to Resolved, reopen it, and confirm the timeline shows a real date on that step. Re-save an unrelated field afterwards: the resolution time must NOT move forward.",
+                    href: "/admin/support-tickets",
+                },
+                {
+                    key: "payout-utr-actually-saves",
+                    label: "The UTR entered when marking a payout paid is still there on reload",
+                    description: "The mark-paid modal REQUIRES a transaction reference, the route declared it, its own test asserted it reached the action — and the action picked only status/adminNote/processedAt, so the UTR was dropped while the 200 echoed it back as if stored. Mark a payout paid with a reference, reload the payout, and confirm 'Transaction ref' shows it.",
+                    href: "/admin/payouts",
+                },
+                {
+                    key: "store-approval-makes-it-public",
+                    label: "Approving a pending store actually makes it visible on /stores",
+                    description: "`status` and `isPublic` are two distinct fields and public visibility gates on `isPublic`. The admin PATCH wrote `status` directly and never touched `isPublic`, so an approved store was active AND invisible with no error anywhere. Approve `store-blader-bazaar`, then open /stores and confirm it appears.",
+                    href: "/admin/stores",
+                },
+                {
+                    key: "store-timeline-shows-who-suspended",
+                    label: "A suspended store's page shows who suspended it, when, and why",
+                    description: "Previously recoverable only from /admin/audit-log, which a store owner can never see. Suspend a store with a reason, open its admin detail page, and confirm the History block names the admin, the time, and the reason.",
+                    href: "/admin/stores",
+                },
+                {
+                    key: "payout-failure-reasons-survive-retries",
+                    label: "A payout that failed twice shows BOTH reasons, not just the last",
+                    description: "`lastFailureReason` is overwritten by every retry, so the timeline is the only place earlier attempts survive. Also confirm the four dispatch fields (razorpayPayoutId, razorpayStatus, failureCount, lastFailureReason) render — they were written by the batch and UNDECLARED on the document until 2026-08-26, so nothing could safely surface them.",
+                    href: "/admin/payouts",
+                },
+                {
+                    key: "bid-timeline-explains-forfeited",
+                    label: "A forfeited bid says why it was forfeited",
+                    description: "Open a forfeited bid from /admin/bids. The History block must read 'Forfeited' with the system actor and the reason 'The 48-hour checkout window closed without payment.' A bid moves through more states than any record a buyer owns and every one of them happened inside a settlement batch with nothing recording it.",
+                    href: "/admin/bids",
+                },
+                {
+                    key: "catalogue-rejection-reason-survives",
+                    label: "A catalogue item rejected twice keeps both reasons",
+                    description: "`rejectionReason` holds only the last decision. Reject a submission, have the owner resubmit, reject again with a different reason — the approval modal's History block must show both, each with its own date.",
+                    href: "/admin/catalogue-approvals",
+                },
+                {
+                    key: "history-absent-renders-empty-not-invented",
+                    label: "A record created BEFORE history existed shows 'no recorded history', not a made-up date",
+                    description: "Never fabricate a timestamp. Open any store, payout or ticket that predates this feature: the History block must say there is none, NOT derive a step from `updatedAt` — 'last write of any kind' is not an event, and a made-up date makes the record lie.",
+                    href: "/admin/stores",
+                },
+                {
+                    key: "history-carries-no-pii",
+                    label: "No name or email appears anywhere in a record's History block",
+                    description: "`encryptPiiFields` is a flat top-level loop that never descends into arrays, so a PII value inside statusHistory would be stored in PLAINTEXT. Every entry shows a ROLE (Admin/System/Buyer/Store) and never a name. Check a payout (sellerEmail/upiId), a bid (userName/userEmail) and a scammer profile (built entirely of identifying details).",
+                    href: "/admin/payouts",
+                },
+                {
+                    key: "form-errors-wait-for-first-submit",
+                    label: "Opening the address form shows NO errors until you press Save",
+                    description: "Live bug fixed 2026-08-26: every schema-driven form greeted the user with a list of its own requirements as errors before they had typed anything. Two causes compounded — <FormErrorSummary> was deliberately un-gated, and ~20 views run validate(draft) in a mount effect, so an untouched empty draft failed every .min(1) on first paint. Open /user/addresses/new: the summary block must be absent. Press Save with the form empty: NOW it lists the missing fields.",
+                    href: "/user/addresses/new",
+                },
+                {
+                    key: "form-errors-stay-live-after-first-submit",
+                    label: "After a failed Save, the error list SHRINKS as you fill fields in",
+                    description: "The fix gates the DISPLAY, not the computation — the live validation underneath is what makes the list useful. Press Save on an empty address form, then fill Full name. The summary must drop that entry immediately, without a second Save. If the list is frozen, the on-mount validate() was removed instead of gated, which is the wrong fix.",
+                    href: "/user/addresses/new",
+                },
+                {
+                    key: "form-mobile-bar-pinned",
+                    label: "On a phone, Save and Cancel are pinned above the tab bar on the address form",
+                    description: "Added 2026-08-26 (W21). Narrow the window below 1024px, or use a real phone. Save/Cancel should sit in the same fixed bar the cart uses for 'Proceed to checkout' — above the bottom tab bar, not scrolled off the end of a long form. On desktop the bar is hidden and the inline Save/Cancel row at the bottom of the form is the control.",
+                    href: "/user/addresses/new",
+                },
+                {
+                    key: "form-mobile-error-sheet",
+                    label: "On a phone, a failed Save opens a 'Fix N issues' sheet you can tap through",
+                    description: "Below 1024px, press Save on an empty address form. A 'Fix 6 issues' row must appear above the buttons with the list already open. Collapse it, press Save again — it must RE-open (the count is a counter, not a boolean, precisely so a second attempt is a new event). Tapping an entry on a sectioned form jumps to that field.",
+                    href: "/user/addresses/new",
+                },
+                {
+                    key: "form-bar-restores-listing-bulk-bar",
+                    label: "Closing a form drawer over a listing brings the listing's bulk bar back",
+                    description: "Regression test for the singleton clobber: there is ONE bottom bar per route and DataListingView claims it on ~70 admin screens. Select a few rows on an admin listing so the bulk bar appears, open a row's editor drawer, then close it — the bulk bar must still be there with the selection intact. Before the claim stack landed, the drawer overwrote it and blanked it on close.",
+                    href: "/admin/products",
+                },
+                {
+                    key: "form-bar-absent-inside-a-modal",
+                    label: "A form inside a modal or drawer does NOT get a second bar at the bottom of the screen",
+                    description: "An overlay owns its own footer, and a viewport-fixed bar would render behind the backdrop, below the dialog it belongs to. Open any drawer-based editor on a phone-width window and confirm the only Save/Cancel controls are the ones inside the drawer.",
+                    href: "/admin/coupons",
+                },
                 {
                     key: "address-routes-normalised",
                     label: "Adding and editing an address works, and the OLD urls still resolve",

package/dist/index.d.ts

@@ -2120,6 +2120,10 @@ export { SidebarLayout } from "./features/layout/index";
 export { TitleBar } from "./features/layout/index";
 export { TitleBarLayout } from "./features/layout/index";
 export { useBottomActions } from "./features/layout/index";
+export { RecordStatusTimeline } from "./features/status-history/index";
+export { useFormBottomActions } from "./features/layout/index";
+export { FormErrorList } from "./ui/forms";
+export { OverlayContext, useIsInsideOverlay } from "./ui/components/overlay-context";
 export { useBottomActionsContext } from "./features/layout/index";
 export { useDashboardNav } from "./features/layout/index";
 export type { AppLayoutShellProps } from "./features/layout/index";
@@ -3233,7 +3237,7 @@ export { getListingRule, getCategoryRule, pickOrderType, getSplitKey, runSyncPre
 export type { ListingCheckoutRule, CategoryCheckoutRule, CartItemProductPair, OrderItemInput, RefundPolicy, } from "./_internal/shared/checkout/rules";
 export { MEGABYTE, MAX_IMAGE_BYTES, MAX_PDF_BYTES, MAX_VIDEO_BYTES, MAX_LABEL, MAX_BYTES, ALLOWED_IMAGE_MIMES, ALLOWED_VIDEO_MIMES, ALLOWED_DOC_MIMES, ALLOWED_MIMES, ALLOWED_TYPES_LABEL, MIME_TO_EXT, PDF_MAGIC, VIDEO_CONVERSION_HINTS, classifyMime, isAllowedMime, maxBytesFor, getConversionHint, } from "./_internal/shared/media/limits";
 export type { MediaKind, AllowedImageMime, AllowedVideoMime, AllowedDocMime, AllowedMime, } from "./_internal/shared/media/limits";
-export { PRODUCT_FIELDS, PRODUCT_STATUS_TRANSITIONS, ORDER_FIELDS, REVIEW_FIELDS, BID_FIELDS, AD_FIELDS, BLOG_FIELDS, BRAND_FIELDS, WISHLIST_FIELDS, HISTORY_FIELDS, COUPON_USAGE_FIELDS, CONVERSATION_FIELDS, CAROUSEL_FIELDS, FAQ_FIELDS, HOMEPAGE_SECTION_FIELDS, SITE_SETTINGS_FIELDS, COMMON_FIELDS, OAUTH_STATE_VALUES, SCHEMA_DEFAULTS, } from "./constants/field-names";
+export { PRODUCT_FIELDS, PRODUCT_STATUS_TRANSITIONS, ORDER_FIELDS, REVIEW_FIELDS, BID_FIELDS, AD_FIELDS, AD_TRACKED_FIELDS, BLOG_FIELDS, BRAND_FIELDS, WISHLIST_FIELDS, HISTORY_FIELDS, COUPON_USAGE_FIELDS, CONVERSATION_FIELDS, CAROUSEL_FIELDS, FAQ_FIELDS, HOMEPAGE_SECTION_FIELDS, SITE_SETTINGS_FIELDS, COMMON_FIELDS, OAUTH_STATE_VALUES, SCHEMA_DEFAULTS, } from "./constants/field-names";
 export { SORT_DIR, sortBy } from "./constants/sort";
 export type { SortDirection } from "./constants/sort";
 export { TABLE_KEYS, VIEW_MODE } from "./constants/table-keys";
@@ -3294,3 +3298,5 @@ export { adminUserUpdateSchema, whatsappSettingsSchema, lotteryPullSchema, } fro
 export { siteSettingsFormSchema } from "./features/admin/schemas/site-settings-form";
 export { createReviewSchema as reviewSubmitSchema } from "./_internal/shared/features/reviews/schema";
 export { wishlistAddSchema } from "./schemas/api-routes";
+export { withHistory, buildHistoryEntry, appendHistoryEntry, diffTrackedFields, STATUS_HISTORY_MAX, } from "./_internal/shared/history/index";
+export type { StatusChangeEntry, SerialisedStatusChangeEntry, HistoryActor, HistoryActorRole, FieldChange, } from "./_internal/shared/history/index";

package/dist/index.js

@@ -3934,6 +3934,11 @@ export { TitleBarLayout } from "./features/layout/index";
 // [CLIENT-SSR]-Runs in both SSR and browser â€" React component or hook that does not depend on browser-only APIs.
 // useBottomActions - React hook for use bottom actions.
 export { useBottomActions } from "./features/layout/index";
+export { RecordStatusTimeline } from "./features/status-history/index";
+// useFormBottomActions - pins a form's Save/Cancel row + error sheet to the mobile bottom-chrome tier.
+export { useFormBottomActions } from "./features/layout/index";
+export { FormErrorList } from "./ui/forms";
+export { OverlayContext, useIsInsideOverlay } from "./ui/components/overlay-context";
 // [CLIENT-SSR]-Runs in both SSR and browser â€" React component or hook that does not depend on browser-only APIs.
 // useBottomActionsContext - React hook for use bottom actions context.
 export { useBottomActionsContext } from "./features/layout/index";
@@ -5637,7 +5642,7 @@ export { MEGABYTE, MAX_IMAGE_BYTES, MAX_PDF_BYTES, MAX_VIDEO_BYTES, MAX_LABEL, M
 // NOTE: STORE_FIELDS, CATEGORY_FIELDS, EVENT_FIELDS, EVENT_ENTRY_FIELDS, PAYOUT_FIELDS,
 // COUPON_FIELDS, CART_FIELDS, USER_FIELDS, ADDRESS_FIELDS, NOTIFICATION_FIELDS,
 // SESSION_FIELDS, SCAMMER_FIELDS are already exported from feature barrels above.
-export { PRODUCT_FIELDS, PRODUCT_STATUS_TRANSITIONS, ORDER_FIELDS, REVIEW_FIELDS, BID_FIELDS, AD_FIELDS, BLOG_FIELDS, BRAND_FIELDS, WISHLIST_FIELDS, HISTORY_FIELDS, COUPON_USAGE_FIELDS, CONVERSATION_FIELDS, CAROUSEL_FIELDS, FAQ_FIELDS, HOMEPAGE_SECTION_FIELDS, SITE_SETTINGS_FIELDS, COMMON_FIELDS, OAUTH_STATE_VALUES, SCHEMA_DEFAULTS, } from "./constants/field-names";
+export { PRODUCT_FIELDS, PRODUCT_STATUS_TRANSITIONS, ORDER_FIELDS, REVIEW_FIELDS, BID_FIELDS, AD_FIELDS, AD_TRACKED_FIELDS, BLOG_FIELDS, BRAND_FIELDS, WISHLIST_FIELDS, HISTORY_FIELDS, COUPON_USAGE_FIELDS, CONVERSATION_FIELDS, CAROUSEL_FIELDS, FAQ_FIELDS, HOMEPAGE_SECTION_FIELDS, SITE_SETTINGS_FIELDS, COMMON_FIELDS, OAUTH_STATE_VALUES, SCHEMA_DEFAULTS, } from "./constants/field-names";
 // ── Sort helpers ──────────────────────────────────────────────────────────────
 export { SORT_DIR, sortBy } from "./constants/sort";
 // ── URL table keys + view mode ────────────────────────────────────────────────
@@ -5711,3 +5716,13 @@ export { siteSettingsFormSchema } from "./features/admin/schemas/site-settings-f
  */
 export { createReviewSchema as reviewSubmitSchema } from "./_internal/shared/features/reviews/schema";
 export { wishlistAddSchema } from "./schemas/api-routes";
+/*
+ * Status history — the generic primitive behind every entity timeline.
+ *
+ * `withHistory` is exported because ads have no repository of their own: they
+ * live inside the `siteSettings` singleton, so their route calls it directly.
+ * Every other adopter funnels through its repository's write primitives and
+ * should keep doing so — a call site reaching for this outside a repository
+ * is usually a missing funnel, not a reason to export more of it.
+ */
+export { withHistory, buildHistoryEntry, appendHistoryEntry, diffTrackedFields, STATUS_HISTORY_MAX, } from "./_internal/shared/history/index";