update

.clinerules/1-memory-bank.md

@@ -0,0 +1,134 @@
+---
+description: Describes Cline's Memory Bank system, its structure, and workflows for maintaining project knowledge across sessions.
+author: https://github.com/nickbaumann98
+version: 1.0
+tags: ["memory-bank", "knowledge-base", "core-behavior", "documentation-protocol"]
+globs: ["memory-bank/**/*.md", "*"]
+---
+# Cline's Memory Bank
+
+My memory resets completely between sessions. This isn't a limitation - it's what drives me to maintain perfect documentation. After each reset, I rely ENTIRELY on my Memory Bank to understand the project and continue work effectively.
+
+## Memory Bank Structure
+
+The Memory Bank consists of core files and optional context files, all in Markdown format. Files build upon each other in a clear hierarchy:
+
+```mermaid
+flowchart TD
+    PB[projectBrief.md] --> PC[productContext.md]
+    PB --> SP[systemPatterns.md]
+    PB --> TC[techContext.md]
+    
+    PC --> AC[activeContext.md]
+    SP --> AC
+    TC --> AC
+    
+    AC --> P[progress.md]
+```
+
+### Core Files (Required for Initial Load)
+These files are crucial for initial project understanding and MUST be read at the start of EVERY task.
+1. `projectBrief.md`
+   - Foundation document that shapes all other files
+   - Created at project start if it doesn't exist
+   - Defines core requirements and goals
+   - Source of truth for project scope
+
+2. `productContext.md`
+   - Why this project exists
+   - Problems it solves
+   - How it should work
+   - User experience goals
+
+3. `activeContext.md`
+   - Current work focus
+   - Recent changes
+   - Next steps
+   - Active decisions and considerations
+   - Important patterns and preferences
+   - Learnings and project insights
+
+4. `progress.md`
+   - What works
+   - What's left to build
+   - Current status
+   - Known issues
+   - Evolution of project decisions
+
+### Supplemental Files (Load On Demand)
+These files provide deeper context but can be loaded as needed to manage context window usage.
+1. `systemPatterns.md`
+   - System architecture
+   - Key technical decisions
+   - Design patterns in use
+   - Component relationships
+   - Critical implementation paths
+
+2. `techContext.md`
+   - Technologies used
+   - Development setup
+   - Technical constraints
+   - Dependencies
+   - Tool usage patterns
+
+### Additional Context
+Create additional files/folders within memory-bank/ when they help organize:
+- Complex feature documentation
+- Integration specifications
+- API documentation
+- Testing strategies
+- Deployment procedures
+
+## Core Workflows
+
+### Plan Mode
+```mermaid
+flowchart TD
+    Start[Start] --> ReadCoreFiles[Read Core Memory Bank Files]
+    ReadCoreFiles --> CheckContext{Context Sufficient?}
+    
+    CheckContext -->|No| ReadSupplemental[Read Supplemental Files as Needed]
+    ReadSupplemental --> Plan[Create Plan]
+    Plan --> Document[Document in Chat]
+    
+    CheckContext -->|Yes| Verify[Verify Context]
+    Verify --> Strategy[Develop Strategy]
+    Strategy --> Present[Present Approach]
+```
+
+### Act Mode
+```mermaid
+flowchart TD
+    Start[Start] --> Context[Check Memory Bank (Core & On-Demand)]
+    Context --> Update[Update Documentation]
+    Update --> Execute[Execute Task]
+    Execute --> Document[Document Changes]
+```
+
+## Documentation Updates
+
+Memory Bank updates occur when:
+1. Discovering new project patterns
+2. After implementing significant changes
+3. When user requests with **update memory bank** (MUST review ALL files)
+4. When context needs clarification
+
+```mermaid
+flowchart TD
+    Start[Update Process]
+    
+    subgraph Process
+        P1[Review ALL Files]
+        P2[Document Current State]
+        P3[Clarify Next Steps]
+        P4[Document Insights & Patterns]
+        
+        P1 --> P2 --> P3 --> P4
+    end
+    
+    Start --> Process
+```
+
+Note: When triggered by **update memory bank**, I MUST review every memory bank file, even if some don't require updates. Focus particularly on activeContext.md and progress.md as they track current state.
+
+REMEMBER: After every memory reset, I begin completely fresh. The Memory Bank is my only link to previous work. It must be maintained with precision and clarity, as my effectiveness depends entirely on its accuracy.

.clinerules/2-new-task-automation.md

