@mohasinac/appkit 4.42.1 → 4.42.3

package/dist/features/tester/seed-data/authored/admin__bulk-actions.js

@@ -12,6 +12,29 @@
  * keeps its layout height while invisible over-reports the tier on every page that
  * has no bar, pushing floating controls up the screen site-wide.
  *
+ * 🛑 BOTH RECURRING SHAPES ARE PRESENT TODAY, and three cases were pointed at a
+ * surface where neither can be observed (checked 2026-09-29).
+ *
+ * `BulkActionItem` is `{ id, label, variant, onClick }`. There is NO `action`
+ * ActionDef on it, so Rule #7's auto-confirmation — which works by resolving
+ * `ActionDef.confirmation` inside `<Button action={…}>` — never runs here.
+ * `BulkActionBar.handleApply` calls `selectedAction?.onClick()` directly, and
+ * `variant: "danger"` only adds `--danger` styling to the trigger and the
+ * option. So **bulk Cancel on /admin/orders cancels every selected order with
+ * no dialog**, which is exactly the failure this file's own header describes.
+ *
+ * And every bulk handler is a fire-and-forget loop —
+ * `for (const rowId of selection.selectedIds) void handleQuickStatus(rowId, …)`
+ * then `clearSelection()` — so there is no aggregated outcome anywhere: no
+ * succeeded count, no failed count, and no way to name which rows failed. Two
+ * cases asked for those counts; they now expect their absence and say so.
+ *
+ * 🛑 /admin/products HAS NO DESTRUCTIVE BULK ACTION. Its preset is
+ * [FEATURE, PROMOTE, SALE] — three boolean flags — so the confirmation case
+ * cannot start there. It now starts on /admin/orders, whose preset carries
+ * CANCEL. Note those three are TOGGLES (`!row[field]`), so running "Feature"
+ * over a mixed selection UN-features the rows that were already featured.
+ *
  * @tag domain:tester
  * @tag layer:seed
  * @tag pattern:none
@@ -53,47 +76,54 @@ export const authored = {
     },
     "checklist-admin-bulk-actions-bulk-destructive-confirms": {
         roles: ["admin"],
-        startPage: "/admin/products",
+        startPage: "/admin/orders",
         steps: [
             SIGN_IN_ADMIN,
-            "Open /admin/products and select three rows.",
-            "Trigger the destructive bulk action offered.",
-            "Read the dialog WITHOUT confirming.",
-            "Check it names the action and how many rows it will affect.",
-            "Cancel it and check all three rows are untouched.",
-            "Repeat on /admin/users and /admin/orders.",
+            "Open /admin/products and read its bulk actions with three rows selected — they are Feature, Promote and Sale, and NONE of them is destructive, so there is nothing to confirm here.",
+            "Open /admin/orders and select ONE order that is already cancelled, so that running the action cannot destroy anything.",
+            "Open the bulk action picker and read the options — Mark Shipped, Mark Delivered and Cancel.",
+            "Choose Cancel and apply it. Watch carefully for a confirmation dialog BEFORE anything commits.",
+            "Record whether a dialog appeared at all, and what the bar did immediately afterwards.",
+            "Open /admin/users, select one row, and check whether its Delete bulk action confirms.",
         ],
-        expectedBehaviour: "Every destructive bulk action confirms first, naming the count. An action defined inline at its call site rather than in the shared registry has no confirmation configured at all, and so runs immediately and irreversibly — on the largest selection the admin has ever made, since bulk is where selections are largest.",
-        expectedUiState: "A confirmation naming the action and the row count appears on all three surfaces, and cancelling changes nothing. A destructive action that runs on click is the finding.",
-        endResult: "Nothing is deleted.",
+        inputs: { productBulkActions: "Feature, Promote, Sale", orderBulkActions: "Mark Shipped, Mark Delivered, Cancel" },
+        expectedBehaviour: "Every destructive bulk action should confirm first, naming the count. Bulk is where selections are largest, so an unconfirmed destructive action is irreversible across the most rows an admin ever touches at once.",
+        expectedUiState: "🛑 EXPECT NO CONFIRMATION, AND RECORD IT AS A FAILURE. `BulkActionItem` carries no ActionDef, so the registry's confirmation never resolves; the bar calls the handler directly and `variant: \"danger\"` only colours the control. Select an ALREADY-CANCELLED order so that proving this costs nothing. Say for each surface whether a dialog appeared.",
+        expectedData: { confirmationShownOnOrdersCancel: false },
+        endResult: "Nothing that mattered was destroyed — the only order actioned was already cancelled. Do not test this with a live order.",
     },
     "checklist-admin-bulk-actions-bulk-action-reports-result": {
         roles: ["admin"],
         startPage: "/admin/products",
         steps: [
             SIGN_IN_ADMIN,
-            "Open /admin/products and select three rows.",
-            "Run a non-destructive bulk action on them, such as a status or flag change.",
-            "Read the message shown when it completes.",
-            "Check it states how many rows succeeded and how many failed.",
-            "Check the affected rows show the change without a manual reload.",
+            "Open /admin/products and note which of three rows are already Featured — the bulk action is a TOGGLE, so this matters.",
+            "Select three rows that are all NOT featured, so the toggle moves them the same way.",
+            "Run the Feature bulk action.",
+            "Read whatever message appears when it completes, and record the exact wording.",
+            "Check whether the three rows show the change without a manual reload.",
+            "Re-select the same three and run Feature again to put them back.",
         ],
-        expectedBehaviour: "The result names the counts. A bare 'Done' after an action over N rows tells the admin nothing about whether it was N — and a partial success reported as an unqualified success is how rows silently stay unchanged.",
-        expectedUiState: "A message naming the succeeded and failed counts, and the rows updated in place. A bare success message is the finding.",
-        endResult: "Restore whatever the action changed.",
+        inputs: { action: "Feature", rowCount: 3 },
+        expectedBehaviour: "The result should name the counts. A bare 'Done' after an action over N rows tells the admin nothing about whether it was N — and a partial success reported as an unqualified success is how rows silently stay unchanged.",
+        expectedUiState: "🛑 EXPECT NO COUNTS, AND RECORD IT AS A FAILURE. The handler is a fire-and-forget loop over the selected ids followed by clearSelection(), so nothing collects an outcome: there is no succeeded count, no failed count, and no aggregated message to read. Record what IS shown — per-row toast, nothing at all, or a bare success — and whether the rows updated in place. 🛑 Select rows that are all in the same starting state: Feature inverts each row independently, so a mixed selection un-features the ones that were already featured.",
+        expectedData: { succeededCountShown: false, failedCountShown: false },
+        endResult: "The three rows are back to not-featured. Running the same toggle twice restores them, which is only true because they all started the same way.",
     },
     "checklist-admin-bulk-actions-bulk-partial-failure-named": {
         roles: ["admin"],
         startPage: "/admin/products",
         steps: [
             SIGN_IN_ADMIN,
-            "Open /admin/products and build a selection mixing rows the action can apply to with rows it cannot — an archived row alongside published ones, for example.",
-            "Run the action.",
-            "Read the result message.",
-            "Check the rows that failed are named rather than only counted.",
-            "Check the rows that succeeded did in fact change.",
+            "Open /admin/orders and build a selection mixing rows the action can apply to with rows it cannot — one PENDING order alongside one already CANCELLED and one already DELIVERED.",
+            "Run Mark Shipped over that selection.",
+            "Read the result message and record the exact wording.",
+            "Check whether the rows that could not be shipped are NAMED, merely counted, or not mentioned at all.",
+            "Reload and read each of the three rows' status to find out what actually happened to each.",
+            "Restore any order whose status this changed.",
         ],
-        expectedBehaviour: "Failures are named. 'Two rows failed' out of a selection of twenty leaves the admin re-checking twenty rows by hand to find which two — and the usual next step is to run the action again on everything, which is worse.",
+        inputs: { action: "Mark Shipped", mixedStatuses: "pending + cancelled + delivered" },
+        expectedBehaviour: "Failures should be named. 'Two rows failed' out of a selection of twenty leaves the admin re-checking twenty rows by hand to find which two — and the usual next step is to run the action again on everything, which is worse. Naming nothing at all is worse still: the admin cannot even tell that anything failed.",
         expectedUiState: "The failed rows are identified by title or id, with a reason. A bare failure count is the finding.",
         endResult: "Restore whatever succeeded.",
     },
