@mohasinac/appkit 4.58.0 → 4.59.0

package/dist/features/tester/seed-data/authored/admin__events-raffles-spin.js

@@ -1,202 +0,0 @@
-/*
- * WHY: Authored six-part procedures for the admin/events-raffles-spin page.
- * WHAT: 8 case(s), keyed by full checklist id.
- *
- * Written by hand, case by case, against the label each one states. There is no
- * generator: the authoring scripts were deleted once it was clear they were
- * scaffolding around work that is simply writing.
- *
- * 🛑 THE ADMIN EVENT TYPE PICKER HAS BEEN WRONG BEFORE in a way no query error
- * surfaced: it offered three types the event union has never had, so each matched
- * zero rows forever, while omitting five real ones. Two cases here read the picker
- * and the filter chips against the real union rather than trusting either.
- *
- * The two "view before deciding" cases are the same defect as the moderation
- * pages: a row that offers Confirm and Waitlist without showing the entry lets an
- * admin act on a record they were never able to read.
- *
- * @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-events-raffles-spin-raffle-create-open": {
-        roles: ["admin", "buyer"],
-        startPage: "/admin/events/new",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/events/new and read every option in the event type picker.",
-            "Write the list down and compare it against the real event types the catalogue supports.",
-            "Create an event titled 'QA Event raffle-open' with a raffle of type 'Open raffle (all confirmed entries)' — the full dropdown label, a prize, a start date of today and an end date a week out.",
-            "Save, RELOAD, and read the raffle type, the prize and the dates.",
-            "Sign out, sign in as rehan.sheikh@gmail.com / TempPass123!, and enter the raffle from its public page.",
-            "Sign back in as admin and read the entry count on the event.",
-        ],
-        inputs: { title: "QA Event raffle-open", raffleType: "open" },
-        expectedBehaviour: "The type picker offers every real event type and no invented ones. An option whose value is not a stored type matches nothing forever with no error — the picker once offered three such and omitted five real ones, under a comment deferring the fix.",
-        expectedUiState: "The picker's options match the real type list, with no contest, giveaway or flash-sale style values that the union does not carry, and with lottery present. After the reload the raffle settings hold, and the buyer's entry raises the count.",
-        endResult: "Leave the event in place — the draw case reads it.",
-    },
-    "checklist-admin-events-raffles-spin-raffle-create-top-n-scorers": {
-        roles: ["admin", "buyer"],
-        startPage: "/admin/events/new",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Create an event titled 'QA Event raffle-scorers' with the raffle type 'Top N scorers' — that exact dropdown label — N set to 3, and a prize.",
-            "Save, RELOAD, and read the raffle type and the N value.",
-            "Open the event's public page at /events/{its id} and read how the Overview tab describes who can win.",
-            "Swap identity before this step: this case lists admin among its roles, so the harness resolves the whole batch to the ADMIN session. Copy tester/.tester-runs/session-buyer.json over session.json and CLOSE THE BROWSER — the MCP reads it only at context creation. Then sign in as rehan.sheikh@gmail.com / TempPass123!, enter the event, and read the Leaderboard tab. Entering as the ADMIN would still populate a leaderboard, so this would pass while measuring the wrong account.",
-            "Read whether the leaderboard is ordered by score and whether the qualifying cut-off is stated.",
-        ],
-        inputs: { title: "QA Event raffle-scorers", raffleType: "top_n_scorers", topN: 3 },
-        expectedBehaviour: "A top-N-scorers raffle draws from the highest-scoring entries, so the leaderboard must rank by score and the public page must state how many qualify. Ranking by entry time instead silently changes who can win, and nothing errors.",
-        expectedUiState: "After the reload the type and N hold. The public Overview states the rule, and the Leaderboard is ordered by score with the cut-off named. A leaderboard ordered by entry time is the failure.",
-        endResult: "Delete the event after reading it.",
-    },
-    "checklist-admin-events-raffles-spin-raffle-create-top-n-participants": {
-        roles: ["admin", "buyer"],
-        startPage: "/admin/events/new",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Create an event titled 'QA Event raffle-participants' with the raffle type 'Top N earliest participants' — note the word 'earliest', which a tester scanning for 'Top N participants' would not match, N set to 3, and a prize.",
-            "Save, RELOAD, and read the raffle type and N.",
-            "Open the event's public page at /events/{its id} and read how the Overview tab describes who can win.",
-            "Compare that description against the scorers event's.",
-            "Enter as rehan.sheikh@gmail.com / TempPass123! and compare the two leaderboards' ordering.",
-        ],
-        inputs: { title: "QA Event raffle-participants", raffleType: "top_n_participants", topN: 3 },
-        expectedBehaviour: "This variant draws by participation rather than by score — a genuinely different rule from the scorers one. The two exist side by side precisely so the difference is checkable: identical leaderboards on both means the raffle type is not reaching the ranking.",
-        expectedUiState: "The type and N hold after the reload, and the Overview describes a different rule from the scorers event. The two leaderboards order differently. Identical ordering on both is the failure.",
-        endResult: "Delete the event after reading it.",
-    },
-    "checklist-admin-events-raffles-spin-raffle-draw-winner": {
-        roles: ["admin", "buyer"],
-        startPage: "/admin/events",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open 'QA Event raffle-open' in the admin editor and read the entry list and the 'Pool size' readout in the raffle panel.",
-            "Press 'Trigger Raffle Now'. A CONFIRMATION DIALOG must appear first — read it, then confirm.",
-            "Read the winner named and the pool size reported.",
-            "RELOAD and read the winner again.",
-            "Read whether the winner's name and entry are both recorded on the event.",
-            "Sign in as the winning buyer and open the notification bell; read the notification and follow its link.",
-            "Sign back in as admin, reopen the event, and read the button's label and enabled state. Then attempt a second draw.",
-        ],
-        expectedBehaviour: "The draw picks once with real randomness, records the winner on the event, and notifies them. A second draw must be refused — redrawing replaces a winner who has already been told they won, and the notification cannot be recalled. A pool size of 0 on an event that visibly has entries is itself the failure: it means the eligibility query and the entry writer disagree about which field marks an entry eligible.",
-        expectedUiState: "A confirmation dialog gates the draw. The winner is named and survives the reload. The event records both the winner and their entry. The buyer has one notification that deep-links to the event's winner page. On reopening, the button reads 'Already triggered' and is disabled; forcing a second draw is refused naming the existing winner, never with a generic failure.",
-        /*
-         * `drawsPermitted: 1` was already here and had never been exercised. The
-         * other three are the preconditions that made it unexercisable:
-         *   poolSizeNotZero       — the draw queried `status == "CONFIRMED"`, which
-         *                           nothing writes at entry time, so EVERY draw
-         *                           returned "no eligible entries"
-         *   winnerNotifications   — the winner was recorded and never told
-         *   confirmationDialogs   — an irreversible action with no confirmation
-         */
-        expectedData: {
-            drawsPermitted: 1,
-            poolSizeNotZero: true,
-            winnerNotifications: 1,
-            confirmationDialogs: 1,
-        },
-        endResult: "BEFORE: there was no confirmation dialog, the draw answered 'no eligible entries' on an event with entries (so no winner could ever be drawn), and on the rare path it did write a winner that person was never notified. AFTER: the dialog gates it, one winner is drawn and notified, and the second attempt is refused naming the existing winner. Delete the event afterwards. A second draw succeeding is the most serious failure on this page.",
-    },
-    "checklist-admin-events-raffles-spin-spin-wheel-create": {
-        roles: ["admin", "buyer"],
-        startPage: "/admin/events/new",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Create an event titled 'QA Event spin-create' of the spin-wheel type.",
-            "Define three prizes with labels and weights, set a maximum of 2 spins per user, and set a spin window covering today.",
-            "Save, RELOAD, and read every prize, weight, the maximum and the window.",
-            "Open the event's public page at /events/{its id} and read the wheel and its segments.",
-            "View SOURCE (or the network payload) for /events/{its id}/participate and search the response text for the string 'weight'. Then search it for 'couponId'.",
-        ],
-        inputs: { title: "QA Event spin-create", prizeCount: 3, maxPerUser: 2 },
-        expectedBehaviour: "Prizes, weights, the per-user maximum and the window all round-trip. Weights are the odds and belong server-side — a public wheel that renders them tells every visitor which segment is worthless.",
-        expectedUiState: "After the reload all four groups of settings hold. The public wheel shows three labelled segments.",
-        /*
-         * 🛑 The last step searches the PAYLOAD, not the rendered wheel, and that
-         * is the whole case.
-         *
-         * It previously read "check the wheel does NOT disclose their weights" —
-         * and the rendered wheel has never shown a weight, so a tester looked at
-         * three labelled segments and passed. Meanwhile the participate page cast
-         * the stored prize array straight into a client prop, so every weight AND
-         * every internal coupon document id was sitting in the RSC payload of a
-         * public page. The case asserted `weightsInPublicSource: 0` and could not
-         * see the thing it was counting.
-         */
-        expectedData: { weightsInPublicSource: 0, couponIdsInPublicSource: 0 },
-        endResult: "BEFORE: the payload contained 'weight: 15', 'weight: 25', 'weight: 10' and a 'couponId' for any prize carrying a coupon. AFTER: neither string appears anywhere in it, while the three labels still render. Leave the event in place — the limits case reads it.",
-    },
-    "checklist-admin-events-raffles-spin-spin-wheel-limits-enforced": {
-        roles: ["admin", "buyer"],
-        startPage: "/admin/events",
-        steps: [
-            "Sign in as rehan.sheikh@gmail.com / TempPass123! and open 'QA Event spin-create'.",
-            "Spin once and read the prize and the remaining count.",
-            "Spin a second time and read the remaining count.",
-            "Attempt a third spin and read the refusal WORD FOR WORD.",
-            "RELOAD the page and read the Spin button's state before clicking anything.",
-            "An event is reachable by two URL spellings — its SLUG and its DOCUMENT ID. Note which one you have been using, then open the OTHER one as the same account and attempt a spin.",
-            "Sign out and sign in as admin@letitrip.in / TempPass123!, then narrow the spin window so it is closed.",
-            "Sign back in as the buyer and attempt a spin, reading that refusal word for word too.",
-        ],
-        inputs: { maxPerUser: 2 },
-        expectedBehaviour: "The per-user cap and the window are both enforced server-side, the cap is scoped to the PERSON rather than to the URL spelling, and the two refusals read differently — 'no spins left' and 'the window is closed' are different facts and a single generic message tells the buyer neither.",
-        expectedUiState: "The third attempt is refused naming the limit. After the reload the button is already disabled with the spent state shown, without a round trip. The other URL spelling is refused identically. With the window closed the refusal names the window instead.",
-        /*
-         * Three invariants, each of which was broken in a different way:
-         *   spinsAfterReload       — the cap itself
-         *   spinsViaOtherUrlForm   — the guest/identity hash was scoped to the
-         *                            SLUG while enterEvent scoped it to the doc id,
-         *                            so the two URL spellings were two identities
-         *                            and the other one handed out a fresh allowance
-         *   distinctRefusalMessages — both refusals were the same sentence
-         */
-        expectedData: {
-            maxPerUser: 2,
-            spinsAfterReload: 0,
-            spinsViaOtherUrlForm: 0,
-            distinctRefusalMessages: 2,
-        },
-        endResult: "BEFORE: every refusal on this page read 'Spin failed. Please try again.', the button stayed enabled after a reload so the cap cost a round trip to discover, and the other URL spelling granted a fresh set of spins. AFTER: 'You've already used your spins for this event.' and 'The spin window isn't open right now.' are distinct, the button is pre-disabled, and both URL spellings share one allowance. Delete the event afterwards.",
-    },
-    "checklist-admin-events-raffles-spin-event-entries-admin-view": {
-        roles: ["admin"],
-        startPage: "/admin/events",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/events/event-favourite-blader-poll/entries — an ACTIVE poll carrying 3 seeded entries, so the table is not empty — and read every column.",
-            "Read every status filter offered and select each, noting any that returns nothing.",
-            "For each empty filter, check the unfiltered list for rows of that status.",
-            "Read the row actions offered and check at least one lets you VIEW an entry.",
-            "Use the search if one is offered, then search zzzznope and read the count.",
-            "Check whether buyer email addresses are shown in full.",
-        ],
-        inputs: { nonsenseQuery: "zzzznope" },
-        expectedBehaviour: "Entries are readable and filterable, and every status chip names a value entries actually hold. The entry document carries the participant's email, which is PII — how much of it this list exposes is worth recording rather than assuming.",
-        expectedUiState: "Every filter returns its own rows or is empty with none unfiltered either. A view affordance exists alongside the actions. 'zzzznope' returns none. Record exactly how buyer emails are displayed.",
-        expectedData: { nonsenseResultCount: 0 },
-        endResult: "Read-only; nothing persists beyond the URL.",
-    },
-    "checklist-admin-events-raffles-spin-event-entries-view-before-deciding": {
-        roles: ["admin"],
-        startPage: "/admin/events",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/events/event-favourite-blader-poll/entries. That is the poll, and it has 3 seeded entries; picking an event with none would leave nothing to read and is indistinguishable from a broken table.",
-            "Find a row offering Confirm, Waitlist or Cancel.",
-            "WITHOUT using any of those, look for a way to read the entry's actual content first.",
-            "Open the entry and read the participant's response in full.",
-            "Return to the list and check the same content is reachable from the row itself.",
-        ],
-        expectedBehaviour: "An admin can read an entry before deciding on it. A row offering Confirm, Waitlist and Cancel without showing what was submitted is a decision made blind — the same shape as approving a catalogue submission whose photos were never rendered, or confirming a bug report whose comment and screenshot are not on screen.",
-        expectedUiState: "The entry's response is readable from the list or from a detail view reachable from the row, before any action is taken. A row with only mutations is the failure, and it looks complete because the buttons work.",
-        endResult: "Read-only; take no action on any entry. Report whether the content was reachable WITHOUT deciding.",
-    },
-};

