lx-0 prompts .cursorrules file for unknown

# PROJECT-SPECIFIC CURSOR RULES

## DEVELOPMENT METHODOLOGY

We are using a **TEST-DRIVEN DEVELOPMENT (TDD)** approach. Follow these core principles:

1. **PHASE SEPARATION**:
   - Stick to TDD phases:
     - **[PREPARATION PHASE]**: Analyze project related input documents and persist summary in documentation.
     - **[TEST PHASE]**: Write failing tests based on requirements, without implementation.
     - **[IMPLEMENTATION PHASE]**: Write only the minimal code necessary to pass the tests.
     - **[REFACTOR PHASE]**: Refactor code to improve quality without altering behavior.
   - **PREFIX**: All responses must begin with the phase prefix (e.g., `[TEST PHASE]`).

2. **SHORT, ITERATIVE EXCHANGES**:
   - Keep prompts and outputs small in scope (e.g., single tests or components).
   - Validate outputs after each step before proceeding to the next.

3. **NO TEST MODIFICATIONS DURING IMPLEMENTATION**:
   - Tests are final once the **[IMPLEMENTATION PHASE]** begins.
   - Tests can only change during the **[TEST PHASE]** to address updated requirements.

---

## AI ASSISTANCE GUIDELINES

1. **CHECK FOR EXISTING IMPLEMENTATIONS**:
   - Before implementing new functionality, confirm whether existing components meet the requirement.
   - Reuse or extend existing components whenever possible to avoid duplication.

2. **PRESERVE UNRELATED FUNCTIONALITY**:
   - Ensure unrelated existing functionality is preserved. Validate changes with tests.

3. **GAP ANALYSIS**:
   - During the **[TEST PHASE]**, evaluate the completeness of requirements and identify missing or conflicting details.

4. **FOCUS ON REQUIREMENTS**:
   - Adhere strictly to requirements provided by the user.
   - Avoid adjusting or altering requirements unless explicitly instructed.

5. **EXPLANATION & DOCUMENTATION**:
   - Provide clear explanations for every solution.
   - Document component designs, purposes, and behaviors as Markdown output when requested.

6. **PROACTIVE FEEDBACK**:
   - Provide constructive feedback on:
     - Product design decisions and their implications
     - Architectural choices and their impact on scalability
     - Code maintainability and potential technical debt
     - Adherence to clean code principles and best practices
   - Suggest improvements while respecting existing design decisions
   - Highlight potential risks or areas for optimization

---

## CODING STANDARDS

1. **STRICT TYPING**:
   - Always use strict typing to ensure code reliability.
   - Avoid generic types like `any`.

2. **CONSISTENT NAMING**:
   - Use clear, consistent naming conventions for variables, functions, and components.

3. **MODULARITY**:
   - Write reusable, modular code that adheres to single-responsibility principles.

4. **DOCUMENTATION**:
   - Create README.md files for components, usage, and architecture when requested.
   - Include diagrams and markdown-friendly formats to support understanding.

5. **ENVIRONMENT MANAGEMENT**:
   - Use modern environment managers (e.g., pyenv, poetry for Python, nvm for Node.js) for dependency isolation.
   - Ensure reproducible development environments across different machines.
   - Lock dependency versions to maintain consistency.
   - Document environment setup steps in README.md.

---

## TESTING GUIDELINES

1. **WRITE FAILING TESTS FIRST**:
   - Start with failing tests that define the desired behavior.
   - Tests must include acceptance criteria based on user requirements.

2. **CLEAR AND DESCRIPTIVE TESTS**:
   - Ensure all tests are self-explanatory and clearly reflect expected behavior.

3. **ISOLATION**:
   - Tests must remain independent, avoiding reliance on shared state or execution order.

4. **EDGE CASE COVERAGE**:
   - Ensure tests include edge cases and invalid inputs.

---

## IMPLEMENTATION PHASE

1. **MINIMAL IMPLEMENTATION**:
   - Write just enough code to pass the current test(s) without adding extra functionality.

2. **NO DUPLICATION**:
   - Avoid duplicating logic or components. Reuse existing code when possible.

3. **INTEGRATION TESTING**:
   - Once components are implemented, validate their interactions with integration tests.

---

## ENFORCED RULES FOR LLM RESPONSES

1. **PHASE AWARENESS**:
   - Prefix all responses with the current phase:
     - `[PREPARATION PHASE]`: Analyzing project related input documents and persisting summary in documentation.
     - `[TEST PHASE]`: Writing failing tests.
     - `[IMPLEMENTATION PHASE]`: Implementing code to pass tests.
     - `[REFACTOR PHASE]`: Improving code without altering behavior.
   - Example:
     `[TEST PHASE] Writing failing tests for user authentication. Here is the test case: ...`

2. **ITERATIVE TASKS**:
   - Limit responses to small tasks or single components to avoid confusion and maintain focus.

3. **CONSISTENT OUTPUT**:
   - Ensure outputs (tests, code, or diagrams) follow the project’s coding and documentation standards.

4. **EXISTING FUNCTIONALITY CHECK**:
   - Before suggesting or implementing code, confirm whether similar functionality already exists. Reuse or extend it if applicable.

---

## FINAL CHECKS & DOCUMENTATION

1. **CONTINUOUS VALIDATION**:
   - After completing a task, validate it through tests or user feedback before proceeding.

2. **GENERATE FINAL ARTIFACTS**:
   - Provide summaries of components, architecture, and gaps in functionality at project milestones.
   - Ensure README.md and documentation files are up-to-date.

---

## KEY REMINDERS

1. **RESPECT TDD PHASES**: Tests first, minimal implementation second, and refactor last. Always prefix responses to clarify the current phase.

2. **AVOID DUPLICATION**: Check for and reuse existing implementations before creating new functionality.

3. **PRESERVE EXISTING FUNCTIONALITY**: Ensure changes do not break unrelated functionality. Use tests to validate this.