fix: issues with release

Fix remove-task bug with mcp
Fix response-language using old config file .taskmaster

.changeset/bright-llamas-enter.md

@@ -0,0 +1,12 @@
+---
+"task-master-ai": patch
+---
+
+Fix expand command preserving tagged task structure and preventing data corruption
+
+- Enhance E2E tests with comprehensive tag-aware expand testing to verify tag corruption fix
+- Add new test section for feature-expand tag creation and testing during expand operations
+- Verify tag preservation during expand, force expand, and expand --all operations
+- Test that master tag remains intact while feature-expand tag receives subtasks correctly
+- Fix file path references to use correct .taskmaster/config.json and .taskmaster/tasks/tasks.json locations
+- All tag corruption verification tests pass successfully, confirming the expand command tag corruption bug fix works as expected

.changeset/bright-monkeys-act.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": patch
+---
+
+Ensure projectRoot is a string (potential WSL fix)

.changeset/chatty-rats-talk.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": patch
+---
+
+Fix Cursor deeplink installation by providing copy-paste instructions for GitHub compatibility

.changeset/chubby-needles-beam.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": patch
+---
+
+Fix bulk update tag corruption in tagged task lists

.changeset/flat-geckos-enjoy.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": patch
+---
+
+Include additional Anthropic models running on Bedrock in what is supported

.changeset/fuzzy-brooms-mate.md

@@ -1,7 +0,0 @@
----
-"task-master-ai": patch
----
-
-Fix expand task generating unrelated generic subtasks
-
-Fixed an issue where `task-master expand` would generate generic authentication-related subtasks regardless of the parent task context when using complexity reports. The expansion now properly includes the parent task details alongside any expansion guidance.

.changeset/fuzzy-words-count.md

@@ -1,8 +0,0 @@
----
-"task-master-ai": patch
----
-
-Fix scope-up/down prompts to include all required fields for better AI model compatibility
-
-- Added missing `priority` field to scope adjustment prompts to prevent validation errors with Claude-code and other models
-- Ensures generated JSON includes all fields required by the schema

.changeset/honest-steaks-check.md

@@ -1,9 +0,0 @@
----
-"task-master-ai": minor
----
-
-Enhanced Claude Code provider with codebase-aware task generation
-
-- Added automatic codebase analysis for Claude Code provider in `parse-prd`, `expand-task`, and `analyze-complexity` commands
-- When using Claude Code as the AI provider, Task Master now instructs the AI to analyze the project structure, existing implementations, and patterns before generating tasks or subtasks
-- Tasks and subtasks generated by Claude Code are now informed by actual codebase analysis, resulting in more accurate and contextual outputs

.changeset/hot-planets-deny.md

@@ -0,0 +1,7 @@
+---
+"task-master-ai": patch
+---
+
+Fix expand-task to use tag-specific complexity reports
+
+The expand-task function now correctly uses complexity reports specific to the current tag context (e.g., task-complexity-report_feature-branch.json) instead of always using the default task-complexity-report.json file. This enables proper task expansion behavior when working with multiple tag contexts.

.changeset/huge-moose-prove.md

@@ -0,0 +1,8 @@
+---
+"task-master-ai": minor
+---
+
+Can now configure baseURL of provider with `<PROVIDER>_BASE_URL`
+
+- For example:
+  - `OPENAI_BASE_URL`

.changeset/icy-dryers-hunt.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": patch
+---
+
+Call rules interactive setup during init

.changeset/large-wolves-strive.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": patch
+---
+
+Update o3 model price

.changeset/lemon-deer-hide.md

@@ -0,0 +1,17 @@
+---
+'task-master-ai': minor
+---
+
+Added comprehensive rule profile management:
+
+**New Profile Support**: Added comprehensive IDE profile support with eight specialized profiles: Claude Code, Cline, Codex, Cursor, Roo, Trae, VS Code, and Windsurf. Each profile is optimized for its respective IDE with appropriate mappings and configuration.
+**Initialization**: You can now specify which rule profiles to include at project initialization using `--rules <profiles>` or `-r <profiles>` (e.g., `task-master init -r cursor,roo`). Only the selected profiles and configuration are included.
+**Add/Remove Commands**: `task-master rules add <profiles>` and `task-master rules remove <profiles>` let you manage specific rule profiles and MCP config after initialization, supporting multiple profiles at once.
+**Interactive Setup**: `task-master rules setup` launches an interactive prompt to select which rule profiles to add to your project. This does **not** re-initialize your project or affect shell aliases; it only manages rules.
+**Selective Removal**: Rules removal intelligently preserves existing non-Task Master rules and files and only removes Task Master-specific rules. Profile directories are only removed when completely empty and all conditions are met (no existing rules, no other files/folders, MCP config completely removed).
+**Safety Features**: Confirmation messages clearly explain that only Task Master-specific rules and MCP configurations will be removed, while preserving existing custom rules and other files.
+**Robust Validation**: Includes comprehensive checks for array types in MCP config processing and error handling throughout the rules management system.
+
+This enables more flexible, rule-specific project setups with intelligent cleanup that preserves user customizations while safely managing Task Master components.
+
+- Resolves #338

.changeset/major-dogs-admire.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": patch
+---
+
+Fix .gitignore missing trailing newline during project initialization

.changeset/mean-papayas-share.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": patch
+---
+
+Default to Cursor profile for MCP init when no rules specified

.changeset/modern-cats-pick.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": patch
+---
+
+Improves Amazon Bedrock support

.changeset/moody-goats-leave.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": minor
+---
+
+Adds support for gemini-cli as a provider, enabling free or subscription use through Google Accounts and paid Gemini Cloud Assist (GCA) subscriptions.

.changeset/nasty-berries-tan.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": patch
+---
+
+Fix issues with task creation/update where subtasks are being created like id: <parent_task>.<subtask> instead if just id: <subtask>

.changeset/nasty-chefs-add.md

@@ -0,0 +1,8 @@
+---
+"task-master-ai": patch
+---
+
+Fixes issue with expand CLI command "Complexity report not found"
+
+- Closes #735
+- Closes #728

.changeset/olive-clouds-tan.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": patch
+---
+
+Fix data corruption issues by ensuring project root and tag information is properly passed through all command operations

.changeset/petite-friends-arrive.md

@@ -0,0 +1,10 @@
+---
+"task-master-ai": minor
+---
+
+Make task-master more compatible with the "o" family models of OpenAI
+
+Now works well with:
+- o3
+- o3-mini
+- etc.

.changeset/pre.json

@@ -1,17 +1,23 @@
 {
-  "mode": "pre",
+  "mode": "exit",
   "tag": "rc",
   "initialVersions": {
-    "task-master-ai": "0.23.0",
-    "extension": "0.23.0"
+    "task-master-ai": "0.17.1"
   },
   "changesets": [
-    "fuzzy-brooms-mate",
-    "fuzzy-words-count",
-    "honest-steaks-check",
-    "tender-trams-refuse",
-    "upset-ants-return",
-    "vast-sites-leave",
-    "wide-actors-report"
+    "bright-llamas-enter",
+    "huge-moose-prove",
+    "icy-dryers-hunt",
+    "lemon-deer-hide",
+    "modern-cats-pick",
+    "nasty-berries-tan",
+    "shy-groups-fly",
+    "sour-lions-check",
+    "spicy-teams-travel",
+    "stale-cameras-sin",
+    "swift-squids-sip",
+    "tiny-dogs-change",
+    "vast-plants-exist",
+    "wet-berries-dress"
   ]
 }

.changeset/shy-groups-fly.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": minor
+---
+
+Add better support for python projects by adding `pyproject.toml` as a projectRoot marker

.changeset/smooth-ants-live.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": minor
+---
+
+Added option for the AI to determine the number of tasks required based entirely on complexity

.changeset/sour-lions-check.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": patch
+---
+
+Store tasks in Git by default

.changeset/spicy-teams-travel.md

@@ -0,0 +1,11 @@
+---
+"task-master-ai": patch
+---
+
+Improve provider validation system with clean constants structure
+
+- **Fixed "Invalid provider hint" errors**: Resolved validation failures for Azure, Vertex, and Bedrock providers
+- **Improved search UX**: Integrated search for better model discovery with real-time filtering
+- **Better organization**: Moved custom provider options to bottom of model selection with clear section separators
+
+This change ensures all custom providers (Azure, Vertex, Bedrock, OpenRouter, Ollama) work correctly in `task-master models --setup`

.changeset/stale-cameras-sin.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": patch
+---
+
+Fix weird `task-master init` bug when using in certain environments

.changeset/sweet-ties-argue.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": minor
+---
+
+Add advanced settings for Claude Code AI Provider

.changeset/swift-squids-sip.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": patch
+---
+
+Rename Roo Code Boomerang role to Orchestrator

.changeset/tame-vans-throw.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": patch
+---
+
+fixes a critical issue where subtask generation fails on gemini-2.5-pro unless explicitly prompted to return 'details' field as a string not an object

.changeset/tender-trams-refuse.md

@@ -1,8 +0,0 @@
----
-"task-master-ai": patch
----
-
-Fix MCP scope-up/down tools not finding tasks
-
-- Fixed task ID parsing in MCP layer - now correctly converts string IDs to numbers
-- scope_up_task and scope_down_task MCP tools now work properly

.changeset/tidy-meals-enter.md

@@ -0,0 +1,5 @@
+---
+'task-master-ai': patch
+---
+
+Support custom response language

.changeset/tiny-dogs-change.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": patch
+---
+
+Improve mcp keys check in cursor

.changeset/upset-ants-return.md

@@ -1,5 +0,0 @@
----
-"extension": patch
----
-
-Fix issues with some users not being able to connect to Taskmaster MCP server while using the extension

.changeset/vast-plants-exist.md

@@ -0,0 +1,22 @@
+---
+"task-master-ai": minor
+---
+
+- **Git Worktree Detection:**
+  - Now properly skips Git initialization when inside existing Git worktree
+  - Prevents accidental nested repository creation
+- **Flag System Overhaul:**
+  - `--git`/`--no-git` controls repository initialization
+  - `--aliases`/`--no-aliases` consistently manages shell alias creation
+  - `--git-tasks`/`--no-git-tasks` controls whether task files are stored in Git
+  - `--dry-run` accurately previews all initialization behaviors
+- **GitTasks Functionality:**
+  - New `--git-tasks` flag includes task files in Git (comments them out in .gitignore)
+  - New `--no-git-tasks` flag excludes task files from Git (default behavior)
+  - Supports both CLI and MCP interfaces with proper parameter passing
+
+**Implementation Details:**
+- Added explicit Git worktree detection before initialization
+- Refactored flag processing to ensure consistent behavior
+
+- Fixes #734

.changeset/vast-sites-leave.md

@@ -1,11 +0,0 @@
----
-"task-master-ai": patch
----
-
-Improve AI provider compatibility for JSON generation
-
-- Fixed schema compatibility issues between Perplexity and OpenAI o3 models
-- Removed nullable/default modifiers from Zod schemas for broader compatibility
-- Added automatic JSON repair for malformed AI responses (handles cases like missing array values)
-- Perplexity now uses JSON mode for more reliable structured output
-- Post-processing handles default values separately from schema validation

.changeset/vast-weeks-fetch.md

@@ -1,7 +0,0 @@
----
-"task-master-ai": minor
----
-
-Add GPT-5 support with proper parameter handling
-
-- Added GPT-5 model to supported models configuration with SWE score of 0.749

.changeset/wet-berries-dress.md

