| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 12 | 0 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 2 | 3 | 1 | 33% |
What each file covers
Sections
0 shared · 12 only in A · 0 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 · 3 only in A · 1 only in B- − types
- − database
- − api
- + do-not
- code-style
- security
Line diff
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
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
@@ −1 +1 @@
1−# API Patterns and Data Management
1+Codex Workspace Rules (AGENTS.md)
22
3−## Supabase Integration
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.
46
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`
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.
910
10−## Service Layer Pattern
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.
1118
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
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).
1623
17−## API Response Handling
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.
1829
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)
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.
2335
24−## Pagination Implementation
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.
2540
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
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.
3145
32−## Data Fetching Patterns
46+When In Doubt
47+- Clarify requirements, propose a minimal plan, and confirm before large changes.
3348
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
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.*`.
3858
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−---
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.
11562
