Cline rules

1# General Rules (Reusable)
2 
3## CRITICAL: No Unsolicited Documentation
4 
5**NEVER create documentation files (README, guides, tutorials, FIXES, SUMMARY, USAGE, etc.) unless EXPLICITLY requested by the user.**
6 
7This includes but is not limited to:
8- README files
9- Usage guides
10- Fix summaries
11- Tutorial documents
12- API documentation
13- Architecture documents
14 
15Only create standalone documentation files when the user specifically asks for them.
16 
17---
18 
19## Code Quality Standards
20 
21### Architecture Principles
22- **Separation of Concerns**: Each module has a single, well-defined responsibility
23- **Dependency Injection**: Components receive dependencies rather than creating them
24- **Configuration Management**: Use dataclasses for type-safe configuration
25- **Error Handling**: Comprehensive error handling with informative messages
26- **Type Safety**: Full type hints throughout the codebase
27 
28### Code Style
29- **Type Hints**: All functions must have parameter and return type hints
30- **Docstrings**: All public classes and functions must have one-line docstrings
31- **Naming**: Use descriptive names (e.g., `screen_manager` not `sm`)
32- **Line Length**: Max 88 characters (Black default)
33- **Imports**: Group by stdlib, third-party, local (use isort)
34- **Simplicity**: Keep code simple and straightforward - avoid over-engineering
35- **Leverage Libraries**: Use well-established libraries instead of custom implementations where they add value
36- **Pylance Errors**: All Pylance errors must be addressed before finishing a task
37 
38### Testing Approach
39- Each module should be independently testable
40- Use dependency injection to facilitate mocking
41- Configuration should be passed in, not read from environment
42 
43### Logging
44- Use language-appropriate logging frameworks
45- Log at appropriate levels (DEBUG, INFO, WARNING, ERROR)
46- Include context in log messages
47 
48## Import Rules
49 
50- Use absolute imports within package
51- Keep imports organized: stdlib → third-party → local
52- Avoid circular dependencies
53- Use package initialization files to expose public API
54 
55## Documentation Standards
56 
57**IMPORTANT: Do NOT add documentation (README, guides, tutorials, etc.) unless explicitly requested by the user.**
58 
59When documentation is requested:
60- Keep it minimalistic, functional, and no fluff
61- Focus on what's needed, not what's nice to have
62- Code examples over explanations
63- No marketing language or excessive descriptions
64 
65Docstrings:
66- One-line docstrings for all public functions/classes
67- Explain what it does, parameters, return values, exceptions
68- Keep concise and technical
69- Focus on code over documentation
70 
71## Research and Verification
72 
73**ALWAYS search online before implementing features or using APIs:**
741. Search for the latest official documentation
752. Verify API methods, parameters, and best practices
763. Check for deprecations or breaking changes
774. Use the most recent stable versions
785. Example workflow:
79   - Search for official documentation
80   - Verify from authoritative sources
81   - Implement using verified patterns and methods
82