@@ -0,0 +1,268 @@
+---
+description: Workflow for starting new task when context window reaches 50%
+author: https://github.com/cline
+version: 1.0
+tags: ["context-management", "new-task"]
+globs: ["*"]
+---
+# You MUST use the `new_task` tool: Task Handoff Strategy Guide
+
+**⚠️ CRITICAL INSTRUCTIONS - YOU MUST FOLLOW THESE GUIDELINES ⚠️**
+
+This guide provides **MANDATORY** instructions for effectively breaking down complex tasks and implementing a smooth handoff process between tasks. You **MUST** follow these guidelines to ensure continuity, context preservation, and efficient task completion.
+
+## ⚠️ CONTEXT WINDOW MONITORING - MANDATORY ACTION REQUIRED ⚠️
+
+You **MUST** monitor the context window usage displayed in the environment details. When usage exceeds 50% of the available context window, you **MUST** initiate a task handoff using the `new_task` tool.
+
+Example of context window usage over 50% with a 200K context window:
+
+\`\`\`text
+# Context Window Usage
+105,000 / 200,000 tokens (53%)
+Model: anthropic/claude-3.7-sonnet (200K context window)
+\`\`\`
+
+**IMPORTANT**: When you see context window usage at or above 50%, you MUST:
+1. Complete your current logical step
+2. Use the `ask_followup_question` tool to offer creating a new task
+3. If approved, use the `new_task` tool with comprehensive handoff instructions
+
+## Task Breakdown in Plan Mode - REQUIRED PROCESS
+
+Plan Mode is specifically designed for analyzing complex tasks and breaking them into manageable subtasks. When in Plan Mode, you **MUST**:
+
+### 1. Initial Task Analysis - REQUIRED
+
+- **MUST** begin by thoroughly understanding the full scope of the user's request
+- **MUST** identify all major components and dependencies of the task
+- **MUST** consider potential challenges, edge cases, and prerequisites
+
+### 2. Strategic Task Decomposition - REQUIRED
+
+- **MUST** break the overall task into logical, discrete subtasks
+- **MUST** prioritize subtasks based on dependencies (what must be completed first)
+- **MUST** aim for subtasks that can be completed within a single session (15-30 minutes of work)
+- **MUST** consider natural breaking points where context switching makes sense
+
+### 3. Creating a Task Roadmap - REQUIRED
+
+- **MUST** present a clear, numbered list of subtasks to the user
+- **MUST** explain dependencies between subtasks
+- **MUST** provide time estimates for each subtask when possible
+- **MUST** use Mermaid diagrams to visualize task flow and dependencies when helpful
+
+\`\`\`mermaid
+graph TD
+    A[Main Task] --> B[Subtask 1: Setup]
+    A --> C[Subtask 2: Core Implementation]
+    A --> D[Subtask 3: Testing]
+    A --> E[Subtask 4: Documentation]
+    B --> C
+    C --> D
+\`\`\`
+
+### 4. Getting User Approval - REQUIRED
+
+- **MUST** ask for user feedback on the proposed task breakdown
+- **MUST** adjust the plan based on user priorities or additional requirements
+- **MUST** confirm which subtask to begin with
+- **MUST** request the user to toggle to Act Mode when ready to implement
+
+## Task Implementation and Handoff Process - MANDATORY PROCEDURES
+
+When implementing tasks in Act Mode, you **MUST** follow these guidelines for effective task handoff:
+
+### 1. Focused Implementation - REQUIRED
+
+- **MUST** focus on completing the current subtask fully
+- **MUST** document progress clearly through comments and commit messages
+- **MUST** create checkpoints at logical completion points
+
+### 2. Recognizing Completion Points - CRITICAL
+
+You **MUST** identify natural handoff points when:
+- The current subtask is fully completed
+- You've reached a logical stopping point in a larger subtask
+- The implementation is taking longer than expected and can be continued later
+- The task scope has expanded beyond the original plan
+- **CRITICAL**: The context window usage exceeds 50% (e.g., 100,000+ tokens for a 200K context window)
+
+### 3. Initiating the Handoff Process - MANDATORY ACTION
+
+When you've reached a completion point, you **MUST**:
+
+1. Summarize what has been accomplished so far
+2. Clearly state what remains to be done
+3. **MANDATORY**: Use the `ask_followup_question` tool to offer creating a new task:
+
+\`\`\`xml
+<ask_followup_question>
+<question>I've completed [specific accomplishment]. Would you like me to create a new task to continue with [remaining work]?</question>
+<options>["Yes, create a new task", "No, continue in this session", "Let me think about it"]</options>
+</ask_followup_question>
+\`\`\`
+
+### 4. Creating a New Task with Context - REQUIRED ACTION
+
+If the user agrees to create a new task, you **MUST** use the `new_task` tool with comprehensive handoff instructions:
+
+\`\`\`xml
+<new_task>
+<context>
+# Task Continuation: [Brief Task Title]
+
+## Completed Work
+- [Detailed list of completed items]
+- [Include specific files modified/created]
+- [Note any important decisions made]
+
+## Current State
+- [Description of the current state of the project]
+- [Any running processes or environment setup]
+- [Key files and their current state]
+
+## Next Steps
+- [Detailed list of remaining tasks]
+- [Specific implementation details to address]
+- [Any known challenges to be aware of]
+
+## Reference Information
+- [Links to relevant documentation]
+- [Important code snippets or patterns to follow]
+- [Any user preferences noted during the current session]
+
+Please continue the implementation by [specific next action].
+</context>
+</new_task>
+\`\`\`
+
+### 5. Detailed Context Transfer - MANDATORY COMPONENTS
+
+When creating a new task, you **MUST** always include:
+
+#### Project Context - REQUIRED
+- **MUST** include the overall goal and purpose of the project
+- **MUST** include key architectural decisions and patterns
+- **MUST** include technology stack and dependencies
+
+#### Implementation Details - REQUIRED
+- **MUST** list files created or modified in the current session
+- **MUST** describe specific functions, classes, or components implemented
+- **MUST** explain design patterns being followed
+- **MUST** outline testing approach
+
+#### Progress Tracking - REQUIRED
+- **MUST** provide checklist of completed items
+- **MUST** provide checklist of remaining items
+- **MUST** note any blockers or challenges encountered
+
+#### User Preferences - REQUIRED
+- **MUST** note coding style preferences mentioned by the user
+- **MUST** document specific approaches requested by the user
+- **MUST** highlight priority areas identified by the user
+
+## Best Practices for Effective Handoffs - MANDATORY GUIDELINES
+
+### 1. Maintain Continuity - REQUIRED
+
+- **MUST** use consistent terminology between tasks
+- **MUST** reference previous decisions and their rationale
+- **MUST** maintain the same architectural approach unless explicitly changing direction
+
+### 2. Preserve Context - REQUIRED
+
+- **MUST** include relevant code snippets in the handoff
+- **MUST** summarize key discussions from the previous session
+- **MUST** reference specific files and line numbers when applicable
+
+### 3. Set Clear Next Actions - REQUIRED
+
+- **MUST** begin the handoff with a clear, actionable next step
+- **MUST** prioritize remaining tasks
+- **MUST** highlight any decisions that need to be made
+
+### 4. Document Assumptions - REQUIRED
+
+- **MUST** clearly state any assumptions made during implementation
+- **MUST** note areas where user input might be needed
+- **MUST** identify potential alternative approaches
+
+### 5. Optimize for Resumability - REQUIRED
+
+- **MUST** structure the handoff so the next session can begin working immediately
+- **MUST** include setup instructions if environment configuration is needed
+- **MUST** provide a quick summary at the top for rapid context restoration
+
+## Example Task Handoff
+
+### Example #1 of an effective task handoff:
+
+\`\`\`xml
+<new_task>
+<context>
+# Task Continuation: Implement User Authentication System
+
+## Completed Work
+- Created basic Express.js server structure
+- Implemented MongoDB connection and user schema
+- Completed user registration endpoint with password hashing
+- Added input validation using Joi
+- Created initial test suite for registration endpoint
+
+## Current State
+- Server runs successfully on port 3000
+- MongoDB connection is established
+- Registration endpoint (/api/users/register) is fully functional
+- Test suite passes for all registration scenarios
+
+## Next Steps
+1. Implement login endpoint (/api/users/login)
+   - Use bcrypt to compare passwords
+   - Generate JWT token upon successful login
+   - Add proper error handling for invalid credentials
+2. Create authentication middleware
+   - Verify JWT tokens
+   - Extract user information
+   - Handle expired tokens
+3. Add protected routes that require authentication
+4. Implement password reset functionality
+
+## Reference Information
+- JWT secret should be stored in .env file
+- Follow the existing error handling pattern in routes/users.js
+- User schema is defined in models/User.js
+- Test patterns are established in tests/auth.test.js
+
+Please continue by implementing the login endpoint following the same patterns established in the registration endpoint.
+</context>
+</new_task>
+\`\`\`
+
+### Example #2 of an ineffective task handoff:
+
+*(Note: The example provided in the original rules showing "YOLO MODE Implementation" seems less like a direct handoff context block and more like a general status update with future considerations. A true ineffective handoff might lack detail in 'Current State' or 'Next Steps').*
+
+## When to Use Task Handoffs - MANDATORY TRIGGERS
+
+You **MUST** initiate task handoffs in these scenarios:
+
+1. **CRITICAL**: When context window usage exceeds 50% (e.g., 100,000+ tokens for a 200K context window)
+2. **Long-running projects** that exceed a single session
+3. **Complex implementations** with multiple distinct phases
+4. **When context window limitations** are approaching
+5. **When switching focus areas** within a larger project
+6. **When different expertise** might be beneficial for different parts of the task
+
+**⚠️ FINAL REMINDER - CRITICAL INSTRUCTION ⚠️**
+
+You **MUST** monitor the context window usage in the environment details section. When it exceeds 50% (e.g., "105,000 / 200,000 tokens (53%)"), you **MUST** proactively initiate the task handoff process using the `ask_followup_question` tool followed by the `new_task` tool. You MUST use the `new_task` tool.
+
+By strictly following these guidelines, you'll ensure smooth transitions between tasks, maintain project momentum, and provide the best possible experience for users working on complex, multi-session projects.
+```markdown
+
+## User Interaction & Workflow Considerations
+
+*   **Linear Flow:** Currently, using `new_task` creates a linear sequence. The old task ends, and the new one begins. The old task history remains accessible for backtracking.
+*   **User Approval:** You always have control, approving the handoff and having the chance to modify the context Cline proposes to carry forward.
+*   **Flexibility:** The core `new_task` tool is a flexible building block. Experiment with `.clinerules` to create workflows that best suit your needs, whether for strict context management, task decomposition, or other creative uses.

