@mohasinac/appkit 4.42.1 → 4.42.2

package/dist/features/tester/seed-data/authored/page-wiring__reachability.js

@@ -10,6 +10,17 @@
  * A page with no nav entry and a nav entry with no page are the two halves of one
  * defect, and both ship as "half done" without anything failing.
  *
+ * 🛑 Two fixtures pinned on 2026-09-29. Exactly ONE named carousel is seeded
+ * — carousel-hero-default, 'Homepage Hero', status active — so 'the first
+ * carousel' is that one, and its status toggles between exactly two values,
+ * active and draft. The 'Edit carousel' control lives on the DETAIL page
+ * /admin/carousels/{id}, not on the list, which only links to each row.
+ *
+ * Verified before asserting: /admin/events/new really does derive its type list
+ * from ALL_EVENT_TYPES now, so Lottery is in the picker and the first case
+ * should pass. Its own file still carries the note about the local copy that
+ * omitted it, which is why lottery events could once only come from the seeder.
+ *
  * @tag domain:tester
  * @tag layer:seed
  * @tag pattern:none
@@ -29,7 +40,7 @@ export const authored = {
             "Open /admin/lotteries and open the new event's slot editor.",
             "Add three slots numbered 1, 2 and 3, give each a name, and save.",
             "Sign out and sign in as rehan.sheikh@gmail.com / TempPass123!.",
-            "Open the new lottery's public page and pull slot 1.",
+            "Open /lottery/{the new event id} and pull slot 1.",
         ],
         inputs: { eventTitle: "QA Event lottery-created-without-seeding", slotCount: 3, pulledSlot: 1 },
         expectedBehaviour: "A lottery can be built entirely through the UI. The event and its slots are edited in different places on purpose — the slot editor has no fields for title, dates, status or media, so a lottery created there alone would have no dates, and the draw window is measured from them.",
@@ -42,18 +53,24 @@ export const authored = {
         startPage: "/admin/carousels",
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/carousels and read the list.",
-            "Open the first carousel and look for an 'Edit carousel' control.",
-            "Change its name to 'QA Carousel can-be-renamed' and change its status.",
+            "Open /admin/carousels and read the list — one carousel is seeded, 'Homepage Hero', with status active.",
+            "Open /admin/carousels/carousel-hero-default and find its 'Edit carousel' control. It is on this detail page, not on the list.",
+            "Change the name to 'QA Carousel can-be-renamed' and the status from active to draft.",
             "Save.",
-            "RELOAD /admin/carousels and read the name and status.",
-            "Set both back to their original values.",
+            "RELOAD /admin/carousels and read the name and status in the row.",
+            "Set the name back to 'Homepage Hero' and the status back to active, then reload once more to confirm.",
         ],
-        inputs: { newName: "QA Carousel can-be-renamed" },
+        inputs: {
+            carousel: "carousel-hero-default",
+            originalName: "Homepage Hero",
+            newName: "QA Carousel can-be-renamed",
+            statusBefore: "active",
+            statusAfter: "draft",
+        },
         expectedBehaviour: "A named carousel can be edited after creation. The group editor was create-only, so a carousel's name was fixed for its entire life with no path to change it — and /admin/carousels rendered the flat slide editor rather than a list of named carousels at all.",
-        expectedUiState: "The list page shows named carousels, not a bare slide editor. 'Edit carousel' exists, opens with the current values, and after saving and reloading the new name and status are shown.",
+        expectedUiState: "The list page shows named carousels, not a bare slide editor. 'Edit carousel' exists on the detail page, opens with the current values, and after saving and reloading the list row reads 'QA Carousel can-be-renamed' with status draft. Status has exactly two values here — active and draft — so a picker offering more is itself worth noting.",
         expectedData: { editControlPresent: true },
