| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 0 | 14 | 0% |
| Commands | 0 | 0 | 1 | 0% |
| Section tags | 2 | 1 | 6 | 22% |
What each file covers
Sections
0 shared · 0 only in A · 14 only in B- + SneakInMarket Project Conventions
- + Project-Specific Requirements
- + Enum Usage Requirements
- + Key Enums to Use
- + Component Structure Patterns
- + Authentication Flow
- + Cart and Checkout Flow
- + Product Management
- + Mobile-First Design Requirements
- + Error Handling Patterns
- + Performance Requirements
- + Testing Scenarios
- + Code Organization
- + Build and Deployment
Commands
0 shared · 0 only in A · 1 only in B- + npm run build
Section tags
2 shared · 1 only in A · 6 only in B- − do-not
- + build
- + test
- + architecture
- + types
- + ui
- + performance
- code-style
- security
Line diff
KAMAL20201/SneakerMarketplace · AGENTS.md
@@ −1 @@
1Codex Workspace Rules (AGENTS.md)
2
3Purpose
4- This file defines project-specific rules and preferences that Codex reads before answering any chat in this workspace.
5- Keep it concise and concrete. Place non-obvious, high-impact rules first.
6
7Cursor Rules
8- Also read and honor all rules in `.cursor/rules/*.mdc` for this project.
9- If any guidance conflicts, `.cursor/rules` takes precedence for this repo.
10
11Behavior Rules
12- Always: Ask 1–2 clarifying questions when scope or intent is ambiguous.
13- Always: Explain planned terminal actions briefly before running commands.
14- Always: Keep answers concise by default; expand only when asked.
15- Ask First: Before running destructive commands (rm/reset) or installing packages.
16- Ask First: Before changing config, adding dependencies, or altering build settings.
17- Never: Expose secrets or print full .env contents in answers or logs.
18
19Style and Tone
20- Tone: Friendly, direct, and efficient. Avoid filler.
21- Responses: Use short sections and bullet lists when they improve scanability.
22- File References: Use clickable paths like `src/file.ts:42` (single line only).
23
24Task Execution
25- Scope: Make minimal, surgical changes focused on the user’s request.
26- Tests: If tests exist, run targeted tests for modified code first.
27- Validation: Prefer small, verifiable steps; summarize progress between steps.
28- Plans: Use the plan tool for multi-step or ambiguous work only.
29
30Code and Project
31- Stack: Vite + React + TypeScript (see `package.json`).
32- Formatting: Match existing style; do not add formatters unless requested.
33- Types: Prefer explicit types in new/changed code; avoid one-letter names.
34- Security: Treat environment variables and credentials as sensitive.
35
36Shell and Approvals
37- Approval Mode: Default to asking before actions needing elevated permissions or network.
38- Sandboxing: Assume workspace-write, network restricted; call out when escalation is needed.
39- Commands: Prefer `rg` for search; read files in <=250-line chunks.
40
41Response Defaults
42- Brevity: Target 3–8 lines unless detail is necessary.
43- Structure: Use short headers sparingly; avoid over-fragmentation.
44- Monospace: Wrap commands, paths, env vars, and identifiers in backticks.
45
46When In Doubt
47- Clarify requirements, propose a minimal plan, and confirm before large changes.
48
49Project-Specific Rules (Customize Below)
50- Backend: Supabase is the source of truth (DB/Auth/Storage/Edge Functions). Do not add custom servers. Use Edge Functions for server logic.
51- Supabase Calls: Avoid redundant fetches. Cache shared data in React Context; expose typed hooks and explicit invalidate/refresh methods.
52- Pagination: For any list/multi-item fetch, implement pagination; show fewer items first and add page controls at the bottom.
53- Dependencies: Install latest stable versions. If unsure about API/usage, ask for a docs link and confirmation before adding. Request approval before changing build/config deps.
54- TypeScript: Use strict typing in all new code. Do not change existing TypeScript config; ensure new code compiles under current strictness. Never use `any`.
55- Mobile UI: Design mobile-first (320px+). Use Tailwind responsive prefixes (`sm:`, `md:`, `lg:`, `xl:`). Ensure touch targets ≥44px and test across screen sizes.
56- UI Patterns: Follow shadcn/ui and Radix-based components in `src/components/ui/`; keep props minimal and typed.
57- Secrets: Never echo or log values from `process.env.*`.
58
59Notes
60- Adjust or expand sections above to reflect your preferences.
61- This file is intended to be read as high-priority context at session start.
62
KAMAL20201/SneakerMarketplace · .cursor/rules/project-conventions.mdc
@@ +1 @@
1# SneakInMarket Project Conventions
2
3## Project-Specific Requirements
4
5- **Marketplace Focus**: Sneakers, clothing, accessories, electronics, gaming, collectibles
6- **Seller-Buyer Platform**: Support both listing creation and purchasing flows
7- **Payment Integration**: Razorpay for Indian market payments
8- **Mobile-First**: Optimized for mobile users in Indian market
9- **Regional Features**: Pincode validation, address management, local delivery
10
11## Enum Usage Requirements
12
13- **Always use enums from `src/constants/enums.ts`**
14- **Never hardcode values that exist in enums**
15- **Use enum types for TypeScript interfaces**
16
17### Key Enums to Use
18
19```typescript
20// Routes - use ROUTE_NAMES for navigation
21import { ROUTE_NAMES } from "@/constants/enums";
22navigate(ROUTE_NAMES.HOME);
23
24// Product conditions - use PRODUCT_CONDITIONS
25import { PRODUCT_CONDITIONS } from "@/constants/enums";
26const condition = PRODUCT_CONDITIONS.NEW;
27
28// Categories - use CATEGORY_IDS
29import { CATEGORY_IDS } from "@/constants/enums";
30const category = CATEGORY_IDS.SNEAKERS;
31
32// Listing status - use LISTING_STATUS
33import { LISTING_STATUS } from "@/constants/enums";
34const status = LISTING_STATUS.APPROVED;
35```
36
37## Component Structure Patterns
38
39- **Feature Components**: Place in `src/components/` (e.g., `Cart/`, `checkout/`)
40- **UI Components**: Place in `src/components/ui/` (shadcn/ui style)
41- **Page Components**: Place in `src/pages/`
42- **Context Providers**: Place in `src/contexts/`
43
44## Authentication Flow
45
46- **Public Routes**: Use `PublicRoute` component for login/signup
47- **Protected Routes**: Use `ProtectedRoute` component for authenticated users
48- **Admin Routes**: Use `AdminRoute` component for admin-only access
49- **Context**: Use `useAuth()` hook for authentication state
50
51## Cart and Checkout Flow
52
53- **Cart Context**: Use `useCart()` hook for cart management
54- **Multi-step Checkout**: Cart → Shipping → Payment
55- **Address Management**: Use `useAddressStorage()` hook
56- **Payment Integration**: Razorpay with proper error handling
57
58## Product Management
59
60- **Listing Creation**: Multi-step form with image upload
61- **Image Compression**: Use `imageCompression` utility
62- **Status Management**: Draft → Review → Approved/Rejected
63- **Condition Badges**: Use `ConditionBadge` component
64
65## Mobile-First Design Requirements
66
67- **Touch Targets**: Minimum 44px for interactive elements
68- **Responsive Breakpoints**: 320px+ (mobile), 768px+ (tablet), 1024px+ (desktop)
69- **Navigation**: Mobile-friendly navigation patterns
70- **Forms**: Optimized for mobile input
71
72## Error Handling Patterns
73
74- **Toast Notifications**: Use `sonner` for user feedback
75- **Loading States**: Skeleton components and spinners
76- **Form Validation**: Zod schemas with clear error messages
77- **API Errors**: Graceful fallbacks and retry mechanisms
78
79## Performance Requirements
80
81- **Image Optimization**: Use `OptimizedImage` component
82- **Lazy Loading**: Implement for heavy components
83- **Bundle Splitting**: Consider for large pages
84- **Caching**: Implement appropriate caching strategies
85
86## Testing Scenarios
87
88- **User Flows**: Complete buyer and seller journeys
89- **Mobile Experience**: Test on various screen sizes
90- **Payment Flow**: Test successful and failed payment scenarios
91- **Form Validation**: Test all validation rules
92- **Error States**: Test error handling and recovery
93
94## Code Organization
95
96- **Import Order**: External → Internal → Types → Utils
97- **File Structure**: Follow existing patterns
98- **Naming**: Use descriptive, consistent names
99- **Documentation**: Comment complex logic and business rules
100
101## Build and Deployment
102
103- **TypeScript**: Strict mode, no compilation errors
104- **Bundle Size**: Monitor and optimize large chunks
105- **Environment**: Use proper environment variables
106- **Build Command**: Always run `npm run build` before committing
107 description:
108 globs:
109 alwaysApply: false
110
111---
112
@@ −1 +1 @@
1−Codex Workspace Rules (AGENTS.md)
1+# SneakInMarket Project Conventions
22
3−Purpose
4−- This file defines project-specific rules and preferences that Codex reads before answering any chat in this workspace.
5−- Keep it concise and concrete. Place non-obvious, high-impact rules first.
3+## Project-Specific Requirements
64
7−Cursor Rules
8−- Also read and honor all rules in `.cursor/rules/*.mdc` for this project.
9−- If any guidance conflicts, `.cursor/rules` takes precedence for this repo.
5+- **Marketplace Focus**: Sneakers, clothing, accessories, electronics, gaming, collectibles
6+- **Seller-Buyer Platform**: Support both listing creation and purchasing flows
7+- **Payment Integration**: Razorpay for Indian market payments
8+- **Mobile-First**: Optimized for mobile users in Indian market
9+- **Regional Features**: Pincode validation, address management, local delivery
1010
11−Behavior Rules
12−- Always: Ask 1–2 clarifying questions when scope or intent is ambiguous.
13−- Always: Explain planned terminal actions briefly before running commands.
14−- Always: Keep answers concise by default; expand only when asked.
15−- Ask First: Before running destructive commands (rm/reset) or installing packages.
16−- Ask First: Before changing config, adding dependencies, or altering build settings.
17−- Never: Expose secrets or print full .env contents in answers or logs.
11+## Enum Usage Requirements
1812
19−Style and Tone
20−- Tone: Friendly, direct, and efficient. Avoid filler.
21−- Responses: Use short sections and bullet lists when they improve scanability.
22−- File References: Use clickable paths like `src/file.ts:42` (single line only).
13+- **Always use enums from `src/constants/enums.ts`**
14+- **Never hardcode values that exist in enums**
15+- **Use enum types for TypeScript interfaces**
2316
24−Task Execution
25−- Scope: Make minimal, surgical changes focused on the user’s request.
26−- Tests: If tests exist, run targeted tests for modified code first.
27−- Validation: Prefer small, verifiable steps; summarize progress between steps.
28−- Plans: Use the plan tool for multi-step or ambiguous work only.
17+### Key Enums to Use
2918
30−Code and Project
31−- Stack: Vite + React + TypeScript (see `package.json`).
32−- Formatting: Match existing style; do not add formatters unless requested.
33−- Types: Prefer explicit types in new/changed code; avoid one-letter names.
34−- Security: Treat environment variables and credentials as sensitive.
19+```typescript
20+// Routes - use ROUTE_NAMES for navigation
21+import { ROUTE_NAMES } from "@/constants/enums";
22+navigate(ROUTE_NAMES.HOME);
3523
36−Shell and Approvals
37−- Approval Mode: Default to asking before actions needing elevated permissions or network.
38−- Sandboxing: Assume workspace-write, network restricted; call out when escalation is needed.
39−- Commands: Prefer `rg` for search; read files in <=250-line chunks.
24+// Product conditions - use PRODUCT_CONDITIONS
25+import { PRODUCT_CONDITIONS } from "@/constants/enums";
26+const condition = PRODUCT_CONDITIONS.NEW;
4027
41−Response Defaults
42−- Brevity: Target 3–8 lines unless detail is necessary.
43−- Structure: Use short headers sparingly; avoid over-fragmentation.
44−- Monospace: Wrap commands, paths, env vars, and identifiers in backticks.
28+// Categories - use CATEGORY_IDS
29+import { CATEGORY_IDS } from "@/constants/enums";
30+const category = CATEGORY_IDS.SNEAKERS;
4531
46−When In Doubt
47−- Clarify requirements, propose a minimal plan, and confirm before large changes.
32+// Listing status - use LISTING_STATUS
33+import { LISTING_STATUS } from "@/constants/enums";
34+const status = LISTING_STATUS.APPROVED;
35+```
4836
49−Project-Specific Rules (Customize Below)
50−- Backend: Supabase is the source of truth (DB/Auth/Storage/Edge Functions). Do not add custom servers. Use Edge Functions for server logic.
51−- Supabase Calls: Avoid redundant fetches. Cache shared data in React Context; expose typed hooks and explicit invalidate/refresh methods.
52−- Pagination: For any list/multi-item fetch, implement pagination; show fewer items first and add page controls at the bottom.
53−- Dependencies: Install latest stable versions. If unsure about API/usage, ask for a docs link and confirmation before adding. Request approval before changing build/config deps.
54−- TypeScript: Use strict typing in all new code. Do not change existing TypeScript config; ensure new code compiles under current strictness. Never use `any`.
55−- Mobile UI: Design mobile-first (320px+). Use Tailwind responsive prefixes (`sm:`, `md:`, `lg:`, `xl:`). Ensure touch targets ≥44px and test across screen sizes.
56−- UI Patterns: Follow shadcn/ui and Radix-based components in `src/components/ui/`; keep props minimal and typed.
57−- Secrets: Never echo or log values from `process.env.*`.
37+## Component Structure Patterns
5838
59−Notes
60−- Adjust or expand sections above to reflect your preferences.
61−- This file is intended to be read as high-priority context at session start.
39+- **Feature Components**: Place in `src/components/` (e.g., `Cart/`, `checkout/`)
40+- **UI Components**: Place in `src/components/ui/` (shadcn/ui style)
41+- **Page Components**: Place in `src/pages/`
42+- **Context Providers**: Place in `src/contexts/`
43+
44+## Authentication Flow
45+
46+- **Public Routes**: Use `PublicRoute` component for login/signup
47+- **Protected Routes**: Use `ProtectedRoute` component for authenticated users
48+- **Admin Routes**: Use `AdminRoute` component for admin-only access
49+- **Context**: Use `useAuth()` hook for authentication state
50+
51+## Cart and Checkout Flow
52+
53+- **Cart Context**: Use `useCart()` hook for cart management
54+- **Multi-step Checkout**: Cart → Shipping → Payment
55+- **Address Management**: Use `useAddressStorage()` hook
56+- **Payment Integration**: Razorpay with proper error handling
57+
58+## Product Management
59+
60+- **Listing Creation**: Multi-step form with image upload
61+- **Image Compression**: Use `imageCompression` utility
62+- **Status Management**: Draft → Review → Approved/Rejected
63+- **Condition Badges**: Use `ConditionBadge` component
64+
65+## Mobile-First Design Requirements
66+
67+- **Touch Targets**: Minimum 44px for interactive elements
68+- **Responsive Breakpoints**: 320px+ (mobile), 768px+ (tablet), 1024px+ (desktop)
69+- **Navigation**: Mobile-friendly navigation patterns
70+- **Forms**: Optimized for mobile input
71+
72+## Error Handling Patterns
73+
74+- **Toast Notifications**: Use `sonner` for user feedback
75+- **Loading States**: Skeleton components and spinners
76+- **Form Validation**: Zod schemas with clear error messages
77+- **API Errors**: Graceful fallbacks and retry mechanisms
78+
79+## Performance Requirements
80+
81+- **Image Optimization**: Use `OptimizedImage` component
82+- **Lazy Loading**: Implement for heavy components
83+- **Bundle Splitting**: Consider for large pages
84+- **Caching**: Implement appropriate caching strategies
85+
86+## Testing Scenarios
87+
88+- **User Flows**: Complete buyer and seller journeys
89+- **Mobile Experience**: Test on various screen sizes
90+- **Payment Flow**: Test successful and failed payment scenarios
91+- **Form Validation**: Test all validation rules
92+- **Error States**: Test error handling and recovery
93+
94+## Code Organization
95+
96+- **Import Order**: External → Internal → Types → Utils
97+- **File Structure**: Follow existing patterns
98+- **Naming**: Use descriptive, consistent names
99+- **Documentation**: Comment complex logic and business rules
100+
101+## Build and Deployment
102+
103+- **TypeScript**: Strict mode, no compilation errors
104+- **Bundle Size**: Monitor and optimize large chunks
105+- **Environment**: Use proper environment variables
106+- **Build Command**: Always run `npm run build` before committing
107+ description:
108+ globs:
109+ alwaysApply: false
110+
111+---
62112