package/dist/features/tester/seed-data/authored/admin__firebase-function-effects.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__firebase-function-effects.js

@@ -1,249 +0,0 @@
-/*
- * WHY: Authored six-part procedures for the admin/firebase-function-effects page.
- * WHAT: 14 cases, keyed by full checklist id.
- *
- * 🛑 EVERY CASE HERE TESTS AN EFFECT, NEVER A FUNCTION.
- *
- * 53 Firebase functions are defined — 27 scheduled, 20 Firestore triggers, 6
- * HTTPS — and none had a checklist case. The reason is that the obvious way to
- * write one is untestable: "trigger the cron and confirm it ran" cannot be done
- * from a browser in a session, so every such case would be answered null
- * forever, which reads as coverage while providing none.
- *
- * 🛑 THOSE FOUR NUMBERS WERE 55 / 28 / 20 / 7 UNTIL 2026-09-29, and three of them
- * were wrong. Recounted from the registry itself:
- *
- *     grep -c "defineFunction(" appkit/src/_internal/server/functions/scheduled.ts
- *                                                                    firestore.ts
- *                                                                    https.ts
- *
- * CLAUDE.md warns that the scheduled figure has drifted four separate times and
- * says to recount rather than quote it; this file quoted it and drifted a fifth.
- * Recount before trusting any of them — including these.
- *
- * So each case instead reads the thing the function is RESPONSIBLE FOR. A nightly
- * reconciler is tested by recounting what it reconciles; a settlement job by
- * whether the winner can pay; a self-triggering write-back by whether its
- * timestamp moves when nothing changed. All answerable in seconds, all able to
- * fail.
- *
- * Three of these are written against real, recorded incidents and would have
- * caught them: #92 (a trigger that self-triggered 1,017,548 times in 24h),
- * #60 (a settlement that produced an order nobody could pay), #102 (a reconciler
- * that could not express what it reconciled).
- *
- * @tag domain:tester
- * @tag layer:seed
- * @tag pattern:none
- * @tag access:server-only
- * @tag consumers:seed-data/authored/index.ts
- * @tag sideEffects:none
- */
-const ADMIN = "Sign in as admin@letitrip.in / TempPass123!.";
-export const authored = {
-    "checklist-admin-firebase-function-effects-function-invocation-health-per-function": {
-        roles: ["admin"],
-        startPage: "/admin/maintenance",
-        steps: [
-            ADMIN,
-            "Open the Firebase console for this project and go to Functions.",
-            "Sort the function list by invocation count over the last 24 hours, highest first.",
-            "Write down the top entry's count and the count of the tenth entry.",
-            "Divide the first by the second.",
-        ],
-        expectedBehaviour: "No single function is running away from the rest. This is the case that would have caught Root Cause #92, where onShipmentHeaderWrite self-triggered 1,017,548 times in 24 hours against a 2,000,000/month free quota while every other function in the project sat between 0 and 95 — and the overage then blocked deploys and degraded production through the sibling Firestore read quota.",
-        expectedUiState: "The per-function breakdown is on screen, sorted. The top function's count is of the same order as the rest of the active ones. A ratio in the thousands is the finding, and the function's name is quoted.",
-        expectedData: { runawayFunctions: 0 },
-        endResult: "Read-only; nothing persists. 🛑 Read the PER-FUNCTION breakdown, never the aggregate — the aggregate never names the culprit, which is exactly why #92 was found from a billing page rather than from monitoring.",
-        requiresHumanChannel: true,
-        humanChannelReason: "The per-function invocation breakdown lives in the Firebase console, which needs an interactive Google sign-in the automated browser does not have. There is no in-product surface for it — /admin/maintenance/cloud-logs shows raw log lines, not per-function counts. A human runs this one; the automated answer is null, naming the console as the missing channel.",
-    },
-    "checklist-admin-firebase-function-effects-function-errors-page-has-no-producer": {
-        roles: ["admin"],
-        startPage: "/admin/maintenance/function-errors",
-        steps: [
-            ADMIN,
-            "Open /admin/maintenance/function-errors and read what it shows.",
-            "Open /admin/maintenance/server-errors in another tab and read what it shows.",
-            "Compare the two: note whether server-errors has rows while function-errors does not.",
-        ],
-        expectedBehaviour: "BEFORE: the page is expected to list Cloud Function failures. AFTER: it is empty, and it will remain empty no matter what breaks, because NOTHING IN PRODUCTION WRITES a serverErrors row with source \"function\". `wrapJobHandler` is the only thing that would, and as of 2026-09-29 it has NO CALL SITES AT ALL — it is defined, re-exported from the server barrel, and invoked nowhere. (This case used to say \"referenced solely by its own test\", which stopped being true when both test suites were deleted; the claim is now stronger, not weaker.) The sibling server-errors page has a real producer and should show rows, which is what makes the contrast legible.",
-        expectedUiState: "function-errors renders an empty list or empty state. server-errors renders actual rows. Screenshot both, side by side if possible.",
-        expectedData: { functionErrorRows: 0 },
-        endResult: "🛑 ANSWER NO. This case is authored to FAIL against today's product, and that is deliberate: a case reading \"check that errors appear here\" would pass vacuously against a surface that can never populate. A red case with a screenshot is a tracked defect; a note in a document is not.",
-    },
-    "checklist-admin-firebase-function-effects-https-function-401-is-healthy-500-is-not": {
-        roles: ["admin"],
-        startPage: "/admin/maintenance",
-        steps: [
-            ADMIN,
-            "Open the Firebase console's Functions list and copy the trigger URL of adminAnalytics.",
-            "Open that URL in a new tab with no auth header and read the status and body.",
-            "Repeat for storeAnalytics, promotionsApi, listingProcessor, triggerEventRaffle, assignSpinPrize and gateway.",
-            "Write down the status code each one returned.",
-        ],
-        expectedBehaviour: "Every one of the seven answers 401. A 401 means the module LOADED and the auth gate ran — that is healthy, and it is the expected answer, not a failure. A 500 means the module failed at cold start, which is how Root Cause #69 served 500 on every route while the build reported READY.",
-        expectedUiState: "Seven status codes are recorded. All are 401 (or 403). Any 500 is quoted with the function's name and whatever body it returned.",
-        expectedData: { httpsFunctions: 7, fiveHundreds: 0 },
-        endResult: "Read-only; nothing persists. 🛑 Do not record a 401 as a failure — that inversion is the single most likely way this case is answered wrongly.",
-    },
-    "checklist-admin-firebase-function-effects-counters-reconcile-effect-category-counts": {
-        roles: ["admin"],
-        startPage: "/categories",
-        steps: [
-            ADMIN,
-            "Open /categories and write down the product count shown for the root category Spinning Tops.",
-            "Open that category's own page and count the listings it actually shows, paging through if there is more than one page.",
-            "Do the same for one leaf category further down the tree.",
-            "Compare each displayed count against your recount.",
-        ],
-        expectedBehaviour: "The displayed count equals the recount, for both the root and the leaf. countersReconcile runs nightly and maintains two DIFFERENT numbers — metrics.productCount, the items filed directly under a row, and metrics.totalProductCount, that row plus every descendant. Root Cause 102: setMetrics took one pair of numbers and wrote it to both fields, so on any ancestor the row's own items were lost from its own rollup. 19 of 65 rows disagreed with a recount and every one was LOW.",
-        expectedUiState: "Two categories are recounted and both match. Any mismatch is reported with three numbers: the displayed count, the recount, and which category.",
-        endResult: "Read-only; nothing persists. A wrong number here never errors — it is simply a number — so the recount is the only thing that can detect it.",
-    },
-    "checklist-admin-firebase-function-effects-revenue-rollup-effect-dashboard-reads-one-doc": {
-        roles: ["admin"],
-        startPage: "/admin",
-        steps: [
-            ADMIN,
-            "Open /admin and read the revenue figures on the dashboard.",
-            "Open /admin/orders, filter to delivered orders, and note roughly how many there are and their rough total.",
-            "Compare the dashboard's figure against that rough total.",
-            "Reload /admin once and confirm the figure is the same and appears without a long delay.",
-        ],
-        expectedBehaviour: "The dashboard shows a plausible revenue figure derived from a pre-computed rollup rather than a live scan of every order. revenueRollup exists specifically so this page is a single-document read — that is the pattern protecting the 50,000/day Firestore read quota, and a dashboard that scans instead is how that quota gets spent.",
-        expectedUiState: "A revenue figure is present and is of the same order as the delivered orders suggest. Zero revenue while real delivered orders exist means the rollup did not run or wrote a shape the page cannot read.",
-        endResult: "Read-only; nothing persists.",
-    },
-    "checklist-admin-firebase-function-effects-auction-settlement-effect-winner-gets-payable-line": {
-        roles: ["admin"],
-        startPage: "/admin/products",
-        steps: [
-            ADMIN,
-            "Open /admin/products and filter to auctions, then find one that has already ended with bids on it.",
-            "Open it and note the winning bidder.",
-            "Open that winner's account view from /admin/users and look for what the win produced.",
-            "Establish whether the win left something the winner could actually pay for — a locked cart line reachable from checkout — or only a record that renders nowhere.",
-        ],
-        expectedBehaviour: "A settled auction leaves the winner a LOCKED cart line that reaches checkout through the auction lane. Root Cause #60: auctionSettlement used to write a document into the orders collection that was not an OrderDocument — flat productId/unitPrice fields instead of buyerId and items[], no paymentMethod, a Firestore auto-id instead of a semantic one. It rendered correctly in no orders list, no checkout accepted it, and the sweep that cleans up unpaid orders never saw it. There was no way, anywhere in the product, for a winner to pay.",
-        expectedUiState: "The win is visible to the winner as something actionable. If it appears only as a row that cannot be opened or paid, that is the finding, and the auction id is quoted.",
-        endResult: "Read-only — do not pay or cancel anything. The point is whether a payable path EXISTS, not whether it completes.",
-    },
-    "checklist-admin-firebase-function-effects-offer-expiry-effect-lapsed-offer-frees-the-cart": {
-        roles: ["admin"],
-        startPage: "/admin/offers",
-        steps: [
-            ADMIN,
-            "Open /admin/offers and find an offer whose status is expired, or one whose deadline has clearly passed.",
-            "Open it and note the buyer.",
-            "Open that buyer's cart from the admin user view, or sign in as them if the fixture allows.",
-            "Check whether a locked line for that offer is still sitting in their cart.",
-        ],
-        expectedBehaviour: "A lapsed offer is no longer actionable AND has left no locked line behind. runOfferExpiry sweeps three things in one pass — pending offers past expiresAt, ACCEPTED offers past checkoutDeadline, and unpaid auction wins. The third and second were added later than the first, and the function deliberately has no early return when the first query is empty, because the other two sweeps must still run.",
-        expectedUiState: "The offer reads as expired and the buyer's cart has no leftover locked line for it.",
-        expectedData: { leftoverLockedLines: 0 },
-        endResult: "Read-only; nothing persists. 🛑 A leftover locked line is worse than it looks: the offer lane OUTRANKS the standard lane, so it blocks the buyer's entire cart, not merely that one offer.",
-    },
-    "checklist-admin-firebase-function-effects-payment-window-timeout-effect-expired-proof-window": {
-        roles: ["admin"],
-        startPage: "/admin/orders",
-        steps: [
-            ADMIN,
-            "Open /admin/orders and filter to manual-payment orders awaiting payment.",
-            "Find one whose payment deadline has already passed.",
-            "Open it and read its status and its payment panel.",
-            "Note whether it has been resolved by a sweep or is still sitting pending with an expired deadline.",
-        ],
-        expectedBehaviour: "An order past its 15-minute payment window has been resolved rather than left pending indefinitely. paymentWindowTimeout and paymentReviewAutoApprove are the two sweeps that stop a manual payment stalling forever — one cancels an unpaid window, the other auto-approves an unreviewed proof after two hours.",
-        expectedUiState: "The order shows a resolved state consistent with its deadline having passed. An order still pending with a deadline hours in the past is the finding, with its id and its deadline quoted.",
-        endResult: "Read-only — do not verify or reject the payment yourself; that would destroy the evidence.",
-    },
-    "checklist-admin-firebase-function-effects-rtdb-event-channels-are-pruned": {
-        roles: ["admin"],
-        startPage: "/admin/maintenance",
-        steps: [
-            ADMIN,
-            "Open the Firebase console's Realtime Database for this project.",
-            "Look at the auth_events, payment_events and bulk_events nodes and note roughly how many children each holds.",
-            "Note the oldest timestamp you can see under each.",
-            "Compare that age against the prune interval each is supposed to have.",
-        ],
-        expectedBehaviour: "The signal channels are being pruned rather than accumulating. cleanupRtdbEvents prunes auth_events at 3 minutes and payment_events and bulk_events at 15, and email_events at 1 hour. The email channel is deliberately the longest: a batch can take ten minutes between triggering a send and asserting on it, and a ping deleted mid-batch reads as \"no email was sent\" — a false negative in exactly the mechanism meant to prevent one.",
-        expectedUiState: "Each channel holds only recent children. A node holding entries hours or days old means the prune is not running for it, and that node's name is quoted.",
-        endResult: "Read-only — do not delete anything by hand. Note that auction-bids is deliberately NOT pruned and is not part of this case.",
-    },
-    "checklist-admin-firebase-function-effects-media-tmp-cleanup-effect-aborted-uploads-removed": {
-        roles: ["admin"],
-        startPage: "/admin/media",
-        steps: [
-            ADMIN,
-            "Open /admin/media and begin uploading an image.",
-            "Abandon the upload before it finalises — close the dialog or navigate away mid-upload.",
-            "Return to /admin/media and look for the abandoned file.",
-            "Reload once and look again.",
-        ],
-        expectedBehaviour: "An abandoned upload does not appear as a real, usable asset. Bytes land under a tmp/ prefix and are moved to a permanent path only by finalize; mediaTmpCleanup removes whatever never finalised. An un-finalised object showing up in the media library is the finding, because it can then be attached to a listing and will later vanish.",
-        expectedUiState: "The media library shows no entry for the abandoned upload, either immediately or after the reload.",
-        endResult: "If a stray entry was created, note its name so it can be cleaned up; do not leave it attached to any listing.",
-    },
-    "checklist-admin-firebase-function-effects-product-write-trigger-effect-stock-and-groups": {
-        roles: ["admin"],
-        startPage: "/admin/products",
-        steps: [
-            ADMIN,
-            "Open /admin/grouped-listings and pick a group, noting its member count and how many members it says are active.",
-            "Note one member product's id.",
-            "Open that product in /admin/products and set its stock quantity to 0, then save.",
-            "Return to /admin/grouped-listings and reload, then read the same group's active member count.",
-            "Set the product's stock back to its original value and confirm the count returns.",
-        ],
-        expectedBehaviour: "Changing one product's stock updates the derived state on the OTHER records that depend on it, without anyone editing them. onProductWrite / onProductStockChange recompute a grouped listing's activeMemberCount and visibilityStatus and keep bundles in sync. The effect is visible on the group, never on the product you edited — which is why a case that only re-reads the product would pass against a broken trigger.",
-        expectedUiState: "The group's active member count drops by one after the stock change and returns after it is restored. A count that never moves is the finding.",
-        endResult: "🛑 RESTORE THE STOCK. Leaving a seeded product at zero silently removes it from every public listing for every later case.",
-    },
-    "checklist-admin-firebase-function-effects-order-create-trigger-effect-staff-signal": {
-        roles: ["admin"],
-        startPage: "/admin/orders",
-        steps: [
-            ADMIN,
-            "Open /admin/orders and note the most recent order's id and the time it was created.",
-            "Open /admin/admin-notifications — the staff inbox, which is a different page from /admin/notifications, the per-user notification list — and look for a signal corresponding to that order.",
-            "Note whether the signal exists, and whether there is exactly one rather than one per employee.",
-        ],
-        expectedBehaviour: "A new order leaves something an operator can notice, as ONE durable staff-visible record rather than a personal notification fanned out to every employee. The fan-out shape is what nearly exhausted a 100/day email allowance from a single event, so one row read by the admin inbox and counted by the daily digest is the correct shape.",
-        expectedUiState: "A staff-visible signal exists for the recent order. If several identical signals exist, one per employee, that is a finding in its own right.",
-        endResult: "Read-only; nothing persists.",
-    },
-    "checklist-admin-firebase-function-effects-shipment-trigger-no-op-guard-holds": {
-        roles: ["admin"],
-        startPage: "/admin/shipments",
-        steps: [
-            ADMIN,
-            "Open /admin/shipments and open one shipment.",
-            "Note its computed totals and the timestamp showing when those totals were last computed.",
-            "Press Save without changing any field.",
-            "Reload the shipment and read that timestamp again.",
-            "Press Save unchanged a second time, reload, and read it once more.",
-        ],
-        expectedBehaviour: "Saving an unchanged shipment does NOT recompute its totals — the timestamp is identical all three times. This is Root Cause #92's exact mechanism: onShipmentHeaderWrite watches the collection it writes back to, and its only brake is a no-op guard. That guard compared with JSON.stringify, which is key-order sensitive, while Firestore returns map fields alphabetically and the code built them in construction order. The two strings could never match, so every write re-triggered — 1,017,548 invocations in 24 hours, which then blocked deploys and degraded production.",
-        expectedUiState: "The totals-computed timestamp is byte-identical across all three readings. Any movement on an unchanged save means the guard is not holding, and that is a billing incident, not a cosmetic one.",
-        expectedData: { timestampMovementsOnUnchangedSave: 0 },
-        endResult: "No field is changed. 🛑 If the timestamp DOES move, stop and report immediately rather than saving again — each save is another round of the loop.",
-    },
-    "checklist-admin-firebase-function-effects-scheduled-job-count-matches-registry": {
-        roles: ["admin"],
-        startPage: "/admin/maintenance",
-        steps: [
-            ADMIN,
-            "Open the Google Cloud console's Cloud Scheduler page for this project.",
-            "Count the jobs listed and write the number down.",
-            "Open the Firebase console's Functions list and count the entries with a scheduled trigger.",
-            "Compare the two numbers.",
-        ],
-        expectedBehaviour: "The two counts match. Scheduler bills per REGISTERED job rather than per invocation, so a job with no matching function is paid for and dead, and a scheduled function with no job simply never runs — and nothing in the product reports either.",
-        expectedUiState: "Two counts are written down and are equal. If they differ, name the jobs or functions that appear on only one side.",
-        endResult: "Read-only; nothing persists. 🛑 RECOUNT rather than quoting a remembered number — this figure has drifted five separate times now, including once inside this very file, which is exactly why the case asks for a count instead of stating one. As of 2026-09-29 the registry defines 27 scheduled functions; if Scheduler shows a different number, the difference is the finding.",
-        requiresHumanChannel: true,
-        humanChannelReason: "Both counts are read from Google consoles — Cloud Scheduler and the Firebase Functions list — which need an interactive Google sign-in the automated browser does not have. The registry side can be counted from source, but the billed side cannot, and the whole case is the comparison. A human runs this one.",
-    },
-};

