@mohasinac/appkit 4.30.15 → 4.30.17

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

@@ -174,6 +174,24 @@ const rawTesterChecklistItems = [
                 { key: "browse-categories", label: "Browsing categories shows relevant products", href: "/categories" },
                 { key: "search", label: "Search returns relevant results", href: "/search" },
                 { key: "filters", label: "Search/listing filters (price, brand, condition) work correctly" },
+                {
+                    key: "grid-one-card-per-row-on-phone",
+                    label: "On a phone, a product listing shows exactly ONE card per row — not two narrow ones",
+                    description: "BEFORE (until 2026-08-28): every listing put 2 cards per row at 375px, so each card was ~170px wide and its title/price squeezed. AFTER: 1 card per row on a phone, 2 on a tablet (~768px), 3–4 on a desktop. Check /products, /stores, /blog and an admin listing in card view. Resize slowly through 375 / 768 / 1024 / 1440 — the count should go 1, 2, 3, 4 and the cards should always fill the full width between the page margins, never leave a gap on the right.",
+                    href: "/products",
+                },
+                {
+                    key: "grid-short-last-row-not-stretched",
+                    label: "A listing whose last row is short does NOT stretch that card across the page",
+                    description: "Find a listing showing e.g. 4 items while 3 fit per row (add filters until the count is not a multiple of the row size). The single card left over on the last row must be exactly as wide as the cards above it, sitting on the left with empty space to its right. If it stretches to full width, the grid was switched from `auto-fill` to `auto-fit` — report it, this is the specific bug the layout was rebuilt to fix.",
+                    href: "/products",
+                },
+                {
+                    key: "grid-follows-sidebar-not-viewport",
+                    label: "Opening the desktop filter sidebar drops ONE column and keeps the cards the same size",
+                    description: "On a wide desktop (~1440px) open /products and toggle the filter sidebar. The card count per row should drop by one while each card stays roughly the same width — the grid measures its own container, not the window. If the cards instead shrink to squeeze the same number in, report it.",
+                    href: "/products",
+                },
                 {
                     key: "homepage-prize-draws-section",
                     label: "The homepage shows a \"Prize Draws\" strip with real cards — NOT an empty gap and NOT a \"Something went wrong\" block",
@@ -192,6 +210,18 @@ const rawTesterChecklistItems = [
                     description: "Press F12 → Console tab, then load the page. A missing translation key logs 'MISSING_MESSAGE: <key>' and renders the raw key text instead of a readable label. Report the exact key name if you see one.",
                     href: "/products",
                 },
+                {
+                    key: "listing-toolbar-collapsed-on-mobile",
+                    label: "On a phone, a listing opens with the search/filter toolbar COLLAPSED to a single \"Show Toolbar\" strip",
+                    description: "BEFORE (until 2026-08-28): every listing opened with two stacked toolbar rows — search + Filter, then a scrolling sort/view chip row — roughly 100px of chrome above the first card. AFTER: a phone gets one thin \"Show Toolbar\" strip instead. Tap it: search, Filter and sort appear. Navigate to another listing and back — it should stay expanded, because you chose that. On a desktop (~1440px) the toolbar must still be open by default, exactly as before. Also confirm the toolbar is never simply GONE — there must always be a visible strip to tap.",
+                    href: "/products",
+                },
+                {
+                    key: "listing-toolbar-forced-open-on-selection",
+                    label: "Selecting rows on a phone force-opens the toolbar so the bulk actions are reachable",
+                    description: "In an admin or seller listing on a phone, collapse the toolbar, then select a row (long-press or the checkbox). The toolbar must open by itself, because the bulk-action bar lives inside it — if it stays collapsed you can select rows but have no way to act on them. Report if the bulk bar is invisible or cut off.",
+                    href: "/products",
+                },
                 {
                     key: "product-filter-status-labels",
                     label: "In an admin/seller listing's filter drawer, every Status option reads as words (Published / Draft / In Review / Archived) — never a raw key like \"filters.statusInReview\"",
@@ -220,52 +250,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 +330,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 +342,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",
                 },
                 {
@@ -668,6 +717,18 @@ const rawTesterChecklistItems = [
                     label: "A seller's per-listing \"Minimum Bid Increment\" can require MORE than the admin tier, but can never let a bid undercut the tier",
                     description: "Set a listing's \"Minimum Bid Increment\" below the current tier's value (e.g. 1) and confirm the effective minimum bid still enforces the tier, not the smaller override. Then set it above the tier (e.g. 500 when the tier is 100) and confirm the higher override is now enforced instead.",
                 },
+                {
+                    key: "bid-succeeds-and-outbids-previous-winner",
+                    label: "Placing a valid bid actually records it — the current bid rises and the previous high bid flips to \"outbid\"",
+                    description: "Fixed 2026-08-28. BEFORE: every bid failed and the modal showed the raw text \"Batch write failed: Cannot find module '../providers/db-firebase' Require stack: - /var/task/.next/server/chunks/ssr/...\" in the amount field. AFTER: the bid is accepted, \"Current bid\" rises by at least the minimum increment, and the previous winner's row in Bid History reads \"outbid\". Note the failure returned a normally-rendered modal and an HTTP 200, so \"the page loaded\" and \"no error in the network tab\" both prove nothing — read the actual numbers. Root cause: a relative-path runtime require inside appkit that only breaks once bundled into a Lambda chunk.",
+                    href: "/auctions/auction-tester-sandbox-cycle-1",
+                },
+                {
+                    key: "server-error-copy-is-never-raw",
+                    label: "A server failure shows plain-English copy — never a file path, stack trace or \"Cannot find module\"",
+                    description: "Fixed 2026-08-28. BEFORE: any 500 printed its own internal message to the user, including absolute server paths under /var/task/. AFTER: the user sees \"A database error occurred. Please try again\" (or \"Something went wrong. Please try again.\"), while the FULL original text plus its cause chain appears in Admin → Maintenance → Server errors. Check both halves: generic in the browser, specific in the admin list. Seeing the raw text in either the bid modal or any toast is a regression.",
+                    href: "/auctions/auction-tester-sandbox-cycle-1",
+                },
                 {
                     key: "bid-increment-live-tier-change",
                     label: "The displayed \"min increment\" on an open auction updates live (without a page refresh) if another bidder's bid pushes the current bid across a tier boundary",
@@ -1719,7 +1780,18 @@ const rawTesterChecklistItems = [
             cases: [
                 { key: "start-conversation", label: "Starting a conversation with a seller works" },
                 { key: "receive-reply", label: "Receiving and reading a seller's reply works" },
-                { key: "message-realtime-update", label: "A new message appears in the recipient's thread without a manual page refresh (realtime ping-channel)", href: "/user/messages" },
+                {
+                    key: "message-realtime-update",
+                    label: "A new message appears in the RECIPIENT's thread without a manual page refresh (realtime ping-channel)",
+                    description: "Fixed 2026-08-28. BEFORE: only the SENDER saw their own message, because the send handler calls refetch() directly — the recipient saw nothing until they reloaded. Two stacked faults: the hooks subscribed without ever signing in to the realtime database, AND the `conversationIds` claim the security rule requires had no issuer anywhere (the token route only sent `chatIds`, from an unrelated collection). Both errors were swallowed, one into a literal `// ignore`. AFTER: open the same conversation as buyer in one browser and seller in another, send from one, and the other updates on its own. Test it from BOTH directions — testing only the sender's own window is what let this pass before.",
+                    href: "/user/messages",
+                },
+                {
+                    key: "message-live-updates-survive-bulk-job",
+                    label: "Running a bulk admin action while a message thread is open does not kill that thread's live updates",
+                    description: "Fixed 2026-08-28. BEFORE: the realtime app is a single shared connection, and finishing a bulk job signed it out globally — so an open chat or message thread silently stopped updating, and vice versa (opening a chat killed an in-flight bulk job's progress). AFTER: open a message thread, run any bulk action from an admin listing until it completes, then send a message from the other account — the thread must still update live without a reload.",
+                    href: "/user/messages",
+                },
                 { key: "messages-list-thread", label: "The messages list and individual thread view both load correctly", href: "/user/messages" },
             ],
         },
@@ -2338,6 +2410,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/next/api/routeHandler.js

@@ -32,6 +32,7 @@ import { NextResponse } from "next/server.js";
 import { getProviders } from "../../contracts";
 import { isEffectiveAdminUser } from "../../features/auth/role-predicates";
 import { mapToHttpError, HTTP_ERROR_CODES } from "../../errors/error-mapping";
+import { describeCauseChain } from "../../errors/describe-cause";
 import { buildErrorEnvelope, toApiIssues } from "../../errors/error-envelope";
 import { serverErrorsRepository } from "../../features/server-errors/repository/server-errors.repository";
 import { userRepository } from "../../repositories";
@@ -93,10 +94,17 @@ const LOG_AS_INCIDENT_CODES = new Set([
     HTTP_ERROR_CODES.PAYMENT_ROLLBACK_ATTEMPTED,
     HTTP_ERROR_CODES.PAYMENT_ROLLBACK_FAILED,
 ]);
-function shouldPersist(status, code) {
-    if (status >= 500)
+function shouldPersist(mapped) {
+    if (mapped.status >= 500)
         return true;
-    return LOG_AS_INCIDENT_CODES.has(code);
+    // Firestore itself refused. `permission-denied` (expired service-account
+    // key) and `resource-exhausted` (quota blown) map to 403/429, which sit
+    // below the 5xx threshold — so these were previously recorded nowhere.
+    // Keyed on provenance rather than code, because our own RBAC guard and rate
+    // limiter emit those same codes in normal operation.
+    if (mapped.infrastructure)
+        return true;
+    return LOG_AS_INCIDENT_CODES.has(mapped.code);
 }
 /**
  * Resolve the body schema for a createRouteHandler call. Accepts either a
@@ -282,16 +290,28 @@ export function createRouteHandler(options) {
             const mapped = mapToHttpError(err, {
                 isProduction: process.env.NODE_ENV === "production",
             });
-            // -- Persisted log (5xx + selected 4xx) --------------------------------
-            if (shouldPersist(mapped.status, mapped.code)) {
-                void serverErrorsRepository().record({
+            // -- Persisted log (5xx + infrastructure + selected 4xx) ---------------
+            // AWAITED, not fire-and-forget. `void record(...)` raced the response:
+            // the lambda can be frozen or reclaimed the moment we return, and
+            // `record()` swallows its own failures, so a lost write left no trace
+            // anywhere — indistinguishable from "the error never happened".
+            // `record()` is documented never to throw, so awaiting it cannot turn a
+            // logging failure into a request failure; the cost is one Firestore
+            // round-trip on an already-failed request.
+            if (shouldPersist(mapped)) {
+                await serverErrorsRepository().record({
                     source: "vercel",
                     route: new URL(request.url).pathname,
                     method: request.method,
                     ...(user?.uid ? { userId: user.uid } : {}),
                     code: mapped.code,
-                    message: mapped.message,
+                    // internalMessage ?? message — `mapped.message` is scrubbed to a
+                    // generic string for 5xx in production so it is safe to send to a
+                    // browser. The store must get the real one, or the scrub would have
+                    // traded a UI leak for blindness.
+                    message: mapped.internalMessage ?? mapped.message,
                     stack: err instanceof Error ? err.stack : undefined,
+                    cause: describeCauseChain(err),
                     requestId,
                     userAgent: request.headers.get("user-agent") ?? undefined,
                 });

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

@@ -5,6 +5,17 @@ import { applySieveToFirestore, countSieveMatches, } from "./sieve";
 import { deserializeTimestamps, prepareForFirestore } from "./helpers";
 import { getAdminDb } from "./admin";
 import { encryptPiiFields, piiIndicesFor } from "../../security/pii-encrypt";
+/**
+ * The underlying failure's message, for interpolation into a DatabaseError.
+ *
+ * Every wrap below used to read `"Failed to update document: abc123"` and
+ * nothing else, so the persisted serverErrors row — whose `message` is what the
+ * admin list renders — said only which method failed, never why. `cause` now
+ * carries the stack, but a human scanning the list needs the reason on the row.
+ */
+function detailOf(error) {
+    return error instanceof Error ? error.message : String(error);
+}
 export class BaseRepository {
     constructor(collectionName) {
         /**
@@ -60,7 +71,7 @@ export class BaseRepository {
         }
         catch (error) {
             void normalizeError(error);
-            throw new DatabaseError(`Failed to find document by ID: ${id}`, error);
+            throw new DatabaseError(`Failed to find document by ID: ${id}: ${detailOf(error)}`, error);
         }
     }
     async findByIdOrFail(id) {
@@ -79,7 +90,7 @@ export class BaseRepository {
         }
         catch (error) {
             void normalizeError(error);
-            throw new DatabaseError(`Failed to find documents by ${field}`, error);
+            throw new DatabaseError(`Failed to find documents by ${field}: ${detailOf(error)}`, error);
         }
     }
     async findOneBy(field, value) {
@@ -95,7 +106,7 @@ export class BaseRepository {
         }
         catch (error) {
             void normalizeError(error);
-            throw new DatabaseError(`Failed to find document by ${field}`, error);
+            throw new DatabaseError(`Failed to find document by ${field}: ${detailOf(error)}`, error);
         }
     }
     async findAll(limit) {
@@ -109,7 +120,7 @@ export class BaseRepository {
         }
         catch (error) {
             void normalizeError(error);
-            throw new DatabaseError("Failed to fetch all documents", error);
+            throw new DatabaseError(`Failed to fetch all documents: ${detailOf(error)}`, error);
         }
     }
     /**
@@ -158,7 +169,7 @@ export class BaseRepository {
         }
         catch (error) {
             void normalizeError(error);
-            throw new DatabaseError("Failed to create document", error);
+            throw new DatabaseError(`Failed to create document: ${detailOf(error)}`, error);
         }
     }
     async createWithId(id, data) {
@@ -169,20 +180,20 @@ export class BaseRepository {
                 createdAt: now,
                 updatedAt: now,
             });
-            serverLogger.debug(`Creating document with ID: ${id} in collection: ${this.collection}`);
+            // No success-path logging. This emitted one debug + one info line for
+            // EVERY document written, against Rule #6's ~4 KB/s log budget, and the
+            // failure path below already carries everything the success path did.
             await this.getCollection().doc(id).set(cleanData);
-            serverLogger.info(`Document created successfully: ${id}`);
             const doc = await this.getCollection().doc(id).get();
             return this.mapDoc(doc);
         }
         catch (error) {
             void normalizeError(error);
-            serverLogger.error(`Failed to create document with ID: ${id}`, {
-                collection: this.collection,
-                error: error.message,
-                code: error.code,
-            });
-            throw new DatabaseError(`Failed to create document with ID: ${id}`, error);
+            // No serverLogger.error here either — this method was the only one of the
+            // ten wraps that logged AND rethrew, so its failures were recorded twice
+            // (once here, once by createRouteHandler), the first copy strictly less
+            // informative. The DatabaseError below now carries the same detail.
+            throw new DatabaseError(`Failed to create document with ID: ${id}: ${detailOf(error)}`, error);
         }
     }
     async update(id, data) {
@@ -196,7 +207,7 @@ export class BaseRepository {
         }
         catch (error) {
             void normalizeError(error);
-            throw new DatabaseError(`Failed to update document: ${id}`, error);
+            throw new DatabaseError(`Failed to update document: ${id}: ${detailOf(error)}`, error);
         }
     }
     async delete(id) {
@@ -205,7 +216,7 @@ export class BaseRepository {
         }
         catch (error) {
             void normalizeError(error);
-            throw new DatabaseError(`Failed to delete document: ${id}`, error);
+            throw new DatabaseError(`Failed to delete document: ${id}: ${detailOf(error)}`, error);
         }
     }
     async exists(id) {
@@ -215,17 +226,29 @@ export class BaseRepository {
         }
         catch (error) {
             void normalizeError(error);
-            throw new DatabaseError(`Failed to check document existence: ${id}`, error);
+            throw new DatabaseError(`Failed to check document existence: ${id}: ${detailOf(error)}`, 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);
-            throw new DatabaseError("Failed to count documents", error);
+            throw new DatabaseError(`Failed to count documents: ${detailOf(error)}`, error);
         }
     }
     async sieveQuery(model, fields, options) {
@@ -286,7 +309,12 @@ export class BaseRepository {
             }
             catch (error) {
                 void normalizeError(error);
-                serverLogger.warn(`facetCounts: count failed for ${this.collection}.${field}==${value}; facet will stay visible`);
+                // ERROR, not warn, and WITH the error object. A count failing here is
+                // almost always a missing composite index — a permanent, silent
+                // degradation of every facet on the listing page, not a transient
+                // blip. Logging it at warn with no error attached meant the actual
+                // FAILED_PRECONDITION (which names the index to create) was discarded.
+                serverLogger.error(`facetCounts: count failed for ${this.collection}.${field}==${value}; facet will stay visible`, { collection: this.collection, field, value, error });
                 return [value, undefined];
             }
         }));

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;
     /**