@mohasinac/appkit 4.58.0 → 4.59.0

package/dist/features/tester/seed-data/authored/selling__seller-orders.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__seller-orders.js

@@ -1,213 +0,0 @@
-/*
- * WHY: Authored six-part procedures for the selling/seller-orders page.
- * WHAT: 11 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.
- *
- * 🛑 THE SELLER SEES LESS OF A MANUAL PAYMENT THAN THE ADMIN DOES, on purpose. The
- * proof screenshot is a bank or UPI capture and stays admin-only; the seller gets
- * a status badge and the reference. Three cases here check the seller CANNOT do
- * what only an admin may — verify, request a re-upload, or reject as fraud.
- *
- * @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-seller-orders-view-orders": {
-        roles: ["seller"],
-        startPage: "/store/orders",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            "Open /store/orders and read every row's primary label.",
-            "Check each names the ITEM and shows its thumbnail rather than only an order id.",
-            "Read the availability or scope tabs offered and select each in turn.",
-            "Read every status filter and select each, noting any that returns nothing.",
-            "Open one order and read its detail.",
-        ],
-        expectedBehaviour: "Every order carries its item title and image denormalised onto the document precisely so a list row needs no extra fetch. A row reading 'Order {id}' is a row-mapper that threw that away, leaving the seller to open each order to find out what it is.",
-        expectedUiState: "Rows name the product with a thumbnail, and a multi-item order shows a '+N more' style suffix rather than only the first item. The order id is present but de-emphasised. Scope tabs read Active / Closed / All. Every status filter returns rows or is genuinely empty.",
-        endResult: "Read-only; nothing persists beyond the URL.",
-    },
-    "checklist-selling-seller-orders-seller-order-manual-payment-badge": {
-        roles: ["seller"],
-        startPage: "/store/orders",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            "Open /store/orders and find an order paid by cash or UPI.",
-            "Read its manual-payment badge in the list and note the state it reports.",
-            "Open the order and read the badge and the payment reference there.",
-            "Look for the buyer's uploaded proof screenshot anywhere on the page.",
-            "Look for any control to verify, request a re-upload, or reject the payment.",
-        ],
-        expectedBehaviour: "The state is DERIVED from two fields rather than stored, so every surface computes the same four states — awaiting payment, awaiting verification, re-upload requested, resolved. A stored mirror would drift the first time a write path forgot it.",
-        expectedUiState: "The badge states which of the four the order is in, in both the list and the detail. The reference is shown. The proof SCREENSHOT is not — it is a bank or UPI capture and is admin-only. No verify, re-upload or reject control is offered to the seller.",
-        expectedData: { proofScreenshotVisibleToSeller: false },
-        endResult: "Read-only. A visible screenshot or an actionable verify control here is a permissions finding, not a UI one.",
-    },
-    "checklist-selling-seller-orders-confirm-payment": {
-        roles: ["seller"],
-        startPage: "/store/orders",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            "Open /store/orders and open an order awaiting payment verification.",
-            "Read every control the page offers.",
-            "Look specifically for a control that would mark the payment verified.",
-            "Sign out and sign in as admin@letitrip.in / TempPass123!.",
-            "Open the same order in /admin/orders and read the controls offered there.",
-        ],
-        expectedBehaviour: "Verifying a manual payment is an admin and moderator action. The seller is the beneficiary of the payment, so letting them confirm it is the party with the incentive marking their own money received — the split is deliberate and the admin view is where the control lives.",
-        expectedUiState: "The seller's view offers no verify control. The admin's view offers Verify alongside Request re-upload and Reject as fraud, with the proof screenshot visible. A verify control on the seller's page is the failure.",
-        endResult: "Do not verify anything. Read-only on both sides.",
-    },
-    "checklist-selling-seller-orders-request-reupload": {
-        roles: ["seller", "admin"],
-        startPage: "/store/orders",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123! and open an order whose proof has been submitted.",
-            "Confirm no re-upload control is offered to the seller.",
-            "Sign out and sign in as admin@letitrip.in / TempPass123!.",
-            "Open the same order in /admin/orders and use Request re-upload, typing a note.",
-            "Sign in as the buyer who placed that order and open the order's payment page.",
-            "Read whether the upload form is active again and what the deadline shows.",
-        ],
-        expectedBehaviour: "Only an admin may request a re-upload, and doing so reopens the buyer's window. The note is required — a re-upload request with no reason leaves the buyer resubmitting the same thing.",
-        expectedUiState: "The seller has no such control. The admin's request requires a note before it will submit. The buyer's payment page becomes active again with an extended deadline rather than staying locked.",
-        endResult: "The order is left in the re-upload-requested state. Note that a corrected re-upload must clear that state — an order stuck in it is invisible to both the auto-approve sweep and the admin queue, and stalls forever.",
-    },
-    "checklist-selling-seller-orders-reject-fraud": {
-        roles: ["seller", "admin"],
-        startPage: "/store/orders",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123! and open an order awaiting verification.",
-            "Confirm no reject-as-fraud control is offered.",
-            "Sign out and sign in as admin@letitrip.in / TempPass123!.",
-            "Open the same order in /admin/orders and read the reject-as-fraud control and what it requires.",
-            "Read any confirmation dialog it opens, without confirming it.",
-            "Cancel out of the dialog.",
-        ],
-        expectedBehaviour: "Rejecting as fraud is admin-only and requires a note, because it cancels the order, restores stock and enqueues a seven-day ban cascade against the buyer. A destructive action of that reach must carry a confirmation naming what it will do — one without it executes immediately with no warning.",
-        expectedUiState: "The seller has no such control. The admin's version requires a note and opens a confirmation that names the consequences rather than asking a generic 'Are you sure?'. Cancelling leaves the order untouched.",
-        endResult: "Nothing is rejected. Cancel rather than confirm — this action bans a real account for seven days.",
-    },
-    "checklist-selling-seller-orders-mark-shipped": {
-        roles: ["seller"],
-        startPage: "/store/orders",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            "Open /store/orders and open an order that is ready to ship.",
-            "Use the mark-shipped control and read what it asks for.",
-            "Type 'QA Carrier mark-shipped' as the carrier and 'QATRACK118427' as the tracking number, then submit.",
-            "RELOAD the order and read its status, carrier and tracking number.",
-            "Open /store/orders and check the row's status has moved too.",
-            "Check the scope tabs — the order should still be under Active, not Closed.",
-        ],
-        inputs: { carrier: "QA Carrier mark-shipped", trackingNumber: "QATRACK118427" },
-        expectedBehaviour: "Marking shipped records the carrier and tracking number alongside the status. Shipping is manual here — there is no carrier integration — so the seller's typed values ARE the tracking data, and a status change that discards them leaves the buyer with nothing to follow.",
-        expectedUiState: "After the reload the order reads as shipped and holds both the carrier and the tracking number. The list row reflects the new status. The order stays in the Active scope, since shipped is not a closed state.",
-        expectedData: { trackingNumber: "QATRACK118427" },
-        endResult: "The order is shipped and carries its tracking data. A status that moved while the carrier and tracking are blank is the failure.",
-    },
-    "checklist-selling-seller-orders-tracking-visible": {
-        roles: ["seller", "buyer"],
-        startPage: "/store/orders",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123! and open the order marked shipped in the previous case.",
-            "Read the carrier and tracking number shown.",
-            "Sign out and sign in as the buyer who placed that order.",
-            "Open /user/orders and open the same order.",
-            "Read the carrier and tracking number there.",
-            "Open the order's tracking page and read what it shows.",
-        ],
-        inputs: { trackingNumber: "QATRACK118427" },
-        expectedBehaviour: "What the seller entered reaches the buyer. The buyer's tracking page renders a timeline from the order's real per-status dates — a status with no recorded date shows no timestamp rather than a guessed one, because a fabricated date is worse than a missing one.",
-        expectedUiState: "Both sides show the same carrier and tracking number. The buyer's tracking page renders a timeline with real dates against the statuses that have them, and an em-dash against those that do not.",
-        endResult: "Read-only on the buyer side. A tracking page that is blank, or that shows invented dates for every status, are both failures.",
-    },
-    "checklist-selling-seller-orders-whatsapp-admin-share": {
-        roles: ["seller"],
-        startPage: "/store/orders",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            "Open /store/orders and open an order.",
-            /*
-             * 🛑 NO SUCH CONTROL EXISTS TODAY, AND ABSENCE IS THE EXPECTED ANSWER.
-             *
-             * Measured 2026-09-29: SELLER_ROW_ACTIONS.orders is
-             * [VIEW, EDIT, TRACK, RESEND] — no share. SellerOrdersView mentions
-             * WhatsApp only as the buyer's purchased add-on flag
-             * only as `wa.me` links, and every one of those in
-             * the codebase is on the contact page, the chat button or the buyer's own
-             * payment page. The registry's WhatsApp actions are store SETUP
-             * (whatsapp-connect, catalog-sync, catalog-import).
-             *
-             * The case is kept rather than deleted because it guards a real risk the
-             * day someone adds one: an order share is exactly the control that would
-             * paste a buyer's address and phone into a third-party app. Written so
-             * that absence PASSES and a leaky implementation FAILS — which is the
-             * only shape that stays useful while the feature does not exist.
-             */
-            "Look for a WhatsApp or generic share control on the order — in the row actions, the detail drawer and the full detail page.",
-            "If none exists anywhere, record that and stop: no share control is the expected state and the case passes.",
-            "If one does exist, trigger it and read the message it composes before sending anything.",
-            "Check that message for the buyer's full phone number, full address and any payment identifier.",
-            "Close without sending.",
-        ],
-        expectedBehaviour: "The share composes a message about the order. What it must not do is put more of the buyer's data into a third-party app than the seller needs to fulfil — a share that pastes a full address and phone into an outbound message has moved PII somewhere no policy here covers.",
-        expectedUiState: "No share control is present on the row actions, the drawer or the detail page — that is the current expected state and it passes. If one IS present, the composed message identifies the order and what it contains; read exactly what buyer data it includes and record it, and a full payment identifier in that message is a finding regardless of anything else.",
-        endResult: "Nothing is sent. Report precisely which buyer fields the message carries — that is the substance of this case.",
-    },
-    "checklist-selling-seller-orders-seller-auction-forfeit-notification": {
-        roles: ["seller"],
-        startPage: "/store",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            "Open /store and open the notification list.",
-            "Look for any notification about an auction win that lapsed unpaid.",
-            "Read its title, body and destination if one exists.",
-            "Open the store's auctions list and find an auction whose win was forfeited.",
-            "Read what state that auction is now in.",
-        ],
-        expectedBehaviour: "When a win lapses unpaid the bid is forfeited and the buyer is notified. Whether the SELLER is notified is the question this case answers rather than assumes — for an unpaid buyout the seller is deliberately not told, because nothing was ever sold, and the same reasoning may or may not apply here.",
-        expectedUiState: "Record what the seller actually receives. If a notification exists it has a readable title, a body and a destination that resolves. If none exists, record that as the observed behaviour rather than as a failure.",
-        endResult: "Read-only. This case documents behaviour; report what happened rather than forcing a yes or no.",
-    },
-    "checklist-selling-seller-orders-seller-order-detail-full-page": {
-        roles: ["seller"],
-        startPage: "/store/orders",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            "Open /store/orders and open an order's detail panel from the list.",
-            "Write down every field label and section it shows.",
-            "Note the order id and close the panel.",
-            "Open that order's standalone detail page directly by URL.",
-            "Write down every field and section, and compare the two lists.",
-            "Reload the standalone page and confirm it still loads the same order.",
-        ],
-        expectedBehaviour: "The panel and the page render from one shared content component, so their fields match by construction. The standalone page exists because a panel cannot be bookmarked or sent to someone — and an order is exactly the record a seller needs to share.",
-        expectedUiState: "Both surfaces show the same fields and sections with the same values. The standalone page survives a reload on the same order. A field in one and not the other means a second copy of the content component has appeared and the two will drift.",
-        endResult: "Read-only; nothing persists.",
-    },
-    "checklist-selling-seller-orders-seller-new-order-notification-reaches-seller": {
-        roles: ["buyer", "seller"],
-        startPage: "/products/product-beyblade-burst-valkyrie",
-        steps: [
-            "Sign in as rehan.sheikh@gmail.com / TempPass123!.",
-            "Add product-beyblade-burst-valkyrie (₹999, Beyblade Arena) to the cart.",
-            "Open /checkout, select the first saved address, choose Cash on Delivery, and place the order.",
-            "Sign out and sign in as tyson@beybladearena.in / TempPass123!, who owns that store.",
-            "Open /store and read the notification bell.",
-            "Open the notification list, read the newest entry's title and body, and click it.",
-            "Read where it lands.",
-        ],
-        inputs: { productId: "product-beyblade-burst-valkyrie", paymentMethod: "Cash on Delivery" },
-        expectedBehaviour: "A new order notifies the store that received it. The audience is a property of the EVENT, not of the person — the same account is a buyer elsewhere, so the notification has to be addressed to the store portal rather than to whichever dashboard the user happens to open.",
-        expectedUiState: "The bell shows an unread count and the newest entry names the new order with a readable body. Clicking it opens that order in the STORE portal, not the buyer's own order page.",
-        endResult: "The order exists and the notification survives a reload. No notification at all means the hook did not fire; one landing in the buyer portal means the audience was resolved from the person rather than the event.",
-    },
-};

