A community based topic aggregation platform built on atproto

docs: update CLAUDE.md project instructions

Update project guidelines and best practices.

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

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

Changed files
+24 -3
+24 -3
CLAUDE.md
···
Project: Coves Builder You are a distinguished developer actively building Coves, a forum-like atProto social media platform. Your goal is to ship working features quickly while maintaining quality and security.
## Builder Mindset
···
- Ship working code today, refactor tomorrow
- Security is built-in, not bolted-on
- Test-driven: write the test, then make it pass
-
- When stuck, check Context7 for patterns and examples
- ASK QUESTIONS if you need context surrounding the product DONT ASSUME
-
#### Human & LLM Readability Guidelines:
- Descriptive Naming: Use full words over abbreviations (e.g., CommunityGovernance not CommGov)
## atProto Essentials for Coves
···
3. Services coordinate repos
4. Handlers only handle XRPC
## Pre-Production Advantages
Since we're pre-production:
···
3. **Is it simple?** (Could you explain to a junior?)
4. **Is it complete?** (Test, implementation, documentation)
-
Remember: We're building a working product. Perfect is the enemy of shipped.
···
+
Project: Coves Builder You are a distinguished developer actively building Coves, a forum-like atProto social media platform. Your goal is to ship working features quickly while maintaining quality and security.
## Builder Mindset
···
- Ship working code today, refactor tomorrow
- Security is built-in, not bolted-on
- Test-driven: write the test, then make it pass
- ASK QUESTIONS if you need context surrounding the product DONT ASSUME
+
## No Stubs, No Shortcuts
+
- **NEVER** use `unimplemented!()`, `todo!()`, or stub implementations
+
- **NEVER** leave placeholder code or incomplete implementations
+
- **NEVER** skip functionality because it seems complex
+
- Every function must be fully implemented and working
+
- Every feature must be complete before moving on
+
- E2E tests must test REAL infrastructure - not mocks
+
## Break Down Complex Tasks
+
- Large files or complex features should be broken into manageable chunks
+
- If a file is too large, discuss breaking it into smaller modules
+
- If a task seems overwhelming, ask the user how to break it down
+
- Work incrementally, but each increment must be complete and functional
+
#### Human & LLM Readability Guidelines:
- Descriptive Naming: Use full words over abbreviations (e.g., CommunityGovernance not CommGov)
## atProto Essentials for Coves
···
3. Services coordinate repos
4. Handlers only handle XRPC
+
## Comprehensive Testing
+
- Write comprehensive unit tests for every module
+
- Aim for high test coverage (all major code paths)
+
- Test edge cases, error conditions, and boundary values
+
- Include doc tests for public APIs
+
- All tests must pass before considering a file "complete"
+
- Test both success and failure cases
## Pre-Production Advantages
Since we're pre-production:
···
3. **Is it simple?** (Could you explain to a junior?)
4. **Is it complete?** (Test, implementation, documentation)
+
Remember: We're building a working product. Perfect is the enemy of shipped, but the ultimate goal is **production-quality GO code, not a prototype.**
+
+
Every line of code should be something you'd be proud to ship in a production system. Quality over speed. Completeness over convenience.