@mohasinac/appkit 4.30.15 → 4.30.16

package/dist/features/products/components/ProductsIndexListing.js

@@ -5,7 +5,7 @@ import { ShoppingCart, Heart, Columns } from "lucide-react";
 import { useRouter } from "next/navigation";
 import { useUrlTable } from "../../../react/hooks/useUrlTable";
 import { useProducts } from "../hooks/useProducts";
-import { BulkActionBar, Div, FilterChipGroup, FilterDrawer, ListingToolbar, LoginRequiredModal, Pagination, Row, Stack, useToast, StickyToolbar } from "../../../ui";
+import { BulkActionBar, Div, FilterDrawer, ListingToolbar, LoginRequiredModal, Pagination, Row, Stack, useToast, StickyToolbar } from "../../../ui";
 import { usePendingTable } from "../../../react/hooks/usePendingTable";
 import { useAuthGate } from "../../../react/hooks/useAuthGate";
 import { ACTION_ID, ACTION_META, COMPARE_MAX_ITEMS } from "../constants/action-defs";
@@ -40,7 +40,27 @@ const __O = {
     hidden: "overflow-hidden",
 };
 const DEFAULT_SORT = sortBy(PRODUCT_FIELDS.CREATED_AT);
-const FILTER_KEYS = [TABLE_KEYS.CATEGORY, TABLE_KEYS.CONDITION, TABLE_KEYS.MIN_PRICE, TABLE_KEYS.MAX_PRICE, TABLE_KEYS.BRAND, TABLE_KEYS.STORE_ID, TABLE_KEYS.FREE_SHIPPING, TABLE_KEYS.TAGS, TABLE_KEYS.FEATURES, TABLE_KEYS.IS_PART_OF_BUNDLE];
+// `LISTING_TYPE` is a managed filter key like any other: it stages in the
+// drawer, counts toward the filter badge, and is cleared by Reset. It used to
+// be driven by a separate always-visible chip row that wrote the URL directly,
+// which was the one facet bypassing the Apply model everything else uses.
+const FILTER_KEYS = [TABLE_KEYS.LISTING_TYPE, TABLE_KEYS.CATEGORY, TABLE_KEYS.CONDITION, TABLE_KEYS.MIN_PRICE, TABLE_KEYS.MAX_PRICE, TABLE_KEYS.BRAND, TABLE_KEYS.STORE_ID, TABLE_KEYS.FREE_SHIPPING, TABLE_KEYS.TAGS, TABLE_KEYS.FEATURES, TABLE_KEYS.IS_PART_OF_BUNDLE];
+/**
+ * The dedicated per-type browse page for a selection, when there is exactly
+ * one type and that type has its own page — which carries facets this generic
+ * one can't (bid range, delivery-date window, reveal status).
+ */
+function dedicatedPageFor(types) {
+    if (types.length !== 1)
+        return null;
+    const plugin = pluginFor(types[0]);
+    if (!plugin.browseRoute)
+        return null;
+    return {
+        href: plugin.browseRoute,
+        label: `Full ${plugin.pluralLabel} filters →`,
+    };
+}
 export function ProductsIndexListing({ initialData, listingTypes = GENERIC_PRODUCT_LISTING_TYPES, typeTabs = PRODUCT_TYPE_FILTER_TABS, searchPlaceholder = "Search products...", }) {
     const router = useRouter();
     const table = useUrlTable({ defaults: { pageSize: "24", sort: DEFAULT_SORT } });
@@ -74,36 +94,39 @@ export function ProductsIndexListing({ initialData, listingTypes = GENERIC_PRODU
     // keeps the SSR paint and the first refetch in agreement (Root Cause #30).
     const availability = table.get(TABLE_KEYS.AVAILABILITY) ||
         AVAILABILITY_VALUES.AVAILABLE;
-    // "Full <type> filters →" — a single selected type with a dedicated browse
-    // page gets a link to it, since that page carries facets this generic one
-    // can't (bid range, delivery-date window, reveal status).
-    const dedicatedPage = selectedTypes.length === 1 && pluginFor(selectedTypes[0]).browseRoute
-        ? {
-            href: pluginFor(selectedTypes[0]).browseRoute,
-            label: `Full ${pluginFor(selectedTypes[0]).pluralLabel} filters →`,
-        }
-        : null;
     const { pendingTable, filterActiveCount, onFilterApply, onFilterClear, onResetAll, onFilterReset } = usePendingTable(table, FILTER_KEYS);
+    // The drawer's own, uncommitted type selection. The "Full <type> filters →"
+    // link tracks THIS rather than the applied URL value, so it appears the
+    // moment the user ticks a single type instead of only after Apply.
+    const pendingTypes = parseSelectedListingTypes(pendingTable.get(TABLE_KEYS.LISTING_TYPE)).filter((t) => listingTypes.includes(t));
+    const dedicatedPage = dedicatedPageFor(pendingTypes);
+    const listingTypeOptions = typeTabs.map((t) => ({ value: t.id, label: t.label }));
     const openFilters = useCallback(() => {
         onFilterReset();
         setFilterOpen(true);
     }, [onFilterReset]);
     const applyFilters = useCallback(() => {
-        onFilterApply();
+        // A sort valid for the old type selection (say -auctionEndDate) can be
+        // invalid for the new one, so it is blanked in the SAME setMany as the
+        // filters — a follow-up table.set would read stale searchParams and
+        // overwrite this update (Root Cause #13).
+        const key = (types) => [...types].sort().join("|");
+        const typesChanged = key(pendingTypes) !== key(selectedTypes);
+        onFilterApply(typesChanged ? { [TABLE_KEYS.SORT]: "" } : undefined);
         setFilterOpen(false);
-    }, [onFilterApply]);
+    }, [onFilterApply, pendingTypes, selectedTypes]);
     const resetAll = useCallback(() => {
+        // `listingType` is a managed filter key now, so onResetAll clears it —
+        // repeating it here would be a second write of the same value.
         onResetAll({
             [TABLE_KEYS.QUERY]: "",
             [TABLE_KEYS.SORT]: "",
             [TABLE_KEYS.AVAILABILITY]: "",
-            [TABLE_KEYS.LISTING_TYPE]: "",
         });
         setSearchInput("");
     }, [onResetAll]);
     const hasActiveState = !!table.get(TABLE_KEYS.QUERY) ||
         availability !== AVAILABILITY_VALUES.AVAILABLE ||
-        !!typeParam ||
         table.get(TABLE_KEYS.SORT) !== DEFAULT_SORT ||
         filterActiveCount > 0;
     const localCart = useGuestCart();
@@ -263,17 +286,7 @@ export function ProductsIndexListing({ initialData, listingTypes = GENERIC_PRODU
                     // → close for every toggle. The full facet set (category/price/brand/…)
                     // remains in <FilterDrawer> below.
                     { label: "Free shipping", active: table.get(TABLE_KEYS.FREE_SHIPPING) === "true", onChange: (next) => table.set(TABLE_KEYS.FREE_SHIPPING, next ? "true" : "") },
-                ] }), _jsx(Div, { padding: "y-sm", children: _jsx(AvailabilityTabs, { types: effectiveTypes }) }), _jsx(Div, { padding: "y-sm", children: _jsxs(Row, { justify: "between", align: "center", wrap: true, gap: "sm", children: [_jsx(FilterChipGroup, { multiple: true, label: "Type", tabs: typeTabs, value: selectedTypes.join("|"), onChange: (next) => {
-                                // Clear `sort` alongside the type change: a sort valid for the
-                                // old selection (say -auctionEndDate) can be invalid for the new
-                                // one, and useUrlTable's single router.replace means we must set
-                                // both in ONE call — a follow-up setPage/set would read stale
-                                // searchParams and overwrite this update (Root Cause #13).
-                                table.setMany({
-                                    [TABLE_KEYS.LISTING_TYPE]: next,
-                                    [TABLE_KEYS.SORT]: "",
-                                });
-                            } }), dedicatedPage && (_jsx(TextLink, { href: dedicatedPage.href, size: "sm", weight: "medium", children: dedicatedPage.label }))] }) }), _jsx(BulkActionBar, { selectedCount: selection.selectedCount, onClearSelection: selection.clearSelection, actions: [
+                ] }), _jsx(Div, { padding: "y-sm", children: _jsx(AvailabilityTabs, { types: effectiveTypes }) }), _jsx(BulkActionBar, { selectedCount: selection.selectedCount, onClearSelection: selection.clearSelection, actions: [
                     {
                         id: ACTION_ID.ADD_TO_CART,
                         label: ACTION_META[ACTION_ID.ADD_TO_CART].label,
@@ -321,5 +334,5 @@ export function ProductsIndexListing({ initialData, listingTypes = GENERIC_PRODU
                 ] }), totalPages > 1 && (_jsx(StickyToolbar, { offset: "header+pagination", tone: "translucent", border: true, padding: "toolbar", children: _jsx(Row, { justify: "center", children: _jsx(Pagination, { currentPage: page, totalPages: totalPages, onPageChange: (p) => table.setPage(p) }) }) })), _jsx(Div, { padding: "y-lg", children: isLoading ? (_jsx(Div, { layout: "grid", gap: "4", className: "grid-cols-2 sm:grid-cols-3 lg:grid-cols-4", children: Array.from({ length: 10 }).map((_, i) => (_jsxs(Div, { className: `${__O.hidden} animate-pulse`, border: "subtle", rounded: "xl", children: [_jsx(Div, { className: "aspect-square", surface: "subtle" }), _jsxs(Stack, { className: `${__P.p3}`, gap: "sm", children: [_jsx(Div, { className: "h-3 w-3/4", surface: "subtle", rounded: "default" }), _jsx(Div, { className: "h-3 w-1/2", surface: "subtle", rounded: "default" }), _jsx(Div, { className: "h-4 w-1/3", surface: "subtle", rounded: "default" })] })] }, i))) })) : (_jsx(ProductGrid, { products: products, getProductHref: (p) => pluginFor(p.listingType ?? "standard").detailRoute(p.slug || p.id), view: view === "grid" ? "card" : "list", onWishlistToggle: handleWishlistToggle, wishlistedIds: wishlistedIds, onAddToCart: handleAddToCart, onBuyNow: handleBuyNow, selectionMode: selection.isSelecting, selectedIds: selection.selectedIdSet, onToggleSelect: selection.toggle })) }), _jsx(CompareOverlay, { isOpen: compareIds.length > 0, productIds: compareIds, productType: "product", onClose: () => {
                     setCompareIds([]);
                     selection.clearSelection();
-                }, onRemove: (id) => setCompareIds((ids) => ids.filter((i) => i !== id)) }), _jsx(FilterDrawer, { open: filterOpen, onOpen: openFilters, onClose: () => setFilterOpen(false), onApply: applyFilters, onReset: onFilterClear, activeCount: filterActiveCount, hideTrigger: true, children: _jsx(ProductFilters, { table: pendingTable, currencyPrefix: "\u20B9", categoryOptions: categoryOptions, brandOptions: brandOptions, featureOptions: featureOptions }) }), _jsx(LoginRequiredModal, { isOpen: modalOpen, onClose: closeModal, message: modalMessage })] }));
+                }, onRemove: (id) => setCompareIds((ids) => ids.filter((i) => i !== id)) }), _jsx(FilterDrawer, { open: filterOpen, onOpen: openFilters, onClose: () => setFilterOpen(false), onApply: applyFilters, onReset: onFilterClear, activeCount: filterActiveCount, hideTrigger: true, children: _jsx(ProductFilters, { table: pendingTable, currencyPrefix: "\u20B9", listingTypeOptions: listingTypeOptions, listingTypeFooter: dedicatedPage ? (_jsx(Div, { padding: "x-md", className: "pb-[var(--appkit-space-3)]", children: _jsx(TextLink, { href: dedicatedPage.href, size: "sm", weight: "medium", children: dedicatedPage.label }) })) : null, categoryOptions: categoryOptions, brandOptions: brandOptions, featureOptions: featureOptions }) }), _jsx(LoginRequiredModal, { isOpen: modalOpen, onClose: closeModal, message: modalMessage })] }));
 }

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