package/dist/features/tester/seed-data/authored/admin__media-watermark.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__media-watermark.js

@@ -1,148 +0,0 @@
-/*
- * WHY: Authored six-part procedures for the admin/media-watermark page.
- * WHAT: 5 case(s), keyed by full checklist id.
- *
- * Written by hand, case by case, against the label each one states. There is no
- * generator: the authoring scripts were deleted once it was clear they were
- * scaffolding around work that is simply writing.
- *
- * 🛑 THE WATERMARK HAS A FOUR-TIER FALLBACK and never simply skips: an admin image
- * override, then the bundled brand mark, then the wordmark, then plain text. So an
- * image with NO mark at all does not mean the watermark is off — it means that
- * image was not served through the proxy, which is a different and larger finding.
- *
- * Video is the exception, and deliberately so: it cannot be composited server-side
- * within the platform's compute budget, so the mark is a client overlay and its
- * settings have to reach a second consumer.
- *
- * 🛑 …AND THAT SECOND CONSUMER IS NOT ON THE PRODUCT PAGE (found 2026-09-29).
- * `<MediaVideo>`, which owns the overlay, is mounted in exactly three places:
- * `HeroCarousel` and the two admin upload previews. A product video plays in
- * `ImageLightbox`, which renders a bare `<video controls>` — no overlay layer at
- * all. So the poster frame is watermarked (it is a still, proxied like any
- * image) and the playing video is not. The parity case now expects that and
- * names the homepage hero as the surface where the overlay does apply.
- *
- * The watermark tab is on /admin/site → 'Watermark'. Its real controls:
- * a 'Watermark type' select (Text | Image), 'Watermark text' or a
- * 'Watermark image' upload, a `Size — N% of image width` slider (5-100 step 5),
- * an `Opacity — N%` slider (5-100 step 5), a 'Position' select, and a
- * 'Use a custom X/Y offset instead' toggle revealing two labelled offset
- * inputs measured in percent FROM CENTER (+right/+down).
- *
- * 🛑 THEME RECOLOUR READS `defaultLightThemeId` AND NOTHING ELSE.
- * `resolveThemeGradientStops` looks up the theme record named by
- * `theme.defaultLightThemeId` (falling back to "default-light") and takes its
- * `--appkit-gradient-logo` stops. Changing the DARK default, or a viewer's own
- * mode, does not move the composited mark's colour — so the case must change
- * the default LIGHT theme or it will report a failure that is really a
- * mis-aimed step.
- *
- * @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-media-watermark-watermark-size-opacity-controls": {
-        roles: ["admin", "guest"],
-        startPage: "/admin/site",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/site, go to its 'Watermark' tab, and write down the current values of the `Size — N% of image width` and `Opacity — N%` sliders.",
-            "Sign out and open /products/product-beyblade-burst-valkyrie, then open its main image and note how the mark looks.",
-            "Sign back in and set Size to 100 and Opacity to 100, then save.",
-            "Sign out, reload that product image with a HARD reload, and compare.",
-            "Sign back in, restore both sliders to the values written down in step 2, save, and reload the image again.",
-        ],
-        inputs: {
-            product: "product-beyblade-burst-valkyrie",
-            sizeAfter: 100,
-            opacityAfter: 100,
-            sliderStep: 5,
-        },
-        expectedBehaviour: "Size and opacity reach the served image. The mark is composited server-side as the image is proxied, so a setting that saves without changing the output means the render path is not reading it — and because images are cached aggressively, a hard reload may be needed before concluding either way.",
-        expectedUiState: "The mark is visibly larger and more opaque after the change, and back to its original appearance after the restore. Both sliders move in steps of 5 between 5 and 100, so a value typed outside that range is not reachable and is not a finding. A settings page that saves with no visible effect on the served image IS the failure.",
-        endResult: "Both settings are restored. Note whether a hard reload was required — that is cache behaviour rather than a defect, but it changes how the next tester reads this page.",
-    },
-    "checklist-admin-media-watermark-watermark-position-presets": {
-        roles: ["admin", "guest"],
-        startPage: "/admin/site",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/site → 'Watermark' and read every option in the 'Position' select, writing down which is currently set.",
-            "Select each preset in turn — the four corners and center — saving after each. Leave 'custom' to the offset case.",
-            "After each save, sign out and open /products/product-beyblade-burst-valkyrie's main image, noting where the mark sits.",
-            "Repeat one corner preset against a portrait image and a landscape one.",
-            "Restore the preset written down in step 2.",
-        ],
-        inputs: { product: "product-beyblade-burst-valkyrie" },
-        expectedBehaviour: "Every preset places the mark somewhere different and every one keeps it inside the frame. A corner preset that pushes part of the mark off the edge is the likely failure, since the offset is computed from the image's dimensions and a portrait image behaves differently from a landscape one.",
-        expectedUiState: "Each preset moves the mark to its named position and the whole mark remains visible within the image at all of them. Test at least one portrait and one landscape image — a preset correct on one aspect and clipped on the other is the finding.",
-        endResult: "The original preset is restored.",
-    },
-    "checklist-admin-media-watermark-watermark-custom-offset": {
-        roles: ["admin", "guest"],
-        startPage: "/admin/site",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/site → 'Watermark' and write down the current Position and any offsets.",
-            "Turn on 'Use a custom X/Y offset instead' and read the two inputs it reveals — 'X offset (%) — + right / − left of center' and 'Y offset (%) — + down / − up from center'.",
-            "Set X to 10 and Y to 10, save, sign out, and read /products/product-beyblade-burst-valkyrie's main image.",
-            "Sign back in, set X to 100 and Y to 100 — far enough to push the mark past the edge — save, sign out, and read the image again.",
-            "Read whether the mark is clipped, gone entirely, or clamped so it stays fully inside the frame.",
-            "Sign back in and restore the Position and offsets written down in step 2.",
-        ],
-        inputs: {
-            product: "product-beyblade-burst-valkyrie",
-            modestOffset: 10,
-            extremeOffset: 100,
-        },
-        expectedBehaviour: "A custom offset moves the mark, and an offset that would push it out of frame is clamped rather than obeyed. Obeying it produces images with no visible watermark at all — which is indistinguishable from the proxy being bypassed and would mask a much larger problem.",
-        expectedUiState: "The modest offset moves the mark by the amount set. The extreme offset leaves the mark still visible, clamped flush to the frame, rather than pushing it off the image. A silently unwatermarked image is the failure. This is expected to PASS — the offset is clamped twice, once when the setting is read and again when the overlay is placed — so a clipped mark here would mean one of those clamps stopped running.",
-        endResult: "The original offset is restored.",
-    },
-    "checklist-admin-media-watermark-watermark-theme-recolor": {
-        roles: ["admin", "guest"],
-        startPage: "/admin/site",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/site → 'Watermark' and confirm 'Watermark type' has no uploaded 'Watermark image' override — with none set the mark falls through to the bundled brand glyph, which is the only tier the theme can recolour.",
-            "Sign out, open /products/product-beyblade-burst-valkyrie's main image, and note the mark's colour.",
-            "Sign back in, open the 'Themes' tab, and write down which theme is set as the DEFAULT LIGHT theme.",
-            "Change the default LIGHT theme to one with different brand colours and save. Changing the dark default will not move the mark — the resolver reads the light one only.",
-            "Sign out, hard-reload the product image, and compare the mark's colour.",
-            "Compare a dark product photo and a light one and check the mark is legible on both.",
-            "Sign back in and restore the default light theme written down in step 4.",
-        ],
-        inputs: { product: "product-beyblade-burst-valkyrie", themeSetting: "defaultLightThemeId" },
-        expectedBehaviour: "With no image override the mark falls through to the bundled brand glyph, whose gradient stops come from theme colour tokens — so changing the theme recolours it without a second asset. It must stay legible over both dark and light photographs, which is the part a colour change can quietly break.",
-        expectedUiState: "The mark's colour follows the DEFAULT LIGHT theme's logo gradient. It remains legible on both a dark and a light product photo after the change. A mark that vanishes into one of the two is the finding. A mark that does not change at all is only a finding if the default LIGHT theme was the one changed — say which you changed.",
-        endResult: "The original theme is restored.",
-    },
-    "checklist-admin-media-watermark-watermark-video-overlay-parity": {
-        roles: ["admin", "guest"],
-        startPage: "/admin/site",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/site → 'Watermark' and write down the size, opacity and position.",
-            "Sign out and open /products/product-beyblade-burst-spryzen-video-demo.",
-            "Look at the video's POSTER frame in the gallery strip and note whether it carries the mark.",
-            "Click it to open the lightbox, play the video, and look for the mark while it is playing.",
-            "Compare that against a still image on the same page.",
-            "Now open / and find the 'Live auctions' hero slide, whose background is a video, and look for the mark on it while it plays.",
-            "Sign back in, change the watermark position, save, sign out, and check which of the three — the poster, the product video, the hero video — followed.",
-            "Restore the position.",
-        ],
-        inputs: {
-            product: "product-beyblade-burst-spryzen-video-demo",
-            heroSlide: "Live auctions",
-        },
-        expectedBehaviour: "A still goes through the proxy and is composited server-side. A video cannot be, within the platform's compute budget, so its mark has to be a client overlay reading the same settings — two consumers, one configuration. The case is whether every surface that plays a video has that second consumer.",
-        expectedUiState: "The poster frame carries the mark, and follows a position change.\n\n🛑 EXPECT THE PRODUCT VIDEO TO CARRY NO MARK, AND RECORD IT AS A FAILURE. The overlay lives in `<MediaVideo>`, which is mounted only by the homepage hero carousel and the two admin upload previews; a product video plays in the lightbox, which renders a bare `<video controls>` with no overlay layer. So expect: poster marked, product video unmarked, hero video marked. Report which of the three followed the position change — that comparison is the finding, and a bare 'the video has no watermark' does not distinguish a missing overlay from a broken one.",
-        expectedData: { posterMarked: true, productVideoMarked: false, heroVideoMarked: true },
-        endResult: "The position is restored. Parity between the paths is the case — a mark on the poster alone proves nothing about the frames a buyer actually watches.",
-    },
-};

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

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