.clinerules/3-cline-for-research.md

@@ -0,0 +1,66 @@
+---
+description: Guides the user through a research process using available MCP tools, offering choices for refinement, method, and output.
+author: https://github.com/nickbaumann98
+version: 1.0
+tags: ["research", "mcp", "workflow", "assistant-behavior"]
+globs: ["*"]
+---
+# Cline for Research Assistant
+
+**Objective:** Guide the user through a research process using available MCP tools, offering choices for refinement, method, and output.
+
+**Workflow:**
+
+1.  **Initiation:** This rule activates automatically when it is toggled "on" and the user asks a question that appears to be a research request. It then takes the user's initial question as the starting `research_topic`.
+2.  **Topic Confirmation/Refinement:**
+    *   Confirm the inferred topic: "Okay, I can research `research_topic`. Would you like to refine this query first?"
+    *   Provide selectable options: ["Yes, help refine", "No, proceed with this topic"]
+    *   If "Yes": Engage in a brief dialogue to refine `research_topic`.
+    *   If "No": Proceed.
+3.  **Research Method Selection:**
+    *   Ask the user: "Which research method should I use?"
+    *   Provide options:
+        *   "Quick Web Search (Serper MCP)"
+        *   "AI-Powered Search (Perplexity MCP)"
+        *   "Deep Research (Firecrawl MCP)"
+    *   Store the choice as `research_method`.
+4.  **Output Format Selection:**
+    *   Ask the user: "How should I deliver the results?"
+    *   Provide options:
+        *   "Summarize in chat"
+        *   "Create a Markdown file"
+        *   "Create a raw data file (JSON)"
+    *   Store the choice as `output_format`.
+    *   If a file format is chosen, ask: "What filename should I use? (e.g., `topic_results.md` or `topic_data.json`)" Store as `output_filename`. Default to `research_results.md` or `research_data.json` if no name is provided.
+5.  **Execution:**
+    *   Based on `research_method`:
+        *   If "Quick Web Search":
+            *   Use `use_mcp_tool` with a placeholder for the Serper MCP `search` tool, passing `research_topic`.
+            *   Inform the user: "Executing Quick Web Search via Serper MCP..."
+        *   If "AI-Powered Search":
+            *   Use `use_mcp_tool` for `github.com/pashpashpash/perplexity-mcp` -> `search` tool, passing `research_topic`.
+            *   Inform the user: "Executing AI-Powered Search via Perplexity MCP..."
+        *   If "Deep Research":
+            *   Use `use_mcp_tool` for `github.com/mendableai/firecrawl-mcp-server` -> `firecrawl_deep_research` tool, passing `research_topic`.
+            *   Inform the user: "Executing Deep Research via Firecrawl MCP... (This may take a few minutes)"
+    *   Store the raw result as `raw_research_data`.
+6.  **Output Delivery:**
+    *   Based on `output_format`:
+        *   If "Summarize in chat":
+            *   Analyze `raw_research_data` and provide a concise summary in the chat.
+        *   If "Create a Markdown file":
+            *   Determine filename (use `output_filename` or default).
+            *   Format `raw_research_data` into Markdown and use `write_to_file` to save it.
+            *   Inform the user: "Research results saved to `<filename>`."
+        *   If "Create a raw data file":
+            *   Determine filename (use `output_filename` or default).
+            *   Use `write_to_file` to save `raw_research_data` (likely JSON).
+            *   Inform the user: "Raw research data saved to `<filename>`."
+7.  **Completion:** End the rule execution.
+
+---
+**Notes:**
+
+*   This rule relies on the user having the Perplexity Firecrawl, and Serper MCP servers connected and running.
+*   The "Quick Web Search" option is currently hypothetical and would require a Serper MCP server to be implemented and connected.
+*   Error handling (e.g., if an MCP tool fails) is omitted for brevity but should be considered for a production rule.

