@mohasinac/appkit 4.58.0 → 4.60.0

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

@@ -1,185 +0,0 @@
-/*
- * WHY: Authored six-part procedures for the search-and-nav/header-search page.
- * WHAT: 4 case(s), keyed by full checklist id.
- *
- * Written by hand, case by case, against the label each one states. There is no
- * generator: the authoring scripts were deleted once it was clear they were
- * scaffolding around work that is simply writing.
- *
- * Every one of these searches for a word that does NOT appear in the label of
- * what it should find. That is the point of the whole page: matching labels is
- * the behaviour being replaced, so a query whose answer is in its own label
- * cannot tell the two apart.
- *
- * @tag domain:tester
- * @tag layer:seed
- * @tag pattern:none
- * @tag access:server-only
- * @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: "/admin",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin and click into the sidebar search box.",
-            "Type maintenance.",
-            "Read the results.",
-            "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. 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: "/admin",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "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.",
-            "Clear the box, type zzzznope and read the results.",
-        ],
-        inputs: { query1: "refund", query2: "postcode", query3: "cod", nonsenseQuery: "zzzznope" },
-        expectedBehaviour: "Entries carry a description and keywords, so a user who knows what they want to DO finds the screen without knowing what it is called. None of these three words appears in the label of what it finds.",
-        expectedUiState: "'refund' returns Payouts. 'postcode' returns Addresses. 'cod' returns the Cash on delivery toggle. 'zzzznope' returns an empty state — the control that proves the box is matching rather than listing everything.",
-        expectedData: { nonsenseResultCount: 0 },
-        endResult: "Read-only; nothing persists.",
-    },
-    "checklist-search-and-nav-header-search-search-ranks-exact-first": {
-        roles: ["admin"],
-        startPage: "/admin",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "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 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: "/user",
-        steps: [
-            "Sign in as rehan.sheikh@gmail.com / TempPass123!, an ordinary buyer.",
-            "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: "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.",
-    },
-};
-/*
- * ── The header now reaches /search (2026-10-19) ─────────────────────────
- *
- * One `onSearch` handler was the entire reason the cross-resource results
- * page had no users: it mapped the type dropdown to a browse route and
- * redirected there, so a buyer searching "dranzer" never learned there is
- * also a category, a part, a blog post and an FAQ about it.
- */
-export const authoredIndexEra = {
-    "checklist-search-and-nav-header-search-header-search-submit-lands-on-search": {
-        roles: ["guest"],
-        startPage: "/",
-        steps: [
-            "Open / in a private window.",
-            "Click the header search and type dranzer.",
-            "Press Enter.",
-            "Read the URL in the address bar.",
-            "Count the section headings on the page.",
-            "Find the 'See all … →' link on one group and read where it points.",
-        ],
-        inputs: { query: "dranzer" },
-        expectedBehaviour: "Submitting goes to the cross-resource page. The nine per-type browse routes are not lost — each is its own group's 'See all' link, which is where a per-type destination belongs once results are grouped.",
-        expectedUiState: "The URL is /search?q=dranzer. Results appear under several headings. Any URL of the form /products?q=… or /stores?q=… means the old redirect is still in place.",
-        endResult: "Read-only; nothing persists.",
-    },
-    "checklist-search-and-nav-header-search-header-search-type-is-a-filter": {
-        roles: ["guest"],
-        startPage: "/",
-        steps: [
-            "Open / in a private window.",
-            "Open the header search and set the type dropdown to Stores.",
-            "Type beyblade and press Enter.",
-            "Read the URL and the sections shown.",
-            "Find the Stores group and click its 'See all stores →' link.",
-            "Go back, clear the query completely, and press Enter with an EMPTY box.",
-            "Note whether the page navigated anywhere.",
-        ],
-        inputs: { type: "Stores", query: "beyblade" },
-        expectedBehaviour: "The dropdown narrows the result set; it no longer decides the destination. An empty query does nothing, because landing on a browse page you did not ask for is worse than staying put.",
-        expectedUiState: "You land on /search, not /stores. The Stores group's 'See all' link is what goes to /stores. Submitting an empty box leaves you exactly where you were.",
-        endResult: "Read-only; nothing persists.",
-    },
-    "checklist-search-and-nav-header-search-header-search-no-price-for-guest": {
-        roles: ["guest"],
-        startPage: "/",
-        steps: [
-            "Open / in a private window with no session.",
-            "Click the header search and type dranzer.",
-            "Read every suggestion row, including the small grey second line.",
-            "Look specifically for a ₹ figure anywhere in the dropdown.",
-        ],
-        inputs: { query: "dranzer" },
-        expectedBehaviour: "The suggestion subtitle used to be the product's price, from an unauthenticated route cached publicly for 60 seconds — so every signed-out visitor saw prices in the header on every page of the site.",
-        expectedUiState: "Subtitles read as brand and category, e.g. 'Takara-Tomy · Attack Rings'. Any ₹ in the dropdown while signed out is a FAIL.",
-        endResult: "Read-only; nothing persists.",
-    },
-};

