@mohasinac/appkit 4.53.0 → 4.53.2

package/dist/features/tester/seed-data/authored/content-discovery__category-tabs-franchise-bundles.js

@@ -1,7 +1,7 @@
 /*
  * WHY: Authored six-part procedures for the categories-index tabs, the
  *      franchise unit and the bundle collage (2026-10-14).
- * WHAT: 8 cases, keyed by full checklist id.
+ * WHAT: 9 cases, keyed by full checklist id.
  *
  * 🛑 EVERY CASE IS BEFORE → AFTER, because every defect this work produced
  * rendered a page that looked fine:
@@ -9,17 +9,19 @@
  *   1. The index rendered all 1,185 rows flat — six roots buried under 752
  *      part leaves. A case reading "the categories page loads" passes against
  *      that.
- *   2. The Parts tab first returned 772, catching the 20 classification NODES
- *      as well as the leaves, because their own `parentIds` also pass through
- *      a `*-parts` node. A list mixing "Attack Rings" with attack rings is not
- *      visibly wrong.
- *   3. Seven franchises have no stock. Active, each is a card opening an empty
+ *   2. Seven franchises have no stock. Active, each is a card opening an empty
  *      shop; absent, seventeen `CharacterHotspot` links stay 404. Both look
  *      correct from any single page — which is why two cases here check the
  *      index and the detail page SEPARATELY.
- *   4. Every bundle also carries a placeholder cover, so a collage tested
+ *   3. Every bundle also carries a placeholder cover, so a collage tested
  *      after the cover never renders — and one grey tile is not "broken".
  *
+ * 🛑 A fifth PARTS tab was removed 2026-10-20 and its case deleted with it.
+ * Parts live at `/parts/[classification]/[code]` and in the spares listing
+ * type; a flat tab over 752 leaves was the worse half of both. The
+ * product-detail Parts COMPOSITION tab is unrelated and still covered, on the
+ * `parts-database` page.
+ *
  * So each case counts an exact number or compares two surfaces. Several carry
  * a nonsense control, because a filter that returns everything looks identical
  * to a filter that works.
@@ -47,49 +49,36 @@ export const authored = {
         expectedData: { rootCards: 6 },
         endResult: "Nothing is changed; this case only reads.",
     },
-    "checklist-content-discovery-category-tabs-franchise-bundles-five-tabs-no-all": {
+    "checklist-content-discovery-category-tabs-franchise-bundles-four-tabs-no-all-no-parts": {
         roles: ["guest"],
         startPage: "/categories",
         steps: [
             "Open /categories.",
             "Read the tab bar.",
-            "Confirm there are exactly five tabs: Categories, Brands, Franchises, Parts, Bundles.",
+            "Confirm there are exactly four tabs: Categories, Brands, Franchises, Bundles.",
             "Answer no if a tab labelled 'All' is present.",
+            "Answer no if a tab labelled 'Parts' is present.",
+            "Open a product detail page for a named-model Beyblade — for example /categories/category-ace-dragon-sting-charge-zan reached through Spinning Tops, or any complete-top listing — and confirm its own 'Parts' / 'What it is made of' composition section is STILL there. That is a different tab on a different surface and must not have been removed.",
         ],
-        expectedBehaviour: "BEFORE: the tabs were All / Categories / Brands, and 'All' was the DEFAULT — it is what rendered the 1,185 rows. AFTER: five tabs, no 'All'. Every tab answers a question ('which parts do you have?'); 'all' answered none of them, which is why it was removed rather than reordered.",
-        expectedUiState: "Five tabs, named exactly as above, with no 'All'.",
-        expectedData: { tabCount: 5, hasAllTab: false },
-        endResult: "Nothing is changed; this case only reads.",
-    },
-    "checklist-content-discovery-category-tabs-franchise-bundles-parts-tab-is-leaves-only": {
-        roles: ["guest"],
-        startPage: "/categories",
-        steps: [
-            "Open /categories and click the Parts tab.",
-            "Read the total the pager reports.",
-            "Confirm it reads 752 and not 772.",
-            "Scan the first page and confirm every card is an individual PART — '1B', 'Ten Heavy', 'Neo Right SG'.",
-            "Answer no if a classification GROUP appears as a card: 'Attack Rings', 'Weight Disks', 'Performance Tips', 'Bit Chips'.",
-        ],
-        expectedBehaviour: "BEFORE: the tab returned 772, because the predicate matched any row whose ancestry passes a `*-parts` node — which is true of the 20 classification NODES as well as the leaves beneath them. The list mixed groups with their own contents and was not visibly wrong. AFTER: leaves only, 752. A part is a leaf by itself; a classification is a branch you reach by drilling down.",
-        expectedUiState: "752 parts reported. Every card is a single part; no classification group appears.",
-        expectedData: { partsTotal: 752, classificationNodesShown: 0 },
+        expectedBehaviour: "BEFORE the first fix: the tabs were All / Categories / Brands, and 'All' was the DEFAULT — it is what rendered the 1,185 rows. BEFORE this one: a fifth 'Parts' tab listed all 752 part leaves flat, duplicating /parts and the spares listing type with a worse version of both. AFTER: four tabs, no 'All' and no 'Parts'. The part leaves still exist and are still reached by drilling into a `*-parts` node; only the flat shortcut tab is gone. The product-level composition tab is untouched — removing that would have deleted the part database's own reason to exist.",
+        expectedUiState: "Four tabs, named exactly as above. No 'All', no 'Parts'. A model listing still shows its composition section.",
+        expectedData: { tabCount: 4, hasAllTab: false, hasPartsTab: false },
         endResult: "Nothing is changed; this case only reads.",
     },
     "checklist-content-discovery-category-tabs-franchise-bundles-tabs-do-not-overlap": {
         roles: ["guest"],
         startPage: "/categories",
         steps: [
-            "Open /categories and note the total each of the five tabs reports: Categories, Brands, Franchises, Parts, Bundles.",
-            "Expect 6, 28, 8, 752, 5.",
+            "Open /categories and note the total each of the four tabs reports: Categories, Brands, Franchises, Bundles.",
+            "Expect 6, 28, 8, 5.",
             "Pick one brand by name on the Brands tab — for example Takara-Tomy.",
-            "Open each of the other four tabs and search for that same name.",
+            "Open each of the other three tabs and search for that same name.",
             "Answer no if it appears on any tab other than Brands.",
             "Repeat once with a bundle name taken from the Bundles tab.",
         ],
         expectedBehaviour: "Brands, franchises and bundles are all tier-0 rows, so a predicate that tested the tier before the discriminator would list every one of them under Categories as well. The type check has to come first. A row on two tabs double-counts the catalogue and makes the totals unreadable.",
-        expectedUiState: "Tab totals read 6 / 28 / 8 / 752 / 5. The sampled brand and bundle each appear on exactly one tab.",
-        expectedData: { categories: 6, brands: 28, franchises: 8, parts: 752, bundles: 5 },
+        expectedUiState: "Tab totals read 6 / 28 / 8 / 5. The sampled brand and bundle each appear on exactly one tab.",
+        expectedData: { categories: 6, brands: 28, franchises: 8, bundles: 5 },
         endResult: "Nothing is changed; this case only reads.",
     },
     "checklist-content-discovery-category-tabs-franchise-bundles-franchise-index-hides-unstocked": {
@@ -149,4 +138,37 @@ export const authored = {
         expectedData: { bundleCards: 5, cardsWithCollage: 5 },
         endResult: "Nothing is changed; this case only reads.",
     },
+    "checklist-content-discovery-category-tabs-franchise-bundles-tabs-collapse-on-narrow-viewport": {
+        roles: ["guest"],
+        startPage: "/categories",
+        steps: [
+            "Resize the viewport to a phone width, around 390px.",
+            "Open /categories.",
+            "Look at the tab row reading Categories / Brands / Franchises / Bundles.",
+            "BEFORE a fix landed 2026-10-19: this was a plain row of `<Button variant=\"ghost\">`s with a hand-written underline — no `role=\"tablist\"`, no overflow handling, and on a narrow viewport the later tabs ran past the right edge with no scrollbar and no visible way to reach them.",
+            "AFTER: the row is `<OverflowRow>`. Confirm it has collapsed into a single trigger button showing the active tab's name plus a chevron.",
+            "Click the trigger. Confirm a searchable dropdown opens listing all four tabs.",
+            "Pick a different tab from the dropdown and confirm the page re-filters to it.",
+        ],
+        expectedBehaviour: "A row of controls that does not fit its container must become a trigger that opens a searchable list, not a row the visitor has to discover can be scrolled. `<OverflowRow>` is the one primitive this project built for exactly this shape (see CLAUDE.md § Overflowing Pill & Tab Rows) — the old row predates it and was never migrated. 🛑 Four tabs can still overflow 390px: the threshold is MEASURED width, never a count (that is why `TabsList`'s old `items.length > 5` rule was deleted), so dropping the fifth tab does not retire this case.",
+        expectedUiState: "At 390px: one trigger button, not four separate tab buttons. Opening it shows all four tabs in a dropdown, each clickable, with the active one marked.",
+        expectedData: { tabsVisibleAsRowAt390px: false, collapsedTriggerPresent: true },
+        endResult: "Nothing is changed; this case only reads.",
+    },
+    "checklist-content-discovery-category-tabs-franchise-bundles-tabs-hover-changes-ink": {
+        roles: ["guest"],
+        startPage: "/categories",
+        steps: [
+            "Open /categories on a desktop-width viewport (at least 1024px, so the tabs render as a row rather than a collapsed trigger).",
+            "Pick a tab that is NOT currently active.",
+            "BEFORE a fix landed 2026-10-19: this row (and several others — the notification bell, the admin sidebar/nav/header, the mobile bottom-nav item) carried two competing `hover:text-*` classes on one element, one of which resolved to the element's own RESTING colour. Hovering therefore changed nothing, which reads as 'hover is broken' rather than as a styling bug.",
+            "Hover the mouse pointer over the inactive tab's label without clicking.",
+            "Compare its text colour before and during the hover.",
+            "Move the pointer away and confirm the colour returns to the resting shade.",
+        ],
+        expectedBehaviour: "Every hover state must visibly differ from the resting state. A hover ink that equals the resting ink is indistinguishable from no hover handler at all.",
+        expectedUiState: "The inactive tab's text colour visibly changes while hovered, and reverts when the pointer leaves.",
+        expectedData: { hoverChangesTextColor: true },
+        endResult: "Nothing is changed; this case only reads.",
+    },
 };

package/dist/features/tester/seed-data/authored/content-discovery__parts-database.js

@@ -36,12 +36,13 @@ export const authored = {
         startPage: "/parts",
         steps: [
             "Open /parts.",
+            "Confirm the page heading reads 'Beyblade parts gallery'.",
             "Count the classification tiles.",
             "Confirm every tile reads as a part NAME in sentence case — 'Performance Tip', 'Fusion Wheel', 'Bit Chip' — and not as a URL slug like 'performance-tip' or 'bit-chip'.",
             "Open any one tile and confirm it loads a page rather than 404ing.",
         ],
-        expectedBehaviour: "BEFORE: there was no parts database at all, so a buyer reading '105RF' on a listing had nowhere to learn that 105 is a spin-track height and RF is a rubber flat tip. AFTER: 20 classifications, each a real page. The labels come from a compile-checked map rather than being title-cased from the slug, because 'Bit Chip' is not 'bit-chip' title-cased and 'Armour' is not 'armour'.",
-        expectedUiState: "Exactly 20 tiles, each labelled in sentence case, each a working link.",
+        expectedBehaviour: "BEFORE: there was no parts reference at all, so a buyer reading '105RF' on a listing had nowhere to learn that 105 is a spin-track height and RF is a rubber flat tip. AFTER: 20 classifications, each a real page, under the heading 'Beyblade parts gallery'. The labels come from a compile-checked map rather than being title-cased from the slug, because 'Bit Chip' is not 'bit-chip' title-cased and 'Armour' is not 'armour'.",
+        expectedUiState: "The heading reads 'Beyblade parts gallery'. Exactly 20 tiles, each labelled in sentence case, each a working link.",
         expectedData: { classificationTiles: 20 },
         endResult: "Nothing is changed; this case only reads.",
     },

package/dist/features/tester/seed-data/authored/content-discovery__price-index-and-compare.d.ts

@@ -0,0 +1,2 @@
+import type { AuthoredCase } from "./_types";
+export declare const authored: Record<string, AuthoredCase>;

package/dist/features/tester/seed-data/authored/content-discovery__price-index-and-compare.js

@@ -0,0 +1,73 @@
+/*
+ * WHY: Authored six-part procedures for the two Wave-11 adoptions —
+ *      price-index local resolution and the compare overlay's new
+ *      "add another" typeahead.
+ * WHAT: 4 case(s), keyed by full checklist id.
+ *
+ * @tag domain:tester
+ * @tag layer:seed
+ * @tag pattern:none
+ * @tag access:server-only
+ * @tag consumers:seed-data/authored/index.ts
+ * @tag sideEffects:none
+ */
+export const authored = {
+    "checklist-content-discovery-price-index-tool-price-index-resolves-locally": {
+        roles: ["guest"],
+        startPage: "/tools/price-index",
+        steps: [
+            "Open /tools/price-index in a private window and open DevTools → Network.",
+            "Clear the network log.",
+            "Type a real model name into the search box and submit.",
+            "Read the network log for what fired.",
+            "Read the results on the page.",
+        ],
+        inputs: { query: "Dragoon G" },
+        expectedBehaviour: "The query-to-leaf resolution step runs in the browser against the local search artifact, at zero Firestore reads — before this, it was a searchTxt push-down query on every submit. The server is now asked only for the sale bands of the already-resolved id(s).",
+        expectedUiState: "The network log shows the one-time artifact fetch (a .json, if not already cached from an earlier visit) plus exactly one request to a bands endpoint carrying resolved id(s) — not a raw free-text query parameter. The page shows real min/median/mean/max figures for a model with recorded sales.",
+        endResult: "Read-only; nothing persists.",
+    },
+    "checklist-content-discovery-price-index-tool-price-index-falls-back-when-index-off": {
+        roles: ["admin"],
+        startPage: "/tools/price-index",
+        steps: [
+            "Sign in as admin and flip siteSettings.search.indexEnabled to false (via Firestore console or an admin settings surface, if one exists for it).",
+            "Open /tools/price-index in a private window.",
+            "Search a real model name and submit.",
+            "Read the results.",
+            "Restore the flag to true afterwards.",
+        ],
+        needsReview: true,
+        reviewNote: "Needs the kill switch flipped off to observe the fallback path, which an ordinary run never exercises — flagged for a human or an admin-tooling pass.",
+        expectedBehaviour: "With the index unavailable, the tool must fall back to the original query-based endpoint rather than going blank. The fallback pays a real Firestore query, which is the accepted cost of the flag being off.",
+        expectedUiState: "The same real sale figures appear as when the index is on — slower, possibly, but not absent.",
+        endResult: "Restore siteSettings.search.indexEnabled to true before ending the session.",
+    },
+    "checklist-content-discovery-compare-overlay-add-item-compare-add-another-via-typeahead": {
+        roles: ["guest"],
+        startPage: "/products",
+        steps: [
+            "Open /products and select one item for comparison (checkbox).",
+            "Open the compare overlay.",
+            "Find the 'Add another to compare' box inside the overlay.",
+            "Type a different product's name and read the suggestions.",
+            "Click one.",
+            "Read the overlay's columns.",
+        ],
+        expectedBehaviour: "Before this, the only way to add an item was selecting it via a listing-page checkbox BEFORE opening the overlay — there was no way to add a further item once inside it. The typeahead resolves a slug locally and the overlay fetches that product the same way it already fetches checkbox-selected ones.",
+        expectedUiState: "A new column appears for the picked item — its image, price and specs — without closing the overlay or returning to the grid. The originally-selected item's column is still there.",
+        endResult: "Close the overlay; nothing persists.",
+    },
+    "checklist-content-discovery-compare-overlay-add-item-compare-add-hidden-at-column-limit": {
+        roles: ["guest"],
+        startPage: "/products",
+        steps: [
+            "Open /products and select items for comparison until the compare overlay's maximum column count is reached (checkboxes, then the typeahead if room remains).",
+            "Open or stay in the overlay once full.",
+            "Look for the 'Add another to compare' box.",
+        ],
+        expectedBehaviour: "A picker that cannot actually add anything because the overlay is full is worse than an absent one — it invites a click that does nothing.",
+        expectedUiState: "The 'Add another' box is completely ABSENT once the column limit is reached, not merely disabled or greyed out.",
+        endResult: "Close the overlay; nothing persists.",
+    },
+};

