📝 Add constants philosophy: DRY over cargo cult

- Add "Constants Philosophy" section to typescript coding standards
- Add code-review-standards.mdc with pragmatic review guidelines
- Constants should be extracted to stay DRY, not to avoid "magic strings"

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

Author: Nick Sullivan

.cursor/rules/code-review-standards.mdc

@@ -0,0 +1,61 @@
+---
+description: When doing code reviews
+alwaysApply: false
+---
+
+# Code Review Standards
+
+This rule defines what feedback is actionable based on project priorities. Use this to
+focus reviews on issues that actually get addressed.
+
+## Core Philosophy
+
+We ship pragmatically. Fix critical bugs, ensure security, validate core behavior.
+Ignore theoretical edge cases, minor polish, and over-engineering. Trust runtime
+validation over compile-time perfection.
+
+## Skip These Issues
+
+Do not include them in reviews.
+
+### Transactions for Rare Race Conditions
+
+Only flag race conditions you can demonstrate happen in practice. Theoretical edge cases
+requiring contrived timing are accepted as-is. Added complexity for extremely rare
+scenarios is not justified.
+
+### Magic Numbers and String Constants
+
+Constants exist to stay DRY, not to avoid "magic strings." This isn't Java. If a value
+appears once and the meaning is clear from context, inline is better than indirection.
+Only flag repeated values that would require multiple updates to change. Extracting
+`METHOD_INITIALIZE = "initialize"` for a single use is cargo cult programming.
+
+### Accessibility Improvements
+
+ARIA labels, keyboard navigation, and screen reader support are not current project
+priorities.
+
+### Minor Type Safety Improvements
+
+When runtime checks handle edge cases correctly, compile-time type refinement is
+optional. TypeScript serves the code, not vice versa. Working code takes priority over
+perfect types.
+
+### Test Edge Cases
+
+Core behavior receives test coverage. Edge cases including malformed API responses,
+empty arrays, and boundary conditions are deferred unless they cause production issues.
+Target is 90% coverage, not 100%. Focus on user-facing functionality.
+
+### Performance Micro-Optimizations
+
+Optimize when metrics show actual problems. Skipping unnecessary queries, adding
+theoretical indexes, or batching operations for minor latency gains without profiling
+data is premature optimization.
+
+### Documentation Enhancements
+
+Core documentation exists. Troubleshooting sections, rate limit documentation, and
+explanatory comments are iterative improvements based on user feedback. Perfect
+documentation delays shipping.

.cursor/rules/frontend/typescript-coding-standards.mdc

@@ -147,6 +147,33 @@ Naming conventions:
 - Functions/Variables: camelCase (`getCredentials`)
 - Constants: SCREAMING_SNAKE_CASE (`API_TIMEOUT_MS`)
 
+## Constants Philosophy
+
+Extract constants to stay DRY, not to avoid "magic strings." This isn't Java.
+
+**Extract when the value is repeated** and changing it requires updating multiple places:
+
+```typescript
+// Good - used in multiple files for token validation
+const TOKEN_PREFIX = "mcp_hubby_";
+const TOKEN_SUFFIX = "_end";
+```
+
+**Keep inline when used once** and the meaning is clear from context:
+
+```typescript
+// Good - clear from context, used once
+if (method === "initialize") { ... }
+if (status === "CONNECTED") { ... }
+const timeout = 30000; // 30 seconds, obvious from variable name
+```
+
+Extracting single-use values into named constants adds indirection without value. This is
+cargo cult programming from Java/C traditions that doesn't serve TypeScript codebases.
+
+The test: if you change the value, do you need to update multiple places? Extract it. If
+not, inline is clearer.
+
 ## Async Patterns
 
 Use async/await instead of raw Promises. This produces cleaner stack traces and works