package/dist/features/tester/seed-data/authored/search-and-nav__settings-deep-links.d.ts

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

package/dist/features/tester/seed-data/authored/search-and-nav__settings-deep-links.js

@@ -1,82 +0,0 @@
-/*
- * WHY: Authored six-part procedures for the search-and-nav/settings-deep-links page.
- * WHAT: 2 case(s), keyed by full checklist id.
- *
- * Written by hand, case by case, against the label each one states. There is no
- * generator: the authoring scripts were deleted once it was clear they were
- * scaffolding around work that is simply writing.
- *
- * @tag domain:tester
- * @tag layer:seed
- * @tag pattern:none
- * @tag access:server-only
- * @tag consumers:seed-data/authored/index.ts
- * @tag sideEffects:none
- */
-/*
- * Verified on 2026-09-29, and both cases are right, including the detail most
- * likely to be wrong: the default really IS branding. `activeTab` is
- *
-  *   useState(() => { if (typeof window === "undefined") return "branding";
-  *                    const requested = new URLSearchParams(...).get("tab");
-  *                    return isSiteSettingsTabId(requested) ? requested : "branding"; })
- *
- * so an unknown or empty value falls through to branding with no complaint,
- * which is exactly what the second case asserts. The tab id is validated
- * against the union rather than trusted.
- *
- * 🛑 DO NOT infer the default from the JSX. `about` is the first
- * SettingsTabForm in the file, so reading the markup suggests the page opens
- * there; it does not, because the default is explicit state. The 20 valid ids
- * in declaration order are:
- *
- *   about branding appearance themes announcement seo contact watermark fees
- *   integrations shipping auction limits legal whatsapp notifications
- *   procurement emi gst listings
- *
- * 🛑 AND THE FIRST PAINT IS ALWAYS BRANDING. The initialiser returns branding
- * when `window` is undefined, so the server-rendered tab is branding and the
- * URL's tab is applied on hydration. On a slow load a tester can briefly see
- * Branding before Fees appears. That is the deep link working, not failing,
- * and the case now says so rather than leaving it to be reported.
- *
- * Note `ADMIN_SETTINGS_TABS` is a DIFFERENT registry {actions, navigation} for
- * /admin/settings/*. The guard that matters here is `isSiteSettingsTabId` in
- * site-settings-tabs.ts; chasing the wrong constant leads to a two-tab list.
-*/
-export const authored = {
-    "checklist-search-and-nav-settings-deep-links-tab-query-param-opens-that-tab": {
-        roles: ["admin"],
-        startPage: "/admin/site",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/site?tab=fees directly in the address bar.",
-            "Read which tab is selected, waiting for hydration before judging — the first paint is always Branding.",
-            "Open /admin/site?tab=themes directly.",
-            "Read which tab is selected.",
-            "Open /admin/site with no query parameter.",
-            "Read which tab is selected.",
-        ],
-        inputs: { tab1: "fees", tab2: "themes" },
-        expectedBehaviour: "The open tab is read from the URL, so a deep link — from search, from a guide, from a colleague's message — lands where it says it will. A page that hard-codes its default ignores the URL entirely and every such link arrives on tab one.",
-        expectedUiState: "?tab=fees opens the Fees tab with its fields on screen. ?tab=themes opens Themes. With no parameter the page opens on Branding. Two different parameters producing the same tab means the URL is not being read — but a MOMENT of Branding before the requested tab is hydration, not a failure: the server-rendered default is always Branding because the initialiser cannot read the URL without a window.",
-        expectedData: { defaultTab: "branding", validTabCount: 20 },
-        endResult: "Read-only; do not save anything. Nothing persists from opening a tab.",
-    },
-    "checklist-search-and-nav-settings-deep-links-unknown-tab-falls-back-quietly": {
-        roles: ["admin"],
-        startPage: "/admin/site",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/site?tab=nonsense directly in the address bar.",
-            "Read which tab is selected and look for any error.",
-            "Open /admin/site?tab= with an empty value.",
-            "Read which tab is selected.",
-        ],
-        inputs: { unknownTab: "nonsense" },
-        expectedBehaviour: "An unrecognised tab value falls back to the default without complaint, because the id is validated against the 20-value union rather than trusted. The realistic cause is a stale bookmark from a tab that has since been renamed, and that is not an error condition — it is a page whose shape changed.",
-        expectedUiState: "Both URLs open Branding. No error banner, no toast, no empty tab strip and no blank panel. A rejected value must not look like a broken page. Worth trying one more: ?tab=Fees with a capital F, since the guard is an exact match against the union and so should also fall back rather than open Fees.",
-        expectedData: { fallbackTab: "branding" },
-        endResult: "Read-only; nothing persists.",
-    },
-};

