Cline rules

1# Documentation Standards
2 
3## Docstrings
4- Required for all public classes, methods, and functions
5- Include: purpose, parameters, return values, exceptions
6- Follow Sphinx/Google style consistently
7 
8## Comments
9 
10### Brief Overview
11These rules govern code comments and documentation standards. Focus is on keeping code clean and avoiding unhelpful or redundant comments.
12 
13### Comment Guidelines
14 
15- **Keep helpful TODOs**: Preserve actionable TODO comments that clearly indicate work needed
16  - Example: `# TODO: Implement via market data adapter`
17  - Example: `# TODO: Add get_recent_trade_outcomes method to transaction service`
18 
19- **Remove historical/context comments**: Delete comments that explain where code came from or past refactoring history
20  - ❌ BAD: `(merged from agent/portfolio.py)`
21  - ❌ BAD: `NOTE: This function was previously in utils/old_file.py`
22  - ❌ BAD: `This method has been refactored to remove direct SQLite access`
23 
24- **No explanatory NOTE comments**: Do not add NOTE comments during refactoring that merely state what was done
25  - ❌ BAD: `NOTE: This function requires market data adapter that provides historical bars. It no longer uses direct database access.`
26  - ✅ GOOD: Keep the docstring simple and focused on current behavior
27 
28- **Docstrings should be current**: Focus on what the function does NOW, not what it used to do or how it changed
29  - ✅ GOOD: "Calculate pairwise correlation between all symbols."
30  - ❌ BAD: "Calculate pairwise correlation between all symbols. NOTE: This function has been refactored..."
31 
32### Code Cleanliness
33 
34- Code should be self-documenting where possible
35- Comments that don't add value should be removed
36- Historical context belongs in git history, not in code comments
37- If a comment doesn't help someone using or maintaining the code, it shouldn't be there
38 
39### Basic Standards
40 
41- Place above code, not beside (except brief end-of-line comments)
42- Avoid obvious statements
43- Start with capital letter, end with period
44- Update when code changes
45 
46## Markdown Files
47- Professional senior dev tone
48- Clear, concise, direct
49- No fluff or filler words
50- Proper syntax and formatting
51- No third-person references
52 
53## Documentation Tasks
54- Create ModelContextProtocol for accessing code indices
55- Structure documentation with clear sections and headings
56- Enable quick reference and navigation
57- Provide clear explanations of functionality, purpose, and usage
58