package/dist/features/tester/seed-data/authored/content-discovery__site-wide-index.d.ts

@@ -0,0 +1,2 @@
+import type { AuthoredCase } from "./_types";
+export declare const authored: Record<string, AuthoredCase>;

package/dist/features/tester/seed-data/authored/content-discovery__site-wide-index.js

@@ -0,0 +1,340 @@
+/*
+ * WHY: Authored six-part procedures for the site-wide search index cases
+ *      added 2026-10-19 to the content-discovery/search page.
+ * WHAT: 17 case(s), keyed by full checklist id.
+ *
+ * 🛑 EVERY CASE CARRIES A CONTROL. A search box that has stopped filtering
+ * returns plausible rows for any real term and looks identical to one that
+ * works — "zzzznope" returning zero is the only kind of assertion here that
+ * cannot pass by accident. That is this directory's standing rule and it is
+ * why the control is a STEP, not a footnote.
+ *
+ * 🛑 Several of these check the NETWORK PANEL rather than the page, and that
+ * is deliberate. "Zero Firestore reads per keystroke" and "a guest issues no
+ * authenticated request" are the two claims the whole design rests on, and
+ * neither is visible on screen — a page that fetches per keystroke looks
+ * exactly like one that does not.
+ *
+ * @tag domain:tester
+ * @tag layer:seed
+ * @tag pattern:none
+ * @tag access:server-only
+ * @tag consumers:seed-data/authored/index.ts
+ * @tag sideEffects:none
+ */
+export const authored = {
+    "checklist-content-discovery-search-search-finds-every-type": {
+        roles: ["guest"],
+        startPage: "/",
+        steps: [
+            "Open / in a private window with no session.",
+            "Click the header search and type dranzer.",
+            "Press Enter.",
+            "Read the URL in the address bar.",
+            "Count how many distinct section headings the results page shows.",
+            "Go back, type zzzznope, and press Enter.",
+            "Read what the page says.",
+        ],
+        inputs: { query: "dranzer", control: "zzzznope" },
+        expectedBehaviour: "Submitting navigates to the cross-resource results page and searches every indexed type at once, rather than redirecting to one browse route chosen by the type dropdown.",
+        expectedUiState: "The URL is /search?q=dranzer, not /products?q=dranzer. Results appear under several headings (for example Products, Categories, Parts, Articles), each with its own 'See all … →' link. For zzzznope the page says nothing matched and shows ZERO result rows — that control is the only assertion here that cannot pass by accident.",
+        endResult: "Read-only; nothing persists.",
+    },
+    "checklist-content-discovery-search-search-finds-a-part": {
+        roles: ["guest"],
+        startPage: "/search",
+        steps: [
+            "Open /search?q=Rubber Flat in a private window.",
+            "Read every result row and note which section each sits under.",
+            "Change the query to RF and search again.",
+            "Compare the two result sets.",
+            "Click the part row and read the page it lands on.",
+        ],
+        inputs: { byName: "Rubber Flat", byCode: "RF" },
+        expectedBehaviour: "Parts are searchable by full name and by code. Before this they had no search tokens at all — all 752 were reachable only by drilling /parts into a classification and then a code.",
+        expectedUiState: "Both queries return the part under a Parts heading, and the row shows its classification on a second line underneath the name. Clicking it lands on a real /parts/<classification>/<code> page, not a 404.",
+        endResult: "Read-only; nothing persists.",
+    },
+    "checklist-content-discovery-search-search-ambiguous-part-code": {
+        roles: ["guest"],
+        startPage: "/search",
+        steps: [
+            "Open /search?q=105 in a private window.",
+            "Count the rows under the Parts heading.",
+            "Read the second line of each row and write down the classification it names.",
+            "Click two different rows in turn and write down the URL each lands on.",
+        ],
+        inputs: { query: "105" },
+        expectedBehaviour: "A bare code is ambiguous across generations — 105 is a Metal Fight spin-track height while a bare number in Burst is a disc — so the engine must return all of them rather than picking one.",
+        expectedUiState: "SEVERAL rows, each naming a DIFFERENT classification, each linking to a different /parts/<classification>/105 URL. Exactly one row is the FAILURE: it means something chose a winner for the user.",
+        endResult: "Read-only; nothing persists.",
+    },
+    "checklist-content-discovery-search-search-midword": {
+        roles: ["guest"],
+        startPage: "/search",
+        steps: [
+            "Open /search?q=ariza in a private window.",
+            "Read the result rows.",
+            "Change the query to zzzz and search again.",
+            "Read what the page says.",
+        ],
+        inputs: { midword: "ariza", control: "zzzz" },
+        expectedBehaviour: "The browser scans the whole index, so a fragment from the MIDDLE of a word matches. The Firestore path structurally cannot do this — its tokens are word-prefix only.",
+        expectedUiState: "'ariza' returns Charizard rows. 'zzzz' returns nothing — without that control a matcher returning everything for any fragment would also pass the first half.",
+        endResult: "Read-only; nothing persists.",
+    },
+    "checklist-content-discovery-search-search-typo": {
+        roles: ["guest"],
+        startPage: "/search",
+        steps: [
+            "Open /search?q=dragon g in a private window.",
+            "Read the result rows.",
+            "Search again for Pegasis (note the spelling: 'sis', not 'sus').",
+            "Read the result rows.",
+        ],
+        inputs: { typo1: "dragon g", typo2: "Pegasis" },
+        expectedBehaviour: "Misspellings are expanded at INDEX time from a crawl of a counterfeit seller's real titles, on the measured insight that an evasion spelling is the same string a genuine buyer mistypes.",
+        expectedUiState: "'dragon g' returns Dragoon G. 'Pegasis' returns Storm Pegasus. Neither returns an empty state.",
+        endResult: "Read-only; nothing persists.",
+    },
+    "checklist-content-discovery-search-search-normalised-away": {
+        roles: ["guest"],
+        startPage: "/search",
+        steps: [
+            "Open /search?q=!!! in a private window.",
+            "Read the message on the page word for word.",
+            "Count the result rows.",
+            "Now search zzzznope and read that message too.",
+            "Compare the two messages.",
+        ],
+        inputs: { punctuation: "!!!", nonsense: "zzzznope" },
+        expectedBehaviour: "A query that normalises to no searchable words must return NOTHING, never everything. The inverse of this bug shipped on /api/products once: a punctuation-only query produced no filter clause and returned the entire published catalogue as search results.",
+        expectedUiState: "'!!!' says the search had no searchable words in it. 'zzzznope' says nothing matched. The two messages are DIFFERENT — one means we could not form a query, the other means we ran one and found none. Any rows at all for '!!!' is the failure.",
+        endResult: "Read-only; nothing persists.",
+    },
+    "checklist-content-discovery-search-search-zero-reads": {
+        roles: ["guest"],
+        startPage: "/",
+        steps: [
+            "Open / in a private window and open DevTools → Network.",
+            "Clear the network log.",
+            "Click into the header search and type d.",
+            "Wait for suggestions to appear, then type r, a, n, z, e, r one character at a time.",
+            "Read the network log and count the requests made after the first one.",
+        ],
+        inputs: { query: "dranzer" },
+        expectedBehaviour: "The index is fetched ONCE per page session and searched locally thereafter. Before this, every keystroke was a request to /api/search/suggestions, which was four parallel Firestore reads.",
+        expectedUiState: "The log shows ONE large .json fetch from firebasestorage (a few hundred KB) on the first focus or keystroke, and NOTHING further as you keep typing. A request per character is the failure even though the suggestions look identical either way.",
+        endResult: "Read-only; nothing persists.",
+    },
+    "checklist-content-discovery-search-search-no-prices": {
+        roles: ["guest"],
+        startPage: "/",
+        steps: [
+            "Open / in a private window with no session.",
+            "Click the header search and type dranzer.",
+            "Read every suggestion row, including the small second line.",
+            "Press Enter and read every row on the results page.",
+            "Search the rendered page for the ₹ character.",
+        ],
+        inputs: { query: "dranzer" },
+        expectedBehaviour: "Prices are hidden from signed-out visitors so the catalogue cannot be read at scale without an account. The suggestion subtitle used to be the product's price, served from a route cached PUBLIC for 60 seconds — a live leak on every page of the site.",
+        expectedUiState: "Suggestion subtitles show the brand and category, e.g. 'Takara-Tomy · Attack Rings'. No ₹ appears anywhere in the dropdown or in the results, signed out.",
+        endResult: "Read-only; nothing persists.",
+    },
+    "checklist-content-discovery-search-search-no-sandbox": {
+        roles: ["guest"],
+        startPage: "/search",
+        steps: [
+            "Open /search?q=sandbox in a private window with no session.",
+            "Read every result row.",
+            "Search again for tester and read every row.",
+            "Note any row whose title or detail names a tester or sandbox fixture.",
+        ],
+        inputs: { query1: "sandbox", query2: "tester" },
+        expectedBehaviour: "The index is ONE shared file every browser downloads, with no per-viewer filter anywhere after it is built — so a test-data row in it is published to the world for that version's whole lifetime, and an immutable object cannot be recalled.",
+        expectedUiState: "No row seeded as test data appears. Finding even one is a disclosure, not a cosmetic issue.",
+        endResult: "Read-only; nothing persists.",
+    },
+    "checklist-content-discovery-search-search-freshness": {
+        roles: ["seller"],
+        startPage: "/store/products/new",
+        steps: [
+            "Create and PUBLISH a listing with a distinctive title, e.g. Freshness Probe Dranzer.",
+            "Write down the time.",
+            "Open /search in a private window and search that exact title.",
+            "If it is absent, wait and retry every few minutes for up to 20 minutes.",
+            "Once it appears, go back and UNPUBLISH the listing.",
+            "Search the same title again, retrying for up to 20 minutes.",
+        ],
+        inputs: { title: "Freshness Probe Dranzer" },
+        expectedBehaviour: "A content write marks the index stale and the scheduled job rebuilds within about 15 minutes. An unpublished listing still has a fresh updatedAt, so the incremental pass re-reads it, sees it fail the published filter, and removes it.",
+        expectedUiState: "The listing becomes findable within ~15 minutes of publishing and disappears within ~15 minutes of unpublishing. A row that NEVER appears and a row that never LEAVES are both failures, and both mean the rebuild has stopped — note which one you saw.",
+        endResult: "Delete the probe listing afterwards. Its absence from search within ~15 minutes is itself the final check.",
+    },
+    "checklist-content-discovery-search-search-facet-counts": {
+        roles: ["guest"],
+        startPage: "/search",
+        steps: [
+            "Open /search?q=beyblade in a private window.",
+            "Find the facet chips above the results and write down each chip's label and number.",
+            "Count the result rows actually shown for one type and compare it with that chip's number.",
+            "Click one chip.",
+            "Read the result rows again, and read the other chips' numbers again.",
+            "Click the same chip a second time to clear it.",
+        ],
+        inputs: { query: "beyblade" },
+        expectedBehaviour: "Facet counts are computed over the hits the current query produced, in memory. The Firestore path cannot afford this — it is one aggregation query per facet value, each needing its own composite index, and it returns no count at all when an index is missing.",
+        expectedUiState: "Chips show a number each. Clicking one narrows the results AND lowers the other chips' numbers to match. Clicking again restores both. A chip that does not change the results, or a number that disagrees with the rows you can count, is the failure.",
+        endResult: "Read-only; the selection is not persisted and is gone on reload.",
+    },
+    "checklist-content-discovery-search-search-guest-no-private": {
+        roles: ["guest"],
+        startPage: "/search",
+        steps: [
+            "Open a private window with no session and open DevTools → Network.",
+            "Clear the network log.",
+            "Go to /search?q=order.",
+            "Read every request in the log.",
+            "Look specifically for any request whose path contains /api/search/scoped.",
+            "Read the page for any section headed 'Your …' or 'Admin'.",
+        ],
+        inputs: { query: "order" },
+        expectedBehaviour: "A signed-out visitor must make NO authenticated request at all — not a 401, not an empty 200. The client gate, the route's auth requirement and the empty source list are three independent gates, because the expensive failure is not a guest seeing an error, it is a guest silently receiving someone's data.",
+        expectedUiState: "No /api/search/scoped request appears in the log in any form. No account or admin section renders on the page. A 401 in the log is still a FAIL — it means the request was issued.",
+        endResult: "Read-only; nothing persists.",
+    },
+    "checklist-content-discovery-search-search-buyer-isolation": {
+        roles: ["buyer"],
+        startPage: "/search",
+        steps: [
+            "Sign in as one buyer.",
+            "From an admin session in another browser, find a DIFFERENT buyer's order and note a distinctive word from its product title.",
+            "Back in the first buyer's session, search that word on /search.",
+            "Read every row, including any under 'Your orders'.",
+            "Now open /api/search/scoped?q=<that word> directly in the same signed-in session.",
+            "Read the raw JSON response end to end.",
+        ],
+        expectedBehaviour: "Every scoped source carries an owner clause built from the verified session, so the QUERY itself cannot return another viewer's rows. The API half of this check is the half that matters.",
+        expectedUiState: "Neither the page nor the JSON contains the other buyer's order. A page that hides the row while the endpoint returns it is precisely the failure this case exists for, and only the second half can see it.",
+        endResult: "Read-only; nothing persists.",
+    },
+    "checklist-content-discovery-search-search-seller-own-store": {
+        roles: ["seller"],
+        startPage: "/store/products/new",
+        steps: [
+            "Signed in as a seller, create a listing with a distinctive title and leave it as a DRAFT.",
+            "Go to /search and search that title.",
+            "Read which section the row appears under.",
+            "Note a draft title belonging to a DIFFERENT store (ask an admin for one).",
+            "Search that second title and read every row.",
+        ],
+        inputs: { ownDraft: "Isolation Probe Draft" },
+        expectedBehaviour: "A seller's own drafts are returned by the scoped tier. Published listings are deduped away because the public index already has them, so what survives in that section is exactly the drafts — which is why it is labelled as such.",
+        expectedUiState: "Your own draft appears under 'Your listings (incl. drafts)'. The other store's draft returns nothing at all.",
+        endResult: "Delete the probe draft afterwards.",
+    },
+    "checklist-content-discovery-search-search-listing-boxes-still-filter": {
+        roles: ["guest", "seller", "admin"],
+        startPage: "/stores",
+        steps: [
+            "Open /stores and type a real store name into the page's own search box.",
+            "Confirm the list narrows, then type zzzznope and confirm it empties.",
+            "Sign in as a seller, open /store/orders, and repeat both searches there.",
+            "Check the pager still works and the filter-drawer badge still shows the right count.",
+            "Sign in as an admin, open /admin/users, and repeat both searches there.",
+        ],
+        inputs: { control: "zzzznope" },
+        expectedBehaviour: "The per-collection boxes are a DIFFERENT system from site-wide search — they filter one table, carry URL state and feed real pagination — and nothing in the index work touches them. This case exists because that is a promise, and a promise with no check is a hope.",
+        expectedUiState: "All three boxes narrow on a real term and return zero on the control. Pagination still pages, and the filter-drawer badge still counts only drawer filters.",
+        endResult: "Read-only; the URL carries the query but nothing persists server-side.",
+    },
+    "checklist-content-discovery-search-search-support-ticket-two-words": {
+        roles: ["admin"],
+        startPage: "/admin/support-tickets",
+        steps: [
+            "Open /admin/support-tickets and read several ticket subjects.",
+            "Pick TWO words that appear together in exactly one subject, where the longer word also appears in others.",
+            "Type just the longer word into the search box and count the rows.",
+            "Now type both words and count the rows again.",
+            "Compare the two counts.",
+        ],
+        expectedBehaviour: "Both words must narrow the result. Before this the second word was discarded entirely — only the longest term reached the query — so a two-word search returned everything matching the longer word while looking like it was working.",
+        expectedUiState: "The two-word search returns FEWER rows than the one-word search, and every row it returns contains both words. Identical counts mean the second word is still being thrown away.",
+        endResult: "Read-only; nothing persists.",
+    },
+    "checklist-content-discovery-search-search-parts-page-has-a-box": {
+        roles: ["guest"],
+        startPage: "/parts",
+        steps: [
+            "Open /parts in a private window.",
+            "Look above the grid of classifications for a search input.",
+            "Type RF and read the rows that appear.",
+            "Read the second line of each row.",
+            "Clear it and type zzzznope.",
+            "Scroll down and confirm the classification grid is still present.",
+        ],
+        inputs: { query: "RF", control: "zzzznope" },
+        expectedBehaviour: "Before this the page was browse-only: 752 parts reachable only by clicking a classification and then a code, with no search input anywhere on the surface.",
+        expectedUiState: "A search box sits above the grid. 'RF' returns the part with its classification on a second line; 'zzzznope' says no part matches. The classification grid is still there underneath — the box adds a way in, it does not replace browsing.",
+        endResult: "Read-only; nothing persists.",
+    },
+    "checklist-content-discovery-search-search-facet-carries-through": {
+        roles: ["guest"],
+        startPage: "/search",
+        steps: [
+            "Open /search?q=beyblade in a private window.",
+            "Tick one facet chip, e.g. a brand.",
+            "Find that group's own 'See all →' link and read its href before clicking.",
+            "Click it.",
+            "Read the URL you land on and whether the listing page shows the same filter applied.",
+        ],
+        inputs: { query: "beyblade" },
+        expectedBehaviour: "The refinement a visitor builds on /search must survive the jump to the real browse page — losing it means re-doing work they already did.",
+        expectedUiState: "The destination URL carries the same filter (e.g. a brand query parameter), and the browse page opens already narrowed to it, not showing the unfiltered full list.",
+        endResult: "Read-only; nothing persists.",
+    },
+    "checklist-content-discovery-search-search-admin-person-exact": {
+        roles: ["admin"],
+        startPage: "/admin/users",
+        steps: [
+            "Sign in as admin and open /admin/users.",
+            "Pick a real user and note their first name only.",
+            "Type just that first name into the search box.",
+            "Read the results.",
+            "Clear the box and type only the first 3-4 letters of that same first name — a prefix, not the whole word.",
+            "Read the results again.",
+        ],
+        expectedBehaviour: "The admin search resolves through a whole-WORD index, not a whole-STRING exact match. Typing a first name alone must find a user whose displayName is 'First Last' — before this it required the exact full string. A PREFIX of the word must find nobody: the index is whole-word only on purpose, so it cannot be unpicked by counting partial-match frequencies.",
+        expectedUiState: "The full first name returns the user. The 3-4 letter prefix returns an empty list — not the same user, not anybody else.",
+        endResult: "Read-only; nothing persists.",
+    },
+    "checklist-content-discovery-search-search-no-plaintext-pii": {
+        roles: ["admin"],
+        startPage: "/admin/users",
+        steps: [
+            "With Firestore console access, open any `users` document.",
+            "Find the `nameTokensIndex` field and read its values.",
+            "Confirm every entry is an opaque hex string with an `hmac:` prefix, never a readable name fragment.",
+            "Separately, fetch the public search artifact's .json file (the one the header search downloads) and search its raw text for the word 'TokensIndex'.",
+        ],
+        needsReview: true,
+        reviewNote: "Needs Firestore console access, which an automated browser session does not have — flagged for a human or an admin-tooling pass rather than answered null.",
+        expectedBehaviour: "A blind index lets admin search without ever decrypting anyone's name. If the stored values are readable, or if the field reaches the public artifact (a deterministic per-person identifier published to every browser, cross-referenceable even unbroken), the whole design has failed regardless of what the UI shows.",
+        expectedUiState: "Every `nameTokensIndex` entry is an `hmac:`-prefixed digest. The public artifact's raw text contains no occurrence of 'TokensIndex' at all.",
+        endResult: "Read-only; nothing persists.",
+    },
+    "checklist-content-discovery-search-faq-punctuation-search": {
+        roles: ["guest"],
+        startPage: "/faqs",
+        steps: [
+            "Open /faqs in a private window.",
+            "Type !!! into the FAQ search box.",
+            "Read the message shown and count the FAQs displayed.",
+        ],
+        inputs: { punctuation: "!!!" },
+        expectedBehaviour: "GUARD CASE — pins behaviour that is already correct. A punctuation-only query has no searchable words, and must say so rather than silently falling through to 'no filter', which would return the entire FAQ catalogue disguised as search results.",
+        expectedUiState: "The page says the search had no searchable words. Zero FAQs are shown — not the full list.",
+        endResult: "Read-only; nothing persists.",
+    },
+};