@mohasinac/appkit 4.58.0 → 4.59.0

package/dist/features/tester/seed-data/authored/community-support__messages.js

@@ -1,200 +0,0 @@
-/*
- * WHY: Authored six-part procedures for the D9 chat pages (/messages).
- * WHAT: 10 case(s), keyed by full checklist id.
- *
- * 🛑 CHAT IS OFF BY DEFAULT AND `undefined` READS AS OFF.
- *
- * `siteSettings.chat.enabled` gates every write path server-side
- * (`assertChatEnabled`) AND the nav icon AND the Message Seller button. So the
- * FIRST case here turns it on, and every case after it depends on that having
- * happened — which is deliberate: the off-state behaviour is itself a case
- * worth having, because "the feature silently half-works when disabled" is the
- * shape the original chat feature died of.
- *
- * 🛑 AND IT IS A REAL SETTING, NOT A FIXTURE. The seed does not write it, so a
- * fresh run starts with chat OFF. A case that assumes the icon is present
- * without having turned it on is testing the wrong state and will answer `no`
- * for a reason that is not a defect.
- *
- * 🛑 THE OLD FEATURE'S TWO BUGS ARE THE TWO MOST VALUABLE CASES HERE, and
- * neither is visible from the UI alone:
- *
- *   1. `useConversation`/`useConversations` never called `signInWithToken`, so
- *      every RTDB rule evaluated false and the live channel was permission-
- *      denied — swallowed into `setIsConnected(false)` and a literal
- *      `// ignore`. The channel LOOKED implemented and was inert. Case
- *      `live-ping-surfaces-failure` is the control: the error must be VISIBLE.
- *   2. `listByBuyer`/`listByStore` had no `.limit()`, and every message wrote
- *      2–3 pings each triggering an unpaginated refetch for both participants.
- *      Twenty messages ≈ 1,600 reads. Case `inbox-read-is-bounded` is the
- *      negative control the plan names explicitly.
- *
- * 🛑 TWO ACCOUNTS ARE REQUIRED and both are seeded: admin@letitrip.in (admin)
- * and the owner of store-beyblade-arena, user-tyson-blader. A conversation is
- * between two DIFFERENT users and the server refuses a self-conversation, so a
- * single-account run cannot exercise anything past case 2.
- *
- * audit-tester-created-id: the conversation id is generated by Firestore and is
- * therefore not knowable in advance — every case that needs it says to read it
- * off the URL after the Message Seller button navigates, which is the only
- * honest instruction. It is not a seed fixture and must not become one: the
- * point is to exercise the create path.
- *
- * @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-community-support-messages-chat-off-hides-everything": {
-        roles: ["admin", "buyer", "guest"],
-        startPage: "/admin/site",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/site and confirm the Chat toggle is OFF (its stored value is absent on a fresh seed, which reads as off).",
-            "Open /products/product-beyblade-burst-valkyrie and look at the 'Sold by' card.",
-            "Look at the header icon row, between the notification bell and the wishlist heart.",
-            "Navigate directly to /messages.",
-        ],
-        expectedBehaviour: "With chat off, nothing chat-related renders anywhere: no Message Seller button on the store card, no Messages icon in the header, and no /api/messages/unread-count request fires at all (the hook is gated on the setting, not merely rendered-and-empty). /messages itself still resolves — it is a real route — and shows the signed-out or empty state rather than 404ing.",
-        expectedUiState: "The 'Sold by' card shows ONLY 'Visit Store →'. The header icon row has no speech-bubble icon. /messages renders its own chrome with no conversation rows.",
-        endResult: "Nothing persists; this is the baseline state. Reload and the three absences hold.",
-    },
-    "checklist-community-support-messages-enable-chat-reveals-entry-points": {
-        roles: ["admin", "buyer"],
-        startPage: "/admin/site",
-        steps: [
-            "Sign in as admin@letitrip.in / TempPass123!.",
-            "Open /admin/site, turn the Chat toggle ON, and save.",
-            "Reload /products/product-beyblade-burst-valkyrie.",
-            "Look at the 'Sold by' card and at the header icon row.",
-        ],
-        inputs: { "chat.enabled": true },
-        expectedBehaviour: "Turning it on makes both entry points appear WITHOUT a code change: the gate is a live settings read, not a build-time flag. The Messages icon appears in the header with no badge (zero unread).",
-        expectedUiState: "The 'Sold by' card now shows a 'Message Seller' button beside 'Visit Store →'. A speech-bubble icon appears in the header icon row.",
-        expectedData: { "siteSettings.chat.enabled": true },
-        endResult: "Reload: both still present. The setting is stored, so it survives a sign-out and back in.",
-    },
-    "checklist-community-support-messages-message-seller-creates-thread": {
-        roles: ["buyer", "seller"],
-        startPage: "/products/product-beyblade-burst-valkyrie",
-        steps: [
-            "With chat enabled (previous case), sign in as admin@letitrip.in / TempPass123!.",
-            "Open /products/product-beyblade-burst-valkyrie and click 'Message Seller' on the 'Sold by' card.",
-            "Read the URL you land on and note the conversation id — it is a Firestore-generated id, not a slug.",
-            "Click 'Message Seller' on the SAME product a second time (go back and click again).",
-            "Compare the URL to the one you noted.",
-        ],
-        expectedBehaviour: "The first click resolves store-beyblade-arena's storeId to its owner's uid SERVER-SIDE (a product page knows the store slug, never the owner's Auth UID) and creates one conversation. The second click finds the existing thread and does NOT create a second one — the thread is between two USERS, not per listing, so a buyer with three questions about three items gets one thread.",
-        expectedUiState: "Both clicks land on /messages/{sameId} showing an empty thread with a composer and a 'Block' control in the header.",
-        expectedData: { "conversations: documents between this pair": 1 },
-        endResult: "The conversation persists. /messages now lists it. Clicking Message Seller again forever reuses it.",
-    },
-    "checklist-community-support-messages-send-and-recipient-sees-it": {
-        roles: ["buyer", "seller"],
-        startPage: "/messages",
-        steps: [
-            "Signed in as admin@letitrip.in, open the conversation created in the previous case.",
-            "Type 'Does this come with the original launcher?' and press Enter.",
-            "Watch the bubble while it sends.",
-            "Sign out, sign in as the owner of store-beyblade-arena (user-tyson-blader), and open /messages.",
-            "Open the conversation and read the message.",
-        ],
-        inputs: { body: "Does this come with the original launcher?" },
-        expectedBehaviour: "The message appears immediately as a pending bubble (optimistic), then resolves to a sent one. Server-side the body is PII-stripped and encrypted at rest, a truncated preview is denormalised onto the conversation, the recipient's unread counter is incremented with a real Firestore increment (not a read-modify-write), and a bell-only `message_received` notification is written — no email, because EMAIL_ELIGIBLE_TYPES says false for it.",
-        expectedUiState: "Sender side: the bubble is right-aligned and reads 'Sending…' briefly, then settles. Recipient side: /messages shows the thread with an unread badge of 1 and the preview text; opening it shows the message left-aligned and clears the badge.",
-        expectedData: { "recipient unread before opening": 1, "recipient unread after opening": 0 },
-        endResult: "Reload on both sides: the message is still there, the badge stays cleared for the recipient, and the preview on the inbox row matches the message.",
-    },
-    "checklist-community-support-messages-pii-is-stripped-from-the-body": {
-        roles: ["buyer"],
-        startPage: "/messages",
-        steps: [
-            "Open any conversation you are a participant in.",
-            "Send exactly: 'call me on 9876543210 or pay to tyson@paytm or tyson@okhdfc'",
-            "Read the message as it appears in the thread.",
-            "Reload the page and read it again.",
-        ],
-        inputs: { body: "call me on 9876543210 or pay to tyson@paytm or tyson@okhdfc" },
-        expectedBehaviour: "All three identifiers are replaced BEFORE the write, so the stored body never contains them. The rule order is specific-before-general and that ordering IS the fix: a bare `name@bank` VPA has no TLD dot so it matches neither the email nor the phone rule, and running phone first would mangle '9876543210@upi' into '[number removed]@upi' before the UPI rule ever saw it.",
-        expectedUiState: "The message renders as 'call me on [number removed] or pay to [email removed] or pay to [UPI removed]' — the ten-digit run, the dotted VPA and the bare VPA each replaced, none left through.",
-        expectedData: { "stored body contains '9876543210'": false, "stored body contains 'okhdfc'": false },
-        endResult: "Reload: the redacted form persists. The original text is not recoverable from the UI, which is the point — the redaction happened on the way in, not on the way out.",
-    },
-    "checklist-community-support-messages-retry-does-not-double-post": {
-        roles: ["buyer"],
-        startPage: "/messages",
-        steps: [
-            "Open a conversation and open DevTools → Network, set throttling to Offline.",
-            "Type 'retry test' and press Enter.",
-            "Observe the bubble's state.",
-            "Set throttling back to online and click the failed bubble's retry control.",
-            "Count the messages in the thread.",
-        ],
-        inputs: { body: "retry test" },
-        expectedBehaviour: "The failed send keeps its ORIGINAL clientMessageId — generated once at compose time, not per attempt — so the retry resolves to the same message server-side rather than creating a second one. The server uses the clientMessageId as the message document id and returns the existing document on a replay.",
-        expectedUiState: "Offline: the bubble reads 'Failed — tap to retry' rather than disappearing or silently succeeding. After retry: exactly ONE 'retry test' bubble in the thread, no duplicate.",
-        expectedData: { "messages with body 'retry test'": 1 },
-        endResult: "Reload: one message. A silent failure or a duplicate would both be defects — the first is how the old feature hid, the second is what idempotency exists to prevent.",
-    },
-    "checklist-community-support-messages-soft-ban-blocks-sending": {
-        roles: ["admin", "buyer"],
-        startPage: "/admin/users",
-        steps: [
-            "Sign in as admin@letitrip.in and open /admin/users.",
-            "Find the account you have been testing with as the buyer, open its editor, and apply a soft ban with action 'Send messages' and a reason.",
-            "Sign in as that banned account and open a conversation you are a participant in.",
-            "Type anything and try to send.",
-            "Read the refusal.",
-        ],
-        inputs: { "softBan.action": "send_messages", "softBan.reason": "QA test ban" },
-        expectedBehaviour: "The send is refused server-side with the ban's own reason quoted back. 🛑 This is the case that matters most about this flag: `send_messages` was a live BannedAction with NO READER anywhere in the codebase — an admin could set it and nothing checked it. The check lives in the domain function, so every caller (route, future job) is covered rather than just the one route someone remembered.",
-        expectedUiState: "An error surfaces naming the restriction and the reason — 'You are restricted from sending messages. Reason: QA test ban.' — not a generic failure and not a silently-dropped message.",
-        expectedData: { "messages added to the thread": 0 },
-        endResult: "Reload: no message was added. Remove the ban and the same send succeeds, which is what proves the ban was the cause rather than something else.",
-    },
-    "checklist-community-support-messages-block-stops-the-other-side": {
-        roles: ["buyer", "seller"],
-        startPage: "/messages",
-        steps: [
-            "Sign in as the seller (user-tyson-blader) and open the shared conversation.",
-            "Click 'Block' in the thread header and confirm.",
-            "Sign out, sign back in as the buyer (admin@letitrip.in), open the same conversation.",
-            "Try to send a message.",
-        ],
-        expectedBehaviour: "Blocking records the blocker's uid on the conversation. A send from the blocked party is refused with a clear reason rather than silently vanishing — a blocked sender who thinks their message went through is worse than one who is told.",
-        expectedUiState: "Blocker side: a confirmation, then the block persists. Blocked side: the send fails with 'The other participant is not accepting messages from you.'",
-        expectedData: { "messages added after the block": 0 },
-        endResult: "Reload on both sides: the block holds and the thread's existing history is still readable to both. Blocking stops new messages; it does not delete the past.",
-    },
-    "checklist-community-support-messages-live-ping-surfaces-failure": {
-        roles: ["buyer"],
-        startPage: "/messages",
-        steps: [
-            "Open a conversation and leave it open.",
-            "Open DevTools → Network and block requests to the Firebase Realtime Database host (or set throttling to Offline then back, which drops the subscription).",
-            "Watch the top of the thread for a notice.",
-            "In a second browser profile signed in as the other participant, send a message.",
-            "Reload the first tab.",
-        ],
-        expectedBehaviour: "🛑 THE CONTROL FOR THE BUG THAT KILLED THE OLD FEATURE. When the realtime channel cannot connect, the failure is SURFACED, never swallowed. The old hooks swallowed permission-denied into `setIsConnected(false)` and a literal `// ignore`, so the channel looked implemented and was inert for its entire life. The message is still delivered — it is durably in Firestore the moment the send returns — and the subscription only controls whether the open tab learns about it without a reload.",
-        expectedUiState: "A visible warning strip above the thread reading 'Live updates are unavailable for this conversation. New messages may not appear until you reload.' — NOT a silent nothing. After reload, the other participant's message is present.",
-        endResult: "The message was never lost; only the live notification was. That distinction is what the warning communicates, and a tester seeing no warning at all is the defect.",
-    },
-    "checklist-community-support-messages-inbox-read-is-bounded": {
-        roles: ["buyer"],
-        startPage: "/messages",
-        steps: [
-            "Open DevTools → Network and filter to /api/messages.",
-            "Load /messages and note the request and its response shape.",
-            "Open one conversation and note the thread request's response shape.",
-            "Scroll the thread to its oldest message.",
-        ],
-        expectedBehaviour: "🛑 THE NEGATIVE CONTROL THE PLAN NAMES. Both list reads are bounded and cursor-paginated: the inbox returns at most 50 conversations with a `nextCursor`, the thread at most 50 messages (default 30) with its own `nextCursor`. The absence of a `.limit()` is literally what turned 20 messages into ~1,600 reads the first time this feature existed. The unread badge sums the conversation list the inbox already holds and never issues a list query of its own.",
-        expectedUiState: "Each response carries `{ items: [...], nextCursor }` with `items.length` at or below the limit — never an unbounded array, and never a response whose size grows with total thread count.",
-        expectedData: { "inbox items.length <= 50": true, "thread items.length <= 50": true },
-        endResult: "Reload: the same bounded shape. A response returning every message in a thread is the defect this case exists to catch, and it is invisible from the rendered page — only the network panel shows it.",
-    },
-};

package/dist/features/tester/seed-data/authored/community-support__public-profile.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/community-support__public-profile.js

@@ -1,54 +0,0 @@
-/*
- * WHY: Authored six-part procedures for the community-support/public-profile page.
- * WHAT: 2 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.
- *
- * Both cases are run SIGNED OUT on purpose. A public page read while signed in as
- * the owner proves nothing about what the public sees, and the store page is one
- * of the surfaces that once passed a raw store document straight into a client
- * component — publishing a decrypted WhatsApp token into the page HTML.
- *
- * @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-community-support-public-profile-view-seller-store": {
-        roles: ["guest"],
-        startPage: "/stores",
-        steps: [
-            "Open /stores in a private window with no session.",
-            "Click the 'Beyblade Arena' card.",
-            "Read the store header — name, logo, banner, verified badge and rating.",
-            "Read the tab bar and open each tab in turn.",
-            "Open the browser's View Source and search the HTML for the words accessToken, adminNotes, suspensionReason and customCommissionRate.",
-        ],
-        inputs: { storeId: "store-beyblade-arena" },
-        expectedBehaviour: "The public store page is built from a projection that names every field it emits, rather than by spreading the store document and deleting a few keys. A deny-list is blind to fields nobody thought to delete — and to fields the TypeScript interface never declared at all.",
-        expectedUiState: "The header shows 'Beyblade Arena' with its logo and banner. The tabs render their listings. None of accessToken, adminNotes, suspensionReason or customCommissionRate appears anywhere in the page source, including inside the React data payload embedded at the bottom of the HTML.",
-        expectedData: { secretFieldsInHtml: 0 },
-        endResult: "Nothing persists — read-only. A hit on any of those four words is a data leak and fails the case outright, regardless of how the page looks.",
-    },
-    "checklist-community-support-public-profile-view-public-profile": {
-        roles: ["guest"],
-        startPage: "/profile/user-tyson-blader",
-        steps: [
-            "Open /profile/user-tyson-blader in a private window with no session.",
-            "Read the display name, avatar and bio. The name is 'Mock User 6' — every seeded persona is literally Mock User N, so that is the fixture rather than a placeholder bug, and the bio is real prose.",
-            "Open each tab on the profile.",
-            "Search the page source for an email address and for a phone number.",
-            "Open /profile/user-yugi-muto and read the same things — display name 'Mock User 3', its own bio.",
-            "On BOTH profiles, check what is NOT shown. Each seeded publicProfile sets showEmail, showPhone, showOrders and showWishlist to FALSE, so none of those may appear anywhere on the page. Open View Source and search for the personas' email addresses (tyson@beybladearena.in, rehan.sheikh@gmail.com) and for the strings phoneNumber, orders and wishlist — a value hidden in the rendered page but present in the HTML is still published, which is the shape the store case on this page checks for.",
-        ],
-        inputs: { sellerProfile: "user-tyson-blader", buyerProfile: "user-yugi-muto" },
-        expectedBehaviour: "A public profile shows what its owner chose to publish and nothing drawn from their account record. Email and phone are PII-encrypted at rest and have no business on this page in any form, masked or otherwise.",
-        expectedUiState: "Both profiles render a display name, avatar and bio, with their tabs populated. Neither page — nor its source — contains an email address or a phone number. A profile set to Private returns a not-found page for a signed-out visitor rather than rendering with fields blanked out.",
-        endResult: "Nothing persists — read-only. Both profiles are public in the seed, so a not-found here means the visibility default changed.",
-    },
-};

package/dist/features/tester/seed-data/authored/community-support__support-tickets.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/community-support__support-tickets.js

@@ -1,76 +0,0 @@
-/*
- * WHY: Authored six-part procedures for the community-support/support-tickets page.
- * WHAT: 3 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.
- *
- * @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-community-support-support-tickets-create-ticket": {
-        roles: ["buyer"],
-        startPage: "/user/support",
-        steps: [
-            "Sign in as rehan.sheikh@gmail.com / TempPass123!.",
-            "Open /user/support.",
-            "Click the control that starts a new ticket.",
-            "Type 'QA Ticket create-ticket' in the subject field.",
-            "Select 'Orders' as the category.",
-            "Type 'Raised by the tester checklist to confirm ticket creation persists.' in the message field.",
-            "Submit the ticket.",
-            "Reload /user/support.",
-        ],
-        inputs: {
-            subject: "QA Ticket create-ticket",
-            category: "Orders",
-            message: "Raised by the tester checklist to confirm ticket creation persists.",
-        },
-        expectedBehaviour: "A ticket document is created against this buyer with a ticket- prefixed id, an open status, and the first message stored as its opening entry rather than as a separate field the reply thread cannot see.",
-        expectedUiState: "The list gains a row reading 'QA Ticket create-ticket' with an open status and the Orders category. Opening it shows the submitted message as the first entry in the thread.",
-        expectedData: { subject: "QA Ticket create-ticket", status: "open" },
-        endResult: "The row is still there after the reload. A ticket that appears once and is gone on refresh was written to component state, not to Firestore.",
-    },
-    "checklist-community-support-support-tickets-reply-ticket": {
-        roles: ["buyer"],
-        startPage: "/user/support",
-        steps: [
-            "Sign in as rehan.sheikh@gmail.com / TempPass123!.",
-            "Open /user/support and open the ticket named 'QA Ticket create-ticket'.",
-            "Read how many messages the thread holds.",
-            "Type 'QA Reply reply-ticket — second message in the thread.' in the reply box.",
-            "Submit the reply.",
-            "Reload the page.",
-        ],
-        inputs: { reply: "QA Reply reply-ticket — second message in the thread." },
-        expectedBehaviour: "The reply is appended to the ticket's own message array in a transaction, so two replies sent quickly cannot overwrite one another. An ordinary reply that carries no status change costs one write and no read — the ticket is only re-read when a status accompanies the message.",
-        expectedUiState: "The thread gains a second entry with the typed text, attributed to the buyer and timestamped. The earlier message is still above it, unchanged. The ticket's status has not silently moved to resolved.",
-        expectedData: { threadMessageCount: 2 },
-        endResult: "Both messages survive the reload in the same order. A reply that replaces the first message rather than appending is the failure this case catches.",
-    },
-    "checklist-community-support-support-tickets-support-tickets-search-box": {
-        roles: ["buyer"],
-        startPage: "/user/support",
-        steps: [
-            "Sign in as rehan.sheikh@gmail.com / TempPass123!.",
-            "Open /user/support and read the total number of rows. This account owns FIVE seeded tickets spanning all five statuses — open, in progress, waiting on user, resolved and closed — so the status filter and the hide-toggle below both have real rows to act on, and the starting count is five plus whatever this run has created.",
-            "Type 'QA Ticket' in the search box. 🛑 That row exists only if create-ticket has already run in this batch — work these three in order. If it has not, search a word from a seeded subject instead and say which you used.",
-            "Read the rows.",
-            "Clear the box and type 'zzzznope'.",
-            "Read the rows.",
-            "Clear the box, then use the status filter to select each status in turn and read the rows. All five have at least one seeded ticket, so a status returning nothing is a finding rather than an empty corner of the fixture.",
-            "Toggle 'Hide resolved/closed' and read the rows. The seed carries one resolved AND one closed ticket for this account, so the count must FALL by at least two — a toggle that changes nothing is the inert-control failure this step exists for.",
-        ],
-        inputs: { matchingQuery: "QA Ticket", nonsenseQuery: "zzzznope" },
-        expectedBehaviour: "This list moved onto the shared listing scaffold, which supplies search over subject, id and category for free. The pre-existing status filter and the hide-resolved toggle have to keep working across that conversion — a migration that adds one affordance and quietly drops two is a net loss.",
-        expectedUiState: "'QA Ticket' narrows the list to matching subjects. 'zzzznope' returns an empty state, not the full list — that is the control which proves the box filters rather than decorates. The status filter changes which rows appear, and the toggle removes resolved and closed rows.",
-        expectedData: { nonsenseResultCount: 0 },
-        endResult: "Nothing persists; search and filter state live in the URL, so reloading reproduces the same narrowed list.",
-    },
-};

package/dist/features/tester/seed-data/authored/content-discovery__authenticity-checker.d.ts

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