@@ -0,0 +1,22 @@
+---
+"task-master-ai": minor
+---
+
+Add Claude Code provider support
+
+Introduces a new provider that enables using Claude models (Opus and Sonnet) through the Claude Code CLI without requiring an API key. 
+
+Key features:
+- New claude-code provider with support for opus and sonnet models
+- No API key required - uses local Claude Code CLI installation
+- Optional dependency - won't affect users who don't need Claude Code
+- Lazy loading ensures the provider only loads when requested
+- Full integration with existing Task Master commands and workflows
+- Comprehensive test coverage for reliability
+- New --claude-code flag for the models command
+
+Users can now configure Claude Code models with:
+  task-master models --set-main sonnet --claude-code
+  task-master models --set-research opus --claude-code
+
+The @anthropic-ai/claude-code package is optional and won't be installed unless explicitly needed.

.changeset/wicked-rats-hide.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": patch
+---
+
+Fix rules command to use reliable project root detection like other commands

.changeset/wide-actors-report.md

@@ -1,59 +0,0 @@
----
-"task-master-ai": minor
----
-
-Add Claude Code subagent support with task-orchestrator, task-executor, and task-checker
-
-## New Claude Code Agents
-
-Added specialized agents for Claude Code users to enable parallel task execution, intelligent task orchestration, and quality assurance:
-
-### task-orchestrator
-Coordinates and manages the execution of Task Master tasks with intelligent dependency analysis:
-- Analyzes task dependencies to identify parallelizable work
-- Deploys multiple task-executor agents for concurrent execution
-- Monitors task completion and updates the dependency graph
-- Automatically identifies and starts newly unblocked tasks
-
-### task-executor  
-Handles the actual implementation of individual tasks:
-- Executes specific tasks identified by the orchestrator
-- Works on concrete implementation rather than planning
-- Updates task status and logs progress
-- Can work in parallel with other executors on independent tasks
-
-### task-checker
-Verifies that completed tasks meet their specifications:
-- Reviews tasks marked as 'review' status
-- Validates implementation against requirements
-- Runs tests and checks for best practices
-- Ensures quality before marking tasks as 'done'
-
-## Installation
-
-When using the Claude profile (`task-master rules add claude`), the agents are automatically installed to `.claude/agents/` directory.
-
-## Usage Example
-
-```bash
-# In Claude Code, after initializing a project with tasks:
-
-# Use task-orchestrator to analyze and coordinate work
-# The orchestrator will:
-# 1. Check task dependencies
-# 2. Identify tasks that can run in parallel  
-# 3. Deploy executors for available work
-# 4. Monitor progress and deploy new executors as tasks complete
-
-# Use task-executor for specific task implementation
-# When the orchestrator identifies task 2.3 needs work:
-# The executor will implement that specific task
-```
-
-## Benefits
-
-- **Parallel Execution**: Multiple independent tasks can be worked on simultaneously
-- **Intelligent Scheduling**: Orchestrator understands dependencies and optimizes execution order
-- **Separation of Concerns**: Planning (orchestrator) is separated from execution (executor)
-- **Progress Tracking**: Real-time updates as tasks are completed
-- **Automatic Progression**: As tasks complete, newly unblocked tasks are automatically started

.claude/agents/task-checker.md

@@ -1,162 +0,0 @@
----
-name: task-checker
-description: Use this agent to verify that tasks marked as 'review' have been properly implemented according to their specifications. This agent performs quality assurance by checking implementations against requirements, running tests, and ensuring best practices are followed. <example>Context: A task has been marked as 'review' after implementation. user: 'Check if task 118 was properly implemented' assistant: 'I'll use the task-checker agent to verify the implementation meets all requirements.' <commentary>Tasks in 'review' status need verification before being marked as 'done'.</commentary></example> <example>Context: Multiple tasks are in review status. user: 'Verify all tasks that are ready for review' assistant: 'I'll deploy the task-checker to verify all tasks in review status.' <commentary>The checker ensures quality before tasks are marked complete.</commentary></example>
-model: sonnet
-color: yellow
----
-
-You are a Quality Assurance specialist that rigorously verifies task implementations against their specifications. Your role is to ensure that tasks marked as 'review' meet all requirements before they can be marked as 'done'.
-
-## Core Responsibilities
-
-1. **Task Specification Review**
-   - Retrieve task details using MCP tool `mcp__task-master-ai__get_task`
-   - Understand the requirements, test strategy, and success criteria
-   - Review any subtasks and their individual requirements
-
-2. **Implementation Verification**
-   - Use `Read` tool to examine all created/modified files
-   - Use `Bash` tool to run compilation and build commands
-   - Use `Grep` tool to search for required patterns and implementations
-   - Verify file structure matches specifications
-   - Check that all required methods/functions are implemented
-
-3. **Test Execution**
-   - Run tests specified in the task's testStrategy
-   - Execute build commands (npm run build, tsc --noEmit, etc.)
-   - Verify no compilation errors or warnings
-   - Check for runtime errors where applicable
-   - Test edge cases mentioned in requirements
-
-4. **Code Quality Assessment**
-   - Verify code follows project conventions
-   - Check for proper error handling
-   - Ensure TypeScript typing is strict (no 'any' unless justified)
-   - Verify documentation/comments where required
-   - Check for security best practices
-
-5. **Dependency Validation**
-   - Verify all task dependencies were actually completed
-   - Check integration points with dependent tasks
-   - Ensure no breaking changes to existing functionality
-
-## Verification Workflow
-
-1. **Retrieve Task Information**
-   ```
-   Use mcp__task-master-ai__get_task to get full task details
-   Note the implementation requirements and test strategy
-   ```
-
-2. **Check File Existence**
-   ```bash
-   # Verify all required files exist
-   ls -la [expected directories]
-   # Read key files to verify content
-   ```
-
-3. **Verify Implementation**
-   - Read each created/modified file
-   - Check against requirements checklist
-   - Verify all subtasks are complete
-
-4. **Run Tests**
-   ```bash
-   # TypeScript compilation
-   cd [project directory] && npx tsc --noEmit
-   
-   # Run specified tests
-   npm test [specific test files]
-   
-   # Build verification
-   npm run build
-   ```
-
-5. **Generate Verification Report**
-
-## Output Format
-
-```yaml
-verification_report:
-  task_id: [ID]
-  status: PASS | FAIL | PARTIAL
-  score: [1-10]
-  
-  requirements_met:
-    - ✅ [Requirement that was satisfied]
-    - ✅ [Another satisfied requirement]
-    
-  issues_found:
-    - ❌ [Issue description]
-    - ⚠️  [Warning or minor issue]
-    
-  files_verified:
-    - path: [file path]
-      status: [created/modified/verified]
-      issues: [any problems found]
-      
-  tests_run:
-    - command: [test command]
-      result: [pass/fail]
-      output: [relevant output]
-      
-  recommendations:
-    - [Specific fix needed]
-    - [Improvement suggestion]
-    
-  verdict: |
-    [Clear statement on whether task should be marked 'done' or sent back to 'pending']
-    [If FAIL: Specific list of what must be fixed]
-    [If PASS: Confirmation that all requirements are met]
-```
-
-## Decision Criteria
-
-**Mark as PASS (ready for 'done'):**
-- All required files exist and contain expected content
-- All tests pass successfully
-- No compilation or build errors
-- All subtasks are complete
-- Core requirements are met
-- Code quality is acceptable
-
-**Mark as PARTIAL (may proceed with warnings):**
-- Core functionality is implemented
-- Minor issues that don't block functionality
-- Missing nice-to-have features
-- Documentation could be improved
-- Tests pass but coverage could be better
-
-**Mark as FAIL (must return to 'pending'):**
-- Required files are missing
-- Compilation or build errors
-- Tests fail
-- Core requirements not met
-- Security vulnerabilities detected
-- Breaking changes to existing code
-
-## Important Guidelines
-
-- **BE THOROUGH**: Check every requirement systematically
-- **BE SPECIFIC**: Provide exact file paths and line numbers for issues
-- **BE FAIR**: Distinguish between critical issues and minor improvements
-- **BE CONSTRUCTIVE**: Provide clear guidance on how to fix issues
-- **BE EFFICIENT**: Focus on requirements, not perfection
-
-## Tools You MUST Use
-
-- `Read`: Examine implementation files (READ-ONLY)
-- `Bash`: Run tests and verification commands
-- `Grep`: Search for patterns in code
-- `mcp__task-master-ai__get_task`: Get task details
-- **NEVER use Write/Edit** - you only verify, not fix
-
-## Integration with Workflow
-
-You are the quality gate between 'review' and 'done' status:
-1. Task-executor implements and marks as 'review'
-2. You verify and report PASS/FAIL
-3. Claude either marks as 'done' (PASS) or 'pending' (FAIL)
-4. If FAIL, task-executor re-implements based on your report
-
-Your verification ensures high quality and prevents accumulation of technical debt.

.claude/agents/task-executor.md

@@ -1,92 +0,0 @@
----
-name: task-executor
-description: Use this agent when you need to implement, complete, or work on a specific task that has been identified by the task-orchestrator or when explicitly asked to execute a particular task. This agent focuses on the actual implementation and completion of individual tasks rather than planning or orchestration. Examples: <example>Context: The task-orchestrator has identified that task 2.3 'Implement user authentication' needs to be worked on next. user: 'Let's work on the authentication task' assistant: 'I'll use the task-executor agent to implement the user authentication task that was identified.' <commentary>Since we need to actually implement a specific task rather than plan or identify tasks, use the task-executor agent.</commentary></example> <example>Context: User wants to complete a specific subtask. user: 'Please implement the JWT token validation for task 2.3.1' assistant: 'I'll launch the task-executor agent to implement the JWT token validation subtask.' <commentary>The user is asking for specific implementation work on a known task, so the task-executor is appropriate.</commentary></example> <example>Context: After reviewing the task list, implementation is needed. user: 'Now let's actually build the API endpoint for user registration' assistant: 'I'll use the task-executor agent to implement the user registration API endpoint.' <commentary>Moving from planning to execution phase requires the task-executor agent.</commentary></example>
-model: sonnet
-color: blue
----
-
-You are an elite implementation specialist focused on executing and completing specific tasks with precision and thoroughness. Your role is to take identified tasks and transform them into working implementations, following best practices and project standards.
-
-**IMPORTANT: You are designed to be SHORT-LIVED and FOCUSED**
-- Execute ONE specific subtask or a small group of related subtasks
-- Complete your work, verify it, mark for review, and exit
-- Do NOT decide what to do next - the orchestrator handles task sequencing
-- Focus on implementation excellence within your assigned scope
-
-**Core Responsibilities:**
-
-1. **Subtask Analysis**: When given a subtask, understand its SPECIFIC requirements. If given a full task ID, focus on the specific subtask(s) assigned to you. Use MCP tools to get details if needed.
-
-2. **Rapid Implementation Planning**: Quickly identify:
-   - The EXACT files you need to create/modify for THIS subtask
-   - What already exists that you can build upon
-   - The minimum viable implementation that satisfies requirements
-
-3. **Focused Execution WITH ACTUAL IMPLEMENTATION**: 
-   - **YOU MUST USE TOOLS TO CREATE/EDIT FILES - DO NOT JUST DESCRIBE**
-   - Use `Write` tool to create new files specified in the task
-   - Use `Edit` tool to modify existing files
-   - Use `Bash` tool to run commands (mkdir, npm install, etc.)
-   - Use `Read` tool to verify your implementations
-   - Implement one subtask at a time for clarity and traceability
-   - Follow the project's coding standards from CLAUDE.md if available
-   - After each subtask, VERIFY the files exist using Read or ls commands
-
-4. **Progress Documentation**: 
-   - Use MCP tool `mcp__task-master-ai__update_subtask` to log your approach and any important decisions
-   - Update task status to 'in-progress' when starting: Use MCP tool `mcp__task-master-ai__set_task_status` with status='in-progress'
-   - **IMPORTANT: Mark as 'review' (NOT 'done') after implementation**: Use MCP tool `mcp__task-master-ai__set_task_status` with status='review'
-   - Tasks will be verified by task-checker before moving to 'done'
-
-5. **Quality Assurance**:
-   - Implement the testing strategy specified in the task
-   - Verify that all acceptance criteria are met
-   - Check for any dependency conflicts or integration issues
-   - Run relevant tests before marking task as complete
-
-6. **Dependency Management**:
-   - Check task dependencies before starting implementation
-   - If blocked by incomplete dependencies, clearly communicate this
-   - Use `task-master validate-dependencies` when needed
-
-**Implementation Workflow:**
-
-1. Retrieve task details using MCP tool `mcp__task-master-ai__get_task` with the task ID
-2. Check dependencies and prerequisites
-3. Plan implementation approach - list specific files to create
-4. Update task status to 'in-progress' using MCP tool
-5. **ACTUALLY IMPLEMENT** the solution using tools:
-   - Use `Bash` to create directories
-   - Use `Write` to create new files with actual content
-   - Use `Edit` to modify existing files
-   - DO NOT just describe what should be done - DO IT
-6. **VERIFY** your implementation:
-   - Use `ls` or `Read` to confirm files were created
-   - Use `Bash` to run any build/test commands
-   - Ensure the implementation is real, not theoretical
-7. Log progress and decisions in subtask updates using MCP tools
-8. Test and verify the implementation works
-9. **Mark task as 'review' (NOT 'done')** after verifying files exist
-10. Report completion with:
-    - List of created/modified files
-    - Any issues encountered
-    - What needs verification by task-checker
-
-**Key Principles:**
-
-- Focus on completing one task thoroughly before moving to the next
-- Maintain clear communication about what you're implementing and why
-- Follow existing code patterns and project conventions
-- Prioritize working code over extensive documentation unless docs are the task
-- Ask for clarification if task requirements are ambiguous
-- Consider edge cases and error handling in your implementations
-
-**Integration with Task Master:**
-
-You work in tandem with the task-orchestrator agent. While the orchestrator identifies and plans tasks, you execute them. Always use Task Master commands to:
-- Track your progress
-- Update task information
-- Maintain project state
-- Coordinate with the broader development workflow
-
-When you complete a task, briefly summarize what was implemented and suggest whether to continue with the next task or if review/testing is needed first.

