diff --git a/.commandcode/taste/taste/taste.md b/.commandcode/taste/taste/taste.md index 272ba98..a98342a 100644 --- a/.commandcode/taste/taste/taste.md +++ b/.commandcode/taste/taste/taste.md @@ -12,6 +12,7 @@ - Prefers embedding related data into existing cache files over creating or calling separate API endpoints. Confidence: 0.9 - Prefers using icons from Hicons (rather than custom/hand-authored SVGs or other icon libraries). Confidence: 0.9 - When a feature or page is repurposed, wants file names, route names, and code references renamed to match the new purpose (not just UI content/icons). Confidence: 0.8 +- When replicating a UI pattern (e.g., home page tabs) onto a different page/context, adapt the copied colors to that page's own brand accent (e.g., the flash page's tabs use the flash pink `text-flash-600`/`bg-flash-500` instead of the home page's brand blue) while keeping the layout and styling identical. Confidence: 0.6 - Wants analysis findings and plans persisted in a markdown file before any implementation begins, with explicit confirmation that implementation is paused until instructed. Confidence: 0.8 - When changing cache or storage keys, wants both the read and write paths verified to use the same single source of truth (e.g., a shared `CACHE_STORAGE_KEYS` constant). Confidence: 0.8 - In React Native with react-native-paper's `Text` component (wrapped as `MyText`), prefers avoiding mixed string/expression children; use template literals to produce a single string child to prevent "Text strings must be rendered within a component" warnings. Confidence: 0.8 @@ -23,6 +24,8 @@ - Dislikes nested headers in mobile/drawer navigation; prefers a single, shared header (e.g., the drawer header) and relies on device back buttons or gestures for returning to previous screens. Confidence: 0.9 - After reviewing a presented plan, prefers brief, action-oriented approval (e.g., "nice. go ahead", "go ahead and implement") before implementation proceeds, expecting the agent to autonomously execute the already-presented plan. Confidence: 0.85 - Wants feature parity maintained between the web-ui and user-ui apps (port logic/data patterns, rebuild UI per platform). Confidence: 0.95 +- Wants the web-ui home page section/component order to match the reference user-ui home page exactly (e.g., "on the home page have the order same as that of @apps/user-ui/.../home/index.tsx"), including when deciding placement of sections like Explore, Stores, Slots, and All Products. Confidence: 0.7 +- Wants brand/logo spots to use the single real brand logo asset (shared across apps, e.g., the Freshyo splash logo) displayed as an image, not a generic/decorative icon (e.g., a "meat piece" Meat/Beef icon) — web-ui should be on par with user-ui and show the same logo; applies to favicon, PWA icons, and every in-UI branding spot (sidebar, topbar, login, home banner). Confidence: 0.85 - Prefers dead-code audits to be documented in a markdown file. Confidence: 0.8 - Prefers detailed technical documentation of system architecture, data models, flows, and integrations in markdown format. Confidence: 0.8 - Wants edge cases explicitly enumerated when documenting or analyzing existing code/systems. Confidence: 0.8 @@ -32,9 +35,13 @@ - Prefers handling special-case logic locally in the relevant component/file rather than globally or via parallel flows. Confidence: 0.85 - Prefers lazy/virtualized list rendering (e.g., FlatList) for long lists, rather than rendering all items at once. Confidence: 0.8 - Wants true responsive web design for desktop, not just color/theme changes or mobile layouts stretched to desktop. Confidence: 0.95 +- Specifies layout proportions in relative terms rather than fixed pixel sizes — e.g., the left sidebar/menu should be 20% of the viewport width at most ("the left menu should be 20% of width at max"), implemented as a viewport-relative track (20vw) rather than a hard-coded px column. Confidence: 0.7 +- On the web-ui, wants the topbar (logo/search/cart) hidden on mobile screens and only rendered from the tablet breakpoint (`md`, 768px) upward, since mobile gets its own bottom navigation; when hiding it, the surrounding grid layout must be cleaned up so no empty reserved space remains. Confidence: 0.8 +- The search bar must be independent of the topbar and always visible on every screen size; decoupling it from the topbar's tablet-only visibility — hiding the topbar must not hide search ("the search bar... should be independent of the top bar. I want it visible always"). When a page already has its own search UI (e.g., the search route's sticky header), the global always-visible search row should be suppressed there to avoid stacked duplicate bars. Confidence: 0.8 +- Wants the search bar (and other persistent page-level UI like the topbar) to be sticky, pinning to the top of the viewport while the page scrolls ("I see it's not sticky. I want it sticky"); to make sticky actually work, the header group should live in a full-height flex column rather than a bounded grid row that scrolls away. Confidence: 0.9 - Does not want color/theme changes during redesigns — keep colors and theme consistent with the existing apps (e.g., @apps/user-ui): reuse the shared theme tokens (Untitled UI blue brand scale, flash pink accent, gray neutrals) rather than introducing new brand palettes; approval of a redesign's layout/composition does not imply approval of color or theme changes. Confidence: 0.95 roducing new brand palettes; approval of a redesign's layout/composition does not imply approval of color or theme changes. Confidence: 0.95 -er-ui/app/(drawer)/(tabs)/home/index.tsx, I want similar here") and expects the agent to mirror that pattern exactly, including details like item counts and container styling. Confidence: 0.9 +er-ui/app/(drawer)/(tabs)/home/index.tsx, I want similar here") and expects the agent to mirror that pattern exactly, including details like item counts and container styling. Confidence: 0.95 - Combo-only SKUs (`isComboOnly` on `product_skus`) must be hidden from all user-facing product surfaces — home page, offers page, and any other list where they could appear ("Don't display them. We're hiding them from home page too"). Confidence: 0.75 - Expects a filter/business rule already applied on one page to be applied consistently on every other page showing the same data, not just the page he happened to notice ("we need to hide them here too"). Confidence: 0.85 - Debugs by adding temporary console.log debug prints to inspect runtime data (e.g., `console.log({skusData})` to check a query result) and reports the observed values to the agent as ground truth (e.g., "the database is same. I've checked"). Confidence: 0.75 @@ -43,6 +50,7 @@ er-ui/app/(drawer)/(tabs)/home/index.tsx, I want similar here") and expects the - Prefers monetary amounts (totals, discounts, savings) displayed as whole numbers only — explicitly truncates decimals (e.g., `Math.trunc()`) rather than rounding, keeping internal calculations at full precision and truncating only at the render site ("Just truncate and show only the whole number"). Confidence: 0.7 - When displaying savings/benefit lines, hides the row entirely unless the amount exceeds a meaningful threshold (e.g., "show only if the savings is greater than rs 1") so the truncated whole-number display never shows a negligible ₹0/₹1 saving. Confidence: 0.55 - Prefers out-of-stock items pushed to the end of product list sections (e.g., home page tab sections) while preserving the existing/admin-curated order — a stable partition (in-stock first, out-of-stock last, relative order kept within each group), reusing the same out-of-stock detection rule used elsewhere on the page ("preserve the order but push the out of stock items to last"). Confidence: 0.7 +- Wants product grid sections (e.g., Explore Products, All Available Products on the home page) to render at least 3 columns even on the smallest screens, scaling up on larger breakpoints — prefers the minimum column count on mobile to not be reduced to 2. Confidence: 0.7 - Tracks previously discussed/planned fixes and follows up to verify they were actually applied (e.g., "did we take care of the math.trunc"); expects the agent to check the current state of the code and apply any outstanding planned changes rather than assume they were completed. Confidence: 0.8 - Prevents contradictory/invalid states in admin forms by hiding the inapplicable control entirely — including its label/text row — rather than leaving it visible but disabled (e.g., the entire "Combo Only SKU" checkbox row is hidden when the SKU itself is a combo — has combo items — not just disabled). Confidence: 0.6 - Wants savings figures kept consistent across all order surfaces: a savings concept shown in the cart/checkout bill (market price − offered price) must also be reflected in the order confirmation summary ("you saved n on this order"), aggregating all savings sources (coupon discount, market-price savings, free delivery) rather than only the coupon/discount component. Confidence: 0.85 @@ -50,6 +58,22 @@ er-ui/app/(drawer)/(tabs)/home/index.tsx, I want similar here") and expects the - When a button/feature is broken on one page but works on a sibling page (e.g., "Edit Notes" in the order-list three-dot menu vs. the order detail page), expects it fixed to behave like the working page — including calling the proper API with the correct parameter types (numeric order id matching the backend's zod schema, not a stringified id) rather than a no-op or wrong call. Confidence: 0.7 - Reports UI bugs by pointing at the specific file and describing the intended action plus the visible symptom (e.g., "submit not happening"), often with a hypothesis about the cause ("maybe we're not fulfilling conditions to enable"); expects the agent to trace the validation/submit path and find the root cause rather than just making the UI appear to work. Confidence: 0.6 - Expects form validation and submit-enable conditions to match the current UI mode: fields hidden by a mode toggle (e.g., the single coupon-code field when "reserved coupon" is selected) must not be required, and discount-type toggles should not pre-fill placeholder values (like 0) that fail the `> 0` validation — hidden/placeholder state must never block submission. Confidence: 0.55 +- On mobile screens, prefers abbreviated button labels to conserve horizontal space — e.g., the add-to-cart button shows just the cart icon + "Add" on mobile and the full "Add to Cart" label from the `md` breakpoint up ("if the screen is mobile one just show cart symbol and Add instead of Add to cart"), implemented with responsive `md:hidden` / `hidden md:inline` spans. Confidence: 0.8 +- Expects the UI to reflect state changes immediately after an action, without a manual page refresh — e.g., items added to the cart must show up in the cart/badge right away; reports staleness bugs as "added items are not visible unless page is refreshed. They are added but not shown in cart," distinguishing that data was persisted (localStorage) but the UI didn't update. Confidence: 0.7 +- Wants the same UI component variant used consistently across every section/page in the app: when the user designates one section as having the "correct" version of a component, that exact section is the reference and its variant must be replicated everywhere else. Confirmed by an explicit correction: the Explore tabs section's mini floating cart icon (`miniView={true}`) was the correct one — "what was first present in tabs section, should've been replicated elsewhere" — i.e., replicated to All Products, search results, offers, and store detail, not the other way around. He expects the agent to follow the stated direction precisely and will correct a swapped interpretation. Confidence: 0.9 +- When the user asks for "similar tabs" on a page (e.g., the home page's category tabs on the 1-hr flash page), they mean the tabs model should REPLACE the page's existing filter/navigation mechanism — e.g., the store selector sidebar — entirely, not be layered on top of it ("I meant, replace the store selector with tabs model"). The page should use a single, consistent navigation/filter model like the home page, not two stacked filter controls; expects the agent to remove the superseded component and its now-unused imports/state. Confidence: 0.85 +- Dislikes transparent backgrounds on UI controls that overlay content — e.g., the quantity stepper floating over product images must have a solid background (white with a subtle shadow) so it reads clearly over any image, not a transparent one ("the background of the quantifier is transparent. Don't do that."). Confidence: 0.7 +- Modal dialogs (e.g., the add-to-cart dialog) must always layer above persistent fixed UI — the floating cart bar and the bottom navigation — never behind them; states the rule explicitly: the bar "shouldn't have more z index than the dialog," on both mobile and desktop. On mobile, interactive dialog content (the Add/Update button) must also clear the bottom nav (higher z-index than the nav's z-50 plus mobile-only bottom padding) while desktop behavior stays unchanged ("Move it a little top in case of mobile view"). Confidence: 0.75 +- In any cart surface, decrementing a quantity stepper down to 0 must remove the item from the cart entirely (make it disappear), never leave it persisted at quantity 0 — expected both on the cart page and in the cart slide-over opened from the floating cart bar, and the user will explicitly correct which surface he meant if the fix targets the wrong one ("I'm unable to click - to make it 0 and disappear" / "I clicked the cart bar to open cart view. There I'm not able to make '0' and remove"). Confidence: 0.7 +- In Tailwind v4 apps, arbitrary-value classes (e.g., `z-[60]`) authored in external/shared packages (like `packages/web-components`) can be silently dropped by the content scanner even when sibling classes from the same file compile — so for critical layering/positioning, prefer built-in scale values or an inline `style={{ zIndex: ... }}` and verify the compiled output (CSS/JS bundle) actually contains it rather than trusting the class source. Confidence: 0.7 +- In modal dialogs that contain a list plus a primary action (e.g., the add-to-cart dialog with delivery slots and an Add to Cart button), only the list region should scroll — the header and footer (quantity + action buttons) stay pinned and always visible, so reaching the primary action never requires scrolling ("only the slots should be scrollable... I need to scroll down to see the add to cart button"); implemented as a flex column with a fixed header, a `flex-1 min-h-0 overflow-y-auto` scrollable middle, and a `shrink-0` footer. Confidence: 0.75 +- On narrow/small screens, prefers text to scale DOWN to avoid crowding — prices/amounts and general card text alike: e.g., cart item prices `text-sm` on mobile bumping to `text-base` at the `sm` breakpoint, product card prices `text-base` → `text-lg`, and tightened vertical gaps near the quantity row ("if the width is small, reduce the price size and also the gap below the quantity"). Explicitly generalized to all card text (name, price, unit/quantity) with the direct request "when the screen width is small, reduce the font size too" — implemented as smaller arbitrary sizes (e.g., `text-[13px]`, `text-[15px]`, `text-[11px]`) below the `sm` breakpoint returning to normal sizes at `sm` and up. Explicitly requested and then repeatedly reinforced ("I still see large blue text in price"). Confidence: 0.8 +- When he reports a visual issue persisting ("I still see the same"), he is referring to the same visual pattern (e.g., "large blue text in price" = any `text-brand-600` price across cart pages, product cards) wherever it appears — expects the agent to grep the whole codebase for every occurrence of the matching styling and fix them all, not just the one surface initially identified. Confidence: 0.7 +- When a spacing/visual complaint persists ("I still see the gap below the quantity"), the same issue may live in a different rendering mode of the component than the one already fixed — e.g., product cards in `miniView` where the quantity control overlays the image and the gap comes from the unit-line bottom margin plus the card's bottom padding, not the cart slide-over that was edited first. Expects the agent to re-inspect the actual rendered layout of each variant/mode and tighten spacing everywhere the pattern appears. Confidence: 0.6 +- Prefers vertical tab/sidebar lists for store/category selection on ALL screen sizes — a vertical sidebar layout must not be swapped to a horizontal scrolling chip strip on mobile ("on the flash screen, the store tabs are horizontal, they should have been vertical"); instead keep the vertical list, stacked full-width above the content on small screens and as a sticky rail on desktop. Confidence: 0.7 +- When adopting the tabs model to replace a store filter, the tabs must be driven by the same dimension as the replaced filter — one tab per store, labeled by the store name, with each tab showing only that store's items (per-tab scoped content), not category/product tags. Explicitly corrected after a misinterpretation ("the tab labels should be store names. In every tab we need to show the items of that store"). Confidence: 0.8 +- When replicating a horizontal scrollable tab strip (store/category tabs) from user-ui to web-ui, expects identical interactive behavior, not just styling — the active tab must auto-scroll into view on selection so clicking a right-most tab brings it fully into view (matching user-ui's scroll-to-tab-position behavior, e.g., scroll to `offsetLeft - 16`), and the same auto-scroll must be applied consistently to every page using that tab strip pattern ("the tabs aren't behaving same as user-ui. They aren't auto scrolling when I try to click a right most tab"). Confidence: 0.8 +- For compact product cards (price, strike-through market price, quantity), dictates a specific vertical stacking layout rather than a side-by-side row: show the price first, then the struck market price on the same line, and the quantity on a new line below ("first show the price, then the striked price, in new line show the quantity") — this supersedes earlier attempts to pin the quantity to the right of the same row. Confidence: 0.7 e changes. Confidence: 0.95 er-ui/app/(drawer)/(tabs)/home/index.tsx, I want similar here") and expects the agent to mirror that pattern exactly, including details like item counts and container styling. Confidence: 0.9 als) rather than introducing new brand palettes; approval of a redesign's layout/composition does not imply approval of color or theme changes. Confidence: 0.95 diff --git a/apps/web-ui/public/freshyo-logo.png b/apps/web-ui/public/freshyo-logo.png new file mode 100644 index 0000000..83f0a8c Binary files /dev/null and b/apps/web-ui/public/freshyo-logo.png differ diff --git a/apps/web-ui/public/logo192.png b/apps/web-ui/public/logo192.png index fc44b0a..c1c782e 100644 Binary files a/apps/web-ui/public/logo192.png and b/apps/web-ui/public/logo192.png differ diff --git a/apps/web-ui/public/logo512.png b/apps/web-ui/public/logo512.png index a4e47a6..2053b8b 100644 Binary files a/apps/web-ui/public/logo512.png and b/apps/web-ui/public/logo512.png differ diff --git a/apps/web-ui/public/manifest.json b/apps/web-ui/public/manifest.json index 078ef50..a3831d6 100644 --- a/apps/web-ui/public/manifest.json +++ b/apps/web-ui/public/manifest.json @@ -1,11 +1,11 @@ { - "short_name": "TanStack App", - "name": "Create TanStack App Sample", + "short_name": "Freshyo", + "name": "Freshyo", "icons": [ { - "src": "favicon.ico", + "src": "favicon.png", "sizes": "64x64 32x32 24x24 16x16", - "type": "image/x-icon" + "type": "image/png" }, { "src": "logo192.png", @@ -20,6 +20,6 @@ ], "start_url": ".", "display": "standalone", - "theme_color": "#000000", + "theme_color": "#0033CC", "background_color": "#ffffff" } diff --git a/apps/web-ui/src/components/AddToCartDialog.tsx b/apps/web-ui/src/components/AddToCartDialog.tsx index c1de297..af2b292 100644 --- a/apps/web-ui/src/components/AddToCartDialog.tsx +++ b/apps/web-ui/src/components/AddToCartDialog.tsx @@ -139,7 +139,7 @@ export default function AddToCartDialog() { -
+
{availableSlots.map((slot: any) => (