Cursor rule

1---
2description: When doing code reviews
3alwaysApply: false
4version: 1.0.0
5---
6 
7# Code Review Standards
8 
9This rule defines what feedback is actionable based on project priorities. Use this to
10focus reviews on issues that actually get addressed.
11 
12## Core Philosophy
13 
14We ship pragmatically. Fix critical bugs, ensure security, validate core behavior.
15Ignore theoretical edge cases, minor polish, and over-engineering. Trust runtime
16validation over compile-time perfection.
17 
18## Skip These Issues
19 
20Do not include them in reviews.
21 
22### Transactions for Rare Race Conditions
23 
24Only flag race conditions you can demonstrate happen in practice. Theoretical edge cases
25requiring contrived timing are accepted as-is. Added complexity for extremely rare
26scenarios is not justified.
27 
28### Magic Numbers and String Constants
29 
30Constants exist to stay DRY, not to avoid "magic strings." This isn't Java. If a value
31appears once and the meaning is clear from context, inline is better than indirection.
32Only flag repeated values that would require multiple updates to change. Extracting
33`METHOD_INITIALIZE = "initialize"` for a single use is cargo cult programming.
34 
35### Accessibility Improvements
36 
37ARIA labels, keyboard navigation, and screen reader support are not current project
38priorities.
39 
40### Minor Type Safety Improvements
41 
42When runtime checks handle edge cases correctly, compile-time type refinement is
43optional. TypeScript serves the code, not vice versa. Working code takes priority over
44perfect types.
45 
46### Test Edge Cases
47 
48Core behavior receives test coverage. Edge cases including malformed API responses,
49empty arrays, and boundary conditions are deferred unless they cause production issues.
50Target is 90% coverage, not 100%. Focus on user-facing functionality.
51 
52### Performance Micro-Optimizations
53 
54Optimize when metrics show actual problems. Skipping unnecessary queries, adding
55theoretical indexes, or batching operations for minor latency gains without profiling
56data is premature optimization.
57 
58### Documentation Enhancements
59 
60Core documentation exists. Troubleshooting sections, rate limit documentation, and
61explanatory comments are iterative improvements based on user feedback. Perfect
62documentation delays shipping.
63