@mohasinac/appkit 4.42.1 → 4.42.3

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

@@ -14,6 +14,33 @@
  * was unbanned a moment ago — the fix is to re-read on navigation, not to widen
  * the refresh interval.
  *
+ * 🛑 A SOFT BAN DOES NOT BLOCK SIGN-IN (corrected 2026-09-29). Three cases and
+ * one catalogue label said it did. It does not, and the code is unambiguous:
+ *
+ *   soft ban   POST /api/admin/users/{uid}/soft-ban appends to `user.softBans[]`
+ *              as `{ action, reason, bannedBy, bannedAt, expiresAt }`, where
+ *              `action` is one of EIGHT: write_reviews, write_blog_comments,
+ *              join_events, place_bids, create_listings, send_messages,
+ *              create_support_tickets, report_scammers. It is a PER-ACTION
+ *              restriction. Sign-in is untouched.
+ *   lift       DELETE /api/admin/users/{uid}/soft-ban/{action} — one action at a
+ *              time. `/unban` does NOT clear softBans.
+ *   hard ban   POST …/hard-ban sets `disabled: true` on the Auth record and
+ *              enqueues the 8-stage `hardBanCascade` job. `/api/auth/login`
+ *              refuses on `userRecord.disabled` alone — so THIS is the ban that
+ *              blocks sign-in.
+ *   unban      POST …/unban sets `disabled: false` on Auth and the user doc and
+ *              clears the hard-ban fields only.
+ *
+ * So the sign-in case now exercises a HARD ban for the sign-in half and a soft
+ * ban for the restriction half, and says plainly that a soft-banned account
+ * signing in normally is CORRECT — otherwise the first tester to run it reports
+ * a defect that is really the case being wrong.
+ *
+ * `reason` is `z.string().min(1)`, so a ONE-CHARACTER reason is accepted. The
+ * requires-reason case hedged on "if a minimum length applies"; it now states
+ * the contract so a one-character reason being accepted is not written up.
+ *
  * @tag domain:tester
  * @tag layer:seed
  * @tag pattern:none
@@ -29,49 +56,58 @@ export const authored = {
         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.",
+            "Soft-ban it from place_bids with the reason 'QA ban probe — checklist case, will be lifted.'",
+            "Sign out and sign in as rohit.collect@gmail.com / TempPass123!. This must SUCCEED — a soft ban restricts one action, it does not block sign-in.",
+            "Open any live auction and try to place a bid. Read the refusal and whether it quotes the reason the admin typed.",
+            "Sign back in as the admin and lift that soft ban.",
+            "Now HARD-ban the same account with the reason 'QA sign-in block probe — checklist case, will be lifted.'",
+            "Sign out and try to sign in as rohit.collect@gmail.com / TempPass123!. Read exactly what is shown.",
+            "Sign back in as the admin and unban the account, then confirm it signs in again.",
         ],
-        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.",
+        inputs: {
+            reason: "QA ban probe — checklist case, will be lifted.",
+            softBanAction: "place_bids",
+            hardBanReason: "QA sign-in block probe — checklist case, will be lifted.",
+        },
+        expectedBehaviour: "The two bans do different things and both must say why. A soft ban blocks ONE action and leaves sign-in alone; a hard ban disables the account outright and sign-in is refused. 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 soft-banned account SIGNS IN NORMALLY — that is correct and is not a finding — and is refused only at the bid, with the admin's reason quoted. The hard-banned account is refused at sign-in with a message naming the disabled account, not an invalid-credentials error. Record the exact wording of both refusals.",
+        expectedData: { softBannedCanSignIn: true, hardBannedCanSignIn: false },
+        endResult: "The soft ban is lifted, the hard ban is lifted, and the account signs in and can bid again. 🛑 Both must be lifted separately — /unban clears the hard-ban fields only and leaves softBans untouched.",
     },
     "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.",
+            "Open /admin/users and start a soft ban on 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.",
+            "Read what happens and WHERE the error appears — on the field, or as a banner.",
+            "Type a single character as the reason and submit.",
+            "Read whether that is accepted — the schema is a minimum of one character, so it should be.",
+            "If it was accepted, lift that soft ban immediately.",
         ],
+        inputs: { minimumReasonLength: 1 },
         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.",
+        expectedUiState: "The empty submission is refused with an inline error ON THE REASON FIELD, not a banner. A one-character reason IS accepted — the contract is `z.string().min(1)` — so do not record that as a finding; record instead whether a reason that short is useful to the person who reads it. What would be a finding is an empty reason being accepted, or the refusal appearing only as a banner with nothing marked on the field.",
+        expectedData: { emptyReasonRejected: true, oneCharReasonAccepted: true },
+        endResult: "Nobody is left banned — if the one-character ban applied, it is lifted.",
     },
     "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.",
+            "In a second browser, sign in as rohit.collect@gmail.com / TempPass123! and leave that session open on a signed-in page.",
+            "As the admin, soft-ban that account from place_bids with the reason 'QA unban probe — checklist case.'",
+            "In the second browser, WITHOUT signing out or reloading, open a live auction and confirm bidding is refused.",
+            "As the admin, lift that soft ban.",
+            "In the second browser, WITHOUT signing out or reloading, navigate to another page and try to bid again.",
+            "Read whether access is restored, and note how long it took if it was not immediate.",
         ],