package/dist/features/tester/seed-data/authored/selling__seller-shipping-payouts-setup.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__seller-shipping-payouts-setup.js

@@ -1,192 +0,0 @@
-/*
- * WHY: Authored six-part procedures for the selling/seller-shipping-payouts-setup page.
- * WHAT: 10 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.
- *
- * 🛑 SEPARATE PAGES WERE CONSOLIDATED INTO TABS, so the old URLs are live links in
- * bookmarks, emails and guides. Three cases here are about that seam: old URLs
- * must still land, the tab must be written back to the URL so a deep link works
- * in both directions, and a search box must only promise what its corpus can
- * deliver.
- *
- * @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-seller-shipping-payouts-setup-shipping-page": {
-        roles: ["seller"],
-        startPage: "/store/shipping",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            "Open /store/shipping and read every field and section.",
-            "Note which shipping options the store currently offers and their rates.",
-            "Read whether a free-shipping threshold is configurable and what it is set to.",
-            "Reload the page and confirm the same values are shown.",
-        ],
-        expectedBehaviour: "The page renders the store's real shipping configuration. Free shipping is DERIVED from who pays rather than being a field of its own, so a control labelled 'free shipping' has to write the field the read side actually consults — a filter on a field the document does not have matches nothing forever.",
-        expectedUiState: "Every configured option and rate is shown with real values rather than blanks. Reloading reproduces them.",
-        endResult: "Read-only; nothing persists.",
-    },
-    "checklist-selling-seller-shipping-payouts-setup-shipping-configs-crud": {
-        roles: ["seller"],
-        startPage: "/store/shipping",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            "Open /store/shipping and create a config named 'QA Shipping configs-crud' with a rate of 99.",
-            "Save, RELOAD, and read every field of it.",
-            "Edit only its rate to 149, save, RELOAD, and read every field again including the name.",
-            "Open /store/products, then that product's editor, and check the new config is offered as a shipping choice.",
-            "Delete the config and RELOAD to confirm.",
-        ],
-        inputs: { name: "QA Shipping configs-crud", rateBefore: 99, rateAfter: 149 },
-        expectedBehaviour: "Create, edit and delete persist, and an edit to one field leaves the others alone. A new config becomes available to the listing forms immediately — a config that exists only on its own settings page is a config no listing can use.",
-        expectedUiState: "After each reload the config holds exactly what was saved. Following the rate edit the name is unchanged. The config appears in a product editor's shipping choices.",
-        endResult: "The config is deleted by the final step.",
-    },
-    "checklist-selling-seller-shipping-payouts-setup-payout-methods-crud": {
-        roles: ["seller"],
-        startPage: "/store/payouts",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            "Open the store's payout methods and read the existing ones.",
-            "Note how any existing account number or UPI id is displayed.",
-            "Add a method named 'QA Payout methods-crud' with test details and save.",
-            "RELOAD and read how the new method's details are displayed.",
-            "Open the browser's View Source and search for the full account identifier you typed.",
-            "Delete the method.",
-        ],
-        inputs: { name: "QA Payout methods-crud" },
-        expectedBehaviour: "Payout details are PII-encrypted at rest and shown masked. This is one of the few places a seller's bank identifier exists in the product at all, so the source check is the real assertion — a masked display over an unmasked payload is a leak that looks like a fix.",
-        expectedUiState: "Existing and new methods both show masked identifiers rather than full ones. The full identifier does not appear anywhere in the page source, including the embedded data payload.",
-        expectedData: { fullIdentifierInSource: 0 },
-        endResult: "The method is deleted by the final step. A full account number in the source fails the case regardless of how the page renders.",
-    },
-    "checklist-selling-seller-shipping-payouts-setup-payout-settings-page": {
-        roles: ["seller"],
-        startPage: "/store/payouts",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            "Open /store/payouts and read every field and toggle.",
-            "Read whether the payout schedule, hold period and minimum amount are shown.",
-            "Change one editable setting and save.",
-            "RELOAD and read every setting again.",
-            "Restore the changed setting.",
-        ],
-        expectedBehaviour: "The page shows the seller's own payout settings and saves what they change. Platform-side figures such as the hold period and the minimum payout amount are informational here — they are not buyer-facing and were once being published by an unauthenticated public endpoint, so a seller seeing them is correct and a public page showing them is not.",
-        expectedUiState: "Settings render with real values and the changed one survives the reload. Every other setting is unchanged after the save.",
-        endResult: "The setting is restored by the final step.",
-    },
-    "checklist-selling-seller-shipping-payouts-setup-consolidated-tabs-old-urls": {
-        roles: ["seller"],
-        startPage: "/store/shipping",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            /*
-             * 🛑 THE URLS ARE NAMED NOW. This said "each of the pre-consolidation
-             * URLs" and listed none, so the tester had to guess which ones existed —
-             * and a guess that misses the one that regressed reports a clean pass.
-             *
-             * These are the real shims under /store, each a page.tsx whose whole body
-             * is a redirect. Two of them carry a TAB, which is the part worth
-             * checking: /store/payout-settings redirects to ?tab=settings, and
-             * /store/print-center forwards its own query onto /store/fulfillment.
-             * Landing on the right page but the FIRST tab is the regression this case
-             * exists for, and it is invisible unless the URLs are enumerated.
-             */
-            "Open each of these pre-consolidation URLs directly in the address bar, one at a time: /store/payout-methods, /store/payout-settings, /store/shipping-configs, /store/print-center, /store/auctions, /store/pre-orders, /store/prize-draws, /store/slug.",
-            "For each, read where the browser lands and which tab is open.",
-            "Note any that 404 or land on the first tab rather than the one they name.",
-            "Read the final URL each one settles on.",
-        ],
-        expectedBehaviour: "An old URL lands on the consolidated page WITH its own tab open. These URLs are live in bookmarks, emails and guides, so a 404 breaks links that were correct when they were written — and landing on tab one is only marginally better, since the user still has to hunt.",
-        expectedUiState: "Every old URL resolves and opens the tab it corresponds to. None 404s and none lands on the default tab. Specifically: /store/payout-settings settles on /store/payouts with the settings tab open (its shim appends ?tab=settings), /store/payout-methods settles on /store/payouts, /store/shipping-configs on /store/shipping, /store/print-center on /store/fulfillment carrying any query it was given, /store/slug on /store/storefront, and /store/auctions, /store/pre-orders and /store/prize-draws each on /store/products carrying its own ?listingType= (auction, pre-order, prize-draw) — arriving without that parameter is the regression, because the page then shows every type. Record any that 404 or land on the default tab, by URL.",
-        endResult: "Read-only; nothing persists.",
-    },
-    "checklist-selling-seller-shipping-payouts-setup-consolidated-tabs-url-writeback": {
-        roles: ["seller"],
-        startPage: "/store/shipping",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            "Open /store/shipping and read the URL. It is the consolidated page: /store/shipping-configs now redirects here, as /store/payout-methods and /store/payout-settings both redirect to /store/payouts.",
-            "Click a different tab and read the URL again.",
-            "Copy that URL, open it in a new tab, and read which tab is open.",
-            "Press the browser back button and read which tab is shown.",
-            "Open the page with an unknown tab value in the URL and read what happens.",
-        ],
-        expectedBehaviour: "Selecting a tab writes it to the URL, so the deep link works in both directions and back walks the tabs. An unknown value falls back to the default quietly — the realistic cause is a stale bookmark from a renamed tab, which is not an error condition.",
-        expectedUiState: "The URL changes with the tab and reopening it lands on that tab. Back returns to the previous tab. An unknown value opens the default with no error banner and no blank panel.",
-        endResult: "Read-only; nothing persists beyond the URL.",
-    },
-    "checklist-selling-seller-shipping-payouts-setup-print-center-selection-deeplink": {
-        roles: ["seller"],
-        startPage: "/store/print-center",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            "Open /store/print-center — it REDIRECTS to /store/fulfillment and carries the query string with it, which is the whole mechanism this case depends on — then switch to the 'Print centre' tab and select two items to print.",
-            "Read the URL and check the selection is represented in it.",
-            "Copy the URL and open it in a new tab.",
-            "Read whether the same two items are selected on arrival.",
-            "Reload and read the selection again.",
-        ],
-        expectedBehaviour: "A print selection is deep-linkable so it can be reopened or handed to a colleague. Holding it in component state alone means the URL describes a different page than the one on screen, and reloading loses the work.",
-        expectedUiState: "The URL encodes the selection, the pasted URL arrives with the same two items selected, and a reload preserves them. A selection lost on reload is the failure.",
-        endResult: "Clear the selection; nothing is printed.",
-    },
-    "checklist-selling-seller-shipping-payouts-setup-search-box-promises-match-corpus": {
-        roles: ["seller"],
-        startPage: "/store/products",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            "Open each store listing page that has a search box and read its placeholder text.",
-            "Write down what each placeholder claims to search — title, sku, buyer, id.",
-            "For each page, search a value of every kind its placeholder names.",
-            "Write down any kind the placeholder names that returns nothing when it should match.",
-            "Search zzzznope on each page and confirm zero results.",
-        ],
-        inputs: { nonsenseQuery: "zzzznope" },
-        expectedBehaviour: "A placeholder is a promise about what the corpus can match. Naming a field the search index does not carry produces a search that fails for a reason the user cannot see — they conclude the record does not exist. Placeholders promising something unmatchable have been found and removed before.",
-        expectedUiState: "Every kind a placeholder names returns results when a matching value is searched. 'zzzznope' returns zero everywhere. A placeholder promising a field that matches nothing is the finding, quoted with the page it is on.",
-        expectedData: { unkeptPlaceholderPromises: 0 },
-        endResult: "Read-only; nothing persists beyond the URL.",
-    },
-    "checklist-selling-seller-shipping-payouts-setup-exact-search-boxes-commit-on-enter": {
-        roles: ["seller"],
-        startPage: "/store/orders",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            "Open a store listing whose search is exact-match and read its helper text.",
-            "Type a full matching value but do NOT press Enter — wait five seconds and read the rows.",
-            "Press Enter and read the rows.",
-            "Clear the box, type a partial value, press Enter, and read the rows.",
-            "Type zzzznope, press Enter, and read the rows.",
-        ],
-        inputs: { nonsenseQuery: "zzzznope" },
-        expectedBehaviour: "An exact-match box commits on Enter rather than searching as you type. Encrypted fields can only be matched through a blind index, so a partial value cannot match — searching mid-typing would fire a query per keystroke, every one of which is guaranteed to return nothing.",
-        expectedUiState: "Nothing changes while typing. Enter runs the search and the full value returns its rows. The partial value returns none, and the helper text explains that matching is exact. 'zzzznope' returns none.",
-        endResult: "Read-only; nothing persists beyond the URL.",
-    },
-    "checklist-selling-seller-shipping-payouts-setup-consolidated-tabs-command-palette": {
-        roles: ["seller"],
-        startPage: "/store",
-        steps: [
-            "Sign in as tyson@beybladearena.in / TempPass123!.",
-            "Open /store and open the command palette or header search.",
-            "Type shipping and read the results.",
-            "Click the result and read which page and which tab it opens.",
-            "Repeat with payout, reading the results and where they land.",
-            "Type zzzznope and read the results.",
-        ],
-        inputs: { query1: "shipping", query2: "payout", nonsenseQuery: "zzzznope" },
-        expectedBehaviour: "Search reaches individual TABS, not only the consolidated page, because a tab is where the setting actually is. Landing on the page's first tab and leaving the seller to hunt is the same failure as the old-URL case, arriving from a different direction.",
-        expectedUiState: "Both queries return entries that open the consolidated page ON the relevant tab. 'zzzznope' returns nothing rather than the full list of settings.",
-        expectedData: { nonsenseResultCount: 0 },
-        endResult: "Read-only; nothing persists.",
-    },
-};

