Taste

Defines tunable/magic numbers as named module-level constants in the SAME file where they are used (e.g., const TOKENS_PER_QUEUE_MESSAGE = 5 next to the code it configures, with a short explanatory comment) instead of inline literals or a shared/global config — explicitly stated: "Define 5 as a constant in the same file." Confidence: 0.7
Prefers that the agent not run typechecks; instead, read the project's AGENTS.md for instructions on what to do/not do before finalizing work. Confidence: 0.9
Judges completion by seeing the feature live in the running app ("I still don't see it on the /home route page"), so for data-driven features the agent must verify the app's actual runtime data source (API base URL, cache/backend) has the required data — not just that code builds and typechecks. Confirmed when the user signaled success only after the fix (pointing web-ui at the local backend with the tags data) made the section visible in the running app, and reconfirmed with the admin-ui product selector showing no products because it points at the production worker. Confidence: 0.9
Prefers detailed analysis and explicit error/mistake checking before executing destructive operations, rather than just performing the action — e.g., before a git merge, or before deleting a row directly from the DB (asked "Can I simply delete the row from db. Will it cause any problems" about an unclaimed reserved coupon, expecting the agent to trace all referencing tables/FKs — couponUsages, couponApplicableUsers/Products — before answering). Confidence: 0.7
Do not run git stash or other destructive git operations that would discard or modify working-tree changes without explicit permission. Confidence: 0.9
When removing unused code (e.g., an unused tRPC procedure), prefers a complete cleanup: also remove internal helper methods used only by it, associated types, re-exports, orphaned hook/API files and their shared types, and even commented-out imports, leaving zero remaining references. Confidence: 0.9
Before removing or deciding on code, likes to first verify where it is actually used across the codebase (asks questions like "where is X used"), rather than removing based on assumption. Confidence: 0.4
Prefers light/pastel colors for randomized or accent UI elements (e.g., tabs, chips). Confidence: 0.7
Prefers minimal, flat tab/navigation UI: active state shown with a thick underline, no pill/chip backgrounds or rounded fills; communicates desired visual styles by sharing reference images/screenshots. Confidence: 0.8
Wants the agent to come up with a plan first before implementing code changes. Confidence: 0.9
Appreciates being asked clarifying design questions with concrete options during planning. Confidence: 0.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
When requesting test plans, expects exhaustive coverage across all relevant apps/screens/routes, including every functionality and every edge case. Confidence: 0.9
Verifies that changed code introduces no NEW type errors beyond a project's pre-existing baseline (e.g., by temporarily stashing changes to compare typecheck output), and fixes even pre-existing type errors in files he heavily edits. Confidence: 0.8
Prefers test case documentation to be structured with preconditions, steps, explicit "things to test" checklist, and expected results. Confidence: 0.7
Prefers test plans written for a non-technical audience, using plain-language, click-by-click instructions ("tap this", "type that", "check there") rather than technical terms or API names. Confidence: 0.9
When updating or creating a document, prefers the agent first compare it against existing source documents, identify missing items or gaps, and add them in the same established format. Confidence: 0.9
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.9
Wants feature parity maintained between the web-ui and user-ui apps (port logic/data patterns, rebuild UI per platform) — e.g., when he asks for a link in the cart page "at the coupons section" of @apps/user-ui/components/cart-page.tsx, he means mirror user-ui's coupons section (card, header, icon) in web-ui and add the requested link there; and conversely asks for features added in one app to be added to the sibling app "too" (e.g., "add the coupon redirection on the user-ui cart-page too"), expecting the agent to locate the equivalent component/route and replicate it. Confidence: 0.98
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.9
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
Values end-to-end analysis of features (architecture, data model, flows, integrations, and edge cases) when asked to explain how something works. Confidence: 0.7
When creating a clone/mirror of an app on a different platform (e.g., a web version of a React Native app), expects EXACT replication — functionality and looks must match the reference app with zero changes ("not even a slight change is acceptable"). The tech stack is inherited from the existing clone, not the original. The exactness requirement applies per section and down to every sub-page: naming a section of the RN app (e.g., "the 'me' section and all its sub pages") means the entire subtree must be an exact replica of the mobile screens, and he will flag remaining gaps ("I see a lot of gaps") if any sub-screen diverges — so the agent should audit every sub-page, not just the section hub, against the RN source of truth. Confidence: 0.95
Prefers unifying parallel data structures into a single instance rather than maintaining separate ones (e.g., one cart for flash and regular items instead of separate flash/regular carts). Confidence: 0.9
Prefers using sentinel values in existing fields (e.g., slotId = 0) to distinguish special-case items rather than creating separate fields or structures. Confidence: 0.9
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.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
When a bug reproduces only on a deployed API (e.g., devapi) but not against the local backend, expects the agent to investigate the environment difference — which API base URL the app actually points to, wrangler/D1 bindings, and the deployed bundle version — rather than assuming identical code paths. Confidence: 0.65
Keeps operational runbooks / command documentation (e.g., apps/backend/wrangler-commands.md documenting the D1 export table-ordering trap) in repo markdown files and expects the agent to read them and apply the documented procedure when performing the related operation (e.g., fixing dump table order), treating the doc as the source of truth for the fix. Confidence: 0.65
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
Cares about the exact user-facing wording of labels and explicitly dictates renames (e.g., "Total Savings" → "Total Discount" on the cart page), expecting the change to be applied exactly as specified — including new labels dictated verbatim in the request (e.g., a link literally named "Add Coupons to account", a button that "should say Add Multiple", not paraphrased). Confidence: 0.8
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", "I see [id]/index instead of product name in the top bar"), often with a hypothesis about the cause ("maybe we're not fulfilling conditions to enable"); expects the agent to trace the actual code path and find the root cause rather than just making the UI appear to work. Confidence: 0.65
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
For text that wraps next to a leading icon in a chip/label (e.g., the delivery-date chip with a truck icon), constrains multiline text to a maximum of 2 lines (line-clamp-2) and pins the icon to the top of the first line (items-start + shrink-0 + top margin on the icon) so it never drops to a second line when the text wraps ("which takes at most 2 lines, with the truck on the first line"). Confidence: 0.6
When a fixed N-line block (e.g., the delivery-date chip capped at 2 lines) must carry an icon on line 1 only, he rejects relying on natural text wrapping: if the text naturally fits on one line, the second line renders empty ("still the same. I see truck and space below it in next line empty"). Prefers a DETERMINISTIC structure that explicitly fills every line — split the content into two deliberate lines (e.g., date on line 1 next to the icon, time on its own line 2) so line 2 always has content, rather than wrap/clamp heuristics that can leave a gap. Confidence: 0.75
Prefers minimal, chrome-free presentation for informational text like the delivery-date line: drop the background, border, and padding entirely and show just the text (and any leading icon) in the brand color at 70% opacity (text-brand-700/70), rather than a colored/bordered chip, after the layout was finalized ("remove the blue background and the padding. Just show the text in brand color but 70% opacity"). Confidence: 0.7
When a pinned leading icon reserves its own column in a chip, a subsequent wrapped text line must NOT carry over that reserved gap — the second line should span the full inner width with proper spacing, not leave an "open gap" where the icon column sits on the first line ("in the second line I don't see truck but the gap is open. It should have space"). Confidence: 0.45
When he wants a UI element/feature hidden for now (e.g., a delivery-date block), prefers the agent to comment the code out (wrapping in {/* ... */}) rather than delete it, so it can be easily restored later ("just hide the delivery date. just comment it out"). Confidence: 0.6
Prefers the product-card quantity line to carry an explicit "Qty:" label prefix before the formatted value — e.g., "Qty: 12Kg" — rather than showing the bare formatted quantity (e.g., just 12Kg). Confidence: 0.7
Prefers a lighter, more compact look for product-card text: the product name rendered at font-medium (not font-bold) and the card's content padding tightened (e.g., px-3 pt-2.5 pb-2.5 instead of px-4 pt-3 pb-3) — explicit instruction: "for the text of product name, reduce the weight and it's padding." He then continued tightening the horizontal padding by directly dictating the value ("make the padding px-1.5"), so expects the agent to apply exact spacing values he specifies. Confidence: 0.7
Prefers secondary/informational product-card text (e.g., the quantity line) in the brand color at 70% opacity (text-brand-700/70) rather than muted gray — "show the quantity in the branch [brand] color 70% opacity" — the same text-brand-700/70 treatment he chose for the delivery-date line, suggesting a recurring card-text color treatment for secondary info. When the line carries a label prefix (e.g., "Qty:"), only the VALUE part gets the brand color; the label stays muted gray and the value gets a touch more weight (font-semibold) to stand out — "only the value part. not the 'Qty'". Confidence: 0.7
During product-card decluttering passes, wants promo/discount badges (e.g., the "n% OFF" label) hidden too — prefers a clean, uncluttered product card with no discount badge overlays ("hide the n% off label too"), the same treatment previously applied to hiding the delivery-date block. Confidence: 0.6
Prefers bottom-sheet dialogs (the app's BottomDialog) for collecting simple input values (e.g., a count for bulk coupon generation) rather than separate screens or inline form sections — explicitly requested "it should open a bottom dialog and should take input of the desired count". Confidence: 0.4
Expects newly generated/derived data to be merged into existing state structures rather than managed separately — e.g., bulk-generated coupon codes appended to the existing couponCodes array because "we already have coupon codes as array". Confidence: 0.5
Expects back navigation in the mobile app to return to the screen he navigated from, not to an unrelated tab root — when a link from the cart page to the coupons page (which lives in another tab's stack) made pressing back land on the "Me" page instead of the cart, he reported it as a bug ("when I try to press back I don't come to the cart page again. I come to me page. why is that"); cross-tab navigation flows must preserve a way back to the origin screen. Confidence: 0.6
When the same screen can be reached from multiple entry points, wants its UI to adapt based on the entry point — e.g., the coupons page opened from the cart page (via a ?from=cart param) should hide the bottom tab bar while focused and restore it on leaving, while the same page opened from its own tab keeps the tab bar visible ("if coupons page is accessed from cart page, I want to hide the bottom nav bar"). Confidence: 0.7
For bulk/sequential generation from a code pattern (e.g., ABC12 → ABC13...), expects numbering to continue from the HIGHEST existing value so regeneration never re-emits already-entered codes — after entering ABC12, the next batch must start at ABC13, not restart at 12 (the first matching code). Confidence: 0.6
Dislikes UI that renders transient loading states as definitive business states — e.g., the home page showed every item as "out of stock" until slot data loaded, because the out-of-stock check treated "no slot yet" (data not loaded) as genuinely out of stock. Expects a "data loaded" guard so the UI never flashes a wrong definitive status (out of stock) before data arrives, while still applying real out-of-stock detection once loaded. Confidence: 0.7
When deleting a record, prefers the existing soft-delete/invalidate path over hard-deleting rows: the supported delete already sets isInvalidated: true (keeping history/audit and avoiding broken FK joins), and a raw hard delete should only be considered when confirmed nothing references the row (no usage records), with related rows (couponApplicableUsers/Products) removed transactionally to avoid orphans. Confidence: 0.75
When commissioning a dead-code audit of an app/package, expects a "close analysis" that is exhaustive across every category — dead, unreachable, and unused code: orphaned files, unreachable/unlinked routes, dormant or disabled-by-flag features, dead branches and commented-out blocks, and unused imports/exports — finding "every such code which serves no purpose" rather than only obviously-unreferenced files; findings should distinguish verified-dead items from merely dormant/judgment-call items. Confidence: 0.65
When an analysis/audit has been produced for one app in the monorepo, expects the same analysis run for the sibling apps too — after the user-ui dead-code audit he immediately asked "now do the same for the @apps/admin-ui" — applying the identical exhaustive methodology and document style to each named app. Confidence: 0.85
For analysis documents, expects a consistent naming pattern following the established convention (user_ui_dpsk.md → admin_ui_dpsk.md, i.e., {app}_dpsk.md at the repo root) rather than an ad-hoc filename — "make another md file with same naming pattern"; the _dpsk.md suffix also applies to cross-cutting topic analyses (e.g., repeat_types_dpsk.md for the repeated-types scan). Confidence: 0.9
When commissioning a cross-cutting audit/analysis, expects the scan to span the entire monorepo in one pass — every app, the backend, AND the shared packages (e.g., "scan the entire @apps/user-ui/ @apps/admin-ui/ @apps/backend/ and also entire @packages/") — not just one app or one area. Confidence: 0.65
Values type-level hygiene alongside runtime structures: wants repeated type declarations across the monorepo hunted down and classified (identical duplicates, near-identical/unifiable shapes, same-name-different-shape collisions) and documented in a report before any refactor, rather than fixing types piecemeal. Confidence: 0.6
Requires the parallel DB-helper packages (db_helper_sqlite and db_helper_postgres) to not duplicate type definitions: they must share one canonical set of types and emit exactly the same data shape, since they represent the same business entities on different backends — stated directly: "they shouldn't duplicate types. They should emit exactly same type of data. They should share the types." Confidence: 0.9
When the two DB-helper implementations diverge at the data-model level (sqlite is SKU-based with skuIds; the dormant postgres collapsed the SKU tier into productIds), the live/canonical model wins: the sqlite/SKU model — which packages/shared already standardizes on — is the source of truth and the dormant postgres helper is to be aligned/migrated to it (up to and including schema-level changes so even row types match), not the reverse. Confidence: 0.75
The dedup directive is general, not limited to DB helpers: for types that are "exactly same but repeated" anywhere in the monorepo, move them into a shared package (@packages/shared), organize them there with proper comments, and export/reuse them from that one source — "Do this for all the types which are same and repeated" (stated when asking to address the duplicate-type spread repo-wide). Confidence: 0.9
When organizing a shared type package, prefers to keep similar types together — all types that have identical properties should stay grouped/collocated so exact duplicates live side by side (e.g., clustering same-shaped types together in the shared files rather than scattering them). Confidence: 0.75
When he introduces a processing/batching parameter (e.g., a batch size such as "5 tokens per queue message"), expects it enforced end-to-end on BOTH sides of the pipeline — the write/enqueue producer AND the read/consumer/processing path — and follows up to confirm the read side honors the same limit ("we've also changed the code to read and process 5 tokens at a time right?"); a limit applied on only one side is treated as an incomplete change. Confidence: 0.6
Scrollable content (e.g., a product grid) must never be buried beneath a persistent floating UI element like the floating cart bar: pages that scroll above such a bar need sufficient bottom padding on the content container so the last row of items can scroll fully clear of the bar ("There should be enough padding in bottom. I see the last row of products buried beneath the floating cart bar. They should be scrollable"). Errs toward GENEROUS bottom spacing and iterates for more if it still feels tight — after the initial fix (matching siblings' mobile pb-24) he asked to bump it again ("it's improved but add some more padding"), landing at mobile pb-32 / desktop md:pb-16. Expects the fix to follow the sibling pages' bottom-padding pattern but lean roomier rather than matching the minimum. Confidence: 0.85
Prefers an incremental "load more"/"Show More" reveal model over rendering the entire product list at once on listing/dashboard pages: show a fixed batch at a time (the user-ui dashboard's All Products list shows 21 items and adds another 21 per click, hiding the button once all are visible) and expects the same model replicated in the sibling web-ui app ("we aren't showing all the items at once. We have a load more model. Implement the same on the @apps/web-ui too"), matching the reference's batch size and button behavior. Confidence: 0.8
For browser/E2E test automation, prefers Playwright and wants the suite placed in a tests/ folder at the project ROOT (not inside the app it targets) — "At the project root add a folder tests. I want playwright based tests". Confidence: 0.85
Wants E2E automation organized around long, multi-step, real user workflows executed in a SINGLE browser instance/session (e.g., add a product → update it → create a slot for it → suspend it), rather than split into isolated per-step tests — "I want to automate long tasks in a single instance". Confidence: 0.85
For the E2E harness itself: tests should drive whatever UI URL is targeted (no backend management from the harness), pull staff credentials from environment variables (not committed inline), and NOT auto-start the dev server — the app is assumed to be running. Confidence: 0.6
Wants automation tests (Playwright) to run with a VISIBLE browser, not headless — "I want to see the browser, I don't want it in headless mode" — so local runs should default to headed (CI may stay headless), with a convenience script/flag (e.g. test:e2e:headed, HEADED=0/1) to switch. Confidence: 0.85
Prefers names/labels displayed in FULL rather than truncated — e.g., product names in the cart drawer should wrap and show completely (text wrap / break-words instead of truncate) — "show the name full, if needed do text wrap". Confidence: 0.55
Wants the floating cart bar HIDDEN on routes where it is redundant — the cart page (including the flash cart alias) and the entire "me" section — and expects the condition to cover ALL child routes via a path-prefix check (pathname.startsWith('/me')) rather than matching only the parent route. Confidence: 0.6
Uses Bun as his package manager / package runner ("I use bun"), so whenever giving or documenting commands he expects bun run <script> / bunx <tool> rather than npm run / npx (including inside subfolders, e.g. bun run --cwd .. <script>). Confidence: 0.9
Expects generated test automation to be actually EXECUTED and passing, not just written/typechecking — he asks the agent to run the suite and report how many tests succeed ("try to run the script and see how many tests succeed"), treating a suite that was never run against a live app as unverified. Confidence: 0.65
Treats reports/audits (e.g., DEAD_CODE_REPORT.md) as claims to be independently verified against actual code usage, not trusted at face value: he asks the agent to read a report and confirm "if the pointed code is actually dead", expecting per-claim caller searches and explicit flags of false positives. Confidence: 0.75
Before shipping/publishing a branch, wants a pre-flight risk assessment rather than just execution: he names the last published reference branch and asks "Tell me if I'm going to face any problems" — expecting the agent to verify the current branch is a superset of what was published (no feature/migration/commit lost), that removed files and assets have no dangling references or build-config dependencies, and that build/typecheck integrity holds, then present blockers vs. non-blocking caveats (e.g., committed secrets) before he deploys. Confidence: 0.7
After performing removals himself, expects the agent to re-scan the codebase and independently confirm each item is actually gone (and that the removals didn't break anything) — "I've removed them. Check and tell me if all are gone" — treating his own "done" statement as a claim to verify rather than assuming completion. Confidence: 0.6
When asking to compare branches/versions (e.g., "compare the current branch's @apps/user-ui with the product_to_sku_c1 branch"), wants the answer framed "functionality wise" — a semantic/behavioral summary of what actually changed for the app and its users (new logic, changed API calls, changed UI, removed screens), explicitly distinguishing real functional changes from no-op churn (pure type imports, dead-code deletions, config tweaks which he should be told are non-functional), rather than a raw file/line diff dump. Confidence: 0.6
Wants order-item rows to display the pack size / unit notation (e.g., 2 × 500g · ₹250) alongside quantity and unit price, not quantity alone — composed via the existing shared composeUnitNotation helper and surfaced through the shared item type to both user-ui and web-ui. Confidence: 0.6
Prefers that disruptive user-facing dialogs be reserved for genuinely important events: the OTA update prompt should NOT be shown for every update — only for a few crucial releases ("I don't want to show this for all the updates. Only a few updates are so important"), while routine updates apply silently in the background. Confidence: 0.7
Uses "quantity" loosely to refer to the pack size / unit notation on order items: he reported "we aren't showing quantity" about a row that already rendered the numeric count, then clarified "yeah, show the pack size" — so when he says a quantity isn't shown, check whether he actually means the unit/pack-size notation is missing. Confidence: 0.55
For new operational switches/flags, prefers a backend constant in the admin-editable constants store (CONST_KEYS + seed + exposed via essentialConsts, editable in Customize App) over build/publish-time config (e.g. an expo.extra flag in app.json) or hardcoding — chosen when offered the trade-off ("let's introduce a new constant"), because it can be changed remotely with no rebuild or republish. Confidence: 0.6
Dislikes long lists of CLI flags for supplying run-time/test values and asks for a "better way" ("isn't there a better way to supply the values"). Expects values supplied declaratively: non-secret defaults committed in a config file (e.g. Maestro config.yaml env: block), secrets in a gitignored .env-style file, and a thin wrapper/runner script wired to a single package-manager entry point (bun run e2e) so one short command runs everything — with extra flags still passable through. Secrets should never be passed inline on the command line or committed. Confidence: 0.7
When he doubts the current approach ("isn't there a better way"), expects the agent to actually research the tool's documented capabilities (check --help, official docs) before proposing alternatives, rather than answering from memory. Confidence: 0.6
For mobile app E2E testing, wants Android ONLY and never iOS — stated explicitly: "I want to test only on android. Never on ios." The test runner/harness should be wired so it can never target an iOS simulator (e.g., pin the Android package id and always pass --platform android), rather than auto-detecting the platform from booted devices. Confidence: 0.9
For React Native / Expo mobile E2E automation, prefers Maestro (not Detox/Appium), with its flow configs in a folder at the repo ROOT named e2e/ — "I want test end to end test automation with maestro. have a folder at the root named e2e" — mirroring his tests/-at-root convention for Playwright. Expects the tool's own YAML workspace layout inside it (config.yaml, flows/, reusable subflows/), not per-app test dirs. Confidence: 0.85
Wants E2E flows to take the shortest realistic user path and skip unnecessary intermediate screens — e.g., add to the cart directly from the home product card's cart icon instead of opening the product-detail screen first ("don't open any product detail. Just click on the cart icon of any product, then go to the cart page and then place order"). Confidence: 0.5
When he pastes a runtime error/log (e.g., a tRPC/D1 Failed query: select ... from "key_val_store" 500), he asks for an explanation first — "what does this error mean. Why am I seeing it" — expecting the agent to investigate and explain the root cause (local D1 state, migrations/config) before changing any code, not to jump straight to a fix. Confidence: 0.5 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 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 tes; 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 y, including details like item counts and container styling. Confidence: 0.9 tes; 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 olor 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 tes; 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 y, including details like item counts and container styling. Confidence: 0.9 tes; 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

46 KiB Raw Blame History Unescape Escape

Taste

46 KiB

Raw Blame History