@mohasinac/appkit 4.58.0 → 4.60.0

package/dist/features/tester/seed-data/authored/addresses__unban-request.js

@@ -1,77 +0,0 @@
-/*
- * WHY: Authored six-part procedures for the addresses/unban-request page.
- * WHAT: 1 case, 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.
- *
- * @tag domain:tester
- * @tag layer:seed
- * @tag pattern:none
- * @tag access:server-only
- * @tag consumers:seed-data/authored/index.ts
- * @tag sideEffects:none
- */
-/*
- * Verified against the drawer on 2026-09-29, and every assertion the case
- * makes is correct: the trigger reads 'Request Unban' and renders only when
- * the address is banned; the drawer's field is 'Reason for unban request';
- * its submit is 'Submit request' and is DELIBERATELY not disabled on an empty
- * note, with a source comment saying why; and addressUnbanRequestSchema
- * carries a .min(20) whose message is
- *
- *   'Explain what happened — at least 20 characters. This is all the reviewer sees.'
- *
- * So the 20 the case names is real, and so is the error text.
- *
- * 🛑 WHAT IS MISSING IS THE PRECONDITION. This buyer has no addresses at all,
- * and no seeded address is banned, so 'find an address showing a banned state'
- * finds nothing. Worse, there is no UI path to ban one: ban-address is a row
- * action on the Banned Addresses queue, which is fed only by
- * GET /api/admin/addresses?banStatus=..., and its chips are banned,
- * unban_requested and suspicious. The All chip sends no banStatus and the
- * route then returns an empty list — so that queue can only act on rows
- * already in it, and nothing in the product puts a clean address there.
- *
- * The one real producer is hardBanCascade, which bans every address belonging
- * to a hard-banned user. But /unban reverses exactly that via
- * unbanAutoForOwner, so lifting the user's ban clears the address too. The two
- * states this case needs together — an ACTIVE buyer with a BANNED address —
- * cannot be reached from the UI at all.
- *
- * So the case attempts the setup, RECORDS the gap, and runs the real
- * assertions only if a banned address does exist. Recorded in OUTOFSCOPE.
-*/
-export const authored = {
-    "checklist-addresses-unban-request-empty-note-says-why": {
-        roles: ["buyer"],
-        startPage: "/user/addresses",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123! and open the Banned Addresses queue.",
-            "Select the All chip and read how many rows are listed, then try the Banned, Unban Requested and Suspicious chips in turn.",
-            "Record whether ANY route in the product lets an admin ban a single address on an otherwise-active account — if none does, this case cannot be set up, and that is the finding.",
-            "If a banned address belonging to rehan.sheikh@gmail.com does exist, continue. Otherwise stop here and answer no, quoting what each chip returned.",
-            "Sign in as rehan.sheikh@gmail.com / TempPass123! and open /user/addresses.",
-            "Find the banned address and click 'Request Unban'.",
-            "Leave 'Reason for unban request' completely empty and click 'Submit request'. The button must be clickable, not greyed out.",
-            "Read where the message appears.",
-            "Type 'Too short' and click 'Submit request' again.",
-            "Type 'This address was banned in error; it is my registered home address.' and submit.",
-        ],
-        inputs: {
-            shortNote: "Too short",
-            validNote: "This address was banned in error; it is my registered home address.",
-            minimumLength: 20,
-            trigger: "Request Unban",
-            field: "Reason for unban request",
-            submit: "Submit request",
-        },
-        expectedBehaviour: "Submitting with an empty or too-short note fails loudly ON THE FIELD and names the 20-character minimum. The note is the entire case a reviewer reads, so a request without one is not a request — but a greyed-out button with a bare return in its handler tells the user nothing about why, which is what this replaced.",
-        expectedUiState: "The submit button is enabled even with the box empty. Pressing it puts an error on the note field naming the minimum length; the schema message reads 'Explain what happened — at least 20 characters. This is all the reviewer sees.' 'Too short' produces the same error. The full sentence is accepted and a confirmation appears.\n\n🛑 If no banned address exists, answer NO for the precondition rather than null: there is no UI path to ban one, which is a product gap and not a missing test channel.",
-        expectedData: { minimumNoteLength: 20, submitEnabledWhenEmpty: true },
-        endResult: "If the request was submitted, the address reads as unban-requested and carries the full note. A silently disabled button that does nothing when pressed is the failure — the user cannot tell it from a broken page.",
-        needsReview: true,
-        reviewNote: "The assertions are verified correct against the drawer and its schema. What is unsettled is whether an admin should be able to ban a single address on an otherwise-active account at all; today they cannot, so this case has no reachable setup.",
-    },
-};

package/dist/features/tester/seed-data/authored/admin__admin-detail-round-trips.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__admin-detail-round-trips.js

