@mohasinac/appkit 4.34.0 → 4.35.0

package/dist/features/tester/seed-data/authored/cta-layout__product-bottom-bar.d.ts

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

package/dist/features/tester/seed-data/authored/cta-layout__product-bottom-bar.js

@@ -0,0 +1,35 @@
+/*
+ * WHY: Authored six-part procedures for the cta-layout/product-bottom-bar page.
+ * WHAT: 1 case, keyed by full checklist id.
+ *
+ * Written by hand, case by case, against the label each one states. There is no
+ * generator: the authoring scripts were deleted once it was clear they were
+ * scaffolding around work that is simply writing.
+ *
+ * @tag domain:tester
+ * @tag layer:seed
+ * @tag pattern:none
+ * @tag access:server-only
+ * @tag consumers:seed-data/authored/index.ts
+ * @tag sideEffects:none
+ */
+export const authored = {
+    "checklist-cta-layout-product-bottom-bar-three-actions-wrap-to-second-row": {
+        roles: ["buyer"],
+        startPage: "/products/product-beyblade-original-dranzer-s",
+        steps: [
+            "Resize the browser window to 375 pixels wide.",
+            "Sign in as rehan.sheikh@gmail.com / TempPass123!.",
+            "Open /products/product-beyblade-original-dranzer-s.",
+            "Read the bottom action bar and note which buttons share a row.",
+            "Compare the widths of the two buttons on the upper row.",
+            "Click 'Add to Cart' and watch the bar while the label changes.",
+            "Count the rows in the bar during and after the change.",
+        ],
+        inputs: { viewportWidth: 375, productId: "product-beyblade-original-dranzer-s" },
+        expectedBehaviour: "Three actions of different weight are laid out as two secondaries sharing a row above one full-width primary. The secondaries share that row proportionally rather than one being pinned to its content width, which is what made the row read lopsided before.",
+        expectedUiState: "'Wishlist' and 'Add to Cart' occupy the upper row and neither is squeezed to a fraction of the other. 'Buy Now' spans the full width beneath them. While the label reads 'Adding…' the bar still has exactly two rows — a bar that reflows to three rows and back makes the whole page jump under the buyer's thumb mid-tap.",
+        expectedData: { barRowCount: 2 },
+        endResult: "The item is in the cart. Restore the window width and empty the cart afterwards so later cases start clean.",
+    },
+};

package/dist/features/tester/seed-data/authored/design-ux__back-to-top-button.d.ts

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

package/dist/features/tester/seed-data/authored/design-ux__back-to-top-button.js