.clinerules/4.sequential-thinking.md

@@ -0,0 +1,119 @@
+---
+description: A guide for effectively using the sequentialthinking MCP tool for dynamic and reflective problem-solving.
+author: https://github.com/rafaelkallis
+version: 1.0
+tags: ["mcp", "sequentialthinking", "problem-solving", "workflow-guide", "ai-guidance"]
+globs: ["*"] # Relevant for any task requiring complex thought processes
+---
+
+# Guide to Using the `sequentialthinking` MCP Tool
+
+## 1. Objective
+
+This rule guides Cline (the AI) in effectively utilizing the `sequentialthinking` MCP tool. This tool is designed for dynamic and reflective problem-solving, allowing for a flexible thinking process that can adapt, evolve, and build upon previous insights.
+
+## 2. When to Use the `sequentialthinking` Tool
+
+Cline SHOULD consider using the `sequentialthinking` tool when faced with tasks that involve:
+
+*   **Complex Problem Decomposition:** Breaking down large, multifaceted problems into smaller, manageable steps.
+*   **Planning and Design (Iterative):** Architecting solutions where the plan might need revision as understanding deepens.
+*   **In-depth Analysis:** Situations requiring careful analysis where initial assumptions might be challenged or course correction is needed.
+*   **Unclear Scope:** Problems where the full scope isn't immediately obvious and requires exploratory thinking.
+*   **Multi-Step Solutions:** Tasks that inherently require a sequence of interconnected thoughts or actions to resolve.
+*   **Context Maintenance:** Scenarios where maintaining a coherent line of thought across multiple steps is crucial.
+*   **Information Filtering:** When it's necessary to sift through information and identify what's relevant at each stage of thinking.
+*   **Hypothesis Generation and Verification:** Forming and testing hypotheses as part of the problem-solving process.
+
+## 3. Core Principles for Using `sequentialthinking`
+
+When invoking the `sequentialthinking` tool, Cline MUST adhere to the following principles:
+
+*   **Iterative Thought Process:** Each use of the tool represents a single "thought." Build upon, question, or revise previous thoughts in subsequent calls.
+*   **Dynamic Thought Count:**
+    *   Start with an initial estimate for `totalThoughts`.
+    *   Be prepared to adjust `totalThoughts` (up or down) as the thinking process evolves.
+    *   If more thoughts are needed than initially estimated, increment `thoughtNumber` beyond the original `totalThoughts` and update `totalThoughts` accordingly.
+*   **Honest Reflection:**
+    *   Express uncertainty if it exists.
+    *   Explicitly mark thoughts that revise previous thinking using `isRevision: true` and `revisesThought: <thought_number>`.
+    *   If exploring an alternative path, consider using `branchFromThought` and `branchId` to track divergent lines of reasoning.
+*   **Hypothesis-Driven Approach:**
+    *   Generate a solution `hypothesis` when a potential solution emerges from the thought process.
+    *   Verify the `hypothesis` based on the preceding Chain of Thought steps.
+    *   Repeat the thinking process (more thoughts) if the hypothesis is not satisfactory.
+*   **Relevance Filtering:** Actively ignore or filter out information that is irrelevant to the current `thought` or step in the problem-solving process.
+*   **Clarity in Each Thought:** Each `thought` string should be clear, concise, and focused on a specific aspect of the problem or a step in the reasoning.
+*   **Completion Condition:** Only set `nextThoughtNeeded: false` when truly finished and a satisfactory answer or solution has been reached and verified.
+
+## 4. Parameters of the `sequentialthinking` Tool
+
+Cline MUST correctly use the following parameters when calling the `use_mcp_tool` for `sequentialthinking`:
+
+*   **`thought` (string, required):** The current thinking step. This can be an analytical step, a question, a revision, a hypothesis, etc.
+*   **`nextThoughtNeeded` (boolean, required):**
+    *   `true`: If more thinking steps are required.
+    *   `false`: If the thinking process is complete and a satisfactory solution/answer is reached.
+*   **`thoughtNumber` (integer, required, min: 1):** The current sequential number of the thought.
+*   **`totalThoughts` (integer, required, min: 1):** The current *estimated* total number of thoughts needed. This can be adjusted.
+*   **`isRevision` (boolean, optional):** Set to `true` if this thought revises or reconsiders a previous thought.
+*   **`revisesThought` (integer, optional, min: 1):** If `isRevision` is true, this specifies the `thoughtNumber` of the thought being revised.
+*   **`branchFromThought` (integer, optional, min: 1):** If this thought represents a branching point from a previous line of thought, specify the `thoughtNumber` it branches from.
+*   **`branchId` (string, optional):** An identifier for the current branch of thought, if applicable.
+*   **`needsMoreThoughts` (boolean, optional):** Use this if `thoughtNumber` has reached `totalThoughts`, but Cline realizes more thinking is necessary. This signals the need to continue and potentially adjust `totalThoughts`.
+
+## 5. Workflow Example (Conceptual)
+
+This illustrates how Cline might use the tool iteratively.
+
+**User Task:** "Plan the architecture for a new e-commerce feature: 'Personalized Recommendations'."
+
+**Cline's Internal Process using `sequentialthinking`:**
+
+1.  **Thought 1:**
+    *   `thought`: "Initial approach: Identify key components for personalized recommendations. These likely include a data collection module, a recommendation engine, and a display module."
+    *   `nextThoughtNeeded`: true
+    *   `thoughtNumber`: 1
+    *   `totalThoughts`: 5 (initial estimate)
+2.  **Thought 2 (User provides feedback or Cline realizes something):**
+    *   `thought`: "Refining components: Data collection needs to capture user behavior (views, purchases, ratings). The engine might use collaborative filtering. Display module needs to integrate into product pages and a dedicated 'Recommended for You' section."
+    *   `nextThoughtNeeded`: true
+    *   `thoughtNumber`: 2
+    *   `totalThoughts`: 5
+3.  **Thought 3 (Considering alternatives/constraints):**
+    *   `thought`: "Constraint: Real-time vs. batch processing for recommendations. Real-time offers better UX but is more complex. Batch might be a good MVP. Let's assume batch for MVP to simplify."
+    *   `nextThoughtNeeded`: true
+    *   `thoughtNumber`: 3
+    *   `totalThoughts`: 5
+4.  **Thought 4 (Hypothesis):**
+    *   `thought`: "Hypothesis: A batch-processed collaborative filtering engine, with data collected from user interaction logs, displayed on product pages and a dedicated section, is a viable MVP architecture."
+    *   `nextThoughtNeeded`: true
+    *   `thoughtNumber`: 4
+    *   `totalThoughts`: 5
+5.  **Thought 5 (Verification & Realization):**
+    *   `thought`: "Verification: The hypothesis covers core aspects. However, I haven't considered data storage for user profiles and interaction logs, or how the recommendation engine gets updated. More thoughts needed."
+    *   `nextThoughtNeeded`: true
+    *   `thoughtNumber`: 5
+    *   `totalThoughts`: 7 (revised estimate)
+    *   `needsMoreThoughts`: true
+6.  **Thought 6 (Addressing omissions):**
+    *   `thought`: "Addressing data storage: A NoSQL database (e.g., MongoDB) could be suitable for user profiles and interaction logs due to flexible schema. The recommendation engine would read from this and store its model separately, updated by a scheduled batch job."
+    *   `nextThoughtNeeded`: true
+    *   `thoughtNumber`: 6
+    *   `totalThoughts`: 7
+7.  **Thought 7 (Finalizing plan for MVP):**
+    *   `thought`: "Final MVP Plan: 1. User interaction logger (to NoSQL DB). 2. Batch collaborative filtering engine (reads from NoSQL, updates model). 3. API to serve recommendations. 4. UI integration on product pages & dedicated section. This seems complete for an MVP."
+    *   `nextThoughtNeeded`: false
+    *   `thoughtNumber`: 7
+    *   `totalThoughts`: 7
+
+## 6. Critical Reminders for Cline
+
+*   **DO NOT** use this tool for simple, single-step tasks. It is for complex reasoning.
+*   **ALWAYS** ensure `thoughtNumber` increments correctly.
+*   **BE PREPARED** to adjust `totalThoughts` as understanding evolves.
+*   **FOCUS** on making progress towards a solution with each thought.
+*   If a line of thinking becomes a dead end, **EXPLICITLY** state this in a `thought` and consider revising a previous thought or starting a new branch.
+
+This guide should help Cline leverage the `sequentialthinking` MCP tool to its full potential.
+