package/dist/features/tester/seed-data/authored/search-and-nav__sidebar-search.d.ts

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

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

@@ -1,60 +0,0 @@
-/*
- * WHY: Authored six-part procedures for the search-and-nav/sidebar-search page.
- * WHAT: 1 case, keyed by full checklist id.
- *
- * Written by hand, case by case, against the label each one states. There is no
- * generator: the authoring scripts were deleted once it was clear they were
- * scaffolding around work that is simply writing.
- *
- * @tag domain:tester
- * @tag layer:seed
- * @tag pattern:none
- * @tag access:server-only
- * @tag consumers:seed-data/authored/index.ts
- * @tag sideEffects:none
- */
-/*
- * Counted against ADMIN_NAV_GROUPS on 2026-09-29, because the case named three
- * entries and the query returns five, in TWO groups:
- *
- *   Trust & Safety   Banned Addresses   keywords: blocklist, fraud, ban
- *                    Address Clusters   description AND keywords
- *                    Payment Clusters   keywords: fraud, duplicates, linked accounts
- *                    Scam Registry      keywords: fraud, blocklist, report
- *   Guides           Trust & Safety Guide   description AND keywords
- *
- * 🛑 The two the case omitted are the ones a tester would have to judge.
- * Seeing Banned Addresses and a GUIDE come back for 'fraud' looks like
- * over-matching when the case promised three specific entries, and the honest
- * reading is the opposite: the guide is a description-and-keyword hit, which is
- * exactly the behaviour under test. Note Payment METHODS does not match and
- * Payment CLUSTERS does; they are adjacent in the sidebar and easy to confuse.
- *
- * Groups keep their declared order and only their contents narrow, so both
- * headings stay and Trust & Safety stays above Guides.
-*/
-export const authored = {
-    "checklist-search-and-nav-sidebar-search-sidebar-search-matches-description": {
-        roles: ["admin"],
-        startPage: "/admin",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin and read the sidebar's group headings in order.",
-            "Type fraud in the sidebar search box.",
-            "Read which entries remain, count them, and note which group heading each sits under.",
-            "Clear the box and type zzzznope.",
-            "Read the sidebar.",
-            "Clear the box and read the group order again.",
-        ],
-        inputs: {
-            query: "fraud",
-            nonsenseQuery: "zzzznope",
-            expectedMatches: 5,
-            expectedGroups: 2,
-        },
-        expectedBehaviour: "The filter matches a screen's description and keywords, not only its label. Matching on the label alone means only a screen with 'fraud' in its name survives the query — and none is named that.",
-        expectedUiState: "'fraud' leaves FIVE entries across TWO groups: Banned Addresses, Address Clusters, Payment Clusters and Scam Registry under Trust & Safety, and Trust & Safety Guide under Guides. The guide is a legitimate hit — it matches on description and keywords, which is the behaviour under test, not over-matching. Payment Methods must NOT appear; only Payment Clusters carries the keyword, and the two sit next to each other. Groups keep their normal order and only their contents narrow. 'zzzznope' empties the sidebar rather than leaving it unfiltered. Clearing the box restores every group in the original order.",
-        expectedData: { nonsenseVisibleCount: 0, fraudMatchCount: 5, fraudGroupCount: 2 },
-        endResult: "Nothing persists; the filter is local to the sidebar and resets on reload.",
-    },
-};