@@ -0,0 +1,95 @@
+/*
+ * WHY: Authored six-part procedures for the design-ux/back-to-top-button 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 bottom edge is three declared tiers with exactly three variables and three
+ * writers: the keyboard inset, the mobile tab bar, and one container measuring
+ * everything between. This control consumes all three — which is why "does it
+ * clear the CTA bar" is a case rather than a detail.
+ *
+ * @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-design-ux-back-to-top-button-appears-and-clickable-on-long-page": {
+        roles: ["guest"],
+        startPage: "/products",
+        steps: [
+            "Open /products in a private window at a desktop width of 1280 pixels.",
+            "Look for the back-to-top control before scrolling.",
+            "Scroll down past 400 pixels.",
+            "Look for the control again and read what it shows.",
+            "Click it.",
+        ],
+        inputs: { viewportWidth: 1280, revealScrollPx: 400 },
+        expectedBehaviour: "The control is hidden at the top of the page, where it would do nothing, and appears once there is somewhere to return to. It must be genuinely clickable rather than sitting behind another fixed element.",
+        expectedUiState: "Nothing is shown before scrolling. After 400 pixels the control appears and responds to a click. A control that appears but does not respond means something transparent is on top of it.",
+        endResult: "Read-only; nothing persists.",
+    },
+    "checklist-design-ux-back-to-top-button-above-sticky-buy-bar": {
+        roles: ["guest"],
+        startPage: "/products/product-beyblade-original-dranzer-s",
+        steps: [
+            "Open /products/product-beyblade-original-dranzer-s in a private window at 1280 pixels wide.",
+            "Scroll down past 400 pixels so both the sticky buy bar and the back-to-top control are showing.",
+            "Look at where the back-to-top control sits relative to the buy bar.",
+            "Try to click both the back-to-top control and each button in the buy bar.",
+            "Resize to 390 pixels wide and repeat.",
+        ],
+        inputs: { desktopWidth: 1280, mobileWidth: 390 },
+        expectedBehaviour: "Neither element learns the other's height — both read from the one measured container, so the control clears the bar automatically and a bar added later is covered with no edit. The desktop reveal threshold for the buy bar is the SAME 400 pixels, so the two appear on the same scroll tick and the overlap is guaranteed rather than occasional.",
+        expectedUiState: "The back-to-top control sits fully above the buy bar with a visible gap, at both widths. It does not overlap any buy-bar button, and every button in the bar is clickable.",
+        endResult: "Read-only; nothing persists. Restore the window width afterwards.",
+    },
+    "checklist-design-ux-back-to-top-button-scrolls-to-top": {
+        roles: ["guest"],
+        startPage: "/products",
+        steps: [
+            "Open /products in a private window and scroll to the bottom of the grid.",
+            "Click the back-to-top control.",
+            "Watch the page as it moves.",
+            "Read what is at the top of the viewport when it stops.",
+            "Read the address bar.",
+        ],
+        expectedBehaviour: "The control scrolls the window to the top of the current page. It is not a navigation — the URL, the filters and the page of results are all unchanged.",
+        expectedUiState: "The page ends at the top with the header and toolbar visible. The URL is unchanged, the same filters are still applied, and the same page of results is still loaded — a jump back to page one would be a navigation wearing a scroll control's clothes.",
+        endResult: "Read-only; nothing persists.",
+    },
+    "checklist-design-ux-back-to-top-button-dismiss-returns-on-navigation": {
+        roles: ["guest"],
+        startPage: "/products",
+        steps: [
+            "Open /products in a private window and scroll past 400 pixels so the control appears.",
+            "Click its close or dismiss control.",
+            "Scroll up and down again and check whether it returns.",
+            "Navigate to /auctions WITHOUT reloading — click a link rather than typing the URL.",
+            "Scroll past 400 pixels and look for the control.",
+        ],
+        expectedBehaviour: "Dismissal lasts for the current page and is reset on the next navigation. This control lives in a shell that does NOT remount when the route changes, so a dismissal stored in browser storage reads as permanent: one click hid it until the tab was closed, with no way to bring it back.",
+        expectedUiState: "After dismissing, the control stays hidden on /products however much the page is scrolled. After navigating to /auctions it returns on scroll. A control still hidden after navigation is the failure.",
+        endResult: "Read-only; nothing persists.",
+    },
+    "checklist-design-ux-back-to-top-button-not-covering-toast-or-modal-actions": {
+        roles: ["buyer"],
+        startPage: "/products/product-tester-standard-1",
+        steps: [
+            "Sign in as rehan.sheikh@gmail.com / TempPass123!.",
+            "Open /products/product-tester-standard-1 and scroll past 400 pixels so the control appears.",
+            "Click 'Add to Cart' and watch for a toast.",
+            "Look at whether the control overlaps the toast or any control inside it.",
+            "Open any modal on the page and look at its footer buttons.",
+            "Try to click each footer button.",
+        ],
+        expectedBehaviour: "The control yields to transient and modal UI. A toast carries actions and a modal footer carries the decision — a floating control on top of either takes a click the user meant for something else.",
+        expectedUiState: "The toast is fully visible and its controls are clickable. The modal's footer buttons are unobstructed and every one responds. The back-to-top control either sits clear of both or is hidden while they are open.",
+        endResult: "Remove the item from the cart afterwards so later cases start from an empty cart.",
+    },
+};

package/dist/features/tester/seed-data/authored/design-ux__carousel-arrow-bounds.d.ts

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

package/dist/features/tester/seed-data/authored/design-ux__carousel-arrow-bounds.js

@@ -0,0 +1,191 @@
+/*
+ * WHY: Authored six-part procedures for the design-ux/carousel-arrow-bounds page.
+ * WHAT: 12 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.
+ *
+ * Every carousel in the app shares one implementation, so the last two cases
+ * exist to prove that sharing is real: a fix that lands on the homepage rail and
+ * not on the related-items rail means there are two implementations.
+ *
+ * @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-design-ux-carousel-arrow-bounds-arrows-never-cover-cards": {
+        roles: ["guest"],
+        startPage: "/",
+        steps: [
+            "Open / in a private window at 1280 pixels wide.",
+            "Scroll to a horizontal card carousel.",
+            "Look at the left and right arrows and what sits under each.",
+            "Read the title and price of the first and last visible cards.",
+            "Try to click the first card's title without hitting an arrow.",
+        ],
+        inputs: { viewportWidth: 1280 },
+        expectedBehaviour: "Arrows sit in reserved gutters beside the rail rather than floating over the first and last cards. An arrow on top of a card takes the click meant for the card, which reads as a card that does not open.",
+        expectedUiState: "Neither arrow overlaps a card's image, title or price. The first card is clickable across its whole area. An arrow covering the corner of the end card is the failure even when the card still opens from elsewhere.",
+        endResult: "Read-only; restore the window width afterwards.",
+    },
+    "checklist-design-ux-carousel-arrow-bounds-arrows-no-overlap-mid-scroll": {
+        roles: ["guest"],
+        startPage: "/",
+        steps: [
+            "Open / in a private window at 1280 pixels wide and scroll to a card carousel.",
+            "Click the right arrow once and watch the cards move.",
+            "While the cards are still moving, look at where the arrows are.",
+            "Let it settle and look again.",
+            "Click through to the middle of the rail and look once more.",
+        ],
+        expectedBehaviour: "The arrows are fixed to the rail's gutters and do not move with its content, so a card sliding past never ends up under one — mid-scroll is the moment a card is most likely to be beneath an arrow.",
+        expectedUiState: "Arrows stay in place while the cards move and no card passes under them. In the middle of the rail neither arrow overlaps a card.",
+        endResult: "Read-only; restore the window width afterwards.",
+    },
+    "checklist-design-ux-carousel-arrow-bounds-no-arrows-on-mobile": {
+        roles: ["guest"],
+        startPage: "/",
+        steps: [
+            "Resize the browser window to 390 pixels wide and open / in a private window.",
+            "Scroll to a card carousel and look for arrows.",
+            "Swipe the rail and check it moves.",
+            "Resize to 1280 pixels and look for the arrows again.",
+        ],
+        inputs: { mobileWidth: 390, desktopWidth: 1280 },
+        expectedBehaviour: "Arrows are a pointer affordance and are hidden on touch widths, where swiping is the interaction. Keeping them costs horizontal space the cards need on the narrowest screens.",
+        expectedUiState: "No arrows at 390 pixels, and the rail still swipes. Arrows return at 1280. Arrows present at 390 are the failure.",
+        endResult: "Read-only; restore the window width afterwards.",
+    },
+    "checklist-design-ux-carousel-arrow-bounds-mobile-card-not-clipped": {
+        roles: ["guest"],
+        startPage: "/",
+        steps: [
+            "Resize the browser window to 390 pixels wide and open / in a private window.",
+            "Scroll to a card carousel and look at the first card's left edge.",
+            "Look at the last card's right edge after swiping to the end.",
+            "Read each visible card's title and price in full.",
+            "Try to scroll the page sideways rather than the rail.",
+        ],
+        inputs: { mobileWidth: 390 },
+        expectedBehaviour: "Cards are fully readable at the rail's ends, with the container's own padding preserved. A rail that bleeds into the page's edge padding makes the whole page scroll sideways instead of the rail.",
+        expectedUiState: "No card is clipped at either end. Every visible title and price reads in full. The PAGE does not scroll sideways — only the rail does.",
+        endResult: "Read-only; restore the window width afterwards.",
+    },
+    "checklist-design-ux-carousel-arrow-bounds-mobile-swipe-and-snap": {
+        roles: ["guest"],
+        startPage: "/",
+        steps: [
+            "Resize the browser window to 390 pixels wide and open / in a private window.",
+            "Scroll to a card carousel and swipe it left with a short flick.",
+            "Watch where it comes to rest.",
+            "Swipe again with a long flick and watch where it rests.",
+            "Swipe back to the start.",
+        ],
+        inputs: { mobileWidth: 390 },
+        expectedBehaviour: "The rail snaps so a card edge aligns to the viewport rather than resting mid-card. Both a short and a long flick end aligned — a snap that only works for one gesture length is not a snap.",
+        expectedUiState: "After both flicks the rail rests with a card edge aligned, not with a card half off screen. Swiping back reaches the true start with the first card fully visible.",
+        endResult: "Read-only; restore the window width afterwards.",
+    },
+    "checklist-design-ux-carousel-arrow-bounds-no-white-fade-smear": {
+        roles: ["guest"],
+        startPage: "/",
+        steps: [
+            "Open / in a private window in light mode at 1280 pixels and scroll to a card carousel.",
+            "Look at the left and right edges of the rail for a fade or gradient overlay.",
+            "Switch to dark mode and look at the same edges.",
+            "Scroll the rail to the middle and look again in dark mode.",
+        ],
+        expectedBehaviour: "Any edge fade is drawn from a theme-relative surface so it matches the page behind it. A fade hard-coded to white sits as a pale smear over a dark page — visible as a haze rather than as a gradient into the background.",
+        expectedUiState: "The rail's edges blend into the page background in both themes. In dark mode there is no light smear or milky band at either edge.",
+        endResult: "Read-only; return the site to light mode and restore the width.",
+    },
+    "checklist-design-ux-carousel-arrow-bounds-two-row-tall-arrows": {
+        roles: ["guest"],
+        startPage: "/",
+        steps: [
+            "Open / in a private window at 1280 pixels and find a carousel whose cards wrap to two rows, or a taller card variant.",
+            "Look at the arrows' vertical position relative to the rail.",
+            "Check whether they are centred on the full height or on one row.",
+            "Click each and check it scrolls the whole rail.",
+        ],
+        expectedBehaviour: "Arrows centre on the rail's full height whatever the card height, so a taller card variant does not leave them stranded near the top.",
+        expectedUiState: "Both arrows are vertically centred against the full rail height and both scroll the entire rail. Arrows aligned to the first row of a two-row rail are the failure.",
+        endResult: "Read-only; restore the window width afterwards.",
+    },
+    "checklist-design-ux-carousel-arrow-bounds-arrows-dark-mode": {
+        roles: ["guest"],
+        startPage: "/",
+        steps: [
+            "Open / in a private window and switch to dark mode.",
+            "Scroll to a card carousel and look at both arrows.",
+            "Hover each and look at it while hovering.",
+            "Compare their visibility against light mode.",
+        ],
+        expectedBehaviour: "Arrow fill and glyph both come from tokens that invert, so the control is visible in both themes at rest and on hover. A named palette tint as the hover fill is the same near-white in both, and swallows the glyph in dark.",
+        expectedUiState: "Both arrows are clearly visible in dark mode and stay visible while hovered. An arrow that disappears under its own hover fill is the failure.",
+        endResult: "Read-only; return the site to light mode afterwards.",
+    },
+    "checklist-design-ux-carousel-arrow-bounds-arrow-end-state-no-jump": {
+        roles: ["guest"],
+        startPage: "/",
+        steps: [
+            "Open / in a private window at 1280 pixels and scroll to a card carousel.",
+            "Look at the left arrow while the rail is at its start.",
+            "Click right repeatedly to the end of the rail.",
+            "Look at the right arrow at the end and at the rail's position.",
+            "Watch whether the cards shift when an arrow changes state.",
+        ],
+        expectedBehaviour: "An arrow that cannot act is disabled in place rather than removed. Removing it frees its gutter, the rail widens, and every card jumps sideways at exactly the moment the user is reaching for one.",
+        expectedUiState: "At the start the left arrow is present and visibly disabled, not absent. At the end the right arrow is the same. The cards do not shift horizontally when either changes state.",
+        endResult: "Read-only; restore the window width afterwards.",
+    },
+    "checklist-design-ux-carousel-arrow-bounds-resize-across-breakpoint": {
+        roles: ["guest"],
+        startPage: "/",
+        steps: [
+            "Open / in a private window at 1280 pixels and scroll to a card carousel.",
+            "Slowly resize the window down through 1024, 768 and 640 to 390 pixels, watching the rail throughout.",
+            "Note the width at which the arrows disappear.",
+            "Slowly resize back up to 1280, watching the rail.",
+            "Check no card is left clipped or overlapped at any width.",
+        ],
+        expectedBehaviour: "The rail re-measures as the viewport changes, so arrows appear and disappear at the breakpoint and the card widths keep up. A rail that measures once on mount is correct at the width it loaded at and wrong at every other.",
+        expectedUiState: "Arrows appear and disappear cleanly at the breakpoint in both directions. At no intermediate width is a card clipped, overlapped by an arrow, or left at a stale width. The page never scrolls sideways.",
+        endResult: "Read-only; restore the window width afterwards.",
+    },
+    "checklist-design-ux-carousel-arrow-bounds-related-carousels-same-behaviour": {
+        roles: ["guest"],
+        startPage: "/products/product-beyblade-burst-valkyrie",
+        steps: [
+            "Open /products/product-beyblade-burst-valkyrie in a private window at 1280 pixels.",
+            "Scroll to the related-items carousels below the main content.",
+            "Check the arrows against the same points as the homepage: no card overlap, disabled at the ends, centred vertically.",
+            "Resize to 390 pixels and check the arrows disappear and the rail swipes.",
+            "Compare everything against how the homepage carousel behaved.",
+        ],
+        inputs: { desktopWidth: 1280, mobileWidth: 390 },
+        expectedBehaviour: "Related-items rails use the same carousel as the homepage, so every behaviour above holds here without a separate fix. A difference means there are two implementations and a fix has only landed on one.",
+        expectedUiState: "Arrow bounds, disabled end states, vertical centring and mobile behaviour all match the homepage carousel. Any difference is the finding, named specifically.",
+        endResult: "Read-only; restore the window width afterwards.",
+    },
+    "checklist-design-ux-carousel-arrow-bounds-category-page-carousels-same-behaviour": {
+        roles: ["guest"],
+        startPage: "/categories/category-beyblade-burst",
+        steps: [
+            "Open /categories/category-beyblade-burst in a private window at 1280 pixels.",
+            "Scroll to the grouped-listings carousel.",
+            "Check the arrows against the same points as the homepage rail.",
+            "Open /brands/brand-beyblade and check its carousel the same way.",
+            "Resize both to 390 pixels and check the arrows disappear and the rails swipe.",
+        ],
+        inputs: { desktopWidth: 1280, mobileWidth: 390 },
+        expectedBehaviour: "Category and brand pages use the same carousel again. These two are worth checking separately because the category and brand tab components are deliberate near-duplicates, and a duplicate is exactly where a shared component gets replaced by a local copy.",
+        expectedUiState: "Both pages' carousels behave identically to the homepage rail at both widths. A difference between the category page and the brand page is itself a finding, since they should be the same component scoped differently.",
+        endResult: "Read-only; restore the window width afterwards.",
+    },
+};

package/dist/features/tester/seed-data/authored/design-ux__dashboard-layout.d.ts

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

package/dist/features/tester/seed-data/authored/design-ux__dashboard-layout.js

@@ -0,0 +1,158 @@
+/*
+ * WHY: Authored six-part procedures for the design-ux/dashboard-layout page.
+ * WHAT: 9 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 three portal shells are deliberate near-duplicates — different domain
+ * semantics over one structural shell — so the three collapsible cases are the
+ * same check run three times rather than one case with a loop. That is the point:
+ * a shared shell is only shared if all three actually behave alike.
+ *
+ * @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-design-ux-dashboard-layout-collapsible-admin": {
+        roles: ["admin"],
+        startPage: "/admin",
+        steps: [
+            "Sign in as admin@letitrip.in / TempPass123!.",
+            "Open /admin and read the sidebar's group headings.",
+            "Collapse one expanded group and read what remains.",
+            "Expand a collapsed group and read its contents.",
+            "Navigate to another admin page using the sidebar.",
+            "Read whether the collapsed group is still collapsed.",
+            "Reload the page and read it again.",
+        ],
+        expectedBehaviour: "Groups collapse and expand, and the state survives navigation within the portal. Whether it survives a full reload is the second question — a preference held only in memory resets on refresh, which for a sidebar the user has arranged is a small but repeated annoyance.",
+        expectedUiState: "Collapsing hides that group's entries and leaves its heading. The state holds across sidebar navigation. Record in the comment whether it also survives the reload.",
+        endResult: "Re-expand anything collapsed, so later cases that count sidebar entries are not reading a collapsed sidebar.",
+    },
+    "checklist-design-ux-dashboard-layout-collapsible-store": {
+        roles: ["seller"],
+        startPage: "/store",
+        steps: [
+            "Sign in as tyson@beybladearena.in / TempPass123!.",
+            "Open /store and read the sidebar's group headings.",
+            "Collapse one expanded group and read what remains.",
+            "Expand a collapsed group and read its contents.",
+            "Navigate to another store page using the sidebar and read the state.",
+            "Reload the page and read it again.",
+        ],
+        expectedBehaviour: "The store sidebar behaves the same way as the admin one, because both wrap one structural shell. A difference between them means the behaviour lives in the wrapper rather than the shell.",
+        expectedUiState: "Collapse and expand work, and the state survives sidebar navigation — the same as /admin. Any divergence from the admin sidebar's behaviour is the finding.",
+        endResult: "Re-expand anything collapsed.",
+    },
+    "checklist-design-ux-dashboard-layout-collapsible-user": {
+        roles: ["buyer"],
+        startPage: "/user",
+        steps: [
+            "Sign in as rehan.sheikh@gmail.com / TempPass123!.",
+            "Open /user and read the sidebar's group headings.",
+            "Collapse one expanded group and read what remains.",
+            "Expand a collapsed group and read its contents.",
+            "Navigate to another user page using the sidebar and read the state.",
+            "Reload the page and read it again.",
+        ],
+        expectedBehaviour: "The user sidebar behaves like the other two. This portal's layout reads no session server-side, so its shell is prerendered and hydrated client-side — a difference in collapse behaviour here would point at that difference rather than at the shell.",
+        expectedUiState: "Collapse and expand work and survive sidebar navigation, matching /admin and /store. Any divergence is the finding.",
+        endResult: "Re-expand anything collapsed.",
+    },
+    "checklist-design-ux-dashboard-layout-mobile-table-cards": {
+        roles: ["admin"],
+        startPage: "/admin/products",
+        steps: [
+            "Sign in as admin@letitrip.in / TempPass123!.",
+            "Open /admin/products at a desktop width of 1280 pixels and read how rows are presented.",
+            "Resize the window to 390 pixels wide.",
+            "Read how the same rows are presented now.",
+            "Try to scroll the page sideways.",
+            "Open a row's action menu and read its entries.",
+        ],
+        inputs: { desktopWidth: 1280, mobileWidth: 390 },
+        expectedBehaviour: "A table becomes cards on a phone rather than a sideways-scrolling table, because columns off the right edge are columns nobody reads. Every row action stays reachable in the card form.",
+        expectedUiState: "At 1280 the rows are a table. At 390 they are cards, each carrying the row's key fields. The page does not scroll sideways. The row action menu opens and is fully on screen.",
+        endResult: "Read-only; restore the window width afterwards.",
+    },
+    "checklist-design-ux-dashboard-layout-view-mode-persist": {
+        roles: ["admin"],
+        startPage: "/admin/products",
+        steps: [
+            "Sign in as admin@letitrip.in / TempPass123!.",
+            "Open /admin/products and read which view mode is active.",
+            "Switch to the other view mode.",
+            "Read the URL.",
+            "Reload the page and read the view mode before touching anything.",
+            "Navigate to /admin/orders and back to /admin/products, then read the view mode.",
+        ],
+        expectedBehaviour: "View mode lives in the URL alongside the other listing state, so the server's first paint and the control agree and the choice is shareable. It is one of the few keys that does NOT reset the page number when it changes — switching how rows are drawn is not a new query.",
+        expectedUiState: "The URL carries the view mode. After the reload the chosen mode is active on first paint, not the default that then switches. Changing it does not send the list back to page one.",
+        endResult: "Read-only; nothing persists beyond the URL.",
+    },
+    "checklist-design-ux-dashboard-layout-list-view-default": {
+        roles: ["admin"],
+        startPage: "/admin/orders",
+        steps: [
+            "Sign in as admin@letitrip.in / TempPass123!.",
+            "Open /admin/orders with no query parameters and read which view mode is active.",
+            "Open /admin/products the same way and read its default.",
+            "Open /admin/users the same way and read its default.",
+            "Compare the three.",
+        ],
+        expectedBehaviour: "Listing pages open in the same default view. Three admin listings opening in three different modes means each is choosing its own default rather than taking the shared one.",
+        expectedUiState: "All three open in the same view mode with no parameter in the URL. A page that differs is the finding, named specifically.",
+        endResult: "Read-only; nothing persists.",
+    },
+    "checklist-design-ux-dashboard-layout-row-table-click-consistency": {
+        roles: ["admin"],
+        startPage: "/admin/orders",
+        steps: [
+            "Sign in as admin@letitrip.in / TempPass123!.",
+            "Open /admin/orders in table view and click a row anywhere except on a control.",
+            "Read what opens.",
+            "Go back, switch to card view, and click a card the same way.",
+            "Read what opens and compare with the table result.",
+            "Repeat both on /admin/products.",
+        ],
+        expectedBehaviour: "A row and its card open the same thing, because both derive their click target from the same row href. A card that only offers a menu while its table row opens a drawer means the two renderers have diverged.",
+        expectedUiState: "Clicking a row and clicking its card open the same record in the same way, on both listings. A card that is inert while its row is clickable is the failure.",
+        endResult: "Read-only; close whatever opens without saving.",
+    },
+    "checklist-design-ux-dashboard-layout-list-card-row-actions": {
+        roles: ["admin"],
+        startPage: "/admin/products",
+        steps: [
+            "Sign in as admin@letitrip.in / TempPass123!.",
+            "Open /admin/products in table view and open a row's action menu.",
+            "Write down every action it offers.",
+            "Switch to card view and open the same record's action menu.",
+            "Write down every action it offers and compare the two lists.",
+            "Check whether either list offers a way to VIEW the record, not only to mutate it.",
+        ],
+        expectedBehaviour: "Both renderers offer the same actions from the same preset. A menu of pure mutations is a dead end: it lets an admin act on a record they were never able to read, which is why a detail affordance has to be among them.",
+        expectedUiState: "The two menus offer the same actions. At least one is a view or edit action rather than all being mutations. Destructive entries are visually marked as such.",
+        endResult: "Read-only; close the menus without choosing anything.",
+    },
+    "checklist-design-ux-dashboard-layout-listing-toolbar-consistency": {
+        roles: ["admin"],
+        startPage: "/admin/products",
+        steps: [
+            "Sign in as admin@letitrip.in / TempPass123!.",
+            "Open /admin/products and write down every control in its toolbar, left to right.",
+            "Open /admin/orders and write down the same.",
+            "Open /admin/users and write down the same.",
+            "Compare the three orderings.",
+            "Look for any toolbar with an empty gap where a control would sit.",
+        ],
+        expectedBehaviour: "Every listing draws its toolbar from one shared scaffold, so search, filters, sort and view mode appear in the same order everywhere. A listing whose controls are in a different order is one that has been hand-wired.",
+        expectedUiState: "All three toolbars present the same controls in the same order. None shows an empty gap where a removed control used to be — a collapsed control must collapse its layout too.",
+        endResult: "Read-only; nothing persists.",
+    },
+};

package/dist/features/tester/seed-data/authored/design-ux__footer-theme.d.ts

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

package/dist/features/tester/seed-data/authored/design-ux__footer-theme.js

@@ -0,0 +1,106 @@
+/*
+ * WHY: Authored six-part procedures for the design-ux/footer-theme page.
+ * WHAT: 6 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.
+ *
+ * 🛑 EVERY CASE HERE IS READ IN BOTH THEMES. A near-white tint is the same fill
+ * in every theme, so white-on-white shows up in exactly one of them — reading
+ * only the light theme passes the whole page while half of it is invisible.
+ *
+ * @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-design-ux-footer-theme-footer-dark-mode": {
+        roles: ["guest"],
+        startPage: "/",
+        steps: [
+            "Open / in a private window and switch the site to dark mode.",
+            "Scroll to the footer.",
+            "Read every link, heading and paragraph in it.",
+            "Hover each link and read it while hovering.",
+            "Write down anything that becomes unreadable at any point.",
+        ],
+        expectedBehaviour: "Footer colours come from theme tokens that invert, so text stays readable in both themes and a hover fill stays behind its own ink. A named palette tint such as zinc-50 is the same near-white in every theme, so under inverted ink it is white-on-white on hover only.",
+        expectedUiState: "Every link, heading and paragraph is legible against the dark footer. Hovering any link keeps its text readable — a link that vanishes on hover is the specific failure, and it is invisible until the pointer is actually over it.",
+        expectedData: { unreadableElementsOnHover: 0 },
+        endResult: "Read-only; return the site to light mode afterwards.",
+    },
+    "checklist-design-ux-footer-theme-footer-github-icon": {
+        roles: ["guest"],
+        startPage: "/",
+        steps: [
+            "Open / in a private window and scroll to the footer.",
+            "Find the GitHub icon and look at its size relative to the other social icons.",
+            "Hover it and read any tooltip or label.",
+            "Click it and read where it lands.",
+            "Switch to dark mode and look at the icon again.",
+        ],
+        expectedBehaviour: "The icon is a real sized glyph inside its control, not a text character. A text character cannot be sized by any width or height utility — it renders at the platform font fallback, which is exactly what makes one icon in a row look wrong next to its neighbours.",
+        expectedUiState: "The GitHub icon is the same size as the other social icons in the row and is visible in both themes. It opens the real profile rather than a 404 or the GitHub homepage.",
+        endResult: "Read-only; return the site to light mode afterwards.",
+    },
+    "checklist-design-ux-footer-theme-footer-text-weight-readable": {
+        roles: ["guest"],
+        startPage: "/",
+        steps: [
+            "Open / in a private window at a desktop width and scroll to the footer.",
+            "Read the body text in each column at normal viewing distance.",
+            "Compare the link text's weight and contrast against the paragraph text around it.",
+            "Resize to 390 pixels wide and read the same text.",
+        ],
+        expectedBehaviour: "Footer text is legible rather than technically present. A muted token applied to text that is already small enough to be secondary compounds into text nobody reads.",
+        expectedUiState: "Body text in every column is readable without leaning in, at both widths. Links are distinguishable from surrounding paragraph text by more than colour alone.",
+        endResult: "Read-only; restore the window width afterwards.",
+    },
+    "checklist-design-ux-footer-theme-footer-column-headings-stand-out": {
+        roles: ["guest"],
+        startPage: "/",
+        steps: [
+            "Open / in a private window and scroll to the footer.",
+            "Read each column heading and the links beneath it.",
+            "Compare each heading's weight and size against its own links.",
+            "Switch to dark mode and compare them again.",
+        ],
+        expectedBehaviour: "A column heading is visually distinct from its links, so the footer reads as grouped columns rather than one long list. The distinction has to survive both themes, since it usually comes from a colour token.",
+        expectedUiState: "Every heading is clearly heavier or larger than the links under it, in both themes. A heading indistinguishable from its own links is the failure — the grouping is then invisible and the footer reads as noise.",
+        endResult: "Read-only; return the site to light mode afterwards.",
+    },
+    "checklist-design-ux-footer-theme-footer-weight-both-themes": {
+        roles: ["guest"],
+        startPage: "/",
+        steps: [
+            "Open / in a private window in light mode and scroll to the footer.",
+            "Write down how the footer reads: heading weights, link contrast, divider visibility.",
+            "Switch to dark mode without navigating.",
+            "Read the same three things again and compare.",
+            "Look specifically at any divider or border between columns or rows.",
+        ],
+        expectedBehaviour: "The footer's visual hierarchy is the same in both themes because every colour is a token that inverts. A divider declared once under the root and never inverted is invisible in one of the two.",
+        expectedUiState: "Headings, links and dividers all read equivalently in both themes. A divider visible in light and gone in dark — or the reverse — is the failure this case is looking for.",
+        endResult: "Read-only; return the site to light mode afterwards.",
+    },
+    "checklist-design-ux-footer-theme-footer-mobile-accordions": {
+        roles: ["guest"],
+        startPage: "/",
+        steps: [
+            "Resize the browser window to 390 pixels wide and open / in a private window.",
+            "Scroll to the footer.",
+            "Read how the columns are presented.",
+            "Expand one section and read its links.",
+            "Collapse it and expand another.",
+            "Try to scroll the page sideways.",
+        ],
+        inputs: { mobileWidth: 390 },
+        expectedBehaviour: "On a phone the columns collapse to accordions so the footer does not become a screen-and-a-half of links. Collapsing must remove the section's height rather than hide it by transform, or the page keeps the full footer's length with nothing in it.",
+        expectedUiState: "Sections are collapsed by default and expand on tap, showing their links. A collapsed section takes no vertical space. The page does not scroll sideways.",
+        endResult: "Read-only; restore the window width afterwards.",
+    },
+};

package/dist/features/tester/seed-data/authored/design-ux__form-validation-errors.d.ts

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