@@ -149,14 +179,14 @@ export const authored = {
         steps: [
             SIGN_IN_ADMIN,
             "Open /admin/offers and select two rows.",
-            "Read every bulk action offered.",
-            "Run each one in turn, noting what changed.",
-            "Reload after each and check whether the records actually changed.",
-            "Record any action that only cleared the selection.",
+            "Read what the bulk bar offers — the correct answer here is NOTHING.",
+            "If any bulk action IS offered, run it, reload, and check whether the records actually changed.",
+            "Open a single offer's row menu and confirm Cancel is there instead, and that it demands a reason.",
         ],
-        expectedBehaviour: "Every offered action does what its label says. A destructively-labelled bulk action once existed here whose handler only cleared the selection — it read as working, cancelled nothing, and an admin using it believed a batch of offers had been cancelled.",
-        expectedUiState: "Each action produces a visible, persisted change matching its label. An action whose only effect is clearing the selection is the finding, named.",
-        endResult: "Restore whatever the actions changed.",
+        inputs: { expectedBulkActionCount: 0 },
+        expectedBehaviour: "Every offered action does what its label says — and where it cannot, it is not offered. A destructively-labelled bulk action once existed here whose handler only cleared the selection: it read as working, cancelled nothing, and an admin using it believed a batch of offers had been cancelled. It was DELETED rather than wired, because cancelling an offer requires a reason and one shared reason across a mixed selection is worse audit data than no bulk action at all.",
+        expectedUiState: "No bulk actions are offered on this page. That absence is the pass. A re-appeared bulk Cancel is the finding — whether it works or not — and per-offer Cancel is still available from the row menu, where it can ask for a reason.",
+        endResult: "Nothing is changed; no offer is cancelled.",
     },
     "checklist-admin-bulk-actions-bulk-users-actions": {
         roles: ["admin"],

package/dist/features/tester/seed-data/authored/admin__bundles.js

@@ -11,6 +11,33 @@
  * that mirror, so a write path that updates the rule and forgets the mirror
  * produces a bundle that renders as "0 items" with no error anywhere.
  *
+ * 🛑 THREE MEMBERS MINIMUM, AND EVERY CASE HERE ASKED FOR TWO (fixed 2026-09-29).
+ *
+ * BUNDLE_MIN_ITEMS is 3 (bundle-config.ts:10) and bundle-form.ts's superRefine
+ * enforces it with "Select at least 3 products (currently 2)." So the create
+ * case could never save, and the two cases that READ that bundle were testing
+ * something which had never been created — three verdicts of "could not test"
+ * for a rule the editor states on its own field label.
+ *
+ * Every member is now a real seeded id with its real price, so the undiscounted
+ * total is arithmetic a tester can check rather than a number to trust.
+ *
+ * 🛑 EVERY STANDARD LISTING IN THE CATALOGUE BELONGS TO store-beyblade-arena.
+ * The only other seller with stock is store-letitrip-official, whose six
+ * listings are all prize draws — so the cross-store refusal is exercised with
+ * one of those. The guard reads storeId and does not care about listing type.
+ * (CLAUDE.md claims product-tester-crossstore-a/b are seeded for exactly this;
+ * they are not, anywhere — recorded in OUTOFSCOPE.)
+ *
+ * 🛑 THE SLUG IS DERIVED AND THEREFORE KNOWABLE: the route slugifies the name
+ * and prefixes "bundle-", so 'QA Bundle admin-create' is always
+ * /bundles/bundle-qa-bundle-admin-create. The cases used to say "/bundles/{slug}"
+ * without saying how to learn it.
+ *
+ * audit-tester-created-id: bundle-qa-bundle-admin-create — created by case 1 step 2
+ * and visited by cases 1-3. It is not a seed fixture and must not be one: the point
+ * is to exercise the CREATE path, and a pre-seeded bundle would skip it.
+ *
  * @tag domain:tester
  * @tag layer:seed
  * @tag pattern:none
@@ -24,56 +51,69 @@ export const authored = {
         startPage: "/admin/bundles",
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/bundles and create one named 'QA Bundle admin-create'.",
-            "Add product-beyblade-burst-valkyrie (₹999) and product-beyblade-x-wizard-arrow (₹899) as members.",
-            "Set the bundle price to 1500 and save.",
+            "Open /admin/bundles/new and set Name to 'QA Bundle admin-create'.",
+            "Leave the member-source select on its static option, add exactly TWO members — product-beyblade-burst-valkyrie and product-beyblade-x-wizard-arrow — set 'Bundle price (₹)' to 1500, and try to save.",
+            "Read the refusal: the minimum is three, and the field label states the range.",
+            "Add product-beyblade-x-knife-shinobi (₹949) as the third member and save.",
             "RELOAD the editor and read the members, the price and the original total.",
-            "Open /bundles/{slug} in a private window and read the members, price and discount badge.",
-            "Attempt to add a member from a different store and read what happens.",
+            "Open /bundles/bundle-qa-bundle-admin-create — the slug is the name slugified under a 'bundle-' prefix — and read the members, price and discount badge.",
+            "Back in the editor add prizedraw-beyblade-mystery-box, which belongs to store-letitrip-official, as a fourth member, save, and read what happens.",
+            "Remove that fourth member and save, leaving the bundle at its three arena members.",
         ],
         inputs: {
             name: "QA Bundle admin-create",
             member1: "product-beyblade-burst-valkyrie",
             member2: "product-beyblade-x-wizard-arrow",
+            member3: "product-beyblade-x-knife-shinobi",
+            crossStoreMember: "prizedraw-beyblade-mystery-box",
             bundlePrice: 1500,
-            memberTotal: 1898,
+            memberTotal: 2847,
         },
-        expectedBehaviour: "The bundle stores its members, its locked price and the members' undiscounted total — the last of these is what drives the discount badge, so a bundle without it shows a price and no saving. Members must come from one store: the store id is the order-splitting key, and a cross-store bundle produces an order belonging to one seller holding another's products.",
-        expectedUiState: "After the reload both members are listed with a bundle price of ₹1,500 against ₹1,898. The public page shows both members and a discount badge. The cross-store member is refused at save time with a message naming the reason.",
-        expectedData: { memberCount: 2, bundlePrice: 1500 },
-        endResult: "Leave the bundle in place — the next three cases read it.",
+        expectedBehaviour: "A bundle holds at least three members, stores its locked price, and derives the members' undiscounted total SERVER-SIDE — the editor never sends that total, and it is what drives the discount badge, so a bundle without it shows a price and no saving. Members must come from one store: the store id is the order-splitting and payout key, so a cross-store bundle would produce an order belonging to one seller while holding another seller's products.",
+        expectedUiState: "The two-member save is refused inline with 'Select at least 3 products (currently 2).' — not a silent no-op and not a generic banner. With the third added, the reload lists all three, a bundle price of ₹1,500 against an original total of ₹2,847, and the public page shows the three members with a discount badge of roughly 47% off. The cross-store save is refused with a message naming how many sellers the members span, not a 500.",
+        expectedData: { memberCount: 3, bundlePrice: 1500, bundleOriginalTotal: 2847 },
+        endResult: "The bundle survives with its three arena members — the next two cases read it. The cross-store member is NOT part of it.",
     },
     "checklist-admin-bundles-bundle-stock-sync": {
         roles: ["admin", "seller", "guest"],
         startPage: "/admin/bundles",
         steps: [
-            "Sign in as admin@letitrip.in / TempPass123! and open /bundles/{slug} for 'QA Bundle admin-create' in a private window, noting it is purchasable.",
-            "Sign in as tyson@beybladearena.in / TempPass123! and set product-beyblade-x-wizard-arrow's stock to 0.",
-            "Reload the bundle's public page and read its availability.",
-            "Open /admin/bundles and read the bundle's row.",
-            "Set the product's stock back to its original value.",
-            "Reload the bundle's public page and read its availability again.",
+            "Open /bundles/bundle-qa-bundle-admin-create signed out and note that it offers purchase.",
+            "Sign in as tyson@beybladearena.in / TempPass123!, open /store/products, edit product-beyblade-x-wizard-arrow, and set its stock quantity from 12 to 0.",
+            "Reload /bundles/bundle-qa-bundle-admin-create and read its availability.",
+            "Sign in as admin@letitrip.in / TempPass123!, open /admin/bundles and read the bundle's row.",
+            "Sign back in as tyson@beybladearena.in and set that product's stock back to 12.",
+            "Reload /bundles/bundle-qa-bundle-admin-create and read its availability again.",
         ],
-        inputs: { member: "product-beyblade-x-wizard-arrow" },
+        inputs: { member: "product-beyblade-x-wizard-arrow", stockBefore: 12, stockDuring: 0 },
         expectedBehaviour: "A bundle is all-or-nothing, so one member going out of stock makes the whole bundle unavailable. That is kept in sync by a hook on the member's stock change rather than computed per request — which is what makes the reverse direction worth testing too: restoring the stock must restore the bundle.",
-        expectedUiState: "With the member at zero the bundle reads as unavailable and cannot be purchased. After the stock is restored it becomes purchasable again. A bundle still offering purchase with a zero-stock member is the failure.",
-        endResult: "The member's stock is restored. Both directions matter — a sync that only ever disables is half a sync.",
+        expectedUiState: "With the member at zero the bundle reads as unavailable and offers no purchase control. After the stock is restored it becomes purchasable again. A bundle still offering purchase with a zero-stock member is the failure; so is one that stays unavailable after the stock returns.",
+        expectedData: { stockAfterRestore: 12 },
+        endResult: "The member's stock is back at 12 and the bundle is purchasable. Both directions matter — a sync that only ever disables is half a sync, and leaving the stock at zero silently breaks the next case.",
     },
     "checklist-admin-bundles-bundle-edit-delete": {
         roles: ["admin", "guest"],
         startPage: "/admin/bundles",
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open the editor for 'QA Bundle admin-create' and write down every field.",
-            "Change ONLY the bundle price to 1400 and save.",
-            "RELOAD and compare every field against what was written down.",
-            "Remove one member, save, RELOAD, and read the member list and the original total.",
-            "Open the public page and read the members and the discount.",
-            "Delete the bundle and confirm it is gone from /admin/bundles and from /bundles.",
+            "Open /admin/bundles, open 'QA Bundle admin-create' for editing, and write down every field — name, description, price, the three members, cover image, brand and active.",
+            "Change ONLY 'Bundle price (₹)' to 1400 and save.",
+            "RELOAD the editor and compare every field against what was written down.",
+            "SWAP one member rather than dropping one: remove product-beyblade-x-knife-shinobi (₹949), add product-beyblade-burst-regalia-genesis (₹1,399), keeping three. Save, RELOAD, and read the member list and the original total.",
+            "Open /bundles/bundle-qa-bundle-admin-create and read the members and the discount badge.",
+            "Back in the editor click the delete control, confirm, and check the bundle is gone from /admin/bundles and from /bundles.",
         ],
