@mohasinac/appkit 4.35.4 → 4.37.0

package/dist/features/tester/seed-data/tester-checklist-seed-data.js

@@ -62,6 +62,25 @@ function group(groupKey, groupLabel, pages, opts) {
                 expectedUiState: c.expectedUiState ?? authored?.expectedUiState,
                 expectedData: c.expectedData ?? authored?.expectedData,
                 endResult: c.endResult ?? authored?.endResult,
+                /*
+                 * 🛑 This mapping is HAND-PICKED, so a field the overlay carries but
+                 * nobody lists here dies right at this line — Root Cause #38, which the
+                 * header of this very file warns about.
+                 *
+                 * `needsReview`/`reviewNote` were exactly that, from the day they were
+                 * added until 2026-09-13: `fetch-cases.mjs` reads them off the Firestore
+                 * item, SKILL.md documents them, and `record-verdicts.mjs` renders
+                 * "the case's own author flagged it for review" in the report — but
+                 * nothing ever put them ON the document, so the flag was permanently
+                 * false and that report line had never printed once. Four hops correct,
+                 * one hop missing, no error anywhere.
+                 *
+                 * When adding a field to AuthoredCase, add it HERE in the same commit.
+                 */
+                needsReview: c.needsReview ?? authored?.needsReview,
+                reviewNote: c.reviewNote ?? authored?.reviewNote,
+                requiresHumanChannel: c.requiresHumanChannel ?? authored?.requiresHumanChannel,
+                humanChannelReason: c.humanChannelReason ?? authored?.humanChannelReason,
                 // Every case gets a link: its own href, or the page's default —
                 // guarantees "Go test this ->" always has somewhere real to send
                 // the tester, even for cases nobody bothered to link individually.
@@ -2107,12 +2126,24 @@ const rawTesterChecklistItems = [
                     description: "Fixed 2026-08-21 — a fresh upload can briefly 404 while the Firestore doc and Storage object finish propagating; the thumbnail now retries with backoff instead of latching a permanent broken-image placeholder. Try uploading 2-3 images back-to-back on a slower connection to see the retry in action.",
                     href: "/store/products/new",
                 },
-                {
-                    key: "media-upload-images-capped-at-5",
-                    label: "The product gallery upload UI caps at 5 images (not 10) and its label reads \"up to 5\"",
-                    description: "Fixed 2026-08-21 — the UI previously advertised/allowed up to 10 images while the server schema only ever accepted 5, so a 6th+ image silently failed validation with no clear reason.",
-                    href: "/store/products/new",
-                },
+                /*
+                 * REMOVED 2026-09-11 — `media-upload-images-capped-at-5`.
+                 *
+                 * It asserted the gallery caps at "5 images (not 10)". The cap was
+                 * raised to 10 (`PRODUCT_MAX_IMAGES`, shared/media/limits.ts:37) and the
+                 * `selling/media-limits` page asserts the opposite in its own label:
+                 * "The 10th gallery image uploads — the 5th used to fail with a 400".
+                 *
+                 * So this case documented the OLD behaviour as the expectation. It
+                 * would fail against correct code, and anyone "fixing" the product to
+                 * satisfy it would re-break ten-image support. Its id encoded the wrong
+                 * number too, so correcting the label alone would still mislead.
+                 *
+                 * The invariant it really tested — the stated limit equals the enforced
+                 * limit — survives in `media-eleventh-image-refused-client-side`, which
+                 * requires the refusal to name the limit ("You can upload up to 10
+                 * images."). Nothing was lost.
+                 */
                 {
                     key: "media-upload-video-duration",
                     label: "Attaching a directly-uploaded video file during listing captures its duration automatically and saves without a validation error; attaching a YouTube or external video URL also saves fine without needing a duration",
@@ -2605,6 +2636,80 @@ const rawTesterChecklistItems = [
                 },
             ],
         },
