@mohasinac/appkit 4.58.0 → 4.59.0

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

@@ -1,131 +0,0 @@
-/*
- * 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.
- *
- * VERIFIED FIXED 2026-09-29 before asserting anything about it: the PATCH at
- * `src/app/api/admin/faqs/[id]/route.ts:53-57` destructures `answer` and `slug`
- * out and applies the same transform as POST. So that half of the FAQ case
- * should PASS, and a pass is the expected result rather than a surprise. It is
- * kept because the failure is invisible in the admin form and only shows on the
- * public page — exactly the kind that returns.
- *
- * 🛑 THE FAQ CATEGORY PICKER OFFERS VALUES `FAQCategory` DOES NOT HAVE.
- *
- * `AdminFaqEditorView`'s CATEGORY_OPTIONS is shipping / returns / payments /
- * auctions / pre-orders / general. The real union is orders_payment /
- * shipping_delivery / returns_refunds / product_information / account_security /
- * technical_support / general / scam_awareness. **Only `general` overlaps.**
- * The API types category as a bare `z.string().min(1)` and then casts
- * `as FAQCategory`, with a comment acknowledging it, so the wrong value is
- * persisted unvalidated — and `FAQPageContent` counts a FAQ only
- * `if (faq.category in categoryCounts)`, so an admin-created FAQ is in no
- * sidebar bucket and no category filter ever returns it. All 63 seeded FAQs use
- * the real values, which is why this has never shown up. Root Cause #33/#34's
- * shape. Recorded in OUTOFSCOPE; the case below now expects it.
- *
- * (CLAUDE.md's Seed Data Reference lists FAQ categories as
- * "Shipping/Returns/Payments/Auctions/Pre-orders" — it is describing this
- * picker, not the schema, and is wrong about the data.)
- *
- * 🛑 THE BLOG SLUG IS EDITABLE, and this file used to claim the opposite.
- * `updateBlogPostSchema` accepts `slug` and the editor's Content section has a
- * 'Slug' field. What is true is narrower: the slug is derived from the title at
- * creation and is never RECOMPUTED when the title changes. Those are different
- * claims and only the second one holds.
- *
- * Blog vocabulary, all closed enums: category is news | tips | guides | updates
- * | community; status is draft | published | archived. Editor sections are
- * Content, Media, 'SEO & Tags' and Publish.
- *
- * @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 /admin/blog/new and create a post titled 'QA Blog create-edit-publish' with an excerpt, category Guides, tags 'qa' and 'checklist', and body content in the rich-text editor. Write down the Slug the Content section shows.",
-            "Save it as a DRAFT and read the status shown in the Publish section.",
-            "Sign out and open /blog, confirming the draft is NOT listed and its slug URL does not render it.",
-            "Sign back in, open the post from /admin/blog, change ONLY the body, set status to Published, save, and RELOAD the editor.",
-            "Read every field to confirm only the body changed and the status is published.",
-            "Change ONLY the Title to 'QA Blog renamed', save, RELOAD, and read the Slug field: it must still be the one written down in step 2.",
-            "Sign out, open /blog and open the post at that original slug.",
-            "Sign back in, delete the post, and confirm it disappears from /admin/blog and from /blog.",
-        ],
-        inputs: {
-            title: "QA Blog create-edit-publish",
-            titleAfter: "QA Blog renamed",
-            category: "Guides",
-            tags: "qa, checklist",
-        },
-        expectedBehaviour: "Draft and published are genuinely different: a draft is invisible publicly. The slug is derived from the title at creation and is never RECOMPUTED when the title changes, because recomputing it would break every existing link — it stays directly editable in the Slug field, which is the deliberate escape hatch rather than an oversight.",
-        expectedUiState: "The draft appears nowhere on /blog and its URL does not render it. After publishing it does, carrying the edited body. After the title change every other field — including Slug — is untouched, and the post is still reachable at the original slug.",
-        expectedData: { statusAfterPublish: "published", slugUnchangedAfterRename: true },
-        endResult: "The post is deleted from /admin/blog and /blog. A draft visible publicly is the most serious failure here; a slug that silently followed the title is the second.",
-    },
-    "checklist-admin-blog-faqs-blog-media-step-save": {
-        roles: ["admin", "guest"],
-        startPage: "/admin/blog",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/blog, open blog-spot-genuine-takara-tomy-beyblade for editing, and write down its current Cover Image and YouTube Video ID from the Media section (the id may be empty — no seeded post sets one).",
-            "Upload /test-media/sample-image.png as the Cover Image.",
-            "Set the YouTube Video ID to dQw4w9WgXcQ.",
-            "In the Content section's rich-text editor, insert /test-media/sample-image-2.png into the body itself.",
-            "Save, then RELOAD the editor and read the cover, the YouTube id and the body image.",
-            "Sign out, open the post on /blog, and read whether the cover, the video embed and the inline image all render.",
-            "Sign back in and restore the Cover Image and YouTube Video ID written down in step 1, and remove the inserted body image.",
-        ],
-        inputs: {
-            coverImage: "/test-media/sample-image.png",
-            bodyImage: "/test-media/sample-image-2.png",
-            youtubeId: "dQw4w9WgXcQ",
-            post: "blog-spot-genuine-takara-tomy-beyblade",
-        },
-        expectedBehaviour: "The cover image, the YouTube id and inline body images all persist and all render publicly. Extra images belong INSIDE the body HTML: `BlogPostDocument` does declare `contentImages` and `additionalImages` arrays and the PATCH accepts them, but no renderer anywhere reads either one, no mounted editor exposes them (only `BlogPostForm`, which has no consumer), and no seeded post sets them — so a separate image array is not a path to anything visible. 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, the YouTube id and the inline image are all present in the editor, and all three render on the public post. An image that previews while editing and is gone after the reload was never finalised — that is the orphaned-upload failure and is the thing this case is for.",
-        expectedData: { coverPersisted: true, youtubeIdPersisted: true, bodyImagePersisted: true },
-        endResult: "The post carries its original cover and YouTube id again and the inserted body image is gone. Record any image that vanished on reload, and whether it vanished in the editor, on the public post, or both.",
-    },
-    "checklist-admin-blog-faqs-faq-create-edit-category": {
-        roles: ["admin", "guest"],
-        startPage: "/admin/faqs",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/faqs/new and create one: question 'QA FAQ create-edit-category?', answer 'Created by the tester checklist.', and pick Shipping from the Category select.",
-            "Save, RELOAD the editor, and read the answer as it is displayed.",
-            "Sign out, open /faqs, and look for the question — first under the category sidebar, then under All.",
-            "Sign back in, 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 whether it moved category on /faqs.",
-            "Delete the FAQ and confirm it disappears from /admin/faqs and /faqs.",
-        ],
-        inputs: {
-            question: "QA FAQ create-edit-category?",
-            answerBefore: "Created by the tester checklist.",
-            answerAfter: "Edited by the tester checklist.",
-            categoryBefore: "Shipping",
-            categoryAfter: "Payments",
-        },
-        expectedBehaviour: "Two independent things, and they have different answers today. (1) The ANSWER round-trip: creating a FAQ wraps the flat answer into a text-plus-format object, and the update must apply the same transform rather than spreading a bare string into a field every reader expects to be an object. (2) The CATEGORY: whatever the picker offers must be a value the rest of the product can represent, or the FAQ lands in a category nothing renders.",
-        expectedUiState: "The answer half should PASS — verified in source, the PATCH applies the same transform as create, so the answer reads as prose in both the admin editor and on /faqs, with no raw markup and no blank public answer.\n\n🛑 EXPECT THE CATEGORY HALF TO FAIL, AND RECORD IT AS A FAILURE. The picker's 'Shipping' writes the string 'shipping', and FAQCategory has no such value — it has 'shipping_delivery'. The API types category as a bare z.string() and casts it, so it is stored unvalidated, and /faqs counts a FAQ only if its category is a known one. So expect the question to be absent from every category in the sidebar while still appearing under All, and the move to Payments to change nothing visible. Say which categories you tried.",
-        expectedData: { answerRendersAsProse: true, appearsUnderAnyCategory: false },
-        endResult: "The FAQ is deleted from both surfaces. Keep the two halves apart in the comment: one mechanism works and one writes a value no reader understands.",
-    },
-};

package/dist/features/tester/seed-data/authored/admin__bug-hunter-rewards.d.ts

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

package/dist/features/tester/seed-data/authored/admin__bug-hunter-rewards.js

@@ -1,143 +0,0 @@
-/*
- * WHY: Authored six-part procedures for the admin/bug-hunter-rewards page.
- * WHAT: 4 case(s), keyed by full checklist id.
- *
- * 🛑 THE LAST UNAUTHORED PAGE IN THE CATALOGUE. It was the sole remaining entry in
- * R5's `UNAUTHORED_PAGES` ratchet (audit-tester-plugin-wiring.mjs), whose own
- * header says the ratchet exists to be emptied. With this file it is.
- *
- * This page is awkward to test for a reason worth stating: confirming a bug
- * DISABLES the case it was reported against, and credit is awarded to exactly one
- * tester. Both effects are visible to every other tester, and the credit cannot be
- * silently reassigned. So the cases below deliberately operate on the seeded demo
- * fixture pair (v1 disabled + credited, v2 active) rather than on a live report:
- *
- *   checklist-admin-bug-hunter-rewards-demo-fixture      v1, isActive:false,
- *                                                        bugConfirmed, credited to
- *                                                        "Mock User 3"
- *   checklist-admin-bug-hunter-rewards-demo-fixture-v2   v2, isActive:true
- *
- * That pair exists precisely so this flow can be read without spending a real
- * tester's report on it. Where a case must perform the irreversible half —
- * confirming a bug — it does so against v2, which is the fixture reopened for
- * exactly that purpose.
- *
- * 🛑 THE CREDIT IS "Mock User 3", NOT "Mock User 18" (fixed 2026-09-29). The seed
- * sets `bugHunterId: "user-yugi-muto"` / `bugHunterName: "Mock User 3"`, and the
- * responses seed uses the same pair. The idempotency case asserted
- * byte-identity against "Mock User 18", so it would have failed on a correct
- * system — the worst shape a case can have, because the failure looks like a
- * product defect.
- *
- * 🛑 v1 CANNOT BE REOPENED AGAIN. It already carries `supersededByItemId`, and
- * the route returns 409 "This case has already been reopened" on exactly that.
- * The reopen case pointed at v1 and expected a new version to appear; it now
- * asserts the 409 on v1 and performs the real reopen on **v2**, which the
- * confirm-bug case above it has just made bug-confirmed. That is a deliberate
- * dependency between two cases in one batch, which is why they run in order.
- *
- * Both response rows ARE seeded (`tester-responses-seed-data.ts`), the v2 one
- * deliberately left `status: "new"` and unconfirmed so confirm-bug has
- * something to do. So no case here has to file a report first.
- *
- * @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-bug-hunter-rewards-confirm-bug": {
-        roles: ["admin"],
-        startPage: "/admin/tester-feedback",
-        steps: [
-            SIGN_IN_ADMIN,
-            "Open /admin/tester-feedback and select the Main Issues tab.",
-            "Find the row for the case 'Demo fixture — reported bug, already confirmed and reopened (v2, active)' and read the tester name on it.",
-            "Click 'Mark as Bug' on that row.",
-            "Read the confirmation dialog before accepting: it should be titled 'Confirm this bug?' and say the credit is awarded and the case disabled for other testers. Then accept it.",
-            "Read the badge that appears on the row afterwards.",
-            "Open /admin/tester-checklist, set the Status filter to 'All', and read the Status of that same case.",
-        ],
-        inputs: {
-            caseId: "checklist-admin-bug-hunter-rewards-demo-fixture-v2",
-            dialogTitle: "Confirm this bug?",
-            creditedTo: "Mock User 3",
-        },
-        expectedBehaviour: "Confirming a bug does two things at once and both are irreversible from this screen: it credits exactly one tester, and it takes the case out of circulation so no second tester can answer it. A confirmation dialog must stand in front of it — an accidental click here spends a credit on the wrong person and silently shrinks the catalogue.",
-        expectedUiState: "A dialog titled 'Confirm this bug?' appears BEFORE anything commits. After accepting, the row shows a confirmed-bug badge naming the crediting tester — the same name that was on the row beforehand, 'Mock User 3', not a different one. In the catalog the case's Status reads 'Bug Confirmed' rather than 'Active'.",
-        expectedData: { creditedTesterUnchanged: true },
-        endResult: "Survives a reload: the badge and the credited name are still there, and the case is still out of the Active view. 🛑 Leave v2 confirmed — the reopen case below needs a bug-confirmed case that has NOT already been superseded, and v2 is the only one a fresh seed can provide.",
-    },
-    "checklist-admin-bug-hunter-rewards-confirm-bug-idempotent": {
-        roles: ["admin"],
-        startPage: "/admin/tester-feedback",
-        steps: [
-            SIGN_IN_ADMIN,
-            "Open /admin/tester-feedback and select the All Submissions tab.",
-            "Find a row whose case is ALREADY bug-confirmed — the demo fixture 'reported bug, already confirmed and reopened (v1, disabled)' is credited to Mock User 3.",
-            "Read the tester name currently credited on it.",
-            "Attempt 'Mark as Bug' on that row.",
-            "Read whatever the screen says in response.",
-            "Read the credited tester name again and compare it against the one noted earlier.",
-        ],
-        inputs: {
-            caseId: "checklist-admin-bug-hunter-rewards-demo-fixture",
-            creditedTo: "Mock User 3",
-            expectedRefusal: "This case has already been confirmed as a bug",
-        },
-        expectedBehaviour: "A second confirmation on an already-confirmed case is REFUSED, and refused loudly. The failure mode this guards is silent re-crediting: two testers report the same case, an admin confirms twice, and the second confirmation quietly moves the credit off the person who actually found it. Nothing about that is visible unless the screen says so.",
-        expectedUiState: "Either the action is absent/disabled on an already-confirmed row, or it is refused — the server answers 409 'This case has already been confirmed as a bug'. What must NOT happen is a success message. The credited name is byte-identical to the one read at the start.",
-        expectedData: { creditedTo: "Mock User 3" },
-        endResult: "Reload the page: the credit still reads Mock User 3, and the case has not gained a second confirmation.",
-    },
-    "checklist-admin-bug-hunter-rewards-reopen-case": {
-        roles: ["admin"],
-        startPage: "/admin/tester-checklist",
-        steps: [
-            SIGN_IN_ADMIN,
-            "Open /admin/tester-checklist and set 'Bug status' to 'Bug Confirmed'.",
-            "Find 'Demo fixture — reported bug, already confirmed and reopened (v1, disabled)' and read its Status and its bug-hunter credit.",
-            "Use its 'Reopen as New Test Case' row action and read what happens — v1 has already been superseded once, so expect a refusal rather than a new case.",
-            "Now find the v2 fixture, which the confirm-bug case above has just made bug-confirmed, and use 'Reopen as New Test Case' on it.",
-            "Read the new case that appears — its label, its Status, its version, and whether it carries any bug-hunter credit.",
-            "Go back to the v1 and v2 cases and read their Status and credit again.",
-            "Open /tester and search for the new case to confirm it is answerable.",
-        ],
-        inputs: {
-            v1Id: "checklist-admin-bug-hunter-rewards-demo-fixture",
-            v2Id: "checklist-admin-bug-hunter-rewards-demo-fixture-v2",
-            newIdPattern: "{v2Id}-v3",
-            v1Refusal: "This case has already been reopened",
-        },
-        expectedBehaviour: "Reopening creates a NEW version rather than resurrecting the old one, and a case can only be reopened ONCE — a second reopen would fork the chain into two live retests of the same finding. The original must keep both its disabled state and its bug-hunter credit: that credit records who found the defect, and a retest of the same behaviour does not undo the finding. Mutating the old row in place would erase the history the whole feature exists to keep.",
-        expectedUiState: "v1 refuses the reopen — 409 'This case has already been reopened' — and is unchanged by the attempt. v2 reopens into a new row whose id ends '-v3' and whose version reads 3, Active and answerable from /tester, carrying NO bug-hunter credit of its own. Both older rows stay disabled and stay credited. A new case that inherited the credit, or an old row that lost it, is the failure.",
-        expectedData: {
-            originalStaysDisabled: true,
-            originalKeepsCredit: true,
-            newVersion: 3,
-            newCaseHasCredit: false,
-        },
-        endResult: "Survives a reload: v1 and v2 disabled with their credits, the reopened v3 active and answerable.",
-    },
-    "checklist-admin-bug-hunter-rewards-catalog-default-active-filter": {
-        roles: ["admin"],
-        startPage: "/admin/tester-checklist",
-        steps: [
-            SIGN_IN_ADMIN,
-            "Open /admin/tester-checklist without touching any filter and read the total count shown.",
-            "Search for 'Demo fixture' and write down every matching row with its Status.",
-            "Switch the Status filter to 'All' and read the total count and the matching rows again.",
-            "Switch the Status filter to 'Inactive' and read which of the demo fixtures appear.",
-            "Set Status back to its default and set 'Bug status' to 'Bug Confirmed'.",
-            "Read which rows appear under that filter, and confirm every one of them was absent from the default view.",
-        ],
-        inputs: { search: "Demo fixture" },
-        expectedBehaviour: "The default view is the answerable catalogue, not everything ever written. A bug-confirmed case is deliberately out of circulation, so showing it by default would invite an admin to treat a closed finding as open work. Switching the filter must reveal it — hidden is not the same as gone.",
-        expectedUiState: "Every bug-confirmed row is absent from the default view and present under Status 'All', under 'Inactive', and under Bug status 'Bug Confirmed'. The totals move in the direction each filter implies. v1 is bug-confirmed on any fresh seed, so it is the row to anchor on.\n\n🛑 Do NOT assert an absolute count of demo fixtures. The three cases above this one deliberately confirm v2 and reopen it as v3, so how many demo rows exist depends on whether they ran. The assertion is the FILTER SEMANTICS — hidden is not gone — not the arithmetic. If v2 and v3 exist, they must obey the same rule, which makes the case stronger rather than fragile.",
-        expectedData: { defaultViewHidesBugConfirmed: true },
-        endResult: "Read-only — no case is modified.",
-    },
-};

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

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

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

@@ -1,207 +0,0 @@
-/*
- * 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.
- *
- * 🛑 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
- * @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/orders",
-        steps: [
-            SIGN_IN_ADMIN,
-            "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.",
-        ],
-        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 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.",
-        ],
-        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/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.",
-        ],
-        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.",
-    },
-    "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 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.",
-        ],
-        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"],
-        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

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