-        inputs: { priceBefore: 1500, priceAfter: 1400 },
-        expectedBehaviour: "An edit writes back only what changed, and removing a member recomputes the undiscounted total — a stale total makes the discount badge claim a saving that no longer exists. The delete removes it from the public listing too.",
-        expectedUiState: "After the price edit only the price differs. After the member removal the list holds one member and the original total has fallen accordingly. After the delete the bundle is absent from both surfaces.",
+        inputs: {
+            priceBefore: 1500,
+            priceAfter: 1400,
+            memberRemoved: "product-beyblade-x-knife-shinobi",
+            memberAdded: "product-beyblade-burst-regalia-genesis",
+            totalBefore: 2847,
+            totalAfter: 3297,
+        },
+        expectedBehaviour: "An edit writes back only what changed, and changing the member list recomputes the undiscounted total server-side — a stale total makes the discount badge claim a saving that no longer exists. A SWAP rather than a bare removal is what makes this readable: the count stays at the legal minimum of three while the total must move, so a total that did not change cannot be excused as the member rule having been left alone.",
+        expectedUiState: "After the price edit only the price differs — every other field matches what was written down. After the swap the list holds three members and the original total reads ₹3,297 rather than ₹2,847, so the badge's saving shrinks. After the delete the bundle is absent from /admin/bundles and /bundles, and its own URL no longer renders it.",
+        expectedData: { memberCountAfterSwap: 3, bundleOriginalTotalAfterSwap: 3297 },
         endResult: "The bundle is deleted. A public page still rendering a deleted bundle is a cache or projection failure worth naming.",
     },
     "checklist-admin-bundles-bundle-brand-picker": {
@@ -81,17 +121,24 @@ export const authored = {
         startPage: "/admin/bundles",
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/bundles and create one named 'QA Bundle brand-picker' with two members from Beyblade Arena.",
-            "Find the brand picker and read what it offers.",
-            "Select Beyblade as the bundle's brand and save.",
-            "RELOAD and read the brand.",
-            "Open /brands/brand-beyblade in a private window and find the bundle in its Bundles tab.",
-            "Clear the brand, save, reload, and check the bundle leaves that tab.",
+            "Open /admin/bundles/new, set Name to 'QA Bundle brand-picker', and add THREE members from Beyblade Arena — product-beyblade-burst-valkyrie, product-beyblade-x-wizard-arrow and product-beyblade-x-knife-shinobi. Fewer than three is refused.",
+            "Set 'Bundle price (₹)' to 2000.",
+            "Find the 'Brand' select and read what it offers.",
+            "Select Beyblade and save.",
+            "RELOAD the editor and read the brand.",
+            "Open /brands/brand-beyblade signed out and find the bundle in its Bundles tab.",
+            "Back in the editor set Brand to 'No specific brand', save, reload the brand page, and check the bundle has left that tab.",
             "Delete the bundle.",
         ],
-        inputs: { name: "QA Bundle brand-picker", brand: "Beyblade" },
+        inputs: {
+            name: "QA Bundle brand-picker",
+            brand: "Beyblade",
+            clearedTo: "No specific brand",
+            bundlePrice: 2000,
+        },
         expectedBehaviour: "A bundle's own brand tag is a DIFFERENT field from any brand filter inside a dynamic member rule — the tag says which brand the bundle belongs to regardless of how its members were resolved, and it is what the brand page's Bundles tab filters on. Not every bundle needs one; a genuinely cross-brand bundle leaves it unset.",
-        expectedUiState: "The picker offers real brands. With the brand set the bundle appears in that brand's Bundles tab; with it cleared it leaves. A bundle appearing on a brand page it was never tagged with means the tab is filtering on the member rule instead.",
-        endResult: "The bundle is deleted by the final step.",
+        expectedUiState: "The select offers the real seeded brands plus a 'No specific brand' option — not a free-text box and not an empty list. With Beyblade set the bundle appears in that brand's Bundles tab; with it cleared it leaves. Worth watching: two of the three members are tagged Takara-Tomy rather than Beyblade, so a bundle still appearing under Beyblade after the tag is cleared means the tab is filtering on the MEMBERS instead of the tag.",
+        expectedData: { brandAfterReload: "Beyblade" },
+        endResult: "The bundle is deleted by the final step, so /brands/brand-beyblade's Bundles tab holds only the seeded bundles again.",
     },
 };

