@mohasinac/appkit 4.35.3 → 4.36.0

package/dist/_internal/server/jobs/handlers/onShipmentAllocationSync.js

@@ -1,5 +1,59 @@
 import { allocateShipmentCosts } from "../../../../features/shipments/utils/cost-allocation";
 const DEFAULT_MAX_HOURS_PER_DAY = 4;
+/*
+ * 🛑 THIS COMPARISON IS LOAD-BEARING. GETTING IT WRONG IS AN INFINITE LOOP THAT
+ * COSTS REAL MONEY, AND IT ALREADY DID.
+ *
+ * `onShipmentHeaderWrite` watches `procurementShipments/{shipmentId}` on
+ * documentWritten and writes BACK to that same document. The only thing stopping
+ * that from recurring forever is this equality check, so a false "changed" is not
+ * a wasted write — it is a permanent, self-sustaining cascade.
+ *
+ * It was `JSON.stringify(shipment.totals ?? {}) === JSON.stringify(totals)`.
+ * That is key-ORDER sensitive, and the two sides can never agree:
+ *
+ *   computed  — construction order from allocateShipmentCosts():
+ *               lotsCost, customsTotal, shippingTotal, laborCost, …
+ *   stored    — Firestore returns map fields with keys sorted ALPHABETICALLY:
+ *               customsTotal, estimatedProcessingDays, laborCost, lotCount, …
+ *
+ * So `totalsUnchanged` was ALWAYS false, every invocation wrote, and every write
+ * re-triggered the function. Measured 2026-09-11 in the Firebase console:
+ * `onShipmentHeaderWrite` 1,017,548 and `onShipmentDeleted` 1,017,372 invocations
+ * in 24 HOURS — 12M for the month against a 2M/month free quota, exceeded by
+ * 9.7M, while every other function in the project sat between 0 and 95.
+ *
+ * `onShipmentDeleted` was pure collateral: it is correctly guarded
+ * (`if (event.after) return`) but is bound to the same path, so it woke up a
+ * million times a day just to return.
+ *
+ * Two properties this replacement needs, and the old one had neither:
+ *   1. KEY ORDER MUST NOT MATTER — compare by key, never by serialised form.
+ *   2. FLOATS NEED TOLERANCE. `projectedMarginPercent` and `projectedRoiPercent`
+ *      are unrounded divisions, and a Firestore round-trip can return a value
+ *      that differs in the last bit. Exact `!==` on those is another way to make
+ *      "unchanged" unreachable — the same bug with a different mechanism.
+ */
+const MONEY_EPSILON = 0.005; // half a paisa: below anything that can be displayed
+function numbersEqual(a, b) {
+    const x = typeof a === "number" ? a : Number.NaN;
+    const y = typeof b === "number" ? b : Number.NaN;
+    if (Number.isNaN(x) && Number.isNaN(y))
+        return a === b; // both non-numeric: identity
+    return Math.abs(x - y) < MONEY_EPSILON;
+}
+/** Value equality over a flat numeric map, independent of key order. */
+function totalsEqual(stored, computed) {
+    if (!stored || typeof stored !== "object" || Array.isArray(stored))
+        return false;
+    const a = stored;
+    const keys = new Set([...Object.keys(a), ...Object.keys(computed)]);
+    for (const k of keys) {
+        if (!numbersEqual(a[k], computed[k]))
+            return false;
+    }
+    return true;
+}
 async function recomputeShipmentAllocation(shipmentId, ctx) {
     const shipmentRef = ctx.db.collection("procurementShipments").doc(shipmentId);
     const shipmentSnap = await shipmentRef.get();
@@ -34,11 +88,17 @@ async function recomputeShipmentAllocation(shipmentId, ctx) {
     for (const lot of lots) {
         const computed = perLot[lot.id];
         const statusChanged = lot.shipmentStatus !== shipment.status;
-        const valuesChanged = lot.customsAllocated !== computed.customsAllocated ||
-            lot.shippingAllocated !== computed.shippingAllocated ||
-            lot.totalLandedCost !== computed.totalLandedCost ||
-            lot.projectedRevenue !== computed.projectedRevenue ||
-            lot.projectedProfit !== computed.projectedProfit;
+        /*
+         * Same tolerance as the totals check, for the same reason: a lot write fires
+         * `onShipmentLotWrite`, which calls straight back into this function. Exact
+         * `!==` on a float that has round-tripped through Firestore is a second,
+         * independent path to the same infinite cascade.
+         */
+        const valuesChanged = !numbersEqual(lot.customsAllocated, computed.customsAllocated) ||
+            !numbersEqual(lot.shippingAllocated, computed.shippingAllocated) ||
+            !numbersEqual(lot.totalLandedCost, computed.totalLandedCost) ||
+            !numbersEqual(lot.projectedRevenue, computed.projectedRevenue) ||
+            !numbersEqual(lot.projectedProfit, computed.projectedProfit);
         if (statusChanged || valuesChanged) {
             anyLotChanged = true;
             batch.update(ctx.db.collection("shipmentLots").doc(lot.id), {
@@ -48,8 +108,15 @@ async function recomputeShipmentAllocation(shipmentId, ctx) {
             });
         }
     }
-    const totalsUnchanged = JSON.stringify(shipment.totals ?? {}) === JSON.stringify(totals);
+    const totalsUnchanged = totalsEqual(shipment.totals, totals);
     if (!totalsUnchanged) {
+        // trigger-self-write-ok: this writes to the collection onShipmentHeaderWrite
+        // watches, so it re-triggers itself — ONCE. The second pass recomputes the
+        // same `totals` from unchanged inputs, totalsEqual() reports them identical
+        // (by key, with a float tolerance — NOT by JSON.stringify, which is key-order
+        // sensitive and is what made this loop run 1,017,548 times in 24h), so no
+        // write happens and the cascade stops. Pinned by
+        // scripts/verify-shipment-allocation-guard.mjs.
         batch.update(shipmentRef, { totals, totalsComputedAt: ctx.now, updatedAt: ctx.now });
     }
     if (anyLotChanged || !totalsUnchanged) {

package/dist/features/products/hooks/useProducts.js

@@ -3,6 +3,8 @@ import { useEffect } from "react";
 import { useQuery } from "@tanstack/react-query";
 import { apiClient } from "../../../http";
 import { useToast } from "../../../ui";
+import { useOptionalSession } from "../../../react/contexts/SessionContext";
+import { isAdminUser, isTesterUser } from "../../auth/role-predicates";
 import { PRODUCT_ENDPOINTS } from "../../../constants/api-endpoints";
 export function useProducts(params = {}, opts) {
     const { showToast } = useToast();
@@ -73,11 +75,46 @@ export function useProducts(params = {}, opts) {
             sp.set(key, value);
     }
     const qs = sp.toString();
+    /*
+     * 🛑 A TESTER MUST REFETCH; EVERYONE ELSE MUST KEEP THE CACHED SSR PAINT.
+     *
+     * Sandbox rows are correctly hidden from the public. But the SSR listing views
+     * pass no `viewer` to `listPublicProducts`, so the server-rendered grid is the
+     * anonymous one for EVERY visitor — and with `initialData` + `staleTime:
+     * Infinity` the client never refetches, so a signed-in tester saw a catalogue
+     * with no sandbox fixtures in it, on every listing page. The items were
+     * reachable by direct URL, which is what made it look like a data problem
+     * rather than a visibility one.
+     *
+     * The fix is NOT to read the session in those SSR views. `getServerSessionUser`
+     * is a dynamic API, and calling it there would make every public listing page
+     * per-request — no caching, a billed invocation per visitor, and every
+     * `revalidate` silently overridden. That is Root Cause #82, and paying it for a
+     * testing affordance would be a poor trade.
+     *
+     * `/api/products` ALREADY resolves the session and passes `viewer`. So the only
+     * thing missing was a reason for the client to ask again: the query key now
+     * carries the viewer class, giving testers their own cache entry, and their
+     * `staleTime` is not frozen. Anonymous visitors keep the cached SSR data
+     * untouched and issue no extra request.
+     *
+     * `useOptionalSession` rather than `useAuth()` on purpose — `useSession`
+     * THROWS outside a provider, and making a public appkit hook require one would
+     * be a breaking contract change (Root Cause #20). Absent provider degrades to
+     * "not a tester", which is the fail-closed answer.
+     */
+    const session = useOptionalSession();
+    const viewer = session?.user;
+    const canSeeTestData = isTesterUser(viewer) || isAdminUser(viewer);
     const query = useQuery({
-        queryKey: ["products", qs],
+        queryKey: ["products", qs, canSeeTestData ? "with-test-data" : "public"],
         queryFn: () => apiClient.get(`${PRODUCT_ENDPOINTS.LIST}${qs ? `?${qs}` : ""}`),
-        initialData: opts?.initialData,
-        staleTime: opts?.staleTime ?? (opts?.initialData != null ? Infinity : 0),
+        // The SSR paint is the anonymous view, so it is only a valid starting point
+        // for an anonymous viewer. Handing it to a tester would show them the very
+        // rows this refetch exists to reveal.
+        initialData: canSeeTestData ? undefined : opts?.initialData,
+        staleTime: opts?.staleTime ??
+            (!canSeeTestData && opts?.initialData != null ? Infinity : 0),
         enabled: opts?.enabled,
     });
     const warning = query.data?.warning;

package/dist/features/tester/schemas/firestore.d.ts

@@ -108,6 +108,35 @@ export interface TesterChecklistItemDocument extends BaseDocument {
      * field to mean two different things.
      */
     endResult?: string;
+    /**
+     * The case's own author was unsure of its intent — the report flags the verdict
+     * so nobody reads it with more confidence than it earned.
+     *
+     * 🛑 These were UNDECLARED here until 2026-09-13, which is why the flag had
+     * never once fired: `fetch-cases.mjs` read them off the document, SKILL.md
+     * documented them and `record-verdicts.mjs` had a line to render them, but
+     * `group()` did not forward them and this interface did not admit them. Four
+     * hops right, two hops missing, and not one error anywhere. Root Cause #38.
+     */
+    needsReview?: boolean;
+    reviewNote?: string;
+    /**
+     * The case needs a channel an automated browser does not have — a real email
+     * inbox, or an interactive Google account. Always `null` in an automated run,
+     * by nature rather than by fault.
+     *
+     * 🛑 A PERMANENT FLOOR, not a backlog. Unflagged, these sit in the same
+     * "blocked" bucket as a case blocked by a genuine defect, so a raw blocked
+     * count mixes a constant with a signal and every run re-triages the same
+     * thirteen to rediscover none is a bug. Flagged, the report subtracts them.
+     *
+     * Never use it for a case that is merely hard, flaky or currently failing —
+     * that converts a defect into a documented non-test. See the three-kinds-of-
+     * null table in docs/TESTING-RIG-NOTES.md.
+     */
+    requiresHumanChannel?: boolean;
+    /** Which channel is missing, e.g. "real email inbox". Rendered in the report. */
+    humanChannelReason?: string;
     href?: string;
     order: number;
     phase: number;

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

@@ -30,4 +30,28 @@ export interface AuthoredCase {
      */
     needsReview?: boolean;
     reviewNote?: string;
+    /**
+     * The case needs a channel an automated browser does not have — a real email
+     * inbox, or an interactive Google account. It is correct, it is worth keeping,
+     * and an automated run can never do anything with it but abstain.
+     *
+     * 🛑 This is a PERMANENT FLOOR, not a backlog. Without the flag those ~13 cases
+     * report `null` in every run forever and land in the same "blocked" bucket as a
+     * case blocked by a real defect — so a raw blocked count mixes a constant with
+     * a signal, and each run re-triages the same thirteen to rediscover that none
+     * of them is a bug. Flagged, the report can subtract them and say so.
+     *
+     * Deliberately distinct from the other two reasons a case yields no verdict —
+     * see the three-kinds-of-null table in docs/TESTING-RIG-NOTES.md. A missing
+     * fixture is a RIG fault and must be fixed; a case blocked by another defect is
+     * a PRODUCT fault and disappears when its cause does. Only this one is a
+     * permanent property of running headlessly, and collapsing the three is how a
+     * fixable gap hides inside an unfixable one.
+     *
+     * It must NEVER be used to excuse a case that is merely hard, flaky, or
+     * currently failing: that converts a defect into a documented non-test.
+     */
+    requiresHumanChannel?: boolean;
+    /** Which channel is missing, e.g. "real email inbox" / "interactive Google account". */
+    humanChannelReason?: string;
 }

package/dist/features/tester/seed-data/authored/account-auth__profile-settings.js

@@ -148,6 +148,8 @@ export const authored = {
         endResult: "All three links reach the same page. Set profile visibility back to Public afterwards, since other cases read this profile as another user.",
     },
     "checklist-account-auth-profile-settings-password-change-reset-link": {
+        requiresHumanChannel: true,
+        humanChannelReason: "real email inbox",
         roles: ["buyer"],
         startPage: "/user/settings",
         steps: [

package/dist/features/tester/seed-data/authored/account-auth__signup-login.js

@@ -28,6 +28,8 @@
  */
 export const authored = {
     "checklist-account-auth-signup-login-auth-email-links-single-use": {
+        requiresHumanChannel: true,
+        humanChannelReason: "real email inbox",
         roles: ["guest"],
         startPage: "/auth/forgot-password",
         steps: [
@@ -51,6 +53,8 @@ export const authored = {
         endResult: "Account state after the second click is identical to after the first. divya.funko@gmail.com is back on TempPass123! by the final step — skipping that restore leaves the account unusable by every later case, since the seeder never resets an existing password.",
     },
     "checklist-account-auth-signup-login-auth-emails-sender-identity-and-inbox": {
+        requiresHumanChannel: true,
+        humanChannelReason: "real email inbox",
         roles: ["guest"],
         startPage: "/auth/register",
         steps: [
@@ -92,6 +96,8 @@ export const authored = {
         endResult: "Reloading /user shows 'QA Signup Tester' and the address used. The account persists — this case creates a real row that a later teardown does not remove, which is why the address is numbered rather than fixed.",
     },
     "checklist-account-auth-signup-login-email-verify": {
+        requiresHumanChannel: true,
+        humanChannelReason: "real email inbox",
         roles: ["guest"],
         startPage: "/auth/register",
         steps: [
@@ -124,6 +130,8 @@ export const authored = {
         endResult: "No email arrives for nobody-here-12345@example.com. The two on-screen responses were indistinguishable, which is the whole point — a difference of any kind is an account-enumeration leak.",
     },
     "checklist-account-auth-signup-login-google-link-confirmation-shown": {
+        requiresHumanChannel: true,
+        humanChannelReason: "interactive Google account",
         roles: ["buyer"],
         startPage: "/user",
         steps: [
@@ -137,6 +145,8 @@ export const authored = {
         endResult: "After reload the green confirmation is still there and the blue prompt has not returned. Needs a Google account to reach — answer null with that reason rather than guessing if none is available.",
     },
     "checklist-account-auth-signup-login-google-link-conflict-rejected": {
+        requiresHumanChannel: true,
+        humanChannelReason: "interactive Google account",
         roles: ["buyer"],
         startPage: "/user/settings",
         steps: [
@@ -156,6 +166,8 @@ export const authored = {
         endResult: "After reload vivaan.kapoor@gmail.com has no Google link and rehan.sheikh@gmail.com still has G. Unlink G from rehan.sheikh@gmail.com afterwards. Needs a real Google account — answer null if none is available.",
     },
     "checklist-account-auth-signup-login-google-link-different-email": {
+        requiresHumanChannel: true,
+        humanChannelReason: "interactive Google account",
         roles: ["buyer"],
         startPage: "/user/settings",
         steps: [
@@ -174,6 +186,8 @@ export const authored = {
         endResult: "After reload the link persists and the primary email is still vivaan.kapoor@gmail.com. Unlink afterwards. Needs a second Google account — answer null if none is available.",
     },
     "checklist-account-auth-signup-login-google-link-existing": {
+        requiresHumanChannel: true,
+        humanChannelReason: "interactive Google account",
         roles: ["guest"],
         startPage: "/auth/register",
         steps: [
@@ -194,6 +208,8 @@ export const authored = {
         endResult: "One account exists for that email, not two, and it kept its wishlist. Needs a Google account whose address you can also register with — answer null if none is available.",
     },
     "checklist-account-auth-signup-login-google-oauth": {
+        requiresHumanChannel: true,
+        humanChannelReason: "interactive Google account",
         roles: ["guest"],
         startPage: "/auth/login",
         steps: [
@@ -208,6 +224,8 @@ export const authored = {
         endResult: "Reloading /user keeps the session. Needs a Google account — answer null with that reason if none is available.",
     },
     "checklist-account-auth-signup-login-google-popup-blocked-fallback": {
+        requiresHumanChannel: true,
+        humanChannelReason: "interactive Google account",
         roles: ["guest"],
         startPage: "/auth/login",
         steps: [
@@ -253,6 +271,8 @@ export const authored = {
         endResult: "Navigating to /user lands on /auth/login and no data for Vivaan Kapoor is rendered at any point. A back-button press does not restore the dashboard.",
     },
     "checklist-account-auth-signup-login-password-reset": {
+        requiresHumanChannel: true,
+        humanChannelReason: "real email inbox",
         roles: ["guest"],
         startPage: "/auth/login",
         steps: [
@@ -276,6 +296,8 @@ export const authored = {
         endResult: "The password is back at TempPass123! by the final step. That restore is mandatory: the seeder never resets an existing password, so skipping it leaves this account permanently signed out of every later case.",
     },
     "checklist-account-auth-signup-login-signup-verification-email-arrives": {
+        requiresHumanChannel: true,
+        humanChannelReason: "real email inbox",
         roles: ["guest"],
         startPage: "/auth/register",
         steps: [

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

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

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

@@ -0,0 +1,106 @@
+/*
+ * 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 18"
+ *   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.
+ *
+ * @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 in full before accepting, 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" },
+        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.",
+        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.",
+    },
+    "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 18.",
+            "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" },
+        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.",
+    },
+    "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').",
+            "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.",
+        ],
+        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.",
+    },
+    "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 — reported bug' and read how many rows match.",
+            "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.",
+            "Set Status back to its default and set 'Bug status' to 'Bug Confirmed'.",
+            "Read which rows appear under that filter.",
+        ],
+        inputs: { search: "Demo fixture — reported bug" },
+        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.",
+        expectedData: { defaultViewHidesBugConfirmed: true },
+        endResult: "Read-only — no case is modified.",
+    },
+};

package/dist/features/tester/seed-data/authored/admin__site-system.js

@@ -211,6 +211,8 @@ export const authored = {
         endResult: "Read-only; send nothing.",
     },
     "checklist-admin-site-system-daily-digest-email-content": {
+        requiresHumanChannel: true,
+        humanChannelReason: "real email inbox",
         roles: ["admin"],
         startPage: "/admin/site",
         steps: [

package/dist/features/tester/seed-data/authored/buying__my-orders.js

@@ -239,6 +239,8 @@ export const authored = {
         endResult: "Read-only. If no rejected order exists, answer null rather than creating one — rejecting as fraud bans a real account for seven days.",
     },
     "checklist-buying-my-orders-order-lifecycle-emails-arrive": {
+        requiresHumanChannel: true,
+        humanChannelReason: "real email inbox",
         roles: ["buyer"],
         startPage: "/user/orders",
         steps: [

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

@@ -384,6 +384,8 @@ export const authored = {
         endResult: "All four listings keep their type-specific fields. Restore any title that was changed.",
     },
     "checklist-buying-offers-notification-email-is-a-real-email": {
+        requiresHumanChannel: true,
+        humanChannelReason: "real email inbox",
         roles: ["buyer"],
         startPage: "/user/settings",
         steps: [

package/dist/features/tester/seed-data/authored/content-discovery__notifications.js

@@ -96,6 +96,8 @@ export const authored = {
         endResult: "Read-only; nothing persists beyond the URL.",
     },
     "checklist-content-discovery-notifications-notification-email-actually-arrives": {
+        requiresHumanChannel: true,
+        humanChannelReason: "real email inbox",
         roles: ["buyer"],
         startPage: "/user/settings",
         steps: [

package/dist/features/tester/seed-data/authored/content-discovery__search.js

@@ -39,17 +39,30 @@ export const authored = {
         roles: ["guest"],
         startPage: "/",
         steps: [
+            // The batch seeds TWO probe rows: product-{{w}}-draft-probe (status
+            // "draft") and product-{{w}}-archived-probe (status "archived"), both
+            // titled so the query below matches them. Without a KNOWN unpublished row
+            // the case cannot distinguish "drafts are correctly hidden" from "there
+            // were no drafts" — a tester reported exactly that: the suggestion payload
+            // carries no status field to inspect, and no draft existed to probe with.
             "Open / in a private window with no session.",
-            "Click into the header search and type beyblade.",
+            "Click into the header search and type draftprobe.",
             "Read every suggestion and note its title.",
+            "Check specifically whether product-{{w}}-draft-probe or product-{{w}}-archived-probe appear.",
+            "Now type beyblade and read every suggestion.",
             "Open each suggestion in turn and read the page it lands on.",
             "Note any that 404s or shows an unpublished listing.",
         ],
-        inputs: { query: "beyblade" },
+        inputs: {
+            query: "beyblade",
+            probeQuery: "draftprobe",
+            draftProduct: "product-{{w}}-draft-probe",
+            archivedProduct: "product-{{w}}-archived-probe",
+        },
         expectedBehaviour: "Suggestions are filtered to published, publicly-visible listings. A status filter applied only when the caller explicitly asks for one is absent here, because a typeahead rarely asks — which is exactly how draft rows reach a public suggestion list.",
-        expectedUiState: "Every suggestion opens a real published listing. None 404s, none opens a draft or archived listing, and none names a tester sandbox item for a signed-out visitor.",
-        expectedData: { draftSuggestions: 0 },
-        endResult: "Read-only; nothing persists.",
+        expectedUiState: "Searching 'draftprobe' returns NEITHER probe row — that is the real test, because both exist and both match the term. Then every 'beyblade' suggestion opens a real published listing: none 404s, none opens a draft or archived listing, and none names a tester sandbox item for a signed-out visitor.",
+        expectedData: { draftSuggestions: 0, probeRowsSuggested: 0 },
+        endResult: "Read-only; both probe rows are removed when the batch ends.",
     },
     "checklist-content-discovery-search-search-prefix-match": {
         roles: ["guest"],
@@ -101,16 +114,24 @@ export const authored = {
         roles: ["guest"],
         startPage: "/products",
         steps: [
-            "Open /products in a private window.",
+            // PRECONDITION FIRST. Without it a broken sort reads as "inconclusive"
+            // instead of "fail" — which is exactly what happened: a tester reported
+            // sorts=price and sorts=-price returning an IDENTICAL order with no
+            // search term at all, and had no way to record that as a verdict.
+            "Open /products in a private window with NO search term.",
+            "Set the sort to 'Price: low to high' and read the first three prices in order.",
+            "Set the sort to 'Price: high to low' and read the first three prices again.",
+            "If those two orders are identical, STOP and answer NO — sort is broken before search is involved, and say so. Do not continue.",
             "Type beyblade in the search field and click 'Search'.",
             "Read the card order and note the sort dropdown's selection.",
-            "Change the sort to price, low to high.",
+            "Change the sort to 'Price: low to high'.",
             "Read the card order, the URL and the search field.",
             "Reload the page and read all three again.",
         ],
-        inputs: { query: "beyblade", sort: "Price: low to high" },
+        inputs: { query: "beyblade", sort: "Price: low to high", sortReverse: "Price: high to low" },
         expectedBehaviour: "Changing the sort re-orders the current results and keeps the term. Both live in the URL, so a reload reproduces the same page — and the sort field must be one the query can actually sort on, since an unsortable field is dropped and the dropdown silently reorders nothing.",
-        expectedUiState: "Prices ascend down the page and the search field still holds 'beyblade'. The URL carries both. After the reload the order and the term are unchanged. A dropdown selection that changes no order at all is the dropped-sort failure.",
+        expectedUiState: "With no search term, ascending and descending produce DIFFERENT orders — that is the precondition. Then, with the term applied, prices ascend down the page and the search field still holds 'beyblade'. The URL carries both. After the reload the order and the term are unchanged. A dropdown selection that changes no order at all is the dropped-sort failure, and it is a NO rather than an unanswerable.",
+        expectedData: { ascendingDiffersFromDescending: true },
         endResult: "Read-only; nothing persists beyond the URL.",
     },
     "checklist-content-discovery-search-search-keeps-facets": {
@@ -126,8 +147,8 @@ export const authored = {
         ],
         inputs: { query: "beyblade", priceMin: 500, priceMax: 1500 },
         expectedBehaviour: "Price, tag and availability all narrow alongside the term. A facet that renders and counts toward the badge while changing nothing is inert — that happens when it emits a field the query allowlist does not carry, and nothing raises.",
-        expectedUiState: "Each facet visibly reduces the count and every card respects it. The availability tab changes which rows appear. A facet that leaves the count identical while the filter badge increments is the failure.",
-        expectedData: { inertFacetCount: 0 },
+        expectedUiState: "Each facet visibly reduces the count and every card respects it. The availability tab changes which rows appear. A facet that leaves the count identical while the filter badge increments is the failure. RECORD ALL THREE COUNTS SEPARATELY — price, tag, availability. This case names those three specifically; exercising a different facet (category, say) and reporting a partial pass answers a question nobody asked. If one of the three cannot be reached, answer NO or null for that reason rather than passing on the strength of the other two.",
+        expectedData: { inertFacetCount: 0, facetsExercised: 3 },
         endResult: "Read-only; nothing persists beyond the URL.",
     },
     "checklist-content-discovery-search-search-case-and-accents": {
@@ -182,10 +203,11 @@ export const authored = {
         startPage: "/faqs",
         steps: [
             "Open /faqs in a private window and read the category list.",
-            "Open the Shipping category page.",
+            "CLICK INTO the Shipping category — this case is about the category PAGE, so reading the counters on /faqs is not an answer to it.",
             "Read the questions listed and expand one to read its answer.",
             "Read the address bar.",
             "Open a second category page and read its questions.",
+            "Compare the two lists of questions against each other.",
         ],
         expectedBehaviour: "Each category has its own page, keyed on the category's slug, rendering only its questions. Two category pages showing the same questions means the slug is not reaching the query.",
         expectedUiState: "The Shipping page lists shipping questions and an expanded answer renders as formatted text, not as raw HTML shown as visible characters. The second category shows a different set.",
@@ -318,15 +340,22 @@ export const authored = {
         startPage: "/admin/products",
         steps: [
             "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/products and sort by oldest first.",
-            "Read the title of the oldest listing.",
-            "Search for a distinctive word from that title.",
-            "Read whether that listing is returned.",
-            "Repeat with the newest listing's title as a comparison.",
+            // The batch seeds product-{{w}}-untokenised with NO searchTokens field —
+            // a stand-in for a record written before the token field existed. On a
+            // freshly-seeded catalogue every row carries current tokens, so without
+            // this fixture the case is unanswerable by construction, which is exactly
+            // what a tester reported: "the catalogue was freshly seeded... there is no
+            // older record to probe with".
+            "Open /admin/products and search for the exact word 'untokenised'.",
+            "Read whether product-{{w}}-untokenised is returned.",
+            "Search for a distinctive word from any ordinary seeded listing's title.",
+            "Read whether that one is returned.",
+            "Compare the two results.",
         ],
+        inputs: { untokenisedProduct: "product-{{w}}-untokenised", query: "untokenised" },
         expectedBehaviour: "Search is backed by a normalised token field written on save. Records created before that field existed have no tokens, so they are unfindable — the fix is a backfill, and this case is what detects whether one is needed.",
-        expectedUiState: "Both the oldest and the newest listing are returned by a word from their own titles. The newest being findable while the oldest is not is the signature of missing tokens on older rows, not of a broken search.",
+        expectedUiState: "BOTH listings are returned by a word from their own titles. The ordinary one being findable while product-{{w}}-untokenised is not is the signature of missing tokens on older rows, not of a broken search — and it means a backfill is owed.",
         expectedData: { oldRecordFound: true },
-        endResult: "Read-only; nothing persists. Testing only recent records would pass this case while the backfill gap remains.",
+        endResult: "Read-only; the fixture is removed when the batch ends. Testing only recent records would pass this case while the backfill gap remains.",
     },
 };