@@ -11,16 +11,18 @@ declare class ReviewRepository extends BaseRepository<ReviewDocument> {
     constructor();
     private decryptSieveResult;
     /**
-     * Encrypt PII, then attach blind indices derived from the plaintext.
+     * Declared, not hand-rolled.
      *
-     * Previously this reassigned `encrypted = addPiiIndices(data, …)` — which
-     * re-reads the ORIGINAL plaintext and returns `{...data, ...indices}` — and
-     * then spread that over the ciphertext, so plaintext won and `userName` was
-     * written to Firestore in the clear beside a valid index. `piiIndicesFor`
-     * returns the index fields alone, so the ciphertext cannot be overwritten.
-     * The identical bug was fixed in UserRepository and never propagated here.
+     * `BaseRepository.applyWriteHooks` already does exactly what the private
+     * `encryptReviewData` did — encrypt the listed fields, then add the mapped blind
+     * indices derived from the PLAINTEXT source. Declaring the fields means all
+     * nine mutating methods get it, including the `createWithId` / `*InTx` /
+     * `*InBatch` family that inherited unhooked base implementations while the
+     * encryption lived in a private method only three call sites remembered to
+     * call.
      */
-    private encryptReviewData;
+    protected piiFields: readonly ["userName"];
+    protected piiIndexMap: Record<string, string>;
     protected mapDoc<D = ReviewDocument>(snap: import("../../../providers/db-firebase").DocumentSnapshot): D;
     create(input: ReviewCreateInput): Promise<ReviewDocument>;
     update(reviewId: string, data: Partial<ReviewDocument>): Promise<ReviewDocument>;

package/dist/features/reviews/repository/reviews.repository.js

@@ -1,7 +1,7 @@
 import { BaseRepository, getFirestoreCount, prepareForFirestore, parseSieveDateValue, } from "../../../providers/db-firebase";
 import { NotFoundError } from "../../../errors";
 import { REVIEW_MAX_RATING, REVIEW_MIN_RATING } from "../../../_internal/shared/features/reviews/config";
-import { decryptPiiFields, encryptPiiFields, piiIndicesFor, REVIEW_PII_FIELDS, REVIEW_PII_INDEX_MAP, } from "../../../security";
+import { decryptPiiFields, REVIEW_PII_FIELDS, REVIEW_PII_INDEX_MAP, } from "../../../security";
 import { createReviewId, REVIEW_COLLECTION, } from "../schemas";
 import { buildReviewSearchTxt } from "../../../utils/search-txt-builders";
 import { planSearchTxt, refineSearchTxt, emptySearchResult, } from "../../../utils/search-txt-query";
@@ -21,6 +21,19 @@ const REVIEW_FIELDS = {
 class ReviewRepository extends BaseRepository {
     constructor() {
         super(REVIEW_COLLECTION);
+        /**
+         * Declared, not hand-rolled.
+         *
+         * `BaseRepository.applyWriteHooks` already does exactly what the private
+         * `encryptReviewData` did — encrypt the listed fields, then add the mapped blind
+         * indices derived from the PLAINTEXT source. Declaring the fields means all
+         * nine mutating methods get it, including the `createWithId` / `*InTx` /
+         * `*InBatch` family that inherited unhooked base implementations while the
+         * encryption lived in a private method only three call sites remembered to
+         * call.
+         */
+        this.piiFields = REVIEW_PII_FIELDS;
+        this.piiIndexMap = REVIEW_PII_INDEX_MAP;
     }
     decryptSieveResult(result) {
         return {
@@ -30,22 +43,6 @@ class ReviewRepository extends BaseRepository {
             ])),
         };
     }
-    /**
-     * Encrypt PII, then attach blind indices derived from the plaintext.
-     *
-     * Previously this reassigned `encrypted = addPiiIndices(data, …)` — which
-     * re-reads the ORIGINAL plaintext and returns `{...data, ...indices}` — and
-     * then spread that over the ciphertext, so plaintext won and `userName` was
-     * written to Firestore in the clear beside a valid index. `piiIndicesFor`
-     * returns the index fields alone, so the ciphertext cannot be overwritten.
-     * The identical bug was fixed in UserRepository and never propagated here.
-     */
-    encryptReviewData(data) {
-        return {
-            ...encryptPiiFields(data, [...REVIEW_PII_FIELDS]),
-            ...piiIndicesFor(data, REVIEW_PII_INDEX_MAP),
-        };
-    }
     mapDoc(snap) {
         const raw = super.mapDoc(snap);
         // `helpfulVoterIds` is an idempotency key, not review content — publishing it
@@ -71,7 +68,7 @@ class ReviewRepository extends BaseRepository {
             createdAt: new Date(),
             updatedAt: new Date(),
         };
-        const encrypted = this.encryptReviewData(reviewData);
+        const encrypted = this.applyWriteHooks(reviewData);
         await this.db
             .collection(this.collection)
             .doc(id)
@@ -79,7 +76,7 @@ class ReviewRepository extends BaseRepository {
         return { id, ...reviewData };
     }
     async update(reviewId, data) {
-        const encrypted = this.encryptReviewData(data);
+        const encrypted = this.applyWriteHooks(data);
         return super.update(reviewId, encrypted);
     }
     async findByProduct(productId) {

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

@@ -220,52 +220,70 @@ const rawTesterChecklistItems = [
                     description: "Verify against the seeded fixtures: \"Test Collectible — Sold Out\" (standard, hidden until \"Show sold\" is on), \"Test Auction — Already Won\" (hidden until \"Show ended\" is on), \"Test Prize Draw — Already Closed\" (hidden until \"Show closed\" is on). All three should be genuinely absent by default, not just from an unrelated broken query.",
                     href: "/products",
                 },
+                {
+                    key: "product-type-filter-lives-in-drawer",
+                    label: "There is NO standalone \"TYPE\" chip row on /products — the listing-type filter is a \"Listing type\" checkbox section at the TOP of the Filters drawer",
+                    description: "Changed 2026-08-28. BEFORE: a full-width band of pill chips (Standard / Auctions / Pre-Orders / …) sat between the Available-Sold-All tabs and the product grid, and clicking one filtered instantly. AFTER: that band is gone — the availability tabs sit directly above the grid — and the same options appear as checkboxes under \"Listing type\" when you press Filters. Report it if you can still see the old chip band anywhere.",
+                    href: "/products",
+                },
                 {
                     key: "product-type-chips-cover-all-types",
-                    label: "The TYPE chip row on /products lists ALL nine listing types — Standard, Auctions, Pre-Orders, Prize Draws, Classifieds, Digital Codes, Live Items, Art and Stickers",
-                    description: "Fixed 2026-08-21 — the row used to show only 5 chips (All / Standard / Classified / Digital Codes / Live Items), so auctions, pre-orders, prize draws, art and stickers were unreachable from the main catalogue even though items of those types existed. Count the chips: there should be nine, and none labelled \"Bundles\" (bundles are not a listing type).",
+                    label: "The \"Listing type\" section in the /products Filters drawer lists ALL nine listing types — Standard, Auctions, Pre-Orders, Prize Draws, Classifieds, Digital Codes, Live Items, Art and Stickers",
+                    description: "Open Filters and count the checkboxes under \"Listing type\": there should be nine, and none labelled \"Bundles\" (bundles are not a listing type). A type missing here is unreachable from the main catalogue even when items of that type exist.",
                     href: "/products",
                 },
                 {
                     key: "product-type-chips-multi-select",
-                    label: "The TYPE chips behave as CHECKBOXES, not radio buttons — several can be ticked at once, and ticking Auctions + Pre-Orders shows both types in one grid",
-                    description: "Tick Auctions, then tick Pre-Orders WITHOUT unticking Auctions. Both must stay highlighted and the grid must contain items of both types. Untick both and the grid returns to showing every type.",
+                    label: "The \"Listing type\" boxes are CHECKBOXES, not radio buttons — ticking Auctions + Pre-Orders and pressing Apply shows both types in one grid",
+                    description: "Tick Auctions, then tick Pre-Orders WITHOUT unticking Auctions, then press Apply. Both must stay ticked when you reopen the drawer, and the grid must contain items of both types. Untick both, Apply, and the grid returns to showing every type.",
                     href: "/products",
                 },
                 {
                     key: "product-type-chips-none-means-all",
-                    label: "With NO type chip ticked, /products shows a mix of listing types — check the coloured type badges on the cards",
+                    label: "With NO \"Listing type\" box ticked, /products shows a mix of listing types — check the coloured type badges on the cards",
                     description: "\"Nothing ticked\" means \"every type\", so you should be able to spot at least two different badges (e.g. an \"Auction\" and a \"Digital Code\") within the first page without filtering.",
                     href: "/products",
                 },
+                {
+                    key: "product-type-filter-counts-in-badge",
+                    label: "Ticking a \"Listing type\" box and pressing Apply increases the number on the Filters button, and \"Reset all\" in the drawer clears the type selection again",
+                    description: "Changed 2026-08-28 — the type filter used to sit outside the drawer and was invisible to both the badge and Reset. BEFORE: pick a type, badge stays where it was, Reset all leaves the type selection in place. AFTER: the badge goes up by one, and Reset all unticks every type box and repopulates the grid with all types.",
+                    href: "/products",
+                },
                 {
                     key: "product-type-chip-drives-sort-options",
-                    label: "Ticking exactly ONE type changes the Sort dropdown to that type's own sorts — Auctions alone offers \"Ending Soon\", Pre-Orders alone offers \"Earliest Delivery\"",
-                    description: "Tick only Auctions and open Sort: \"Ending Soon\" must be present. Untick it, tick only Pre-Orders: \"Earliest Delivery\" must be present and \"Ending Soon\" gone. With two types ticked only the sorts valid for both remain (Newest / Price / Name) — that is correct, not a bug.",
+                    label: "Applying exactly ONE listing type changes the Sort dropdown to that type's own sorts — Auctions alone offers \"Ending Soon\", Pre-Orders alone offers \"Earliest Delivery\"",
+                    description: "Filters → tick only Auctions → Apply, then open Sort: \"Ending Soon\" must be present. Swap to only Pre-Orders and Apply: \"Earliest Delivery\" must be present and \"Ending Soon\" gone. With two types applied only the sorts valid for both remain (Newest / Price / Name) — that is correct, not a bug.",
                     href: "/products",
                 },
                 {
                     key: "product-type-chip-sort-resets-no-empty-page",
                     label: "Choosing a type-specific sort and THEN changing the type selection never leaves an empty grid or an error",
-                    description: "The important regression check. Tick Auctions, sort by \"Ending Soon\", then untick Auctions and tick Standard instead. The grid must repopulate with products. A blank page here means a stale sort leaked into the new query.",
+                    description: "The important regression check. Apply Auctions, sort by \"Ending Soon\", then reopen Filters, untick Auctions, tick Standard, Apply. The grid must repopulate with products and the Sort dropdown must fall back to Newest. A blank page here means a stale sort leaked into the new query.",
                     href: "/products",
                 },
                 {
                     key: "product-type-toggles-follow-selection",
-                    label: "The toolbar toggles follow the type selection — \"Show ended\" appears only when a time-limited type is in play, \"Show sold\" only when a sellable type is",
-                    description: "Tick only Auctions: a \"Show ended\" toggle appears. Tick only Standard instead: \"Show ended\" disappears and \"Show sold\" remains. With nothing ticked (= all types) both may appear, which is correct.",
+                    label: "The middle availability tab is worded for the applied types — \"Ended\" for Auctions alone, \"Sold\" for Standard alone, \"Sold & Ended\" with nothing applied",
+                    description: "Apply only Auctions and read the middle tab above the grid; then swap to only Standard and read it again. It must re-word itself, and switching to that tab must list the unavailable items of the applied type.",
                     href: "/products",
                 },
                 {
                     key: "product-type-chip-dedicated-page-link",
-                    label: "Ticking exactly one type that has its own browse page shows a \"Full <type> filters\" link that lands on the right page",
-                    description: "Tick only Auctions — a \"Full Auctions filters\" link should appear beside the chips and open /auctions. Repeat for Pre-Orders and Prize Draws.",
+                    label: "Ticking exactly one type that has its own browse page shows a \"Full <type> filters\" link, inside the drawer under the Listing type section, that lands on the right page",
+                    description: "Changed 2026-08-28 — the link used to sit beside the old chip row. Open Filters, tick only Auctions: a \"Full Auctions filters →\" link appears directly under the Listing type checkboxes (before you press Apply) and opens /auctions. Repeat for Pre-Orders and Prize Draws. With two types ticked, or none, the link must NOT appear.",
                     href: "/products",
                 },
                 {
                     key: "product-type-selection-survives-reload",
-                    label: "The ticked type chips are reflected in the URL and survive a reload and the browser Back button",
-                    description: "Tick Auctions + Art, copy the URL, open it in a new tab: the same two chips must come back ticked with the same grid. Then press Back and confirm the previous selection returns.",
+                    label: "The applied listing types are reflected in the URL and survive a reload and the browser Back button",
+                    description: "Apply Auctions + Art, copy the URL, open it in a new tab: the grid must match and reopening Filters must show those two boxes already ticked. Then press Back and confirm the previous selection returns.",
+                    href: "/products",
+                },
+                {
+                    key: "product-type-pending-until-apply",
+                    label: "Ticking a \"Listing type\" box does NOT change the grid until you press Apply — and closing the drawer with the X discards the change",
+                    description: "Changed 2026-08-28 — the old chips filtered on every click. Tick Auctions and watch the grid behind the drawer: it must not change. Press Apply and it does. Reopen, tick Art, close the drawer with the X (not Apply), and reopen: Art must be unticked again, matching what is actually applied.",
                     href: "/products",
                 },
                 {
@@ -282,8 +300,8 @@ const rawTesterChecklistItems = [
                 },
                 {
                     key: "pre-orders-reachable-from-products",
-                    label: "Pre-orders are reachable from /products — tick the Pre-Orders chip and confirm real pre-order items appear with a \"Pre-Order\" badge",
-                    description: "This was the original report: pre-orders (and auctions, prize draws, art, stickers) had no chip at all, so they could only be found via their own dedicated pages.",
+                    label: "Pre-orders are reachable from /products — Filters → Listing type → tick Pre-Orders → Apply, and confirm real pre-order items appear with a \"Pre-Order\" badge",
+                    description: "This was the original report: pre-orders (and auctions, prize draws, art, stickers) had no entry in the type filter at all, so they could only be found via their own dedicated pages.",
                     href: "/products",
                 },
                 {
@@ -294,7 +312,8 @@ const rawTesterChecklistItems = [
                 },
                 {
                     key: "art-stickers-type-chips-narrow",
-                    label: "On /art, the \"Art\" and \"Stickers\" type chips each narrow the grid to only that type — neither chip nor \"All\" ever returns zero rows",
+                    label: "On /art, the Filters drawer's \"Listing type\" section offers exactly two boxes — Art and Stickers — and each one alone narrows the grid to that type without ever returning zero rows",
+                    description: "This page spans only two of the nine listing types, so its Listing type section must show only those two. Tick Art → Apply, then Stickers → Apply, then untick both → Apply; all three states must return rows.",
                     href: "/art",
                 },
                 {
@@ -2338,6 +2357,131 @@ const rawTesterChecklistItems = [
                 { key: "tabs-mobile-dropdown", label: "Tabs on category/brand/product/event detail pages collapse into a colored dropdown on mobile once there are more than 5 tabs" },
             ],
         },
+        {
+            pageKey: "search",
+            pageLabel: "Search",
+            href: "/products",
+            cases: [
+                {
+                    key: "search-typeahead-differs",
+                    label: "Typing \"dranzer\" and then \"dragoon\" in the header search gives DIFFERENT suggestions",
+                    description: "WAS: the same 5 newest rows appeared for every keystroke, because no search term reached the query at all. If both terms give an identical list, the term is still being ignored.",
+                },
+                {
+                    key: "search-typeahead-no-drafts",
+                    label: "Header search suggestions contain no draft or archived listings",
+                    description: "WAS: the suggestion query applied no status filter, so unpublished drafts were visible to the public.",
+                },
+                {
+                    key: "search-prefix-match",
+                    label: "Searching \"dran\" finds Dranzer products on /products",
+                    description: "WAS: no match at all - only whole words matched, so a partial term found nothing.",
+                    href: "/products",
+                },
+                {
+                    key: "search-both-words-required",
+                    label: "Searching \"red dranzer\" returns only items matching BOTH words, not either one",
+                    description: "WAS: array-contains-any made multi-word search an OR, so adding a second word made the list LONGER instead of narrower. Check the count drops versus \"dranzer\" alone.",
+                    href: "/products",
+                },
+                {
+                    key: "search-plus-category-filter",
+                    label: "A search term AND a category filter apply together on /products",
+                    description: "WAS: an empty if-body dropped BOTH, so the page ignored the search and the filter simultaneously and showed everything. Apply one, note the count, then add the other and confirm it narrows again.",
+                    href: "/products",
+                },
+                {
+                    key: "search-keeps-sort",
+                    label: "Changing the sort while a search term is active re-orders the results and keeps the term",
+                    description: "WAS: the sort was silently discarded whenever a term was present, so the dropdown said \"Oldest\" over unsorted rows.",
+                    href: "/products",
+                },
+                {
+                    key: "search-keeps-facets",
+                    label: "On /products, searching keeps the price, tag and availability facets working",
+                    description: "WAS: the old case-insensitive operator threw inside the query builder, and because exceptions were suppressed the throw aborted every clause AFTER it - so one search term silently disabled the rest of the filter bar.",
+                    href: "/products",
+                },
+                {
+                    key: "search-case-and-accents",
+                    label: "\"POKEMON\" with an accent, without one, and capitalised all return the same results",
+                    description: "WAS: matching was case- and accent-sensitive, so only the exact stored spelling matched.",
+                    href: "/products",
+                },
+                {
+                    key: "search-single-char-narrows",
+                    label: "A single-character query narrows the list instead of showing everything",
+                    description: "WAS: a 1-char term was discarded as too short and the unfiltered collection came back - indistinguishable from a search that matched everything.",
+                    href: "/products",
+                },
+                {
+                    key: "search-faqs",
+                    label: "Searching on /faqs returns matching questions",
+                    description: "WAS: this is the report that started the whole migration - 63 FAQs existed, none had search tokens, so every query returned empty.",
+                    href: "/faqs",
+                },
+                {
+                    key: "search-faq-category-page",
+                    label: "Opening a FAQ category page renders its questions",
+                    description: "WAS: a missing index threw FAILED_PRECONDITION, which was swallowed, leaving a blank page with no error.",
+                    href: "/faqs",
+                },
+                {
+                    key: "search-scams-listing",
+                    label: "/scams lists the verified scammer profiles",
+                    description: "WAS: \"No verified scammers yet\" always, because the query needed an index that did not exist.",
+                    href: "/scams",
+                },
+                {
+                    key: "search-scam-partial-and-upi",
+                    label: "On /admin/scammers, searching \"Vikram\" finds \"Vikram Mehta\", and searching a UPI id also finds its profile",
+                    description: "WAS: the query matched a WHOLE array element, so \"Vikram\" found nothing against a list holding \"Vikram M\" and \"Vikram Mehta\" - and phones and UPI ids were never searched at all despite the box promising them.",
+                    href: "/admin/scammers",
+                },
+                {
+                    key: "search-store-event-blog-review",
+                    label: "Store, event, blog and review searches each return matches",
+                    description: "WAS: never implemented for any of the four - the box existed and the endpoint ignored the term.",
+                    href: "/blog",
+                },
+                {
+                    key: "search-admin-exact-match",
+                    label: "On /admin/reviews a FULL reviewer name matches, a partial one matches nothing, and the box says \"exact match\"",
+                    description: "This asserts a DELIBERATE decision, not a bug: the field is encrypted, and ciphertext has no usable prefix, so it is resolved through a blind index that matches exactly. What was wrong was the placeholder - it read \"Search reviews, products, or seller names\" and matched none of those three.",
+                    href: "/admin/reviews",
+                },
+                {
+                    key: "search-admin-degraded-sort",
+                    label: "Searching on /admin/payouts shows a notice that results are not sorted while searching",
+                    description: "Preserving the sort would need 14 more composite indexes to order a result an exact email match bounds at one row, so the sort is dropped on purpose. WAS: dropped SILENTLY - the sort dropdown kept displaying \"Oldest\" over unsorted rows.",
+                    href: "/admin/payouts",
+                },
+                {
+                    key: "search-admin-team-filter-chip",
+                    label: "On /admin/team, applying any filter chip still returns employees",
+                    description: "WAS: the filter string was CONCATENATED rather than joined, producing one malformed clause that matched nothing - so the team list silently emptied the moment anyone filtered it.",
+                    href: "/admin/team",
+                },
+                {
+                    key: "search-no-empty-toolbar-gap",
+                    label: "A listing page whose search box was removed shows no empty gap in its toolbar",
+                    description: "31 boxes were removed because their endpoints ignored the term. The toolbar should close up, not leave a hole where the input was.",
+                    href: "/admin/coupons",
+                },
+                {
+                    key: "search-nonsense-term-returns-nothing",
+                    label: "Searching \"zzzznope\" anywhere returns ZERO results",
+                    description: "The single most important case here. Every bug above returned HTTP 200 with plausible-looking rows, so a real term matching something proves nothing - only a nonsense term returning nothing distinguishes \"filtering\" from \"returning everything\". Try it on /products, /faqs, /blog and /admin/scammers.",
+                    href: "/products",
+                },
+                {
+                    key: "search-finds-older-records",
+                    label: "An OLDER listing - one that existed before this feature shipped - is findable by name",
+                    description: "Write this one carefully. Every other case here passes on freshly seeded data while real production documents stay invisible, because search tokens are only written when a record is saved. Pick a listing that has NOT been edited recently and confirm it is findable; if it is not, the backfill did not cover it.",
+                    href: "/products",
+                },
+            ],
+        },
     ]),
     ...group("community-support", "Community & Support", [
         {

package/dist/providers/db-firebase/base.repository.d.ts

@@ -62,6 +62,18 @@ export declare abstract class BaseRepository<T extends DocumentData> {
     update(id: string, data: Partial<T>): Promise<T>;
     delete(id: string): Promise<void>;
     exists(id: string): Promise<boolean>;
+    /**
+     * Server-side aggregation — never a full read.
+     *
+     * This used to be `getCollection().get()` then `.size`, which downloads every
+     * document in the collection to learn how many there are. On `products` or
+     * `orders` that is the entire collection billed as reads, and the payload is
+     * discarded immediately. Straight Rule #6 violation, and it scales with the
+     * data rather than staying flat.
+     *
+     * `count()` is a Firestore aggregation query: the server returns a number,
+     * billed at one read per 1000 documents matched rather than one per document.
+     */
     count(): Promise<number>;
     protected sieveQuery<TResult extends DocumentData = T>(model: SieveModel, fields: FirebaseSieveFields, options?: FirebaseSieveOptions & {
         baseQuery?: CollectionReference | Query;

package/dist/providers/db-firebase/base.repository.js

@@ -218,10 +218,22 @@ export class BaseRepository {
             throw new DatabaseError(`Failed to check document existence: ${id}`, error);
         }
     }
+    /**
+     * Server-side aggregation — never a full read.
+     *
+     * This used to be `getCollection().get()` then `.size`, which downloads every
+     * document in the collection to learn how many there are. On `products` or
+     * `orders` that is the entire collection billed as reads, and the payload is
+     * discarded immediately. Straight Rule #6 violation, and it scales with the
+     * data rather than staying flat.
+     *
+     * `count()` is a Firestore aggregation query: the server returns a number,
+     * billed at one read per 1000 documents matched rather than one per document.
+     */
     async count() {
         try {
-            const snapshot = await this.getCollection().get();
-            return snapshot.size;
+            const snapshot = await this.getCollection().count().get();
+            return snapshot.data().count;
         }
         catch (error) {
             void normalizeError(error);

package/dist/react/hooks/usePendingFilters.d.ts

@@ -19,8 +19,18 @@ export interface UsePendingFiltersReturn {
     appliedCount: number;
     /** Update one key in pending state (does NOT write to URL) */
     set: (key: string, values: string[]) => void;
-    /** Write all pending keys to the URL (resets page to 1) */
-    apply: () => void;
+    /**
+     * Write all pending keys to the URL (resets page to 1).
+     *
+     * `extras` piggy-backs non-filter keys onto the SAME `router.replace` —
+     * the escape hatch `clearAll` already has, for the same reason. A caller
+     * that needs to blank `sort` alongside a filter change (a sort valid for
+     * one selection can be FAILED_PRECONDITION for the next) must not issue a
+     * second `set`: it would read stale searchParams and overwrite this update
+     * (Root Cause #13). Filter keys are written last, so `extras` can never
+     * shadow one.
+     */
+    apply: (extras?: Record<string, string>) => void;
     /** Discard pending, revert to applied (URL) state */
     reset: () => void;
     /** Clear all keys in both pending state and the URL */

package/dist/react/hooks/usePendingFilters.js

@@ -47,8 +47,8 @@ export function usePendingFilters({ table, keys, }) {
     const set = useCallback((key, values) => {
         setPending((prev) => ({ ...prev, [key]: values }));
     }, []);
-    const apply = useCallback(() => {
-        const updates = { page: "1" };
+    const apply = useCallback((extras) => {
+        const updates = { page: "1", ...extras };
         for (const k of keys) {
             updates[k] = (pending[k] ?? []).join(",");
         }

package/dist/react/hooks/usePendingTable.d.ts

@@ -13,8 +13,15 @@ export interface UsePendingTableReturn {
     pendingTable: PendingTable;
     /** Count of applied (URL) filter values — use for the filter badge */
     filterActiveCount: number;
-    /** Commit all pending changes to the URL (resets page to 1) */
-    onFilterApply: () => void;
+    /**
+     * Commit all pending changes to the URL (resets page to 1).
+     *
+     * Pass `extras` to write non-filter keys in the SAME `router.replace` —
+     * e.g. blanking `sort` when the applied filters invalidate it. A follow-up
+     * `table.set` would read stale searchParams and clobber this one
+     * (Root Cause #13).
+     */
+    onFilterApply: (extras?: Record<string, string>) => void;
     /** Clear all filter keys from pending state and URL */
     onFilterClear: () => void;
     /**

package/dist/security/pii-schemas.d.ts

@@ -5,7 +5,25 @@
  * encrypted before storage and decrypted on read.
  */
 /** PII fields in the users collection (top-level string fields) */
-export declare const USER_PII_FIELDS: readonly ["email", "phoneNumber"];
+/**
+ * `googleLinkedEmail` was added 2026-08-28, found by audit-pii-coverage.
+ *
+ * It is a real email address, written in cleartext by the Google OAuth callback
+ * (`api/auth/google/callback`, three write sites) and stored on the user
+ * document beside `email` — which has always been encrypted. So one user's two
+ * email addresses sat in the same document, one ciphertext and one plaintext,
+ * and nothing pointed at the difference.
+ *
+ * No blind index: nothing queries by it. Its only reader is the account
+ * holder's own profile ("Signed in as …"), which is a legitimate plaintext read.
+ *
+ * Existing rows stay plaintext until backfilled and keep reading correctly —
+ * `decryptValue` passes a non-`enc:v1:` string through unchanged — so new
+ * writes encrypt while old rows converge, never diverge. Add
+ * `googleLinkedEmail` to the `users` target in `backfill-pii.mjs` when that
+ * backfill is next run.
+ */
+export declare const USER_PII_FIELDS: readonly ["email", "phoneNumber", "googleLinkedEmail"];
 /** Blind-index mapping for queryable user PII: source → index field name */
 export declare const USER_PII_INDEX_MAP: Record<string, string>;
 /** PII fields in the addresses subcollection */

package/dist/security/pii-schemas.js

@@ -5,7 +5,25 @@
  * encrypted before storage and decrypted on read.
  */
 /** PII fields in the users collection (top-level string fields) */
-export const USER_PII_FIELDS = ["email", "phoneNumber"];
+/**
+ * `googleLinkedEmail` was added 2026-08-28, found by audit-pii-coverage.
+ *
+ * It is a real email address, written in cleartext by the Google OAuth callback
+ * (`api/auth/google/callback`, three write sites) and stored on the user
+ * document beside `email` — which has always been encrypted. So one user's two
+ * email addresses sat in the same document, one ciphertext and one plaintext,
+ * and nothing pointed at the difference.
+ *
+ * No blind index: nothing queries by it. Its only reader is the account
+ * holder's own profile ("Signed in as …"), which is a legitimate plaintext read.
+ *
+ * Existing rows stay plaintext until backfilled and keep reading correctly —
+ * `decryptValue` passes a non-`enc:v1:` string through unchanged — so new
+ * writes encrypt while old rows converge, never diverge. Add
+ * `googleLinkedEmail` to the `users` target in `backfill-pii.mjs` when that
+ * backfill is next run.
+ */
+export const USER_PII_FIELDS = ["email", "phoneNumber", "googleLinkedEmail"];
 /** Blind-index mapping for queryable user PII: source → index field name */
 export const USER_PII_INDEX_MAP = {
     email: "emailIndex",