@mohasinac/appkit 4.58.0 → 4.60.0

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

@@ -1,110 +0,0 @@
-/*
- * WHY: Authored six-part procedures for the content-discovery/blog page.
- * WHAT: 5 case(s), keyed by full checklist id.
- *
- * Written by hand, case by case, against the label each one states. There is no
- * generator: the authoring scripts were deleted once it was clear they were
- * scaffolding around work that is simply writing.
- *
- * Blog posts have no gallery field, so extra images live inline in the content
- * HTML — a case looking for a separate image array is looking for something the
- * document has never had.
- *
- * @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-blog-blog-listing": {
-        roles: ["guest"],
-        startPage: "/blog",
-        steps: [
-            "Open /blog in a private window with no session.",
-            "Read every card — title, excerpt, cover image, category and read time.",
-            "Note whether any card names a draft or archived post.",
-            "Use the category filter, selecting each value in turn, and read the results.",
-            "Page to the end of the list.",
-        ],
-        expectedBehaviour: "The listing shows published posts only. The seed holds 17 published, 2 draft and 1 archived, so a listing showing 20 is not filtering by status at all — and status filtering is the kind of guard that gets dropped when a route stops sending a parameter the query only applied when asked.",
-        expectedUiState: "Every card carries a title, an excerpt, a rendered cover image and a category. No draft or archived post appears. Each category filter value returns rows or a named empty state.",
-        expectedData: { draftPostsVisible: 0 },
-        endResult: "Read-only; nothing persists beyond the URL.",
-    },
-    "checklist-content-discovery-blog-read-post": {
-        roles: ["guest"],
-        startPage: "/blog",
-        steps: [
-            "Open /blog in a private window and click the first post.",
-            "Read the title, author, publish date and read time.",
-            "Read the whole article body, checking the paragraphs and any inline images render.",
-            "Read the address bar and note whether the URL uses the post's slug.",
-            "Reload the page.",
-        ],
-        expectedBehaviour: "A post renders its stored HTML content, including the images embedded inline within it. The route is keyed on slug, so the URL is stable and shareable.",
-        expectedUiState: "Title, author, date and read time are shown. The body renders as formatted prose with its inline images displayed — not as raw HTML tags shown as visible text, and not as a wall of markup. The URL carries the post's slug.",
-        endResult: "Read-only; nothing persists. The reload shows the same article.",
-    },
-    "checklist-content-discovery-blog-blog-cover-image-display": {
-        roles: ["guest"],
-        startPage: "/blog",
-        steps: [
-            "Open /blog in a private window and look at every card's cover image.",
-            "Hard-reload with Ctrl+Shift+R and look again.",
-            "Open one post and look at its cover image at the top of the article.",
-            "Note whether the same image appears on the card and on the post.",
-            "Look for any broken-image glyph or grey placeholder tile.",
-        ],
-        expectedBehaviour: "Cover images are served through the media proxy, which is what applies the watermark and keeps the storage bucket private. An image stored as a raw bucket URL bypasses that entirely and is the pattern to watch for.",
-        expectedUiState: "Every card shows its cover image, on both loads. The post's hero image matches its card's. No broken-image glyph and no grey placeholder square anywhere.",
-        endResult: "Read-only; nothing persists.",
-    },
-    "checklist-content-discovery-blog-blog-youtube-embed": {
-        roles: ["guest"],
-        startPage: "/blog",
-        steps: [
-            "Open /blog/selling-tips-letitrip in a private window — '10 Tips to Sell Faster on LetItRip' is the ONLY seeded post carrying a youtubeId, so searching the listing for a video indicator finds nothing and a tester would answer null on a path that works.",
-            "Scroll to the embedded video.",
-            "Click play and watch for a few seconds.",
-            "Read any error text shown in or near the player.",
-        ],
-        expectedBehaviour: "A YouTube id on a post renders as a privacy-preserving embed. The failure worth naming is the one the product-detail pages had: a YouTube URL handed to a native video element, which cannot play a watch-page URL and says so in the player's own words.",
-        expectedUiState: "The embedded player renders and plays on click. What must not appear is 'No video with supported format and MIME type found', an empty black box, or a bare link where a player should be.",
-        endResult: "Read-only; nothing persists.",
-    },
-    "checklist-content-discovery-blog-blog-related-posts-sections": {
-        roles: ["guest"],
-        startPage: "/blog",
-        steps: [
-            "Open /blog in a private window and open any post.",
-            "Scroll below the article body.",
-            "Read the heading of each related section and the cards inside it.",
-            "Check whether the post currently open appears in any of them.",
-            "Click a card in each section and confirm it opens that post.",
-        ],
-        expectedBehaviour: "Three separate signals are rendered below the article — same category, shared tags, and same author — each as its own section. A section with a heading and an empty rail should not render at all; showing the heading anyway advertises content that is not there.",
-        expectedUiState: "Three headed sections appear: Related Posts, 'You might also like', and a same-author section. Each holds at least one card with a real title and image. The current post appears in none of them, and every card opens the post it names.",
-        expectedData: { selfLinkCount: 0 },
-        endResult: "Read-only; nothing persists.",
-    },
-    "checklist-content-discovery-blog-blog-search-filters-the-list": {
-        roles: ["guest"],
-        startPage: "/blog",
-        steps: [
-            "Open /blog in a private window with no session and count the posts listed.",
-            "Type beyblade into the search box ('Search posts...') and commit the search.",
-            "Read the count and confirm it is SMALLER than the unfiltered count, and that every remaining card is relevant.",
-            "Clear the box, type zzzznope, and commit.",
-            "Read the result — an empty state, not the full list.",
-            "RELOAD the page while zzzznope is still in the URL and read the FIRST PAINT, before anything settles.",
-            "Clear the search and confirm the original count returns.",
-        ],
-        inputs: { realQuery: "beyblade", nonsenseQuery: "zzzznope" },
-        expectedBehaviour: "The blog listing filters server-side and the filtered result survives a reload. The nonsense control is the whole case: a real term returns plausible cards whether or not the query reached the server, so only zzzznope distinguishes filtering from returning everything. The reload matters separately — the SSR view and the API are two implementations of one query, and when the view ignored `q` the client hook's initialData froze the UNFILTERED list permanently, because a public listing hook sets staleTime Infinity once it is given SSR data. A page that shows the right rows only after a moment is that bug, not a slow render.",
-        expectedUiState: "'beyblade' returns fewer cards than the unfiltered list. 'zzzznope' returns a named empty state and zero cards, on first paint as well as after hydration. Clearing restores the original count.",
-        expectedData: { nonsenseResultCount: 0 },
-        endResult: "Read-only; nothing persists beyond the URL. A full list under zzzznope is the failure, and it is the same shape whether the query never left the browser or the SSR view dropped it.",
-    },
-};

package/dist/features/tester/seed-data/authored/content-discovery__category-brand-relations.d.ts

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

package/dist/features/tester/seed-data/authored/content-discovery__category-brand-relations.js

@@ -1,149 +0,0 @@
-/*
- * WHY: Authored six-part procedures for the content-discovery/category-brand-relations page.
- * WHAT: 8 case(s), keyed by full checklist id.
- *
- * 🛑 THE TWO SIDES OF THE TREE ARE ASYMMETRIC AND THAT ASYMMETRY IS THE POINT.
- *
- * A PRODUCT carries its full ancestor chain, so a category page matches on its own
- * id alone. A STORE carries a single category with no chain, so the store side
- * genuinely needs the descendant list. Reversing either is a real defect that
- * renders as an empty grid: expanding a root into every descendant blows the
- * query's value cap and the throw is swallowed, while NOT expanding the store side
- * hides every store filed below the top tier.
- *
- * Brands are rows in the same collection as categories, discriminated by a type
- * field, and they match products by DISPLAY NAME rather than by id — so renaming a
- * brand silently orphans its catalogue while the page keeps rendering.
- *
- * @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-category-brand-relations-tier-depth-reachable": {
-        roles: ["guest"],
-        startPage: "/categories",
-        steps: [
-            "Open /categories and find Spinning Tops.",
-            "Click into it and read the child categories listed.",
-            "Click Beyblade Burst and read its children.",
-            "Click Burst Parts and read its children.",
-            "Click one of those and note there are no further children.",
-            "Count how many clicks it took to reach the leaf.",
-        ],
-        expectedBehaviour: "Every tier is reachable by clicking, with no typed URLs. A tier that renders but offers no way down is unreachable in practice, which is the same as not existing for anyone browsing.",
-        expectedUiState: "Four levels: Spinning Tops, then Beyblade Burst, then Burst Parts, then a leaf such as Layers or Drivers. Each page lists its own children until the leaf, which lists none.",
-        expectedData: { tiersReached: 4 },
-        endResult: "Read-only.",
-    },
-    "checklist-content-discovery-category-brand-relations-second-root-reachable": {
-        roles: ["guest"],
-        startPage: "/categories",
-        steps: [
-            "Open /categories and read every top-level category shown.",
-            "Check all six roots are present: Spinning Tops, Trading Cards, Collectible Figures, Hot Wheels, Model Kits, Living Collectibles.",
-            "Click Living Collectibles and read its children.",
-            "Click down to a leaf under it.",
-            "Check the leaf lists at least one live-item listing.",
-        ],
-        inputs: { rootA: "category-spinning-tops", rootB: "category-living-collectibles" },
-        expectedBehaviour: "All SIX roots are on the index. The tree had one root and two tiers before it was rebuilt, so the live-item listings carried no category at all and were unreachable from every category and brand page — a whole listing type invisible to browsing while its detail pages worked fine. Living Collectibles is the one to walk, because it is the root whose leaves hold the live-item listings.",
-        expectedUiState: "Six roots on the index, and the Living Collectibles branch walks down to a leaf holding a live listing. A missing root, or a root that leads nowhere, is the finding.",
-        endResult: "Read-only.",
-    },
-    "checklist-content-discovery-category-brand-relations-root-page-shows-descendant-products": {
-        roles: ["guest"],
-        startPage: "/categories/category-spinning-tops",
-        steps: [
-            "Open /categories/category-beyblade-burst and note the title of one product listed there.",
-            "Open /categories/category-spinning-tops.",
-            "Search the listing for that same product.",
-            "Read the product count shown on the root page.",
-            "Compare it against the counts on its four generation children.",
-        ],
-        inputs: { rootId: "category-spinning-tops", childId: "category-beyblade-burst" },
-        expectedBehaviour: "A product carries its FULL ancestor chain, so a root page matches on its own id and needs no descendant expansion. A product visible on a leaf but missing from its root means the chain was not written on the product side — and nothing appends ancestors on write today, so a listing created through the seller form has a single-element chain and is invisible on every ancestor page.",
-        expectedUiState: "The product from the child page also appears on the root page, and the root's count is at least the sum of its children's. A root showing only its own directly-tagged products — normally none — is the finding.",
-        endResult: "Read-only.",
-    },
-    "checklist-content-discovery-category-brand-relations-root-page-not-blank-on-large-tree": {
-        roles: ["guest"],
-        startPage: "/categories/category-spinning-tops",
-        steps: [
-            "Open /categories/category-spinning-tops with the browser console open.",
-            "Read whether the product grid renders rows or is empty.",
-            "Read the console for any error.",
-            "Read the network panel for any failed request.",
-            "Change the sort and read the grid again.",
-            "Page forward once and read it again.",
-        ],
-        inputs: { rootId: "category-spinning-tops" },
-        expectedBehaviour: "The root page renders products. Expanding a root into itself plus every descendant on a fifty-node tree exceeds the query's value cap, the query throws, and every caller wraps that fetch so the failure resolves to nothing — a blank grid with no error in the console, no failed request, and nothing to point at.",
-        expectedUiState: "Rows render on the default view and after a sort change and a page forward, with a clean console. A blank grid is the finding precisely BECAUSE nothing else signals it.",
-        expectedData: { consoleErrors: 0 },
-        endResult: "Read-only.",
-    },
-    "checklist-content-discovery-category-brand-relations-mid-tier-scopes-to-own-subtree": {
-        roles: ["guest"],
-        startPage: "/categories/category-beyblade-burst",
-        steps: [
-            "Open /categories/category-spinning-tops and note its product count.",
-            "Open /categories/category-beyblade-burst and note its count.",
-            "Compare the two.",
-            "Open /categories/category-beyblade-metal and note the title of a product listed there.",
-            "Search for it on the Beyblade Burst page.",
-        ],
-        inputs: { parentId: "category-spinning-tops", childId: "category-beyblade-burst" },
-        expectedBehaviour: "A mid-tier category shows its own subtree only. Equal counts on parent and child mean the scoping is not being applied at all — which reads as a working page right up until somebody notices a Metal Fight product on the Burst page.",
-        expectedUiState: "The child's count is strictly smaller than the parent's, and no Metal Fight product appears on the Burst page. Equal counts, or a sibling's product appearing, are both findings.",
-        endResult: "Read-only.",
-    },
-    "checklist-content-discovery-category-brand-relations-store-under-deep-category-visible-at-root": {
-        roles: ["guest"],
-        startPage: "/categories/category-spinning-tops",
-        steps: [
-            "Open /categories/category-spinning-tops — the ROOT — and open its Stores tab.",
-            "Read every store listed. Four stores carry a storeCategory: store-letitrip-official and store-beyblade-arena at this root, store-blader-bazaar under category-beyblade-burst, and store-vintage-vault-co under category-beyblade-original. All four should appear here, because a store carries a SINGLE category with no ancestor chain, so the root must expand descendants to find the deeper two — the half that once listed direct children only. Note store-blader-bazaar is pending and store-vintage-vault-co suspended, so check whether the tab filters by status before calling a missing one a rollup failure.",
-            "Open /categories/category-beyblade-burst — one level down, and the category store-blader-bazaar is filed under — and open ITS Stores tab.",
-            "Read the stores listed there. Only stores filed at or beneath that category belong; the two filed at the root do not.",
-            "Check every store from the deeper page also appears on the root's tab.",
-        ],
-        inputs: { rootId: "category-spinning-tops" },
-        expectedBehaviour: "A store carries a SINGLE category with no ancestor chain, so the store side genuinely does need the descendant list — the opposite of the product side. It expanded direct children only, so a store filed three tiers down was invisible on its root while its products were not, which is why the two sides look inconsistent when this breaks.",
-        expectedUiState: "Every store on a descendant category's Stores tab also appears on the root's. A store visible deep and absent at the root is the finding, named.",
-        endResult: "Read-only.",
-    },
-    "checklist-content-discovery-category-brand-relations-brand-page-lists-its-products": {
-        roles: ["guest"],
-        startPage: "/brands/brand-takara-tomy",
-        steps: [
-            "Open /brands/brand-takara-tomy and read the brand name in the hero.",
-            "Read the products listed and count them.",
-            "Open one of those products and read the brand named on its detail page.",
-            "Compare that string against the brand page's name, character for character.",
-            "Repeat on /brands/brand-beyblade.",
-        ],
-        inputs: { brandId: "brand-takara-tomy" },
-        expectedBehaviour: "Products are matched to a brand by its DISPLAY NAME, not its id. The two strings must agree exactly, so renaming a brand orphans its entire catalogue — and the page still renders its hero, its editorial panels and an empty grid, with nothing anywhere reporting that a rename caused it.",
-        expectedUiState: "Both brand pages list products, and each listed product's own detail page names the same brand string as the page's title. An empty grid on a brand with known products is the finding.",
-        endResult: "Read-only.",
-    },
-    "checklist-content-discovery-category-brand-relations-brand-and-category-are-one-collection": {
-        roles: ["guest"],
-        startPage: "/brands/brand-takara-tomy",
-        steps: [
-            "Open /brands/brand-takara-tomy and read every panel on the page.",
-            "Note whether an About-this-brand panel with website, country and founding year is present.",
-            "Open /categories/category-beyblade-burst and read every panel there.",
-            "Check no About-this-brand panel appears on the category page.",
-            "Check both pages render their highlights and questions sections, or neither if both are unset.",
-        ],
-        inputs: { brandId: "brand-takara-tomy", categoryId: "category-beyblade-burst" },
-        expectedBehaviour: "A brand and a category are rows in ONE collection distinguished by a type field, so the only thing keeping their pages apart is that each renders the fields belonging to its own kind. Brand-only fields were seeded and accepted by the interface for a long time while nothing rendered them anywhere.",
-        expectedUiState: "The brand page shows website, country and founding year; the category page shows none of them and shows no empty labelled slots for them either.",
-        endResult: "Read-only.",
-    },
-};

package/dist/features/tester/seed-data/authored/content-discovery__category-counts-and-rollup.d.ts

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

package/dist/features/tester/seed-data/authored/content-discovery__category-counts-and-rollup.js

@@ -1,145 +0,0 @@
-/*
- * WHY: Authored six-part procedures for content-discovery/category-counts-and-rollup.
- * WHAT: 8 cases, keyed by full checklist id.
- *
- * 🛑 THE RULE THESE CASES ENCODE: a category's count is its OWN items plus every
- * descendant's, and clicking it must LIST exactly those items. With
- * A → (B, C → D) and own counts A=5, B=5, C=8, D=2, the numbers are D=2, B=5,
- * C=10 and **A=20** — and opening A lists all twenty.
- *
- * Both halves were wrong on 2026-09-14. The nightly reconciler could not express
- * own-vs-rollup at all — `setMetrics` wrote one number to both fields — so it
- * OVERWROTE the live trigger's correct values every night: 19 of 65 rows
- * disagreed with a recount, every one low. And the child chips beneath a
- * category header rendered the OWN count while the header rendered the rollup,
- * so a parent reading 20 could sit above chips summing to 5.
- *
- * Nothing errored in either case. A wrong number is simply a number, which is
- * why every case below compares TWO things that must agree rather than checking
- * that a number is present.
- *
- * @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-category-counts-and-rollup-leaf-count-matches-its-listing": {
-        roles: ["guest"],
-        startPage: "/categories",
-        steps: [
-            "Open /categories.",
-            "Open the tile for x-starters — a leaf with no child chips of its own.",
-            "Write down the count shown on its tile.",
-            "Open that category.",
-            "Count the product cards listed, using the pager total rather than counting by eye if there is more than one page.",
-        ],
-        expectedBehaviour: "A count is a promise about a listing. On a leaf there are no descendants, so the number and the listing are the same set and any difference is a stale counter.",
-        expectedUiState: "The number on the tile equals the number of products the category page lists.",
-        expectedData: { tileCountEqualsListingTotal: true },
-        endResult: "Nothing is changed; this case only reads.",
-    },
-    "checklist-content-discovery-category-counts-and-rollup-parent-count-includes-descendants": {
-        roles: ["guest"],
-        startPage: "/categories",
-        steps: [
-            "Open /categories/category-x-tops — a parent whose children are the four Beyblade X retail lines, category-x-basic, category-x-unique-ux, category-x-custom-cx and category-x-over — every category id carries the `category-` prefix, and a URL without it does not resolve.",
-            "Write down the count on the parent's tile.",
-            "Open the parent and write down the count shown on each of its child chips.",
-            "Add the children's counts together.",
-            "Open the parent's own listing and note whether any product there is filed directly under the parent rather than a child.",
-        ],
-        expectedBehaviour: "The parent's number is its own items plus every descendant's. A parent showing only its own items reports a number smaller than the branch it stands for, and a parent showing only its descendants loses whatever is filed directly under it.",
-        expectedUiState: "The parent's count is greater than or equal to the sum of its children's counts, and equals that sum plus anything filed directly under the parent.",
-        expectedData: { parentCountAtLeastSumOfChildren: true },
-        endResult: "Nothing is changed; this case only reads.",
-    },
-    "checklist-content-discovery-category-counts-and-rollup-parent-listing-includes-descendant-items": {
-        roles: ["guest"],
-        startPage: "/categories",
-        steps: [
-            "Open /categories/category-x-tops.",
-            "Open one of its CHILD categories and write down the title of a product listed there.",
-            "Go back to the parent category's own page.",
-            "Search the parent's listing for that same product, paging through if necessary.",
-        ],
-        expectedBehaviour: "The rule governs the LISTING, not only the number. A count that rolls up while the listing does not is worse than both being wrong together: the page then contradicts itself in a way that reads as a pagination problem.",
-        expectedUiState: "The child's product appears in the parent category's listing.",
-        expectedData: { childProductVisibleOnParent: true },
-        endResult: "Nothing is changed; this case only reads.",
-    },
-    "checklist-content-discovery-category-counts-and-rollup-header-and-child-chips-agree": {
-        roles: ["guest"],
-        startPage: "/categories",
-        steps: [
-            "Open /categories/category-x-tops, a parent that shows a row of child chips — category-x-basic, category-x-unique-ux, category-x-custom-cx and category-x-over.",
-            "Write down the number in the page header.",
-            "Write down the number on each child chip.",
-            "Open one child and compare its own header number to the number its chip showed.",
-        ],
-        expectedBehaviour: "Every number a visitor reads is the same kind of number — the rollup. Showing the rollup in the header and the own-count on the chips answers two different questions with identically-styled figures side by side, and nothing on the screen says which is which.",
-        expectedUiState: "The number on a child's chip equals the number in that child's own page header.",
-        expectedData: { chipMatchesChildHeader: true },
-        endResult: "Nothing is changed; this case only reads.",
-    },
-    "checklist-content-discovery-category-counts-and-rollup-root-count-is-the-whole-subtree": {
-        roles: ["guest"],
-        startPage: "/categories",
-        steps: [
-            "Open /categories/category-spinning-tops — a root category.",
-            "Write down its count.",
-            "Open it and write down the count on each of its direct children.",
-            "Open each child in turn and write down its children's counts, until you reach leaves.",
-            "Add up every leaf's count, plus anything filed directly under an intermediate node.",
-        ],
-        expectedBehaviour: "A root's count is the sum over its whole subtree. This is the case that catches a reconciler summing only ONE level of descendants — it produces a number that is plausible, consistently too low, and never flagged.",
-        expectedUiState: "The root's count equals the total counted across the subtree.",
-        expectedData: { rootCountEqualsSubtreeSum: true },
-        endResult: "Nothing is changed; this case only reads.",
-    },
-    "checklist-content-discovery-category-counts-and-rollup-sibling-isolation": {
-        roles: ["guest"],
-        startPage: "/categories",
-        steps: [
-            "Open /categories/category-x-tops, which has several children.",
-            "Open the first child and write down a product title from its listing.",
-            "Open the second child's listing.",
-            "Search the second child for that product.",
-            "Compare the two children's counts.",
-        ],
-        expectedBehaviour: "Roll-up goes upward only. A product must not be counted in, or listed under, a sibling branch — the failure that produces is a set of counts that all look slightly too large and still sum plausibly.",
-        expectedUiState: "The first child's product is absent from the second child's listing.",
-        expectedData: { productLeakedToSibling: false },
-        endResult: "Nothing is changed; this case only reads.",
-    },
-    "checklist-content-discovery-category-counts-and-rollup-guest-sees-the-same-counts": {
-        roles: ["guest", "buyer"],
-        startPage: "/categories",
-        steps: [
-            "Open /categories in a private window with no session.",
-            "Write down the counts on the first four category tiles.",
-            "Sign in as the buyer rehan.sheikh@gmail.com / TempPass123!.",
-            "Open /categories again and read the same four tiles.",
-        ],
-        expectedBehaviour: "A category count is a fact about the catalogue, not about the viewer. If the two differ, something viewer-scoped is leaking into a shared number — the likeliest candidate being a filter that hides test fixtures from one audience but is counted for the other.",
-        expectedUiState: "All four numbers are identical in both sessions.",
-        expectedData: { countsDifferBetweenSessions: false },
-        endResult: "Nothing is changed; this case only reads.",
-    },
-    "checklist-content-discovery-category-counts-and-rollup-brand-count-matches-its-listing": {
-        roles: ["guest"],
-        startPage: "/brands",
-        steps: [
-            "Open /brands.",
-            "Write down the product count shown for one brand.",
-            "Open that brand's page.",
-            "Read the total the listing reports.",
-        ],
-        expectedBehaviour: "A brand is a row in the same collection as a category and its count is written by the same trigger — but brands hang off `brandSlug` rather than the category chain, so they are a separate pass and can be missed entirely while every category is correct. Brand rows had no counter writer at all until 2026-09-14.",
-        expectedUiState: "The number on the brand tile equals the number of products the brand page lists.",
-        expectedData: { brandTileMatchesListing: true },
-        endResult: "Nothing is changed; this case only reads.",
-    },
-};

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

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

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

@@ -1,174 +0,0 @@
-/*
- * WHY: Authored six-part procedures for the categories-index tabs, the
- *      franchise unit and the bundle collage (2026-10-14).
- * 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:
- *
- *   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. 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.
- *   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.
- *
- * @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-category-tabs-franchise-bundles-index-shows-roots-only": {
-        roles: ["guest"],
-        startPage: "/categories",
-        steps: [
-            "Open /categories.",
-            "Confirm the Categories tab is the one selected on arrival.",
-            "Count the cards. There must be exactly six.",
-            "Read the six names: Spinning Tops, Trading Cards, Collectible Figures, Hot Wheels, Model Kits, Living Collectibles.",
-            "Answer no if any deeper category appears here — 'Attack Rings', 'Beyblade Burst', '1B' or any single part name.",
-        ],
-        expectedBehaviour: "BEFORE: the index rendered the whole flat forest — 1,185 rows, of which 752 are part leaves and 220 are model leaves — so the six roots were buried and a visitor met a wall of names with no sense of where they were. AFTER: the Categories tab shows ONLY the tier-0 roots and you walk down from one.",
-        expectedUiState: "Exactly six cards, each a root. No tier-1-or-deeper row anywhere on this tab.",
-        expectedData: { rootCards: 6 },
-        endResult: "Nothing is changed; this case only reads.",
-    },
-    "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 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 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 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 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 / 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": {
-        roles: ["guest"],
-        startPage: "/franchise",
-        steps: [
-            "Open /franchise.",
-            "Count the cards. Exactly one must be present: Beyblade.",
-            "Answer no if Marvel, DC Comics, Dragon Ball, Naruto, Bleach, One Piece or One Punch Man appears here.",
-        ],
-        expectedBehaviour: "Eight franchises are seeded; seven have no stock. A row with no product is a dead facet — a card that opens an empty shop — so the index lists ACTIVE franchises only. The seven still exist and their pages still resolve; they are simply not advertised as somewhere to shop until they have something to sell.",
-        expectedUiState: "One card, Beyblade. None of the seven unstocked IPs.",
-        expectedData: { franchiseCards: 1 },
-        endResult: "Nothing is changed; this case only reads.",
-    },
-    "checklist-content-discovery-category-tabs-franchise-bundles-unstocked-franchise-page-resolves": {
-        roles: ["guest"],
-        startPage: "/franchise/marvel",
-        steps: [
-            "Open /franchise/marvel directly.",
-            "Confirm a real page renders — a heading reading Marvel — and NOT a 404 or not-found view.",
-            "Confirm a message says plainly that this franchise is not stocked yet.",
-            "Answer no if the page 404s, or if it renders an empty product grid with no explanation.",
-        ],
-        expectedBehaviour: "BEFORE: `/franchise/*` was not a route at all, so seventeen links in CharacterHotspot 404ed. AFTER: the page resolves. An unstocked franchise is NOT a 404 — the row exists deliberately so those links land somewhere honest. An unexplained empty grid would be the other wrong answer: the visitor arrived from a real link and should be told it is coming, not left to assume something broke.",
-        expectedUiState: "The Marvel page renders with its name and an explicit 'not stocking this yet' message. No 404, no bare empty grid.",
-        expectedData: { httpOk: true, explanationShown: true },
-        endResult: "Nothing is changed; this case only reads.",
-    },
-    "checklist-content-discovery-category-tabs-franchise-bundles-franchise-detail-lists-its-products": {
-        roles: ["guest"],
-        startPage: "/franchise/franchise-beyblade",
-        steps: [
-            "Open the Beyblade franchise page from /franchise.",
-            "Confirm it reports a listing count in the thousands, not zero and not a handful.",
-            "Confirm product cards render.",
-            "CONTROL: now open /franchise/zzznope by typing it.",
-            "Confirm that page 404s rather than showing the whole catalogue.",
-        ],
-        expectedBehaviour: "The products filter matches on `franchiseSlug`, so a clause that was silently dropped would return the ENTIRE catalogue on every franchise page — which looks like a working page full of products. The nonsense control is the only step that tells a working filter from an absent one.",
-        expectedUiState: "Beyblade lists ~1,304 listings. An unknown franchise slug 404s and never renders a populated grid.",
-        expectedData: { beybladeListings: 1304, nonsenseSlug404s: true },
-        endResult: "Nothing is changed; this case only reads.",
-    },
-    "checklist-content-discovery-category-tabs-franchise-bundles-bundle-card-shows-a-collage": {
-        roles: ["guest"],
-        startPage: "/categories",
-        steps: [
-            "Open /categories and click the Bundles tab.",
-            "Confirm five bundle cards render.",
-            "Look at each card's image area.",
-            "Confirm it shows a COLLAGE of several product photos, not one single image.",
-            "Answer no if any card shows a single flat colour tile or one lone photo.",
-        ],
-        expectedBehaviour: "BEFORE: a bundle card showed one generic placeholder tile — the least informative thing a bundle card can show, since a bundle IS its contents. AFTER: each card shows a collage built from its members' own photos, resolved at seed time so the card costs no extra query. All five bundles carry 3 or 4 member images, which clears the 3-image minimum the collage needs.",
-        expectedUiState: "Five bundle cards, each showing a multi-image collage rather than a single tile.",
-        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__coupons.d.ts

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