@mohasinac/appkit 4.34.0 → 4.35.0

package/dist/features/tester/seed-data/authored/admin__bans-and-trust.js

@@ -0,0 +1,226 @@
+/*
+ * WHY: Authored six-part procedures for the admin/bans-and-trust page.
+ * WHAT: 12 case(s), keyed by full checklist id.
+ *
+ * 🛑 THESE CASES BAN REAL SEEDED ACCOUNTS AND EVERY ONE RESTORES WHAT IT CHANGED.
+ * `users` is in the PRESERVE tier — a tester run never re-seeds it — so a ban left
+ * in place outlives every reseed and quietly breaks whichever other checklist page
+ * signs in as that persona. Each procedure names its restore step for that reason,
+ * and each uses a persona reserved for this page rather than one another page
+ * depends on.
+ *
+ * The unban case is the load-bearing one. Session role fields refresh only
+ * periodically, so a guard reading the cached snapshot keeps blocking a user who
+ * was unbanned a moment ago — the fix is to re-read on navigation, not to widen
+ * the refresh interval.
+ *
+ * @tag domain:tester
+ * @tag layer:seed
+ * @tag pattern:none
+ * @tag access:server-only
+ * @tag consumers:seed-data/authored/index.ts
+ * @tag sideEffects:none
+ */
+const SIGN_IN_ADMIN = "Sign in as admin@letitrip.in / TempPass123!.";
+export const authored = {
+    "checklist-admin-bans-and-trust-soft-ban-blocks-signin": {
+        roles: ["admin", "buyer"],
+        startPage: "/admin/users",
+        steps: [
+            SIGN_IN_ADMIN,
+            "Open /admin/users and find the account rohit.collect@gmail.com.",
+            "Soft-ban the account with the reason 'QA ban probe — checklist case, will be lifted.'",
+            "Sign out.",
+            "Try to sign in as rohit.collect@gmail.com / TempPass123!.",
+            "Read what is shown.",
+            "Sign back in as the admin and lift the ban.",
+        ],
+        inputs: { reason: "QA ban probe — checklist case, will be lifted." },
+        expectedBehaviour: "A soft-banned account cannot sign in and is told why. A refusal with a generic credentials error is worse than a block — the user believes their password is wrong and resets it, repeatedly, against an account that would refuse them either way.",
+        expectedUiState: "The sign-in is refused with a message naming the ban, not an invalid-credentials error. The reason the admin typed is visible to the user.",
+        endResult: "The ban is lifted and the account signs in again.",
+    },
+    "checklist-admin-bans-and-trust-soft-ban-requires-reason": {
+        roles: ["admin"],
+        startPage: "/admin/users",
+        steps: [
+            SIGN_IN_ADMIN,
+            "Open /admin/users and start banning the account rohit.collect@gmail.com.",
+            "Leave the reason field empty and submit.",
+            "Read what happens.",
+            "Type a one-character reason and submit.",
+            "Read whether that is accepted.",
+            "Cancel without banning.",
+        ],
+        expectedBehaviour: "A ban carries a reason, enforced rather than requested. The reason is what the banned user reads and what the audit log records — a ban with none leaves both the user and the next admin with an action and no explanation.",
+        expectedUiState: "The empty submission is refused with an inline error on the reason field, not a banner. A one-character reason is refused too if a minimum length applies.",
+        endResult: "Nobody is banned.",
+    },
+    "checklist-admin-bans-and-trust-unban-restores-access": {
+        roles: ["admin", "buyer"],
+        startPage: "/admin/users",
+        steps: [
+            SIGN_IN_ADMIN,
+            "Soft-ban the account rohit.collect@gmail.com with the reason 'QA unban probe — checklist case.'",
+            "In a second browser, sign in as rohit.collect@gmail.com / TempPass123! and confirm the block.",
+            "As the admin, lift the ban.",
+            "In the second browser, WITHOUT signing out or reloading, navigate to another page.",
+            "Read whether access is restored.",
+            "Note how long it took, if it was not immediate.",
+        ],
+        inputs: { reason: "QA unban probe — checklist case." },
+        expectedBehaviour: "A lifted ban takes effect on the next navigation. Role and status fields on a session refresh only periodically, so a guard reading that cached snapshot keeps blocking for minutes after the ban is gone — which reads to the user as the unban not having worked. The guard re-reads on navigation into a gated area for exactly this reason.",
+        expectedUiState: "Access is restored on the next navigation, without a sign-out or a hard reload. A block persisting for minutes is the finding, recorded with how long.",
+        endResult: "The account is unbanned and working.",
+    },
+    "checklist-admin-bans-and-trust-hard-ban-cascade-runs": {
+        roles: ["admin"],
+        startPage: "/admin/users",
+        steps: [
+            SIGN_IN_ADMIN,
+            "Open /admin/users and hard-ban the account arjun.builder@gmail.com with the reason 'QA hard-ban cascade probe — checklist case.'",
+            "Read what the interface says immediately after submitting.",
+            "Check it reports that work was queued rather than claiming completion.",
+            "Wait for the completion signal and read what it reports.",
+            "Open the account and read its state.",
+            "Lift the ban afterwards.",
+        ],
+        inputs: { reason: "QA hard-ban cascade probe — checklist case." },
+        expectedBehaviour: "A hard ban runs a multi-stage cascade that exceeds a single request's time budget, so it is queued as a background job and its completion is reported back. A screen that claims success at submit time is claiming an outcome it cannot know — the job may still fail.",
+        expectedUiState: "The submit reports queued work, a completion signal follows, and the account's state reflects the finished cascade. An immediate unqualified success message is the finding.",
+        endResult: "The ban is lifted.",
+    },
+    "checklist-admin-bans-and-trust-hard-ban-recorded-in-audit-log": {
+        roles: ["admin"],
+        startPage: "/admin/audit-log",
+        steps: [
+            SIGN_IN_ADMIN,
+            "Soft-ban the account rohit.collect@gmail.com with the reason 'QA audit-log probe — checklist case.', then lift it.",
+            "Open /admin/audit-log.",
+            "Find the ban entry and the unban entry.",
+            "Read the acting admin, the target and the reason on each.",
+            "Check the reason is the one typed.",
+            "Check no personal name or email of the banned user appears in the entry's stored detail.",
+        ],
+        inputs: { reason: "QA audit-log probe — checklist case." },
+        expectedBehaviour: "Bans, unbans and role changes are the privileged actions the audit log exists for, and each records who acted and why. The log is not encrypted, so it carries the target's identifier rather than their name or email — a readable name there is a leak into a surface that was never designed to hold one.",
+        expectedUiState: "Both entries present with the acting admin, the target and the exact reason. A missing entry is one finding; a readable email or personal name in the entry's detail is a different and more serious one.",
+        endResult: "The account is unbanned; the log entries remain.",
+    },
+    "checklist-admin-bans-and-trust-ban-status-visible-in-list": {
+        roles: ["admin"],
+        startPage: "/admin/users",
+        steps: [
+            SIGN_IN_ADMIN,
+            "Soft-ban the account rohit.collect@gmail.com with the reason 'QA list-marker probe — checklist case.'",
+            "Return to /admin/users without opening the account.",
+            "Find the row and read what marks it as banned.",
+            "Check the marker is readable against its background.",
+            "Switch to dark mode and read it again.",
+            "Lift the ban and check the marker clears.",
+        ],
+        inputs: { reason: "QA list-marker probe — checklist case." },
+        expectedBehaviour: "A banned account is marked in the list without opening it, and the marker is legible in both themes. A status tint and its ink both invert with the theme, so a badge pairing a tint with fixed white text is invisible in exactly one of them.",
+        expectedUiState: "A readable badge on the row in both light and dark mode, cleared when the ban is lifted. White-on-near-white in either theme is the finding.",
+        endResult: "The account is unbanned and unmarked.",
+    },
+    "checklist-admin-bans-and-trust-ban-filter-returns-banned-only": {
+        roles: ["admin"],
+        startPage: "/admin/users",
+        steps: [
+            SIGN_IN_ADMIN,
+            "Soft-ban the account rohit.collect@gmail.com with the reason 'QA filter probe — checklist case.'",
+            "Open /admin/users and apply the filter for banned accounts.",
+            "Read the rows returned and check the account rohit.collect@gmail.com is among them.",
+            "Check no unbanned account is in the result.",
+            "Clear the filter and check the full list returns.",
+            "Lift the ban and re-apply the filter, checking the account has left it.",
+        ],
+        inputs: { reason: "QA filter probe — checklist case." },
+        expectedBehaviour: "The filter returns exactly the banned accounts. A filter chip whose value does not byte-for-byte match a stored one matches nothing forever and reports no error — an empty result is indistinguishable from 'no banned users', which is why the case bans somebody first.",
+        expectedUiState: "The banned account is in the filtered result and unbanned accounts are not. An empty result with a known banned account present is the finding.",
+        endResult: "The account is unbanned.",
+    },
+    "checklist-admin-bans-and-trust-session-ip-masked": {
+        roles: ["admin"],
+        startPage: "/admin/sessions",
+        steps: [
+            SIGN_IN_ADMIN,
+            "Open /admin/sessions and read a session's IP address as displayed.",
+            "Check it is partially hidden rather than complete.",
+            "Open the browser's network panel and read the response that populated the list.",
+            "Search that payload for a complete IP address.",
+            "Search the page's own embedded data for one as well.",
+        ],
+        expectedBehaviour: "The IP is masked before it leaves the server, not on the way to the screen. A masked display over an unmasked payload is still a leak — the value is in the page and in the browser's history, and only the rendering hides it.",
+        expectedUiState: "The displayed value is partial AND no complete IP appears in the payload or the page data. A complete address anywhere is the finding, with where it was found.",
+        endResult: "Read-only.",
+    },
+    "checklist-admin-bans-and-trust-sessions-list-device-details": {
+        roles: ["admin"],
+        startPage: "/admin/sessions",
+        steps: [
+            SIGN_IN_ADMIN,
+            "Open /admin/sessions.",
+            "Read each row's browser, operating system and device.",
+            "Read the last-activity time and check it is a real timestamp rather than a placeholder.",
+            "Sort or filter by activity and check the order follows.",
+            "Open a session's detail, if one is offered, and read the same fields there.",
+        ],
+        expectedBehaviour: "Each session states which device it belongs to and when it was last used, because that is what an admin needs to decide whether to revoke it. A row showing only an identifier makes the decision impossible.",
+        expectedUiState: "Browser, operating system, device and a real last-activity timestamp on every row, with sorting that follows. A dash where a device should be is a finding.",
+        endResult: "Read-only.",
+    },
+    "checklist-admin-bans-and-trust-revoke-session-signs-out": {
+        roles: ["admin", "buyer"],
+        startPage: "/admin/sessions",
+        steps: [
+            "In a second browser, sign in as rohit.collect@gmail.com / TempPass123! and leave a page open.",
+            SIGN_IN_ADMIN,
+            "Open /admin/sessions and find that account's session.",
+            "Revoke it.",
+            "In the second browser, navigate to any signed-in page.",
+            "Read whether the account is still signed in.",
+            "Reload the admin sessions list and check the row is gone.",
+        ],
+        expectedBehaviour: "Revoking a session ends it. Removing the row without invalidating the credential is the failure that matters — it reads as done, and the device it was supposed to lock out keeps working indefinitely.",
+        expectedUiState: "The second browser is signed out on its next navigation and the row is gone from the list. A still-signed-in second browser is the finding, regardless of the row disappearing.",
+        endResult: "The session is ended; sign the account back in if another case needs it.",
+    },
+    "checklist-admin-bans-and-trust-unban-request-reaches-admin": {
+        roles: ["admin", "buyer"],
+        startPage: "/admin/users",
+        steps: [
+            SIGN_IN_ADMIN,
+            "Soft-ban the account rohit.collect@gmail.com with the reason 'QA unban-request probe — checklist case.'",
+            "In a second browser, sign in as rohit.collect@gmail.com / TempPass123! and follow whatever route the block offers for appealing.",
+            "Submit an unban request with the text 'QA unban request — checklist case, please ignore.'",
+            "As the admin, find that request in an admin surface.",
+            "Read whether it can be actioned from there.",
+            "Lift the ban afterwards.",
+        ],
+        inputs: {
+            banReason: "QA unban-request probe — checklist case.",
+            requestText: "QA unban request — checklist case, please ignore.",
+        },
+        expectedBehaviour: "An appeal a banned user can submit must land somewhere an admin will see it. A submission form with no admin-side surface is the worst half-built shape available here — the user is told their appeal was received, and nobody will ever read it.",
+        expectedUiState: "The request is visible to the admin with its text and its author, and can be actioned. A form with no admin surface behind it is the finding.",
+        endResult: "The account is unbanned.",
+    },
+    "checklist-admin-bans-and-trust-banned-user-content-handling": {
+        roles: ["admin", "seller"],
+        startPage: "/admin/users",
+        steps: [
+            "Open /stores/store-beyblade-arena as a signed-out visitor and note that its listings are visible.",
+            SIGN_IN_ADMIN,
+            "Soft-ban the seller account tyson@beybladearena.in with the reason 'QA seller-ban content probe — checklist case.'",
+            "As a signed-out visitor, reload /stores/store-beyblade-arena and read what is shown.",
+            "Open /products and check whether that store's listings still appear.",
+            "Lift the ban and reload both.",
+        ],
+        inputs: { storeId: "store-beyblade-arena", reason: "QA seller-ban content probe — checklist case." },
+        expectedBehaviour: "Banning a seller takes their storefront and listings out of public view, and lifting it restores them. Public visibility is gated on the store's own status rather than the user's, so flipping only the user record leaves a banned seller's catalogue fully purchasable.",
+        expectedUiState: "After the ban, the store page and its listings are not publicly reachable; after the lift, both return exactly as before. Listings still buyable during the ban is the finding.",
+        endResult: "The ban is lifted and the store is public again.",
+    },
+};