-        endResult: "The name and status are restored by the final step. Other cases read this carousel by its seeded name.",
+        endResult: "The name reads 'Homepage Hero' and the status is active again. Other cases read this carousel by that seeded name, and it is the only one there is.",
     },
     "checklist-page-wiring-reachability-grouped-listing-members-editable-from-its-own-page": {
         roles: ["seller"],
@@ -73,7 +90,7 @@ export const authored = {
             member1: "product-beyblade-burst-valkyrie",
             member2: "product-beyblade-x-wizard-arrow",
             minActiveMembers: 2,
-            coverImage: "public/test-media/sample-image.png",
+            coverImage: "/test-media/sample-image.png",
         },
         expectedBehaviour: "Members are chosen while the group is being created, in the same form. productIds was hardcoded to an empty array, so a group could only ever be created empty and populated from somewhere else — and neither the minimum-active-members nor the cover-image field had an input anywhere in the app.",
         expectedUiState: "All three controls are present on the create form. After saving and reloading, the group holds both products, a minimum of 2, and the uploaded cover image. A group that saves with zero members is the failure.",
@@ -84,15 +101,15 @@ export const authored = {
         roles: ["guest"],
         startPage: "/",
         steps: [
-            "Open / in a private window with no session.",
+            "Signed out, open /.",
             "Click every link in the public header navigation in turn, reading each destination and going back.",
             "Open the sidebar support links and click each one, reading each destination.",
             "Scroll to the footer and click every link in every column, reading each destination.",
             "Write down any link that lands on a not-found page, an empty shell, or back on the homepage.",
         ],
-        expectedBehaviour: "Every public-facing link resolves to a real page with content. The nav audit only ever checked the three portal sidebars, so not one of these 55 hrefs was covered by anything — a rename anywhere in the public surface rotted silently.",
-        expectedUiState: "All 55 destinations render real content. None shows a 404, none renders chrome with an empty body, and none silently redirects back to / — a redirect to the homepage looks like a working link and is not one.",
-        expectedData: { brokenLinkCount: 0 },
+        expectedBehaviour: "Every public-facing link resolves to a real page with content. The nav audit only ever checked the three portal sidebars, so not one of these 62 hrefs was covered by anything — a rename anywhere in the public surface rotted silently.",
+        expectedUiState: "All 62 destinations render real content. None shows a 404, none renders chrome with an empty body, and none silently redirects back to / — a redirect to the homepage looks like a working link and is not one.",
+        expectedData: { brokenLinkCount: 0, linksChecked: 62 },
         endResult: "Read-only; nothing persists. Record every broken href in the comment, not just the first — one report naming all of them is worth more than a verdict.",
     },
     "checklist-page-wiring-reachability-user-tester-hub-reachable-from-user-sidebar": {

package/dist/features/tester/seed-data/authored/public-pages__auth-error-pages.js

@@ -42,11 +42,12 @@ export const authored = {
             "Open /auth/forgot-password in a private window with no session.",
             "Click 'Send reset link' with the field empty and read where the error appears.",
             "Type not-an-email and click 'Send reset link'.",
-            "Type divya.funko@gmail.com and click 'Send reset link'.",
-            "Open that inbox, open the reset link, and read the page it lands on.",
+            "Type divya.funko@gmail.com and click 'Send reset link'. Read only the CONFIRMATION here — the generic 'if an account exists' message is the whole point of this step and needs no inbox.",
+            "🛑 DO NOT COMPLETE A RESET FOR A SEEDED PERSONA. The harness cannot open divya's inbox — both check-inbox.mjs and the emailEvents recorder key on TESTER_EMAIL_ID — and a reset that half-completes leaves a PRESERVE-tier login changed with nothing to restore it from, breaking every other case that signs in as her. For the link half, register a throwaway account on the harness mailbox using a plus-address and request the reset for THAT.",
+            "Capture a timestamp, request the link for the throwaway address, then run: node tester/scripts/check-inbox.mjs --since <that number> --subject \"reset\". Open the link it reports and read the page it lands on.",
             "Submit the reset form with two different passwords typed into its two fields.",
             "Set both fields to QaAuthPages654! and submit.",
-            "Request another link for the same address and use it to set the password back to TempPass123!.",
+            "No restore is needed: the password changed belongs to a throwaway account, not to a seeded persona. Note in your comment that the account remains — the purge script matches only qa-signup+…@letitrip-qa.test, so a Gmail plus-address is not swept automatically.",
         ],
         inputs: {
             email: "divya.funko@gmail.com",
@@ -61,8 +62,8 @@ export const authored = {
         roles: ["guest"],
         startPage: "/auth/register",
         steps: [
-            "Open /auth/register in a private window and create an account with an inbox you can open, using TestPass123! as the password.",
-            "Open the inbox and find the verification email.",
+            "Open /auth/register in a private window and create an account on the HARNESS mailbox using a plus-address — no seeded persona can receive testable email, since both instruments key on TESTER_EMAIL_ID — with TestPass123! as the password.",
+            "Capture a timestamp before registering, then find the verification email: node tester/scripts/check-inbox.mjs --since <that number> --subject \"verify\". Read the exit code — 0 arrived, 1 did not (a defect), 2 could not open the mailbox (a harness problem, answer null).",
             "Open the verification link and read the page it lands on.",
             "Open /user and look for an unverified-email warning.",
             "Open the same verification link a second time and read the page.",
@@ -100,7 +101,7 @@ export const authored = {
         ],
         inputs: { productId: "product-beyblade-burst-valkyrie", price: 199, paymentMethod: "Cash on Delivery" },
         expectedBehaviour: "The success page reads the real order rather than whatever the checkout had in memory, so it survives a reload. It is also order-scoped data, so a signed-out visitor with the URL must not be shown someone's delivery address.",
-        expectedUiState: "The page names an order number, 'Test Gadget — Standard Listing #1' at ₹199.00, the delivery address and a total. After the reload it shows the same. In the private window it does not render the order details — it asks for sign-in or reports not-found.",
+        expectedUiState: "The page names an order number, 'Beyblade Burst Valkyrie' at ₹1,899.00 — the product the steps actually add, the delivery address and a total. After the reload it shows the same. In the private window it does not render the order details — it asks for sign-in or reports not-found.",
         expectedData: { orderTotal: 199 },
         endResult: "The order exists in /user/orders. A success page that goes blank on reload was rendering from checkout state and not from the order.",
     },

package/dist/features/tester/seed-data/authored/public-pages__bug-hunters.js

@@ -25,12 +25,21 @@ export const authored = {
             "Open /bug-hunters in a private window with no session.",
             "Read the rows from the top and note each name and confirmed-bug count.",
             "Check that the counts descend from the first row to the last.",
-            "Look for 'Mock User 18' and read the count beside it.",
+            /*
+             * 'Mock User 3' — the demo fixture's bugHunterName, matching
+             * bugHunterId "user-yugi-muto". This said 'Mock User 18', and there is no
+             * such persona: the seed runs Mock User 1–17 plus two Mock Employees.
+             *
+             * So the tester looked for a name that cannot be on the board, found
+             * nothing, and the case failed for a reason that is not a bug — while
+             * the leaderboard's real behaviour went unchecked.
+             */
+            "Look for 'Mock User 3' and read the count beside it.",
             "Look for the Claude tester account by name anywhere in the list.",
         ],
-        inputs: { seededHunter: "Mock User 18", seededBugCount: 1 },
+        inputs: { seededHunter: "Mock User 3", seededBugCount: 1 },
         expectedBehaviour: "The board ranks testers by confirmed-bug count, highest first, and is fed by the demo fixture under Admin (Testing) → Bug Hunter Rewards. The bot account is excluded because it carries isBot — credit belongs to people, and a runner working the whole checklist would otherwise sit at the top forever.",
-        expectedUiState: "'Mock User 18' appears with 1 confirmed bug. Counts never increase as you read down the list. The Claude tester account does not appear at all.",
+        expectedUiState: "'Mock User 3' appears with 1 confirmed bug. Counts never increase as you read down the list. The Claude tester account does not appear at all.",
         expectedData: { botAccountOnLeaderboard: 0 },
         endResult: "Read-only; nothing persists. A bot row on the board is a fail even if the ordering is otherwise correct.",
     },
@@ -39,7 +48,7 @@ export const authored = {
         startPage: "/bug-hunters",
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/tester-feedback and find the confirmed bug credited to 'Mock User 18'.",
+            "Open /admin/tester-feedback and find the confirmed bug credited to 'Mock User 3'.",
             "Un-confirm it, so no confirmed bugs remain.",
             "Open /bug-hunters in a private window with no session.",
             "Read the page.",
@@ -47,7 +56,7 @@ export const authored = {
             "Reload /bug-hunters in the private window.",
         ],
         expectedBehaviour: "With nothing to rank the page shows a named empty state rather than a blank container or an error. Zero rows is a normal condition for this page on a new install, not a failure.",
-        expectedUiState: "With no confirmed bugs the page reads 'No confirmed bugs yet' or equivalent, inside the normal site chrome. It is not a blank white page, not an error boundary, and not a heading with nothing under it. After re-confirming, 'Mock User 18' is back.",
+        expectedUiState: "With no confirmed bugs the page reads 'No confirmed bugs yet' or equivalent, inside the normal site chrome. It is not a blank white page, not an error boundary, and not a heading with nothing under it. After re-confirming, 'Mock User 3' is back.",
         expectedData: { emptyStateShown: true },
         endResult: "The confirmation is restored by the final step, so the leaderboard-loads case above still has its fixture. Leaving it un-confirmed silently breaks that case.",
     },

package/dist/features/tester/seed-data/authored/public-pages__core-listing-pages.js

@@ -40,7 +40,7 @@ export const authored = {
         startPage: "/",
         steps: [
             "Open / on a device or emulator with WhatsApp installed.",
-            "Find the 'Join the Community' button and read the URL it points at.",
+            "Find the WhatsApp community button — its default label is 'Join our WhatsApp community', not 'Join the Community' — and read the URL it points at.",
             "Tap it and read what WhatsApp shows.",
             "Open /contact and find its WhatsApp link.",
             "Read that URL and compare it with the first.",
@@ -83,14 +83,14 @@ export const authored = {
         steps: [
             "Open /about in a private window with no session.",
             "Scroll to the 'Our Values' section.",
-            "Count the values listed.",
+            "Count the values listed, and read whether each has a second smaller paragraph under its heading.",
             "Read each one for a second, smaller paragraph beneath its heading.",
             "Find the 'How we hold ourselves to this →' link and click it.",
             "Read the address bar.",
         ],
         inputs: { expectedValueCount: 6 },
         expectedBehaviour: "The section carries six values, each with a subtitle paragraph, and links onward to the Ethics page — where the commitments are actually detailed. Values with no onward link are a statement with nothing behind it.",
-        expectedUiState: "Six values are shown, not three. Each has a second smaller paragraph under its heading rather than a heading alone. The link is present and lands on /ethics.",
+        expectedUiState: "Six values are shown, not three, each with a second smaller paragraph under its heading, and the link lands on /ethics. 🛑 EXPECT THREE WITHOUT SUBTITLES ON A FRESHLY-SEEDED ENVIRONMENT, and record that as a CONTENT gap rather than a UI failure: appkit/src/seed/site-settings-seed-data.ts ships three valueItems and none of them carries a `detail` field, so it predates this expansion. aboutContent lives in siteSettings, which is PRESERVE-tier and never reseeded, so production holds whatever an admin last saved and may well show six. Report the count you actually see and which environment you saw it in — the link and the subtitle rendering are separately testable and the link should work either way.",
         expectedData: { valueCount: 6, ethicsHref: "/ethics" },
         endResult: "Read-only; nothing persists.",
     },

package/dist/features/tester/seed-data/authored/public-pages__help-how-it-works.js

@@ -100,7 +100,7 @@ export const authored = {
         steps: [
             "Open /how-emi-works signed out and read the whole page.",
             "Write down the eligibility threshold it states and the worked example it gives.",
-            "Sign in as rehan.sheikh@gmail.com / TempPass123! and put live-golden-retriever-puppy in the cart.",
+            "Switch identity before continuing: this case is roles [guest] and the harness gives a guest batch NO session at all, so copy tester/.tester-runs/session-buyer.json over session.json and CLOSE THE BROWSER first — the MCP reads that file only at context creation. Then sign in as rehan.sheikh@gmail.com / TempPass123! and put live-golden-retriever-puppy in the cart. That fixture is priced at 25,000, comfortably over the seeded EMI minOrderValue of 10,000, so EMI should be offered; a cheaper item would show no EMI for the right reason and read as a failure.",
             "Reach the payment step and read the instalment figures offered.",
             "Compare them against the page's worked example.",
             "Empty the cart, add product-beyblade-burst-valkyrie instead, and check EMI is NOT offered below the threshold.",

package/dist/features/tester/seed-data/authored/public-pages__help-scams-guides-subpages.js

@@ -129,9 +129,11 @@ export const authored = {
         roles: ["buyer", "admin"],
         startPage: "/scams/report",
         steps: [
+            "START AS THE BUYER. This case lists roles [buyer, admin] and the harness resolves that to the ADMIN session — admin wins whenever it is present — so the batch opens as the wrong person for this first half. Copy tester/.tester-runs/session-buyer.json over session.json and CLOSE THE BROWSER before continuing; the MCP reads that file only when the context is created.",
             "Sign in as rehan.sheikh@gmail.com / TempPass123! and submit a report with the description 'QA scam report routing probe — checklist case.'",
+            "Switch identity before continuing: copy tester/.tester-runs/session-admin.json over tester/.tester-runs/session.json and CLOSE THE BROWSER first — the MCP server reads that file when the context is created, so copying it over an open browser changes nothing and the next steps run as the previous person.",
             "Sign in as admin@letitrip.in / TempPass123!.",
-            "Find that report in an admin surface.",
+            "Find that report at /admin/scammers — the scam-report queue — and if it is not there, check /admin/reports before concluding it did not route.",
             "Open it and read the description and the reporter.",
             "Check it can be actioned — accepted, rejected or turned into a registry entry.",
             "Remove the QA report if the interface allows.",
@@ -162,7 +164,7 @@ export const authored = {
         steps: [
             "Open /seller-guide signed out and read its content.",
             "Note whether it reads as marketing for prospective sellers or as a dashboard manual.",
-            "Sign in as tyson@beybladearena.in / TempPass123! and open /store/guide.",
+            "Do NOT sign in — this case is signed out by design and the harness gives a guest batch no session at all. The comparison against the seller-dashboard hub at /store/guide belongs to selling/seller-guide, which runs as the seller; note here only that /seller-guide is a DIFFERENT, public page and not that hub.",
             "Read that content.",
             "Compare the two.",
             "Check neither is a copy of the other.",

package/dist/features/tester/seed-data/authored/public-pages__legal-policy-pages.js

@@ -108,13 +108,13 @@ export const authored = {
         startPage: "/admin/site",
         steps: [
             "Open /ethics in a private window and read the first paragraph.",
-            "Sign in as admin@letitrip.in / TempPass123! in a normal window.",
-            "Open /admin/site?tab=legal and find the 'Our Ethics' textarea.",
+            "Sign in as admin@letitrip.in / TempPass123!. This case lists roles [admin, guest] and resolves to ADMIN, so the batch already opens signed in; the guest reads below can be done in a private window, or by swapping tester/.tester-runs/session-guest.json over session.json and closing the browser between each switch.",
+            "Open /admin/site?tab=legal and find the 'Our Ethics' textarea. WRITE DOWN exactly what it contains before typing — the seed ships legalPages.ethics as an empty string, but siteSettings is PRESERVE-tier and never reseeded, so on a long-lived environment an admin may have authored real policy copy there.",
             "Type <p>QA Ethics policy-admin-html-override</p> into it.",
             "Save.",
             "Return to the private window and reload /ethics immediately.",
             "Read the first paragraph.",
-            "Go back to the admin textarea, clear it completely, and save again.",
+            "Go back to the admin textarea and RESTORE exactly what step 3 recorded — which on a fresh seed means clearing it, since the field ships empty, but on any other environment means putting the original copy back. Clearing a field that held real policy text is not a restore. Save again.",
             "Reload /ethics in the private window once more.",
         ],
         inputs: { override: "<p>QA Ethics policy-admin-html-override</p>" },

package/dist/features/tester/seed-data/authored/public-pages__newly-wired-browse-indexes.js

@@ -24,7 +24,7 @@ export const authored = {
         roles: ["guest"],
         startPage: "/",
         steps: [
-            "Open the homepage and scroll to the footer.",
+            "Open the homepage and scroll to the footer. Of the six indexes, THREE are redirect shims into the catalogue (/classified, /digital-codes, /live -> /products?listingType=…) and three are real pages (/lottery, /sellers, /brands). A footer link that lands on /products carrying a query has worked; judge each by where it ends up, not by whether the URL changed.",
             "Read the Shop column and list every link in it.",
             "Click Classifieds and confirm where it lands.",
             "Go back and repeat for Digital Codes, Live Items, Lotteries, Brands and Verified Sellers.",
@@ -38,7 +38,7 @@ export const authored = {
         roles: ["guest"],
         startPage: "/classified",
         steps: [
-            "Open /classified.",
+            "Open /classified. 🛑 IT REDIRECTS to /products?listingType=classified, and that IS the wiring this page exists to confirm — the per-type browse indexes were folded into the one catalogue with a type filter, so landing on /products with a query is the design, not a broken link. Everything below is read on that filtered catalogue.",
             "Read the badge on each of the first six cards.",
             "Open the first card and read the badge on its detail page.",
             "Note the URL the card led to.",
@@ -52,7 +52,7 @@ export const authored = {
         roles: ["guest"],
         startPage: "/digital-codes",
         steps: [
-            "Open /digital-codes.",
+            "Open /digital-codes. It redirects to /products?listingType=digital-code — same folding as /classified.",
             "Read the badge on each of the first six cards.",
             "Open the first card and confirm the URL it leads to.",
             "Read whether the detail page states how many codes remain.",
@@ -66,7 +66,7 @@ export const authored = {
         roles: ["guest"],
         startPage: "/live",
         steps: [
-            "Open /live.",
+            "Open /live. It redirects to /products?listingType=live — same folding as /classified.",
             "Read the badge on every card shown.",
             "Open the first card and confirm the URL.",
             "Read whether the detail page shows the species and jurisdiction fields a live item carries.",
@@ -128,7 +128,7 @@ export const authored = {
         startPage: "/classified",
         steps: [
             "Open a private window with no session.",
-            "Open each of /classified, /digital-codes, /live, /lottery, /brands and /sellers in turn.",
+            "Open each of /classified, /digital-codes, /live, /lottery, /brands and /sellers in turn. The first three redirect into /products?listingType=… — expected, and not a sign the gate broke navigation — while the last three are real pages.",
             "On each, confirm cards render and note what appears where a price would be.",
             "Open one listing detail page from a price-bearing index.",
             "Read the price area on that detail page.",

package/dist/features/tester/seed-data/authored/public-pages__store-tabs.js

@@ -23,7 +23,7 @@ export const authored = {
         roles: ["guest"],
         startPage: "/stores",
         steps: [
-            "Open /stores and click through to Beyblade Arena.",
+            "Open /stores and click through to Beyblade Arena. The store URL /stores/store-beyblade-arena redirects to /stores/store-beyblade-arena/products — that redirect IS the default-tab behaviour this case is checking, so landing on a /products URL is the pass condition rather than a surprise.",
             "Note which tab is selected on arrival.",
             "Count the listings shown and read the total the pager reports.",
             "Open two of the cards and read which store each says it belongs to.",
@@ -52,9 +52,9 @@ export const authored = {
     },
     "checklist-public-pages-store-tabs-empty-tab-says-empty": {
         roles: ["guest"],
-        startPage: "/stores/store-beyblade-arena",
+        startPage: "/stores/store-letitrip-official",
         steps: [
-            "Open Beyblade Arena and work through every tab in turn.",
+            "Open /stores/store-letitrip-official and work through all twelve tabs in turn: Products, Auctions, Pre-orders, Prize Draws, Classified, Digital Codes, Live, Art, Bundles, Coupons, Reviews, About. 🛑 USE THIS STORE, NOT Beyblade Arena: the official store carries SIX listings and every one is a prize draw, so eleven of its twelve tabs are genuinely empty. Beyblade Arena has stock in every single type, so it has no empty tab to find and the case cannot be performed there at all.",
             "Find one that lists nothing.",
             "Wait for it to finish loading before judging it.",
             "Read what it shows.",
@@ -85,8 +85,8 @@ export const authored = {
         roles: ["guest"],
         startPage: "/stores/store-letitrip-official",
         steps: [
-            "Open /stores/store-letitrip-official — a store with a small catalogue, so a leak is obvious.",
-            "Work through every tab and read the store name on each card.",
+            "Open /stores/store-letitrip-official — SIX listings, all of them prize draws, which is what makes a leak obvious: any card on any other tab belongs to someone else, and the Prize Draws tab should hold exactly six.",
+            "Work through all twelve tabs and read the store name on each card: Products, Auctions, Pre-orders, Prize Draws, Classified, Digital Codes, Live, Art, Bundles, Coupons, Reviews, About.",
             "Note any card naming a different store.",
             "Open one card and confirm on its detail page which store it belongs to.",
         ],

package/dist/features/tester/seed-data/authored/public-pages__stores-sellers-directories.js

@@ -180,10 +180,10 @@ export const authored = {
     },
     "checklist-public-pages-stores-sellers-directories-store-tab-empty-state-not-error": {
         roles: ["guest"],
-        startPage: "/stores/store-vintage-vault-co",
+        startPage: "/stores/store-letitrip-official",
         steps: [
-            "Open /stores/store-vintage-vault-co in a private window with no session.",
-            "Open every tab offered and find one that is genuinely empty.",
+            "Open /stores/store-letitrip-official in a private window with no session. 🛑 NOT store-vintage-vault-co, which this case used to name: that store is SUSPENDED with isPublic false, and getStoreBySlug returns null unless status is ACTIVE and isPublic is true — so its public page calls notFound(). A tester would meet a 404 and have to judge an empty state on a page that does not exist.",
+            "Open every tab offered and find one that is genuinely empty. This store carries SIX listings, all prize draws, so eleven of its twelve tabs are empty and one is not — which gives both halves of the comparison.",
             "Read exactly what is shown in that empty tab.",
             "Wait 10 seconds and read it again.",
             "Check for any error toast anywhere on the page.",

package/dist/features/tester/seed-data/authored/search-and-nav__employee-permissions.js

@@ -19,6 +19,38 @@
  * @tag consumers:seed-data/authored/index.ts
  * @tag sideEffects:none
  */
+/*
+ * Measured on 2026-09-29 with `node scripts/diff-employee-sidebar.mjs`, which
+ * exists for exactly this and computes what every preset sees:
+ *
+ *   total                 90 items across 12 groups (the case said 91)
+ *   blog_poster           sees  5
+ *   trust_and_safety      sees 24
+ *   maintenance_employee  sees 77  (the most permissive preset)
+ *   20 presets in all, and the SMALLEST is 5
+ *
+ * The nine groups the first case names as vanishing for the blog employee are
+ * exactly the nine the script reports: Finance, Procurement, Catalog, Testing,
+ * Site, Events, Trust & Safety, System, Maintenance. That is a strong
+ * confirmation, so the case is kept as written apart from the count.
+ *
+ * 🛑 THE SECOND CASE ASKED FOR 20 SIGN-IN CYCLES to prove something the repo
+ * already computes. Setting each preset as admin, signing in as the employee
+ * and counting, twenty times over, is most of a session; and the answer is in
+ * the script above, where the smallest preset is 5 and no preset reaches zero.
+ * It now checks two presets by hand and defers the sweep to the script, which
+ * is the difference between a case a tester will run and one they will skip.
+ *
+ * Two things the script itself reports and neither case mentioned:
+ *
+ *   — 45 distinct preset permissions gate NO sidebar entry at all; they gate
+ *     routes and actions instead. So a preset can differ from another in
+ *     permissions and not differ in sidebar count, and identical counts
+ *     between two presets are not automatically the bug.
+ *   — An employee with hand-picked `permissions[]` rather than a preset is NOT
+ *     covered by any of this. That is a real coverage gap, recorded here
+ *     rather than silently left out.
+*/
 export const authored = {
     "checklist-search-and-nav-employee-permissions-employee-sees-only-their-permissions": {
         roles: ["employee", "admin"],
@@ -33,9 +65,9 @@ export const authored = {
             "Sign out and sign in as admin@letitrip.in / TempPass123!, then open /admin and count the entries.",
         ],
         inputs: { blogEmployee: "employee-blog@letitrip.in", trustEmployee: "employee-trust@letitrip.in" },
-        expectedBehaviour: "Nav filtering keys on each item's own id to look up its required permission. The filter short-circuits when an item has no id, and for a long time no item had one — so all 91 entries passed for everybody and every requiredPermission in the config was decorative. A group left with no visible children is removed entirely rather than rendering an empty heading.",
-        expectedUiState: "The blog employee sees roughly five entries, not 91. Finance, Procurement, Catalog, Testing, Site, Events, Trust & Safety, System and Maintenance are absent as headings, not present-and-empty. The trust employee sees a different set, roughly 24. The admin sees everything. Three genuinely different counts is the pass; three identical counts is the exact bug.",
-        expectedData: { blogEntriesApprox: 5, trustEntriesApprox: 24 },
+        expectedBehaviour: "Nav filtering keys on each item's own id to look up its required permission. `filterNavItems` opens with `if (!item.id) return true;` and no item in the config had one — so all 90 entries passed for everybody and every requiredPermission was decorative. A group left with no visible children is removed entirely rather than rendering an empty heading.",
+        expectedUiState: "The blog employee sees FIVE entries, not 90. Finance, Procurement, Catalog, Testing, Site, Events, Trust & Safety and System and Maintenance are absent as HEADINGS, not present-and-empty. The trust employee sees 24. The admin sees all 90 across 12 groups. Three genuinely different counts is the pass; three identical counts is the exact bug — and 90 for all three is the specific bug this replaced.",
+        expectedData: { blogEntries: 5, trustEntries: 24, adminEntries: 90, adminGroups: 12 },
         endResult: "Read-only; nothing persists. Comparing two presets against each other AND against admin is what distinguishes real filtering from a filter that happens to hide the same fixed set from everyone.",
     },
     "checklist-search-and-nav-employee-permissions-employee-sidebar-never-empty": {
@@ -44,16 +76,18 @@ export const authored = {
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
             "Open /admin/team and open the editor for employee-blog@letitrip.in.",
-            "Read every permission preset the editor offers and write the list down.",
-            "Set the account to the first preset and save.",
+            "Read every permission preset the editor offers and count them — there are 20.",
+            "Set the account to blog_poster, the smallest preset, and save.",
             "Sign out, sign in as employee-blog@letitrip.in / TempPass123!, open /admin and count the sidebar entries.",
-            "Repeat for every remaining preset: set it as admin, then sign in as the employee and count.",
-            "Set the account back to the blog poster preset as the last step.",
+            "Sign back in as admin, set the account to maintenance_employee, the most permissive preset, and save.",
+            "Sign in as the employee again and count the entries.",
+            "Sign back in as admin and set the account back to blog_poster as the last step.",
+            "For the remaining 18 presets, run `node scripts/diff-employee-sidebar.mjs` rather than signing in 18 more times — it computes every preset's count from the same config the sidebar reads.",
         ],
         inputs: { employee: "employee-blog@letitrip.in" },
-        expectedBehaviour: "No preset produces a completely blank sidebar. At minimum every employee reaches the dashboard itself, so the portal is navigable from the moment they sign in.",
-        expectedUiState: "For every preset, at least one entry is visible in the sidebar. A blank sidebar is the failure — an employee cannot tell it from a broken account and will report it as one, which is a support ticket the permission system caused rather than prevented.",
-        expectedData: { minimumVisibleEntries: 1 },
-        endResult: "The account is back on the blog poster preset, which the case above depends on. Leaving it on another preset silently breaks that case's expected count of roughly five.",
+        expectedBehaviour: "No preset produces a completely blank sidebar. At minimum every employee reaches the dashboard itself, so the portal is navigable from the moment they sign in. Measured: the smallest of the 20 presets is blog_poster at 5 entries and the largest is maintenance_employee at 77, so the floor is well clear of zero.",
+        expectedUiState: "Both presets checked by hand show entries — 5 for blog_poster and 77 for maintenance_employee — and the script reports no preset below 5. A blank sidebar is the failure: an employee cannot tell it from a broken account and will report it as one, which is a support ticket the permission system caused rather than prevented.",
+        expectedData: { blogPosterEntries: 5, maintenanceEmployeeEntries: 77, presetCount: 20 },
+        endResult: "The account is back on blog_poster, which the case above depends on. Leaving it on another preset silently breaks that case's expected count of exactly 5.",
     },
 };

package/dist/features/tester/seed-data/authored/search-and-nav__header-search.js

@@ -18,30 +18,70 @@
  * @tag consumers:seed-data/authored/index.ts
  * @tag sideEffects:none
  */
+/*
+ * 🛑 THIS IS THE SIDEBAR SEARCH, NOT THE HEADER SEARCH (corrected 2026-09-29).
+ *
+ * All four cases said to open / and click into the header search. Two things
+ * are wrong with that. The public header's Search is a CATALOGUE search: it
+ * carries a resource-type dropdown and navigates to a listing URL with ?q=,
+ * so it never returns a settings toggle or an admin screen. And on / there is
+ * no admin sidebar at all.
+ *
+ * The search these cases describe is `useSidebarSearch`, mounted in each
+ * portal's sidebar, and its own header states exactly what they assert:
+ *
+ *   "refund found nothing, because the screen is called Payouts. postcode
+ *    found nothing, because the field is called PIN code. maintenance found
+ *    nothing, because that toggle lives inside Site Settings."
+ *
+ * and the ranking rule they turn on:
+ *
+ *   "A label hit beats a keyword hit beats a description hit, so typing
+ *    orders puts Orders above the guide that merely mentions orders."
+ *
+ * Groups keep their declared order deliberately, so ranking is WITHIN a group.
+ * A case expecting one flat list ranked end to end would misread that.
+ *
+ * 🛑 AND THERE IS A NAV GROUP TITLED 'Maintenance', with Overview, Server
+ * Errors, Client Errors and Function Errors under it. The first case claimed
+ * no nav item is called Maintenance and that a label-matching search returns
+ * nothing for the word. Both are false, and the corrected case uses that: the
+ * query must return BOTH the Maintenance group and the Site Settings entry
+ * whose keywords carry 'maintenance mode', which is the harder half.
+ *
+ * The Maintenance mode toggle really is on the Branding tab, verified at
+ * AdminSiteSettingsView's `setting-maintenance-mode` anchor. But that is tab
+ * TWO of TWENTY, not one of nineteen.
+ *
+ * Case 4's filter is by CONSTRUCTION rather than by a permission check — each
+ * portal's sidebar is built from its own nav groups, so a buyer's sidebar has
+ * no admin items to surface. That is a stronger guarantee than filtering, and
+ * the case now says so instead of implying a runtime check it does not make.
+*/
 export const authored = {
     "checklist-search-and-nav-header-search-search-finds-maintenance-toggle": {
         roles: ["admin"],
-        startPage: "/",
+        startPage: "/admin",
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open / and click into the header search.",
+            "Open /admin and click into the sidebar search box.",
             "Type maintenance.",
             "Read the results.",
-            "Click the maintenance quick link.",
-            "Read which tab of Site Settings is open and what is on screen.",
+            "Read whether BOTH the Maintenance nav group and the Site Settings entry are returned, then click the Site Settings entry.",
+            "Read which tab of Site Settings opens and whether the Maintenance mode toggle is on screen.",
         ],
         inputs: { query: "maintenance" },
-        expectedBehaviour: "Search reaches individual SETTINGS, not just screens. No nav item is called Maintenance, so a label-matching search returns nothing for this word — and the toggle lives on tab one of nineteen with no way to find it but hunting.",
-        expectedUiState: "A quick link for maintenance appears in the results. Clicking it opens Site Settings on the Branding tab with the Maintenance mode toggle scrolled into view. Landing on Site Settings' first tab with the toggle somewhere off screen is a FAIL, not a partial pass.",
-        expectedData: { resultCount: 1 },
+        expectedBehaviour: "Search reaches individual SETTINGS, not just screens. There IS a nav group called Maintenance, so the word finds those pages on its label alone — the harder half is the Site Settings entry, which matches only through its keywords, and whose Maintenance mode toggle sits on tab two of twenty with no way to find it but hunting.",
+        expectedUiState: "The results include the Maintenance nav group AND the Site Settings entry. Opening Site Settings lands on the Branding tab with the Maintenance mode toggle on screen. Landing on the About tab, which is the first of twenty, with the toggle somewhere below is a FAIL rather than a partial pass. Returning only the Maintenance pages and not Site Settings means keyword matching is not running — that is the finding this case exists for.",
+        expectedData: { siteSettingsReturned: true, maintenanceGroupReturned: true },
         endResult: "Read-only; do not flip the toggle. Turning on maintenance mode would take the site down for every other case in the run.",
     },
     "checklist-search-and-nav-header-search-search-finds-by-what-it-does": {
         roles: ["admin"],
-        startPage: "/",
+        startPage: "/admin",
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open / and click into the header search.",
+            "Open /admin and click into the sidebar search box.",
             "Type refund and read the results.",
             "Clear the box, type postcode and read the results.",
             "Clear the box, type cod and read the results.",
@@ -55,33 +95,33 @@ export const authored = {
     },
     "checklist-search-and-nav-header-search-search-ranks-exact-first": {
         roles: ["admin"],
-        startPage: "/",
+        startPage: "/admin",
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open / and click into the header search.",
+            "Open /admin and click into the sidebar search box.",
             "Type orders.",
             "Read the results in order from the top.",
         ],
         inputs: { query: "orders" },
-        expectedBehaviour: "An exact label match outranks an entry that merely mentions the word in its description. With no ranking at all the results fall into alphabetical order and the thing actually called Orders can land ninth.",
-        expectedUiState: "The entry named Orders is first. Guides and settings whose descriptions mention orders appear below it. Orders appearing anywhere but first is the failure, even though it is present.",
+        expectedBehaviour: "An exact label match outranks a keyword hit, which outranks a description hit. With no ranking the results fall into declaration order and the thing actually called Orders can land well down the list. Ranking is WITHIN each group — groups keep their declared order on purpose, so that the sidebar does not rearrange itself under the reader while they type.",
+        expectedUiState: "Within its own group, the entry named Orders is first. Guides and settings whose descriptions merely mention orders rank below it, inside their own groups. Orders appearing below a description-only match IN THE SAME GROUP is the failure, even though it is present. Do not expect one flat list — groups are not reordered by score.",
         expectedData: { exactMatchPosition: 1 },
         endResult: "Read-only; nothing persists.",
     },
     "checklist-search-and-nav-header-search-search-never-shows-what-you-cannot-reach": {
         roles: ["buyer"],
-        startPage: "/",
+        startPage: "/user",
         steps: [
             "Sign in as rehan.sheikh@gmail.com / TempPass123!, an ordinary buyer.",
-            "Open / and click into the header search.",
+            "Open /user and click into the sidebar search box — a buyer has a user sidebar, not an admin one.",
             "Type users and read every result.",
             "Clear the box, type payouts and read every result.",
             "Clear the box, type maintenance and read every result.",
             "Clear the box, type orders and read every result.",
         ],
         inputs: { query1: "users", query2: "payouts", query3: "maintenance", query4: "orders" },
-        expectedBehaviour: "Results are filtered by what this viewer may actually reach. The labels alone are a site map of the admin panel, so an entry a buyer cannot open is one they must not be shown — hiding the destination behind a 403 is not enough.",
-        expectedUiState: "'users', 'payouts' and 'maintenance' return no admin entries at all — not greyed out, not present-but-unclickable, absent. 'orders' still returns the buyer's OWN orders page, which proves the filter is scoping rather than simply returning nothing.",
+        expectedBehaviour: "A buyer can never surface an admin entry, and the reason is stronger than filtering: each portal builds its sidebar from its OWN nav groups, so there are no admin items in a buyer's list to match against. The labels alone would be a site map of the admin panel, so absence by construction is the right answer — hiding the destination behind a 403 would not be.",
+        expectedUiState: "'users', 'payouts' and 'maintenance' return no admin entries at all — not greyed out, not present-but-unclickable, absent. 'orders' still returns the buyer's OWN orders page, which is the control: a search returning nothing for everything would pass the first three for the wrong reason.",
         expectedData: { adminResultsForBuyer: 0 },
         endResult: "Read-only; nothing persists. The fourth query is the control — a search that returned nothing for everything would pass the first three for the wrong reason.",
     },