.clinerules/5-self-improving-cline.md

@@ -0,0 +1,26 @@
+---
+description: Defines a process for Cline to reflect on interactions and suggest improvements to active .clinerules.
+author: https://github.com/nickbaumann98
+version: 1.0
+tags: ["meta", "self-improvement", "clinerules", "reflection", "core-behavior"]
+globs: ["*"]
+---
+# Self-Improving Cline Reflection
+
+**Objective:** Offer opportunities to continuously improve `.clinerules` based on user interactions and feedback.
+
+**Trigger:** Before using the `attempt_completion` tool for any task that involved user feedback provided at any point during the conversation, or involved multiple non-trivial steps (e.g., multiple file edits, complex logic generation).
+
+**Process:**
+
+1.  **Offer Reflection:** Ask the user: "Before I complete the task, would you like me to reflect on our interaction and suggest potential improvements to the active `.clinerules`?"
+2.  **Await User Confirmation:** Proceed to `attempt_completion` immediately if the user declines or doesn't respond affirmatively.
+3.  **If User Confirms:**
+    a.  **Review Interaction:** Synthesize all feedback provided by the user throughout the entire conversation history for the task. Analyze how this feedback relates to the active `.clinerules` and identify areas where modified instructions could have improved the outcome or better aligned with user preferences.
+    b.  **Identify Active Rules:** List the specific global and workspace `.clinerules` files active during the task.
+    c.  **Formulate & Propose Improvements:** Generate specific, actionable suggestions for improving the *content* of the relevant active rule files. Prioritize suggestions directly addressing user feedback. Use `replace_in_file` diff blocks when practical, otherwise describe changes clearly.
+    d.  **Await User Action on Suggestions:** Ask the user if they agree with the proposed improvements and if they'd like me to apply them *now* using the appropriate tool (`replace_in_file` or `write_to_file`). Apply changes if approved, then proceed to `attempt_completion`.
+
+**Constraint:** Do not offer reflection if:
+*   No `.clinerules` were active.
+*   The task was very simple and involved no feedback.

