| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 0 | 12 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 2 | 1 | 3 | 33% |
What each file covers
Sections
0 shared · 0 only in A · 12 only in B- + API Patterns and Data Management
- + Supabase Integration
- + Service Layer Pattern
- + API Response Handling
- + Pagination Implementation
- + Data Fetching Patterns
- + Error Handling
- + Authentication Flow
- + File Upload
- + Payment Integration
- + Example Patterns
- + Database Schema
Commands
neither file has anySection tags
2 shared · 1 only in A · 3 only in B- − do-not
- + types
- + database
- + api
- 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/api-patterns.mdc
@@ +1 @@
1# API Patterns and Data Management
2
3## Supabase Integration
4
5- Use `src/lib/supabase.ts` for all Supabase operations
6- Access Supabase client via `supabase` export
7- Use environment variables for configuration
8- Handle authentication state through `AuthContext`
9
10## Service Layer Pattern
11
12- Create service files in `src/lib/` for business logic
13- Use descriptive names: `orderService.ts`, `paymentService.ts`
14- Export functions, not classes
15- Handle errors consistently across services
16
17## API Response Handling
18
19- Always handle success and error cases
20- Use proper TypeScript types for API responses
21- Implement proper error boundaries and user feedback
22- Use toast notifications for user feedback (via sonner)
23
24## Pagination Implementation
25
26- Always implement pagination for list APIs
27- Use `count` and `skip` parameters for Supabase queries
28- Show fewer items per page initially (10-20 items)
29- Provide pagination controls at the bottom
30- Allow users to navigate between pages
31
32## Data Fetching Patterns
33
34- Use React Query or SWR for server state management
35- Implement proper loading states with skeletons
36- Handle empty states gracefully
37- Cache data appropriately to reduce API calls
38
39## Error Handling
40
41- Define custom error types in `src/types/`
42- Use try-catch blocks for async operations
43- Provide meaningful error messages to users
44- Log errors for debugging (use `Logger` component)
45
46## Authentication Flow
47
48- Use Supabase Auth for user management
49- Handle social login (Google, etc.)
50- Implement proper route protection
51- Use `PublicRoute` and `ProtectedRoute` components
52
53## File Upload
54
55- Use Supabase Storage for file uploads
56- Implement image compression before upload
57- Handle upload progress and errors
58- Validate file types and sizes
59
60## Payment Integration
61
62- Use Razorpay for payment processing
63- Implement proper payment flow with error handling
64- Store payment status in database
65- Handle webhook notifications
66
67## Example Patterns
68
69```typescript
70// Good: Service function pattern
71export const fetchProducts = async (page: number = 1, limit: number = 10) => {
72 try {
73 const { data, error, count } = await supabase
74 .from("products")
75 .select("*", { count: "exact" })
76 .range((page - 1) * limit, page * limit - 1)
77 .eq("status", LISTING_STATUS.APPROVED);
78
79 if (error) throw error;
80
81 return { data, count, page, limit };
82 } catch (error) {
83 console.error("Error fetching products:", error);
84 throw new Error("Failed to fetch products");
85 }
86};
87
88// Good: API call with proper error handling
89const handleSubmit = async (formData: FormData) => {
90 try {
91 setIsLoading(true);
92 const result = await createOrder(formData);
93 toast.success("Order created successfully!");
94 navigate("/orders");
95 } catch (error) {
96 toast.error("Failed to create order. Please try again.");
97 console.error("Order creation error:", error);
98 } finally {
99 setIsLoading(false);
100 }
101};
102```
103
104## Database Schema
105
106- Use consistent naming conventions (snake_case for DB, camelCase for JS)
107- Implement proper RLS (Row Level Security) policies
108- Use appropriate data types and constraints
109- Create indexes for frequently queried fields
110 description:
111 globs:
112 alwaysApply: false
113
114---
115
@@ −1 +1 @@
1−Codex Workspace Rules (AGENTS.md)
1+# API Patterns and Data Management
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+## Supabase Integration
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+- Use `src/lib/supabase.ts` for all Supabase operations
6+- Access Supabase client via `supabase` export
7+- Use environment variables for configuration
8+- Handle authentication state through `AuthContext`
109
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.
10+## Service Layer Pattern
1811
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).
12+- Create service files in `src/lib/` for business logic
13+- Use descriptive names: `orderService.ts`, `paymentService.ts`
14+- Export functions, not classes
15+- Handle errors consistently across services
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+## API Response Handling
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+- Always handle success and error cases
20+- Use proper TypeScript types for API responses
21+- Implement proper error boundaries and user feedback
22+- Use toast notifications for user feedback (via sonner)
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+## Pagination Implementation
4025
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.
26+- Always implement pagination for list APIs
27+- Use `count` and `skip` parameters for Supabase queries
28+- Show fewer items per page initially (10-20 items)
29+- Provide pagination controls at the bottom
30+- Allow users to navigate between pages
4531
46−When In Doubt
47−- Clarify requirements, propose a minimal plan, and confirm before large changes.
32+## Data Fetching Patterns
4833
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.*`.
34+- Use React Query or SWR for server state management
35+- Implement proper loading states with skeletons
36+- Handle empty states gracefully
37+- Cache data appropriately to reduce API calls
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+## Error Handling
40+
41+- Define custom error types in `src/types/`
42+- Use try-catch blocks for async operations
43+- Provide meaningful error messages to users
44+- Log errors for debugging (use `Logger` component)
45+
46+## Authentication Flow
47+
48+- Use Supabase Auth for user management
49+- Handle social login (Google, etc.)
50+- Implement proper route protection
51+- Use `PublicRoute` and `ProtectedRoute` components
52+
53+## File Upload
54+
55+- Use Supabase Storage for file uploads
56+- Implement image compression before upload
57+- Handle upload progress and errors
58+- Validate file types and sizes
59+
60+## Payment Integration
61+
62+- Use Razorpay for payment processing
63+- Implement proper payment flow with error handling
64+- Store payment status in database
65+- Handle webhook notifications
66+
67+## Example Patterns
68+
69+```typescript
70+// Good: Service function pattern
71+export const fetchProducts = async (page: number = 1, limit: number = 10) => {
72+ try {
73+ const { data, error, count } = await supabase
74+ .from("products")
75+ .select("*", { count: "exact" })
76+ .range((page - 1) * limit, page * limit - 1)
77+ .eq("status", LISTING_STATUS.APPROVED);
78+
79+ if (error) throw error;
80+
81+ return { data, count, page, limit };
82+ } catch (error) {
83+ console.error("Error fetching products:", error);
84+ throw new Error("Failed to fetch products");
85+ }
86+};
87+
88+// Good: API call with proper error handling
89+const handleSubmit = async (formData: FormData) => {
90+ try {
91+ setIsLoading(true);
92+ const result = await createOrder(formData);
93+ toast.success("Order created successfully!");
94+ navigate("/orders");
95+ } catch (error) {
96+ toast.error("Failed to create order. Please try again.");
97+ console.error("Order creation error:", error);
98+ } finally {
99+ setIsLoading(false);
100+ }
101+};
102+```
103+
104+## Database Schema
105+
106+- Use consistent naming conventions (snake_case for DB, camelCase for JS)
107+- Implement proper RLS (Row Level Security) policies
108+- Use appropriate data types and constraints
109+- Create indexes for frequently queried fields
110+ description:
111+ globs:
112+ alwaysApply: false
113+
114+---
62115