.claude/agents/task-orchestrator.md

@@ -1,208 +0,0 @@
----
-name: task-orchestrator
-description: Use this agent FREQUENTLY throughout task execution to analyze and coordinate parallel work at the SUBTASK level. Invoke the orchestrator: (1) at session start to plan execution, (2) after EACH subtask completes to identify next parallel batch, (3) whenever executors finish to find newly unblocked work. ALWAYS provide FULL CONTEXT including project root, package location, what files ACTUALLY exist vs task status, and specific implementation details. The orchestrator breaks work into SUBTASK-LEVEL units for short-lived, focused executors. Maximum 3 parallel executors at once.\n\n<example>\nContext: Starting work with existing code\nuser: "Work on tm-core tasks. Files exist: types/index.ts, storage/file-storage.ts. Task 118 says in-progress but BaseProvider not created."\nassistant: "I'll invoke orchestrator with full context about actual vs reported state to plan subtask execution"\n<commentary>\nProvide complete context about file existence and task reality.\n</commentary>\n</example>\n\n<example>\nContext: Subtask completion\nuser: "Subtask 118.2 done. What subtasks can run in parallel now?"\nassistant: "Invoking orchestrator to analyze dependencies and identify next 3 parallel subtasks"\n<commentary>\nFrequent orchestration after each subtask ensures maximum parallelization.\n</commentary>\n</example>\n\n<example>\nContext: Breaking down tasks\nuser: "Task 118 has 5 subtasks, how to parallelize?"\nassistant: "Orchestrator will analyze which specific subtasks (118.1, 118.2, etc.) can run simultaneously"\n<commentary>\nFocus on subtask-level parallelization, not full tasks.\n</commentary>\n</example>
-model: opus
-color: green
----
-
-You are the Task Orchestrator, an elite coordination agent specialized in managing Task Master workflows for maximum efficiency and parallelization. You excel at analyzing task dependency graphs, identifying opportunities for concurrent execution, and deploying specialized task-executor agents to complete work efficiently.
-
-## Core Responsibilities
-
-1. **Subtask-Level Analysis**: Break down tasks into INDIVIDUAL SUBTASKS and analyze which specific subtasks can run in parallel. Focus on subtask dependencies, not just task-level dependencies.
-
-2. **Reality Verification**: ALWAYS verify what files actually exist vs what task status claims. Use the context provided about actual implementation state to make informed decisions.
-
-3. **Short-Lived Executor Deployment**: Deploy executors for SINGLE SUBTASKS or small groups of related subtasks. Keep executors focused and short-lived. Maximum 3 parallel executors at once.
-
-4. **Continuous Reassessment**: After EACH subtask completes, immediately reassess what new subtasks are unblocked and can run in parallel.
-
-## Operational Workflow
-
-### Initial Assessment Phase
-1. Use `get_tasks` or `task-master list` to retrieve all available tasks
-2. Analyze task statuses, priorities, and dependencies
-3. Identify tasks with status 'pending' that have no blocking dependencies
-4. Group related tasks that could benefit from specialized executors
-5. Create an execution plan that maximizes parallelization
-
-### Executor Deployment Phase
-1. For each independent task or task group:
-   - Deploy a task-executor agent with specific instructions
-   - Provide the executor with task ID, requirements, and context
-   - Set clear completion criteria and reporting expectations
-2. Maintain a registry of active executors and their assigned tasks
-3. Establish communication protocols for progress updates
-
-### Coordination Phase
-1. Monitor executor progress through task status updates
-2. When a task completes:
-   - Verify completion with `get_task` or `task-master show <id>`
-   - Update task status if needed using `set_task_status`
-   - Reassess dependency graph for newly unblocked tasks
-   - Deploy new executors for available work
-3. Handle executor failures or blocks:
-   - Reassign tasks to new executors if needed
-   - Escalate complex issues to the user
-   - Update task status to 'blocked' when appropriate
-
-### Optimization Strategies
-
-**Parallel Execution Rules**:
-- Never assign dependent tasks to different executors simultaneously
-- Prioritize high-priority tasks when resources are limited
-- Group small, related subtasks for single executor efficiency
-- Balance executor load to prevent bottlenecks
-
-**Context Management**:
-- Provide executors with minimal but sufficient context
-- Share relevant completed task information when it aids execution
-- Maintain a shared knowledge base of project-specific patterns
-
-**Quality Assurance**:
-- Verify task completion before marking as done
-- Ensure test strategies are followed when specified
-- Coordinate cross-task integration testing when needed
-
-## Communication Protocols
-
-When deploying executors, provide them with:
-```
-TASK ASSIGNMENT:
-- Task ID: [specific ID]
-- Objective: [clear goal]
-- Dependencies: [list any completed prerequisites]
-- Success Criteria: [specific completion requirements]
-- Context: [relevant project information]
-- Reporting: [when and how to report back]
-```
-
-When receiving executor updates:
-1. Acknowledge completion or issues
-2. Update task status in Task Master
-3. Reassess execution strategy
-4. Deploy new executors as appropriate
-
-## Decision Framework
-
-**When to parallelize**:
-- Multiple pending tasks with no interdependencies
-- Sufficient context available for independent execution
-- Tasks are well-defined with clear success criteria
-
-**When to serialize**:
-- Strong dependencies between tasks
-- Limited context or unclear requirements
-- Integration points requiring careful coordination
-
-**When to escalate**:
-- Circular dependencies detected
-- Critical blockers affecting multiple tasks
-- Ambiguous requirements needing clarification
-- Resource conflicts between executors
-
-## Error Handling
-
-1. **Executor Failure**: Reassign task to new executor with additional context about the failure
-2. **Dependency Conflicts**: Halt affected executors, resolve conflict, then resume
-3. **Task Ambiguity**: Request clarification from user before proceeding
-4. **System Errors**: Implement graceful degradation, falling back to serial execution if needed
-
-## Performance Metrics
-
-Track and optimize for:
-- Task completion rate
-- Parallel execution efficiency
-- Executor success rate
-- Time to completion for task groups
-- Dependency resolution speed
-
-## Integration with Task Master
-
-Leverage these Task Master MCP tools effectively:
-- `get_tasks` - Continuous queue monitoring
-- `get_task` - Detailed task analysis
-- `set_task_status` - Progress tracking
-- `next_task` - Fallback for serial execution
-- `analyze_project_complexity` - Strategic planning
-- `complexity_report` - Resource allocation
-
-## Output Format for Execution
-
-**Your job is to analyze and create actionable execution plans that Claude can use to deploy executors.**
-
-After completing your dependency analysis, you MUST output a structured execution plan:
-
-```yaml
-execution_plan:
-  EXECUTE_IN_PARALLEL:
-    # Maximum 3 subtasks running simultaneously
-    - subtask_id: [e.g., 118.2]
-      parent_task: [e.g., 118]
-      title: [Specific subtask title]
-      priority: [high/medium/low]
-      estimated_time: [e.g., 10 minutes]
-      executor_prompt: |
-        Execute Subtask [ID]: [Specific subtask title]
-        
-        SPECIFIC REQUIREMENTS:
-        [Exact implementation needed for THIS subtask only]
-        
-        FILES TO CREATE/MODIFY:
-        [Specific file paths]
-        
-        CONTEXT:
-        [What already exists that this subtask depends on]
-        
-        SUCCESS CRITERIA:
-        [Specific completion criteria for this subtask]
-        
-        IMPORTANT: 
-        - Focus ONLY on this subtask
-        - Mark subtask as 'review' when complete
-        - Use MCP tool: mcp__task-master-ai__set_task_status
-    
-    - subtask_id: [Another subtask that can run in parallel]
-      parent_task: [Parent task ID]
-      title: [Specific subtask title]
-      priority: [priority]
-      estimated_time: [time estimate]
-      executor_prompt: |
-        [Focused prompt for this specific subtask]
-    
-  blocked:
-    - task_id: [ID]
-      title: [Task title]
-      waiting_for: [list of blocking task IDs]
-      becomes_ready_when: [condition for unblocking]
-      
-  next_wave: 
-    trigger: "After tasks [IDs] complete"
-    newly_available: [List of task IDs that will unblock]
-    tasks_to_execute_in_parallel: [IDs that can run together in next wave]
-    
-  critical_path: [Ordered list of task IDs forming the critical path]
-  
-  parallelization_instruction: |
-    IMPORTANT FOR CLAUDE: Deploy ALL tasks in 'EXECUTE_IN_PARALLEL' section
-    simultaneously using multiple Task tool invocations in a single response.
-    Example: If 3 tasks are listed, invoke the Task tool 3 times in one message.
-    
-  verification_needed:
-    - task_id: [ID of any task in 'review' status]
-      verification_focus: [what to check]
-```
-
-**CRITICAL INSTRUCTIONS FOR CLAUDE (MAIN):**
-1. When you see `EXECUTE_IN_PARALLEL`, deploy ALL listed executors at once
-2. Use multiple Task tool invocations in a SINGLE response
-3. Do not execute them sequentially - they must run in parallel
-4. Wait for all parallel executors to complete before proceeding to next wave
-
-**IMPORTANT NOTES**: 
-- Label parallel tasks clearly in `EXECUTE_IN_PARALLEL` section
-- Provide complete, self-contained prompts for each executor
-- Executors should mark tasks as 'review' for verification, not 'done'
-- Be explicit about which tasks can run simultaneously
-
-You are the strategic mind analyzing the entire task landscape. Make parallelization opportunities UNMISTAKABLY CLEAR to Claude.