-        inputs: { reason: "QA unban probe — checklist case." },
+        inputs: { reason: "QA unban probe — checklist case.", softBanAction: "place_bids" },
         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.",
+        expectedUiState: "Bidding 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 — that is the cached-session-snapshot failure this case exists for, and it reads to a user as the unban not having worked.",
+        endResult: "The soft ban is lifted and the account can bid again. Note this case uses a SOFT ban deliberately: a hard ban ends the session outright, so there would be no live session left to observe the restoration on.",
     },
     "checklist-admin-bans-and-trust-hard-ban-cascade-runs": {
         roles: ["admin"],
@@ -79,16 +115,19 @@ export const authored = {
         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.",
+            "Read what the interface says IMMEDIATELY after submitting — the route returns a job id and a token, so it should report started work rather than a finished cascade.",
             "Wait for the completion signal and read what it reports.",
-            "Open the account and read its state.",
-            "Lift the ban afterwards.",
+            "Open the account and read its state — it should now be disabled.",
+            "Unban the account and confirm it is enabled again.",
         ],
-        inputs: { reason: "QA hard-ban cascade probe — checklist case." },
+        inputs: {
+            reason: "QA hard-ban cascade probe — checklist case.",
+            jobType: "hardBanCascade",
+            cascadeStages: 8,
+        },
         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.",
+        expectedUiState: "The submit reports started or queued work, a completion signal follows separately, and only then does the account's state reflect the finished cascade. An immediate unqualified 'user banned' with no later signal is the finding — the eight-stage cascade runs in a background job and the request cannot know its outcome.",
+        endResult: "The ban is lifted and the account is enabled again. A hard ban left in place outlives every reseed — users is PRESERVE tier — and silently breaks whichever other page signs in as this persona.",
     },
     "checklist-admin-bans-and-trust-hard-ban-recorded-in-audit-log": {
         roles: ["admin"],

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

@@ -9,8 +9,42 @@
  * 🛑 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.
+ * 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
@@ -25,48 +59,62 @@ export const authored = {
         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.",
+            "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.",
-            "Open /blog in the private window and open the post.",
-            "Delete the post and confirm it disappears from both the admin list and /blog.",
+            "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" },
-        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.",
+        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 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.",
+            "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: "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.",
+        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 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.",
+            "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 it moved category on /faqs.",
-            "Delete the FAQ and confirm it disappears from both surfaces.",
+            "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?",
@@ -75,8 +123,9 @@ export const authored = {
             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.",
+        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.js

@@ -14,7 +14,7 @@
  *
  *   checklist-admin-bug-hunter-rewards-demo-fixture      v1, isActive:false,
  *                                                        bugConfirmed, credited to
- *                                                        "Mock User 18"
+ *                                                        "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
@@ -22,6 +22,24 @@
  * 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
@@ -39,15 +57,19 @@ export const authored = {
             "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 in full before accepting, then accept it.",
+            "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" },
+        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 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, not a different one. In the catalog the case's Status reads as bug-confirmed rather than Active.",
+        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.",
+        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"],
@@ -55,35 +77,50 @@ export const authored = {
         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 18.",
+            "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 18" },
+        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 with a message naming the existing credit. 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 18" },
-        endResult: "Reload the page: the credit still reads Mock User 18, and the case has not gained a second confirmation.",
+        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 the Status filter to 'Inactive' (or set Bug status to 'Bug Confirmed').",
+            "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.",
-            "Read the new case that appears — its label, its Status, and its version.",
-            "Go back to the v1 case and read its Status and credit again.",
-            "Open the Tester Hub as the tester and search for the new case.",
+            "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" },
-        expectedBehaviour: "Reopening creates a NEW version rather than resurrecting the old one. The original must keep both its disabled state and its bug-hunter credit — that credit is a record of who found the defect, and a retest of the same behaviour does not undo the finding. Mutating v1 in place would erase the history the whole feature exists to keep.",
-        expectedUiState: "Two rows exist afterwards: the old one still disabled and still credited, and a new active one answerable from the Tester Hub. The new case does NOT carry the old case's bug-hunter credit.",
-        expectedData: { originalStaysDisabled: true, originalKeepsCredit: true },
-        endResult: "Survives a reload: v1 disabled with its credit, the reopened version active and 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"],
@@ -91,15 +128,15 @@ export const authored = {
         steps: [
             SIGN_IN_ADMIN,
             "Open /admin/tester-checklist without touching any filter and read the total count shown.",
-            "Search for 'Demo fixture — reported bug' and read how many rows match.",
+            "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 two demo fixtures appears.",
+            "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.",
+            "Read which rows appear under that filter, and confirm every one of them was absent from the default view.",
         ],
-        inputs: { search: "Demo fixture — reported bug" },
+        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: "On the default view only the v2 (active) demo fixture matches the search. Under Status 'All' both appear and the total is higher. Under 'Inactive' the v1 disabled one appears. Under Bug status 'Bug Confirmed' the v1 one appears. The counts move in the direction the filter implies.",
+        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.",
     },