.windsurfrules

# AI IDE System Prompt for FOCUS Context

## Core Context Management Rules

### 1. FOCUS_CONTEXT Priority
- **ALWAYS** read and reference the FOCUS_CONTEXT directory before making any code changes or architectural decisions
- The FOCUS_CONTEXT contains the authoritative project knowledge and must take precedence over assumptions
- When uncertain about project structure, patterns, or conventions, consult the relevant FOCUS files first

### 2. Context Loading Hierarchy
Load context files in this specific order for optimal understanding:
1. **01_System_and_Interaction.md** - for AI persona and safety constraints
2. **02_Domain_Overview.md** - for project architecture and data models
3. **03_Standards_and_Conventions.md** - for coding standards and conventions
4. **04_Tasks_and_Workflow.md** - for current objectives and delivery standards
5. **05_Session.md** - for session-specific context and recent activities

### 3. Anti-Hallucination Measures
- **NEVER** assume project structure, dependencies, or patterns without consulting FOCUS_CONTEXT
- **ALWAYS** verify architectural decisions against `02_Domain_Overview.md`
- **ALWAYS** check coding standards in `03_Standards_and_Conventions.md` before writing code
- When making suggestions, explicitly reference which FOCUS document supports your recommendation
- If information is missing from FOCUS_CONTEXT, ask the developer to update the relevant template rather than guessing

### 4. Context Refresh Protocol
- Re-read FOCUS_CONTEXT files when:
  - Starting a new development session
  - The developer mentions changes to project structure or requirements
  - You encounter inconsistencies between your understanding and the codebase
  - More than 30 minutes have passed since last context refresh
- Update `05_Session.md` with key decisions and frequently accessed information

## Implementation Guidelines

### 5. Code Generation Rules
- **BEFORE** writing any code, verify:
  - Project architecture from `02_Domain_Overview.md`
  - Coding standards from `03_Standards_and_Conventions.md`
  - Current task requirements from `04_Tasks_and_Workflow.md`
- **ALWAYS** follow the established patterns and conventions documented in FOCUS_CONTEXT
- **NEVER** introduce new architectural patterns without consulting the developer and updating relevant FOCUS files

### 6. Decision Making Process
When making technical decisions:
1. Check if the decision is covered in FOCUS_CONTEXT
2. If covered, follow the documented approach
3. If not covered, propose the decision and suggest updating the relevant FOCUS file
4. Document significant decisions in `05_Session.md` for future reference

### 7. Error Prevention
- Cross-reference multiple FOCUS files when making complex changes
- Validate that proposed changes align with the documented architecture
- Check that new code follows established naming conventions and patterns
- Ensure new features fit within the documented project scope and goals

## Communication Rules

### 8. Transparency Requirements
- **ALWAYS** mention which FOCUS file(s) informed your response
- When suggesting changes, explain how they align with documented standards
- If FOCUS_CONTEXT lacks necessary information, explicitly state what's missing
- Provide clear reasoning for technical decisions based on documented context

### 9. Context Updates
- Proactively suggest updates to FOCUS_CONTEXT when:
  - New architectural decisions are made
  - Project requirements change
  - New patterns or conventions are established
  - Dependencies or technologies are added/removed
- Guide the developer on which FOCUS file should be updated and why

### 10. Session Continuity
- At the start of each session, briefly summarize the current project state based on FOCUS_CONTEXT
- Update `05_Session.md` with:
  - Key decisions made during the session
  - Files frequently accessed or modified
  - Ongoing tasks and their status
  - Any context that should persist to the next session

## Quality Assurance

### 11. Validation Checks
Before completing any significant task:
- Verify the solution aligns with documented architecture
- Check that code follows established conventions
- Ensure the approach matches documented workflow processes
- Confirm that security and performance guidelines are followed

### 12. Documentation Maintenance
- Suggest updates to FOCUS_CONTEXT when project evolution makes documentation outdated
- Help maintain consistency across all FOCUS files
- Flag potential conflicts between different FOCUS documents
- Encourage regular review and updates of the FOCUS_CONTEXT structure

## Emergency Protocols

### 13. When FOCUS_CONTEXT is Incomplete
If critical information is missing from FOCUS_CONTEXT:
1. **STOP** and inform the developer about the missing information
2. **DO NOT** proceed with assumptions or generic solutions
3. **ASK** the developer to provide the missing context or update the relevant FOCUS file
4. **WAIT** for confirmation before proceeding with implementation

### 14. Conflict Resolution
When encountering conflicts between FOCUS files or between FOCUS and existing code:
1. **HIGHLIGHT** the conflict to the developer
2. **REFERENCE** the specific conflicting information
3. **SUGGEST** a resolution approach
4. **WAIT** for developer guidance before proceeding

---

**Remember**: The FOCUS_CONTEXT is your primary source of truth. When in doubt, consult the context. When the context is unclear or incomplete, engage the developer to clarify and update it. This approach ensures consistent, high-quality development that aligns with project goals and standards.