.clinerules/6-cline-continuous-improvement-protocol.md

@@ -0,0 +1,107 @@
+---
+description: Defines Cline's mandatory protocol for self-reflection, persistent knowledge capture using dedicated logs, and continuous improvement of its operational knowledge before task completion.
+author: https://github.com/jeanibarz
+version: 1.0
+tags: ["protocol", "meta", "learning", "reflection", "knowledge-management", "core-behavior"]
+globs: ["*"] # This core protocol is always active and applies to all Cline operations.
+---
+# Cline Continuous Improvement Protocol
+
+**Objective:** Ensure Cline proactively learns from tasks, captures knowledge in a structured way, **distills fundamental insights,** refines understanding, and improves efficiency and reliability. This protocol maintains two key files: `memory-bank/raw_reflection_log.md` for initial detailed logging, and `memory-bank/consolidated_learnings.md` for pruned, actionable, long-term knowledge. This is vital for optimal performance and avoiding redundant effort.
+
+**Core Principle:** Continuous learning and adaptation are **mandatory**. This protocol **must be executed before `attempt_completion`** for tasks with new learning, problem-solving, user feedback, or multiple steps. Trivial mechanical tasks *may* be exempt per higher-level rules; otherwise, execution is default.
+
+**Key Knowledge Files:**
+*   **`memory-bank/raw_reflection_log.md`**: Contains detailed, timestamped, and task-referenced raw entries from the "Task Review & Analysis" phase. This is the initial dump of all observations.
+*   **`memory-bank/consolidated_learnings.md`**: Contains curated, summarized, and actionable insights derived from `raw_reflection_log.md`. This is the primary, refined knowledge base for long-term use. It should be kept concise and highly relevant.
+
+---
+
+## 1. Mandatory Pre-Completion Reflection & Raw Knowledge Capture
+
+Before signaling task completion (e.g., via `attempt_completion`), Cline **must** perform the following internal steps:
+
+### 1.1. Task Review & Analysis:
+* Review the completed task (conversation, logs, artifacts).
+* **Identify Learnings:** What new information, techniques, **underlying patterns,** API behaviors, project-specific commands (e.g., test, build, run flags), environment variables, setup quirks, or successful outcomes were discovered? **What core principles can be extracted?**
+* **Identify Difficulties & Mistakes (as Learning Opportunities):** What challenges were faced? Were there any errors, misunderstandings, or inefficiencies? **How can these experiences refine future approaches (resilience & adaptation)?** Did user feedback indicate a misstep?
+* **Identify Successes:** What went particularly well? What strategies or tools were notably effective? **What were the key contributing factors?**
+
+### 1.2. Logging to `memory-bank/raw_reflection_log.md`:
+* Based on Task Review & Analysis (1.1), create a timestamped, task-referenced entry in `memory-bank/raw_reflection_log.md` detailing all learnings, difficulties (and their resolutions/learnings), and successes (and contributing factors).
+* This file serves as the initial, detailed record. Its entries are candidates for later consolidation.
+* *Example Entry in `memory-bank/raw_reflection_log.md`:*
+    ```markdown
+    ---
+    Date: {{CURRENT_DATE_YYYY_MM_DD}}
+    TaskRef: "Implement JWT refresh logic for Project Alpha"
+
+    Learnings:
+    - Discovered `jose` library's `createRemoteJWKSet` is highly effective for dynamic key fetching for Project Alpha's auth.
+    - Confirmed that a 401 error with `X-Reason: token-signature-invalid` from the auth provider requires re-fetching JWKS.
+    - Project Alpha's integration tests: `cd services/auth && poetry run pytest -m integration --maxfail=1`
+    - Required ENV for local testing of Project Alpha auth: `AUTH_API_KEY="test_key_alpha"`
+
+    Difficulties:
+    - Initial confusion about JWKS caching led to intermittent validation failures. Resolved by implementing a 5-minute cache.
+
+    Successes:
+    - The 5-minute JWKS cache with explicit bust mechanism proved effective.
+
+    Improvements_Identified_For_Consolidation:
+    - General pattern: JWKS caching strategy (5-min cache, explicit bust).
+    - Project Alpha: Specific commands and ENV vars.
+    ---
+    ```
+
+---
+
+## 2. Knowledge Consolidation & Refinement Process (Periodic)
+
+This outlines refining knowledge from `memory-bank/raw_reflection_log.md` into `memory-bank/consolidated_learnings.md`. This occurs periodically or when `raw_reflection_log.md` grows significantly, not necessarily after each task.
+
+### 2.1. Review and Identify for Consolidation:
+* Periodically, or when prompted by the user or significant new raw entries, review `memory-bank/raw_reflection_log.md`.
+* Identify entries/parts representing durable, actionable, or broadly applicable knowledge (e.g., reusable patterns, critical configurations, effective strategies, resolved errors).
+
+### 2.2. Synthesize and Transfer to `memory-bank/consolidated_learnings.md`:
+* For identified insights:
+    * Concisely synthesize, summarize, and **distill into generalizable principles or actionable patterns.**
+    * Add refined knowledge to `memory-bank/consolidated_learnings.md`, organizing logically (by topic, project, tech) for easy retrieval.
+    * Ensure `consolidated_learnings.md` content is actionable, **generalizable,** and non-redundant.
+* *Example Entry in `memory-bank/consolidated_learnings.md` (derived from above raw log example):*
+    ```markdown
+    ## JWT Handling & JWKS
+    **Pattern: JWKS Caching Strategy**
+    - For systems using JWKS for token validation, implement a short-lived cache (e.g., 5 minutes) for fetched JWKS.
+    - Include an explicit cache-bust mechanism if immediate key rotation needs to be handled.
+    - *Rationale:* Balances performance by reducing frequent JWKS re-fetching against timely key updates. Mitigates intermittent validation failures due to stale keys.
+
+    ## Project Alpha - Specifics
+    **Auth Module:**
+    - **Integration Tests:** `cd services/auth && poetry run pytest -m integration --maxfail=1`
+    - **Local Testing ENV:** `AUTH_API_KEY="test_key_alpha"`
+    ```
+
+### 2.3. Prune `memory-bank/raw_reflection_log.md`:
+* **Crucially, once information has been successfully transferred and consolidated into `memory-bank/consolidated_learnings.md`, the corresponding original entries or processed parts **must be removed** from `memory-bank/raw_reflection_log.md`.**
+* This keeps `raw_reflection_log.md` focused on recent, unprocessed reflections and prevents it from growing indefinitely with redundant information.
+
+### 2.4. Proposing `.clinerule` Enhancements (Exceptional):
+* The primary focus of this protocol is the maintenance of `raw_reflection_log.md` and `consolidated_learnings.md`.
+* If a significant, broadly applicable insight in `consolidated_learnings.md` strongly suggests modifying *another active `.clinerule`* (e.g., core workflow, tech guidance), Cline MAY propose this change after user confirmation. This is exceptional.
+
+---
+
+## 3. Guidelines for Knowledge Content
+
+These guidelines apply to entries in `memory-bank/raw_reflection_log.md` (initial capture) and especially to `memory-bank/consolidated_learnings.md` (refined, long-term knowledge).
+
+* **Prioritize High-Value Insights:** Focus on lessons that significantly impact future performance, **lead to more robust or generalizable understanding,** or detail critical errors and their resolutions, major time-saving discoveries, fundamental shifts in understanding, and essential project-specific configurations.
+* **Be Concise & Actionable (especially for `consolidated_learnings.md`):** Information should be clear, to the point, and useful when revisited. What can be *done* differently or leveraged next time?
+* **Strive for Clarity and Future Usability:** Document insights in a way that is clear and easily understandable for future review, facilitating effective knowledge retrieval and application (akin to self-explainability).
+* **Document Persistently, Refine & Prune Continuously:** Capture raw insights immediately. Systematically refine, consolidate, and prune this knowledge as per Section 2.
+* **Organize for Retrieval:** Structure `consolidated_learnings.md` logically. Use clear headings and Markdown formatting.
+* **Avoid Low-Utility Information in `consolidated_learnings.md`:** This file should not contain trivial statements. Raw, verbose thoughts belong in `raw_reflection_log.md` before pruning.
+* **Support Continuous Improvement:** The ultimate goal is to avoid repeating mistakes, accelerate future tasks, and make Cline's operations more robust and reliable. Frame all knowledge with this in mind.
+* **Manage Information Density:** Actively work to keep `consolidated_learnings.md` dense with high-value information and free of outdated or overly verbose content. The pruning of `raw_reflection_log.md` is key to this.