package/dist/features/tester/seed-data/authored/selling__become-seller.d.ts

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

package/dist/features/tester/seed-data/authored/selling__become-seller.js

@@ -1,117 +0,0 @@
-/*
- * WHY: Authored six-part procedures for the selling/become-seller page.
- * WHAT: 4 case(s), keyed by full checklist id.
- *
- * Written by hand, case by case, against the label each one states. There is no
- * generator: the authoring scripts were deleted once it was clear they were
- * scaffolding around work that is simply writing.
- *
- * 🛑 STORE APPROVAL IS TWO FIELDS ON TWO DOCUMENTS — a status on the user record
- * and a status plus a public flag on the store. Flipping only the user's is the
- * classic half-fix: the seller sees an approved dashboard while every public
- * visibility check reads the store's, so the store never appears anywhere.
- *
- * 🛑 THIS CHAIN IS ONE-SHOT AND LEAVES karthik.new@gmail.com A SELLER FOREVER.
- * Read this before running it a second time, because the second run does not
- * fail — it tests something else while looking the same.
- *
- * `users` is PRESERVE tier, so the tester lifecycle never wipes it. `stores` is
- * SEED_OWNED, so it IS wiped. After one run karthik therefore holds
- * `role: seller` and a `storeStatus` with NO STORE — a half-state neither
- * `sell-redirect` (which needs "a buyer with no store") nor `apply-seller`
- * (which needs someone who has not applied) is written for.
- *
- * A users reseed only half-fixes it: the seed declares `role`, so that is
- * restored — but it does NOT declare `storeStatus`, and `appkit-seed load` is a
- * merge write that cannot REMOVE a key it does not carry. The leftover status
- * survives every reseed. Clearing it needs a deliberate field delete.
- *
- * So before re-running this page:
- *   1. delete `storeStatus` (and `storeId`, if set) from user-karthik-new
- *   2. npx appkit-seed load --collections users   (restores role)
- *
- * The honest alternative is a fresh QA signup per run, as
- * account-auth/signup-login does with its run-stamped address — but that leaks
- * a permanent account each time, which is its own cost.
- *
- * @tag domain:tester
- * @tag layer:seed
- * @tag pattern:none
- * @tag access:server-only
- * @tag consumers:seed-data/authored/index.ts
- * @tag sideEffects:none
- */
-export const authored = {
-    "checklist-selling-become-seller-sell-redirect": {
-        roles: ["guest", "buyer"],
-        startPage: "/sell",
-        steps: [
-            "Open /sell in a private window with no session and read where the browser lands.",
-            "Read the HTTP status if the browser's network panel is open, and note whether the page rendered before moving.",
-            "Sign in as karthik.new@gmail.com / TempPass123!, a buyer with no store.",
-            "Open /sell and read where it lands.",
-            "Sign out and sign in as tyson@beybladearena.in / TempPass123!, who already has a store.",
-            "Open /sell and read where it lands.",
-        ],
-        expectedBehaviour: "/sell is an entry point that routes by who is asking: a signed-out visitor to sign-in, a buyer without a store to the become-seller flow, an existing seller to their dashboard. It redirects rather than rendering, and a redirect fires before any document is produced — so a page that returns 200 with content here is not redirecting at all.",
-        expectedUiState: "Each of the three identities ends somewhere different and appropriate. None sees a 404, and none is left on /sell showing an error. A 200 carrying an error page rather than a redirect is the failure worth naming — it is exactly what no monitoring flags.",
-        endResult: "Read-only; nothing persists.",
-    },
-    "checklist-selling-become-seller-apply-seller": {
-        roles: ["buyer"],
-        startPage: "/user/become-seller",
-        steps: [
-            "Sign in as karthik.new@gmail.com / TempPass123!.",
-            "Open /user/become-seller and read the whole form before typing.",
-            "Submit it with every field empty and read where the errors appear.",
-            "Type 'QA Store apply-seller' as the store name and fill every other required field.",
-            "Submit the form.",
-            "Read what is shown immediately afterwards.",
-            "Reload the page and read it again.",
-        ],
-        inputs: { storeName: "QA Store apply-seller" },
-        expectedBehaviour: "The application creates a store and records the applicant's seller status. This view is a slot shell — rendering it with no render props gives a layout skeleton with no content at all, which is a page that looks built and does nothing.",
-        expectedUiState: "The form renders with real fields, not an empty shell. Empty submission marks the individual fields. After submitting, the page reports the application's state rather than returning to a blank form, and that state survives the reload.",
-        endResult: "A store exists for karthik.new@gmail.com. Note its status — it feeds the next two cases.",
-    },
-    "checklist-selling-become-seller-store-setup": {
-        roles: ["seller"],
-        startPage: "/store",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!, whose store-beyblade-arena is approved and public.",
-            "Open /store and read the dashboard.",
-            "Open the store's own settings and read its name, description, logo and banner.",
-            "Change the description to 'QA Store store-setup description' and save.",
-            "RELOAD and read the description.",
-            "Open the store's public page and read the description there.",
-            "Restore the original description.",
-        ],
-        inputs: { description: "QA Store store-setup description" },
-        expectedBehaviour: "An approved store is approved on both documents at once — the user record's status AND the store's own status and public flag. Flipping only the user's leaves the seller with a working dashboard and a store invisible to the public, because every visibility check reads the store's own status. That is why this case reads the PUBLIC page and not only the dashboard.",
-        expectedUiState: "The dashboard loads rather than showing a pending-approval gate. The edited description survives the reload AND appears on the public store page. A description that saves in the dashboard but never reaches the public page means the store is not actually public.",
-        endResult: "The description is restored by the final step. The public page rendering at all is the real assertion here.",
-    },
-    "checklist-selling-become-seller-store-address": {
-        roles: ["seller"],
-        startPage: "/store/addresses",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            "Open /store/addresses and read the existing pickup addresses.",
-            "Add one: name 'QA Address store-address', street '10 Test Lane', city 'Indore', state 'Madhya Pradesh', pincode 452010, landmark 'Behind the arena'.",
-            "Mark it as a pickup location and save.",
-            "RELOAD the page and read every field of the new address, including the landmark.",
-            "Delete it.",
-        ],
-        inputs: {
-            name: "QA Address store-address",
-            street: "10 Test Lane",
-            city: "Indore",
-            state: "Madhya Pradesh",
-            pincode: "452010",
-            landmark: "Behind the arena",
-        },
-        expectedBehaviour: "A store address is written into the same top-level addresses collection as buyer addresses, discriminated by owner type rather than living in a subcollection of its own. Every field the form offers is stored, including the landmark — a form missing a field does not leave it alone, it sends undefined and overwrites.",
-        expectedUiState: "After the reload every typed value is present, landmark included, and the pickup flag is still set. A blank landmark after the reload is the failure this case shares with the store-address edit case in page-wiring.",
-        endResult: "The address is deleted by the final step so it does not accumulate across runs.",
-    },
-};