@@ -1,151 +0,0 @@
-/*
- * WHY: Authored six-part procedures for admin/admin-detail-round-trips.
- * WHAT: 7 cases, keyed by full checklist id.
- *
- * 🛑 THERE ARE 33 `[id]` DIRECTORIES UNDER `admin/` AND ALMOST ALL SAT AT ZERO.
- *
- * Every case here is a ROUND TRIP: open, change ONE field, save, RELOAD, then
- * check the fields you did NOT touch. That shape is what catches an editor
- * seeded from the wrong object — a form that opens blank and then saves its own
- * emptiness passes any case that merely asks whether the page loads. It is
- * exactly how the 2026-09-14 data-loss bug survived (Root Cause #98), and it is
- * also Root Cause #38's shape, where saving one field silently stripped tester
- * flags and un-verified a store because the list row never carried them.
- *
- * @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-admin-detail-round-trips-coupon-edit-round-trip": {
-        roles: ["admin"],
-        startPage: "/admin/coupons",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/coupons and find the coupon with code ARENA25.",
-            "Open its Edit action and write down its discount value, its usage limits and its validity dates.",
-            "Change ONLY the description — append the word roundtrip.",
-            "Press Save.",
-            "Reload the page and open the same coupon again.",
-            "Read the discount value, the usage limits and the validity dates.",
-            "Restore the description by deleting the word you appended, then save again. coupons is SEED_OWNED so a reseed would fix it either way, but a run does not reseed — three earlier runs left this text reading 'roundtrip roundtrip roundtrip', and a later case reading this description would be reading what this one wrote.",
-            "Note the editor keeps Limits and Validity in COLLAPSIBLE sections. After the reload they are closed, so their fields are absent from the page rather than empty — read those four numbers off the coupon card in the list, which renders them directly, or expand the sections again before judging.",
-        ],
-        inputs: { couponCode: "ARENA25", descriptionSuffix: "roundtrip" },
-        expectedBehaviour: "Editing one field writes that field and leaves the rest as they were. A handler that merges a partial validity or restrictions object wholesale wipes whatever the caller did not resend — and a handler that never calls the repository at all returns a 200 that echoes the submission back, which is indistinguishable from a save.",
-        expectedUiState: "The description carries the appended word. The discount value, both usage limits and both validity dates are exactly as written down.",
-        expectedData: { unrelatedFieldsChanged: 0 },
-        endResult: "All of it survives a second reload — the change was stored, not just rendered.",
-    },
-    "checklist-admin-admin-detail-round-trips-faq-edit-preserves-answer-shape": {
-        roles: ["admin"],
-        startPage: "/admin/faqs",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/faqs and pick the FAQ whose slug is coupons-and-discounts.",
-            "Open its Edit action and read how the answer renders in the editor.",
-            "Append the sentence: Edited during a round-trip check.",
-            "Press Save.",
-            "Reload and reopen the same FAQ.",
-            "Open the public /faqs page and find the same question. Answers are collapsed accordions — click the question to expand it before reading.",
-            "Remove the sentence you appended and save again. Append it with the KEYBOARD at the caret, never by filling the field: this is a contenteditable holding real HTML, and a fill replaces the whole answer with plain text, destroying five bold runs on a buyer-facing page.",
-        ],
-        inputs: { faqSlug: "coupons-and-discounts", appended: "Edited during a round-trip check." },
-        expectedBehaviour: "The answer is a structured value, not a bare string. A create path that wraps it and an update path that writes it flat produce a document every reader expects to be an object and finds is a string — which renders as nothing, or as raw markup, on the public page.",
-        expectedUiState: "The editor still shows formatted rich text after the reload, and the public FAQ renders the answer as prose rather than as visible markup or an empty block.",
-        expectedData: { answerRendersAsRichText: true },
-        endResult: "The appended sentence is present on both the admin editor and the public page.",
-    },
-    "checklist-admin-admin-detail-round-trips-category-edit-keeps-hierarchy": {
-        roles: ["admin"],
-        startPage: "/admin/categories",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /categories/category-x-basic as a visitor in a second tab and write down its product count. Note the FULL id — /categories/x-basic serves 'Category Not Found'; every category id carries the category- prefix.",
-            "In the first tab open /admin/categories and find Basic Line — that is the display name of category-x-basic; there is no category called 'X Basic'.",
-            "Write down its parent and how many children it has.",
-            "Open its Edit action, change ONLY its description, and press Save.",
-            "Reload the admin list and reopen it.",
-            "Reload the public category page in the second tab.",
-            "Restore the description by removing the word you appended, then save again. Three of the cases on this page append a marker and this one accumulated 'roundtrip' from an earlier run — categories is SEED_OWNED, but a run does not reseed.",
-        ],
-        inputs: { categorySlug: "x-basic" },
-        expectedBehaviour: "A rename or a description edit touches that field alone. The hierarchy fields — parent, children, ancestors, tier — are derived and must never be rewritten from form state, and the product count is derived from a trigger rather than typed.",
-        expectedUiState: "The parent and the child count are unchanged, and the public page shows the same product count as before.",
-        expectedData: { hierarchyChanged: false, countChanged: false },
-        endResult: "Everything except the description is identical after a reload.",
-    },
-    "checklist-admin-admin-detail-round-trips-user-edit-keeps-tester-flags": {
-        roles: ["admin"],
-        startPage: "/admin/users",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/users and find the account rehan.sheikh@gmail.com.",
-            "Open its Edit action, turn BOTH tester flags on, and save — no seeded account carries them, so the case has to set up the field it is about.",
-            "Reopen the same account and confirm both flags read as on.",
-            "WRITE DOWN the bio exactly as it stands, then change ONLY the bio — append the word roundtrip.",
-            "Press Save.",
-            "Reload the list and reopen the same account.",
-            "Read the tester flags again.",
-            "Turn both tester flags back off AND restore the bio to what you wrote down, then save. users is PRESERVE-tier — never wiped, never reseeded — so an appended word left behind is permanent, and after a few runs the bio reads roundtrip roundtrip roundtrip.",
-        ],
-        inputs: { account: "rehan.sheikh@gmail.com", bioSuffix: "roundtrip" },
-        expectedBehaviour: "An editor seeded from a LIST row can only send back what that row carried. If the list serializer omits a field the update schema accepts, the editor state defaults to false and the save rewrites it — so editing any other field silently strips it. That is why the check is on a field the form did not touch.",
-        expectedUiState: "Both tester flags are still on after the reload, and the bio carries the appended word.",
-        expectedData: { testerFlagsPreserved: true },
-        endResult: "The flags survive a second reload, and the final step leaves the account back on its seeded settings with both flags off.",
-    },
-    "checklist-admin-admin-detail-round-trips-store-edit-keeps-verified": {
-        roles: ["admin"],
-        startPage: "/admin/stores",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/stores and find Beyblade Arena.",
-            "Note whether it is marked Verified and whether it is Featured.",
-            "Note the admin notes as they stand, then open its Edit action and change ONLY the admin notes — append the word roundtrip. Restore them before you finish. Unlike the user bio in the sibling case, stores is SEED_OWNED and a reseed would put this back either way — so this is hygiene rather than damage control, and it keeps a later case from reading notes this one wrote.",
-            "Press Save.",
-            "Reload the list.",
-            "Read the Verified and Featured markers again.",
-        ],
-        inputs: { store: "store-beyblade-arena", notesSuffix: "roundtrip" },
-        expectedBehaviour: "Same failure mode as the tester flags, with a worse consequence: un-verifying a store is visible to shoppers. A store's capabilities can be reset to a two-item default by the same mechanism, which is invisible until a seller reports that a feature disappeared.",
-        expectedUiState: "Verified and Featured are unchanged, and the admin notes carry the appended word.",
-        expectedData: { verifiedPreserved: true, featuredPreserved: true },
-        endResult: "Both markers are still correct after a reload.",
-    },
-    "checklist-admin-admin-detail-round-trips-order-view-matches-drawer": {
-        roles: ["admin"],
-        startPage: "/admin/orders",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/orders and open the row drawer for order-1-20251107-11joon.",
-            "Write down the item titles, the shipping address, the payment method and the status.",
-            "Close the drawer and use that row's Open full page action.",
-            "Read the same four things on the full page.",
-        ],
-        inputs: { orderId: "order-1-20251107-11joon" },
-        expectedBehaviour: "The drawer and the full page are two renderings of one record, so they must agree. Where they differ, one of them is reading a field the other is not — and the full page is the bookmarkable one an admin will send to somebody else.",
-        expectedUiState: "Item titles, address, payment method and status are identical in both, and the full page is at a real bookmarkable URL rather than a modal over the list.",
-        expectedData: { drawerAndPageAgree: true },
-        endResult: "Nothing is changed; this case only reads.",
-    },
-    "checklist-admin-admin-detail-round-trips-admin-detail-missing-id-404s": {
-        roles: ["admin"],
-        startPage: "/admin/coupons",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Navigate to /admin/coupons/zzzznope-not-a-coupon-42/edit — a deliberately invented id, not a fixture.",
-            "Read what the page shows.",
-            "Navigate to /admin/orders/zzzznope-not-an-order-42/view.",
-            "Read that page too.",
-        ],
-        inputs: { couponId: "zzzznope-not-a-coupon-42", orderId: "zzzznope-not-an-order-42" },
-        expectedBehaviour: "An id that resolves to nothing must 404. An empty editor here is the tell that the page never checked what it received — and an empty editor with a Save button is how a record gets created or overwritten from a typo.",
-        expectedUiState: "Both show a not-found page. Neither shows an editable form, and neither shows a Save button.",
-        expectedData: { showsEditForm: false },
-        endResult: "Nothing is created and nothing is saved.",
-    },
-};

package/dist/features/tester/seed-data/authored/admin__bans-and-trust.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__bans-and-trust.js

@@ -1,265 +0,0 @@
-/*
- * 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.
- *
- * 🛑 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
- * @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 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.",
-            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 a soft ban on the account rohit.collect@gmail.com.",
-            "Leave the reason field empty and submit.",
-            "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 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,
-            "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.", 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: "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"],
-        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 — 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 — it should now be disabled.",
-            "Unban the account and confirm it is enabled again.",
-        ],
-        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 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"],
-        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

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