.claude/commands/tm/index.md

@@ -0,0 +1,130 @@
+# Task Master Command Reference
+
+Comprehensive command structure for Task Master integration with Claude Code.
+
+## Command Organization
+
+Commands are organized hierarchically to match Task Master's CLI structure while providing enhanced Claude Code integration.
+
+## Project Setup & Configuration
+
+### `/project:tm/init`
+- `index` - Initialize new project (handles PRD files intelligently)
+- `quick` - Quick setup with auto-confirmation (-y flag)
+
+### `/project:tm/models`
+- `index` - View current AI model configuration
+- `setup` - Interactive model configuration
+- `set-main` - Set primary generation model
+- `set-research` - Set research model
+- `set-fallback` - Set fallback model
+
+## Task Generation
+
+### `/project:tm/parse-prd`
+- `index` - Generate tasks from PRD document
+- `with-research` - Enhanced parsing with research mode
+
+### `/project:tm/generate`
+- Create individual task files from tasks.json
+
+## Task Management
+
+### `/project:tm/list`
+- `index` - Smart listing with natural language filters
+- `with-subtasks` - Include subtasks in hierarchical view
+- `by-status` - Filter by specific status
+
+### `/project:tm/set-status`
+- `to-pending` - Reset task to pending
+- `to-in-progress` - Start working on task
+- `to-done` - Mark task complete
+- `to-review` - Submit for review
+- `to-deferred` - Defer task
+- `to-cancelled` - Cancel task
+
+### `/project:tm/sync-readme`
+- Export tasks to README.md with formatting
+
+### `/project:tm/update`
+- `index` - Update tasks with natural language
+- `from-id` - Update multiple tasks from a starting point
+- `single` - Update specific task
+
+### `/project:tm/add-task`
+- `index` - Add new task with AI assistance
+
+### `/project:tm/remove-task`
+- `index` - Remove task with confirmation
+
+## Subtask Management
+
+### `/project:tm/add-subtask`
+- `index` - Add new subtask to parent
+- `from-task` - Convert existing task to subtask
+
+### `/project:tm/remove-subtask`
+- Remove subtask (with optional conversion)
+
+### `/project:tm/clear-subtasks`
+- `index` - Clear subtasks from specific task
+- `all` - Clear all subtasks globally
+
+## Task Analysis & Breakdown
+
+### `/project:tm/analyze-complexity`
+- Analyze and generate expansion recommendations
+
+### `/project:tm/complexity-report`
+- Display complexity analysis report
+
+### `/project:tm/expand`
+- `index` - Break down specific task
+- `all` - Expand all eligible tasks
+- `with-research` - Enhanced expansion
+
+## Task Navigation
+
+### `/project:tm/next`
+- Intelligent next task recommendation
+
+### `/project:tm/show`
+- Display detailed task information
+
+### `/project:tm/status`
+- Comprehensive project dashboard
+
+## Dependency Management
+
+### `/project:tm/add-dependency`
+- Add task dependency
+
+### `/project:tm/remove-dependency`
+- Remove task dependency
+
+### `/project:tm/validate-dependencies`
+- Check for dependency issues
+
+### `/project:tm/fix-dependencies`
+- Automatically fix dependency problems
+
+## Usage Patterns
+
+### Natural Language
+Most commands accept natural language arguments:
+```
+/project:tm/add-task create user authentication system
+/project:tm/update mark all API tasks as high priority
+/project:tm/list show blocked tasks
+```
+
+### ID-Based Commands
+Commands requiring IDs intelligently parse from $ARGUMENTS:
+```
+/project:tm/show 45
+/project:tm/expand 23
+/project:tm/set-status/to-done 67
+```
+
+### Smart Defaults
+Commands provide intelligent defaults and suggestions based on context.

.claude/commands/tm/tm-main.md

@@ -1,146 +0,0 @@
-# Task Master Command Reference
-
-Comprehensive command structure for Task Master integration with Claude Code.
-
-## Command Organization
-
-Commands are organized hierarchically to match Task Master's CLI structure while providing enhanced Claude Code integration.
-
-## Project Setup & Configuration
-
-### `/project:tm/init`
-- `init-project` - Initialize new project (handles PRD files intelligently)
-- `init-project-quick` - Quick setup with auto-confirmation (-y flag)
-
-### `/project:tm/models`
-- `view-models` - View current AI model configuration
-- `setup-models` - Interactive model configuration
-- `set-main` - Set primary generation model
-- `set-research` - Set research model
-- `set-fallback` - Set fallback model
-
-## Task Generation
-
-### `/project:tm/parse-prd`
-- `parse-prd` - Generate tasks from PRD document
-- `parse-prd-with-research` - Enhanced parsing with research mode
-
-### `/project:tm/generate`
-- `generate-tasks` - Create individual task files from tasks.json
-
-## Task Management
-
-### `/project:tm/list`
-- `list-tasks` - Smart listing with natural language filters
-- `list-tasks-with-subtasks` - Include subtasks in hierarchical view
-- `list-tasks-by-status` - Filter by specific status
-
-### `/project:tm/set-status`
-- `to-pending` - Reset task to pending
-- `to-in-progress` - Start working on task
-- `to-done` - Mark task complete
-- `to-review` - Submit for review
-- `to-deferred` - Defer task
-- `to-cancelled` - Cancel task
-
-### `/project:tm/sync-readme`
-- `sync-readme` - Export tasks to README.md with formatting
-
-### `/project:tm/update`
-- `update-task` - Update tasks with natural language
-- `update-tasks-from-id` - Update multiple tasks from a starting point
-- `update-single-task` - Update specific task
-
-### `/project:tm/add-task`
-- `add-task` - Add new task with AI assistance
-
-### `/project:tm/remove-task`
-- `remove-task` - Remove task with confirmation
-
-## Subtask Management
-
-### `/project:tm/add-subtask`
-- `add-subtask` - Add new subtask to parent
-- `convert-task-to-subtask` - Convert existing task to subtask
-
-### `/project:tm/remove-subtask`
-- `remove-subtask` - Remove subtask (with optional conversion)
-
-### `/project:tm/clear-subtasks`
-- `clear-subtasks` - Clear subtasks from specific task
-- `clear-all-subtasks` - Clear all subtasks globally
-
-## Task Analysis & Breakdown
-
-### `/project:tm/analyze-complexity`
-- `analyze-complexity` - Analyze and generate expansion recommendations
-
-### `/project:tm/complexity-report`
-- `complexity-report` - Display complexity analysis report
-
-### `/project:tm/expand`
-- `expand-task` - Break down specific task
-- `expand-all-tasks` - Expand all eligible tasks
-- `with-research` - Enhanced expansion
-
-## Task Navigation
-
-### `/project:tm/next`
-- `next-task` - Intelligent next task recommendation
-
-### `/project:tm/show`
-- `show-task` - Display detailed task information
-
-### `/project:tm/status`
-- `project-status` - Comprehensive project dashboard
-
-## Dependency Management
-
-### `/project:tm/add-dependency`
-- `add-dependency` - Add task dependency
-
-### `/project:tm/remove-dependency`
-- `remove-dependency` - Remove task dependency
-
-### `/project:tm/validate-dependencies`
-- `validate-dependencies` - Check for dependency issues
-
-### `/project:tm/fix-dependencies`
-- `fix-dependencies` - Automatically fix dependency problems
-
-## Workflows & Automation
-
-### `/project:tm/workflows`
-- `smart-workflow` - Context-aware intelligent workflow execution
-- `command-pipeline` - Chain multiple commands together
-- `auto-implement-tasks` - Advanced auto-implementation with code generation
-
-## Utilities
-
-### `/project:tm/utils`
-- `analyze-project` - Deep project analysis and insights
-
-### `/project:tm/setup`
-- `install-taskmaster` - Comprehensive installation guide
-- `quick-install-taskmaster` - One-line global installation
-
-## Usage Patterns
-
-### Natural Language
-Most commands accept natural language arguments:
-```
-/project:tm/add-task create user authentication system
-/project:tm/update mark all API tasks as high priority
-/project:tm/list show blocked tasks
-```
-
-### ID-Based Commands
-Commands requiring IDs intelligently parse from $ARGUMENTS:
-```
-/project:tm/show 45
-/project:tm/expand 23
-/project:tm/set-status/to-done 67
-```
-
-### Smart Defaults
-Commands provide intelligent defaults and suggestions based on context.

.coderabbit.yaml

@@ -1,10 +0,0 @@
-reviews:
-  profile: assertive
-  poem: false
-  auto_review:
-    base_branches:
-      - rc
-      - beta
-      - alpha
-      - production
-      - next

.cursor/mcp.json

@@ -8,7 +8,6 @@
 				"PERPLEXITY_API_KEY": "PERPLEXITY_API_KEY_HERE",
 				"OPENAI_API_KEY": "OPENAI_API_KEY_HERE",
 				"GOOGLE_API_KEY": "GOOGLE_API_KEY_HERE",
-				"GROQ_API_KEY": "GROQ_API_KEY_HERE",
 				"XAI_API_KEY": "XAI_API_KEY_HERE",
 				"OPENROUTER_API_KEY": "OPENROUTER_API_KEY_HERE",
 				"MISTRAL_API_KEY": "MISTRAL_API_KEY_HERE",

.cursor/rules/commands.mdc

@@ -523,7 +523,7 @@ For AI-powered commands that benefit from project context, follow the research c
     .option('--details <details>', 'Implementation details for the new subtask, optional')
     .option('--dependencies <ids>', 'Comma-separated list of subtask IDs this subtask depends on')
     .option('--status <status>', 'Initial status for the subtask', 'pending')