package/dist/features/tester/seed-data/authored/admin__buyer-data-admin.js

@@ -13,6 +13,26 @@
  * returns a per-user summary only, so the honest fix was to route to the owning
  * user rather than widen the payload.
  *
+ * 🛑 /admin/addresses IS AN OWNER-SCOPED LOOKUP, NOT A LISTING (fixed 2026-09-29).
+ *
+ * It renders `AdminAddressBookView`: an 'Owner type' select (user | store), an
+ * 'Owner ID' text field placeholdered `user-...` / `store-...`, and a Search
+ * button. There are no columns, no sort dropdown, no filter drawer and no
+ * free-text search of addresses — and nothing at all is shown until an owner id
+ * is searched. Three cases here described a listing with owner-type filters and
+ * a sort default; none of that exists on this page.
+ *
+ * The banned-address queue those descriptions actually fit is a DIFFERENT
+ * route, `ROUTES.ADMIN.BANNED_ADDRESSES` ("Banned Addresses"), backed by
+ * `AdminAddressesView` — similar name, different page. Worth stating because
+ * reading the plausibly-named component instead of following the route is how
+ * this was nearly mis-audited.
+ *
+ * Its editor DOES exist, at /admin/addresses/new and /admin/addresses/[id]/edit,
+ * and per its own header the postal code is now validated per country by schema
+ * rather than by `length === 6` — so 'abcdef' should be REJECTED, and the CRUD
+ * case expects a pass.
+ *
  * @tag domain:tester
  * @tag layer:seed
  * @tag pattern:none