package/dist/features/tester/seed-data/authored/admin__blog-faqs.d.ts

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

package/dist/features/tester/seed-data/authored/admin__blog-faqs.js

@@ -0,0 +1,82 @@
+/*
+ * WHY: Authored six-part procedures for the admin/blog-faqs page.
+ * WHAT: 3 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.
+ *
+ * 🛑 A FAQ'S ANSWER IS NOT A STRING. The create path wraps a flat answer into a
+ * text-plus-format object and writes the slug to a nested path; an update path
+ * that spreads the body straight through writes a bare string into a field every
+ * reader expects to be an object. That transform asymmetry is what the FAQ case
+ * below is really testing, and it only shows after a reload.
+ *
+ * @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-admin-blog-faqs-blog-create-edit-publish": {
+        roles: ["admin", "guest"],
+        startPage: "/admin/blog",
+        steps: [
+            "Sign in as admin@letitrip.in / TempPass123!.",
+            "Open the admin blog list and create a post titled 'QA Blog create-edit-publish' with an excerpt, a category, two tags and body content.",
+            "Save it as a DRAFT and read the status shown.",
+            "Open /blog in a private window and check the draft is NOT listed.",
+            "Return to the admin editor, change the body, publish, and RELOAD the editor.",
+            "Read every field to confirm only the body changed and the status is published.",
+            "Open /blog in the private window and open the post.",
+            "Delete the post and confirm it disappears from both the admin list and /blog.",
+        ],
+        inputs: { title: "QA Blog create-edit-publish" },
+        expectedBehaviour: "Draft and published are genuinely different: a draft is invisible publicly. The slug is derived from the title at creation and is then immutable even though the title stays editable — that is the deliberate convention across this codebase, because recomputing it would break existing links.",
+        expectedUiState: "The draft does not appear on /blog. After publishing it does, with the edited body. The editor's other fields are unchanged after the edit. The URL keeps its original slug after any title change.",
+        endResult: "The post is deleted from both surfaces. A draft visible publicly is the most serious failure here.",
+    },
+    "checklist-admin-blog-faqs-blog-media-step-save": {
+        roles: ["admin", "guest"],
+        startPage: "/admin/blog",
+        steps: [
+            "Sign in as admin@letitrip.in / TempPass123!.",
+            "Open the admin blog editor for an existing published post and note its current cover image.",
+            "Upload public/test-media/sample-image.png as the cover image.",
+            "Insert a second image into the body content itself.",
+            "Save and RELOAD the editor, reading both the cover and the body.",
+            "Open the post on /blog in a private window and read both images.",
+            "Restore the original cover image and remove the inserted body image.",
+        ],
+        inputs: { coverImage: "public/test-media/sample-image.png" },
+        expectedBehaviour: "The cover image and inline body images both persist and both render publicly. A blog post has NO gallery field — extra images live inside the body HTML — so a case looking for a separate image array is looking for something the document has never had. Newly uploaded media must also be finalised on update, not only on create, or the file is orphaned in temporary storage.",
+        expectedUiState: "After the reload the cover and the inline image are both present in the editor, and both render on the public post. An image that previews during editing and is missing after the reload was never finalised.",
+        endResult: "The post is restored to its original media. Record any image that vanished on reload — that is the orphaned-upload failure.",
+    },
+    "checklist-admin-blog-faqs-faq-create-edit-category": {
+        roles: ["admin", "guest"],
+        startPage: "/admin/faqs",
+        steps: [
+            "Sign in as admin@letitrip.in / TempPass123!.",
+            "Open the admin FAQs list and create one: question 'QA FAQ create-edit-category?', answer 'Created by the tester checklist.', category Shipping.",
+            "Save, RELOAD, and read the answer as it is displayed.",
+            "Open /faqs in a private window and find the question under Shipping.",
+            "Return to the admin editor, change ONLY the answer to 'Edited by the tester checklist.', and save.",
+            "RELOAD the editor and read the answer, then open /faqs again and read it there.",
+            "Change the category to Payments, save, reload, and check it moved category on /faqs.",
+            "Delete the FAQ and confirm it disappears from both surfaces.",
+        ],
+        inputs: {
+            question: "QA FAQ create-edit-category?",
+            answerBefore: "Created by the tester checklist.",
+            answerAfter: "Edited by the tester checklist.",
+            categoryBefore: "Shipping",
+            categoryAfter: "Payments",
+        },
+        expectedBehaviour: "The EDIT is the case. Creating a FAQ wraps the flat answer into an object and writes the slug to a nested path; an update that spreads the submitted body straight into storage writes a bare string into the field every reader expects to be an object. The admin form may still render it — the public page is where the wrong shape surfaces.",
+        expectedUiState: "After the edit and reload the answer reads as prose in BOTH the admin editor and on /faqs. What must not appear is raw markup, an object rendered as text, or a blank answer on the public page while the admin form looks fine.",
+        endResult: "The FAQ is deleted from both surfaces. Checking /faqs after the edit — not only the admin form — is what makes this case worth running.",
+    },
+};

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

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

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

@@ -0,0 +1,177 @@
+/*
+ * WHY: Authored six-part procedures for the admin/bulk-actions page.
+ * WHAT: 10 case(s), keyed by full checklist id.
+ *
+ * A bulk action multiplies both the work and the mistake. Two failure shapes recur
+ * and both read as success: an action whose handler does nothing but clear the
+ * selection, and a destructive action with no confirmation, which executes
+ * immediately on a selection the admin may have built by accident.
+ *
+ * The bar itself belongs to a measured bottom tier shared with every other fixed
+ * bar, and it must hide by COLLAPSING rather than by sliding away — a bar that
+ * 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.
+ *
+ * @tag domain:tester
+ * @tag layer:seed
+ * @tag pattern:none
+ * @tag access:server-only
+ * @tag consumers:seed-data/authored/index.ts
+ * @tag sideEffects:none
+ */
+const SIGN_IN_ADMIN = "Sign in as admin@letitrip.in / TempPass123!.";
+export const authored = {
+    "checklist-admin-bulk-actions-select-all-count-matches-page": {
+        roles: ["admin"],
+        startPage: "/admin/products",
+        steps: [
+            SIGN_IN_ADMIN,
+            "Open /admin/products and count the rows on the page.",
+            "Use 'Select all'.",
+            "Read the count reported on the bulk bar.",
+            "Compare it against the number of visible rows.",
+            "Page forward and read whether the selection or its count followed.",
+        ],
+        expectedBehaviour: "Select-all covers the rows on screen and says how many. A count larger than what is visible means it is selecting rows the admin cannot see — and the next destructive action then affects them.",
+        expectedUiState: "The reported count equals the visible row count. A larger number is the finding, with both figures.",
+        endResult: "Clear the selection.",
+    },
+    "checklist-admin-bulk-actions-bulk-bar-appears-on-selection": {
+        roles: ["admin"],
+        startPage: "/admin/products",
+        steps: [
+            SIGN_IN_ADMIN,
+            "Open /admin/products with nothing selected and note where the page's content ends at the bottom.",
+            "Select one row and read whether a bulk bar appears.",
+            "Deselect it and read whether the bar goes.",
+            "With the bar gone, check no empty strip, hairline or shadow is left where it was.",
+            "Scroll to the very bottom with nothing selected and check no reserved gap remains.",
+        ],
+        expectedBehaviour: "The bar appears on the first selection and collapses to zero height on the last deselection. Hiding it by sliding it out of view leaves its height behind, so the shared bottom tier over-reports on every page with no bar — and the tier's background and border must sit INSIDE the collapsing box, or they paint a hairline across the screen at zero height.",
+        expectedUiState: "The bar appears and disappears with the selection, leaving no strip, hairline, shadow or reserved gap behind.",
+        endResult: "Nothing is selected.",
+    },
+    "checklist-admin-bulk-actions-bulk-destructive-confirms": {
+        roles: ["admin"],
+        startPage: "/admin/products",
+        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.",
+        ],
+        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.",
+    },
+    "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.",
+        ],
+        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.",
+    },
+    "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.",
+        ],
+        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.",
+        expectedUiState: "The failed rows are identified by title or id, with a reason. A bare failure count is the finding.",
+        endResult: "Restore whatever succeeded.",
+    },
+    "checklist-admin-bulk-actions-bulk-selection-clears-after-run": {
+        roles: ["admin"],
+        startPage: "/admin/products",
+        steps: [
+            SIGN_IN_ADMIN,
+            "Open /admin/products and select two rows.",
+            "Run a bulk action and let it complete.",
+            "Read whether the rows are still selected.",
+            "Read whether the bulk bar is still shown.",
+            "Read whether the list reflects the change without a reload.",
+            "Reload and check the change held.",
+        ],
+        expectedBehaviour: "The selection clears when the action completes and the list reflects the result. A selection left in place invites the admin to run a second action on rows that have already been acted on, and on a destructive action that is unrecoverable.",
+        expectedUiState: "No rows selected, no bulk bar, the list updated in place, and the change still there after a reload.",
+        endResult: "Restore whatever the action changed.",
+    },
+    "checklist-admin-bulk-actions-bulk-selection-survives-filter-change": {
+        roles: ["admin"],
+        startPage: "/admin/products",
+        steps: [
+            SIGN_IN_ADMIN,
+            "Open /admin/products and select three rows.",
+            "Change a filter so that at least one selected row is no longer shown.",
+            "Read the bulk bar's count.",
+            "Read whether the selection was cleared or kept.",
+            "If it was kept, run a harmless action and check which rows it affected.",
+        ],
+        expectedBehaviour: "Either the selection clears visibly, or it stays and the count keeps saying honestly how many rows it covers. What must not happen is an action running against rows the admin can no longer see — the confirmation names a count they cannot reconcile with the screen.",
+        expectedUiState: "The count matches what the bar claims, and any action affects exactly those rows. A silent carry-over of hidden rows into a destructive action is the finding.",
+        endResult: "Clear the selection.",
+    },
+    "checklist-admin-bulk-actions-bulk-actions-from-registry": {
+        roles: ["admin", "seller"],
+        startPage: "/admin/products",
+        steps: [
+            SIGN_IN_ADMIN,
+            "Open /admin/products, select a row, and write down every bulk action offered with its exact label.",
+            "Sign in as tyson@beybladearena.in / TempPass123!.",
+            "Open /store/products, select a row, and write down the same.",
+            "Compare the labels of any action that appears in both lists.",
+            "Check no label differs only in wording.",
+        ],
+        expectedBehaviour: "Actions come from a shared registry, so an action offered in two places carries one label. Two hand-written copies drift in wording first and in behaviour second, and a differently-worded destructive action is one an admin will hesitate over or misread.",
+        expectedUiState: "Any action present on both surfaces reads identically. A wording difference is a finding, quoting both.",
+        endResult: "Clear both selections.",
+    },
+    "checklist-admin-bulk-actions-bulk-no-dead-actions": {
+        roles: ["admin"],
+        startPage: "/admin/offers",
+        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.",
+        ],
+        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.",
+    },
+    "checklist-admin-bulk-actions-bulk-users-actions": {
+        roles: ["admin"],
+        startPage: "/admin/users",
+        steps: [
+            SIGN_IN_ADMIN,
+            "Open /admin/users and select two accounts that no other checklist page signs in as.",
+            "Run a reversible bulk action on them.",
+            "Read the result message.",
+            "Open each account and check the change applied to both.",
+            "Open /admin/audit-log and check both changes are recorded with the acting admin.",
+            "Reverse the change on both accounts.",
+        ],
+        expectedBehaviour: "A bulk action over accounts applies to every selected account and each change is audited individually. One log entry for a batch loses which accounts were affected, which is the only thing the log is there to answer.",
+        expectedUiState: "Both accounts changed, and both appear separately in the audit log with the acting admin. One entry for the batch, or a missing entry, are both findings.",
+        endResult: "Both accounts are restored.",
+    },
+};

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

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

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

@@ -0,0 +1,97 @@
+/*
+ * WHY: Authored six-part procedures for the admin/bundles 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.
+ *
+ * 🛑 A BUNDLE IS A CATEGORY ROW, not a listing type, and its member list is
+ * MIRRORED onto the bundle for index-friendly reads. Every public reader consults
+ * 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.
+ *
+ * @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-admin-bundles-bundle-create": {
+        roles: ["admin", "guest"],
+        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.",
+            "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.",
+        ],
+        inputs: {
+            name: "QA Bundle admin-create",
+            member1: "product-beyblade-burst-valkyrie",
+            member2: "product-beyblade-x-wizard-arrow",
+            bundlePrice: 1500,
+            memberTotal: 1898,
+        },
+        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.",
+    },
+    "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.",
+        ],
+        inputs: { member: "product-beyblade-x-wizard-arrow" },
+        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.",
+    },
+    "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.",
+        ],
+        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.",
+        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": {
+        roles: ["admin", "guest"],
+        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.",
+            "Delete the bundle.",
+        ],
+        inputs: { name: "QA Bundle brand-picker", brand: "Beyblade" },
+        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.",
+    },
+};

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

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