@mohasinac/appkit 4.52.5 → 4.53.1

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

@@ -18,6 +18,7 @@
  * @tag consumers:seed/index.ts,seed/runner.ts
  * @tag sideEffects:none
  */
+import { PRODUCT_MAX_IMAGES, PRODUCT_MAX_VIDEOS, } from "../../../_internal/shared/media/limits.js";
 import { assignDefaultPhases } from "../utils/phases.js";
 import { happyPathPages } from "./_happy-path.js";
 import { moneyFlowsPages } from "./_money-flows.js";
@@ -217,6 +218,49 @@ const rawTesterChecklistItems = [
         },
     ]),
     ...group("buying", "Buying", [
+        {
+            /*
+             * Part Two B/C/D/E — spares, made-to-order, promoted sticker parts and
+             * the group discount, all together on the one page a buyer actually
+             * uses. Each case is an explicit BEFORE -> AFTER: a spare page returning
+             * 200 with plausible cards is not evidence any of this works.
+             */
+            pageKey: "spares-and-groups",
+            pageLabel: "Spares browse, made-to-order, and group selections",
+            href: "/spares",
+            cases: [
+                {
+                    key: "spares-not-in-general-catalogue",
+                    label: "A spare does NOT appear on /products, but does appear on /spares",
+                    description: "BEFORE: there was no tenth listing type. AFTER: open /products and search for a known spare's title (e.g. \"Cross Dranzer\") — it must NOT appear, because `spares` sets `inGeneralCatalogue: false`. The same title DOES appear on /spares. If it appears on both, the exclusion broke; if it appears on neither, the nav/page wiring broke.",
+                },
+                {
+                    key: "spares-nav-entry-present",
+                    label: "The main nav's Products dropdown has a \"Spares\" child linking to /spares",
+                },
+                {
+                    key: "made-to-order-buyable-at-zero-stock",
+                    label: "A made-to-order listing at zero stock is buyable and says \"Made to order\", never \"Out of Stock\"",
+                    description: "Open the seeded \"Custom Beyblade Sticker Sheet — Print on Demand\" (stockQuantity 0, madeToOrder true). It must show \"Made to order — printed when you order\" rather than an Out of Stock badge, Add to Cart must work, and checkout must complete. This is the exact case C exists for: stock must gate nothing on this listing.",
+                    href: "/products/sticker-beyblade-custom-print-on-demand",
+                },
+                {
+                    key: "group-picker-shows-rules-before-choosing",
+                    label: "A group with selection rules states them BEFORE the buyer picks anything",
+                    description: "Open the seeded \"Burst & X Attackers You Might Like\" group (via one of its member products' Group section). The picker must show its rules (min 2, max 3, max 2 of any one, 10% off) as text near the top — not only as a refusal after submitting.",
+                },
+                {
+                    key: "group-picker-blocks-and-explains-invalid-selection",
+                    label: "Picking an invalid combination (e.g. only 1 item, or 3 of one item) shows the reason and disables Add",
+                    description: "On the same group, select only 1 item: the Add button must be disabled and a message naming the rule must appear (\"Pick at least 2…\"). Select 3 of one item: a different message naming the per-item cap must appear. Fixing the selection must re-enable Add without a page reload.",
+                },
+                {
+                    key: "group-discount-applied-and-shown",
+                    label: "The group discount is shown on the picker AND the cart line is actually discounted by that percentage",
+                    description: "Select a valid combination (e.g. 2 different items) on the 10%-off group and note the total shown in the picker. Add to cart, then open the cart and the checkout review: the line total must be 10% below the sum of the two items' individual prices, to the paisa, in all three places (picker, cart, checkout).",
+                },
+            ],
+        },
         {
             /*
              * The post-purchase money surface. `/user/orders/[id]/` has five
@@ -2211,6 +2255,39 @@ const rawTesterChecklistItems = [
         },
     ]),
     ...group("selling", "Selling", [
+        {
+            /*
+             * Part Two B/E — the seller side of spares, and the shared group-stock
+             * editor. "Stock is independent per listing" is the whole premise, so
+             * the editor-save-and-reload round trip is what actually proves that —
+             * a shared pool bug would show up exactly here, as one listing's stock
+             * silently changing another's.
+             */
+            pageKey: "spares-seller-and-group-editing",
+            pageLabel: "Seller spares dashboard and group stock/rules editing",
+            href: "/store/spares",
+            cases: [
+                {
+                    key: "seller-can-list-a-spare",
+                    label: "A seller can create, publish and see a spare on their own /store/spares list",
+                },
+                {
+                    key: "group-stock-edit-is-independent",
+                    label: "Editing one group member's stock does NOT change any other member's stock",
+                    description: "Open a group parent's editor, note two children's stock figures, change ONLY one of them in the shared stock editor, save, reload. The edited child shows the new figure; the other child is UNCHANGED. This is the premise the whole feature rests on — a shared pool would fail exactly this check.",
+                },
+                {
+                    key: "group-rules-save-and-reload",
+                    label: "Saved group rules (min/max/per-item cap/discount) survive a reload and reach the public picker",
+                    description: "In the group parent's editor, set min/max/per-item/discount to new values, save, reload the editor — the same values must still be there. Then open the group's public picker (as a buyer) and confirm the NEW rule text is what shows, not the old one.",
+                },
+                {
+                    key: "group-stock-partial-failure-reported",
+                    label: "Saving group stock for a member no longer in the group reports it, without losing the other saved rows",
+                    description: "Unlink a child from a group in one tab, then (without reloading) try to save that same child's stock from a second tab holding the stale member list. The response must name that row as rejected while the OTHER rows in the same save still succeed — not a blanket failure.",
+                },
+            ],
+        },
         {
             /*
              * The UPDATE path. The create path has 57 cases on /store/products/new
@@ -2314,20 +2391,21 @@ const rawTesterChecklistItems = [
                 /*
                  * REMOVED 2026-09-11 — `media-upload-images-capped-at-5`.
                  *
-                 * It asserted the gallery caps at "5 images (not 10)". The cap was
-                 * raised to 10 (`PRODUCT_MAX_IMAGES`, shared/media/limits.ts:37) and the
-                 * `selling/media-limits` page asserts the opposite in its own label:
-                 * "The 10th gallery image uploads — the 5th used to fail with a 400".
-                 *
-                 * So this case documented the OLD behaviour as the expectation. It
-                 * would fail against correct code, and anyone "fixing" the product to
-                 * satisfy it would re-break ten-image support. Its id encoded the wrong
-                 * number too, so correcting the label alone would still mislead.
+                 * It asserted the gallery caps at "5 images (not 10)". The cap had been
+                 * raised (`PRODUCT_MAX_IMAGES`), so the case documented the OLD
+                 * behaviour as the expectation: it would fail against correct code, and
+                 * anyone "fixing" the product to satisfy it would re-break multi-image
+                 * support. Its id encoded the wrong number too, so correcting the label
+                 * alone would still mislead.
                  *
                  * The invariant it really tested — the stated limit equals the enforced
-                 * limit — survives in `media-eleventh-image-refused-client-side`, which
-                 * requires the refusal to name the limit ("You can upload up to 10
-                 * images."). Nothing was lost.
+                 * limit — survives in `media-over-cap-image-refused-client-side`, which
+                 * requires the refusal to NAME the limit. Nothing was lost.
+                 *
+                 * 🛑 And the lesson got applied rather than just recorded: the cap moved
+                 * again on 2026-10-19 (10 -> 24), and the two cases that would have gone
+                 * stale now interpolate `PRODUCT_MAX_IMAGES` and carry no number in
+                 * their ids. See the note on the `media-limits` page below.
                  */
                 {
                     key: "media-upload-video-duration",
@@ -2903,25 +2981,44 @@ const rawTesterChecklistItems = [
         },
         {
             pageKey: "media-limits",
-            pageLabel: "Media \u2014 ten images and one video, on every listing type",
+            pageLabel: `Media \u2014 ${PRODUCT_MAX_IMAGES} images and ${PRODUCT_MAX_VIDEOS} video, on every listing type`,
             href: "/store/products/new",
             cases: [
                 {
                     key: "media-gallery-accepts-images-and-video",
                     label: "The gallery takes BOTH images and a video, and shows a live per-type count",
-                    description: "Changed 2026-09-04. BEFORE the single-media control on the listing form was video-only (`kind=\"video\"`), so the one \"add media\" affordance a seller saw refused photos. AFTER: the gallery accepts image files and a video file in the same control, and a counter under it reads \"N/10 images \u00b7 N/1 video\" as you add them.",
+                    description: `Changed 2026-09-04. BEFORE the single-media control on the listing form was video-only (\`kind="video"\`), so the one "add media" affordance a seller saw refused photos. AFTER: the gallery accepts image files and a video file in the same control, and a counter under it reads "N/${PRODUCT_MAX_IMAGES} images \u00b7 N/${PRODUCT_MAX_VIDEOS} video" as you add them.`,
                     href: "/store/products/new",
                 },
+                /*
+                 * \ud83d\uded1 These two cases state the cap by INTERPOLATING `PRODUCT_MAX_IMAGES`,
+                 * and their keys no longer encode a number.
+                 *
+                 * The pair they replace (`media-tenth-image-uploads`,
+                 * `media-eleventh-image-refused-client-side`) hard-coded 10 in the key,
+                 * the label, the description and the authored procedure's `inputs` \u2014
+                 * so raising the cap to 24 on 2026-10-19 would have left four cases
+                 * asserting the OLD number and failing against correct code. That is
+                 * exactly what the removal note above this page records happening the
+                 * last time the cap moved, including its warning that "its id encoded
+                 * the wrong number too, so correcting the label alone would still
+                 * mislead".
+                 *
+                 * What is actually under test is the BOUNDARY, not the number: that the
+                 * last allowed image succeeds (the off-by-one), and that the first one
+                 * over is refused client-side. Both are stated cap-agnostically, so the
+                 * next change to the cap needs no edit here at all.
+                 */
                 {
-                    key: "media-tenth-image-uploads",
-                    label: "The 10th gallery image uploads \u2014 the 5th used to fail with a 400",
-                    description: "BEFORE: the gallery was capped at 5 and sent its Nth image as index N+1, while the server's signed-URL guard rejected any index above 5 \u2014 so the LAST slot of every product form returned a 400 that read as a random upload failure. AFTER: add ten images one at a time. All ten must succeed, including the tenth.",
+                    key: "media-last-allowed-image-uploads",
+                    label: "The LAST allowed gallery image uploads \u2014 the cap is inclusive of its own number",
+                    description: `Add images one at a time, counting previews, until the control refuses one. BEFORE: the gallery sent its Nth image as index N+1 while the server's signed-URL guard rejected any index above the cap \u2014 so the LAST slot of every product form returned a 400 that read as a random upload failure. AFTER: the count you reach before any refusal must be exactly ${PRODUCT_MAX_IMAGES}, not ${PRODUCT_MAX_IMAGES - 1}. An off-by-one here is the most likely error and the least likely to be noticed, because one short of the cap still looks like plenty.`,
                     href: "/store/products/new",
                 },
                 {
-                    key: "media-eleventh-image-refused-client-side",
-                    label: "The 11th image is refused by the FORM with a clear message, not by the server",
-                    description: "Try to add an 11th image. The control must refuse it before uploading, naming the limit (\"You can upload up to 10 images.\"). A server-side 400 arriving after the bytes have gone up is the wrong behaviour \u2014 the user has already waited.",
+                    key: "media-over-cap-image-refused-client-side",
+                    label: "The first image OVER the cap is refused by the FORM, not by the server",
+                    description: `With ${PRODUCT_MAX_IMAGES} images already added, attempt one more with the browser's Network panel open. The control must refuse it before requesting a signed URL, and the message must NAME the limit ("You can upload up to ${PRODUCT_MAX_IMAGES} images."). A server-side 400 arriving after the bytes have gone up is the wrong behaviour twice over \u2014 the seller has already waited, and an orphaned object is left in storage.`,
                     href: "/store/products/new",
                 },
                 {
@@ -2932,8 +3029,8 @@ const rawTesterChecklistItems = [
                 },
                 {
                     key: "media-caps-flat-across-types",
-                    label: "The same 10 + 1 applies to an auction and a pre-order \u2014 there is no per-type table",
-                    description: "Repeat the ten-image check on /store/auctions/new and /store/pre-orders/new. Both must allow ten. BEFORE the server carried separate AUCTION_IMAGE_MAX and PREORDER_IMAGE_MAX constants, both 5, disagreeing with everything else.",
+                    label: `The same ${PRODUCT_MAX_IMAGES} + ${PRODUCT_MAX_VIDEOS} applies to an auction and a pre-order \u2014 there is no per-type table`,
+                    description: `Repeat the boundary check on /store/auctions/new and /store/pre-orders/new. Both must allow ${PRODUCT_MAX_IMAGES}. BEFORE the server carried separate AUCTION_IMAGE_MAX and PREORDER_IMAGE_MAX constants, both 5, disagreeing with everything else.`,
                     href: "/store/auctions/new",
                 },
                 {
@@ -3093,8 +3190,169 @@ const rawTesterChecklistItems = [
         },
         {
             /*
-             * D12 — the parts database, the composition panel, and the part line in a
-             * seller's auto-filled description.
+             * Overflowing pill and tab rows — 2026-10-18.
+             *
+             * 🛑 Every case here is written as an explicit BEFORE → AFTER, because
+             * the defect's symptom is not an error: a row that overflows renders
+             * perfectly, returns HTTP 200, and simply puts some of its items past
+             * the right edge where nothing indicates they exist. A case reading
+             * "check the subcategories show" PASSES against the bug.
+             *
+             * The reported instance had 12 subcategory pills on a 1440px viewport
+             * with the last four unreachable — no scrollbar, no arrow, no hint.
+             *
+             * Width is the thing under test, so every case NAMES A VIEWPORT. A run
+             * at an unstated width cannot distinguish "collapsed correctly" from
+             * "collapsed when it had room", which are opposite defects.
+             */
+            pageKey: "overflowing-pill-rows",
+            pageLabel: "Pill and tab rows that do not fit collapse into a searchable dropdown",
+            href: "/categories",
+            cases: [
+                { key: "wide-row-stays-pills", label: "A subcategory row that FITS still renders as pills, not a dropdown" },
+                { key: "narrow-row-collapses", label: "The same row at a phone width collapses to one dropdown trigger" },
+                { key: "collapsed-dropdown-is-searchable", label: "The collapsed dropdown has a search box that filters as you type" },
+                { key: "collapsed-dropdown-keyboard", label: "Arrow keys and Enter pick an item without touching the mouse" },
+                { key: "every-item-reachable-when-collapsed", label: "Every subcategory is reachable from the dropdown, including ones that used to be off-screen" },
+                { key: "pills-carry-a-leading-image", label: "Subcategory pills and dropdown rows show the category's own cover image" },
+                { key: "missing-image-falls-back-to-initial", label: "A subcategory with no cover image shows an initial, not a blank box or a broken image" },
+                { key: "widening-restores-the-pills", label: "Widening the window back expands the dropdown into pills again" },
+                { key: "subcategory-click-is-client-side", label: "Clicking a subcategory navigates without a full page reload" },
+                { key: "tabs-collapse-by-width-not-count", label: "A tab bar with six short tabs stays a row on desktop instead of collapsing on a count" },
+                { key: "event-tabs-do-not-jump-to-top", label: "Switching event tabs does not scroll the page back to the top" },
+            ],
+        },
+        {
+            /*
+             * The authenticity checker — 2026-10-18.
+             *
+             * 🛑 Every case here asserts the presence of a HEDGE, or compares two
+             * inputs, because this tool's failure mode is not a crash: it is a
+             * confident, plausible, wrong answer served with HTTP 200. Code-matching
+             * alone cannot detect a counterfeit (one crawled counterfeit catalogue
+             * printed 900+ genuine Takara Tomy codes), the Metal Fight date-code
+             * decoding is disputed with no manufacturer statement, and two of the
+             * spellings a naive build would flag as fake tells are Takara Tomy's own
+             * romanisation and a licensed Indian importer's name.
+             */
+            pageKey: "authenticity-checker",
+            pageLabel: "Authenticity checker — box codes, per-generation checks and the regional code tables",
+            href: "/tools/authenticity",
+            cases: [
+                /* ── Guards for the near-miss work (2026-10-19) ──────────────────
+                 * All three protect behaviour that is ALREADY CORRECT. They exist
+                 * because a "did you mean" feature is precisely the change that
+                 * could turn an absent code into an accusation, and this tool's
+                 * third rule is that a false counterfeit accusation against a real
+                 * seller is worse than a missed one.
+                 */
+                {
+                    key: "authenticity-unknown-code-is-not-fake",
+                    label: "An invented but well-formed box code returns NEUTRAL + inconclusive — never a counterfeit verdict",
+                    description: "Type a code that is well-formed (one letter, four digits) but not in any table — try Z9999. The verdict must be \"Inconclusive\", the signal must read neutral, and the text must say the code is NOT RECORDED rather than fake. Any wording that implies the item is counterfeit is the failure, and so is any verdict more severe than inconclusive. New genuine codes appear regularly, and counterfeiters use real codes anyway, so an absent code proves nothing in either direction.",
+                    href: "/tools/authenticity",
+                },
+                {
+                    key: "authenticity-near-miss-suggests",
+                    label: "A one-character-off code offers \"did you mean …?\" as a SUGGESTION, with no change to the verdict",
+                    description: "BEFORE: a transposed code said only \"not in either table\". AFTER: enter A0831 when A0813 is a known code — you get a neutral \"did you mean A0813?\" line. It must sit OUTSIDE the \"What I checked\" list, must not appear as a signal, must not fire any evasion or counterfeit warning, and the verdict must stay exactly what it was without the suggestion. A near-miss is ambiguous between a typo and a batch mimicking a real code; it is input correction, never evidence.",
+                    href: "/tools/authenticity",
+                },
+                {
+                    key: "authenticity-inconclusive-asks-for-more",
+                    label: "Code-only input prompts for the model name and offers the ask-the-seller next step",
+                    description: "Enter a code and a generation but NO model name. The inconclusive result must now say that supplying the name lets it cross-check name against code, and must offer asking the seller for a photo of the box bottom and the screws. BEFORE: you got the physical checklist and no indication that a second field would unlock a real check.",
+                    href: "/tools/authenticity",
+                },
+                {
+                    key: "authenticity-evasion-warning-survives",
+                    label: "Typing \"Pegasis\" still reaches the tool's own verdict with the evasion warning intact",
+                    description: "SECURITY-SHAPED, and it exists because of a specific hazard. The site search matcher deliberately treats \"Pegasis\" as a match for \"Storm Pegasus\" — its alias table is built FROM a counterfeit seller's spellings. This tool treats that same spelling as EVIDENCE of trademark evasion. Type Pegasis here: the fuzzy/evasion signal must still fire. If a name typeahead is offered and you pick a canonical name from it, the tool must STILL analyse what you typed — a case asserting only \"the typeahead found it\" would pass against exactly the bug this guards.",
+                    href: "/tools/authenticity",
+                },
+                {
+                    key: "authenticity-name-typeahead",
+                    label: "Typing a partial model name offers canonical releases, and picking one does NOT change what gets checked",
+                    description: "BEFORE: you had to already know the exact release name. AFTER: type a partial name (e.g. \"Drago\") and canonical releases appear beneath the field as suggestions. Click one — a confirmation line appears (\"We have a record close to this: …\"), but the TEXT YOU TYPED in the field must stay exactly as you typed it. Submit the check and confirm the result is consistent with what you typed, not with the suggestion you clicked.",
+                    href: "/tools/authenticity",
+                },
+                {
+                    key: "authenticity-box-code-still-instant",
+                    label: "A box date code (e.g. A0813) resolves instantly with no network request — it is NOT in the search index",
+                    description: "GUARD CASE. Open DevTools -> Network, clear it, and submit a known box date code. No fetch to the search artifact or any search endpoint should appear — the date-code table is bundled locally and always was. This case exists because the site-wide index work added a name typeahead to this same page, and the two must stay on separate code paths.",
+                    href: "/tools/authenticity",
+                },
+                { key: "guest-sees-reference-not-a-wall", label: "Signed out, the LOOKUP ITSELF runs — no sign-in card anywhere on the page" },
+                { key: "no-signin-flash-when-authenticated", label: "No session placeholder and no sign-in card during a hard reload, signed in or out" },
+                { key: "midfake-code-reads-as-batch-not-accusation", label: "A matched midfake code reports a batch, never a counterfeit accusation against the seller" },
+                { key: "date-code-shows-both-readings", label: "A box date code shows BOTH circulating readings and says neither is official" },
+                { key: "real-product-code-is-not-evidence", label: "A well-formed product code is marked neutral and states that real codes appear on fakes" },
+                { key: "name-code-mismatch-asks-rather-than-accuses", label: "A name/code mismatch is a question, and answering 'How it was sold' re-reads it as expected" },
+                { key: "ambiguous-name-asks-which-model", label: "An ambiguous name asks which release instead of confidently naming one" },
+                { key: "takara-spelling-is-not-flagged", label: "'Storm Pegasis' (the Takara Tomy spelling) is not flagged, while 'Scythee' is" },
+                { key: "funskool-is-not-a-fake-signal", label: "Funskool reads as a licensed importer; Rapidity reads as an unlicensed producer" },
+                { key: "unknown-code-is-not-called-fake", label: "An unrecorded code says 'not recorded' and explicitly not 'fake'" },
+                { key: "asks-generation-when-nothing-inferable", label: "With no generation inferable the tool asks instead of returning a verdict" },
+                { key: "api-refuses-signed-out", label: "POST /api/tools/authenticity answers a signed-out caller, and still 400s an undeclared key" },
+                { key: "json-ld-declares-no-false-gate", label: "The WebApplication JSON-LD declares NO paywalled region, now that there is none" },
+                { key: "defaults-to-metal-fight", label: "Generation opens on Metal Fight, and a Burst code against it raises a mismatch signal rather than passing silently" },
+                { key: "contested-code-reports-the-disagreement", label: "A code two sources disagree about reports the disagreement instead of picking a side" },
+                { key: "font-midfake-does-not-accuse", label: "A midfake row whose own source calls the code authentic does NOT reach 'likely reproduction'" },
+                { key: "regional-code-reads-as-regional", label: "A Korean or Middle-East code names its region instead of coming back unrecorded" },
+                { key: "series-window-names-the-production-run", label: "A derivable date names its Metal-series production window, or names none outside all four" },
+                { key: "temporal-context-for-an-unmatched-code", label: "An unmatched code reports what else the tables record from the same month, framed as context not a match" },
+            ],
+        },
+        {
+            pageKey: "price-index-tool",
+            pageLabel: "What it sold for — realised prices",
+            href: "/tools/price-index",
+            cases: [
+                {
+                    key: "price-index-resolves-locally",
+                    label: "Candidate names appear with no network delay while typing; only the bands themselves come from the server",
+                    description: "BEFORE: resolving a free-text query to a category leaf was a Firestore searchTxt query on every lookup. AFTER: open /tools/price-index, open DevTools -> Network, clear the log, and search a real model name. The suggestion/candidate step must feel instant and correspond to the local search artifact (a .json fetched once, not per search); only ONE further request — to the bands endpoint — should fire, carrying just the resolved id(s), and it must return real min/median/mean/max figures for a model with recorded sales.",
+                    href: "/tools/price-index",
+                },
+                {
+                    key: "price-index-falls-back-when-index-off",
+                    label: "Price lookup still works end-to-end if the search index is unavailable",
+                    description: "GUARD CASE for the fallback path. If the admin search-index kill switch is off (or the artifact fails to load), the price lookup must still return real results via the original query-based endpoint — the feature must not go blank just because the faster path is unavailable.",
+                    href: "/tools/price-index",
+                    needsReview: true,
+                    reviewNote: "Needs the kill switch flipped off to observe, which an ordinary run does not do — flagged for a human or admin-tooling pass.",
+                },
+            ],
+        },
+        {
+            pageKey: "compare-overlay-add-item",
+            pageLabel: "Compare overlay — add another item",
+            href: "/products",
+            cases: [
+                {
+                    key: "compare-add-another-via-typeahead",
+                    label: "The compare overlay's \"Add another\" typeahead adds a real item without leaving the page",
+                    description: "BEFORE: the compare overlay only ever showed items selected via listing-page checkboxes before opening it — there was no way to add a further item once the overlay was open. AFTER: open the compare overlay with at least one item selected, find the 'Add another to compare' box, type a product name, and pick a suggestion. The picked item's full column (image, price, specs) appears in the overlay without closing it or returning to the listing grid.",
+                    href: "/products",
+                },
+                {
+                    key: "compare-add-hidden-at-column-limit",
+                    label: "The \"Add another\" box disappears once the compare overlay is full",
+                    description: "Add items via checkboxes (or the typeahead) until the overlay holds its maximum number of columns. The 'Add another' box must then be absent entirely — not merely disabled — since a picker that cannot add anything is worse than none.",
+                    href: "/products",
+                },
+            ],
+        },
+        {
+            /*
+             * D12 — the Beyblade parts gallery, the composition panel, and the part
+             * line in a seller's auto-filled description.
+             *
+             * 🛑 `pageKey` stays `parts-database` even though the surface is now
+             * called the Beyblade parts gallery. It keys all nine case ids, every
+             * `testerChecklistResponses` row already recorded against them, and
+             * `audit-tester-checklist-hrefs`. A label is a label; a key is an
+             * identifier.
              *
              * 🛑 Four defects this feature has already produced, every one of them a
              * 200 with plausible content: a read against a field the collection does
@@ -3105,7 +3363,7 @@ const rawTesterChecklistItems = [
              * ABSENT panel — indistinguishable from a model we have no data for.
              */
             pageKey: "parts-database",
-            pageLabel: "Parts database, composition panel and the part line in a description",
+            pageLabel: "Beyblade parts gallery, composition panel and the part line in a description",
             href: "/parts",
             cases: [
                 { key: "index-lists-every-classification", label: "The parts index lists all 20 classifications, labelled as names and not as URL slugs" },
@@ -3130,30 +3388,33 @@ const rawTesterChecklistItems = [
              *
              *   1. The index rendered all 1,185 rows flat. Nothing errored; it just
              *      buried the six roots under 752 part leaves.
-             *   2. The Parts tab first matched 772 rows — it also caught the 20
-             *      classification NODES, whose own parentIds pass through a
-             *      `*-parts` node. A tab mixing "Attack Rings" with the attack rings
-             *      inside it looks entirely reasonable.
-             *   3. Seven franchises have NO stock. Seeded active they would each be
+             *   2. Seven franchises have NO stock. Seeded active they would each be
              *      a card opening an empty shop; omitted entirely, seventeen
              *      CharacterHotspot links stay 404. Both failure modes look fine
              *      from one page.
-             *   4. Every bundle carries a placeholder cover image, so a collage
+             *   3. Every bundle carries a placeholder cover image, so a collage
              *      checked AFTER the cover would never render — and a card showing
              *      one grey tile is not visibly broken.
+             *
+             * 🛑 There was a fifth tab, Parts, removed 2026-10-20 — parts belong to
+             * `/parts` and the spares listing type, not to a flat tab over 752
+             * leaves. Its own case went with it. The product-detail Parts
+             * COMPOSITION tab is a different surface and still has cases, on the
+             * `parts-database` page above.
              */
             pageKey: "category-tabs-franchise-bundles",
             pageLabel: "Categories index tabs, the franchise unit and the bundle collage",
             href: "/categories",
             cases: [
                 { key: "index-shows-roots-only", label: "The Categories tab lists the six roots and NO deeper category" },
-                { key: "five-tabs-no-all", label: "There are exactly five tabs and none of them is 'All'" },
-                { key: "parts-tab-is-leaves-only", label: "The Parts tab lists part leaves and NOT the 20 classification nodes" },
+                { key: "four-tabs-no-all-no-parts", label: "There are exactly four tabs — no 'All', and no 'Parts'" },
                 { key: "tabs-do-not-overlap", label: "No single row appears on two tabs" },
                 { key: "franchise-index-hides-unstocked", label: "The franchise index shows only stocked franchises, not all eight" },
                 { key: "unstocked-franchise-page-resolves", label: "An unstocked franchise page loads and says so, rather than 404ing or showing an empty grid" },
                 { key: "franchise-detail-lists-its-products", label: "The Beyblade franchise page lists its listings, with a nonsense slug as the control" },
                 { key: "bundle-card-shows-a-collage", label: "A bundle card shows a collage of its members, not its placeholder cover" },
+                { key: "tabs-collapse-on-narrow-viewport", label: "On a phone-width viewport the four tabs collapse into a searchable dropdown, not a row running off-screen" },
+                { key: "tabs-hover-changes-ink", label: "On desktop, hovering an inactive tab visibly changes its text colour" },
             ],
         },
         {
@@ -3363,7 +3624,7 @@ const rawTesterChecklistItems = [
                 {
                     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.",
+                    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. UPDATED 2026-10-19: suggestions now come from the local index and span all 21 content types rather than the four the old endpoint could produce — so expect categories, parts and FAQs among the rows, not only products. ALSO CHECK, in DevTools -> Network: after the first index download there must be NO request per keystroke.",
                 },
                 {
                     key: "search-typeahead-no-drafts",
@@ -3478,6 +3739,138 @@ const rawTesterChecklistItems = [
                     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",
                 },
+                /* ── The site-wide index (2026-10-19) ─────────────────────────────
+                 * Every case below is written as an explicit BEFORE -> AFTER,
+                 * because almost all of them describe behaviour that previously
+                 * returned HTTP 200 with plausible rows. A case reading "check
+                 * search works" passes AGAINST the bug it is meant to catch.
+                 */
+                {
+                    key: "search-finds-every-type",
+                    label: "Searching \"dranzer\" from the header lands on /search and returns hits in SEVERAL sections",
+                    description: "BEFORE: the header sent you to /products?q=dranzer — one browse page — so you never learned there is also a category, a part, a blog post and an FAQ about it. AFTER: you land on /search and see grouped results across several sections. CONTROL, and it is the only assertion here that cannot pass by accident: search \"zzzznope\" and the page must say nothing matched, with ZERO result rows.",
+                    href: "/search",
+                },
+                {
+                    key: "search-finds-a-part",
+                    label: "Searching \"Rubber Flat\" and then \"RF\" both find the part",
+                    description: "BEFORE: zero results for either — all 752 parts had no search tokens at all, so they were reachable only by drilling /parts -> classification -> code. AFTER: both queries return the part, and the row shows its classification underneath the name.",
+                    href: "/search",
+                },
+                {
+                    key: "search-ambiguous-part-code",
+                    label: "Searching \"105\" returns SEVERAL parts, each showing a DIFFERENT classification",
+                    description: "BEFORE: there was no way to search parts at all. AFTER: \"105\" is deliberately ambiguous — it is a Metal Fight spin-track height, while a bare number in Burst is a disc — so the right answer is several rows, each naming its own classification and each linking to a different two-segment /parts/<classification>/<code> page. ONE row is the failure: it means something picked a winner.",
+                    href: "/search",
+                },
+                {
+                    key: "search-midword",
+                    label: "Searching \"ariza\" finds Charizard",
+                    description: "BEFORE: impossible. Firestore token search is word-PREFIX only, so a mid-word fragment matched nothing. AFTER: it matches, because the browser scans the whole index. CONTROL: \"zzzz\" must still return nothing — a matcher that returns everything for any fragment would also pass the first half.",
+                    href: "/search",
+                },
+                {
+                    key: "search-typo",
+                    label: "Searching \"dragon g\" finds Dragoon G, and \"Pegasis\" finds Storm Pegasus",
+                    description: "Misspellings are expanded at index time from a crawl of a counterfeit seller's real titles, on the basis that an evasion spelling is the same string a buyer mistypes. BEFORE: neither matched. AFTER: both do.",
+                    href: "/search",
+                },
+                {
+                    key: "search-normalised-away",
+                    label: "Searching \"!!!\" shows the \"no searchable words\" state — NOT every listing",
+                    description: "BEFORE (the inverse bug, on /api/products): a punctuation-only query produced no filter clause, so it returned the ENTIRE published catalogue as search results. AFTER: the page says the query had no searchable words in it. Note this is a different message from \"nothing matched\" and both must be distinguishable.",
+                    href: "/search",
+                },
+                {
+                    key: "search-zero-reads",
+                    label: "After the first search, typing produces NO further network requests",
+                    description: "Open DevTools -> Network, signed out. Type a query: you should see ONE fetch of the index artifact (a .json from firebasestorage, a few hundred KB) and nothing per keystroke thereafter. BEFORE: every keystroke hit /api/search/suggestions. A request per character is the failure even though the results look identical.",
+                    href: "/search",
+                },
+                {
+                    key: "search-no-prices",
+                    label: "No rupee amount appears anywhere in the header suggestions or /search results, signed out",
+                    description: "BEFORE: the header dropdown printed the product price as the suggestion subtitle, from a route cached PUBLIC for 60s — a live guest-price leak on every page. AFTER: suggestions show the brand and category instead, and no ₹ appears anywhere for a signed-out visitor.",
+                    href: "/search",
+                },
+                {
+                    key: "search-no-sandbox",
+                    label: "No tester-sandbox row appears in search results for a signed-out visitor",
+                    description: "The index is ONE shared file every browser downloads, with no per-viewer filter anywhere after it is built — so a sandbox row in it is published to the world for that version's lifetime. Search \"sandbox\" and \"tester\" signed out; nothing seeded as test data may appear.",
+                    href: "/search",
+                },
+                {
+                    key: "search-freshness",
+                    label: "A newly published listing becomes findable within ~15 minutes, and unpublishing removes it",
+                    description: "Publish a listing, note the time, and search its exact title. It should appear within about 15 minutes. Then unpublish it and search again — it must disappear within the same window. BEFORE: there was no index to go stale. A row that never appears, or never leaves, both mean the rebuild stopped.",
+                    href: "/search",
+                },
+                {
+                    key: "search-facet-counts",
+                    label: "Facet chips on /search show counts that match the rows actually displayed, and ticking one narrows BOTH",
+                    description: "Search a broad term. The rail shows chips like Type/Brand/Condition with a number on each. Tick one: the results narrow AND the other chips' numbers drop to match. A chip whose count does not change the result set, or a count that disagrees with the rows you can see, is the failure.",
+                    href: "/search",
+                },
+                {
+                    key: "search-guest-no-private",
+                    label: "Signed out, /search shows no account sections and makes ZERO authenticated requests",
+                    description: "SECURITY. In a private window with no session, search a broad term and watch DevTools -> Network. There must be no request to /api/search/scoped at all — not a 401, not an empty 200. An authenticated request firing for a guest means a session the page did not expect.",
+                    href: "/search",
+                },
+                {
+                    key: "search-buyer-isolation",
+                    label: "Buyer A cannot find Buyer B's order — by the UI AND by calling the API directly",
+                    description: "SECURITY, and the API half is the half that matters. Signed in as one buyer, search a term from another buyer's order. Then call /api/search/scoped?q=<term> directly in the same session and read the JSON. Neither may contain the other buyer's row. A UI that hides it while the API returns it is the failure this case exists for.",
+                    href: "/search",
+                },
+                {
+                    key: "search-seller-own-store",
+                    label: "A seller finds their own DRAFT listing; another seller's draft is absent",
+                    description: "Signed in as a seller, search a draft listing's title. It appears under \"Your listings (incl. drafts)\" — that section exists precisely because published listings are deduped away into the public results, so what is left is your drafts. Then confirm a different store's draft title returns nothing.",
+                    href: "/search",
+                },
+                {
+                    key: "search-listing-boxes-still-filter",
+                    label: "The per-collection search boxes still filter — one public, one seller, one admin",
+                    description: "REGRESSION GUARD. The box on /stores, the one on /store/orders and the one on /admin/users are a DIFFERENT system from site-wide search and must be untouched. For each: a real term narrows the list, a nonsense term returns zero, pagination still works, and the filter-drawer badge still counts correctly.",
+                    href: "/stores",
+                },
+                {
+                    key: "search-support-ticket-two-words",
+                    label: "A TWO-WORD support-ticket search narrows to tickets matching BOTH words",
+                    description: "BEFORE: the second word was discarded entirely, so the search returned everything matching the longer word and looked like it was working. AFTER: search two words you know appear in one ticket's subject but not together in others — only the matching ticket should remain.",
+                    href: "/admin/support-tickets",
+                },
+                {
+                    key: "search-parts-page-has-a-box",
+                    label: "/parts has a search box that finds a part by name or by code",
+                    description: "BEFORE: /parts was browse-only — 752 parts reachable only by clicking a classification then a code. AFTER: there is a search input above the classification grid. Type \"RF\" and the part appears with its classification; type \"zzzznope\" and it says nothing matches. The classification grid must still be there below it.",
+                    href: "/parts",
+                },
+                {
+                    key: "search-facet-carries-through",
+                    label: "\"See all →\" on a group with a facet ticked lands on the browse page WITH that facet still applied",
+                    description: "Search a broad term and tick a facet chip (e.g. a brand). Click the group's own \"See all →\" link. BEFORE: the link always went to the plain, unfiltered browse page, so refining on /search and then following through threw the refinement away. AFTER: the destination URL carries the same filter (e.g. ?f=brand==Takara-Tomy) and the browse page opens already narrowed.",
+                    href: "/search",
+                },
+                {
+                    key: "search-admin-person-exact",
+                    label: "Admin can find a user by typing just their FIRST name — but a prefix of it finds nothing",
+                    description: "Signed in as admin, open /admin/users and type a real user's first name only (not their full \"First Last\"). BEFORE: the search was an exact match on the WHOLE displayName string, so typing only the first name found nobody. AFTER: it is a whole-WORD match and finds them. Then type only the first 3-4 letters of that name (a prefix, not the whole word) — this must find NOTHING. That second half is the design, not a bug: the index is whole-word only so it cannot be unpicked by counting partial-match frequencies.",
+                    href: "/admin/users",
+                },
+                {
+                    key: "search-no-plaintext-pii",
+                    label: "The stored search-index values are HMAC digests, never a readable name",
+                    description: "For an admin or engineer with Firestore console access: open a `users` document and find `nameTokensIndex`. Every entry must be an opaque hex digest (prefixed `hmac:`), never the person's actual name or email in any form. Also confirm no such field exists on, or is reachable from, the public search artifact (the .json file fetched by a signed-out visitor) — a deterministic per-person identifier published to every browser is a disclosure even though it cannot be reversed.",
+                    href: "/admin/users",
+                },
+                {
+                    key: "faq-punctuation-search",
+                    label: "Searching \"!!!\" in the FAQ box shows the normalised-away state, not every FAQ",
+                    description: "GUARD CASE — this behaviour is already correct and this case exists to pin it so it cannot regress while the site-wide index work is in motion elsewhere. Open /faqs and search \"!!!\". It must say the search had no searchable words, and show zero FAQs — not the entire FAQ list.",
+                    href: "/faqs",
+                },
             ],
         },
         {
@@ -3935,6 +4328,49 @@ const rawTesterChecklistItems = [
                 },
             ],
         },
+        {
+            pageKey: "header-brand-mark-centring",
+            pageLabel: "Header — Centred Brand Mark Never Collides With the Icons",
+            href: "/products",
+            cases: [
+                {
+                    key: "mark-clear-of-icons-across-the-lg-band",
+                    label: "Sweeping the window from 1024px to 1280px, the centred leaf mark never overlaps the notification, messages, wishlist or cart icons",
+                    description: "Fixed 2026-10-19. BEFORE: the mark was `position: absolute; left: 50%` inside the title row, so the row's `justify-between` reserved no space for it and the right-hand cluster grew leftward straight over it. The mark reveals at md (768px) and those four icons reveal at lg (1024px), so from 1024px to roughly 1150px the cluster's left edge crossed the row midpoint and the leaf painted across the bell and the heart. AFTER: resize in ~32px steps from 1024px to 1280px and watch the gap between the wordmark and the first icon. The leaf must sit in clear space at every single step — no part of it may touch an icon's 44px box.",
+                    href: "/products",
+                },
+                {
+                    key: "mark-clear-signed-out-worst-case",
+                    label: "SIGNED OUT at ~1100px — where 'Sign in' and 'Register' make the cluster widest — the mark is still clear of everything",
+                    description: "Signed out is the worst case, not the easiest: the two auth buttons (~160px together) stand in for a single 44px avatar, so the cluster reaches ~120px further left than it does signed in. This is the exact width and session the original screenshot was taken at. Compare the same width signed in and signed out; both must be clean, and if only one fails say which.",
+                    href: "/products",
+                },
+                {
+                    key: "mark-shifts-rather-than-overlapping",
+                    label: "When the cluster is too wide to leave room, the mark moves off-centre — it never ends up underneath an icon, and no control is clipped at the window edge",
+                    description: "The mark is now one of three in-flow tracks, so a crowded row makes it YIELD. Narrow past the point where a perfectly centred mark would no longer fit and confirm the degradation: the leaf slides toward the wordmark and stays fully visible, the icons keep their full 44px boxes, and nothing is cut off at the right edge. A leaf that vanishes under an icon, or a hamburger sliced by the edge, are both failures — record which.",
+                    href: "/products",
+                },
+                {
+                    key: "mark-centred-at-wide-widths",
+                    label: "At 1440px and wider the leaf is centred in the header, not nudged to one side",
+                    description: "With room to spare the two side tracks split the free space evenly, which should put the leaf on the header's midpoint. Maximise the window and eyeball it against the centre of the page — a mark that is visibly off-centre at a wide width means the tracks are no longer balanced, which is a different fault from the collision and should be reported separately.",
+                    href: "/products",
+                },
+                {
+                    key: "mark-absent-below-md",
+                    label: "At 767px and below there is no centred leaf, the wordmark keeps its own small leaf prefix, and the header has no odd empty gap",
+                    description: "The centred mark is `hidden` below md, which removes it as a layout item entirely — so the header should look exactly as it always has on mobile. Check 767px, 640px and 320px: no centred leaf, a small leaf immediately left of the 'LetItRip' wordmark, the action cluster still flush to the right edge with no stray gap, and the hamburger fully visible and tappable at 320px.",
+                    href: "/products",
+                },
+                {
+                    key: "mark-centred-in-left-hand-mode",
+                    label: "In left-hand mode the wordmark and the icons swap sides, the leaf stays centred, and it still overlaps nothing",
+                    description: "Hand mode mirrors the row, so this is where a layout fix most easily half-works. Turn on left-hand mode, then repeat the 1024px–1280px sweep: the wordmark must sit flush against the RIGHT edge with no gap, the icon cluster flush against the LEFT edge with the hamburger outermost, and the leaf still centred and untouched. A wordmark floating away from its edge means a side track lost its mirrored alignment.",
+                    href: "/products",
+                },
+            ],
+        },
         {
             pageKey: "nav-reachability",
             pageLabel: "Navigation — Every Item Reachable at Every Width",
@@ -6626,6 +7062,24 @@ const rawTesterChecklistItems = [
             pageLabel: "Header search",
             href: "/",
             cases: [
+                {
+                    key: "header-search-submit-lands-on-search",
+                    label: "Submitting the header search lands on /search with GROUPED results — not on one browse page",
+                    description: "BEFORE: submitting sent you to the browse route for whichever type was selected in the dropdown — /products?q=dranzer — so a cross-resource search was unreachable and the /search page it should have used had no users at all. AFTER: you land on /search?q=dranzer and see results grouped by type, each group with its own \"See all … →\" link pointing at that browse page. The per-type destinations are not lost; they moved to where they belong.",
+                    href: "/",
+                },
+                {
+                    key: "header-search-type-is-a-filter",
+                    label: "The type dropdown NARROWS the results — it no longer decides where you land",
+                    description: "BEFORE: choosing \"Stores\" meant submitting took you to /stores. AFTER: choosing \"Stores\" narrows what you see, and the Stores group's own \"See all stores →\" link is what takes you to /stores. Also confirm an EMPTY query does nothing at all on submit — landing on a bare browse page you did not ask for is worse than staying put.",
+                    href: "/",
+                },
+                {
+                    key: "header-search-no-price-for-guest",
+                    label: "Signed out, no suggestion row shows a price",
+                    description: "BEFORE: the suggestion subtitle was the product's price, served from a route cached PUBLIC for 60 seconds — so every signed-out visitor saw prices in the header on every page. AFTER: the subtitle is the brand and category. Any ₹ in the dropdown while signed out is a FAIL.",
+                    href: "/",
+                },
                 {
                     key: "search-finds-maintenance-toggle",
                     label: "Searching 'maintenance' reaches the maintenance TOGGLE, not just Site Settings",
@@ -6711,6 +7165,76 @@ const rawTesterChecklistItems = [
      * tester reporting "I did the actions" as if it were "the outcome was right".
      * ══════════════════════════════════════════════════════════════════════════ */
     ...group("money-flows", "Money Flows (end to end)", moneyFlowsPages),
+    /*
+     * The sticker-sheet kiss-cut tracer. Admin-only, under a PUBLIC prefix.
+     *
+     * 🛑 `adminOnly` is a presentation flag for the checklist, not the gate. The
+     * real boundary is the layout's server-side session read, which redirects a
+     * non-admin before any HTML exists — which is exactly what the buyer and
+     * guest cases below assert. Marking it admin-only here only keeps it out of a
+     * non-admin tester's list.
+     *
+     * Every case is an explicit BEFORE -> AFTER, because almost every defect this
+     * feature can have returns 200 with plausible content: a wrong part count, a
+     * watermarked original, a millimetre derived from a DPI nobody confirmed. A
+     * case reading "check the tracer works" would pass against all three.
+     */
+    ...group("tools", "Tools", [
+        {
+            pageKey: "sticker-tracer",
+            pageLabel: "Sticker sheet tracer",
+            href: "/tools/sticker-tracer",
+            cases: [
+                { key: "enclosed-region-opaque", label: "An enclosed region matching the paper colour stays OPAQUE inside its sticker" },
+                { key: "white-on-white-edge", label: "A white sticker edge on white paper is found with no per-sticker parameter" },
+                { key: "background-model-named", label: "The result names which background model ran (paper vs art)" },
+                { key: "name-required", label: "A run cannot be committed without a name" },
+                { key: "no-watermark-on-original", label: "A downloaded original carries NO watermark and comes from a signed GCS URL" },
+                { key: "progress-names-stage", label: "Live progress names the current STAGE, not just a percentage" },
+                { key: "failure-names-stage", label: "A failed run names the stage it died in and survives a reload" },
+                { key: "runs-never-overwrite", label: "A second run never overwrites the first — both stay in history" },
+                { key: "accepted-differs-from-succeeded", label: "'accepted' and 'succeeded' are distinct, and exactly one run is accepted" },
+                { key: "fullres-only-after-accept", label: "Full-resolution parts and the export surface appear only after accepting" },
+                { key: "no-dpi-no-mm", label: "With no confirmed DPI the export REFUSES rather than inventing a scale" },
+                { key: "oversized-named-not-scaled", label: "A part too wide for the machine is NAMED before export, never scaled" },
+                { key: "node-budget-reported", label: "The export node budget reports its cost in millimetres of deviation" },
+                { key: "retry-shows-clamp", label: "A retry SHOWS the resume clamp before it is applied" },
+                { key: "buyer-redirected", label: "A signed-in buyer is redirected and sees no Tools entry for it" },
+                { key: "guest-redirected", label: "A signed-out visitor is redirected; /tools itself is unaffected" },
+                { key: "storage-meter-honest", label: "The storage meter reports object COUNT beside bytes, and says when it truncated" },
+            ],
+        },
+        {
+            /*
+             * Part Two D — promoting a traced, accepted, promoted-to-full-res
+             * sheet into real marketplace listings. Distinct from the tracer's
+             * own "promote" (run -> sheet, full-res pixels); this is sheet ->
+             * marketplace (real products). Needs a real traced sheet to reach, so
+             * these cases follow the tracer's own happy path rather than
+             * standing alone.
+             */
+            pageKey: "sticker-promote-to-listings",
+            pageLabel: "Promoting a sheet to real listings",
+            href: "/tools/sticker-tracer",
+            cases: [
+                {
+                    key: "promote-creates-one-group",
+                    label: "Promoting a sheet creates one parent listing plus one child per UNIQUE part, all in one group",
+                    description: "On a sheet with at least one part marked a duplicate of another, promote it to listings. The group must contain the parent plus exactly the UNIQUE parts — a duplicate part must NOT get its own listing — and the picker on the parent's product page must show every member, not just one (this is exactly the `linkChildToGroup` stale-append bug: linking N children in a loop used to leave only one).",
+                },
+                {
+                    key: "promoted-part-image-watermarked",
+                    label: "A promoted part's marketplace image is watermarked; the admin's original download is NOT",
+                    description: "Open the promoted CHILD listing's public page and note its image carries a visible watermark. Then, from the tracer's own UI, download that same part's original — it must be clean, with no watermark. Same pixels, same object, two different responses: that is the point.",
+                },
+                {
+                    key: "promote-refuses-before-full-res-render",
+                    label: "Promoting a sheet that has not been accepted-and-rendered is refused, naming the fix",
+                    description: "Attempt to promote a sheet whose active run has not had \"Accept & render\" run on it (or try on a fresh trace with no promoted run). The action must refuse with a message naming the required step (accept/render the run first) — not create partial listings.",
+                },
+            ],
+        },
+    ], { adminOnly: true }),
 ];
 const defaultPhases = assignDefaultPhases(rawTesterChecklistItems);
 export const testerChecklistSeedData = rawTesterChecklistItems.map((item, index) => ({