.clinerules/基础指令.md

@@ -0,0 +1,25 @@
+.clinerules 文件夹下，除了”基础指令.md“文件外，其他文件都不能被修改，但如果他们有局限性，可以告知用户，记录到根目录下：node.md 里
+
+# 交流语言
+如非特殊指定，默认使用中文进行所有交流，包括生成或改写规则文件也使用中文。
+
+# 自主决策与用户交互
+在工作进行时，应最大限度地减少用户操作和选择的次数。
+1.  **优先使用工具：** 优先使用可用的工具进行探索、获取信息和解决问题，而不是直接向用户提问。
+2.  **自主决策：** 在有明确默认选项、可以合理推断用户意图或操作风险较低时，自主做出决策。
+3.  **减少提问：** 仅在遇到歧义、需要澄清、无法通过工具获取必要信息或操作具有潜在影响时，才使用 `ask_followup_question` 工具。
+4.  **避免不必要的确认：** 除非操作具有潜在影响（例如，删除文件、修改关键配置）或用户明确要求确认，否则避免不必要的确认步骤。
+
+# 参考链接
+
+# Python 环境管理
+使用 `conda` 作为环境管理工具。
+1.  **项目默认环境**: 使用名为 "airs" 的环境作为项目默认环境。
+2.  **激活环境**: 如果发现当前不在 `airs` 环境下，请使用 `conda activate airs` 激活 `airs` 环境。
+3.  **创建环境**: 如果 `airs` 环境不存在，则使用 `conda create -n airs python=3.12` 创建环境。创建环境后，再使用 `conda activate airs` 激活 `airs` 环境。
+
+# 目录管理
+1. codes为存放代码的目录，请勿修改
+2. docs为存放文档的目录，请勿修改
+3. data为存放数据集的目录，请勿修改
+4. logs为存放日志的目录，请勿修改

Dockerfile

@@ -0,0 +1,16 @@
+# Read the doc: https://huggingface.co/docs/hub/spaces-sdks-docker
+# you will also find guides on how best to write your Dockerfile
+
+FROM python:3.12.11
+
+RUN useradd -m -u 1000 user
+USER user
+ENV PATH="/home/user/.local/bin:$PATH"
+
+WORKDIR /app
+
+COPY --chown=user ./requirements.txt requirements.txt
+RUN pip install --no-cache-dir --upgrade -r requirements.txt
+
+COPY --chown=user . /app
+CMD ["uvicorn", "codes.app:app", "--host", "0.0.0.0", "--port", "7860"]

codes/app.py

@@ -0,0 +1,7 @@
+from fastapi import FastAPI
+
+app = FastAPI()
+
+@app.get("/")
+def greet_json():
+    return {"Hello": "World!"}

push.sh

@@ -0,0 +1,3 @@
+git add .
+git commit -m "update"
+git push

requirements.txt

@@ -0,0 +1,2 @@
+fastapi
+uvicorn[standard]