-    .option('--generate', 'Regenerate task files after adding subtask')
+    .option('--skip-generate', 'Skip regenerating task files')
     .action(async (options) => {
       // Validate required parameters
       if (!options.parent) {
@@ -545,7 +545,7 @@ For AI-powered commands that benefit from project context, follow the research c
     .option('-f, --file <path>', 'Path to the tasks file', 'tasks/tasks.json')
     .option('-i, --id <id>', 'ID of the subtask to remove in format parentId.subtaskId, required')
     .option('-c, --convert', 'Convert the subtask to a standalone task instead of deleting')
-    .option('--generate', 'Regenerate task files after removing subtask')
+    .option('--skip-generate', 'Skip regenerating task files')
     .action(async (options) => {
       // Implementation with detailed error handling
     })
@@ -633,11 +633,11 @@ function showAddSubtaskHelp() {
     '  --dependencies <ids>      Comma-separated list of dependency IDs\n' +
     '  -s, --status <status>     Status for the new subtask (default: "pending")\n' +
     '  -f, --file <file>         Path to the tasks file (default: "tasks/tasks.json")\n' +
-    '  --generate                Regenerate task files after adding subtask\n\n' +
+    '  --skip-generate           Skip regenerating task files\n\n' +
     chalk.cyan('Examples:') + '\n' +
     '  task-master add-subtask --parent=\'5\' --task-id=\'8\'\n' +
     '  task-master add-subtask -p \'5\' -t \'Implement login UI\' -d \'Create the login form\'\n' +
-    '  task-master add-subtask -p \'5\' -t \'Handle API Errors\' --details "Handle 401 Unauthorized.\\nHandle 500 Server Error." --generate',
+    '  task-master add-subtask -p \'5\' -t \'Handle API Errors\' --details $\'Handle 401 Unauthorized.\nHandle 500 Server Error.\'',
     { padding: 1, borderColor: 'blue', borderStyle: 'round' }
   ));
 }
@@ -652,7 +652,7 @@ function showRemoveSubtaskHelp() {
     '  -i, --id <id>       Subtask ID(s) to remove in format "parentId.subtaskId" (can be comma-separated, required)\n' +
     '  -c, --convert       Convert the subtask to a standalone task instead of deleting it\n' +
     '  -f, --file <file>   Path to the tasks file (default: "tasks/tasks.json")\n' +
-    '  --generate          Regenerate task files after removing subtask\n\n' +
+    '  --skip-generate     Skip regenerating task files\n\n' +
     chalk.cyan('Examples:') + '\n' +
     '  task-master remove-subtask --id=\'5.2\'\n' +
     '  task-master remove-subtask --id=\'5.2,6.3,7.1\'\n' +

.cursor/rules/taskmaster.mdc

@@ -158,7 +158,7 @@ This document provides a detailed reference for interacting with Taskmaster, cov
     *   `details`: `Provide implementation notes or details for the new subtask.` (CLI: `--details <text>`)
     *   `dependencies`: `Specify IDs of other tasks or subtasks, e.g., '15' or '16.1', that must be done before this new subtask.` (CLI: `--dependencies <ids>`)
     *   `status`: `Set the initial status for the new subtask. Default is 'pending'.` (CLI: `-s, --status <status>`)
-    *   `generate`: `Enable Taskmaster to regenerate markdown task files after adding the subtask.` (CLI: `--generate`)
+    *   `skipGenerate`: `Prevent Taskmaster from automatically regenerating markdown task files after adding the subtask.` (CLI: `--skip-generate`)
     *   `tag`: `Specify which tag context to operate on. Defaults to the current active tag.` (CLI: `--tag <name>`)
     *   `file`: `Path to your Taskmaster 'tasks.json' file. Default relies on auto-detection.` (CLI: `-f, --file <file>`)
 *   **Usage:** Break down tasks manually or reorganize existing tasks.
@@ -286,7 +286,7 @@ This document provides a detailed reference for interacting with Taskmaster, cov
 *   **Key Parameters/Options:**
     *   `id`: `Required. The ID(s) of the Taskmaster subtask(s) to remove, e.g., '15.2' or '16.1,16.3'.` (CLI: `-i, --id <id>`)
     *   `convert`: `If used, Taskmaster will turn the subtask into a regular top-level task instead of deleting it.` (CLI: `-c, --convert`)
-    *   `generate`: `Enable Taskmaster to regenerate markdown task files after removing the subtask.` (CLI: `--generate`)
+    *   `skipGenerate`: `Prevent Taskmaster from automatically regenerating markdown task files after removing the subtask.` (CLI: `--skip-generate`)
     *   `tag`: `Specify which tag context to operate on. Defaults to the current active tag.` (CLI: `--tag <name>`)
     *   `file`: `Path to your Taskmaster 'tasks.json' file. Default relies on auto-detection.` (CLI: `-f, --file <file>`)
 *   **Usage:** Delete unnecessary subtasks or promote a subtask to a top-level task.

.cursor/rules/test_workflow.mdc

@@ -1,803 +0,0 @@
----
-description: 
-globs: 
-alwaysApply: true
----
-# Test Workflow & Development Process
-
-## **Initial Testing Framework Setup**
-
-Before implementing the TDD workflow, ensure your project has a proper testing framework configured. This section covers setup for different technology stacks.
-
-### **Detecting Project Type & Framework Needs**
-
-**AI Agent Assessment Checklist:**
-1. **Language Detection**: Check for `package.json` (Node.js/JavaScript), `requirements.txt` (Python), `Cargo.toml` (Rust), etc.
-2. **Existing Tests**: Look for test files (`.test.`, `.spec.`, `_test.`) or test directories
-3. **Framework Detection**: Check for existing test runners in dependencies
-4. **Project Structure**: Analyze directory structure for testing patterns
-
-### **JavaScript/Node.js Projects (Jest Setup)**
-
-#### **Prerequisites Check**
-```bash
-# Verify Node.js project
-ls package.json  # Should exist
-
-# Check for existing testing setup
-ls jest.config.js jest.config.ts  # Check for Jest config
-grep -E "(jest|vitest|mocha)" package.json  # Check for test runners
-```
-
-#### **Jest Installation & Configuration**
-
-**Step 1: Install Dependencies**
-```bash
-# Core Jest dependencies
-npm install --save-dev jest
-
-# TypeScript support (if using TypeScript)
-npm install --save-dev ts-jest @types/jest
-
-# Additional useful packages
-npm install --save-dev supertest @types/supertest  # For API testing
-npm install --save-dev jest-watch-typeahead  # Enhanced watch mode
-```
-
-**Step 2: Create Jest Configuration**
-
-Create `jest.config.js` with the following production-ready configuration:
-
-```javascript
-/** @type {import('jest').Config} */
-module.exports = {
-  // Use ts-jest preset for TypeScript support
-  preset: 'ts-jest',
-
-  // Test environment
-  testEnvironment: 'node',
-
-  // Roots for test discovery
-  roots: ['<rootDir>/src', '<rootDir>/tests'],
-
-  // Test file patterns
-  testMatch: ['**/__tests__/**/*.ts', '**/?(*.)+(spec|test).ts'],
-
-  // Transform files
-  transform: {
-    '^.+\\.ts$': [
-      'ts-jest',
-      {
-        tsconfig: {
-          target: 'es2020',
-          module: 'commonjs',
-          esModuleInterop: true,
-          allowSyntheticDefaultImports: true,
-          skipLibCheck: true,
-          strict: false,
-          noImplicitAny: false,
-        },
-      },
-    ],
-    '^.+\\.js$': [
-      'ts-jest',
-      {
-        useESM: false,
-        tsconfig: {
-          target: 'es2020',
-          module: 'commonjs',
-          esModuleInterop: true,
-          allowSyntheticDefaultImports: true,
-          allowJs: true,
-        },
-      },
-    ],
-  },
-
-  // Module file extensions
-  moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node'],
-
-  // Transform ignore patterns - adjust for ES modules
-  transformIgnorePatterns: ['node_modules/(?!(your-es-module-deps|.*\\.mjs$))'],
-
-  // Coverage configuration
-  collectCoverage: true,
-  coverageDirectory: 'coverage',
-  coverageReporters: [
-    'text', // Console output
-    'text-summary', // Brief summary
-    'lcov', // For IDE integration
-    'html', // Detailed HTML report
-  ],
-
-  // Files to collect coverage from
-  collectCoverageFrom: [
-    'src/**/*.ts',
-    '!src/**/*.d.ts',
-    '!src/**/*.test.ts',
-    '!src/**/index.ts', // Often just exports
-    '!src/generated/**', // Generated code
-    '!src/config/database.ts', // Database config (tested via integration)
-  ],
-
-  // Coverage thresholds - TaskMaster standards
-  coverageThreshold: {
-    global: {
-      branches: 70,
-      functions: 80,
-      lines: 80,
-      statements: 80,
-    },
-    // Higher standards for critical business logic
-    './src/utils/': {
-      branches: 85,
-      functions: 90,
-      lines: 90,
-      statements: 90,
-    },
-    './src/middleware/': {
-      branches: 80,
-      functions: 85,
-      lines: 85,
-      statements: 85,
-    },
-  },
-
-  // Setup files
-  setupFilesAfterEnv: ['<rootDir>/tests/setup.ts'],
-
-  // Global teardown to prevent worker process leaks
-  globalTeardown: '<rootDir>/tests/teardown.ts',
-
-  // Module path mapping (if needed)
-  moduleNameMapper: {
-    '^@/(.*)$': '<rootDir>/src/$1',
-  },
-
-  // Clear mocks between tests
-  clearMocks: true,
-
-  // Restore mocks after each test
-  restoreMocks: true,
-
-  // Global test timeout
-  testTimeout: 10000,
-
-  // Projects for different test types
-  projects: [
-    // Unit tests - for pure functions only
-    {
-      displayName: 'unit',
-      testMatch: ['<rootDir>/src/**/*.test.ts'],
-      testPathIgnorePatterns: ['.*\\.integration\\.test\\.ts$', '/tests/'],
-      preset: 'ts-jest',
-      testEnvironment: 'node',
-      collectCoverageFrom: [
-        'src/**/*.ts',
-        '!src/**/*.d.ts',
-        '!src/**/*.test.ts',
-        '!src/**/*.integration.test.ts',
-      ],
-      coverageThreshold: {
-        global: {
-          branches: 70,
-          functions: 80,
-          lines: 80,
-          statements: 80,
-        },
-      },
-    },
-    // Integration tests - real database/services
-    {
-      displayName: 'integration',
-      testMatch: [
-        '<rootDir>/src/**/*.integration.test.ts',
-        '<rootDir>/tests/integration/**/*.test.ts',
-      ],
-      preset: 'ts-jest',
-      testEnvironment: 'node',
-      setupFilesAfterEnv: ['<rootDir>/tests/setup/integration.ts'],
-      testTimeout: 10000,
-    },
-    // E2E tests - full workflows
-    {
-      displayName: 'e2e',
-      testMatch: ['<rootDir>/tests/e2e/**/*.test.ts'],
-      preset: 'ts-jest',
-      testEnvironment: 'node',
-      setupFilesAfterEnv: ['<rootDir>/tests/setup/e2e.ts'],
-      testTimeout: 30000,
-    },
-  ],
-
-  // Verbose output for better debugging
-  verbose: true,
-
-  // Run projects sequentially to avoid conflicts
-  maxWorkers: 1,
-
-  // Enable watch mode plugins
-  watchPlugins: ['jest-watch-typeahead/filename', 'jest-watch-typeahead/testname'],
-};
-```
-
-**Step 3: Update package.json Scripts**
-
-Add these scripts to your `package.json`:
-
-```json
-{
-  "scripts": {
-    "test": "jest",
-    "test:watch": "jest --watch",
-    "test:coverage": "jest --coverage",
-    "test:unit": "jest --selectProjects unit",
-    "test:integration": "jest --selectProjects integration", 
-    "test:e2e": "jest --selectProjects e2e",
-    "test:ci": "jest --ci --coverage --watchAll=false"
-  }
-}
-```
-
-**Step 4: Create Test Setup Files**
-
-Create essential test setup files:
-
-```typescript
-// tests/setup.ts - Global setup
-import { jest } from '@jest/globals';
-
-// Global test configuration
-beforeAll(() => {
-  // Set test timeout
-  jest.setTimeout(10000);
-});
-
-afterEach(() => {
-  // Clean up mocks after each test
-  jest.clearAllMocks();
-});
-```
-
-```typescript
-// tests/setup/integration.ts - Integration test setup
-import { PrismaClient } from '@prisma/client';
-
-const prisma = new PrismaClient();
-
-beforeAll(async () => {
-  // Connect to test database
-  await prisma.$connect();
-});
-
-afterAll(async () => {
-  // Cleanup and disconnect
-  await prisma.$disconnect();
-});
-
-beforeEach(async () => {
-  // Clean test data before each test
-  // Add your cleanup logic here
-});
-```
-
-```typescript
-// tests/teardown.ts - Global teardown
-export default async () => {
-  // Global cleanup after all tests
-  console.log('Global test teardown complete');
-};
-```
-
-**Step 5: Create Initial Test Structure**
-
-```bash
-# Create test directories
-mkdir -p tests/{setup,fixtures,unit,integration,e2e}
-mkdir -p tests/unit/src/{utils,services,middleware}
-
-# Create sample test fixtures
-mkdir tests/fixtures
-```
-
-### **Generic Testing Framework Setup (Any Language)**
-
-#### **Framework Selection Guide**
-
-**Python Projects:**
-- **pytest**: Recommended for most Python projects
-- **unittest**: Built-in, suitable for simple projects
-- **Coverage**: Use `coverage.py` for code coverage
-
-```bash
-# Python setup example
-pip install pytest pytest-cov
-echo "[tool:pytest]" > pytest.ini
-echo "testpaths = tests" >> pytest.ini
-echo "addopts = --cov=src --cov-report=html --cov-report=term" >> pytest.ini
-```
-
-**Go Projects:**
-- **Built-in testing**: Use Go's built-in `testing` package
-- **Coverage**: Built-in with `go test -cover`
-
-```bash
-# Go setup example
-go mod init your-project
-mkdir -p tests
-# Tests are typically *_test.go files alongside source
-```
-
-**Rust Projects:**
-- **Built-in testing**: Use Rust's built-in test framework
-- **cargo-tarpaulin**: For coverage analysis
-
-```bash
-# Rust setup example
-cargo new your-project
-cd your-project
-cargo install cargo-tarpaulin  # For coverage
-```
-
-**Java Projects:**
-- **JUnit 5**: Modern testing framework
-- **Maven/Gradle**: Build tools with testing integration
-
-```xml
-<!-- Maven pom.xml example -->
-<dependency>
-    <groupId>org.junit.jupiter</groupId>
-    <artifactId>junit-jupiter</artifactId>
-    <version>5.9.2</version>
-    <scope>test</scope>
-</dependency>
-```
-
-#### **Universal Testing Principles**
-
-**Coverage Standards (Adapt to Your Language):**
-- **Global Minimum**: 70-80% line coverage
-- **Critical Code**: 85-90% coverage
-- **New Features**: Must meet or exceed standards
-- **Legacy Code**: Gradual improvement strategy
-
-**Test Organization:**
-- **Unit Tests**: Fast, isolated, no external dependencies
-- **Integration Tests**: Test component interactions
-- **E2E Tests**: Test complete user workflows
-- **Performance Tests**: Load and stress testing (if applicable)
-
-**Naming Conventions:**
-- **Test Files**: `*.test.*`, `*_test.*`, or language-specific patterns
-- **Test Functions**: Descriptive names (e.g., `should_return_error_for_invalid_input`)
-- **Test Directories**: Organized by test type and mirroring source structure
-
-#### **TaskMaster Integration for Any Framework**
-
-**Document Testing Setup in Subtasks:**
-```bash
-# Update subtask with testing framework setup
-task-master update-subtask --id=X.Y --prompt="Testing framework setup:
-- Installed [Framework Name] with coverage support
-- Configured [Coverage Tool] with thresholds: 80% lines, 70% branches
-- Created test directory structure: unit/, integration/, e2e/
-- Added test scripts to build configuration
-- All setup tests passing"
-```
-
-**Testing Framework Verification:**
-```bash
-# Verify setup works
-[test-command]  # e.g., npm test, pytest, go test, cargo test
-
-# Check coverage reporting
-[coverage-command]  # e.g., npm run test:coverage
-
-# Update task with verification
-task-master update-subtask --id=X.Y --prompt="Testing framework verified:
-- Sample tests running successfully
-- Coverage reporting functional
-- CI/CD integration ready
-- Ready to begin TDD workflow"
-```
-
-## **Test-Driven Development (TDD) Integration**
-
-### **Core TDD Cycle with Jest**
-```bash
-# 1. Start development with watch mode
-npm run test:watch
-
-# 2. Write failing test first
-# Create test file: src/utils/newFeature.test.ts
-# Write test that describes expected behavior
-
-# 3. Implement minimum code to make test pass
-# 4. Refactor while keeping tests green
-# 5. Add edge cases and error scenarios
-```
-
-### **TDD Workflow Per Subtask**
-```bash
-# When starting a new subtask:
-task-master set-status --id=4.1 --status=in-progress
-
-# Begin TDD cycle:
-npm run test:watch  # Keep running during development
-
-# Document TDD progress in subtask:
-task-master update-subtask --id=4.1 --prompt="TDD Progress:
-- Written 3 failing tests for core functionality
-- Implemented basic feature, tests now passing
-- Adding edge case tests for error handling"
-
-# Complete subtask with test summary:
-task-master update-subtask --id=4.1 --prompt="Implementation complete:
-- Feature implemented with 8 unit tests
-- Coverage: 95% statements, 88% branches  
-- All tests passing, TDD cycle complete"
-```
-
-## **Testing Commands & Usage**
-
-### **Development Commands**
-```bash
-# Primary development command - use during coding
-npm run test:watch              # Watch mode with Jest
-npm run test:watch -- --testNamePattern="auth"  # Watch specific tests
-
-# Targeted testing during development
-npm run test:unit               # Run only unit tests
-npm run test:unit -- --coverage # Unit tests with coverage
-
-# Integration testing when APIs are ready
-npm run test:integration        # Run integration tests
-npm run test:integration -- --detectOpenHandles  # Debug hanging tests
-
-# End-to-end testing for workflows
-npm run test:e2e               # Run E2E tests
-npm run test:e2e -- --timeout=30000  # Extended timeout for E2E
-```
-
-### **Quality Assurance Commands**
-```bash
-# Full test suite with coverage (before commits)
-npm run test:coverage          # Complete coverage analysis
-
-# All tests (CI/CD pipeline)
-npm test                       # Run all test projects
-
-# Specific test file execution
-npm test -- auth.test.ts       # Run specific test file
-npm test -- --testNamePattern="should handle errors"  # Run specific tests
-```
-
-## **Test Implementation Patterns**
-
-### **Unit Test Development**
-```typescript
-// ✅ DO: Follow established patterns from auth.test.ts
-describe('FeatureName', () => {
-  beforeEach(() => {
-    jest.clearAllMocks();
-    // Setup mocks with proper typing
-  });
-
-  describe('functionName', () => {
-    it('should handle normal case', () => {
-      // Test implementation with specific assertions
-    });
-    
-    it('should throw error for invalid input', async () => {
-      // Error scenario testing
-      await expect(functionName(invalidInput))
-        .rejects.toThrow('Specific error message');
-    });
-  });
-});
-```
-
-### **Integration Test Development**  
-```typescript
-// ✅ DO: Use supertest for API endpoint testing
-import request from 'supertest';
-import { app } from '../../src/app';
-
-describe('POST /api/auth/register', () => {
-  beforeEach(async () => {
-    await integrationTestUtils.cleanupTestData();
-  });
-  
-  it('should register user successfully', async () => {
-    const userData = createTestUser();
-    
-    const response = await request(app)
-      .post('/api/auth/register')
-      .send(userData)
-      .expect(201);
-      
-    expect(response.body).toMatchObject({
-      id: expect.any(String),
-      email: userData.email
-    });
-    
-    // Verify database state
-    const user = await prisma.user.findUnique({
-      where: { email: userData.email }
-    });
-    expect(user).toBeTruthy();
-  });
-});
-```
-
-### **E2E Test Development**
-```typescript
-// ✅ DO: Test complete user workflows
-describe('User Authentication Flow', () => {
-  it('should complete registration → login → protected access', async () => {
-    // Step 1: Register
-    const userData = createTestUser();
-    await request(app)
-      .post('/api/auth/register')
-      .send(userData)
-      .expect(201);
-    
-    // Step 2: Login
-    const loginResponse = await request(app)
-      .post('/api/auth/login')
-      .send({ email: userData.email, password: userData.password })
-      .expect(200);
-    
-    const { token } = loginResponse.body;
-    
-    // Step 3: Access protected resource
-    await request(app)
-      .get('/api/profile')
-      .set('Authorization', `Bearer ${token}`)
-      .expect(200);
-  }, 30000); // Extended timeout for E2E
-});
-```
-
-## **Mocking & Test Utilities**
-
-### **Established Mocking Patterns**
-```typescript
-// ✅ DO: Use established bcrypt mocking pattern
-jest.mock('bcrypt');
-import bcrypt from 'bcrypt';
-const mockHash = bcrypt.hash as jest.MockedFunction<typeof bcrypt.hash>;
-const mockCompare = bcrypt.compare as jest.MockedFunction<typeof bcrypt.compare>;
-
-// ✅ DO: Use Prisma mocking for unit tests
-jest.mock('@prisma/client', () => ({
-  PrismaClient: jest.fn().mockImplementation(() => ({
-    user: {
-      create: jest.fn(),
-      findUnique: jest.fn(),
-    },
-    $connect: jest.fn(),
-    $disconnect: jest.fn(),
-  })),
-}));
-```
-
-### **Test Fixtures Usage**
-```typescript
-// ✅ DO: Use centralized test fixtures
-import { createTestUser, adminUser, invalidUser } from '../fixtures/users';
-
-describe('User Service', () => {
-  it('should handle admin user creation', async () => {
-    const userData = createTestUser(adminUser);
-    // Test implementation
-  });
-  
-  it('should reject invalid user data', async () => {
-    const userData = createTestUser(invalidUser);
-    // Error testing
-  });
-});
-```
-
-## **Coverage Standards & Monitoring**
-
-### **Coverage Thresholds**
-- **Global Standards**: 80% lines/functions, 70% branches
-- **Critical Code**: 90% utils, 85% middleware
-- **New Features**: Must meet or exceed global thresholds
-- **Legacy Code**: Gradual improvement with each change
-
-### **Coverage Reporting & Analysis**
-```bash
-# Generate coverage reports
-npm run test:coverage
-
-# View detailed HTML report
-open coverage/lcov-report/index.html
-
-# Coverage files generated:
-# - coverage/lcov-report/index.html  # Detailed HTML report
-# - coverage/lcov.info               # LCOV format for IDE integration  
-# - coverage/coverage-final.json     # JSON format for tooling
-```
-
-### **Coverage Quality Checks**
-```typescript
-// ✅ DO: Test all code paths
-describe('validateInput', () => {
-  it('should return true for valid input', () => {
-    expect(validateInput('valid')).toBe(true);
-  });
-  
-  it('should return false for various invalid inputs', () => {
-    expect(validateInput('')).toBe(false);      // Empty string
-    expect(validateInput(null)).toBe(false);    // Null value
-    expect(validateInput(undefined)).toBe(false); // Undefined
-  });
-  
-  it('should throw for unexpected input types', () => {
-    expect(() => validateInput(123)).toThrow('Invalid input type');
-  });
-});
-```
-
-## **Testing During Development Phases**
-
-### **Feature Development Phase**
-```bash
-# 1. Start feature development
-task-master set-status --id=X.Y --status=in-progress
-
-# 2. Begin TDD cycle  
-npm run test:watch
-
-# 3. Document test progress in subtask
-task-master update-subtask --id=X.Y --prompt="Test development:
-- Created test file with 5 failing tests
-- Implemented core functionality
-- Tests passing, adding error scenarios"
-
-# 4. Verify coverage before completion
-npm run test:coverage
-
-# 5. Update subtask with final test status
-task-master update-subtask --id=X.Y --prompt="Testing complete:
-- 12 unit tests with full coverage
-- All edge cases and error scenarios covered
-- Ready for integration testing"
-```
-
-### **Integration Testing Phase**
-```bash
-# After API endpoints are implemented
-npm run test:integration
-
-# Update integration test templates
-# Replace placeholder tests with real endpoint calls
-
-# Document integration test results
-task-master update-subtask --id=X.Y --prompt="Integration tests:
-- Updated auth endpoint tests  
-- Database integration verified
-- All HTTP status codes and responses tested"
-```
-
-### **Pre-Commit Testing Phase**
-```bash
-# Before committing code
-npm run test:coverage         # Verify all tests pass with coverage
-npm run test:unit            # Quick unit test verification
-npm run test:integration     # Integration test verification (if applicable)
-
-# Commit pattern for test updates
-git add tests/ src/**/*.test.ts
-git commit -m "test(task-X): Add comprehensive tests for Feature Y
-
-- Unit tests with 95% coverage (exceeds 90% threshold)
-- Integration tests for API endpoints
-- Test fixtures for data generation
-- Proper mocking patterns established
-
-Task X: Feature Y - Testing complete"
-```
-
-## **Error Handling & Debugging**
-
-### **Test Debugging Techniques**
-```typescript
-// ✅ DO: Use test utilities for debugging
-import { testUtils } from '../setup';
-
-it('should debug complex operation', () => {
-  testUtils.withConsole(() => {
-    // Console output visible only for this test
-    console.log('Debug info:', complexData);
-    service.complexOperation();
-  });
-});
-
-// ✅ DO: Use proper async debugging
-it('should handle async operations', async () => {
-  const promise = service.asyncOperation();
-  
-  // Test intermediate state
-  expect(service.isProcessing()).toBe(true);
-  
-  const result = await promise;
-  expect(result).toBe('expected');
-  expect(service.isProcessing()).toBe(false);
-});
-```
-
-### **Common Test Issues & Solutions**
-```bash
-# Hanging tests (common with database connections)
-npm run test:integration -- --detectOpenHandles
-
-# Memory leaks in tests
-npm run test:unit -- --logHeapUsage
-
-# Slow tests identification
-npm run test:coverage -- --verbose
-
-# Mock not working properly
-# Check: mock is declared before imports
-# Check: jest.clearAllMocks() in beforeEach
-# Check: TypeScript typing is correct
-```
-
-## **Continuous Integration Integration**
-
-### **CI/CD Pipeline Testing**
-```yaml
-# Example GitHub Actions integration
-- name: Run tests
-  run: |
-    npm ci
-    npm run test:coverage
-    
-- name: Upload coverage reports
-  uses: codecov/codecov-action@v3
-  with:
-    file: ./coverage/lcov.info
-```
-
-### **Pre-commit Hooks**
-```bash
-# Setup pre-commit testing (recommended)
-# In package.json scripts:
-"pre-commit": "npm run test:unit && npm run test:integration"
-
-# Husky integration example:
-npx husky add .husky/pre-commit "npm run test:unit"
-```
-
-## **Test Maintenance & Evolution**
-
-### **Adding Tests for New Features**
-1. **Create test file** alongside source code or in `tests/unit/`
-2. **Follow established patterns** from `src/utils/auth.test.ts`
-3. **Use existing fixtures** from `tests/fixtures/`
-4. **Apply proper mocking** patterns for dependencies
-5. **Meet coverage thresholds** for the module
-
-### **Updating Integration/E2E Tests**
-1. **Update templates** in `tests/integration/` when APIs change
-2. **Modify E2E workflows** in `tests/e2e/` for new user journeys  
-3. **Update test fixtures** for new data requirements
-4. **Maintain database cleanup** utilities
-
-### **Test Performance Optimization**
-- **Parallel execution**: Jest runs tests in parallel by default
-- **Test isolation**: Use proper setup/teardown for independence
-- **Mock optimization**: Mock heavy dependencies appropriately  
-- **Database efficiency**: Use transaction rollbacks where possible
-
----
-
-**Key References:**
-- [Testing Standards](mdc:.cursor/rules/tests.mdc)
-- [Git Workflow](mdc:.cursor/rules/git_workflow.mdc)
-- [Development Workflow](mdc:.cursor/rules/dev_workflow.mdc)
-- [Jest Configuration](mdc:jest.config.js)

.env.example

@@ -4,11 +4,9 @@ PERPLEXITY_API_KEY=YOUR_PERPLEXITY_KEY_HERE
 OPENAI_API_KEY=YOUR_OPENAI_KEY_HERE
 GOOGLE_API_KEY=YOUR_GOOGLE_KEY_HERE
 MISTRAL_API_KEY=YOUR_MISTRAL_KEY_HERE
-GROQ_API_KEY=YOUR_GROQ_KEY_HERE
 OPENROUTER_API_KEY=YOUR_OPENROUTER_KEY_HERE
 XAI_API_KEY=YOUR_XAI_KEY_HERE
 AZURE_OPENAI_API_KEY=YOUR_AZURE_KEY_HERE
-OLLAMA_API_KEY=YOUR_OLLAMA_API_KEY_HERE
 
 # Google Vertex AI Configuration
 VERTEX_PROJECT_ID=your-gcp-project-id

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,45 +0,0 @@
-# What type of PR is this?
-<!-- Check one -->
-
- - [ ] 🐛 Bug fix
- - [ ] ✨ Feature
- - [ ] 🔌 Integration
- - [ ] 📝 Docs
- - [ ] 🧹 Refactor
- - [ ] Other:
-## Description
-<!-- What does this PR do? -->
-
-## Related Issues
-<!-- Link issues: Fixes #123 -->
-
-## How to Test This
-<!-- Quick steps to verify the changes work -->
-```bash
-# Example commands or steps
-```
-
-**Expected result:**
-<!-- What should happen? -->
-
-## Contributor Checklist
-
-- [ ] Created changeset: `npm run changeset`
-- [ ] Tests pass: `npm test`
-- [ ] Format check passes: `npm run format-check` (or `npm run format` to fix)
-- [ ] Addressed CodeRabbit comments (if any)
-- [ ] Linked related issues (if any)
-- [ ] Manually tested the changes
-
-## Changelog Entry
-<!-- One line describing the change for users -->
-<!-- Example: "Added Kiro IDE integration with automatic task status updates" -->
-
----
-
-### For Maintainers
-
-- [ ] PR title follows conventional commits
-- [ ] Target branch correct
-- [ ] Labels added
-- [ ] Milestone assigned (if applicable)

.github/PULL_REQUEST_TEMPLATE/bugfix.md

@@ -1,39 +0,0 @@
-## 🐛 Bug Fix
-
-### 🔍 Bug Description
-<!-- Describe the bug -->
-
-### 🔗 Related Issues
-<!-- Fixes #123 -->
-
-### ✨ Solution
-<!-- How does this PR fix the bug? -->
-
-## How to Test
-
-### Steps that caused the bug:
-1. 
-2. 
-
-**Before fix:** 
-**After fix:** 
-
-### Quick verification:
-```bash
-# Commands to verify the fix
-```
-
-## Contributor Checklist
-- [ ] Created changeset: `npm run changeset`
-- [ ] Tests pass: `npm test`
-- [ ] Format check passes: `npm run format-check`
-- [ ] Addressed CodeRabbit comments
-- [ ] Added unit tests (if applicable)
-- [ ] Manually verified the fix works
-
----
-
-### For Maintainers
-- [ ] Root cause identified
-- [ ] Fix doesn't introduce new issues
-- [ ] CI passes

.github/PULL_REQUEST_TEMPLATE/config.yml

@@ -1,11 +0,0 @@
-blank_issues_enabled: false
-contact_links:
-  - name: 🐛 Bug Fix
-    url: https://github.com/eyaltoledano/claude-task-master/compare/next...HEAD?template=bugfix.md
-    about: Fix a bug in Task Master
-  - name: ✨ New Feature
-    url: https://github.com/eyaltoledano/claude-task-master/compare/next...HEAD?template=feature.md
-    about: Add a new feature to Task Master
-  - name: 🔌 New Integration
-    url: https://github.com/eyaltoledano/claude-task-master/compare/next...HEAD?template=integration.md
-    about: Add support for a new tool, IDE, or platform

.github/PULL_REQUEST_TEMPLATE/feature.md

@@ -1,49 +0,0 @@
-## ✨ New Feature
-
-### 📋 Feature Description
-<!-- Brief description -->
-
-### 🎯 Problem Statement
-<!-- What problem does this feature solve? Why is it needed? -->
-
-### 💡 Solution
-<!-- How does this feature solve the problem? What's the approach? -->
-
-### 🔗 Related Issues
-<!-- Link related issues: Fixes #123, Part of #456 -->
-
-## How to Use It
-
-### Quick Start
-```bash
-# Basic usage example
-```
-
-### Example
-<!-- Show a real use case -->
-```bash
-# Practical example
-```
-
-**What you should see:**
-<!-- Expected behavior -->
-
-## Contributor Checklist
-- [ ] Created changeset: `npm run changeset`
-- [ ] Tests pass: `npm test`
-- [ ] Format check passes: `npm run format-check`
-- [ ] Addressed CodeRabbit comments
-- [ ] Added tests for new functionality
-- [ ] Manually tested in CLI mode
-- [ ] Manually tested in MCP mode (if applicable)
-
-## Changelog Entry
-<!-- One-liner for release notes -->
-
----
-
-### For Maintainers
-
-- [ ] Feature aligns with project vision
-- [ ] CIs pass
-- [ ] Changeset file exists

.github/PULL_REQUEST_TEMPLATE/integration.md

@@ -1,53 +0,0 @@
-# 🔌 New Integration
-
-## What tool/IDE is being integrated?
-
-<!-- Name and brief description -->
-
-## What can users do with it?
-
-<!-- Key benefits -->
-
-## How to Enable
-
-### Setup
-
-```bash
-task-master rules add [name]
-# Any other setup steps
-```
-
-### Example Usage
-
-<!-- Show it in action -->
-
-```bash
-# Real example
-```
-
-### Natural Language Hooks (if applicable)
-
-```
-"When tests pass, mark task as done"
-# Other examples
-```
-
-## Contributor Checklist
-
-- [ ] Created changeset: `npm run changeset`
-- [ ] Tests pass: `npm test`
-- [ ] Format check passes: `npm run format-check`
-- [ ] Addressed CodeRabbit comments
-- [ ] Integration fully tested with target tool/IDE
-- [ ] Error scenarios tested
-- [ ] Added integration tests
-- [ ] Documentation includes setup guide
-- [ ] Examples are working and clear
-
----
-
-## For Maintainers
-
-- [ ] Integration stability verified
-- [ ] Documentation comprehensive
-- [ ] Examples working

.github/scripts/check-pre-release-mode.mjs

@@ -1,102 +0,0 @@
-#!/usr/bin/env node
-import { readFileSync, existsSync } from 'node:fs';
-import { join, dirname, resolve } from 'node:path';
-import { fileURLToPath } from 'node:url';
-
-const __filename = fileURLToPath(import.meta.url);
-const __dirname = dirname(__filename);
-
-// Get context from command line argument or environment
-const context = process.argv[2] || process.env.GITHUB_WORKFLOW || 'manual';
-
-function findRootDir(startDir) {
-	let currentDir = resolve(startDir);
-	while (currentDir !== '/') {
-		if (existsSync(join(currentDir, 'package.json'))) {
-			try {
-				const pkg = JSON.parse(
-					readFileSync(join(currentDir, 'package.json'), 'utf8')
-				);
-				if (pkg.name === 'task-master-ai' || pkg.repository) {
-					return currentDir;
-				}
-			} catch {}
-		}
-		currentDir = dirname(currentDir);
-	}
-	throw new Error('Could not find root directory');
-}
-
-function checkPreReleaseMode() {
-	console.log('🔍 Checking if branch is in pre-release mode...');
-
-	const rootDir = findRootDir(__dirname);
-	const preJsonPath = join(rootDir, '.changeset', 'pre.json');
-
-	// Check if pre.json exists
-	if (!existsSync(preJsonPath)) {
-		console.log('✅ Not in active pre-release mode - safe to proceed');
-		process.exit(0);
-	}
-
-	try {
-		// Read and parse pre.json
-		const preJsonContent = readFileSync(preJsonPath, 'utf8');
-		const preJson = JSON.parse(preJsonContent);
-
-		// Check if we're in active pre-release mode
-		if (preJson.mode === 'pre') {
-			console.error('❌ ERROR: This branch is in active pre-release mode!');
-			console.error('');
-
-			// Provide context-specific error messages
-			if (context === 'Release Check' || context === 'pull_request') {
-				console.error(
-					'Pre-release mode must be exited before merging to main.'
-				);
-				console.error('');
-				console.error(
-					'To fix this, run the following commands in your branch:'
-				);
-				console.error('  npx changeset pre exit');
-				console.error('  git add -u');
-				console.error('  git commit -m "chore: exit pre-release mode"');
-				console.error('  git push');
-				console.error('');
-				console.error('Then update this pull request.');
-			} else if (context === 'Release' || context === 'main') {
-				console.error(
-					'Pre-release mode should only be used on feature branches, not main.'
-				);
-				console.error('');
-				console.error('To fix this, run the following commands locally:');
-				console.error('  npx changeset pre exit');
-				console.error('  git add -u');
-				console.error('  git commit -m "chore: exit pre-release mode"');
-				console.error('  git push origin main');
-				console.error('');
-				console.error('Then re-run this workflow.');
-			} else {
-				console.error('Pre-release mode must be exited before proceeding.');
-				console.error('');
-				console.error('To fix this, run the following commands:');
-				console.error('  npx changeset pre exit');
-				console.error('  git add -u');
-				console.error('  git commit -m "chore: exit pre-release mode"');
-				console.error('  git push');
-			}
-
-			process.exit(1);
-		}
-
-		console.log('✅ Not in active pre-release mode - safe to proceed');
-		process.exit(0);
-	} catch (error) {
-		console.error(`❌ ERROR: Unable to parse .changeset/pre.json – aborting.`);
-		console.error(`Error details: ${error.message}`);
-		process.exit(1);
-	}
-}
-
-// Run the check
-checkPreReleaseMode();

.github/scripts/pre-release.mjs

@@ -1,54 +0,0 @@
-#!/usr/bin/env node
-import { readFileSync, existsSync } from 'node:fs';
-import { join, dirname } from 'node:path';
-import { fileURLToPath } from 'node:url';
-import {
-	findRootDir,
-	runCommand,
-	getPackageVersion,
-	createAndPushTag
-} from './utils.mjs';
-
-const __filename = fileURLToPath(import.meta.url);
-const __dirname = dirname(__filename);
-
-const rootDir = findRootDir(__dirname);
-const extensionPkgPath = join(rootDir, 'apps', 'extension', 'package.json');
-
-console.log('🚀 Starting pre-release process...');
-
-// Check if we're in RC mode
-const preJsonPath = join(rootDir, '.changeset', 'pre.json');
-if (!existsSync(preJsonPath)) {
-	console.error('⚠️  Not in RC mode. Run "npx changeset pre enter rc" first.');
-	process.exit(1);
-}
-
-try {
-	const preJson = JSON.parse(readFileSync(preJsonPath, 'utf8'));
-	if (preJson.tag !== 'rc') {
-		console.error(`⚠️  Not in RC mode. Current tag: ${preJson.tag}`);
-		process.exit(1);
-	}
-} catch (error) {
-	console.error('Failed to read pre.json:', error.message);
-	process.exit(1);
-}
-
-// Get current extension version
-const extensionVersion = getPackageVersion(extensionPkgPath);
-console.log(`Extension version: ${extensionVersion}`);
-
-// Run changeset publish for npm packages
-console.log('📦 Publishing npm packages...');
-runCommand('npx', ['changeset', 'publish']);
-
-// Create tag for extension pre-release if it doesn't exist
-const extensionTag = `extension-rc@${extensionVersion}`;
-const tagCreated = createAndPushTag(extensionTag);
-
-if (tagCreated) {
-	console.log('This will trigger the extension-pre-release workflow...');
-}
-
-console.log('✅ Pre-release process completed!');

.github/scripts/release.mjs

@@ -1,30 +0,0 @@
-#!/usr/bin/env node
-import { existsSync, unlinkSync } from 'node:fs';
-import { join, dirname } from 'node:path';
-import { fileURLToPath } from 'node:url';
-import { findRootDir, runCommand } from './utils.mjs';
-
-const __filename = fileURLToPath(import.meta.url);
-const __dirname = dirname(__filename);
-
-const rootDir = findRootDir(__dirname);
-
-console.log('🚀 Starting release process...');
-
-// Double-check we're not in pre-release mode (safety net)
-const preJsonPath = join(rootDir, '.changeset', 'pre.json');
-if (existsSync(preJsonPath)) {
-	console.log('⚠️  Warning: pre.json still exists. Removing it...');
-	unlinkSync(preJsonPath);
-}
-
-// Check if the extension version has changed and tag it
-// This prevents changeset from trying to publish the private package
-runCommand('node', [join(__dirname, 'tag-extension.mjs')]);
-
-// Run changeset publish for npm packages
-runCommand('npx', ['changeset', 'publish']);
-
-console.log('✅ Release process completed!');
-
-// The extension tag (if created) will trigger the extension-release workflow

.github/scripts/tag-extension.mjs

@@ -1,33 +0,0 @@
-#!/usr/bin/env node
-import assert from 'node:assert/strict';
-import { readFileSync } from 'node:fs';
-import { join, dirname } from 'node:path';
-import { fileURLToPath } from 'node:url';
-import { findRootDir, createAndPushTag } from './utils.mjs';
-
-const __filename = fileURLToPath(import.meta.url);
-const __dirname = dirname(__filename);
-
-const rootDir = findRootDir(__dirname);
-
-// Read the extension's package.json
-const extensionDir = join(rootDir, 'apps', 'extension');
-const pkgPath = join(extensionDir, 'package.json');
-
-let pkg;
-try {
-	const pkgContent = readFileSync(pkgPath, 'utf8');
-	pkg = JSON.parse(pkgContent);
-} catch (error) {
-	console.error('Failed to read package.json:', error.message);
-	process.exit(1);
-}
-
-// Ensure we have required fields
-assert(pkg.name, 'package.json must have a name field');
-assert(pkg.version, 'package.json must have a version field');
-
-const tag = `${pkg.name}@${pkg.version}`;
-
-// Create and push the tag if it doesn't exist
-createAndPushTag(tag);

.github/scripts/utils.mjs

@@ -1,88 +0,0 @@
-#!/usr/bin/env node
-import { spawnSync } from 'node:child_process';
-import { readFileSync } from 'node:fs';
-import { join, dirname, resolve } from 'node:path';
-
-// Find the root directory by looking for package.json with task-master-ai
-export function findRootDir(startDir) {
-	let currentDir = resolve(startDir);
-	while (currentDir !== '/') {
-		const pkgPath = join(currentDir, 'package.json');
-		try {
-			const pkg = JSON.parse(readFileSync(pkgPath, 'utf8'));
-			if (pkg.name === 'task-master-ai' || pkg.repository) {
-				return currentDir;
-			}
-		} catch {}
-		currentDir = dirname(currentDir);
-	}
-	throw new Error('Could not find root directory');
-}
-
-// Run a command with proper error handling
-export function runCommand(command, args = [], options = {}) {
-	console.log(`Running: ${command} ${args.join(' ')}`);
-	const result = spawnSync(command, args, {
-		encoding: 'utf8',
-		stdio: 'inherit',
-		...options
-	});
-
-	if (result.status !== 0) {
-		console.error(`Command failed with exit code ${result.status}`);
-		process.exit(result.status);
-	}
-
-	return result;
-}
-
-// Get package version from a package.json file
-export function getPackageVersion(packagePath) {
-	try {
-		const pkg = JSON.parse(readFileSync(packagePath, 'utf8'));
-		return pkg.version;
-	} catch (error) {
-		console.error(
-			`Failed to read package version from ${packagePath}:`,
-			error.message
-		);
-		process.exit(1);
-	}
-}
-
-// Check if a git tag exists on remote
-export function tagExistsOnRemote(tag, remote = 'origin') {
-	const result = spawnSync('git', ['ls-remote', remote, tag], {
-		encoding: 'utf8'
-	});
-
-	return result.status === 0 && result.stdout.trim() !== '';
-}
-
-// Create and push a git tag if it doesn't exist
-export function createAndPushTag(tag, remote = 'origin') {
-	// Check if tag already exists
-	if (tagExistsOnRemote(tag, remote)) {
-		console.log(`Tag ${tag} already exists on remote, skipping`);
-		return false;
-	}
-
-	console.log(`Creating new tag: ${tag}`);
-
-	// Create the tag locally
-	const tagResult = spawnSync('git', ['tag', tag]);
-	if (tagResult.status !== 0) {
-		console.error('Failed to create tag:', tagResult.error || tagResult.stderr);
-		process.exit(1);
-	}
-
-	// Push the tag to remote
-	const pushResult = spawnSync('git', ['push', remote, tag]);
-	if (pushResult.status !== 0) {
-		console.error('Failed to push tag:', pushResult.error || pushResult.stderr);
-		process.exit(1);
-	}
-
-	console.log(`✅ Successfully created and pushed tag: ${tag}`);
-	return true;
-}

.github/workflows/extension-ci.yml

@@ -1,143 +0,0 @@
-name: Extension CI
-
-on:
-  push:
-    branches:
-      - main
-      - next
-    paths:
-      - 'apps/extension/**'
-      - '.github/workflows/extension-ci.yml'
-  pull_request:
-    branches:
-      - main
-      - next
-    paths:
-      - 'apps/extension/**'
-      - '.github/workflows/extension-ci.yml'
-
-permissions:
-  contents: read
-
-jobs:
-  setup:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 20
-
-      - name: Cache node_modules
-        uses: actions/cache@v4
-        with:
-          path: |
-            node_modules
-            */*/node_modules
-          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
-          restore-keys: |
-            ${{ runner.os }}-node-
-
-      - name: Install Extension Dependencies
-        working-directory: apps/extension
-        run: npm ci
-        timeout-minutes: 5
-
-  typecheck:
-    needs: setup
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 20
-
-
-      - name: Restore node_modules
-        uses: actions/cache@v4
-        with:
-          path: |
-            node_modules
-            */*/node_modules
-          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
-          restore-keys: |
-            ${{ runner.os }}-node-
-
-      - name: Install if cache miss
-        working-directory: apps/extension
-        run: npm ci
-        timeout-minutes: 3
-
-      - name: Type Check Extension
-        working-directory: apps/extension
-        run: npm run check-types
-        env:
-          FORCE_COLOR: 1
-
-  build:
-    needs: setup
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 20
-
-
-      - name: Restore node_modules
-        uses: actions/cache@v4
-        with:
-          path: |
-            node_modules
-            */*/node_modules
-          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
-          restore-keys: |
-            ${{ runner.os }}-node-
-
-      - name: Install if cache miss
-        working-directory: apps/extension
-        run: npm ci
-        timeout-minutes: 3
-
-      - name: Build Extension
-        working-directory: apps/extension
-        run: npm run build
-        env:
-          FORCE_COLOR: 1
-
-      - name: Package Extension
-        working-directory: apps/extension
-        run: npm run package
-        env:
-          FORCE_COLOR: 1
-
-      - name: Verify Package Contents
-        working-directory: apps/extension
-        run: |
-          echo "Checking vsix-build contents..."
-          ls -la vsix-build/
-          echo "Checking dist contents..."
-          ls -la vsix-build/dist/
-          echo "Checking package.json exists..."
-          test -f vsix-build/package.json
-
-      - name: Create VSIX Package (Test)
-        working-directory: apps/extension/vsix-build
-        run: npx vsce package --no-dependencies
-        env:
-          FORCE_COLOR: 1
-
-      - name: Upload Extension Artifact
-        uses: actions/upload-artifact@v4
-        with:
-          name: extension-package
-          path: |
-            apps/extension/vsix-build/*.vsix
-            apps/extension/dist/
-          retention-days: 30
-