+        {
+            pageKey: "product-upload-details",
+            pageLabel: "Product media — crop, refusals, ordering and the video path",
+            href: "/store/products/new",
+            cases: [
+                {
+                    key: "main-image-crop-applies",
+                    label: "The main-image crop is applied to what gets UPLOADED, not just previewed",
+                    description: "BEFORE: a cropper that shows a selection and stores the original is worse than none — the seller believes they framed the photo and the marketplace shows something else. AFTER: crop to the left half, confirm, and the stored thumbnail shows the left half.",
+                },
+                {
+                    key: "oversize-image-refused-client-side",
+                    label: "An image over 10 MB is refused BEFORE any bytes leave the browser",
+                    description: "BEFORE: a 12 MB upload that travels, finalises and then fails validation has taken a minute to say what the form knew when the file was picked. AFTER: immediate refusal reading the size limit, and no /api/media/sign request at all.",
+                },
+                {
+                    key: "disallowed-type-refused",
+                    label: "An SVG is refused, and the field still works immediately afterwards",
+                    description: "SVG is outside the allowed image types on purpose — a document format that can carry script, served from our own origin. Refusing one file must not wedge the control: the next PNG has to upload without a reload.",
+                },
+                {
+                    key: "gallery-order-persists",
+                    label: "Re-ordering gallery images survives Publish and re-opening the editor",
+                    description: "Gallery order is the seller decision about which angle a buyer sees second, so it is stored rather than merely displayed. Order that holds in the form and resets on reload means the array is rebuilt from upload time instead of from the arrangement.",
+                },
+                {
+                    key: "main-image-does-not-collide-with-gallery",
+                    label: "The main image and the first gallery image do not overwrite each other",
+                    description: "Filenames are content-derived with no timestamp, so two uploads computing the same index write the same storage path and the second silently replaces the first — the seller watches one of their two pictures vanish. Main image is index 1; the gallery starts at 2.",
+                },
+                {
+                    key: "video-upload-succeeds",
+                    label: "A video uploaded from the dedicated video panel saves and plays",
+                    description: "BEFORE: /api/media/sign returned 500 because the panel omitted the category from the upload context and the filename generator threw on it — every seller video upload from this panel failed while the gallery path worked. AFTER: sign returns 200, a poster frame and duration appear, and the published page plays it.",
+                },
+            ],
+        },
+        {
+            pageKey: "quick-add-minimum-details",
+            pageLabel: "Quick add — the short form, and what WhatsApp shows",
+            href: "/store/products/new",
+            cases: [
+                {
+                    key: "quick-form-is-the-default",
+                    label: "Creating an ordinary product opens the SHORT form, with the full form one click away",
+                    description: "Most listings need six fields and the sectioned form asks for thirty. /store/products/new opens Quick add; Show all fields (advanced) reaches the rest. Non-standard types open the sectioned form directly because they carry fields the short form has no room for.",
+                },
+                {
+                    key: "publish-with-the-minimum",
+                    label: "The short form alone can publish a real, buyable listing",
+                    description: "If it cannot, it is a decoy: the seller fills it, is refused, and has to learn the long form anyway — having done the work twice.",
+                },
+                {
+                    key: "whatsapp-shows-the-same-fields",
+                    label: "Everything WhatsApp shows was already asked for by the short form",
+                    description: "The catalog push sends title, price, image, condition and stock. That is the quick form field set, which is why the short form is the right shape — a seller who fills only it has supplied everything a WhatsApp buyer will see.",
+                },
+                {
+                    key: "advanced-flip-keeps-values",
+                    label: "Switching to the full form keeps everything already typed",
+                    description: "Losing values on the way to the full form punishes the seller for outgrowing the short one, and teaches them to start with the long form every time — which defeats the point of having a short one.",
+                },
+                {
+                    key: "condition-options-are-all-saveable",
+                    label: "Every Condition option the form offers can actually be saved",
+                    description: "BEFORE: the dropdown lists Like New, Good and Fair while the server accepts only new/used/refurbished/broken, so picking the option that honestly describes the item is refused with nothing on screen saying which options are real. AFTER: every listed option publishes.",
+                },
+                {
+                    key: "description-requirement-is-honest",
+                    label: "The Description field label agrees with what the save actually requires",
+                    description: "BEFORE: the field reads Brief description (optional) and is never validated client-side, while the server demands 20+ characters — so a field marked optional is refused after the seller commits, as a toast, with no error on the field. AFTER: label and behaviour agree and a short entry is caught inline.",
+                },
+            ],
+        },
         {
             pageKey: "media-limits",
             pageLabel: "Media \u2014 ten images and one video, on every listing type",

package/dist/features/tester/seed-data/tester-responses-seed-data.d.ts

@@ -0,0 +1,2 @@
+import type { TesterChecklistResponseDocument } from "../schemas/firestore";
+export declare const testerResponsesSeedData: Partial<TesterChecklistResponseDocument>[];

package/dist/features/tester/seed-data/tester-responses-seed-data.js

@@ -0,0 +1,95 @@
+/*
+ * WHY: Three `admin/bug-hunter-rewards` cases need a tester submission that
+ *      ALREADY EXISTS before the tester arrives — you cannot test "confirm this
+ *      reported bug" or "reopen this confirmed case" against an empty inbox.
+ *
+ *      `testerChecklistResponses` is DERIVED tier, so a run wipes it at setup
+ *      and on a fresh project there are genuinely zero submissions. That is
+ *      correct — stale verdicts from a previous run must not leak into the next
+ *      one — but it left those three cases permanently unrunnable. Measured
+ *      2026-09-11: 0 pass / 0 fail / 5 blocked on that page, with both
+ *      calibration controls answered correctly, so the batch was trustworthy and
+ *      the emptiness was real.
+ *
+ *      The fix is NOT to stop wiping the collection. It is to restore these
+ *      fixtures after the wipe — `SEED_TRANSACTIONAL` in
+ *      tester/scripts/lib/collections.mjs is a RESTORE list, orthogonal to the
+ *      delete tiers, so a collection can be both wiped and re-seeded.
+ *
+ * WHAT: Two response documents against the two demo-fixture checklist items that
+ *       already live in the catalogue.
+ *
+ * 🛑 THE DOC ID IS DETERMINISTIC: `${testerId}__${checklistItemId}`.
+ *    That is the same id the live answer path computes, and it is what makes an
+ *    answer an UPSERT rather than a duplicate — `set({merge:true})`, never
+ *    `add()`. Generating a random id here would (a) create a second, competing
+ *    response for the same (tester, case) pair the moment a real tester answers,
+ *    and (b) break idempotency, so every `appkit-seed load` would pile up
+ *    another copy — Root Cause #25 exactly.
+ *
+ * @tag domain:tester
+ * @tag layer:seed
+ * @tag access:server-only
+ * @tag consumers:appkit/scripts/seed-cli.mjs, seed/manifest.ts
+ * @tag sideEffects:none
+ */
+/** The seeded QA persona that the demo fixtures credit as "Mock User 18". */
+const TESTER_ID = "user-tester-qa";
+const TESTER_NAME = "Mock User 18";
+/** Same shape the answer route computes — see the callout above. */
+const responseId = (testerId, checklistItemId) => `${testerId}__${checklistItemId}`;
+const DEMO_V1 = "checklist-admin-bug-hunter-rewards-demo-fixture";
+const DEMO_V2 = "checklist-admin-bug-hunter-rewards-demo-fixture-v2";
+const seededAt = new Date("2026-08-18T09:30:00.000Z");
+export const testerResponsesSeedData = [
+    /*
+     * The ALREADY-CONFIRMED submission. The v1 catalogue item carries
+     * bugConfirmed:true / bugHunterId:"user-tester-qa" / bugHunterName:"Mock User
+     * 18", and until now there was no response row behind that credit — so
+     * /admin/tester-feedback showed "No feedback submitted yet" while the
+     * leaderboard showed a confirmed bug. This is the missing half.
+     *
+     * Backs: confirm-bug-idempotent (needs a row that is already confirmed) and
+     * reopen-case (needs the v1 credit to be visible from a real submission).
+     *
+     * `status: "reviewed"` because an admin has already acted on it.
+     */
+    {
+        id: responseId(TESTER_ID, DEMO_V1),
+        testerId: TESTER_ID,
+        testerDisplayName: TESTER_NAME,
+        checklistItemId: DEMO_V1,
+        groupKey: "admin",
+        pageKey: "bug-hunter-rewards",
+        phase: 1,
+        answer: "no",
+        comment: "Seed fixture — the reported bug behind the v1 demo case. Already confirmed and credited, then reopened as v2. Exists so an admin can see what a confirmed submission looks like without waiting for a real tester to file one.",
+        status: "reviewed",
+        createdAt: seededAt,
+        updatedAt: seededAt,
+    },
+    /*
+     * The UNCONFIRMED submission, against the active v2 retest. This is the row
+     * "Mark as Bug" is meant to be tried on end-to-end.
+     *
+     * 🛑 status MUST stay "new" and the case MUST stay un-confirmed, or the
+     * confirm-bug case has nothing left to do — it would open an already-confirmed
+     * row and correctly report that it could not perform its own steps. A fixture
+     * that pre-completes the thing under test is worse than no fixture, because it
+     * looks like coverage.
+     */
+    {
+        id: responseId(TESTER_ID, DEMO_V2),
+        testerId: TESTER_ID,
+        testerDisplayName: TESTER_NAME,
+        checklistItemId: DEMO_V2,
+        groupKey: "admin",
+        pageKey: "bug-hunter-rewards",
+        phase: 1,
+        answer: "no",
+        comment: "Seed fixture — a fresh 'No' on the reopened v2 case, deliberately NOT yet confirmed. This is the row to try Mark as Bug against.",
+        status: "new",
+        createdAt: seededAt,
+        updatedAt: seededAt,
+    },
+];

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mohasinac/appkit",
-  "version": "4.35.4",
+  "version": "4.37.0",
   "license": "MIT",
   "publishConfig": {
     "access": "public"