package/dist/features/tester/seed-data/authored/selling__digital-content-delivery.d.ts

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

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

@@ -1,148 +0,0 @@
-/*
- * WHY: Authored six-part procedures for selling/digital-content-delivery.
- * WHAT: 8 cases, keyed by full checklist id.
- *
- * 🛑 THE POOL HAD NO WRITER (Root Cause #103). Its one seller-facing route
- * answered `501 not implemented`, so the pool was empty in every environment,
- * always — and the claim at checkout logged "code pool exhausted" and returned
- * SILENTLY. The order completed normally and the buyer's reveal panel answered
- * 404. Nothing errored, and the seller form's "Code Pool Size" field made the
- * listing advertise stock that had never existed.
- *
- * So the first case here is deliberately about the EMPTY state, and several
- * others assert a number moving rather than a screen appearing: "the reveal
- * page loads" was true throughout the entire period the feature delivered
- * nothing.
- *
- * @tag domain:tester
- * @tag layer:seed
- * @tag pattern:none
- * @tag access:server-only
- * @tag consumers:seed-data/authored/index.ts
- * @tag sideEffects:none
- */
-export const authored = {
-    "checklist-selling-digital-content-delivery-pool-empty-by-default": {
-        roles: ["seller"],
-        startPage: "/store/digital-codes",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            "Open /store/digital-codes and open any listing's Edit action.",
-            "Scroll to the Code Details section.",
-            "Read the pool area beneath the delivery fields.",
-        ],
-        expectedBehaviour: "The editor states what the listing will actually deliver. A listing whose pool is empty can still be bought, and the buyer receives nothing — so the editor has to say that rather than leave the seller to infer it from a Pool Size field they typed themselves.",
-        expectedUiState: "A pool area is present, showing an available count and an already-delivered count. It says in words that an empty pool delivers nothing.",
-        expectedData: { poolSectionVisible: true },
-        endResult: "Nothing is saved; the section was only read.",
-    },
-    "checklist-selling-digital-content-delivery-add-codes-bulk": {
-        roles: ["seller"],
-        startPage: "/store/digital-codes",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            "Open any digital-code listing's Edit action and find the pool section.",
-            "Write down the current available count.",
-            "Paste exactly these four lines into the Add codes box: TEST-AAA, TEST-BBB, TEST-AAA, TEST-CCC — one per line.",
-            "Press Add codes.",
-            "Read the available count.",
-            "Reload the page and read the available count again.",
-        ],
-        inputs: { pasted: "TEST-AAA\nTEST-BBB\nTEST-AAA\nTEST-CCC", distinctCodes: 3 },
-        expectedBehaviour: "Four lines containing three distinct codes add three entries. A duplicate inside one paste is dropped: re-pasting a list is the obvious way to double a pool by accident, and a duplicated code means a second buyer is sold something already delivered.",
-        expectedUiState: "The available count rises by exactly 3, and three new rows appear in the list, each reading Code / available.",
-        expectedData: { availableDelta: 3 },
-        endResult: "After the reload the count is still the original plus 3 — the entries are stored, not just rendered.",
-    },
-    "checklist-selling-digital-content-delivery-buy-then-reveal-code": {
-        roles: ["buyer"],
-        startPage: "/digital-codes",
-        steps: [
-            "Sign in as the buyer rehan.sheikh@gmail.com / TempPass123!.",
-            "Open /digital-codes and open a listing that shows codes available.",
-            "Add it to the cart and complete checkout.",
-            "Open /user/digital-codes.",
-            "Find the row for what you just bought and press Reveal Code.",
-            "Read what appears.",
-        ],
-        expectedBehaviour: "The purchase claims one entry from that listing's pool and hands it to this buyer. If the pool is empty the claim logs and returns silently — the order still completes, so an order confirmation is NOT evidence that anything was delivered.",
-        expectedUiState: "A real code is shown in a monospace box with a Copy button. Not an error, and not 'No code found for this order'.",
-        expectedData: { codeRevealed: true },
-        endResult: "Reloading /user/digital-codes and revealing again shows the SAME code — it was claimed for this order, not generated on demand.",
-    },
-    "checklist-selling-digital-content-delivery-available-count-drops-after-purchase": {
-        roles: ["buyer", "seller"],
-        startPage: "/digital-codes",
-        steps: [
-            "Open a digital-code listing's public page and write down the codes-available number it shows.",
-            "Sign in as the buyer rehan.sheikh@gmail.com / TempPass123! and buy that listing.",
-            "Reload the listing's public page and read the number again.",
-        ],
-        expectedBehaviour: "The counter is derived from the pool, so a claim reduces it. A counter a human typed into the seller form and that nothing recomputes will sit at its original value forever — which lets a sold-out listing keep advertising stock, because the availability predicate reads exactly that field.",
-        expectedUiState: "The number shown is one lower than before the purchase.",
-        expectedData: { availableDelta: -1 },
-        endResult: "The lower number survives a reload.",
-    },
-    "checklist-selling-digital-content-delivery-claimed-entry-cannot-be-removed": {
-        roles: ["seller"],
-        startPage: "/store/digital-codes",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            "Open the Edit action for the listing a code was just bought from.",
-            "Find the pool list and locate the row whose status reads claimed.",
-            "Look for a Remove button on that row.",
-            "Look at a row whose status reads available and compare.",
-        ],
-        expectedBehaviour: "A claimed entry is somebody's purchase. Deleting it makes their reveal answer 404 with no record of what they bought, so the control is absent AND the server refuses it — the UI alone is not the boundary.",
-        expectedUiState: "The claimed row has no Remove button. The available row does.",
-        expectedData: { removeOnClaimedRow: false },
-        endResult: "The claimed entry is still present after a reload.",
-    },
-    "checklist-selling-digital-content-delivery-asset-download-requires-ownership": {
-        roles: ["guest", "buyer"],
-        startPage: "/user/orders",
-        steps: [
-            "Sign in as the bot buyer and open an order for a digital listing that delivered an image or a file.",
-            "Press Reveal, then press Download, and confirm the file arrives.",
-            "Copy the download URL from the address bar or the network panel.",
-            "Open a private window with no session and paste that URL.",
-            "Read what comes back.",
-            "Sign in as a DIFFERENT buyer in that window and load the same URL again.",
-        ],
-        expectedBehaviour: "The bytes live outside the public media path and are served only by an authenticated route that re-checks order ownership on every hit. A URL that works while signed out means the asset is reachable by anyone who learns the path — and product media filenames here are content-derived and therefore guessable.",
-        expectedUiState: "The buyer gets the file. The signed-out window and the other buyer both get a not-found page, not the file and not a sign-in redirect that then serves it.",
-        expectedData: { guestGetsFile: false, otherBuyerGetsFile: false },
-        endResult: "Nothing about the order changes. The buyer can still download it afterwards.",
-    },
-    "checklist-selling-digital-content-delivery-seller-cannot-upload-non-image": {
-        roles: ["seller", "admin"],
-        startPage: "/store/digital-codes",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123! and open a digital-code listing's Edit action.",
-            "In the pool section, press the upload button and read its label.",
-            "Choose a PNG image and confirm it is accepted.",
-            "Try to choose a PDF and note whether the picker even offers it.",
-            "Sign out and sign in as admin@letitrip.in / TempPass123!.",
-            "Open the same listing's Edit action and read the upload button's label.",
-            "Try a PDF as admin.",
-        ],
-        expectedBehaviour: "A seller may attach the QR image they were given; any other file type is staff-only, because those bytes are later streamed to a buyer and a mislabelled document served inline is stored XSS. The rule is enforced on the server at BOTH the sign and the finalize step — hiding the button is convenience, not the boundary.",
-        expectedUiState: "As seller the button reads 'Upload QR image' and the picker is restricted to images. As admin it reads 'Upload QR or file' and a PDF is accepted.",
-        expectedData: { sellerPdfAccepted: false, adminPdfAccepted: true },
-        endResult: "Whatever was accepted is present in the pool after a reload.",
-    },
-    "checklist-selling-digital-content-delivery-pool-list-never-shows-the-code": {
-        roles: ["seller"],
-        startPage: "/store/digital-codes",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            "Open a digital-code listing's Edit action and find the pool list.",
-            "Read every column of a row whose status is available.",
-            "Open the browser network panel, reload, and read the response body of the request that fetched the pool.",
-        ],
-        expectedBehaviour: "The pool view answers 'how many are left', not 'what are they'. The response is an allow-list, so the code and the asset path are absent from the payload rather than merely unrendered — a field that reaches the browser has been disclosed whether or not a component draws it.",
-        expectedUiState: "Each row shows a kind (Code / QR / File), a status, and a filename for assets. No row shows a redemption code.",
-        expectedData: { codeInResponseBody: false },
-        endResult: "Nothing is changed; this case only reads.",
-    },
-};

package/dist/features/tester/seed-data/authored/selling__final-sale-authoring.d.ts

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