@@ -26,7 +46,7 @@ export const authored = {
         startPage: "/admin/carts",
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open the admin carts listing and read every column.",
+            "Open /admin/carts and read every column.",
             "Check each row identifies whose cart it is and how many items it holds.",
             "Read whether guest carts are distinguishable from signed-in ones.",
             "Use every filter and sort offered, confirming each changes the rows.",
@@ -43,14 +63,16 @@ export const authored = {
         startPage: "/admin/carts",
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open the admin carts listing and find a row whose item count is greater than one.",
-            "Click the row and read what opens.",
-            "Read whether the individual ITEMS are listed — titles, quantities, prices.",
-            "Read the row action menu and check it offers a view rather than only mutations.",
-            "Close and try opening a different row the same way.",
+            "Open /admin/carts and find a row whose item count is greater than one.",
+            "Click the row and read what opens — it should be a 'Cart Details' modal.",
+            "Read its badge: a guest cart reads 'Guest' and a signed-in one reads 'Authenticated'.",
+            "Read its fields — Session or User, Last updated, Cart ID.",
+            "Read the 'Items in cart' section and check each item carries a title, a quantity and a price.",
+            "Close and open a different row the same way.",
         ],
+        inputs: { modalTitle: "Cart Details", itemsHeading: "Items in cart" },
         expectedBehaviour: "A row opens to show the cart's items. The list already computes the item count from the items array and then discards it, so the data needed to render the detail is present at list time — this is a UI wiring gap rather than a missing query, and the fix is a detail view rather than a wider payload.",
-        expectedUiState: "Clicking a row opens a detail showing each item with its title, quantity and price. A row that offers only actions, or does nothing on click, is the dead-end failure this page family exists to close.",
+        expectedUiState: "Clicking a row opens the 'Cart Details' modal showing each item with its title, quantity and price under 'Items in cart'. A row that does nothing on click, or opens a modal whose items section is empty for a cart the list counted as non-empty, is the dead-end failure this page family exists to close.",
         endResult: "Read-only; close without acting.",
     },
     "checklist-admin-buyer-data-admin-wishlists-admin-view": {
@@ -58,7 +80,7 @@ export const authored = {
         startPage: "/admin/wishlists",
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open the admin wishlists listing and read every column.",
+            "Open /admin/wishlists and read every column.",
             "Check each row names the owning user and the number of items.",
             "Read whether the item titles themselves are shown in the list.",
             "Use every filter and sort offered.",
@@ -74,15 +96,15 @@ export const authored = {
         startPage: "/admin/wishlists",
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open the admin wishlists listing and click a row.",
-            "Read where it lands.",
-            "Check whether it opens the owning USER rather than a wishlist detail.",
-            "Go back, open the admin history listing, and click a row there.",
-            "Read where that lands.",
+            "Open /admin/wishlists and click a row.",
+            "Read the URL it lands on — it should be that row's owner under /admin/users/{userId}, not a wishlist detail.",
+            "Go back, open /admin/history, and click a row there.",
+            "Read the URL that lands on.",
             "From the user page reached, check the wishlist or history is readable in context.",
         ],
+        inputs: { expectedDestination: "/admin/users/{userId}" },
         expectedBehaviour: "These two rows route to the owning user rather than to a per-record detail, and that is the correct answer rather than a shortcut: their list queries return only a per-user summary, so a detail view would have to fetch separately, and the user page is where the rest of that person's data already is.",
-        expectedUiState: "Both rows open the owning user's admin page. Neither is inert. From there the wishlist or history contents are reachable. A row that does nothing at all is the failure; a row routing to the user is a pass.",
+        expectedUiState: "Both rows navigate to /admin/users/{userId} for that row's owner. Neither is inert. From there the wishlist or history contents are reachable. A row that does nothing at all is the failure; a row routing to the user is a pass. A row whose owner id is missing, so the click does nothing, is also a failure — the navigation is guarded on it.",
         endResult: "Read-only; close without acting.",
     },
     "checklist-admin-buyer-data-admin-history-admin-view": {
@@ -90,7 +112,7 @@ export const authored = {
         startPage: "/admin/history",
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open the admin browsing-history listing and read every column.",
+            "Open /admin/history and read every column.",
             "Check each row names the owning user and the number of entries.",
             "Read the highest entry count in the list.",
             "Use every filter and sort offered.",
@@ -107,17 +129,17 @@ export const authored = {
         startPage: "/admin/notifications",
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open the admin notifications listing and read every column.",
+            "Open /admin/notifications and read every column.",
             "Read every type filter offered and select each, noting any that returns nothing.",
             "For each empty filter, check the unfiltered list for rows of that type.",
-            "Open a row's view action and read the full body and payload.",
+            "Open a row menu's 'View details' action and read the full body and payload in the modal it opens.",
             "Read whether the recipient is identified.",
             "Search zzzznope and read the count.",
         ],
         inputs: { nonsenseQuery: "zzzznope" },
-        expectedBehaviour: "Every type chip names a value notifications actually carry. The type union is a single runtime list, and for a long time the filters were built from a nine-value copy while twenty-seven types existed — eighteen were unfilterable and two could not be allow-listed for any channel at all.",
-        expectedUiState: "Every type filter returns its own rows or is empty with none unfiltered either. A row opens to show the full body and payload rather than only the title. 'zzzznope' returns none.",
-        expectedData: { nonsenseResultCount: 0 },
+        expectedBehaviour: "Every type chip names a value notifications actually carry, and the union has THIRTY values today. The type union is a single runtime list, and for a long time the filters were built from a nine-value copy — most types were unfilterable and two could not be allow-listed for any channel at all. Count the chips against thirty rather than against the seeded data, which covers only ten of them.",
+        expectedUiState: "Every type filter returns its own rows or is empty with none unfiltered either. A row opens to show the full body and payload rather than only the title. 'zzzznope' returns none. A chip MISSING for a real type is as much a finding as a chip that matches nothing — record the count you saw.",
+        expectedData: { nonsenseResultCount: 0, typeChipCount: 30 },
         endResult: "Read-only. A chip empty while matching rows sit unfiltered is the finding, named by type.",
     },
     "checklist-admin-buyer-data-admin-reviews-admin-view": {
@@ -125,7 +147,7 @@ export const authored = {
         startPage: "/admin/reviews",
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/reviews and read every column, including any review images.",
+            "Open /admin/reviews and read every column, including any review images. Roughly 15-20% of the 79 seeded reviews carry one.",
             "Check each image tile renders rather than showing a placeholder icon.",
             "Read the search box's placeholder for how it matches.",
             "Type a reviewer's FULL name and read the results.",
@@ -144,16 +166,21 @@ export const authored = {
         startPage: "/admin/addresses",
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open the admin addresses listing and read every column.",
-            "Read whether store pickup addresses and buyer delivery addresses are distinguishable.",
-            "Use any owner-type filter and confirm it separates the two.",
-            "Read how names and phone numbers are displayed.",
-            "Read the sort dropdown's default and check it is one of the offered options.",
-            "Search zzzznope and read the count.",
+            "Open /admin/addresses and read what the page offers before any input — an 'Owner type' select, an 'Owner ID' field and a Search button.",
+            "Read whether anything is listed before a search is run.",
+            "Leave Owner type on 'user', enter user-admin-letitrip, and click Search.",
+            "Read every field shown for each address returned, and record exactly how much of the name and phone number is displayed.",
+            "Switch Owner type to 'store', enter store-beyblade-arena, and Search.",
+            "Enter zzzznope as the Owner ID and Search.",
         ],
-        inputs: { nonsenseQuery: "zzzznope" },
-        expectedBehaviour: "Both kinds live in one collection discriminated by owner type, so the list must show which is which. Names, phones and street lines are PII-encrypted at rest — how much this list decrypts and displays is worth recording rather than assuming. A default sort that is not among the offered options opens the dropdown with nothing selected, which this listing family has done before.",
-        expectedUiState: "Rows identify their owner type and an owner-type filter separates them. The sort default is one of the options. 'zzzznope' returns none. Record exactly how much of each name and phone is shown.",
+        inputs: {
+            userOwner: "user-admin-letitrip",
+            storeOwner: "store-beyblade-arena",
+            nonsenseOwner: "zzzznope",
+        },
+        expectedBehaviour: "Both buyer delivery and store pickup addresses live in one collection discriminated by owner type, and this page reaches them one OWNER at a time rather than as a browsable list — which is why the owner type is an input rather than a filter. Names, phones and street lines are PII-encrypted at rest, so how much this page decrypts and displays is worth recording rather than assuming.",
+        expectedUiState: "Before a search the page lists nothing, which is correct here rather than an empty-state bug. A searched owner returns their addresses; a nonsense owner id returns 'No addresses found for this owner.' rather than an error or the full collection. Record exactly how much of each name and phone is shown.\n\nNote what this page is NOT: there are no columns, no sort dropdown, no filter drawer and no free-text address search. A case expecting those is describing the Banned Addresses queue, which is a different route.",
+        expectedData: { listedBeforeSearch: 0, nonsenseOwnerResultCount: 0 },
         endResult: "Read-only; nothing persists beyond the URL.",
     },
     "checklist-admin-buyer-data-admin-store-addresses-admin-row-opens-detail": {
@@ -161,27 +188,28 @@ export const authored = {
         startPage: "/admin/addresses",
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open the admin addresses listing and click a store-owned row.",
-            "Read what opens and whether every field is shown, including the landmark.",
-            "Go back and click a buyer-owned row.",
-            "Read what opens there.",
-            "Check the row action menu offers a view rather than only mutations.",
+            "Open /admin/addresses, search Owner type 'store' with store-beyblade-arena, and read the card rendered for each address.",
+            "Record which fields the card shows — label, full name, street, city, state, postal code, phone — and specifically whether the LANDMARK appears.",
+            "Check whether the card is openable at all: a link, a click target or an edit affordance leading to /admin/addresses/{id}/edit.",
+            "Search Owner type 'user' with user-admin-letitrip and read the same for a buyer-owned address.",
+            "Open /admin/addresses/{one of those ids}/edit directly and compare the fields there against what the card showed.",
         ],
-        expectedBehaviour: "A row opens to its full detail for both owner types. The landmark is the field worth naming: a form that cannot express it sends undefined and overwrites, so a detail view that never shows it hides whether the value survived.",
-        expectedUiState: "Both kinds open to a detail showing every stored field, landmark included. A view affordance exists alongside any actions. A row offering only Delete is a dead end.",
-        endResult: "Read-only; close without acting.",
+        inputs: { storeOwner: "store-beyblade-arena", userOwner: "user-admin-letitrip" },
+        expectedBehaviour: "An admin can read every stored field of an address, for both owner types. The landmark is the field worth naming: a form that cannot express it sends undefined and overwrites, so a surface that never shows it hides whether the value survived.",
+        expectedUiState: "Both owner types render cards carrying the stored fields. The editor at /admin/addresses/{id}/edit shows every field including the landmark. Record any field the editor has and the card does not — a card that omits the landmark while the editor can write it is the gap this case is for.",
+        endResult: "Read-only; close the editor without saving.",
     },
     "checklist-admin-buyer-data-admin-addresses-crud-admin": {
         roles: ["admin"],
         startPage: "/admin/addresses",
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open the admin addresses listing and create one: 'QA Address admin-crud', '13 Test Lane', Indore, Madhya Pradesh, 452010, landmark 'Beside the arena'.",
-            "Save, RELOAD, and read every field including the landmark.",
-            "Edit ONLY the street to '14 Test Lane', save, RELOAD, and read every field again.",
+            "Open /admin/addresses/new and create one for Owner type 'user', Owner ID user-admin-letitrip: label 'QA Address admin-crud', '13 Test Lane', Indore, Madhya Pradesh, 452010, landmark 'Beside the arena'.",
+            "Save, then find it again via /admin/addresses searching that owner, open /admin/addresses/{its id}/edit, and read every field including the landmark.",
+            "Edit ONLY the street to '14 Test Lane', save, REOPEN the editor, and read every field again.",
             "Type abcdef into the postal code field and attempt to save.",
-            "Read where the error appears.",
-            "Delete the address and RELOAD to confirm.",
+            "Read where the error appears — on the field, or as a banner, or not at all.",
+            "Restore the postal code, then delete the address and search that owner again to confirm it is gone.",
         ],
         inputs: {
             name: "QA Address admin-crud",
@@ -191,7 +219,7 @@ export const authored = {
             badPostcode: "abcdef",
         },
         expectedBehaviour: "Create, edit and delete persist and an edit to one field leaves the rest alone. The postal code is validated by FORMAT rather than by length: a length-only rule accepts 'abcdef' as a valid six-character Indian PIN code, and one admin route did exactly that.",
-        expectedUiState: "After each reload every value holds, including the landmark after the street edit. 'abcdef' is rejected on the postal code field before any request is sent, not returned as a server error with nothing marked.",
+        expectedUiState: "After each reopen every value holds, including the landmark after the street edit — a landmark that vanishes when only the street changed is the overwrite this case is for. 'abcdef' is rejected ON THE POSTAL CODE FIELD before any request is sent, not returned as a server error with nothing marked. This half is expected to PASS: the form validates per country by schema now, where it once checked only that the value was six characters long — which 'abcdef' satisfies.",
         endResult: "The address is deleted by the final step.",
     },
     "checklist-admin-buyer-data-admin-stores-admin-view": {
@@ -200,15 +228,20 @@ export const authored = {
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
             "Open /admin/stores and read every column and status chip.",
-            "Select each status chip in turn and read the rows returned.",
-            "Note whether the pending and suspended chips return anything.",
-            "Open a verified store's editor, change ONE unrelated field such as its description, and save.",
-            "RELOAD and read whether it is still verified, still featured, and whether its capabilities are unchanged.",
+            "Select each status chip in turn and read the rows returned — the seed carries store-blader-bazaar as pending and store-vintage-vault-co as suspended, so neither chip should be empty.",
+            "Open store-letitrip-official — verified and featured — for editing and write down its verified flag, its featured flag, its capabilities and its admin notes.",
+            "Change ONLY its description and save.",
+            "RELOAD and read all four of those back.",
             "Restore the description.",
         ],
+        inputs: {
+            store: "store-letitrip-official",
+            pendingStore: "store-blader-bazaar",
+            suspendedStore: "store-vintage-vault-co",
+        },
         expectedBehaviour: "🛑 This is the highest-severity case on the page. The list serializer once omitted the verified, featured, capabilities and notes fields, so the editor seeded them as undefined and the save handler sent those defaults back unconditionally — saving ANY unrelated field silently un-verified the store and reset its capabilities. The seed carries a pending and a suspended store precisely so those chips are not permanently empty.",
-        expectedUiState: "Every status chip returns rows or is genuinely empty. After the description save and reload the store is STILL verified, still featured, and its capabilities are unchanged. A store that quietly lost its verified badge is the failure, and the save reported success.",
-        expectedData: { verifiedPreserved: true },
+        expectedUiState: "Every status chip returns rows; the pending and suspended chips have a seeded store each. After the description save and reload the store is STILL verified, still featured, its capabilities are unchanged and its admin notes are intact. A store that quietly lost its verified badge is the failure, and the save reported success. This is expected to PASS — the list serializer now carries all five of those fields — but it is the case worth re-running after any change to that route, because the failure is silent and destructive.",
+        expectedData: { verifiedPreserved: true, featuredPreserved: true, capabilitiesPreserved: true },
         endResult: "The description is restored and the store's flags are as they were. Re-read every flag after the reload, not just the one that was edited.",
     },
     "checklist-admin-buyer-data-admin-admin-store-detail-page": {
@@ -216,14 +249,14 @@ export const authored = {
         startPage: "/admin/stores",
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/stores and open a store's detail panel from the list.",
-            "Write down every field label it shows.",
-            "Note the store id and close the panel.",
-            "Open that store's standalone admin detail page directly by URL.",
-            "Write down every field label and compare the two lists.",
-            "Reload the standalone page and confirm it loads the same store.",
-            "Read whether the store's WhatsApp access token appears anywhere on either surface.",
+            "Open /admin/stores and open store-beyblade-arena's detail panel from the list.",
+            "Write down every field label it shows, then close the panel.",
+            "Open /admin/stores/store-beyblade-arena/view directly.",
+            "Write down every field label there and compare the two lists.",
+            "Reload that page and confirm it loads the same store rather than 404ing or resetting.",
+            "Search both surfaces, and the page source of the standalone one, for a WhatsApp access token.",
         ],
+        inputs: { store: "store-beyblade-arena", standalonePage: "/admin/stores/{id}/view" },
         expectedBehaviour: "The panel and the page render from one shared content component, so their fields match by construction. The store document's WhatsApp token is decrypted on every read, so any surface that does not deliberately project it is handling plaintext — an admin page is allowed to show more than a public one, but not the raw credential.",
         expectedUiState: "Both surfaces show the same fields and the standalone page survives a reload. The access token is masked or absent on both. A field in one and not the other means a second copy of the content component has appeared.",
         expectedData: { rawTokenShown: 0 },