chore: prepare branch
This commit is contained in:
Ralph Khreish
125
.taskmaster/docs/tdd-workflow-phase-0-spike.md
Normal file
125
.taskmaster/docs/tdd-workflow-phase-0-spike.md
Normal file
@@ -0,0 +1,125 @@
|
||||
# Phase 0: Spike - Autonomous TDD Workflow
|
||||
|
||||
## Objective
|
||||
Validate feasibility and build foundational understanding before full implementation.
|
||||
|
||||
## Scope
|
||||
- Implement CLI skeleton `tm autopilot` with dry-run mode
|
||||
- Show planned steps from a real task with subtasks
|
||||
- Detect test runner from package.json
|
||||
- Detect git state and render preflight report
|
||||
|
||||
## Deliverables
|
||||
|
||||
### 1. CLI Command Skeleton
|
||||
- Create `apps/cli/src/commands/autopilot.command.ts`
|
||||
- Support `tm autopilot <taskId>` command
|
||||
- Implement `--dry-run` flag
|
||||
- Basic help text and usage information
|
||||
|
||||
### 2. Preflight Detection System
|
||||
- Detect test runner from package.json (npm test, pnpm test, etc.)
|
||||
- Check git working tree state (clean/dirty)
|
||||
- Validate required tools are available (git, gh, node/npm)
|
||||
- Detect default branch
|
||||
|
||||
### 3. Dry-Run Execution Plan Display
|
||||
Display planned execution for a task including:
|
||||
- Preflight checks status
|
||||
- Branch name that would be created
|
||||
- Tag that would be set
|
||||
- List of subtasks in execution order
|
||||
- For each subtask:
|
||||
- RED phase: test file that would be created
|
||||
- GREEN phase: implementation files that would be modified
|
||||
- COMMIT: commit message that would be used
|
||||
- Finalization steps: test suite run, coverage check, push, PR creation
|
||||
|
||||
### 4. Task Loading & Validation
|
||||
- Load task from TaskMaster state
|
||||
- Validate task exists and has subtasks
|
||||
- If no subtasks, show message about needing to expand first
|
||||
- Show dependency order for subtasks
|
||||
|
||||
## Example Output
|
||||
|
||||
```bash
|
||||
$ tm autopilot 42 --dry-run
|
||||
|
||||
Autopilot Plan for Task #42 [analytics]: User metrics tracking
|
||||
─────────────────────────────────────────────────────────────
|
||||
|
||||
Preflight Checks:
|
||||
✓ Working tree is clean
|
||||
✓ Test command detected: npm test
|
||||
✓ Tools available: git, gh, node, npm
|
||||
✓ Current branch: main (will create new branch)
|
||||
✓ Task has 3 subtasks ready to execute
|
||||
|
||||
Branch & Tag:
|
||||
→ Will create branch: analytics/task-42-user-metrics
|
||||
→ Will set active tag: analytics
|
||||
|
||||
Execution Plan (3 subtasks):
|
||||
|
||||
1. Subtask 42.1: Add metrics schema
|
||||
RED: Generate tests → src/__tests__/schema.test.js
|
||||
GREEN: Implement code → src/schema.js
|
||||
COMMIT: "feat(metrics): add metrics schema (task 42.1)"
|
||||
|
||||
2. Subtask 42.2: Add collection endpoint [depends on 42.1]
|
||||
RED: Generate tests → src/api/__tests__/metrics.test.js
|
||||
GREEN: Implement code → src/api/metrics.js
|
||||
COMMIT: "feat(metrics): add collection endpoint (task 42.2)"
|
||||
|
||||
3. Subtask 42.3: Add dashboard widget [depends on 42.2]
|
||||
RED: Generate tests → src/components/__tests__/MetricsWidget.test.jsx
|
||||
GREEN: Implement code → src/components/MetricsWidget.jsx
|
||||
COMMIT: "feat(metrics): add dashboard widget (task 42.3)"
|
||||
|
||||
Finalization:
|
||||
→ Run full test suite with coverage (threshold: 80%)
|
||||
→ Push branch to origin (will confirm)
|
||||
→ Create PR targeting main
|
||||
|
||||
Estimated commits: 3
|
||||
Estimated duration: ~20-30 minutes (depends on implementation complexity)
|
||||
|
||||
Run without --dry-run to execute.
|
||||
```
|
||||
|
||||
## Success Criteria
|
||||
- Dry-run output is clear and matches expected workflow
|
||||
- Preflight detection works correctly on the project repo
|
||||
- Task loading integrates with existing TaskMaster state
|
||||
- No actual git operations or file modifications occur in dry-run mode
|
||||
|
||||
## Out of Scope
|
||||
- Actual test generation
|
||||
- Actual code implementation
|
||||
- Git operations (branch creation, commits, push)
|
||||
- PR creation
|
||||
- Test execution
|
||||
|
||||
## Implementation Notes
|
||||
- Reuse existing `TaskService` from `packages/tm-core`
|
||||
- Use existing git utilities from `scripts/modules/utils/git-utils.js`
|
||||
- Load task/subtask data from `.taskmaster/tasks/tasks.json`
|
||||
- Detect test command via package.json → scripts.test field
|
||||
|
||||
## Dependencies
|
||||
- Existing TaskMaster CLI structure
|
||||
- Existing task storage format
|
||||
- Git utilities
|
||||
|
||||
## Estimated Effort
|
||||
2-3 days
|
||||
|
||||
## Validation
|
||||
Test dry-run mode with:
|
||||
- Task with 1 subtask
|
||||
- Task with multiple subtasks
|
||||
- Task with dependencies between subtasks
|
||||
- Task without subtasks (should show warning)
|
||||
- Dirty git working tree (should warn)
|
||||
- Missing tools (should error with helpful message)
|
||||
380
.taskmaster/docs/tdd-workflow-phase-1-core-rails.md
Normal file
380
.taskmaster/docs/tdd-workflow-phase-1-core-rails.md
Normal file
@@ -0,0 +1,380 @@
|
||||
# Phase 1: Core Rails - Autonomous TDD Workflow
|
||||
|
||||
## Objective
|
||||
Implement the core autonomous TDD workflow with safe git operations, test generation/execution, and commit gating.
|
||||
|
||||
## Scope
|
||||
- WorkflowOrchestrator with event stream
|
||||
- Git and Test adapters
|
||||
- Subtask loop (RED → GREEN → COMMIT)
|
||||
- Framework-agnostic test generation using Surgical Test Generator
|
||||
- Test execution with detected test command
|
||||
- Commit gating on passing tests and coverage
|
||||
- Branch/tag mapping
|
||||
- Run report persistence
|
||||
|
||||
## Deliverables
|
||||
|
||||
### 1. WorkflowOrchestrator (`packages/tm-core/src/services/workflow-orchestrator.ts`)
|
||||
|
||||
**Responsibilities:**
|
||||
- State machine driving phases: Preflight → Branch/Tag → SubtaskIter → Finalize
|
||||
- Event emission for progress tracking
|
||||
- Coordination of Git, Test, and Executor adapters
|
||||
- Run state persistence
|
||||
|
||||
**API:**
|
||||
```typescript
|
||||
class WorkflowOrchestrator {
|
||||
async executeTask(taskId: string, options: AutopilotOptions): Promise<RunResult>
|
||||
async resume(runId: string): Promise<RunResult>
|
||||
on(event: string, handler: (data: any) => void): void
|
||||
|
||||
// Events emitted:
|
||||
// - 'phase:start' { phase, timestamp }
|
||||
// - 'phase:complete' { phase, status, timestamp }
|
||||
// - 'subtask:start' { subtaskId, phase }
|
||||
// - 'subtask:complete' { subtaskId, phase, status }
|
||||
// - 'test:run' { subtaskId, phase, results }
|
||||
// - 'commit:created' { subtaskId, sha, message }
|
||||
// - 'error' { phase, error, recoverable }
|
||||
}
|
||||
```
|
||||
|
||||
**State Machine Phases:**
|
||||
1. Preflight - validate environment
|
||||
2. BranchSetup - create branch, set tag
|
||||
3. SubtaskLoop - for each subtask: RED → GREEN → COMMIT
|
||||
4. Finalize - full test suite, coverage check
|
||||
5. Complete - run report, cleanup
|
||||
|
||||
### 2. GitAdapter (`packages/tm-core/src/services/git-adapter.ts`)
|
||||
|
||||
**Responsibilities:**
|
||||
- All git operations with safety checks
|
||||
- Branch name generation from tag/task
|
||||
- Confirmation gates for destructive operations
|
||||
|
||||
**API:**
|
||||
```typescript
|
||||
class GitAdapter {
|
||||
async isWorkingTreeClean(): Promise<boolean>
|
||||
async getCurrentBranch(): Promise<string>
|
||||
async getDefaultBranch(): Promise<string>
|
||||
async createBranch(name: string): Promise<void>
|
||||
async checkoutBranch(name: string): Promise<void>
|
||||
async commit(message: string, files?: string[]): Promise<string>
|
||||
async push(branch: string, remote?: string): Promise<void>
|
||||
|
||||
// Safety checks
|
||||
async assertNotOnDefaultBranch(): Promise<void>
|
||||
async assertCleanOrConfirm(): Promise<void>
|
||||
|
||||
// Branch naming
|
||||
generateBranchName(tag: string, taskId: string, slug: string): string
|
||||
}
|
||||
```
|
||||
|
||||
**Guardrails:**
|
||||
- Never allow commits on default branch
|
||||
- Always check working tree before branch creation
|
||||
- Confirm destructive operations unless `--no-confirm` flag
|
||||
|
||||
### 3. TestRunnerAdapter (`packages/tm-core/src/services/test-runner-adapter.ts`)
|
||||
|
||||
**Responsibilities:**
|
||||
- Detect test command from package.json
|
||||
- Execute tests (targeted and full suite)
|
||||
- Parse test results and coverage
|
||||
- Enforce coverage thresholds
|
||||
|
||||
**API:**
|
||||
```typescript
|
||||
class TestRunnerAdapter {
|
||||
async detectTestCommand(): Promise<string>
|
||||
async runTargeted(pattern: string): Promise<TestResults>
|
||||
async runAll(): Promise<TestResults>
|
||||
async getCoverage(): Promise<CoverageReport>
|
||||
async meetsThresholds(coverage: CoverageReport): Promise<boolean>
|
||||
}
|
||||
|
||||
interface TestResults {
|
||||
exitCode: number
|
||||
duration: number
|
||||
summary: {
|
||||
total: number
|
||||
passed: number
|
||||
failed: number
|
||||
skipped: number
|
||||
}
|
||||
failures: Array<{
|
||||
test: string
|
||||
error: string
|
||||
stack?: string
|
||||
}>
|
||||
}
|
||||
|
||||
interface CoverageReport {
|
||||
lines: number
|
||||
branches: number
|
||||
functions: number
|
||||
statements: number
|
||||
}
|
||||
```
|
||||
|
||||
**Detection Logic:**
|
||||
- Check package.json → scripts.test
|
||||
- Support: npm test, pnpm test, yarn test, bun test
|
||||
- Fall back to explicit command from config
|
||||
|
||||
### 4. Test Generation Integration
|
||||
|
||||
**Use Surgical Test Generator:**
|
||||
- Load prompt from `.claude/agents/surgical-test-generator.md`
|
||||
- Compose with task/subtask context
|
||||
- Generate tests via executor (Claude)
|
||||
- Write test files to detected locations
|
||||
|
||||
**Prompt Composition:**
|
||||
```typescript
|
||||
async function composeRedPrompt(subtask: Subtask, context: ProjectContext): Promise<string> {
|
||||
const systemPrompts = [
|
||||
loadFile('.cursor/rules/git_workflow.mdc'),
|
||||
loadFile('.cursor/rules/test_workflow.mdc'),
|
||||
loadFile('.claude/agents/surgical-test-generator.md')
|
||||
]
|
||||
|
||||
const taskContext = formatTaskContext(subtask)
|
||||
const instruction = formatRedInstruction(subtask, context)
|
||||
|
||||
return [
|
||||
...systemPrompts,
|
||||
'<TASK CONTEXT>',
|
||||
taskContext,
|
||||
'<INSTRUCTION>',
|
||||
instruction
|
||||
].join('\n\n')
|
||||
}
|
||||
```
|
||||
|
||||
### 5. Subtask Loop Implementation
|
||||
|
||||
**RED Phase:**
|
||||
1. Compose test generation prompt with subtask context
|
||||
2. Execute via Claude executor
|
||||
3. Parse generated test file paths and code
|
||||
4. Write test files to filesystem
|
||||
5. Run tests to confirm they fail (red state)
|
||||
6. Store test results in run artifacts
|
||||
7. If tests pass unexpectedly, warn and skip to next subtask
|
||||
|
||||
**GREEN Phase:**
|
||||
1. Compose implementation prompt with test failures
|
||||
2. Execute via Claude executor with max attempts (default: 3)
|
||||
3. Parse implementation changes
|
||||
4. Apply changes to filesystem
|
||||
5. Run tests to verify passing (green state)
|
||||
6. If tests still fail after max attempts:
|
||||
- Save current state
|
||||
- Emit pause event
|
||||
- Return resumable checkpoint
|
||||
7. If tests pass, proceed to COMMIT
|
||||
|
||||
**COMMIT Phase:**
|
||||
1. Verify all tests pass
|
||||
2. Check coverage meets thresholds (if enabled)
|
||||
3. Generate conventional commit message
|
||||
4. Stage test files + implementation files
|
||||
5. Commit with message
|
||||
6. Update subtask status to 'done'
|
||||
7. Emit commit event with SHA
|
||||
8. Continue to next subtask
|
||||
|
||||
### 6. Branch & Tag Management
|
||||
|
||||
**Integration with existing tag system:**
|
||||
- Use `scripts/modules/task-manager/tag-management.js`
|
||||
- Explicit tag switching when branch created
|
||||
- Store branch ↔ tag mapping in run state
|
||||
|
||||
**Branch Naming:**
|
||||
- Pattern from config: `{tag}/task-{id}-{slug}`
|
||||
- Default: `analytics/task-42-user-metrics`
|
||||
- Sanitize: lowercase, replace spaces with hyphens
|
||||
|
||||
### 7. Run Artifacts & State Persistence
|
||||
|
||||
**Directory structure:**
|
||||
```
|
||||
.taskmaster/reports/runs/<run-id>/
|
||||
├── manifest.json # run metadata
|
||||
├── log.jsonl # event stream
|
||||
├── commits.txt # commit SHAs
|
||||
├── test-results/
|
||||
│ ├── subtask-42.1-red.json
|
||||
│ ├── subtask-42.1-green.json
|
||||
│ ├── subtask-42.2-red.json
|
||||
│ ├── subtask-42.2-green-attempt1.json
|
||||
│ ├── subtask-42.2-green-attempt2.json
|
||||
│ └── final-suite.json
|
||||
└── state.json # resumable checkpoint
|
||||
```
|
||||
|
||||
**manifest.json:**
|
||||
```json
|
||||
{
|
||||
"runId": "2025-01-15-142033",
|
||||
"taskId": "42",
|
||||
"tag": "analytics",
|
||||
"branch": "analytics/task-42-user-metrics",
|
||||
"startTime": "2025-01-15T14:20:33Z",
|
||||
"endTime": null,
|
||||
"status": "in-progress",
|
||||
"currentPhase": "subtask-loop",
|
||||
"currentSubtask": "42.2",
|
||||
"subtasksCompleted": ["42.1"],
|
||||
"subtasksFailed": [],
|
||||
"totalCommits": 1
|
||||
}
|
||||
```
|
||||
|
||||
**log.jsonl** (append-only event log):
|
||||
```jsonl
|
||||
{"ts":"2025-01-15T14:20:33Z","event":"phase:start","phase":"preflight","status":"ok"}
|
||||
{"ts":"2025-01-15T14:21:00Z","event":"subtask:start","subtask":"42.1","phase":"red"}
|
||||
{"ts":"2025-01-15T14:22:00Z","event":"test:run","subtask":"42.1","phase":"red","results":{"passed":0,"failed":3}}
|
||||
{"ts":"2025-01-15T14:23:00Z","event":"subtask:start","subtask":"42.1","phase":"green"}
|
||||
{"ts":"2025-01-15T14:24:30Z","event":"test:run","subtask":"42.1","phase":"green","attempt":1,"results":{"passed":3,"failed":0}}
|
||||
{"ts":"2025-01-15T14:24:35Z","event":"commit:created","subtask":"42.1","sha":"a1b2c3d","message":"feat(metrics): add metrics schema (task 42.1)"}
|
||||
```
|
||||
|
||||
### 8. CLI Command Implementation
|
||||
|
||||
**Update `tm autopilot` command:**
|
||||
- Remove `--dry-run` only behavior
|
||||
- Execute actual workflow when flag not present
|
||||
- Add progress reporting via orchestrator events
|
||||
- Support `--no-confirm` for CI/automation
|
||||
- Support `--max-attempts` to override default
|
||||
|
||||
**Real-time output:**
|
||||
```bash
|
||||
$ tm autopilot 42
|
||||
|
||||
🚀 Starting autopilot for Task #42 [analytics]: User metrics tracking
|
||||
|
||||
✓ Preflight checks passed
|
||||
✓ Created branch: analytics/task-42-user-metrics
|
||||
✓ Set active tag: analytics
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
[1/3] Subtask 42.1: Add metrics schema
|
||||
|
||||
RED Generating tests... ⏳
|
||||
RED ✓ Tests created: src/__tests__/schema.test.js
|
||||
RED ✓ Tests failing: 3 failed, 0 passed
|
||||
|
||||
GREEN Implementing code... ⏳
|
||||
GREEN ✓ Tests passing: 3 passed, 0 failed (attempt 1)
|
||||
|
||||
COMMIT ✓ Committed: a1b2c3d
|
||||
"feat(metrics): add metrics schema (task 42.1)"
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
[2/3] Subtask 42.2: Add collection endpoint
|
||||
...
|
||||
```
|
||||
|
||||
## Success Criteria
|
||||
- Can execute a simple task end-to-end without manual intervention
|
||||
- All commits made on feature branch, never on default branch
|
||||
- Tests are generated before implementation (RED → GREEN order enforced)
|
||||
- Only commits when tests pass and coverage meets threshold
|
||||
- Run state is persisted and can be inspected post-run
|
||||
- Clear error messages when things go wrong
|
||||
- Orchestrator events allow CLI to show live progress
|
||||
|
||||
## Configuration
|
||||
|
||||
**Add to `.taskmaster/config.json`:**
|
||||
```json
|
||||
{
|
||||
"autopilot": {
|
||||
"enabled": true,
|
||||
"requireCleanWorkingTree": true,
|
||||
"commitTemplate": "{type}({scope}): {msg}",
|
||||
"defaultCommitType": "feat",
|
||||
"maxGreenAttempts": 3,
|
||||
"testTimeout": 300000
|
||||
},
|
||||
"test": {
|
||||
"runner": "auto",
|
||||
"coverageThresholds": {
|
||||
"lines": 80,
|
||||
"branches": 80,
|
||||
"functions": 80,
|
||||
"statements": 80
|
||||
},
|
||||
"targetedRunPattern": "**/*.test.js"
|
||||
},
|
||||
"git": {
|
||||
"branchPattern": "{tag}/task-{id}-{slug}",
|
||||
"defaultRemote": "origin"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Out of Scope (defer to Phase 2)
|
||||
- PR creation (gh integration)
|
||||
- Resume functionality (`--resume` flag)
|
||||
- Lint/format step
|
||||
- Multiple executor support (only Claude)
|
||||
|
||||
## Implementation Order
|
||||
1. GitAdapter with safety checks
|
||||
2. TestRunnerAdapter with detection logic
|
||||
3. WorkflowOrchestrator state machine skeleton
|
||||
4. RED phase: test generation integration
|
||||
5. GREEN phase: implementation with retry logic
|
||||
6. COMMIT phase: gating and persistence
|
||||
7. CLI command wiring with event handling
|
||||
8. Run artifacts and logging
|
||||
|
||||
## Testing Strategy
|
||||
- Unit tests for each adapter (mock git/test commands)
|
||||
- Integration tests with real git repo (temporary directory)
|
||||
- End-to-end test with sample task in test project
|
||||
- Verify no commits on default branch (security test)
|
||||
- Verify commit gating works (force test failure, ensure no commit)
|
||||
|
||||
## Dependencies
|
||||
- Phase 0 completed (CLI skeleton, preflight checks)
|
||||
- Existing TaskService and executor infrastructure
|
||||
- Surgical Test Generator prompt file exists
|
||||
|
||||
## Estimated Effort
|
||||
2-3 weeks
|
||||
|
||||
## Risks & Mitigations
|
||||
- **Risk:** Test generation produces invalid/wrong tests
|
||||
- **Mitigation:** Use Surgical Test Generator prompt, add manual review step in early iterations
|
||||
|
||||
- **Risk:** Implementation attempts timeout/fail repeatedly
|
||||
- **Mitigation:** Max attempts with pause/resume; store state for manual intervention
|
||||
|
||||
- **Risk:** Coverage parsing fails on different test frameworks
|
||||
- **Mitigation:** Start with one framework (vitest), add parsers incrementally
|
||||
|
||||
- **Risk:** Git operations fail (conflicts, permissions)
|
||||
- **Mitigation:** Detailed error messages, save state before destructive ops
|
||||
|
||||
## Validation
|
||||
Test with:
|
||||
- Simple task (1 subtask, clear requirements)
|
||||
- Medium task (3 subtasks with dependencies)
|
||||
- Task requiring multiple GREEN attempts
|
||||
- Task with dirty working tree (should error)
|
||||
- Task on default branch (should error)
|
||||
- Project without test command (should error with helpful message)
|
||||
433
.taskmaster/docs/tdd-workflow-phase-2-pr-resumability.md
Normal file
433
.taskmaster/docs/tdd-workflow-phase-2-pr-resumability.md
Normal file
@@ -0,0 +1,433 @@
|
||||
# Phase 2: PR + Resumability - Autonomous TDD Workflow
|
||||
|
||||
## Objective
|
||||
Add PR creation with GitHub CLI integration, resumable checkpoints for interrupted runs, and enhanced guardrails with coverage enforcement.
|
||||
|
||||
## Scope
|
||||
- GitHub PR creation via `gh` CLI
|
||||
- Well-formed PR body using run report
|
||||
- Resumable checkpoints and `--resume` flag
|
||||
- Coverage enforcement before finalization
|
||||
- Optional lint/format step
|
||||
- Enhanced error recovery
|
||||
|
||||
## Deliverables
|
||||
|
||||
### 1. PR Creation Integration
|
||||
|
||||
**PRAdapter** (`packages/tm-core/src/services/pr-adapter.ts`):
|
||||
```typescript
|
||||
class PRAdapter {
|
||||
async isGHAvailable(): Promise<boolean>
|
||||
async createPR(options: PROptions): Promise<PRResult>
|
||||
async getPRTemplate(runReport: RunReport): Promise<string>
|
||||
|
||||
// Fallback for missing gh CLI
|
||||
async getManualPRInstructions(options: PROptions): Promise<string>
|
||||
}
|
||||
|
||||
interface PROptions {
|
||||
branch: string
|
||||
base: string
|
||||
title: string
|
||||
body: string
|
||||
draft?: boolean
|
||||
}
|
||||
|
||||
interface PRResult {
|
||||
url: string
|
||||
number: number
|
||||
}
|
||||
```
|
||||
|
||||
**PR Title Format:**
|
||||
```
|
||||
Task #<id> [<tag>]: <title>
|
||||
```
|
||||
|
||||
Example: `Task #42 [analytics]: User metrics tracking`
|
||||
|
||||
**PR Body Template:**
|
||||
|
||||
Located at `.taskmaster/templates/pr-body.md`:
|
||||
|
||||
```markdown
|
||||
## Summary
|
||||
|
||||
Implements Task #42 from TaskMaster autonomous workflow.
|
||||
|
||||
**Branch:** {branch}
|
||||
**Tag:** {tag}
|
||||
**Subtasks completed:** {subtaskCount}
|
||||
|
||||
{taskDescription}
|
||||
|
||||
## Subtasks
|
||||
|
||||
{subtasksList}
|
||||
|
||||
## Test Coverage
|
||||
|
||||
| Metric | Coverage |
|
||||
|--------|----------|
|
||||
| Lines | {lines}% |
|
||||
| Branches | {branches}% |
|
||||
| Functions | {functions}% |
|
||||
| Statements | {statements}% |
|
||||
|
||||
**All subtasks passed with {totalTests} tests.**
|
||||
|
||||
## Commits
|
||||
|
||||
{commitsList}
|
||||
|
||||
## Run Report
|
||||
|
||||
Full execution report: `.taskmaster/reports/runs/{runId}/`
|
||||
|
||||
---
|
||||
|
||||
🤖 Generated with [Task Master](https://github.com/cline/task-master) autonomous TDD workflow
|
||||
```
|
||||
|
||||
**Token replacement:**
|
||||
- `{branch}` → branch name
|
||||
- `{tag}` → active tag
|
||||
- `{subtaskCount}` → number of completed subtasks
|
||||
- `{taskDescription}` → task description from TaskMaster
|
||||
- `{subtasksList}` → markdown list of subtask titles
|
||||
- `{lines}`, `{branches}`, `{functions}`, `{statements}` → coverage percentages
|
||||
- `{totalTests}` → total test count
|
||||
- `{commitsList}` → markdown list of commit SHAs and messages
|
||||
- `{runId}` → run ID timestamp
|
||||
|
||||
### 2. GitHub CLI Integration
|
||||
|
||||
**Detection:**
|
||||
```bash
|
||||
which gh
|
||||
```
|
||||
|
||||
If not found, show fallback instructions:
|
||||
```bash
|
||||
✓ Branch pushed: analytics/task-42-user-metrics
|
||||
✗ gh CLI not found - cannot create PR automatically
|
||||
|
||||
To create PR manually:
|
||||
gh pr create \
|
||||
--base main \
|
||||
--head analytics/task-42-user-metrics \
|
||||
--title "Task #42 [analytics]: User metrics tracking" \
|
||||
--body-file .taskmaster/reports/runs/2025-01-15-142033/pr.md
|
||||
|
||||
Or visit:
|
||||
https://github.com/org/repo/compare/main...analytics/task-42-user-metrics
|
||||
```
|
||||
|
||||
**Confirmation gate:**
|
||||
```bash
|
||||
Ready to create PR:
|
||||
Title: Task #42 [analytics]: User metrics tracking
|
||||
Base: main
|
||||
Head: analytics/task-42-user-metrics
|
||||
|
||||
Create PR? [Y/n]
|
||||
```
|
||||
|
||||
Unless `--no-confirm` flag is set.
|
||||
|
||||
### 3. Resumable Workflow
|
||||
|
||||
**State Checkpoint** (`state.json`):
|
||||
```json
|
||||
{
|
||||
"runId": "2025-01-15-142033",
|
||||
"taskId": "42",
|
||||
"phase": "subtask-loop",
|
||||
"currentSubtask": "42.2",
|
||||
"currentPhase": "green",
|
||||
"attempts": 2,
|
||||
"completedSubtasks": ["42.1"],
|
||||
"commits": ["a1b2c3d"],
|
||||
"branch": "analytics/task-42-user-metrics",
|
||||
"tag": "analytics",
|
||||
"canResume": true,
|
||||
"pausedAt": "2025-01-15T14:25:35Z",
|
||||
"pausedReason": "max_attempts_reached",
|
||||
"nextAction": "manual_review_required"
|
||||
}
|
||||
```
|
||||
|
||||
**Resume Command:**
|
||||
```bash
|
||||
$ tm autopilot --resume
|
||||
|
||||
Resuming run: 2025-01-15-142033
|
||||
Task: #42 [analytics] User metrics tracking
|
||||
Branch: analytics/task-42-user-metrics
|
||||
Last subtask: 42.2 (GREEN phase, attempt 2/3 failed)
|
||||
Paused: 5 minutes ago
|
||||
|
||||
Reason: Could not achieve green state after 3 attempts
|
||||
Last error: POST /api/metrics returns 500 instead of 201
|
||||
|
||||
Resume from subtask 42.2 GREEN phase? [Y/n]
|
||||
```
|
||||
|
||||
**Resume logic:**
|
||||
1. Load state from `.taskmaster/reports/runs/<runId>/state.json`
|
||||
2. Verify branch still exists and is checked out
|
||||
3. Verify no uncommitted changes (unless `--force`)
|
||||
4. Continue from last checkpoint phase
|
||||
5. Update state file as execution progresses
|
||||
|
||||
**Multiple interrupted runs:**
|
||||
```bash
|
||||
$ tm autopilot --resume
|
||||
|
||||
Found 2 resumable runs:
|
||||
1. 2025-01-15-142033 - Task #42 (paused 5 min ago at subtask 42.2 GREEN)
|
||||
2. 2025-01-14-103022 - Task #38 (paused 2 hours ago at subtask 38.3 RED)
|
||||
|
||||
Select run to resume [1-2]:
|
||||
```
|
||||
|
||||
### 4. Coverage Enforcement
|
||||
|
||||
**Coverage Check Phase** (before finalization):
|
||||
```typescript
|
||||
async function enforceCoverage(runId: string): Promise<void> {
|
||||
const testResults = await testRunner.runAll()
|
||||
const coverage = await testRunner.getCoverage()
|
||||
|
||||
const thresholds = config.test.coverageThresholds
|
||||
const failures = []
|
||||
|
||||
if (coverage.lines < thresholds.lines) {
|
||||
failures.push(`Lines: ${coverage.lines}% < ${thresholds.lines}%`)
|
||||
}
|
||||
// ... check branches, functions, statements
|
||||
|
||||
if (failures.length > 0) {
|
||||
throw new CoverageError(
|
||||
`Coverage thresholds not met:\n${failures.join('\n')}`
|
||||
)
|
||||
}
|
||||
|
||||
// Store coverage in run report
|
||||
await storeRunArtifact(runId, 'coverage.json', coverage)
|
||||
}
|
||||
```
|
||||
|
||||
**Handling coverage failures:**
|
||||
```bash
|
||||
⚠️ Coverage check failed:
|
||||
Lines: 78.5% < 80%
|
||||
Branches: 75.0% < 80%
|
||||
|
||||
Options:
|
||||
1. Add more tests and resume
|
||||
2. Lower thresholds in .taskmaster/config.json
|
||||
3. Skip coverage check: tm autopilot --resume --skip-coverage
|
||||
|
||||
Run paused. Fix coverage and resume with:
|
||||
tm autopilot --resume
|
||||
```
|
||||
|
||||
### 5. Optional Lint/Format Step
|
||||
|
||||
**Configuration:**
|
||||
```json
|
||||
{
|
||||
"autopilot": {
|
||||
"finalization": {
|
||||
"lint": {
|
||||
"enabled": true,
|
||||
"command": "npm run lint",
|
||||
"fix": true,
|
||||
"failOnError": false
|
||||
},
|
||||
"format": {
|
||||
"enabled": true,
|
||||
"command": "npm run format",
|
||||
"commitChanges": true
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Execution:**
|
||||
```bash
|
||||
Finalization Steps:
|
||||
|
||||
✓ All tests passing (12 tests, 0 failures)
|
||||
✓ Coverage thresholds met (85% lines, 82% branches)
|
||||
|
||||
LINT Running linter... ⏳
|
||||
LINT ✓ No lint errors
|
||||
|
||||
FORMAT Running formatter... ⏳
|
||||
FORMAT ✓ Formatted 3 files
|
||||
FORMAT ✓ Committed formatting changes: "chore: auto-format code"
|
||||
|
||||
PUSH Pushing to origin... ⏳
|
||||
PUSH ✓ Pushed analytics/task-42-user-metrics
|
||||
|
||||
PR Creating pull request... ⏳
|
||||
PR ✓ Created PR #123
|
||||
https://github.com/org/repo/pull/123
|
||||
```
|
||||
|
||||
### 6. Enhanced Error Recovery
|
||||
|
||||
**Pause Points:**
|
||||
- Max GREEN attempts reached (current)
|
||||
- Coverage check failed (new)
|
||||
- Lint errors (if `failOnError: true`)
|
||||
- Git push failed (new)
|
||||
- PR creation failed (new)
|
||||
|
||||
**Each pause saves:**
|
||||
- Full state checkpoint
|
||||
- Last command output
|
||||
- Suggested next actions
|
||||
- Resume instructions
|
||||
|
||||
**Automatic recovery attempts:**
|
||||
- Git push: retry up to 3 times with backoff
|
||||
- PR creation: fall back to manual instructions
|
||||
- Lint: auto-fix if enabled, otherwise pause
|
||||
|
||||
### 7. Finalization Phase Enhancement
|
||||
|
||||
**Updated workflow:**
|
||||
1. Run full test suite
|
||||
2. Check coverage thresholds → pause if failed
|
||||
3. Run lint (if enabled) → pause if failed and `failOnError: true`
|
||||
4. Run format (if enabled) → auto-commit changes
|
||||
5. Confirm push (unless `--no-confirm`)
|
||||
6. Push branch → retry on failure
|
||||
7. Generate PR body from template
|
||||
8. Create PR via gh → fall back to manual instructions
|
||||
9. Update task status to 'review' (configurable)
|
||||
10. Save final run report
|
||||
|
||||
**Final output:**
|
||||
```bash
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
✅ Task #42 [analytics]: User metrics tracking - COMPLETE
|
||||
|
||||
Branch: analytics/task-42-user-metrics
|
||||
Subtasks completed: 3/3
|
||||
Commits: 3
|
||||
Total tests: 12 (12 passed, 0 failed)
|
||||
Coverage: 85% lines, 82% branches, 88% functions, 85% statements
|
||||
|
||||
PR #123: https://github.com/org/repo/pull/123
|
||||
|
||||
Run report: .taskmaster/reports/runs/2025-01-15-142033/
|
||||
|
||||
Next steps:
|
||||
- Review PR and request changes if needed
|
||||
- Merge when ready
|
||||
- Task status updated to 'review'
|
||||
|
||||
Completed in 24 minutes
|
||||
```
|
||||
|
||||
## CLI Updates
|
||||
|
||||
**New flags:**
|
||||
- `--resume` → Resume from last checkpoint
|
||||
- `--skip-coverage` → Skip coverage checks
|
||||
- `--skip-lint` → Skip lint step
|
||||
- `--skip-format` → Skip format step
|
||||
- `--skip-pr` → Push branch but don't create PR
|
||||
- `--draft-pr` → Create draft PR instead of ready-for-review
|
||||
|
||||
## Configuration Updates
|
||||
|
||||
**Add to `.taskmaster/config.json`:**
|
||||
```json
|
||||
{
|
||||
"autopilot": {
|
||||
"finalization": {
|
||||
"lint": {
|
||||
"enabled": false,
|
||||
"command": "npm run lint",
|
||||
"fix": true,
|
||||
"failOnError": false
|
||||
},
|
||||
"format": {
|
||||
"enabled": false,
|
||||
"command": "npm run format",
|
||||
"commitChanges": true
|
||||
},
|
||||
"updateTaskStatus": "review"
|
||||
}
|
||||
},
|
||||
"git": {
|
||||
"pr": {
|
||||
"enabled": true,
|
||||
"base": "default",
|
||||
"bodyTemplate": ".taskmaster/templates/pr-body.md",
|
||||
"draft": false
|
||||
},
|
||||
"pushRetries": 3,
|
||||
"pushRetryDelay": 5000
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Success Criteria
|
||||
- Can create PR automatically with well-formed body
|
||||
- Can resume interrupted runs from any checkpoint
|
||||
- Coverage checks prevent low-quality code from being merged
|
||||
- Clear error messages and recovery paths for all failure modes
|
||||
- Run reports include full PR context for review
|
||||
|
||||
## Out of Scope (defer to Phase 3)
|
||||
- Multiple test framework support (pytest, go test)
|
||||
- Diff preview before commits
|
||||
- TUI panel implementation
|
||||
- Extension/IDE integration
|
||||
|
||||
## Testing Strategy
|
||||
- Mock `gh` CLI for PR creation tests
|
||||
- Test resume from each possible pause point
|
||||
- Test coverage failure scenarios
|
||||
- Test lint/format integration with mock commands
|
||||
- End-to-end test with PR creation on test repo
|
||||
|
||||
## Dependencies
|
||||
- Phase 1 completed (core workflow)
|
||||
- GitHub CLI (`gh`) installed (optional, fallback provided)
|
||||
- Test framework supports coverage output
|
||||
|
||||
## Estimated Effort
|
||||
1-2 weeks
|
||||
|
||||
## Risks & Mitigations
|
||||
- **Risk:** GitHub CLI auth issues
|
||||
- **Mitigation:** Clear auth setup docs, fallback to manual instructions
|
||||
|
||||
- **Risk:** PR body template doesn't match all project needs
|
||||
- **Mitigation:** Make template customizable via config path
|
||||
|
||||
- **Risk:** Resume state gets corrupted
|
||||
- **Mitigation:** Validate state on load, provide --force-reset option
|
||||
|
||||
- **Risk:** Coverage calculation differs between runs
|
||||
- **Mitigation:** Store coverage with each test run for comparison
|
||||
|
||||
## Validation
|
||||
Test with:
|
||||
- Successful PR creation end-to-end
|
||||
- Resume from GREEN attempt failure
|
||||
- Resume from coverage failure
|
||||
- Resume from lint failure
|
||||
- Missing `gh` CLI (fallback to manual)
|
||||
- Lint/format integration enabled
|
||||
- Multiple interrupted runs (selection UI)
|
||||
@@ -0,0 +1,534 @@
|
||||
# Phase 3: Extensibility + Guardrails - Autonomous TDD Workflow
|
||||
|
||||
## Objective
|
||||
Add multi-language/framework support, enhanced safety guardrails, TUI interface, and extensibility for IDE/editor integration.
|
||||
|
||||
## Scope
|
||||
- Multi-language test runner support (pytest, go test, etc.)
|
||||
- Enhanced safety: diff preview, confirmation gates, minimal-change prompts
|
||||
- Optional TUI panel with tmux integration
|
||||
- State-based extension API for IDE integration
|
||||
- Parallel subtask execution (experimental)
|
||||
|
||||
## Deliverables
|
||||
|
||||
### 1. Multi-Language Test Runner Support
|
||||
|
||||
**Extend TestRunnerAdapter:**
|
||||
```typescript
|
||||
class TestRunnerAdapter {
|
||||
// Existing methods...
|
||||
|
||||
async detectLanguage(): Promise<Language>
|
||||
async detectFramework(language: Language): Promise<Framework>
|
||||
async getFrameworkAdapter(framework: Framework): Promise<FrameworkAdapter>
|
||||
}
|
||||
|
||||
enum Language {
|
||||
JavaScript = 'javascript',
|
||||
TypeScript = 'typescript',
|
||||
Python = 'python',
|
||||
Go = 'go',
|
||||
Rust = 'rust'
|
||||
}
|
||||
|
||||
enum Framework {
|
||||
Vitest = 'vitest',
|
||||
Jest = 'jest',
|
||||
Pytest = 'pytest',
|
||||
GoTest = 'gotest',
|
||||
CargoTest = 'cargotest'
|
||||
}
|
||||
|
||||
interface FrameworkAdapter {
|
||||
runTargeted(pattern: string): Promise<TestResults>
|
||||
runAll(): Promise<TestResults>
|
||||
parseCoverage(output: string): Promise<CoverageReport>
|
||||
getTestFilePattern(): string
|
||||
getTestFileExtension(): string
|
||||
}
|
||||
```
|
||||
|
||||
**Framework-specific adapters:**
|
||||
|
||||
**PytestAdapter** (`packages/tm-core/src/services/test-adapters/pytest-adapter.ts`):
|
||||
```typescript
|
||||
class PytestAdapter implements FrameworkAdapter {
|
||||
async runTargeted(pattern: string): Promise<TestResults> {
|
||||
const output = await exec(`pytest ${pattern} --json-report`)
|
||||
return this.parseResults(output)
|
||||
}
|
||||
|
||||
async runAll(): Promise<TestResults> {
|
||||
const output = await exec('pytest --cov --json-report')
|
||||
return this.parseResults(output)
|
||||
}
|
||||
|
||||
parseCoverage(output: string): Promise<CoverageReport> {
|
||||
// Parse pytest-cov XML output
|
||||
}
|
||||
|
||||
getTestFilePattern(): string {
|
||||
return '**/test_*.py'
|
||||
}
|
||||
|
||||
getTestFileExtension(): string {
|
||||
return '.py'
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**GoTestAdapter** (`packages/tm-core/src/services/test-adapters/gotest-adapter.ts`):
|
||||
```typescript
|
||||
class GoTestAdapter implements FrameworkAdapter {
|
||||
async runTargeted(pattern: string): Promise<TestResults> {
|
||||
const output = await exec(`go test ${pattern} -json`)
|
||||
return this.parseResults(output)
|
||||
}
|
||||
|
||||
async runAll(): Promise<TestResults> {
|
||||
const output = await exec('go test ./... -coverprofile=coverage.out -json')
|
||||
return this.parseResults(output)
|
||||
}
|
||||
|
||||
parseCoverage(output: string): Promise<CoverageReport> {
|
||||
// Parse go test coverage output
|
||||
}
|
||||
|
||||
getTestFilePattern(): string {
|
||||
return '**/*_test.go'
|
||||
}
|
||||
|
||||
getTestFileExtension(): string {
|
||||
return '_test.go'
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Detection Logic:**
|
||||
```typescript
|
||||
async function detectFramework(): Promise<Framework> {
|
||||
// Check for package.json
|
||||
if (await exists('package.json')) {
|
||||
const pkg = await readJSON('package.json')
|
||||
if (pkg.devDependencies?.vitest) return Framework.Vitest
|
||||
if (pkg.devDependencies?.jest) return Framework.Jest
|
||||
}
|
||||
|
||||
// Check for Python files
|
||||
if (await exists('pytest.ini') || await exists('setup.py')) {
|
||||
return Framework.Pytest
|
||||
}
|
||||
|
||||
// Check for Go files
|
||||
if (await exists('go.mod')) {
|
||||
return Framework.GoTest
|
||||
}
|
||||
|
||||
// Check for Rust files
|
||||
if (await exists('Cargo.toml')) {
|
||||
return Framework.CargoTest
|
||||
}
|
||||
|
||||
throw new Error('Could not detect test framework')
|
||||
}
|
||||
```
|
||||
|
||||
### 2. Enhanced Safety Guardrails
|
||||
|
||||
**Diff Preview Mode:**
|
||||
```bash
|
||||
$ tm autopilot 42 --preview-diffs
|
||||
|
||||
[2/3] Subtask 42.2: Add collection endpoint
|
||||
|
||||
RED ✓ Tests created: src/api/__tests__/metrics.test.js
|
||||
|
||||
GREEN Implementing code...
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
Proposed changes (src/api/metrics.js):
|
||||
|
||||
+ import { MetricsSchema } from '../models/schema.js'
|
||||
+
|
||||
+ export async function createMetric(data) {
|
||||
+ const validated = MetricsSchema.parse(data)
|
||||
+ const result = await db.metrics.create(validated)
|
||||
+ return result
|
||||
+ }
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
Apply these changes? [Y/n/e(dit)/s(kip)]
|
||||
Y - Apply and continue
|
||||
n - Reject and retry GREEN phase
|
||||
e - Open in editor for manual changes
|
||||
s - Skip this subtask
|
||||
```
|
||||
|
||||
**Minimal Change Enforcement:**
|
||||
|
||||
Add to system prompt:
|
||||
```markdown
|
||||
CRITICAL: Make MINIMAL changes to pass the failing tests.
|
||||
- Only modify files directly related to the subtask
|
||||
- Do not refactor existing code unless absolutely necessary
|
||||
- Do not add features beyond the acceptance criteria
|
||||
- Keep changes under 50 lines per file when possible
|
||||
- Prefer composition over modification
|
||||
```
|
||||
|
||||
**Change Size Warnings:**
|
||||
```bash
|
||||
⚠️ Large change detected:
|
||||
Files modified: 5
|
||||
Lines changed: +234, -12
|
||||
|
||||
This subtask was expected to be small (~50 lines).
|
||||
Consider:
|
||||
- Breaking into smaller subtasks
|
||||
- Reviewing acceptance criteria
|
||||
- Checking for unintended changes
|
||||
|
||||
Continue anyway? [y/N]
|
||||
```
|
||||
|
||||
### 3. TUI Interface with tmux
|
||||
|
||||
**Layout:**
|
||||
```
|
||||
┌──────────────────────────────────┬─────────────────────────────────┐
|
||||
│ Task Navigator (left) │ Executor Terminal (right) │
|
||||
│ │ │
|
||||
│ Project: my-app │ $ tm autopilot --executor-mode │
|
||||
│ Branch: analytics/task-42 │ > Running subtask 42.2 GREEN... │
|
||||
│ Tag: analytics │ > Implementing endpoint... │
|
||||
│ │ > Tests: 3 passed, 0 failed │
|
||||
│ Tasks: │ > Ready to commit │
|
||||
│ → 42 [in-progress] User metrics │ │
|
||||
│ → 42.1 [done] Schema │ [Live output from executor] │
|
||||
│ → 42.2 [active] Endpoint ◀ │ │
|
||||
│ → 42.3 [pending] Dashboard │ │
|
||||
│ │ │
|
||||
│ [s] start [p] pause [q] quit │ │
|
||||
└──────────────────────────────────┴─────────────────────────────────┘
|
||||
```
|
||||
|
||||
**Implementation:**
|
||||
|
||||
**TUI Navigator** (`apps/cli/src/ui/tui/navigator.ts`):
|
||||
```typescript
|
||||
import blessed from 'blessed'
|
||||
|
||||
class AutopilotTUI {
|
||||
private screen: blessed.Widgets.Screen
|
||||
private taskList: blessed.Widgets.ListElement
|
||||
private statusBox: blessed.Widgets.BoxElement
|
||||
private executorPane: string // tmux pane ID
|
||||
|
||||
async start(taskId?: string) {
|
||||
// Create blessed screen
|
||||
this.screen = blessed.screen()
|
||||
|
||||
// Create task list widget
|
||||
this.taskList = blessed.list({
|
||||
label: 'Tasks',
|
||||
keys: true,
|
||||
vi: true,
|
||||
style: { selected: { bg: 'blue' } }
|
||||
})
|
||||
|
||||
// Spawn tmux pane for executor
|
||||
this.executorPane = await this.spawnExecutorPane()
|
||||
|
||||
// Watch state file for updates
|
||||
this.watchStateFile()
|
||||
|
||||
// Handle keybindings
|
||||
this.setupKeybindings()
|
||||
}
|
||||
|
||||
private async spawnExecutorPane(): Promise<string> {
|
||||
const paneId = await exec('tmux split-window -h -P -F "#{pane_id}"')
|
||||
await exec(`tmux send-keys -t ${paneId} "tm autopilot --executor-mode" Enter`)
|
||||
return paneId.trim()
|
||||
}
|
||||
|
||||
private watchStateFile() {
|
||||
watch('.taskmaster/state/current-run.json', (event, filename) => {
|
||||
this.updateDisplay()
|
||||
})
|
||||
}
|
||||
|
||||
private setupKeybindings() {
|
||||
this.screen.key(['s'], () => this.startTask())
|
||||
this.screen.key(['p'], () => this.pauseTask())
|
||||
this.screen.key(['q'], () => this.quit())
|
||||
this.screen.key(['up', 'down'], () => this.navigateTasks())
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Executor Mode:**
|
||||
```bash
|
||||
$ tm autopilot 42 --executor-mode
|
||||
|
||||
# Runs in executor pane, writes state to shared file
|
||||
# Left pane reads state file and updates display
|
||||
```
|
||||
|
||||
**State File** (`.taskmaster/state/current-run.json`):
|
||||
```json
|
||||
{
|
||||
"runId": "2025-01-15-142033",
|
||||
"taskId": "42",
|
||||
"status": "running",
|
||||
"currentPhase": "green",
|
||||
"currentSubtask": "42.2",
|
||||
"lastOutput": "Implementing endpoint...",
|
||||
"testsStatus": {
|
||||
"passed": 3,
|
||||
"failed": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 4. Extension API for IDE Integration
|
||||
|
||||
**State-based API:**
|
||||
|
||||
Expose run state via JSON files that IDEs can read:
|
||||
- `.taskmaster/state/current-run.json` - live run state
|
||||
- `.taskmaster/reports/runs/<runId>/manifest.json` - run metadata
|
||||
- `.taskmaster/reports/runs/<runId>/log.jsonl` - event stream
|
||||
|
||||
**WebSocket API (optional):**
|
||||
```typescript
|
||||
// packages/tm-core/src/services/autopilot-server.ts
|
||||
class AutopilotServer {
|
||||
private wss: WebSocketServer
|
||||
|
||||
start(port: number = 7890) {
|
||||
this.wss = new WebSocketServer({ port })
|
||||
|
||||
this.wss.on('connection', (ws) => {
|
||||
// Send current state
|
||||
ws.send(JSON.stringify(this.getCurrentState()))
|
||||
|
||||
// Stream events
|
||||
this.orchestrator.on('*', (event) => {
|
||||
ws.send(JSON.stringify(event))
|
||||
})
|
||||
})
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Usage from IDE extension:**
|
||||
```typescript
|
||||
// VS Code extension example
|
||||
const ws = new WebSocket('ws://localhost:7890')
|
||||
|
||||
ws.on('message', (data) => {
|
||||
const event = JSON.parse(data)
|
||||
|
||||
if (event.type === 'subtask:complete') {
|
||||
vscode.window.showInformationMessage(
|
||||
`Subtask ${event.subtaskId} completed`
|
||||
)
|
||||
}
|
||||
})
|
||||
```
|
||||
|
||||
### 5. Parallel Subtask Execution (Experimental)
|
||||
|
||||
**Dependency Analysis:**
|
||||
```typescript
|
||||
class SubtaskScheduler {
|
||||
async buildDependencyGraph(subtasks: Subtask[]): Promise<DAG> {
|
||||
const graph = new DAG()
|
||||
|
||||
for (const subtask of subtasks) {
|
||||
graph.addNode(subtask.id)
|
||||
|
||||
for (const depId of subtask.dependencies) {
|
||||
graph.addEdge(depId, subtask.id)
|
||||
}
|
||||
}
|
||||
|
||||
return graph
|
||||
}
|
||||
|
||||
async getParallelBatches(graph: DAG): Promise<Subtask[][]> {
|
||||
const batches: Subtask[][] = []
|
||||
const completed = new Set<string>()
|
||||
|
||||
while (completed.size < graph.size()) {
|
||||
const ready = graph.nodes.filter(node =>
|
||||
!completed.has(node.id) &&
|
||||
node.dependencies.every(dep => completed.has(dep))
|
||||
)
|
||||
|
||||
batches.push(ready)
|
||||
ready.forEach(node => completed.add(node.id))
|
||||
}
|
||||
|
||||
return batches
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Parallel Execution:**
|
||||
```bash
|
||||
$ tm autopilot 42 --parallel
|
||||
|
||||
[Batch 1] Running 2 subtasks in parallel:
|
||||
→ 42.1: Add metrics schema
|
||||
→ 42.4: Add API documentation
|
||||
|
||||
42.1 RED ✓ Tests created
|
||||
42.4 RED ✓ Tests created
|
||||
|
||||
42.1 GREEN ✓ Implementation complete
|
||||
42.4 GREEN ✓ Implementation complete
|
||||
|
||||
42.1 COMMIT ✓ Committed: a1b2c3d
|
||||
42.4 COMMIT ✓ Committed: e5f6g7h
|
||||
|
||||
[Batch 2] Running 2 subtasks in parallel (depend on 42.1):
|
||||
→ 42.2: Add collection endpoint
|
||||
→ 42.3: Add dashboard widget
|
||||
...
|
||||
```
|
||||
|
||||
**Conflict Detection:**
|
||||
```typescript
|
||||
async function detectConflicts(subtasks: Subtask[]): Promise<Conflict[]> {
|
||||
const conflicts: Conflict[] = []
|
||||
|
||||
for (let i = 0; i < subtasks.length; i++) {
|
||||
for (let j = i + 1; j < subtasks.length; j++) {
|
||||
const filesA = await predictAffectedFiles(subtasks[i])
|
||||
const filesB = await predictAffectedFiles(subtasks[j])
|
||||
|
||||
const overlap = filesA.filter(f => filesB.includes(f))
|
||||
|
||||
if (overlap.length > 0) {
|
||||
conflicts.push({
|
||||
subtasks: [subtasks[i].id, subtasks[j].id],
|
||||
files: overlap
|
||||
})
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
return conflicts
|
||||
}
|
||||
```
|
||||
|
||||
### 6. Advanced Configuration
|
||||
|
||||
**Add to `.taskmaster/config.json`:**
|
||||
```json
|
||||
{
|
||||
"autopilot": {
|
||||
"safety": {
|
||||
"previewDiffs": false,
|
||||
"maxChangeLinesPerFile": 100,
|
||||
"warnOnLargeChanges": true,
|
||||
"requireConfirmOnLargeChanges": true
|
||||
},
|
||||
"parallel": {
|
||||
"enabled": false,
|
||||
"maxConcurrent": 3,
|
||||
"detectConflicts": true
|
||||
},
|
||||
"tui": {
|
||||
"enabled": false,
|
||||
"tmuxSession": "taskmaster-autopilot"
|
||||
},
|
||||
"api": {
|
||||
"enabled": false,
|
||||
"port": 7890,
|
||||
"allowRemote": false
|
||||
}
|
||||
},
|
||||
"test": {
|
||||
"frameworks": {
|
||||
"python": {
|
||||
"runner": "pytest",
|
||||
"coverageCommand": "pytest --cov",
|
||||
"testPattern": "**/test_*.py"
|
||||
},
|
||||
"go": {
|
||||
"runner": "go test",
|
||||
"coverageCommand": "go test ./... -coverprofile=coverage.out",
|
||||
"testPattern": "**/*_test.go"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## CLI Updates
|
||||
|
||||
**New commands:**
|
||||
```bash
|
||||
tm autopilot <taskId> --tui # Launch TUI interface
|
||||
tm autopilot <taskId> --parallel # Enable parallel execution
|
||||
tm autopilot <taskId> --preview-diffs # Show diffs before applying
|
||||
tm autopilot <taskId> --executor-mode # Run as executor pane
|
||||
tm autopilot-server start # Start WebSocket API
|
||||
```
|
||||
|
||||
## Success Criteria
|
||||
- Supports Python projects with pytest
|
||||
- Supports Go projects with go test
|
||||
- Diff preview prevents unwanted changes
|
||||
- TUI provides better visibility for long-running tasks
|
||||
- IDE extensions can integrate via state files or WebSocket
|
||||
- Parallel execution reduces total time for independent subtasks
|
||||
|
||||
## Out of Scope
|
||||
- Full Electron/web GUI
|
||||
- AI executor selection UI (defer to Phase 4)
|
||||
- Multi-repository support
|
||||
- Remote execution on cloud runners
|
||||
|
||||
## Testing Strategy
|
||||
- Test with Python project (pytest)
|
||||
- Test with Go project (go test)
|
||||
- Test diff preview UI with mock changes
|
||||
- Test parallel execution with independent subtasks
|
||||
- Test conflict detection with overlapping file changes
|
||||
- Test TUI with mock tmux environment
|
||||
|
||||
## Dependencies
|
||||
- Phase 2 completed (PR + resumability)
|
||||
- tmux installed (for TUI)
|
||||
- blessed or ink library (for TUI rendering)
|
||||
|
||||
## Estimated Effort
|
||||
3-4 weeks
|
||||
|
||||
## Risks & Mitigations
|
||||
- **Risk:** Parallel execution causes git conflicts
|
||||
- **Mitigation:** Conservative conflict detection, sequential fallback
|
||||
|
||||
- **Risk:** TUI adds complexity and maintenance burden
|
||||
- **Mitigation:** Keep TUI optional, state-based design allows alternatives
|
||||
|
||||
- **Risk:** Framework adapters hard to maintain across versions
|
||||
- **Mitigation:** Abstract common parsing logic, document adapter interface
|
||||
|
||||
- **Risk:** Diff preview slows down workflow
|
||||
- **Mitigation:** Make optional, use --preview-diffs flag only when needed
|
||||
|
||||
## Validation
|
||||
Test with:
|
||||
- Python project with pytest and pytest-cov
|
||||
- Go project with go test
|
||||
- Large changes requiring confirmation
|
||||
- Parallel execution with 3+ independent subtasks
|
||||
- TUI with task selection and live status updates
|
||||
- VS Code extension reading state files
|
||||
@@ -0,0 +1,93 @@
|
||||
{
|
||||
"meta": {
|
||||
"generatedAt": "2025-10-07T14:16:40.283Z",
|
||||
"tasksAnalyzed": 10,
|
||||
"totalTasks": 10,
|
||||
"analysisCount": 10,
|
||||
"thresholdScore": 5,
|
||||
"projectName": "Taskmaster",
|
||||
"usedResearch": false
|
||||
},
|
||||
"complexityAnalysis": [
|
||||
{
|
||||
"taskId": 1,
|
||||
"taskTitle": "Create autopilot command CLI skeleton",
|
||||
"complexityScore": 4,
|
||||
"recommendedSubtasks": 3,
|
||||
"expansionPrompt": "Break down the autopilot command creation into: 1) Create AutopilotCommand class extending Commander.Command with proper argument parsing and options, 2) Implement command structure with help text and validation following existing patterns, 3) Add basic registration method and placeholder action handler",
|
||||
"reasoning": "Medium complexity due to following established patterns in the codebase. The command-registry.ts and start.command.ts provide clear templates for implementation. Main complexity is argument parsing and option validation."
|
||||
},
|
||||
{
|
||||
"taskId": 2,
|
||||
"taskTitle": "Implement preflight detection system",
|
||||
"complexityScore": 7,
|
||||
"recommendedSubtasks": 5,
|
||||
"expansionPrompt": "Create PreflightChecker with these subtasks: 1) Package.json test script detection and validation, 2) Git working tree status checking using system commands, 3) Tool availability validation (git, gh, node/npm), 4) Default branch detection via git commands, 5) Structured result reporting with success/failure indicators and error messages",
|
||||
"reasoning": "High complexity due to system integration requirements. Needs to interact with multiple external tools (git, npm, gh), parse various file formats, and handle different system configurations. Error handling for missing tools adds complexity."
|
||||
},
|
||||
{
|
||||
"taskId": 3,
|
||||
"taskTitle": "Implement task loading and validation",
|
||||
"complexityScore": 5,
|
||||
"recommendedSubtasks": 3,
|
||||
"expansionPrompt": "Implement task loading: 1) Use existing TaskService from @tm/core to load tasks by ID with proper error handling, 2) Validate task structure including subtask existence and dependency validation, 3) Provide user-friendly error messages for missing tasks or need to expand subtasks first",
|
||||
"reasoning": "Medium-high complexity. While leveraging existing TaskService reduces implementation effort, the validation logic for subtasks and dependencies requires careful handling of edge cases. Task structure validation adds complexity."
|
||||
},
|
||||
{
|
||||
"taskId": 4,
|
||||
"taskTitle": "Create execution plan display logic",
|
||||
"complexityScore": 6,
|
||||
"recommendedSubtasks": 4,
|
||||
"expansionPrompt": "Build ExecutionPlanDisplay: 1) Create display formatter using boxen and chalk for consistent CLI styling, 2) Format preflight check results with color-coded status indicators, 3) Display subtask execution order with RED/GREEN/COMMIT phase visualization, 4) Show branch/tag info and finalization steps with duration estimates",
|
||||
"reasoning": "Moderate-high complexity due to complex formatting requirements and dependency on multiple other components. The display needs to coordinate information from preflight, task validation, and execution planning. CLI styling consistency adds complexity."
|
||||
},
|
||||
{
|
||||
"taskId": 5,
|
||||
"taskTitle": "Implement branch and tag planning",
|
||||
"complexityScore": 3,
|
||||
"recommendedSubtasks": 2,
|
||||
"expansionPrompt": "Create BranchPlanner: 1) Implement branch name generation using pattern <tag>/task-<id>-<slug> with kebab-case conversion and special character handling, 2) Add TaskMaster config integration to determine active tag and handle existing branch conflicts",
|
||||
"reasoning": "Low-medium complexity. String manipulation and naming convention implementation is straightforward. The main complexity is handling edge cases with special characters and existing branch conflicts."
|
||||
},
|
||||
{
|
||||
"taskId": 6,
|
||||
"taskTitle": "Create subtask execution order calculation",
|
||||
"complexityScore": 8,
|
||||
"recommendedSubtasks": 4,
|
||||
"expansionPrompt": "Implement dependency resolution: 1) Build dependency graph from subtask data with proper parsing, 2) Implement topological sort algorithm for execution order, 3) Add circular dependency detection with clear error reporting, 4) Create parallel execution grouping for independent subtasks",
|
||||
"reasoning": "High complexity due to graph algorithms and dependency resolution. Topological sorting, circular dependency detection, and parallel grouping require algorithmic sophistication. Edge cases in dependency chains add significant complexity."
|
||||
},
|
||||
{
|
||||
"taskId": 7,
|
||||
"taskTitle": "Implement TDD phase planning for subtasks",
|
||||
"complexityScore": 6,
|
||||
"recommendedSubtasks": 4,
|
||||
"expansionPrompt": "Create TDDPhasePlanner: 1) Implement test file path detection for common project structures (src/, tests/, __tests__), 2) Parse implementation files from subtask details and descriptions, 3) Generate conventional commit messages for RED/GREEN/COMMIT phases, 4) Add implementation complexity estimation based on subtask content",
|
||||
"reasoning": "Moderate-high complexity due to project structure detection and file path inference. Conventional commit message generation and complexity estimation require understanding of different project layouts and parsing subtask content effectively."
|
||||
},
|
||||
{
|
||||
"taskId": 8,
|
||||
"taskTitle": "Add finalization steps planning",
|
||||
"complexityScore": 4,
|
||||
"recommendedSubtasks": 3,
|
||||
"expansionPrompt": "Create FinalizationPlanner: 1) Implement test suite execution planning with coverage threshold detection from package.json, 2) Add git operations planning (branch push, PR creation) using existing git patterns, 3) Create duration estimation algorithm based on subtask count and complexity metrics",
|
||||
"reasoning": "Medium complexity. Building on existing git utilities and test command detection reduces complexity. Main challenges are coverage threshold parsing and duration estimation algorithms."
|
||||
},
|
||||
{
|
||||
"taskId": 9,
|
||||
"taskTitle": "Integrate command with existing CLI infrastructure",
|
||||
"complexityScore": 3,
|
||||
"recommendedSubtasks": 2,
|
||||
"expansionPrompt": "Complete CLI integration: 1) Add AutopilotCommand to command-registry.ts following existing patterns and update command metadata, 2) Test command registration and help system integration with proper cleanup and error handling",
|
||||
"reasoning": "Low-medium complexity. The command-registry.ts provides a clear pattern to follow. Main work is registration and ensuring proper integration with existing CLI infrastructure. Well-established patterns reduce complexity."
|
||||
},
|
||||
{
|
||||
"taskId": 10,
|
||||
"taskTitle": "Add comprehensive error handling and edge cases",
|
||||
"complexityScore": 7,
|
||||
"recommendedSubtasks": 5,
|
||||
"expansionPrompt": "Implement error handling: 1) Add missing task and invalid task structure error handling with helpful messages, 2) Handle git state errors (dirty working tree, missing tools), 3) Add dependency validation errors (circular, invalid references), 4) Implement missing tool detection with installation guidance, 5) Create user-friendly error messages following existing CLI patterns",
|
||||
"reasoning": "High complexity due to comprehensive error scenarios. Each component (preflight, task loading, dependency resolution) has multiple failure modes that need proper handling. Providing helpful error messages and recovery suggestions adds complexity."
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -1,9 +1,9 @@
|
||||
{
|
||||
"currentTag": "autonomous-tdd-git-workflow",
|
||||
"lastSwitched": "2025-09-30T13:32:48.187Z",
|
||||
"branchTagMapping": {
|
||||
"v017-adds": "v017-adds",
|
||||
"next": "next"
|
||||
},
|
||||
"migrationNoticeShown": true
|
||||
}
|
||||
"currentTag": "tdd-workflow-phase-0",
|
||||
"lastSwitched": "2025-10-07T14:11:48.167Z",
|
||||
"branchTagMapping": {
|
||||
"v017-adds": "v017-adds",
|
||||
"next": "next"
|
||||
},
|
||||
"migrationNoticeShown": true
|
||||
}
|
||||
@@ -9379,5 +9379,700 @@
|
||||
"updated": "2025-10-06T17:44:07.207Z",
|
||||
"description": "Tasks for autonomous-tdd-git-workflow context"
|
||||
}
|
||||
},
|
||||
"tdd-workflow-phase-0": {
|
||||
"tasks": [
|
||||
{
|
||||
"id": 1,
|
||||
"title": "Create autopilot command CLI skeleton",
|
||||
"description": "Create the basic CLI command structure for tm autopilot with dry-run mode support and argument parsing",
|
||||
"details": "Create apps/cli/src/commands/autopilot.command.ts extending Commander's Command class pattern like existing commands. Support tm autopilot <taskId> with --dry-run flag. Include basic help text, argument validation, and command registration. Follow the existing StartCommand pattern for consistency with the codebase.",
|
||||
"testStrategy": "Unit tests for command parsing, argument validation, and help text display. Test both with and without task ID argument.",
|
||||
"priority": "high",
|
||||
"dependencies": [],
|
||||
"status": "pending",
|
||||
"subtasks": [
|
||||
{
|
||||
"id": 1,
|
||||
"title": "Create autopilot command file structure",
|
||||
"description": "Create the basic autopilot.command.ts file with Commander class extension and basic structure",
|
||||
"dependencies": [],
|
||||
"details": "Create apps/cli/src/commands/autopilot.command.ts extending Commander's Command class. Set up basic class structure with constructor, command name 'autopilot', description, and empty execute method. Follow the pattern used in existing commands like StartCommand for consistency.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for command instantiation and basic structure validation"
|
||||
},
|
||||
{
|
||||
"id": 2,
|
||||
"title": "Implement argument parsing and validation",
|
||||
"description": "Add task ID argument parsing and --dry-run flag support with validation",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Add task ID as required positional argument with validation to ensure it exists in tasks.json. Implement --dry-run boolean flag with proper Commander.js syntax. Add argument validation logic to check task ID format and existence. Include error handling for invalid inputs.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for argument parsing with valid/invalid task IDs and flag combinations"
|
||||
},
|
||||
{
|
||||
"id": 3,
|
||||
"title": "Add help text and command documentation",
|
||||
"description": "Implement comprehensive help text, usage examples, and command documentation",
|
||||
"dependencies": [
|
||||
2
|
||||
],
|
||||
"details": "Add detailed command description, usage examples showing 'tm autopilot <taskId>' and 'tm autopilot <taskId> --dry-run'. Include examples with real task IDs, explain dry-run mode behavior, and provide troubleshooting tips. Follow help text patterns from existing commands.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for help text display and content validation"
|
||||
},
|
||||
{
|
||||
"id": 4,
|
||||
"title": "Implement command registration system",
|
||||
"description": "Register the autopilot command with the CLI application and ensure proper integration",
|
||||
"dependencies": [
|
||||
3
|
||||
],
|
||||
"details": "Add autopilot command registration to the main CLI application in apps/cli/src/index.ts or appropriate registration file. Ensure command is properly exported and available when running 'tm autopilot'. Follow existing command registration patterns used by other commands.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Integration tests for command registration and CLI availability"
|
||||
},
|
||||
{
|
||||
"id": 5,
|
||||
"title": "Create basic execute method with dry-run logic",
|
||||
"description": "Implement the main execute method with basic dry-run mode and task loading logic",
|
||||
"dependencies": [
|
||||
4
|
||||
],
|
||||
"details": "Implement the execute method that loads the specified task from tasks.json, validates task existence, and handles dry-run mode by displaying what would be executed without performing actions. Add basic task loading using existing task utilities and prepare structure for future autopilot logic.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for execute method with valid tasks and dry-run mode behavior"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": 2,
|
||||
"title": "Implement preflight detection system",
|
||||
"description": "Build system to detect test runner, git state, and validate required tools for autopilot execution",
|
||||
"details": "Create a PreflightChecker class that: 1) Detects test command from package.json scripts.test field, 2) Checks git working tree status using existing git-utils.js, 3) Validates availability of git, gh, node/npm tools, 4) Detects default branch. Return structured status for each check with success/failure indicators.",
|
||||
"testStrategy": "Unit tests for each detection method. Integration tests with different package.json configurations and git states.",
|
||||
"priority": "high",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"status": "pending",
|
||||
"subtasks": [
|
||||
{
|
||||
"id": 1,
|
||||
"title": "Create PreflightChecker class structure and package.json test detection",
|
||||
"description": "Implement the core PreflightChecker class with method to detect test command from package.json scripts.test field",
|
||||
"dependencies": [],
|
||||
"details": "Create src/autopilot/preflight-checker.js with PreflightChecker class. Implement detectTestCommand() method that reads package.json and extracts scripts.test field. Handle cases where package.json doesn't exist or scripts.test is undefined. Return structured result with success/failure status and detected command. Follow existing patterns from other service classes in the codebase.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for detectTestCommand() with various package.json configurations: missing file, missing scripts, missing test script, valid test script. Mock fs.readFileSync for different scenarios."
|
||||
},
|
||||
{
|
||||
"id": 2,
|
||||
"title": "Implement git state validation using existing git-utils",
|
||||
"description": "Add git working tree status checks using the existing git-utils.js module functions",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Add checkGitWorkingTree() method to PreflightChecker that uses existing functions from scripts/modules/utils/git-utils.js. Use isGitRepository() to verify git repo, then check for uncommitted changes using git status. Return structured status indicating if working tree is clean, has staged changes, or has unstaged changes. Include helpful messages about what needs to be committed.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests with mocked git-utils functions for different git states: clean working tree, staged changes, unstaged changes, not a git repository. Integration tests with actual git repository setup."
|
||||
},
|
||||
{
|
||||
"id": 3,
|
||||
"title": "Add tool availability validation for required commands",
|
||||
"description": "Implement validation for git, gh, node/npm tool availability on the system",
|
||||
"dependencies": [
|
||||
2
|
||||
],
|
||||
"details": "Add validateRequiredTools() method that checks availability of git, gh CLI, node, and npm commands using execSync with 'which' or 'where' depending on platform. Handle platform differences (Unix vs Windows). Return structured results for each tool with version information where available. Use existing isGhCliAvailable() function from git-utils for gh CLI checking.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests mocking execSync for different scenarios: all tools available, missing tools, platform differences. Test version detection and error handling for command execution failures."
|
||||
},
|
||||
{
|
||||
"id": 4,
|
||||
"title": "Implement default branch detection",
|
||||
"description": "Add default branch detection using existing git-utils functions",
|
||||
"dependencies": [
|
||||
3
|
||||
],
|
||||
"details": "Add detectDefaultBranch() method that uses getDefaultBranch() function from existing git-utils.js. Handle cases where default branch cannot be determined and provide fallback logic. Return structured result with detected branch name and confidence level. Include handling for repositories without remote tracking.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests mocking git-utils getDefaultBranch() for various scenarios: GitHub repo with default branch, local repo without remote, repositories with different default branches (main vs master)."
|
||||
},
|
||||
{
|
||||
"id": 5,
|
||||
"title": "Create comprehensive preflight check orchestration and result formatting",
|
||||
"description": "Implement main runAllChecks() method that orchestrates all preflight checks and formats results",
|
||||
"dependencies": [
|
||||
4
|
||||
],
|
||||
"details": "Add runAllChecks() method that executes all preflight checks in sequence: detectTestCommand(), checkGitWorkingTree(), validateRequiredTools(), detectDefaultBranch(). Collect all results into structured PreflightResult object with overall success status, individual check results, and actionable error messages. Include summary of what passed/failed and next steps for resolving issues.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Integration tests running full preflight checks in different project configurations. Test error aggregation and result formatting. Verify that partial failures are handled gracefully with appropriate user guidance."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": 3,
|
||||
"title": "Implement task loading and validation",
|
||||
"description": "Load task data from TaskMaster state and validate task structure for autopilot execution",
|
||||
"details": "Use existing TaskService from @tm/core to load task by ID. Validate task exists, has subtasks, and subtasks have proper dependency order. If no subtasks exist, provide helpful message about needing to expand first. Reuse existing task loading patterns from other commands.",
|
||||
"testStrategy": "Unit tests for task loading with various scenarios: valid task with subtasks, task without subtasks, non-existent task, tasks with dependencies.",
|
||||
"priority": "medium",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"status": "pending",
|
||||
"subtasks": [
|
||||
{
|
||||
"id": 1,
|
||||
"title": "Create TaskLoadingService class with TaskService integration",
|
||||
"description": "Create a service class that wraps TaskService from @tm/core to load task data and handle initialization properly",
|
||||
"dependencies": [],
|
||||
"details": "Create TaskLoadingService that instantiates TaskService with ConfigManager, handles initialization, and provides methods for loading tasks by ID. Include proper error handling for cases where TaskService fails to initialize or tasks cannot be loaded. Follow existing patterns from tm-core for service instantiation.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for service initialization, task loading success cases, and error handling for initialization failures"
|
||||
},
|
||||
{
|
||||
"id": 2,
|
||||
"title": "Implement task existence validation logic",
|
||||
"description": "Build validation to check if a task exists and has the proper structure for autopilot execution",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Create validation functions that check: 1) Task exists in TaskMaster state, 2) Task has valid structure according to Task interface from @tm/core types, 3) Task is not in 'done' or 'cancelled' status. Return structured validation results with specific error messages for each validation failure.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests with various task scenarios: valid tasks, non-existent tasks, malformed tasks, completed tasks"
|
||||
},
|
||||
{
|
||||
"id": 3,
|
||||
"title": "Create subtask validation and dependency analysis",
|
||||
"description": "Implement validation for subtask structure and dependency ordering for autopilot execution readiness",
|
||||
"dependencies": [
|
||||
2
|
||||
],
|
||||
"details": "Build validation logic that: 1) Checks if task has subtasks defined, 2) Validates subtask structure matches Subtask interface, 3) Analyzes dependency order to ensure subtasks can be executed sequentially, 4) Identifies any circular dependencies or missing dependencies. Provide detailed feedback on dependency issues.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for tasks with valid subtasks, tasks without subtasks, tasks with circular dependencies, and tasks with missing dependencies"
|
||||
},
|
||||
{
|
||||
"id": 4,
|
||||
"title": "Implement helpful expansion messaging system",
|
||||
"description": "Create user-friendly messages when tasks lack subtasks and guide users toward expansion commands",
|
||||
"dependencies": [
|
||||
3
|
||||
],
|
||||
"details": "When validation detects tasks without subtasks, provide helpful messages explaining: 1) Why subtasks are needed for autopilot, 2) How to use 'task-master expand' to create subtasks, 3) Link to existing task expansion patterns from other commands. Include suggestions for complexity analysis if the task appears complex.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for message generation with different task scenarios and integration tests to verify messaging appears correctly"
|
||||
},
|
||||
{
|
||||
"id": 5,
|
||||
"title": "Create comprehensive validation result interface and error handling",
|
||||
"description": "Design and implement structured validation results with detailed error reporting for all validation scenarios",
|
||||
"dependencies": [
|
||||
4
|
||||
],
|
||||
"details": "Create ValidationResult interface that includes: 1) Success/failure status, 2) Specific error types (task not found, no subtasks, dependency issues), 3) Detailed error messages with actionable guidance, 4) Task data when validation succeeds. Implement error handling that provides clear feedback for each validation failure scenario.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for all validation result scenarios and integration tests to verify error handling provides helpful user feedback"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": 4,
|
||||
"title": "Create execution plan display logic",
|
||||
"description": "Build comprehensive display system for showing planned autopilot execution steps in dry-run mode",
|
||||
"details": "Create ExecutionPlanDisplay class that formats and displays: preflight check results, branch/tag information, subtask execution order with RED/GREEN/COMMIT phases, estimated duration, and finalization steps. Use boxen and chalk for consistent CLI styling matching existing command patterns.",
|
||||
"testStrategy": "Unit tests for display formatting with different task configurations. Visual regression tests for output formatting.",
|
||||
"priority": "medium",
|
||||
"dependencies": [
|
||||
2,
|
||||
3
|
||||
],
|
||||
"status": "pending",
|
||||
"subtasks": [
|
||||
{
|
||||
"id": 1,
|
||||
"title": "Create ExecutionPlanDisplay class structure",
|
||||
"description": "Create the base ExecutionPlanDisplay class with proper imports and basic structure following existing CLI patterns",
|
||||
"dependencies": [],
|
||||
"details": "Create src/display/ExecutionPlanDisplay.ts with class structure. Import boxen and chalk libraries. Set up constructor to accept execution plan data. Define private methods for each display section. Follow existing CLI styling patterns from other commands.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for class instantiation and basic structure validation"
|
||||
},
|
||||
{
|
||||
"id": 2,
|
||||
"title": "Implement preflight check results display",
|
||||
"description": "Add method to format and display preflight check results with appropriate styling and status indicators",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Implement displayPreflightChecks() method that formats check results using chalk for colored status indicators (green checkmarks, red X's). Use boxen for section containers. Display task validation, dependency checks, and branch status results.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for preflight display formatting with passing and failing checks"
|
||||
},
|
||||
{
|
||||
"id": 3,
|
||||
"title": "Implement branch and tag information display",
|
||||
"description": "Add method to display planned branch creation and tag information in a formatted section",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Implement displayBranchInfo() method that shows planned branch name, current tag, and branch creation strategy. Use consistent styling with other sections. Display branch existence warnings if applicable.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for branch info display with different tag configurations"
|
||||
},
|
||||
{
|
||||
"id": 4,
|
||||
"title": "Implement subtask execution order display with phases",
|
||||
"description": "Create comprehensive display for subtask execution order showing RED/GREEN/COMMIT phases for each subtask",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Implement displayExecutionOrder() method that shows ordered subtasks with phase indicators (RED: tests fail, GREEN: tests pass, COMMIT: changes committed). Use color coding and clear phase separation. Include dependency information and estimated duration per subtask.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for execution order display with various dependency patterns and phase transitions"
|
||||
},
|
||||
{
|
||||
"id": 5,
|
||||
"title": "Implement main display method and finalization steps",
|
||||
"description": "Create the main display() method that orchestrates all sections and shows finalization steps",
|
||||
"dependencies": [
|
||||
2,
|
||||
3,
|
||||
4
|
||||
],
|
||||
"details": "Implement main display() method that calls all section display methods in proper order. Add displayFinalizationSteps() for PR creation and cleanup steps. Include estimated total duration and final summary. Ensure consistent spacing and styling throughout.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Integration tests for complete display output and visual regression tests for CLI formatting"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": 5,
|
||||
"title": "Implement branch and tag planning",
|
||||
"description": "Generate branch names and tag settings that would be used during autopilot execution",
|
||||
"details": "Create BranchPlanner class that generates branch names following pattern: <tag>/task-<id>-<slug> where slug is kebab-case task title. Determine active tag from TaskMaster config. Show which tag would be set during execution. Handle edge cases like existing branches.",
|
||||
"testStrategy": "Unit tests for branch name generation with various task titles and tags. Test edge cases like special characters and long titles.",
|
||||
"priority": "low",
|
||||
"dependencies": [
|
||||
2
|
||||
],
|
||||
"status": "pending",
|
||||
"subtasks": [
|
||||
{
|
||||
"id": 1,
|
||||
"title": "Create BranchPlanner class with basic structure",
|
||||
"description": "Create the BranchPlanner class with constructor and main method signatures to establish the foundation for branch name generation",
|
||||
"dependencies": [],
|
||||
"details": "Create src/commands/autopilot/branch-planner.js with BranchPlanner class. Include constructor that accepts TaskMaster config and task data. Define main method planBranch() that will return branch name and tag information. Set up basic error handling structure.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for class instantiation and basic method structure"
|
||||
},
|
||||
{
|
||||
"id": 2,
|
||||
"title": "Implement task title to kebab-case slug conversion",
|
||||
"description": "Create utility function to convert task titles into kebab-case slugs suitable for branch names",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Implement convertToKebabCase() method that handles special characters, spaces, and length limits. Remove non-alphanumeric characters except hyphens, convert to lowercase, and truncate to reasonable length (e.g., 50 chars). Handle edge cases like empty titles or titles with only special characters.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests with various task title formats including special characters, long titles, and edge cases"
|
||||
},
|
||||
{
|
||||
"id": 3,
|
||||
"title": "Implement branch name generation logic",
|
||||
"description": "Create the core logic to generate branch names following the pattern <tag>/task-<id>-<slug>",
|
||||
"dependencies": [
|
||||
2
|
||||
],
|
||||
"details": "Implement generateBranchName() method that combines active tag from TaskMaster config, task ID, and kebab-case slug. Format as 'tag/task-id-slug'. Handle cases where tag is undefined or empty by using 'feature' as default. Validate generated names against git branch naming rules.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for branch name generation with different tags, task IDs, and slugs"
|
||||
},
|
||||
{
|
||||
"id": 4,
|
||||
"title": "Add active tag detection from TaskMaster config",
|
||||
"description": "Implement logic to determine the active tag from TaskMaster configuration state",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Create getActiveTag() method that reads from TaskMaster state.json to determine current active tag. Use existing TaskService patterns to access configuration. Handle cases where no tag is set or config is missing. Return default tag 'feature' when no active tag is configured.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for tag detection with various config states including missing config and undefined tags"
|
||||
},
|
||||
{
|
||||
"id": 5,
|
||||
"title": "Implement existing branch conflict detection",
|
||||
"description": "Add logic to detect and handle cases where generated branch names already exist",
|
||||
"dependencies": [
|
||||
3,
|
||||
4
|
||||
],
|
||||
"details": "Create checkBranchExists() method using git-utils.js to check if generated branch name already exists locally or remotely. Implement conflict resolution by appending incremental numbers (e.g., -2, -3) to branch name. Provide warnings about existing branches in planning output.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for branch conflict detection and resolution with mocked git commands"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": 6,
|
||||
"title": "Create subtask execution order calculation",
|
||||
"description": "Calculate the correct execution order for subtasks based on their dependencies",
|
||||
"details": "Implement dependency resolution algorithm that: 1) Reads subtask dependencies from task data, 2) Creates execution order respecting dependencies, 3) Detects circular dependencies, 4) Groups independent subtasks. Return ordered list with dependency information for display.",
|
||||
"testStrategy": "Unit tests for dependency resolution with linear dependencies, parallel subtasks, and circular dependency detection.",
|
||||
"priority": "medium",
|
||||
"dependencies": [
|
||||
3
|
||||
],
|
||||
"status": "pending",
|
||||
"subtasks": [
|
||||
{
|
||||
"id": 1,
|
||||
"title": "Create DependencyResolver class with core algorithm",
|
||||
"description": "Implement the core dependency resolution algorithm that reads subtask dependencies and creates execution order",
|
||||
"dependencies": [],
|
||||
"details": "Create src/utils/dependency-resolver.ts with DependencyResolver class. Implement topological sort algorithm that takes subtasks array and returns ordered execution plan. Handle basic dependency chains and ensure tasks without dependencies can execute first. Include proper TypeScript interfaces for subtask data and execution order results.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for basic dependency resolution with linear chains, parallel independent subtasks, and empty dependency arrays"
|
||||
},
|
||||
{
|
||||
"id": 2,
|
||||
"title": "Implement circular dependency detection",
|
||||
"description": "Add circular dependency detection to prevent infinite loops in dependency resolution",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Extend DependencyResolver to detect circular dependencies using depth-first search with visit tracking. Throw descriptive error when circular dependencies are found, including the cycle path. Add validation before attempting topological sort to fail fast on invalid dependency graphs.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for various circular dependency scenarios: direct cycles (A→B→A), indirect cycles (A→B→C→A), and self-dependencies (A→A)"
|
||||
},
|
||||
{
|
||||
"id": 3,
|
||||
"title": "Add parallel subtask grouping functionality",
|
||||
"description": "Group independent subtasks that can be executed in parallel phases",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Implement parallelization logic that groups subtasks into execution phases. Subtasks with no dependencies or whose dependencies are satisfied in previous phases can execute in parallel. Return execution plan with phase information showing which subtasks can run simultaneously.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for parallel grouping with mixed dependency patterns, ensuring correct phase separation and parallel group identification"
|
||||
},
|
||||
{
|
||||
"id": 4,
|
||||
"title": "Create execution order display interfaces",
|
||||
"description": "Define TypeScript interfaces for execution order results and dependency information",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Create interfaces in types/ directory for ExecutionPlan, ExecutionPhase, and SubtaskDependencyInfo. Include fields for subtask ID, dependencies status, execution phase, and parallel group information. Ensure interfaces support both display formatting and autopilot execution needs.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Type checking tests and interface validation with sample data structures matching real subtask scenarios"
|
||||
},
|
||||
{
|
||||
"id": 5,
|
||||
"title": "Integrate with TaskService and add CLI utilities",
|
||||
"description": "Integrate DependencyResolver with existing TaskService and create utility functions for CLI display",
|
||||
"dependencies": [
|
||||
1,
|
||||
2,
|
||||
3,
|
||||
4
|
||||
],
|
||||
"details": "Add calculateSubtaskExecutionOrder method to TaskService that uses DependencyResolver. Create UI utilities in apps/cli/src/utils/ui.ts for formatting execution order display with chalk colors and dependency status indicators. Follow existing patterns for task loading and error handling.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Integration tests with TaskService loading real task data, and visual tests for CLI display formatting with various dependency scenarios"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": 7,
|
||||
"title": "Implement TDD phase planning for subtasks",
|
||||
"description": "Plan RED/GREEN/COMMIT phases for each subtask showing test files and implementation files",
|
||||
"details": "Create TDDPhasePlanner that for each subtask: 1) Determines test file paths based on project structure, 2) Identifies implementation files from subtask details, 3) Generates commit messages following conventional commits format, 4) Estimates implementation complexity. Support common project structures (src/, tests/, __tests__).",
|
||||
"testStrategy": "Unit tests for file path generation with different project structures. Test commit message generation following conventional commits.",
|
||||
"priority": "medium",
|
||||
"dependencies": [
|
||||
6
|
||||
],
|
||||
"status": "pending",
|
||||
"subtasks": [
|
||||
{
|
||||
"id": 1,
|
||||
"title": "Create TDDPhasePlanner class structure",
|
||||
"description": "Design and implement the core TDDPhasePlanner class that handles phase planning for TDD workflow execution",
|
||||
"dependencies": [],
|
||||
"details": "Create a new TDDPhasePlanner class in src/tdd/ directory with methods for: 1) Analyzing subtask data to extract implementation files, 2) Determining appropriate test file paths based on project structure, 3) Generating conventional commit messages, 4) Estimating complexity. The class should accept subtask data and project configuration as inputs.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for class instantiation and method existence. Mock subtask data to verify the class can be initialized properly."
|
||||
},
|
||||
{
|
||||
"id": 2,
|
||||
"title": "Implement test file path detection logic",
|
||||
"description": "Build logic to detect and generate appropriate test file paths based on common project structures",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Implement method to analyze project structure and determine test file paths for implementation files. Support common patterns: src/ with tests/, src/ with __tests__/, src/ with .test.js files alongside source, and packages/*/src with packages/*/tests. Use filesystem operations to check existing patterns and generate consistent test file paths.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests with mock filesystem structures testing various project layouts (Jest, Vitest, Node.js patterns). Verify correct test file paths are generated for different source file locations."
|
||||
},
|
||||
{
|
||||
"id": 3,
|
||||
"title": "Implement implementation file extraction from subtask details",
|
||||
"description": "Parse subtask details and descriptions to identify implementation files that will be created or modified",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Create method to analyze subtask details text and extract file paths mentioned or implied. Use regex patterns and natural language processing to identify: file names mentioned directly, directory structures implied by descriptions, and component/class names that translate to file paths. Handle various file extensions (.js, .ts, .tsx, .vue, .py, etc.).",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests with various subtask detail examples. Test extraction accuracy with different description formats and file types. Verify edge cases like missing file paths or ambiguous descriptions."
|
||||
},
|
||||
{
|
||||
"id": 4,
|
||||
"title": "Implement conventional commit message generation",
|
||||
"description": "Generate properly formatted conventional commit messages for each TDD phase (RED/GREEN/COMMIT)",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Implement method to generate conventional commit messages following the format: type(scope): description. Support commit types: test (for RED phase), feat/fix (for GREEN phase), and refactor (for COMMIT phase). Extract scope from subtask context and generate descriptive messages. Follow the pattern seen in existing hooks: feat(task-<id>): <description>.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for commit message generation with various subtask types and scopes. Verify conventional commit format compliance and message clarity."
|
||||
},
|
||||
{
|
||||
"id": 5,
|
||||
"title": "Implement complexity estimation and phase organization",
|
||||
"description": "Estimate implementation complexity and organize the three TDD phases (RED/GREEN/COMMIT) with appropriate metadata",
|
||||
"dependencies": [
|
||||
2,
|
||||
3,
|
||||
4
|
||||
],
|
||||
"details": "Create method to estimate implementation complexity based on: number of files involved, description length and complexity keywords, dependencies between subtasks. Organize the output into three distinct phases: RED (test creation), GREEN (implementation), COMMIT (cleanup/refactor). Include estimated time, file lists, and commit messages for each phase.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for complexity calculation with various subtask scenarios. Integration tests verifying complete phase planning output includes all required metadata and follows TDD workflow structure."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": 8,
|
||||
"title": "Add finalization steps planning",
|
||||
"description": "Plan the final steps that would be executed after all subtasks complete",
|
||||
"details": "Create FinalizationPlanner that shows: 1) Full test suite execution with coverage threshold detection, 2) Branch push confirmation, 3) PR creation targeting detected default branch, 4) Duration estimation based on subtask count and complexity. Use existing git-utils.js for git operations planning.",
|
||||
"testStrategy": "Unit tests for finalization step generation. Test coverage threshold detection from package.json or config files.",
|
||||
"priority": "low",
|
||||
"dependencies": [
|
||||
2,
|
||||
6
|
||||
],
|
||||
"status": "pending",
|
||||
"subtasks": [
|
||||
{
|
||||
"id": 1,
|
||||
"title": "Create FinalizationPlanner class structure",
|
||||
"description": "Create the basic FinalizationPlanner class with interface definition and core methods for planning finalization steps",
|
||||
"dependencies": [],
|
||||
"details": "Create a new FinalizationPlanner class that will handle planning final steps after subtask completion. Include interface definitions for finalization steps (test execution, branch push, PR creation, duration estimation) and basic class structure with methods for each planning component. The class should accept subtask data and project context as input.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for class instantiation and method structure. Test interface definitions and basic method signatures."
|
||||
},
|
||||
{
|
||||
"id": 2,
|
||||
"title": "Implement test suite execution planning with coverage detection",
|
||||
"description": "Add functionality to detect test commands and coverage thresholds from package.json and project configuration",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Implement test command detection by reading package.json scripts for 'test', 'test:coverage', 'test:ci' commands. Parse coverage configuration from package.json, jest.config.js, vitest.config.js, or other config files to detect coverage thresholds. Generate execution plan showing which test command would be run and expected coverage requirements. Handle projects without test commands gracefully.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for package.json parsing, config file detection, and coverage threshold extraction. Test with various project structures (Jest, Vitest, no tests)."
|
||||
},
|
||||
{
|
||||
"id": 3,
|
||||
"title": "Add git operations planning using existing git-utils",
|
||||
"description": "Integrate with git-utils.js to plan branch push confirmation and default branch detection for PR targeting",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Use existing git-utils.js functions like getDefaultBranch(), getCurrentBranch(), and isGhCliAvailable() to plan git operations. Generate branch push confirmation plan showing current branch and target remote. Detect default branch for PR creation planning. Check if gh CLI is available for PR operations. Plan git status checks and dirty working tree warnings.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for git-utils integration, branch detection, and gh CLI availability checking. Mock git-utils functions to test various git states."
|
||||
},
|
||||
{
|
||||
"id": 4,
|
||||
"title": "Implement PR creation planning",
|
||||
"description": "Plan PR creation steps including title generation, body template, and target branch detection",
|
||||
"dependencies": [
|
||||
3
|
||||
],
|
||||
"details": "Generate PR creation plan that includes conventional commit-style title generation based on subtask changes, PR body template with task/subtask references, target branch detection using git-utils, and gh CLI command planning. Include checks for existing PR detection and conflict resolution. Plan PR description formatting with task context and implementation notes.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for PR title generation, body template creation, and gh CLI command planning. Test with various task types and subtask combinations."
|
||||
},
|
||||
{
|
||||
"id": 5,
|
||||
"title": "Add duration estimation based on subtask complexity",
|
||||
"description": "Implement duration estimation algorithm that calculates expected completion time based on subtask count and complexity",
|
||||
"dependencies": [
|
||||
2,
|
||||
3,
|
||||
4
|
||||
],
|
||||
"details": "Create duration estimation algorithm that factors in number of subtasks, complexity indicators (file count, test coverage requirements, git operations), and historical patterns. Provide time estimates for each finalization step (testing, git operations, PR creation) and total completion time. Include confidence intervals and factors that might affect duration. Format estimates in human-readable time units.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for duration calculation algorithms, complexity analysis, and time formatting. Test with various subtask configurations and complexity scenarios."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": 9,
|
||||
"title": "Integrate command with existing CLI infrastructure",
|
||||
"description": "Register autopilot command with the main CLI and ensure proper integration with command registry",
|
||||
"details": "Update apps/cli/src/command-registry.ts to include AutopilotCommand. Follow existing patterns for command registration. Ensure proper cleanup and error handling. Update CLI help system to include autopilot command documentation.",
|
||||
"testStrategy": "Integration tests for command registration. Test CLI help includes autopilot command. Test error handling and cleanup.",
|
||||
"priority": "medium",
|
||||
"dependencies": [
|
||||
1,
|
||||
4
|
||||
],
|
||||
"status": "pending",
|
||||
"subtasks": [
|
||||
{
|
||||
"id": 1,
|
||||
"title": "Create AutopilotCommand class file",
|
||||
"description": "Create the AutopilotCommand class file following the existing command pattern used by StartCommand",
|
||||
"dependencies": [],
|
||||
"details": "Create apps/cli/src/commands/autopilot.command.ts with basic class structure extending Commander's Command class. Include constructor, command configuration, and placeholder action method. Follow the exact pattern from StartCommand including imports, error handling, and class structure.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for class instantiation and basic command configuration"
|
||||
},
|
||||
{
|
||||
"id": 2,
|
||||
"title": "Add AutopilotCommand import to command-registry.ts",
|
||||
"description": "Import the AutopilotCommand class in the command registry imports section",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Add import statement for AutopilotCommand in apps/cli/src/command-registry.ts following the existing import pattern. Place it in the appropriate position with other command imports maintaining alphabetical order.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Verify import resolves correctly and doesn't break existing imports"
|
||||
},
|
||||
{
|
||||
"id": 3,
|
||||
"title": "Register autopilot command in CommandRegistry",
|
||||
"description": "Add autopilot command metadata to the CommandRegistry.commands array",
|
||||
"dependencies": [
|
||||
2
|
||||
],
|
||||
"details": "Add autopilot command entry to the commands array in CommandRegistry class. Use 'development' category, provide appropriate description, and reference AutopilotCommand class. Follow the existing pattern with name, description, commandClass, and category fields.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests to verify command is registered and appears in registry listing"
|
||||
},
|
||||
{
|
||||
"id": 4,
|
||||
"title": "Export AutopilotCommand from index.ts",
|
||||
"description": "Add AutopilotCommand export to the main CLI package index file",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Add AutopilotCommand export to apps/cli/src/index.ts in the Commands section following the existing export pattern. Ensure it's properly exported for external usage and testing.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Verify export is available and can be imported from @tm/cli package"
|
||||
},
|
||||
{
|
||||
"id": 5,
|
||||
"title": "Update CLI help system for autopilot command",
|
||||
"description": "Ensure autopilot command appears in help output and command listing",
|
||||
"dependencies": [
|
||||
3
|
||||
],
|
||||
"details": "Verify that the autopilot command appears in the CLI help system through the CommandRegistry.getFormattedCommandList() method. The 'development' category should be included in help output with autopilot command listed. Test help display functionality.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Integration tests for help system displaying autopilot command. Test CLI help output includes autopilot in development category."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": 10,
|
||||
"title": "Add comprehensive error handling and edge cases",
|
||||
"description": "Implement robust error handling for all failure scenarios and edge cases in autopilot dry-run",
|
||||
"details": "Handle scenarios: missing task, task without subtasks, dirty git working tree, missing tools (git, gh, node), invalid dependencies, circular dependencies, no test command detected. Provide helpful error messages and suggestions for resolution. Use existing error patterns from other commands.",
|
||||
"testStrategy": "Unit tests for each error scenario. Integration tests with various invalid configurations. Test error message clarity and helpfulness.",
|
||||
"priority": "high",
|
||||
"dependencies": [
|
||||
1,
|
||||
2,
|
||||
3
|
||||
],
|
||||
"status": "pending",
|
||||
"subtasks": [
|
||||
{
|
||||
"id": 1,
|
||||
"title": "Implement git and working tree validation",
|
||||
"description": "Add error handling for git repository validation, dirty working tree detection, and missing git tool",
|
||||
"dependencies": [],
|
||||
"details": "Create validation functions to check if current directory is a git repository, detect dirty working tree status using git-utils.js patterns, and verify git CLI tool availability. Return specific error messages for each failure case with helpful suggestions for resolution.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for git validation with mocked git states. Test clean/dirty working tree detection and missing git tool scenarios."
|
||||
},
|
||||
{
|
||||
"id": 2,
|
||||
"title": "Add task and dependency validation error handling",
|
||||
"description": "Implement error detection for missing tasks, tasks without subtasks, invalid dependencies, and circular dependency cycles",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Create TaskValidator class that checks task existence in tasks.json, validates task has subtasks for autopilot execution, detects invalid dependency references, and identifies circular dependency chains. Use existing dependency validation patterns from other commands.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for each validation scenario with mock task data. Test circular dependency detection with various dependency graphs."
|
||||
},
|
||||
{
|
||||
"id": 3,
|
||||
"title": "Implement tool availability validation",
|
||||
"description": "Add error handling for missing required tools like gh CLI, node, and npm with helpful installation guidance",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Create ToolValidator that checks availability of gh CLI, node, npm, and other required tools using spawn or which-like detection. Provide specific error messages with installation instructions for each missing tool based on the user's platform.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for tool detection with mocked command availability. Test error messages for different missing tool combinations."
|
||||
},
|
||||
{
|
||||
"id": 4,
|
||||
"title": "Add test command detection error handling",
|
||||
"description": "Implement error handling when no test command is detected in package.json with suggestions for configuration",
|
||||
"dependencies": [
|
||||
2
|
||||
],
|
||||
"details": "Extend PreflightChecker to handle cases where package.json is missing, has no scripts section, or no test script defined. Provide helpful error messages suggesting common test script configurations and link to documentation for test setup.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Unit tests for various package.json configurations. Test error messages for missing test scripts and invalid package.json files."
|
||||
},
|
||||
{
|
||||
"id": 5,
|
||||
"title": "Create comprehensive error reporting system",
|
||||
"description": "Build unified error reporting that aggregates all validation failures and provides actionable resolution steps",
|
||||
"dependencies": [
|
||||
1,
|
||||
2,
|
||||
3,
|
||||
4
|
||||
],
|
||||
"details": "Create ErrorReporter class that collects all validation errors, formats them with clear descriptions and resolution steps, and provides a summary of required actions before autopilot can run. Follow existing error formatting patterns from other TaskMaster commands.",
|
||||
"status": "pending",
|
||||
"testStrategy": "Integration tests combining multiple error scenarios. Test error message clarity and formatting. Verify all error types are properly handled and reported."
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"created": "2025-10-07T14:08:52.047Z",
|
||||
"updated": "2025-10-07T14:13:46.675Z",
|
||||
"description": "Tasks for tdd-workflow-phase-0 context"
|
||||
}
|
||||
}
|
||||
}
|
||||
420
docs/contributor-docs/worktree-setup.md
Normal file
420
docs/contributor-docs/worktree-setup.md
Normal file
@@ -0,0 +1,420 @@
|
||||
# Git Worktree Setup for Parallel Development
|
||||
|
||||
Simple git worktree setup for running multiple AI coding assistants in parallel.
|
||||
|
||||
## Why Worktrees?
|
||||
|
||||
Instead of Docker complexity, use git worktrees to create isolated working directories:
|
||||
|
||||
✅ **Editor Agnostic** - Works with Cursor, Windsurf, VS Code, Claude Code, etc.
|
||||
✅ **Simple** - No Docker, no containers, just git
|
||||
✅ **Fast** - Instant setup, shared git history
|
||||
✅ **Flexible** - Each worktree can be on a different branch
|
||||
✅ **Task Master Works** - Full access to `.taskmaster/` in each worktree
|
||||
|
||||
## Quick Start
|
||||
|
||||
### 1. Create a Worktree
|
||||
|
||||
```bash
|
||||
# Using current branch as base
|
||||
./scripts/create-worktree.sh
|
||||
|
||||
# Or specify a branch name
|
||||
./scripts/create-worktree.sh feature/my-feature
|
||||
```
|
||||
|
||||
This creates a worktree in `../claude-task-master-worktrees/<branch-name>/`
|
||||
|
||||
### 2. Open in Your Editor
|
||||
|
||||
```bash
|
||||
# Navigate to the worktree
|
||||
cd ../claude-task-master-worktrees/auto-main/ # (or whatever branch)
|
||||
|
||||
# Open with your preferred AI editor
|
||||
cursor . # Cursor
|
||||
code . # VS Code
|
||||
windsurf . # Windsurf
|
||||
claude # Claude Code CLI
|
||||
```
|
||||
|
||||
### 3. Work in Parallel
|
||||
|
||||
**Main directory** (where you are now):
|
||||
```bash
|
||||
# Keep working normally
|
||||
git checkout main
|
||||
cursor .
|
||||
```
|
||||
|
||||
**Worktree directory**:
|
||||
```bash
|
||||
cd ../claude-task-master-worktrees/auto-main/
|
||||
# Different files, different branch, same git repo
|
||||
claude
|
||||
```
|
||||
|
||||
## Usage Examples
|
||||
|
||||
### Example 1: Let Claude Work Autonomously
|
||||
|
||||
```bash
|
||||
# Create worktree
|
||||
./scripts/create-worktree.sh auto/taskmaster-work
|
||||
|
||||
# Navigate there
|
||||
cd ../claude-task-master-worktrees/auto-taskmaster-work/
|
||||
|
||||
# Start Claude
|
||||
claude
|
||||
|
||||
# In Claude session
|
||||
> Use task-master to get the next task and complete it
|
||||
```
|
||||
|
||||
**Meanwhile in your main directory:**
|
||||
```bash
|
||||
# You keep working normally
|
||||
cursor .
|
||||
# No conflicts!
|
||||
```
|
||||
|
||||
### Example 2: Multiple AI Assistants in Parallel
|
||||
|
||||
```bash
|
||||
# Create multiple worktrees
|
||||
./scripts/create-worktree.sh cursor/feature-a
|
||||
./scripts/create-worktree.sh claude/feature-b
|
||||
./scripts/create-worktree.sh windsurf/feature-c
|
||||
|
||||
# Terminal 1
|
||||
cd ../claude-task-master-worktrees/cursor-feature-a/
|
||||
cursor .
|
||||
|
||||
# Terminal 2
|
||||
cd ../claude-task-master-worktrees/claude-feature-b/
|
||||
claude
|
||||
|
||||
# Terminal 3
|
||||
cd ../claude-task-master-worktrees/windsurf-feature-c/
|
||||
windsurf .
|
||||
```
|
||||
|
||||
### Example 3: Test vs Implementation
|
||||
|
||||
```bash
|
||||
# Main directory: Write implementation
|
||||
cursor .
|
||||
|
||||
# Worktree: Have Claude write tests
|
||||
cd ../claude-task-master-worktrees/auto-main/
|
||||
claude -p "Write tests for the recent changes in the main branch"
|
||||
```
|
||||
|
||||
## How It Works
|
||||
|
||||
### Directory Structure
|
||||
|
||||
```
|
||||
/Volumes/Workspace/workspace/contrib/task-master/
|
||||
├── claude-task-master/ # Main directory (this one)
|
||||
│ ├── .git/ # Shared git repo
|
||||
│ ├── .taskmaster/ # Synced via git
|
||||
│ └── your code...
|
||||
│
|
||||
└── claude-task-master-worktrees/ # Worktrees directory
|
||||
├── auto-main/ # Worktree 1
|
||||
│ ├── .git -> (points to main .git)
|
||||
│ ├── .taskmaster/ # Same tasks, synced
|
||||
│ └── your code... (on branch auto/main)
|
||||
│
|
||||
└── feature-x/ # Worktree 2
|
||||
├── .git -> (points to main .git)
|
||||
├── .taskmaster/
|
||||
└── your code... (on branch feature/x)
|
||||
```
|
||||
|
||||
### Shared Git Repository
|
||||
|
||||
All worktrees share the same `.git`:
|
||||
- Commits in one worktree are immediately visible in others
|
||||
- Branches are shared
|
||||
- Git history is shared
|
||||
- Only the working files differ
|
||||
|
||||
## Task Master in Worktrees
|
||||
|
||||
Task Master works perfectly in worktrees:
|
||||
|
||||
```bash
|
||||
# In any worktree
|
||||
task-master list # Same tasks
|
||||
task-master next # Same task queue
|
||||
task-master show 1.2 # Same task data
|
||||
|
||||
# Changes are shared (if committed/pushed)
|
||||
```
|
||||
|
||||
### Recommended Workflow
|
||||
|
||||
Use **tags** to separate task contexts:
|
||||
|
||||
```bash
|
||||
# Main directory - use default tag
|
||||
task-master list
|
||||
|
||||
# Worktree 1 - use separate tag
|
||||
cd ../claude-task-master-worktrees/auto-main/
|
||||
task-master add-tag --name=claude-auto
|
||||
task-master use-tag --name=claude-auto
|
||||
task-master list # Shows claude-auto tasks only
|
||||
```
|
||||
|
||||
## Managing Worktrees
|
||||
|
||||
### List All Worktrees
|
||||
|
||||
```bash
|
||||
./scripts/list-worktrees.sh
|
||||
|
||||
# Or directly with git
|
||||
git worktree list
|
||||
```
|
||||
|
||||
### Remove a Worktree
|
||||
|
||||
```bash
|
||||
# Remove specific worktree
|
||||
git worktree remove ../claude-task-master-worktrees/auto-main/
|
||||
|
||||
# Or if there are uncommitted changes, force it
|
||||
git worktree remove --force ../claude-task-master-worktrees/auto-main/
|
||||
```
|
||||
|
||||
### Sync Changes Between Worktrees
|
||||
|
||||
Changes are automatically synced through git:
|
||||
|
||||
```bash
|
||||
# In worktree
|
||||
git add .
|
||||
git commit -m "feat: implement feature"
|
||||
git push
|
||||
|
||||
# In main directory
|
||||
git pull
|
||||
# Changes are now available
|
||||
```
|
||||
|
||||
## Common Workflows
|
||||
|
||||
### 1. Autonomous Claude with Task Master
|
||||
|
||||
**Setup:**
|
||||
```bash
|
||||
./scripts/create-worktree.sh auto/claude-work
|
||||
cd ../claude-task-master-worktrees/auto-claude-work/
|
||||
```
|
||||
|
||||
**Run:**
|
||||
```bash
|
||||
# Copy the autonomous script
|
||||
cp ../claude-task-master/run-autonomous-tasks.sh .
|
||||
|
||||
# Run Claude autonomously
|
||||
./run-autonomous-tasks.sh
|
||||
```
|
||||
|
||||
**Monitor from main directory:**
|
||||
```bash
|
||||
# In another terminal, in main directory
|
||||
watch -n 5 "task-master list"
|
||||
```
|
||||
|
||||
### 2. Code Review Workflow
|
||||
|
||||
**Main directory:**
|
||||
```bash
|
||||
# You write code
|
||||
cursor .
|
||||
git add .
|
||||
git commit -m "feat: new feature"
|
||||
```
|
||||
|
||||
**Worktree:**
|
||||
```bash
|
||||
cd ../claude-task-master-worktrees/auto-main/
|
||||
git pull
|
||||
|
||||
# Have Claude review
|
||||
claude -p "Review the latest commit and suggest improvements"
|
||||
```
|
||||
|
||||
### 3. Parallel Feature Development
|
||||
|
||||
**Worktree 1 (Backend):**
|
||||
```bash
|
||||
./scripts/create-worktree.sh backend/api
|
||||
cd ../claude-task-master-worktrees/backend-api/
|
||||
cursor .
|
||||
# Work on API
|
||||
```
|
||||
|
||||
**Worktree 2 (Frontend):**
|
||||
```bash
|
||||
./scripts/create-worktree.sh frontend/ui
|
||||
cd ../claude-task-master-worktrees/frontend-ui/
|
||||
windsurf .
|
||||
# Work on UI
|
||||
```
|
||||
|
||||
**Main directory:**
|
||||
```bash
|
||||
# Monitor and merge
|
||||
git log --all --graph --oneline
|
||||
```
|
||||
|
||||
## Tips
|
||||
|
||||
### 1. Branch Naming Convention
|
||||
|
||||
Use prefixes to organize:
|
||||
- `auto/*` - For autonomous AI work
|
||||
- `cursor/*` - For Cursor-specific features
|
||||
- `claude/*` - For Claude-specific features
|
||||
- `review/*` - For code review worktrees
|
||||
|
||||
### 2. Commit Often in Worktrees
|
||||
|
||||
Worktrees make it easy to try things:
|
||||
```bash
|
||||
# In worktree
|
||||
git commit -m "experiment: trying approach X"
|
||||
# If it doesn't work, just delete the worktree
|
||||
git worktree remove .
|
||||
```
|
||||
|
||||
### 3. Use Different npm Dependencies
|
||||
|
||||
Each worktree can have different `node_modules`:
|
||||
```bash
|
||||
# Main directory
|
||||
npm install
|
||||
|
||||
# Worktree (different dependencies)
|
||||
cd ../claude-task-master-worktrees/auto-main/
|
||||
npm install
|
||||
# Installs independently
|
||||
```
|
||||
|
||||
### 4. .env Files
|
||||
|
||||
Each worktree can have its own `.env`:
|
||||
```bash
|
||||
# Main directory
|
||||
echo "API_URL=http://localhost:3000" > .env
|
||||
|
||||
# Worktree
|
||||
cd ../claude-task-master-worktrees/auto-main/
|
||||
echo "API_URL=http://localhost:4000" > .env
|
||||
# Different config!
|
||||
```
|
||||
|
||||
## Cleanup
|
||||
|
||||
### Remove All Worktrees
|
||||
|
||||
```bash
|
||||
# List and manually remove
|
||||
./scripts/list-worktrees.sh
|
||||
|
||||
# Remove each one
|
||||
git worktree remove ../claude-task-master-worktrees/auto-main/
|
||||
git worktree remove ../claude-task-master-worktrees/feature-x/
|
||||
|
||||
# Or remove all at once (careful!)
|
||||
rm -rf ../claude-task-master-worktrees/
|
||||
git worktree prune # Clean up git's worktree metadata
|
||||
```
|
||||
|
||||
### Delete Remote Branches
|
||||
|
||||
```bash
|
||||
# After merging/done with branches
|
||||
git branch -d auto/claude-work
|
||||
git push origin --delete auto/claude-work
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### "Cannot create worktree: already exists"
|
||||
|
||||
```bash
|
||||
# Remove the existing worktree first
|
||||
git worktree remove ../claude-task-master-worktrees/auto-main/
|
||||
```
|
||||
|
||||
### "Branch already checked out"
|
||||
|
||||
Git won't let you check out the same branch in multiple worktrees:
|
||||
```bash
|
||||
# Use a different branch name
|
||||
./scripts/create-worktree.sh auto/main-2
|
||||
```
|
||||
|
||||
### Changes Not Syncing
|
||||
|
||||
Worktrees don't auto-sync files. Use git:
|
||||
```bash
|
||||
# In worktree with changes
|
||||
git add .
|
||||
git commit -m "changes"
|
||||
git push
|
||||
|
||||
# In other worktree
|
||||
git pull
|
||||
```
|
||||
|
||||
### npm install Fails
|
||||
|
||||
Each worktree needs its own `node_modules`:
|
||||
```bash
|
||||
cd ../claude-task-master-worktrees/auto-main/
|
||||
npm install
|
||||
```
|
||||
|
||||
## Comparison to Docker
|
||||
|
||||
| Feature | Git Worktrees | Docker |
|
||||
|---------|---------------|--------|
|
||||
| Setup time | Instant | Minutes (build) |
|
||||
| Disk usage | Minimal (shared .git) | GBs per container |
|
||||
| Editor support | Native (any editor) | Limited (need special setup) |
|
||||
| File sync | Via git | Via volumes (can be slow) |
|
||||
| Resource usage | None (native) | RAM/CPU overhead |
|
||||
| Complexity | Simple (just git) | Complex (Dockerfile, compose, etc.) |
|
||||
| npm install | Per worktree | Per container |
|
||||
| AI editor support | ✅ All editors work | ⚠️ Need web-based or special config |
|
||||
|
||||
**TL;DR: Worktrees are simpler, faster, and more flexible for this use case.**
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
```bash
|
||||
# 1. Create worktree
|
||||
./scripts/create-worktree.sh auto/claude-work
|
||||
|
||||
# 2. Open in AI editor
|
||||
cd ../claude-task-master-worktrees/auto-claude-work/
|
||||
cursor . # or claude, windsurf, code, etc.
|
||||
|
||||
# 3. Work in parallel
|
||||
# Main directory: You work
|
||||
# Worktree: AI works
|
||||
# No conflicts!
|
||||
```
|
||||
|
||||
**Simple, fast, editor-agnostic.** 🚀
|
||||
58
scripts/create-worktree.sh
Executable file
58
scripts/create-worktree.sh
Executable file
@@ -0,0 +1,58 @@
|
||||
#!/bin/bash
|
||||
|
||||
# Create a git worktree for parallel Claude Code development
|
||||
# Usage: ./scripts/create-worktree.sh [branch-name]
|
||||
|
||||
set -e
|
||||
|
||||
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
||||
PROJECT_ROOT="$(cd "$SCRIPT_DIR/.." && pwd)"
|
||||
WORKTREES_DIR="$(cd "$PROJECT_ROOT/.." && pwd)/claude-task-master-worktrees"
|
||||
|
||||
# Get branch name (default to current branch with auto/ prefix)
|
||||
if [ -z "$1" ]; then
|
||||
CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
|
||||
BRANCH_NAME="auto/$CURRENT_BRANCH"
|
||||
echo "No branch specified, using: $BRANCH_NAME"
|
||||
else
|
||||
BRANCH_NAME="$1"
|
||||
fi
|
||||
|
||||
# Create worktrees directory if it doesn't exist
|
||||
mkdir -p "$WORKTREES_DIR"
|
||||
|
||||
# Sanitize branch name for directory (replace / with -)
|
||||
DIR_NAME=$(echo "$BRANCH_NAME" | sed 's/\//-/g')
|
||||
WORKTREE_PATH="$WORKTREES_DIR/$DIR_NAME"
|
||||
|
||||
echo "Creating git worktree..."
|
||||
echo " Branch: $BRANCH_NAME"
|
||||
echo " Path: $WORKTREE_PATH"
|
||||
|
||||
# Check if worktree already exists
|
||||
if [ -d "$WORKTREE_PATH" ]; then
|
||||
echo "❌ Worktree already exists at: $WORKTREE_PATH"
|
||||
echo " Remove it first with: git worktree remove $WORKTREE_PATH"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Create new branch and worktree
|
||||
git worktree add -b "$BRANCH_NAME" "$WORKTREE_PATH" 2>/dev/null || \
|
||||
git worktree add "$WORKTREE_PATH" "$BRANCH_NAME"
|
||||
|
||||
echo ""
|
||||
echo "✅ Worktree created successfully!"
|
||||
echo ""
|
||||
echo "📂 Location: $WORKTREE_PATH"
|
||||
echo "🌿 Branch: $BRANCH_NAME"
|
||||
echo ""
|
||||
echo "Next steps:"
|
||||
echo " 1. cd $WORKTREE_PATH"
|
||||
echo " 2. Open with your AI editor:"
|
||||
echo " - Cursor: cursor ."
|
||||
echo " - VS Code: code ."
|
||||
echo " - Windsurf: windsurf ."
|
||||
echo " - Claude Code: claude"
|
||||
echo ""
|
||||
echo "To remove this worktree later:"
|
||||
echo " git worktree remove $WORKTREE_PATH"
|
||||
15
scripts/list-worktrees.sh
Executable file
15
scripts/list-worktrees.sh
Executable file
@@ -0,0 +1,15 @@
|
||||
#!/bin/bash
|
||||
|
||||
# List all git worktrees with helpful information
|
||||
|
||||
set -e
|
||||
|
||||
echo "📋 Git Worktrees:"
|
||||
echo ""
|
||||
git worktree list
|
||||
echo ""
|
||||
echo "To remove a worktree:"
|
||||
echo " git worktree remove <path>"
|
||||
echo ""
|
||||
echo "To remove all worktrees:"
|
||||
echo " git worktree list | grep -v '(bare)' | tail -n +2 | awk '{print \$1}' | xargs -I {} git worktree remove {}"
|
||||
Reference in New Issue
Block a user