package/dist/features/tester/seed-data/authored/selling__spares-and-group-editing.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__spares-and-group-editing.js

@@ -1,77 +0,0 @@
-/*
- * WHY: Authored six-part procedures for the seller side of Part Two —
- *      listing a spare, and the shared group-stock/rules editor.
- * WHAT: 4 case(s), keyed by full checklist id.
- *
- * 🛑 "Stock is independent per listing" is the whole premise of the shared
- * editor, so the round trip that proves it (edit one, reload, check the
- * OTHER member) is the case that actually matters here — not whether the
- * form submits.
- *
- * @tag domain:tester
- * @tag layer:seed
- * @tag pattern:none
- * @tag access:server-only
- * @tag consumers:seed-data/authored/index.ts
- * @tag sideEffects:none
- */
-const SELLER_SIGNIN = "Sign in as a seller account that owns store-beyblade-arena.";
-export const authored = {
-    "checklist-selling-spares-seller-and-group-editing-seller-can-list-a-spare": {
-        roles: ["seller"],
-        startPage: "/store/spares",
-        steps: [
-            SELLER_SIGNIN,
-            "Click \"List a Spare\".",
-            "Fill in title, price, colourway, and a stock quantity, then Publish.",
-            "Return to /store/spares.",
-        ],
-        expectedBehaviour: "The seller product-shell accepts `listingType: \"spares\"` the same way it accepts the other nine types — this is the one new entry in `ProductListingMode`, so a missing wiring here would show as a form that silently fails to save or a blank listing-type dropdown.",
-        expectedUiState: "The new spare appears in the /store/spares list with the colourway shown as its distinguishing column (not a size column, which the other print types use), the price entered, and status Published.",
-        endResult: "BEFORE spares existed, there was no seller-facing way to list one at all. AFTER: creating one is the same shape as creating a sticker or an art print, just under a different type.",
-    },
-    "checklist-selling-spares-seller-and-group-editing-group-stock-edit-is-independent": {
-        roles: ["seller"],
-        startPage: "/store/products",
-        steps: [
-            SELLER_SIGNIN,
-            "Open the editor for a group PARENT product (one with \"isGroupParent\").",
-            "In the Members list, note the current stock figures for two different children, A and B.",
-            "In the shared stock editor, change ONLY child A's stock to a new number. Leave B's input untouched.",
-            "Click \"Save group stock\".",
-            "Reload the editor and re-read both children's stock figures.",
-        ],
-        expectedBehaviour: "`PATCH .../group/stock` writes ONLY the member rows named in the request body — `saveGroupStock()` sends just the touched ids via `stockDraft`/`motDraft`, never a blanket broadcast across every child. Stock is independent per listing by design: a spare is one physical object a seller happens to have, and selling or restocking one must not touch another's figure.",
-        expectedUiState: "After reload, child A shows the NEW figure you entered. Child B shows EXACTLY the figure it had before — unchanged to the unit. This is the single most important assertion in this group: a shared pool bug would show up as B silently changing when only A was edited.",
-        endResult: "BEFORE this editor existed, each child's stock could only be edited by opening its own separate product page — tedious but safe. AFTER: editing is faster AND must remain exactly as safe. If B's figure moved at all, the editor is pooling stock rather than editing independent listings, which contradicts the feature's entire premise.",
-    },
-    "checklist-selling-spares-seller-and-group-editing-group-rules-save-and-reload": {
-        roles: ["seller"],
-        startPage: "/store/products",
-        steps: [
-            SELLER_SIGNIN,
-            "Open a group parent's editor and find the \"Selection rules\" form.",
-            "Change the min, max, per-item cap, and discount fields to new values different from what they currently show.",
-            "Click \"Save rules\".",
-            "Reload the editor page.",
-            "As a buyer (different tab/session), open that group's public picker.",
-        ],
-        expectedBehaviour: "`PATCH .../group` writes only the keys present in the body, via the `in` test rather than a spread — so saving rules must not blank the group title, and reloading must show exactly what was saved, not a stale cached value. The public picker reads the SAME stored fields through `readGroupRules`, so it must reflect the new numbers on its very next load, with no separate publish step.",
-        expectedUiState: "After reload, the editor's four rule fields show the NEW values you typed, not the old ones and not blank. The buyer-facing picker, opened fresh, states the NEW rules in its rule-summary text — if it still shows the old numbers, something is caching the group document past this write.",
-        endResult: "BEFORE: a group had no rules to edit at all. AFTER: a seller's edit is live on the storefront immediately, and a reload of the editor proves the write actually persisted rather than only updating client-side state.",
-    },
-    "checklist-selling-spares-seller-and-group-editing-group-stock-partial-failure-reported": {
-        roles: ["seller"],
-        startPage: "/store/products",
-        steps: [
-            SELLER_SIGNIN,
-            "Open a group parent's editor in TWO browser tabs.",
-            "In tab 1, unlink one child from the group and confirm it.",
-            "Switch to tab 2 (which still shows the now-unlinked child in its member list) and, without reloading, edit that same child's stock PLUS a different, still-valid child's stock.",
-            "Click \"Save group stock\" in tab 2.",
-        ],
-        expectedBehaviour: "The route re-fetches the CURRENT member list server-side before writing, so the unlinked child's id is no longer a member and is rejected — but the request must not fail as a whole. The still-valid child's stock edit must still be written. This is the 207-style partial result the route is built for.",
-        expectedUiState: "A toast or message reports a partial result (e.g. \"Updated 1; 1 could not be updated.\"). Reloading the editor shows the still-valid child's stock at its NEW value — the save for that row was not discarded just because the other row was stale.",
-        endResult: "BEFORE this endpoint existed, there was no shared editor and so no partial-failure case to handle. AFTER: a stale row (the common case when two admins or two tabs edit the same group near-simultaneously) costs nothing to the rows that were still valid.",
-    },
-};

package/dist/features/tester/seed-data/authored/selling__store-dashboard-navigation.d.ts

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