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/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

@@ -0,0 +1,23 @@
+{
+  "mode": "exit",
+  "tag": "rc",
+  "initialVersions": {
+    "task-master-ai": "0.17.1"
+  },
+  "changesets": [
+    "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/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/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/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

.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/release.sh

@@ -1,21 +0,0 @@
-#!/bin/bash
-set -e
-
-echo "🚀 Starting release process..."
-
-# Double-check we're not in pre-release mode (safety net)
-if [ -f .changeset/pre.json ]; then
-  echo "⚠️  Warning: pre.json still exists. Removing it..."
-  rm -f .changeset/pre.json
-fi
-
-# Check if the extension version has changed and tag it
-# This prevents changeset from trying to publish the private package
-node .github/scripts/tag-extension.mjs
-
-# Run changeset publish for npm packages
-npx changeset publish
-
-echo "✅ Release process completed!"
-
-# The extension tag (if created) will trigger the extension-release workflow

.github/scripts/tag-extension.mjs

@@ -1,99 +0,0 @@
-#!/usr/bin/env node
-import assert from 'node:assert/strict';
-import { spawnSync } from 'node:child_process';
-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);
-
-// Find the root directory by looking for package.json
-function findRootDir(startDir) {
-	let currentDir = resolve(startDir);
-	while (currentDir !== '/') {
-		if (existsSync(join(currentDir, 'package.json'))) {
-			// Verify it's the root package.json by checking for expected fields
-			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');
-}
-
-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);
-}
-
-// Read root package.json for repository info
-const rootPkgPath = join(rootDir, 'package.json');
-let rootPkg;
-try {
-	const rootPkgContent = readFileSync(rootPkgPath, 'utf8');
-	rootPkg = JSON.parse(rootPkgContent);
-} catch (error) {
-	console.error('Failed to read root 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');
-assert(rootPkg.repository, 'root package.json must have a repository field');
-
-const tag = `${pkg.name}@${pkg.version}`;
-
-// Get repository URL from root package.json
-const repoUrl = rootPkg.repository.url;
-
-const { status, stdout, error } = spawnSync('git', ['ls-remote', repoUrl, tag]);
-
-assert.equal(status, 0, error);
-
-const exists = String(stdout).trim() !== '';
-
-if (!exists) {
-	console.log(`Creating new extension tag: ${tag}`);
-
-	// Create the tag
-	const tagResult = spawnSync('git', ['tag', tag]);
-	if (tagResult.status !== 0) {
-		console.error(
-			'Failed to create tag:',
-			tagResult.error || tagResult.stderr.toString()
-		);
-		process.exit(1);
-	}
-
-	// Push the tag
-	const pushResult = spawnSync('git', ['push', 'origin', tag]);
-	if (pushResult.status !== 0) {
-		console.error(
-			'Failed to push tag:',
-			pushResult.error || pushResult.stderr.toString()
-		);
-		process.exit(1);
-	}
-
-	console.log(`✅ Successfully created and pushed tag: ${tag}`);
-} else {
-	console.log(`Extension tag already exists: ${tag}`);
-}

.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
-

.github/workflows/extension-release.yml

@@ -1,137 +0,0 @@
-name: Extension Release
-
-on:
-  push:
-    tags:
-      - "extension@*"
-
-permissions:
-  contents: write
-
-concurrency: extension-release-${{ github.ref }}
-
-jobs:
-  publish-extension:
-    runs-on: ubuntu-latest
-    environment: extension-release
-    steps:
-      - uses: actions/checkout@v4
-
-      - 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
-
-      - name: Type Check Extension
-        working-directory: apps/extension
-        run: npm run check-types
-        env:
-          FORCE_COLOR: 1
-
-      - 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: Create VSIX Package
-        working-directory: apps/extension/vsix-build
-        run: npx vsce package --no-dependencies
-        env:
-          FORCE_COLOR: 1
-
-      - name: Get VSIX filename
-        id: vsix-info
-        working-directory: apps/extension/vsix-build
-        run: |
-          VSIX_FILE=$(find . -maxdepth 1 -name "*.vsix" -type f | head -n1 | xargs basename)
-          if [ -z "$VSIX_FILE" ]; then
-            echo "Error: No VSIX file found"
-            exit 1
-          fi
-          echo "vsix-filename=$VSIX_FILE" >> "$GITHUB_OUTPUT"
-          echo "Found VSIX: $VSIX_FILE"
-
-      - name: Publish to VS Code Marketplace
-        working-directory: apps/extension/vsix-build
-        run: npx vsce publish --packagePath "${{ steps.vsix-info.outputs.vsix-filename }}"
-        env:
-          VSCE_PAT: ${{ secrets.VSCE_PAT }}
-          FORCE_COLOR: 1
-
-      - name: Install Open VSX CLI
-        run: npm install -g ovsx
-
-      - name: Publish to Open VSX Registry
-        working-directory: apps/extension/vsix-build
-        run: ovsx publish "${{ steps.vsix-info.outputs.vsix-filename }}"
-        env:
-          OVSX_PAT: ${{ secrets.OVSX_PAT }}
-          FORCE_COLOR: 1
-
-      - name: Create GitHub Release
-        uses: actions/create-release@v1
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        with:
-          tag_name: ${{ github.ref_name }}
-          release_name: Extension ${{ github.ref_name }}
-          body: |
-            VS Code Extension Release ${{ github.ref_name }}
-            
-            **Marketplaces:**
-            - [VS Code Marketplace](https://marketplace.visualstudio.com/items?itemName=Hamster.task-master-hamster)
-            - [Open VSX Registry](https://open-vsx.org/extension/Hamster/task-master-hamster)
-          draft: false
-          prerelease: false
-
-      - name: Upload VSIX to Release
-        uses: actions/upload-release-asset@v1
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        with:
-          upload_url: ${{ steps.create_release.outputs.upload_url }}
-          asset_path: apps/extension/vsix-build/${{ steps.vsix-info.outputs.vsix-filename }}
-          asset_name: ${{ steps.vsix-info.outputs.vsix-filename }}
-          asset_content_type: application/zip
-
-      - name: Upload Build Artifacts
-        uses: actions/upload-artifact@v4
-        with:
-          name: extension-release-${{ github.ref_name }}
-          path: |
-            apps/extension/vsix-build/*.vsix
-            apps/extension/dist/
-          retention-days: 90
-
-  notify-success:
-    needs: publish-extension
-    if: success()
-    runs-on: ubuntu-latest
-    steps:
-      - name: Success Notification
-        run: |
-          echo "🎉 Extension ${{ github.ref_name }} successfully published!"
-          echo "📦 Available on VS Code Marketplace"
-          echo "🌍 Available on Open VSX Registry"
-          echo "🏷️ GitHub release created: ${{ github.ref_name }}"

.github/workflows/pre-release.yml

@@ -16,7 +16,7 @@ jobs:
       - uses: actions/setup-node@v4
         with:
           node-version: 20
-          cache: "npm"
+          cache: 'npm'
 
       - name: Cache node_modules
         uses: actions/cache@v4
@@ -32,13 +32,10 @@ jobs:
         run: npm ci
         timeout-minutes: 2
 
-      - name: Enter RC mode (if not already in RC mode)
+      - name: Enter RC mode
         run: |
-          # ensure we’re in the right pre-mode (tag "rc")
-          if [ ! -f .changeset/pre.json ] \
-            || [ "$(jq -r '.tag' .changeset/pre.json 2>/dev/null || echo '')" != "rc" ]; then
-            npx changeset pre enter rc
-          fi
+          npx changeset pre exit || true
+          npx changeset pre enter rc
 
       - name: Version RC packages
         run: npx changeset version
@@ -54,9 +51,12 @@ jobs:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
 
+      - name: Exit RC mode
+        run: npx changeset pre exit
+
       - name: Commit & Push changes
         uses: actions-js/push@master
         with:
           github_token: ${{ secrets.GITHUB_TOKEN }}
           branch: ${{ github.ref }}
-          message: "chore: rc version bump"
+          message: 'chore: rc version bump'

.github/workflows/release.yml

@@ -6,11 +6,6 @@ on:
 
 concurrency: ${{ github.workflow }}-${{ github.ref }}
 
-permissions:
-  contents: write
-  pull-requests: write
-  id-token: write
-
 jobs:
   release:
     runs-on: ubuntu-latest
@@ -38,31 +33,13 @@ jobs:
         run: npm ci
         timeout-minutes: 2
 
-      - name: Exit pre-release mode and clean up
-        run: |
-          echo "🔄 Ensuring we're not in pre-release mode for main branch..."
-          
-          # Exit pre-release mode if we're in it
-          npx changeset pre exit || echo "Not in pre-release mode"
-          
-          # Remove pre.json file if it exists (belt and suspenders approach)
-          if [ -f .changeset/pre.json ]; then
-            echo "🧹 Removing pre.json file..."
-            rm -f .changeset/pre.json
-          fi
-          
-          # Verify the file is gone
-          if [ ! -f .changeset/pre.json ]; then
-            echo "✅ pre.json successfully removed"
-          else
-            echo "❌ Failed to remove pre.json"
-            exit 1
-          fi
+      - name: Exit pre-release mode (safety check)
+        run: npx changeset pre exit || true
 
       - name: Create Release Pull Request or Publish to npm
         uses: changesets/action@v1
         with:
-          publish: ./.github/scripts/release.sh
+          publish: npm run release
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

.gitignore

@@ -87,10 +87,3 @@ dev-debug.log
 *.njsproj
 *.sln
 *.sw?
-
-# VS Code extension test files
-.vscode-test/
-apps/extension/.vscode-test/
-
-# apps/extension
-apps/extension/vsix-build/

.kiro/hooks/tm-code-change-task-tracker.kiro.hook

@@ -1,23 +0,0 @@
-{
-  "enabled": true,
-  "name": "[TM] Code Change Task Tracker",
-  "description": "Track implementation progress by monitoring code changes",
-  "version": "1",
-  "when": {
-    "type": "fileEdited",
-    "patterns": [
-      "**/*.{js,ts,jsx,tsx,py,go,rs,java,cpp,c,h,hpp,cs,rb,php,swift,kt,scala,clj}",
-      "!**/node_modules/**",
-      "!**/vendor/**",
-      "!**/.git/**",
-      "!**/build/**",
-      "!**/dist/**",
-      "!**/target/**",
-      "!**/__pycache__/**"
-    ]
-  },
-  "then": {
-    "type": "askAgent",
-    "prompt": "I just saved a source code file. Please:\n\n1. Check what task is currently 'in-progress' using 'tm list --status=in-progress'\n2. Look at the file I saved and summarize what was changed (considering the programming language and context)\n3. Update the task's notes with: 'tm update-subtask --id=<task_id> --prompt=\"Implemented: <summary_of_changes> in <file_path>\"'\n4. If the changes seem to complete the task based on its description, ask if I want to mark it as done"
-  }
-}

.kiro/hooks/tm-complexity-analyzer.kiro.hook

@@ -1,16 +0,0 @@
-{
-  "enabled": false,
-  "name": "[TM] Complexity Analyzer",
-  "description": "Analyze task complexity when new tasks are added",
-  "version": "1",
-  "when": {
-    "type": "fileEdited",
-    "patterns": [
-      ".taskmaster/tasks/tasks.json"
-    ]
-  },
-  "then": {
-    "type": "askAgent",
-    "prompt": "New tasks were added to tasks.json. For each new task:\n\n1. Run 'tm analyze-complexity --id=<task_id>'\n2. If complexity score is > 7, automatically expand it: 'tm expand --id=<task_id> --num=5'\n3. Show the complexity analysis results\n4. Suggest task dependencies based on the expanded subtasks"
-  }
-}

.kiro/hooks/tm-daily-standup-assistant.kiro.hook

@@ -1,13 +0,0 @@
-{
-  "enabled": true,
-  "name": "[TM] Daily Standup Assistant",
-  "description": "Morning workflow summary and task selection",
-  "version": "1",
-  "when": {
-    "type": "userTriggered"
-  },
-  "then": {
-    "type": "askAgent",
-    "prompt": "Good morning! Please provide my daily standup summary:\n\n1. Run 'tm list --status=done' and show tasks completed in the last 24 hours\n2. Run 'tm list --status=in-progress' to show current work\n3. Run 'tm next' to suggest the highest priority task to start\n4. Show the dependency graph for upcoming work\n5. Ask which task I'd like to focus on today"
-  }
-}

.kiro/hooks/tm-git-commit-task-linker.kiro.hook

@@ -1,13 +0,0 @@
-{
-  "enabled": true,
-  "name": "[TM] Git Commit Task Linker",
-  "description": "Link commits to tasks for traceability",
-  "version": "1",
-  "when": {
-    "type": "manual"
-  },
-  "then": {
-    "type": "askAgent",
-    "prompt": "I'm about to commit code. Please:\n\n1. Run 'git diff --staged' to see what's being committed\n2. Analyze the changes and suggest which tasks they relate to\n3. Generate a commit message in format: 'feat(task-<id>): <description>'\n4. Update the relevant tasks with a note about this commit\n5. Show the proposed commit message for approval"
-  }
-}

.kiro/hooks/tm-pr-readiness-checker.kiro.hook

@@ -1,13 +0,0 @@
-{
-  "enabled": true,
-  "name": "[TM] PR Readiness Checker",
-  "description": "Validate tasks before creating a pull request",
-  "version": "1",
-  "when": {
-    "type": "manual"
-  },
-  "then": {
-    "type": "askAgent",
-    "prompt": "I'm about to create a PR. Please:\n\n1. List all tasks marked as 'done' in this branch\n2. For each done task, verify:\n   - All subtasks are also done\n   - Test files exist for new functionality\n   - No TODO comments remain related to the task\n3. Generate a PR description listing completed tasks\n4. Suggest a PR title based on the main tasks completed"
-  }
-}

.kiro/hooks/tm-task-dependency-auto-progression.kiro.hook

@@ -1,17 +0,0 @@
-{
-  "enabled": true,
-  "name": "[TM] Task Dependency Auto-Progression",
-  "description": "Automatically progress tasks when dependencies are completed",
-  "version": "1",
-  "when": {
-    "type": "fileEdited",
-    "patterns": [
-      ".taskmaster/tasks/tasks.json",
-      ".taskmaster/tasks/*.json"
-    ]
-  },
-  "then": {
-    "type": "askAgent",
-    "prompt": "Check the tasks.json file for any tasks that just changed status to 'done'. For each completed task:\n\n1. Find all tasks that depend on it\n2. Check if those dependent tasks now have all their dependencies satisfied\n3. If a task has all dependencies met and is still 'pending', use the command 'tm set-status --id=<task_id> --status=in-progress' to start it\n4. Show me which tasks were auto-started and why"
-  }
-}

.kiro/hooks/tm-test-success-task-completer.kiro.hook

@@ -1,23 +0,0 @@
-{
-  "enabled": true,
-  "name": "[TM] Test Success Task Completer",
-  "description": "Mark tasks as done when their tests pass",
-  "version": "1",
-  "when": {
-    "type": "fileEdited",
-    "patterns": [
-      "**/*test*.{js,ts,jsx,tsx,py,go,java,rb,php,rs,cpp,cs}",
-      "**/*spec*.{js,ts,jsx,tsx,rb}",
-      "**/test_*.py",
-      "**/*_test.go",
-      "**/*Test.java",
-      "**/*Tests.cs",
-      "!**/node_modules/**",
-      "!**/vendor/**"
-    ]
-  },
-  "then": {
-    "type": "askAgent",
-    "prompt": "A test file was just saved. Please:\n\n1. Identify the test framework/language and run the appropriate test command for this file (npm test, pytest, go test, cargo test, dotnet test, mvn test, etc.)\n2. If all tests pass, check which tasks mention this functionality\n3. For any matching tasks that are 'in-progress', ask if the passing tests mean the task is complete\n4. If confirmed, mark the task as done with 'tm set-status --id=<task_id> --status=done'"
-  }
-}

.kiro/settings/mcp.json

@@ -1,19 +0,0 @@
-{
-	"mcpServers": {
-		"task-master-ai": {
-			"command": "npx",
-			"args": ["-y", "--package=task-master-ai", "task-master-ai"],
-			"env": {
-				"ANTHROPIC_API_KEY": "YOUR_ANTHROPIC_API_KEY_HERE",
-				"PERPLEXITY_API_KEY": "YOUR_PERPLEXITY_API_KEY_HERE",
-				"OPENAI_API_KEY": "YOUR_OPENAI_KEY_HERE",
-				"GOOGLE_API_KEY": "YOUR_GOOGLE_KEY_HERE",
-				"XAI_API_KEY": "YOUR_XAI_KEY_HERE",
-				"OPENROUTER_API_KEY": "YOUR_OPENROUTER_KEY_HERE",
-				"MISTRAL_API_KEY": "YOUR_MISTRAL_KEY_HERE",
-				"AZURE_OPENAI_API_KEY": "YOUR_AZURE_KEY_HERE",
-				"OLLAMA_API_KEY": "YOUR_OLLAMA_API_KEY_HERE"
-			}
-		}
-	}
-}

.kiro/steering/dev_workflow.md

@@ -1,422 +0,0 @@
----
-inclusion: always
----
-
-# Taskmaster Development Workflow
-
-This guide outlines the standard process for using Taskmaster to manage software development projects. It is written as a set of instructions for you, the AI agent.
-
-- **Your Default Stance**: For most projects, the user can work directly within the `master` task context. Your initial actions should operate on this default context unless a clear pattern for multi-context work emerges.
-- **Your Goal**: Your role is to elevate the user's workflow by intelligently introducing advanced features like **Tagged Task Lists** when you detect the appropriate context. Do not force tags on the user; suggest them as a helpful solution to a specific need.
-
-## The Basic Loop
-The fundamental development cycle you will facilitate is:
-1.  **`list`**: Show the user what needs to be done.
-2.  **`next`**: Help the user decide what to work on.
-3.  **`show <id>`**: Provide details for a specific task.
-4.  **`expand <id>`**: Break down a complex task into smaller, manageable subtasks.
-5.  **Implement**: The user writes the code and tests.
-6.  **`update-subtask`**: Log progress and findings on behalf of the user.
-7.  **`set-status`**: Mark tasks and subtasks as `done` as work is completed.
-8.  **Repeat**.
-
-All your standard command executions should operate on the user's current task context, which defaults to `master`.
-
----
-
-## Standard Development Workflow Process
-
-### Simple Workflow (Default Starting Point)
-
-For new projects or when users are getting started, operate within the `master` tag context:
-
--   Start new projects by running `initialize_project` tool / `task-master init` or `parse_prd` / `task-master parse-prd --input='<prd-file.txt>'` (see @`taskmaster.md`) to generate initial tasks.json with tagged structure
--   Configure rule sets during initialization with `--rules` flag (e.g., `task-master init --rules kiro,windsurf`) or manage them later with `task-master rules add/remove` commands  
--   Begin coding sessions with `get_tasks` / `task-master list` (see @`taskmaster.md`) to see current tasks, status, and IDs
--   Determine the next task to work on using `next_task` / `task-master next` (see @`taskmaster.md`)
--   Analyze task complexity with `analyze_project_complexity` / `task-master analyze-complexity --research` (see @`taskmaster.md`) before breaking down tasks
--   Review complexity report using `complexity_report` / `task-master complexity-report` (see @`taskmaster.md`)
--   Select tasks based on dependencies (all marked 'done'), priority level, and ID order
--   View specific task details using `get_task` / `task-master show <id>` (see @`taskmaster.md`) to understand implementation requirements
--   Break down complex tasks using `expand_task` / `task-master expand --id=<id> --force --research` (see @`taskmaster.md`) with appropriate flags like `--force` (to replace existing subtasks) and `--research`
--   Implement code following task details, dependencies, and project standards
--   Mark completed tasks with `set_task_status` / `task-master set-status --id=<id> --status=done` (see @`taskmaster.md`)
--   Update dependent tasks when implementation differs from original plan using `update` / `task-master update --from=<id> --prompt="..."` or `update_task` / `task-master update-task --id=<id> --prompt="..."` (see @`taskmaster.md`)
-
----
-
-## Leveling Up: Agent-Led Multi-Context Workflows
-
-While the basic workflow is powerful, your primary opportunity to add value is by identifying when to introduce **Tagged Task Lists**. These patterns are your tools for creating a more organized and efficient development environment for the user, especially if you detect agentic or parallel development happening across the same session.
-
-**Critical Principle**: Most users should never see a difference in their experience. Only introduce advanced workflows when you detect clear indicators that the project has evolved beyond simple task management.
-
-### When to Introduce Tags: Your Decision Patterns
-
-Here are the patterns to look for. When you detect one, you should propose the corresponding workflow to the user.
-
-#### Pattern 1: Simple Git Feature Branching
-This is the most common and direct use case for tags.
-
-- **Trigger**: The user creates a new git branch (e.g., `git checkout -b feature/user-auth`).
-- **Your Action**: Propose creating a new tag that mirrors the branch name to isolate the feature's tasks from `master`.
-- **Your Suggested Prompt**: *"I see you've created a new branch named 'feature/user-auth'. To keep all related tasks neatly organized and separate from your main list, I can create a corresponding task tag for you. This helps prevent merge conflicts in your `tasks.json` file later. Shall I create the 'feature-user-auth' tag?"*
-- **Tool to Use**: `task-master add-tag --from-branch`
-
-#### Pattern 2: Team Collaboration
-- **Trigger**: The user mentions working with teammates (e.g., "My teammate Alice is handling the database schema," or "I need to review Bob's work on the API.").
-- **Your Action**: Suggest creating a separate tag for the user's work to prevent conflicts with shared master context.
-- **Your Suggested Prompt**: *"Since you're working with Alice, I can create a separate task context for your work to avoid conflicts. This way, Alice can continue working with the master list while you have your own isolated context. When you're ready to merge your work, we can coordinate the tasks back to master. Shall I create a tag for your current work?"*
-- **Tool to Use**: `task-master add-tag my-work --copy-from-current --description="My tasks while collaborating with Alice"`
-
-#### Pattern 3: Experiments or Risky Refactors
-- **Trigger**: The user wants to try something that might not be kept (e.g., "I want to experiment with switching our state management library," or "Let's refactor the old API module, but I want to keep the current tasks as a reference.").
-- **Your Action**: Propose creating a sandboxed tag for the experimental work.
-- **Your Suggested Prompt**: *"This sounds like a great experiment. To keep these new tasks separate from our main plan, I can create a temporary 'experiment-zustand' tag for this work. If we decide not to proceed, we can simply delete the tag without affecting the main task list. Sound good?"*
-- **Tool to Use**: `task-master add-tag experiment-zustand --description="Exploring Zustand migration"`
-
-#### Pattern 4: Large Feature Initiatives (PRD-Driven)
-This is a more structured approach for significant new features or epics.
-
-- **Trigger**: The user describes a large, multi-step feature that would benefit from a formal plan.
-- **Your Action**: Propose a comprehensive, PRD-driven workflow.
-- **Your Suggested Prompt**: *"This sounds like a significant new feature. To manage this effectively, I suggest we create a dedicated task context for it. Here's the plan: I'll create a new tag called 'feature-xyz', then we can draft a Product Requirements Document (PRD) together to scope the work. Once the PRD is ready, I'll automatically generate all the necessary tasks within that new tag. How does that sound?"*
-- **Your Implementation Flow**:
-    1.  **Create an empty tag**: `task-master add-tag feature-xyz --description "Tasks for the new XYZ feature"`. You can also start by creating a git branch if applicable, and then create the tag from that branch.
-    2.  **Collaborate & Create PRD**: Work with the user to create a detailed PRD file (e.g., `.taskmaster/docs/feature-xyz-prd.txt`).
-    3.  **Parse PRD into the new tag**: `task-master parse-prd .taskmaster/docs/feature-xyz-prd.txt --tag feature-xyz`
-    4.  **Prepare the new task list**: Follow up by suggesting `analyze-complexity` and `expand-all` for the newly created tasks within the `feature-xyz` tag.
-
-#### Pattern 5: Version-Based Development
-Tailor your approach based on the project maturity indicated by tag names.
-
-- **Prototype/MVP Tags** (`prototype`, `mvp`, `poc`, `v0.x`):
-  - **Your Approach**: Focus on speed and functionality over perfection
-  - **Task Generation**: Create tasks that emphasize "get it working" over "get it perfect"
-  - **Complexity Level**: Lower complexity, fewer subtasks, more direct implementation paths
-  - **Research Prompts**: Include context like "This is a prototype - prioritize speed and basic functionality over optimization"
-  - **Example Prompt Addition**: *"Since this is for the MVP, I'll focus on tasks that get core functionality working quickly rather than over-engineering."*
-
-- **Production/Mature Tags** (`v1.0+`, `production`, `stable`):
-  - **Your Approach**: Emphasize robustness, testing, and maintainability
-  - **Task Generation**: Include comprehensive error handling, testing, documentation, and optimization
-  - **Complexity Level**: Higher complexity, more detailed subtasks, thorough implementation paths
-  - **Research Prompts**: Include context like "This is for production - prioritize reliability, performance, and maintainability"
-  - **Example Prompt Addition**: *"Since this is for production, I'll ensure tasks include proper error handling, testing, and documentation."*
-
-### Advanced Workflow (Tag-Based & PRD-Driven)
-
-**When to Transition**: Recognize when the project has evolved (or has initiated a project which existing code) beyond simple task management. Look for these indicators:
-- User mentions teammates or collaboration needs
-- Project has grown to 15+ tasks with mixed priorities
-- User creates feature branches or mentions major initiatives
-- User initializes Taskmaster on an existing, complex codebase
-- User describes large features that would benefit from dedicated planning
-
-**Your Role in Transition**: Guide the user to a more sophisticated workflow that leverages tags for organization and PRDs for comprehensive planning.
-
-#### Master List Strategy (High-Value Focus)
-Once you transition to tag-based workflows, the `master` tag should ideally contain only:
-- **High-level deliverables** that provide significant business value
-- **Major milestones** and epic-level features
-- **Critical infrastructure** work that affects the entire project
-- **Release-blocking** items
-
-**What NOT to put in master**:
-- Detailed implementation subtasks (these go in feature-specific tags' parent tasks)
-- Refactoring work (create dedicated tags like `refactor-auth`)
-- Experimental features (use `experiment-*` tags)
-- Team member-specific tasks (use person-specific tags)
-
-#### PRD-Driven Feature Development
-
-**For New Major Features**:
-1. **Identify the Initiative**: When user describes a significant feature
-2. **Create Dedicated Tag**: `add_tag feature-[name] --description="[Feature description]"`
-3. **Collaborative PRD Creation**: Work with user to create comprehensive PRD in `.taskmaster/docs/feature-[name]-prd.txt`
-4. **Parse & Prepare**: 
-   - `parse_prd .taskmaster/docs/feature-[name]-prd.txt --tag=feature-[name]`
-   - `analyze_project_complexity --tag=feature-[name] --research`
-   - `expand_all --tag=feature-[name] --research`
-5. **Add Master Reference**: Create a high-level task in `master` that references the feature tag
-
-**For Existing Codebase Analysis**:
-When users initialize Taskmaster on existing projects:
-1. **Codebase Discovery**: Use your native tools for producing deep context about the code base. You may use `research` tool with `--tree` and `--files` to collect up to date information using the existing architecture as context.
-2. **Collaborative Assessment**: Work with user to identify improvement areas, technical debt, or new features
-3. **Strategic PRD Creation**: Co-author PRDs that include:
-   - Current state analysis (based on your codebase research)
-   - Proposed improvements or new features
-   - Implementation strategy considering existing code
-4. **Tag-Based Organization**: Parse PRDs into appropriate tags (`refactor-api`, `feature-dashboard`, `tech-debt`, etc.)
-5. **Master List Curation**: Keep only the most valuable initiatives in master
-
-The parse-prd's `--append` flag enables the user to parse multiple PRDs within tags or across tags. PRDs should be focused and the number of tasks they are parsed into should be strategically chosen relative to the PRD's complexity and level of detail.
-
-### Workflow Transition Examples
-
-**Example 1: Simple → Team-Based**
-```
-User: "Alice is going to help with the API work"
-Your Response: "Great! To avoid conflicts, I'll create a separate task context for your work. Alice can continue with the master list while you work in your own context. When you're ready to merge, we can coordinate the tasks back together."
-Action: add_tag my-api-work --copy-from-current --description="My API tasks while collaborating with Alice"
-```
-
-**Example 2: Simple → PRD-Driven**
-```
-User: "I want to add a complete user dashboard with analytics, user management, and reporting"
-Your Response: "This sounds like a major feature that would benefit from detailed planning. Let me create a dedicated context for this work and we can draft a PRD together to ensure we capture all requirements."
-Actions: 
-1. add_tag feature-dashboard --description="User dashboard with analytics and management"
-2. Collaborate on PRD creation
-3. parse_prd dashboard-prd.txt --tag=feature-dashboard
-4. Add high-level "User Dashboard" task to master
-```
-
-**Example 3: Existing Project → Strategic Planning**
-```
-User: "I just initialized Taskmaster on my existing React app. It's getting messy and I want to improve it."
-Your Response: "Let me research your codebase to understand the current architecture, then we can create a strategic plan for improvements."
-Actions:
-1. research "Current React app architecture and improvement opportunities" --tree --files=src/
-2. Collaborate on improvement PRD based on findings
-3. Create tags for different improvement areas (refactor-components, improve-state-management, etc.)
-4. Keep only major improvement initiatives in master
-```
-
----
-
-## Primary Interaction: MCP Server vs. CLI
-
-Taskmaster offers two primary ways to interact:
-
-1.  **MCP Server (Recommended for Integrated Tools)**:
-    - For AI agents and integrated development environments (like Kiro), interacting via the **MCP server is the preferred method**.
-    - The MCP server exposes Taskmaster functionality through a set of tools (e.g., `get_tasks`, `add_subtask`).
-    - This method offers better performance, structured data exchange, and richer error handling compared to CLI parsing.
-    - Refer to @`mcp.md` for details on the MCP architecture and available tools.
-    - A comprehensive list and description of MCP tools and their corresponding CLI commands can be found in @`taskmaster.md`.
-    - **Restart the MCP server** if core logic in `scripts/modules` or MCP tool/direct function definitions change.
-    - **Note**: MCP tools fully support tagged task lists with complete tag management capabilities.
-
-2.  **`task-master` CLI (For Users & Fallback)**:
-    - The global `task-master` command provides a user-friendly interface for direct terminal interaction.
-    - It can also serve as a fallback if the MCP server is inaccessible or a specific function isn't exposed via MCP.
-    - Install globally with `npm install -g task-master-ai` or use locally via `npx task-master-ai ...`.
-    - The CLI commands often mirror the MCP tools (e.g., `task-master list` corresponds to `get_tasks`).
-    - Refer to @`taskmaster.md` for a detailed command reference.
-    - **Tagged Task Lists**: CLI fully supports the new tagged system with seamless migration.
-
-## How the Tag System Works (For Your Reference)
-
-- **Data Structure**: Tasks are organized into separate contexts (tags) like "master", "feature-branch", or "v2.0".
-- **Silent Migration**: Existing projects automatically migrate to use a "master" tag with zero disruption.
-- **Context Isolation**: Tasks in different tags are completely separate. Changes in one tag do not affect any other tag.
-- **Manual Control**: The user is always in control. There is no automatic switching. You facilitate switching by using `use-tag <name>`.
-- **Full CLI & MCP Support**: All tag management commands are available through both the CLI and MCP tools for you to use. Refer to @`taskmaster.md` for a full command list.
-
----
-
-## Task Complexity Analysis
-
--   Run `analyze_project_complexity` / `task-master analyze-complexity --research` (see @`taskmaster.md`) for comprehensive analysis
--   Review complexity report via `complexity_report` / `task-master complexity-report` (see @`taskmaster.md`) for a formatted, readable version.
--   Focus on tasks with highest complexity scores (8-10) for detailed breakdown
--   Use analysis results to determine appropriate subtask allocation
--   Note that reports are automatically used by the `expand_task` tool/command
-
-## Task Breakdown Process
-
--   Use `expand_task` / `task-master expand --id=<id>`. It automatically uses the complexity report if found, otherwise generates default number of subtasks.
--   Use `--num=<number>` to specify an explicit number of subtasks, overriding defaults or complexity report recommendations.
--   Add `--research` flag to leverage Perplexity AI for research-backed expansion.
--   Add `--force` flag to clear existing subtasks before generating new ones (default is to append).
--   Use `--prompt="<context>"` to provide additional context when needed.
--   Review and adjust generated subtasks as necessary.
--   Use `expand_all` tool or `task-master expand --all` to expand multiple pending tasks at once, respecting flags like `--force` and `--research`.
--   If subtasks need complete replacement (regardless of the `--force` flag on `expand`), clear them first with `clear_subtasks` / `task-master clear-subtasks --id=<id>`.
-
-## Implementation Drift Handling
-
--   When implementation differs significantly from planned approach
--   When future tasks need modification due to current implementation choices
--   When new dependencies or requirements emerge
--   Use `update` / `task-master update --from=<futureTaskId> --prompt='<explanation>\nUpdate context...' --research` to update multiple future tasks.
--   Use `update_task` / `task-master update-task --id=<taskId> --prompt='<explanation>\nUpdate context...' --research` to update a single specific task.
-
-## Task Status Management
-
--   Use 'pending' for tasks ready to be worked on
--   Use 'done' for completed and verified tasks
--   Use 'deferred' for postponed tasks
--   Add custom status values as needed for project-specific workflows
-
-## Task Structure Fields
-
-- **id**: Unique identifier for the task (Example: `1`, `1.1`)
-- **title**: Brief, descriptive title (Example: `"Initialize Repo"`)
-- **description**: Concise summary of what the task involves (Example: `"Create a new repository, set up initial structure."`)
-- **status**: Current state of the task (Example: `"pending"`, `"done"`, `"deferred"`)
-- **dependencies**: IDs of prerequisite tasks (Example: `[1, 2.1]`)
-    - Dependencies are displayed with status indicators (✅ for completed, ⏱️ for pending)
-    - This helps quickly identify which prerequisite tasks are blocking work
-- **priority**: Importance level (Example: `"high"`, `"medium"`, `"low"`)
-- **details**: In-depth implementation instructions (Example: `"Use GitHub client ID/secret, handle callback, set session token."`) 
-- **testStrategy**: Verification approach (Example: `"Deploy and call endpoint to confirm 'Hello World' response."`) 
-- **subtasks**: List of smaller, more specific tasks (Example: `[{"id": 1, "title": "Configure OAuth", ...}]`) 
-- Refer to task structure details (previously linked to `tasks.md`).
-
-## Configuration Management (Updated)
-
-Taskmaster configuration is managed through two main mechanisms:
-
-1.  **`.taskmaster/config.json` File (Primary):**
-    *   Located in the project root directory.
-    *   Stores most configuration settings: AI model selections (main, research, fallback), parameters (max tokens, temperature), logging level, default subtasks/priority, project name, etc.
-    *   **Tagged System Settings**: Includes `global.defaultTag` (defaults to "master") and `tags` section for tag management configuration.
-    *   **Managed via `task-master models --setup` command.** Do not edit manually unless you know what you are doing.
-    *   **View/Set specific models via `task-master models` command or `models` MCP tool.**
-    *   Created automatically when you run `task-master models --setup` for the first time or during tagged system migration.
-
-2.  **Environment Variables (`.env` / `mcp.json`):**
-    *   Used **only** for sensitive API keys and specific endpoint URLs.
-    *   Place API keys (one per provider) in a `.env` file in the project root for CLI usage.
-    *   For MCP/Kiro integration, configure these keys in the `env` section of `.kiro/mcp.json`.
-    *   Available keys/variables: See `assets/env.example` or the Configuration section in the command reference (previously linked to `taskmaster.md`).
-
-3.  **`.taskmaster/state.json` File (Tagged System State):**
-    *   Tracks current tag context and migration status.
-    *   Automatically created during tagged system migration.
-    *   Contains: `currentTag`, `lastSwitched`, `migrationNoticeShown`.
-
-**Important:** Non-API key settings (like model selections, `MAX_TOKENS`, `TASKMASTER_LOG_LEVEL`) are **no longer configured via environment variables**. Use the `task-master models` command (or `--setup` for interactive configuration) or the `models` MCP tool.
-**If AI commands FAIL in MCP** verify that the API key for the selected provider is present in the `env` section of `.kiro/mcp.json`.
-**If AI commands FAIL in CLI** verify that the API key for the selected provider is present in the `.env` file in the root of the project.
-
-## Rules Management
-
-Taskmaster supports multiple AI coding assistant rule sets that can be configured during project initialization or managed afterward:
-
-- **Available Profiles**: Claude Code, Cline, Codex, Kiro, Roo Code, Trae, Windsurf (claude, cline, codex, kiro, roo, trae, windsurf)
-- **During Initialization**: Use `task-master init --rules kiro,windsurf` to specify which rule sets to include
-- **After Initialization**: Use `task-master rules add <profiles>` or `task-master rules remove <profiles>` to manage rule sets
-- **Interactive Setup**: Use `task-master rules setup` to launch an interactive prompt for selecting rule profiles
-- **Default Behavior**: If no `--rules` flag is specified during initialization, all available rule profiles are included
-- **Rule Structure**: Each profile creates its own directory (e.g., `.kiro/steering`, `.roo/rules`) with appropriate configuration files
-
-## Determining the Next Task
-
-- Run `next_task` / `task-master next` to show the next task to work on.
-- The command identifies tasks with all dependencies satisfied
-- Tasks are prioritized by priority level, dependency count, and ID
-- The command shows comprehensive task information including:
-    - Basic task details and description
-    - Implementation details
-    - Subtasks (if they exist)
-    - Contextual suggested actions
-- Recommended before starting any new development work
-- Respects your project's dependency structure
-- Ensures tasks are completed in the appropriate sequence
-- Provides ready-to-use commands for common task actions
-
-## Viewing Specific Task Details
-
-- Run `get_task` / `task-master show <id>` to view a specific task.
-- Use dot notation for subtasks: `task-master show 1.2` (shows subtask 2 of task 1)
-- Displays comprehensive information similar to the next command, but for a specific task
-- For parent tasks, shows all subtasks and their current status
-- For subtasks, shows parent task information and relationship
-- Provides contextual suggested actions appropriate for the specific task
-- Useful for examining task details before implementation or checking status
-
-## Managing Task Dependencies
-
-- Use `add_dependency` / `task-master add-dependency --id=<id> --depends-on=<id>` to add a dependency.
-- Use `remove_dependency` / `task-master remove-dependency --id=<id> --depends-on=<id>` to remove a dependency.
-- The system prevents circular dependencies and duplicate dependency entries
-- Dependencies are checked for existence before being added or removed
-- Task files are automatically regenerated after dependency changes
-- Dependencies are visualized with status indicators in task listings and files
-
-## Task Reorganization
-
-- Use `move_task` / `task-master move --from=<id> --to=<id>` to move tasks or subtasks within the hierarchy
-- This command supports several use cases:
-  - Moving a standalone task to become a subtask (e.g., `--from=5 --to=7`)
-  - Moving a subtask to become a standalone task (e.g., `--from=5.2 --to=7`) 
-  - Moving a subtask to a different parent (e.g., `--from=5.2 --to=7.3`)
-  - Reordering subtasks within the same parent (e.g., `--from=5.2 --to=5.4`)
-  - Moving a task to a new, non-existent ID position (e.g., `--from=5 --to=25`)
-  - Moving multiple tasks at once using comma-separated IDs (e.g., `--from=10,11,12 --to=16,17,18`)
-- The system includes validation to prevent data loss:
-  - Allows moving to non-existent IDs by creating placeholder tasks
-  - Prevents moving to existing task IDs that have content (to avoid overwriting)
-  - Validates source tasks exist before attempting to move them
-- The system maintains proper parent-child relationships and dependency integrity
-- Task files are automatically regenerated after the move operation
-- This provides greater flexibility in organizing and refining your task structure as project understanding evolves
-- This is especially useful when dealing with potential merge conflicts arising from teams creating tasks on separate branches. Solve these conflicts very easily by moving your tasks and keeping theirs.
-
-## Iterative Subtask Implementation
-
-Once a task has been broken down into subtasks using `expand_task` or similar methods, follow this iterative process for implementation:
-
-1.  **Understand the Goal (Preparation):**
-    *   Use `get_task` / `task-master show <subtaskId>` (see @`taskmaster.md`) to thoroughly understand the specific goals and requirements of the subtask.
-
-2.  **Initial Exploration & Planning (Iteration 1):**
-    *   This is the first attempt at creating a concrete implementation plan.
-    *   Explore the codebase to identify the precise files, functions, and even specific lines of code that will need modification.
-    *   Determine the intended code changes (diffs) and their locations.
-    *   Gather *all* relevant details from this exploration phase.
-
-3.  **Log the Plan:**
-    *   Run `update_subtask` / `task-master update-subtask --id=<subtaskId> --prompt='<detailed plan>'`.
-    *   Provide the *complete and detailed* findings from the exploration phase in the prompt. Include file paths, line numbers, proposed diffs, reasoning, and any potential challenges identified. Do not omit details. The goal is to create a rich, timestamped log within the subtask's `details`.
-
-4.  **Verify the Plan:**
-    *   Run `get_task` / `task-master show <subtaskId>` again to confirm that the detailed implementation plan has been successfully appended to the subtask's details.
-
-5.  **Begin Implementation:**
-    *   Set the subtask status using `set_task_status` / `task-master set-status --id=<subtaskId> --status=in-progress`.
-    *   Start coding based on the logged plan.
-
-6.  **Refine and Log Progress (Iteration 2+):**
-    *   As implementation progresses, you will encounter challenges, discover nuances, or confirm successful approaches.
-    *   **Before appending new information**: Briefly review the *existing* details logged in the subtask (using `get_task` or recalling from context) to ensure the update adds fresh insights and avoids redundancy.
-    *   **Regularly** use `update_subtask` / `task-master update-subtask --id=<subtaskId> --prompt='<update details>\n- What worked...\n- What didn't work...'` to append new findings.
-    *   **Crucially, log:**
-        *   What worked ("fundamental truths" discovered).
-        *   What didn't work and why (to avoid repeating mistakes).
-        *   Specific code snippets or configurations that were successful.
-        *   Decisions made, especially if confirmed with user input.
-        *   Any deviations from the initial plan and the reasoning.
-    *   The objective is to continuously enrich the subtask's details, creating a log of the implementation journey that helps the AI (and human developers) learn, adapt, and avoid repeating errors.
-
-7.  **Review & Update Rules (Post-Implementation):**
-    *   Once the implementation for the subtask is functionally complete, review all code changes and the relevant chat history.
-    *   Identify any new or modified code patterns, conventions, or best practices established during the implementation.
-    *   Create new or update existing rules following internal guidelines (previously linked to `cursor_rules.md` and `self_improve.md`).
-
-8.  **Mark Task Complete:**
-    *   After verifying the implementation and updating any necessary rules, mark the subtask as completed: `set_task_status` / `task-master set-status --id=<subtaskId> --status=done`.
-
-9.  **Commit Changes (If using Git):**
-    *   Stage the relevant code changes and any updated/new rule files (`git add .`).
-    *   Craft a comprehensive Git commit message summarizing the work done for the subtask, including both code implementation and any rule adjustments.
-    *   Execute the commit command directly in the terminal (e.g., `git commit -m 'feat(module): Implement feature X for subtask <subtaskId>\n\n- Details about changes...\n- Updated rule Y for pattern Z'`).
-    *   Consider if a Changeset is needed according to internal versioning guidelines (previously linked to `changeset.md`). If so, run `npm run changeset`, stage the generated file, and amend the commit or create a new one.
-
-10. **Proceed to Next Subtask:**
-    *   Identify the next subtask (e.g., using `next_task` / `task-master next`).
-
-## Code Analysis & Refactoring Techniques
-
-- **Top-Level Function Search**:
-    - Useful for understanding module structure or planning refactors.
-    - Use grep/ripgrep to find exported functions/constants:
-      `rg "export (async function|function|const) \w+"` or similar patterns.
-    - Can help compare functions between files during migrations or identify potential naming conflicts.
-
----
-*This workflow provides a general guideline. Adapt it based on your specific project needs and team practices.*

.kiro/steering/kiro_rules.md

@@ -1,51 +0,0 @@
----
-inclusion: always
----
-
-- **Required Rule Structure:**
-  ```markdown
-  ---
-  description: Clear, one-line description of what the rule enforces
-  globs: path/to/files/*.ext, other/path/**/*
-  alwaysApply: boolean
-  ---
-
-  - **Main Points in Bold**
-    - Sub-points with details
-    - Examples and explanations
-  ```
-
-- **File References:**
-  - Use `[filename](mdc:path/to/file)` ([filename](mdc:filename)) to reference files
-  - Example: [prisma.md](.kiro/steering/prisma.md) for rule references
-  - Example: [schema.prisma](mdc:prisma/schema.prisma) for code references
-
-- **Code Examples:**
-  - Use language-specific code blocks
-  ```typescript
-  // ✅ DO: Show good examples
-  const goodExample = true;
-  
-  // ❌ DON'T: Show anti-patterns
-  const badExample = false;
-  ```
-
-- **Rule Content Guidelines:**
-  - Start with high-level overview
-  - Include specific, actionable requirements
-  - Show examples of correct implementation
-  - Reference existing code when possible
-  - Keep rules DRY by referencing other rules
-
-- **Rule Maintenance:**
-  - Update rules when new patterns emerge
-  - Add examples from actual codebase
-  - Remove outdated patterns
-  - Cross-reference related rules
-
-- **Best Practices:**
-  - Use bullet points for clarity
-  - Keep descriptions concise
-  - Include both DO and DON'T examples
-  - Reference actual code over theoretical examples
-  - Use consistent formatting across rules