Phase 0: TDD Autopilot Dry-Run Foundation#1282
Phase 0: TDD Autopilot Dry-Run Foundation#1282Crunchyman-ralph merged 11 commits intoralph/feat/tdd.workflowfrom
Conversation
|
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughAdds an autonomous TDD "autopilot" CLI command and wiring, new tm-core services (PreflightChecker, TaskLoaderService), comprehensive git utilities and re-exports, documentation and reports for an orchestrator-based workflow, updated taskmaster state/config, a hardened create-worktree script, and CI config cleanup. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor User
participant CLI as AutopilotCommand
participant Core as tm-core (orchestrator)
participant PF as PreflightChecker
participant GU as GitUtils
participant TL as TaskLoaderService
participant MCP as Executor (MCP/Claude/etc.)
User->>CLI: tm autopilot <taskId> [--dry-run]
CLI->>Core: createTaskMasterCore()
CLI->>PF: runAllChecks()
PF->>GU: detect repo, default branch, tool checks
GU-->>PF: git/gh/tool results
PF-->>CLI: PreflightResult
CLI->>TL: loadAndValidateTask(taskId)
TL->>TL: validate status, subtasks, dependencies
TL-->>CLI: TaskValidationResult
alt dry-run
CLI-->>User: present plan and checks (no execution)
else execute
CLI->>Core: startRun / getNextWorkUnit
Core->>MCP: provide WorkUnit/context
MCP-->>Core: WorkUnitResult
Core->>Core: persist run state / transition phase
Core-->>CLI: execution progress/results
end
CLI->>Core: cleanup()
CLI-->>User: final result
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
Comment |
Crunchyman-ralph
force-pushed
the
tdd-phase-0-implementation
branch
from
3b081a2 to
71f2f2f
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 17
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (22)
.taskmaster/config.json(2 hunks).taskmaster/docs/autonomous-tdd-git-workflow.md(1 hunks).taskmaster/docs/tdd-workflow-phase-0-spike.md(1 hunks).taskmaster/docs/tdd-workflow-phase-1-core-rails.md(1 hunks).taskmaster/docs/tdd-workflow-phase-1-orchestrator.md(1 hunks).taskmaster/docs/tdd-workflow-phase-2-pr-resumability.md(1 hunks).taskmaster/docs/tdd-workflow-phase-3-extensibility-guardrails.md(1 hunks).taskmaster/reports/task-complexity-report_autonomous-tdd-git-workflow.json(1 hunks).taskmaster/reports/task-complexity-report_tdd-workflow-phase-0.json(1 hunks).taskmaster/state.json(1 hunks)apps/cli/src/command-registry.ts(2 hunks)apps/cli/src/commands/autopilot.command.ts(1 hunks)apps/cli/src/index.ts(1 hunks)docs/contributor-docs/worktree-setup.md(1 hunks)packages/tm-core/src/index.ts(1 hunks)packages/tm-core/src/services/index.ts(1 hunks)packages/tm-core/src/services/preflight-checker.service.ts(1 hunks)packages/tm-core/src/services/task-loader.service.ts(1 hunks)packages/tm-core/src/utils/git-utils.ts(1 hunks)packages/tm-core/src/utils/index.ts(1 hunks)scripts/create-worktree.sh(1 hunks)scripts/list-worktrees.sh(1 hunks)
🧰 Additional context used
📓 Path-based instructions (3)
.taskmaster/config.json
📄 CodeRabbit inference engine (.cursor/rules/dev_workflow.mdc)
.taskmaster/config.json: Store Taskmaster configuration settings (AI model selections, parameters, logging level, default subtasks/priority, project name, etc.) in the.taskmaster/config.jsonfile located in the project root directory. Do not configure non-API key settings via environment variables.
Do not manually edit.taskmaster/config.jsonunless you are certain of the changes; use thetask-master modelscommand ormodelsMCP tool for configuration.
.taskmaster/config.json: Do not manually edit the .taskmaster/config.json file. Use the included commands either in the MCP or CLI format as needed. Always prioritize MCP tools when available and use the CLI as a fallback.
All other Taskmaster settings (model choice, max tokens, temperature, log level, custom endpoints) are managed in .taskmaster/config.json via the task-master models command or models MCP tool.
Do not manually edit the .taskmaster/config.json file; always use the provided CLI or MCP tools for configuration changes.
Files:
.taskmaster/config.json
.taskmaster/state.json
📄 CodeRabbit inference engine (.cursor/rules/dev_workflow.mdc)
Track Taskmaster's current tag context and migration status in
.taskmaster/state.json, which is automatically created and managed by the system.
Files:
.taskmaster/state.json
docs/**/*
📄 CodeRabbit inference engine (.cursor/rules/new_features.mdc)
Add feature documentation to '/docs' folder, include tagged system usage examples, update command reference documentation, and provide migration notes if relevant.
Files:
docs/contributor-docs/worktree-setup.md
🧠 Learnings (8)
📚 Learning: 2025-07-31T22:07:49.716Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-31T22:07:49.716Z
Learning: Applies to scripts/modules/commands.js : Export the registerCommands function and keep the CLI setup code clean and maintainable.
Applied to files:
apps/cli/src/index.tsapps/cli/src/command-registry.ts
📚 Learning: 2025-07-18T17:10:53.657Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/glossary.mdc:0-0
Timestamp: 2025-07-18T17:10:53.657Z
Learning: Guidelines for implementing and maintaining tests for Task Master CLI (tests.mdc).
Applied to files:
.taskmaster/docs/autonomous-tdd-git-workflow.md
📚 Learning: 2025-07-18T17:10:53.657Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/glossary.mdc:0-0
Timestamp: 2025-07-18T17:10:53.657Z
Learning: Guide for using Task Master to manage task-driven development workflows with tagged task lists support (dev_workflow.mdc).
Applied to files:
.taskmaster/docs/autonomous-tdd-git-workflow.md
📚 Learning: 2025-07-31T22:08:16.039Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/taskmaster.mdc:0-0
Timestamp: 2025-07-31T22:08:16.039Z
Learning: Applies to {.taskmaster/tasks/tasks.json,.taskmaster/reports/task-complexity-report.json,.taskmaster/docs/research/**} : Do not manually edit generated files such as .taskmaster/tasks/tasks.json, .taskmaster/reports/task-complexity-report.json, or files in .taskmaster/docs/research/. Always use Taskmaster commands to modify these files.
Applied to files:
.taskmaster/reports/task-complexity-report_tdd-workflow-phase-0.json
📚 Learning: 2025-09-24T15:12:12.658Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: assets/.windsurfrules:0-0
Timestamp: 2025-09-24T15:12:12.658Z
Learning: Use task-master complexity-report to view formatted complexity insights and recommendations
Applied to files:
.taskmaster/reports/task-complexity-report_tdd-workflow-phase-0.json
📚 Learning: 2025-09-24T15:12:12.658Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: assets/.windsurfrules:0-0
Timestamp: 2025-09-24T15:12:12.658Z
Learning: Analyze task complexity with task-master analyze-complexity --research and use results to plan breakdown
Applied to files:
.taskmaster/reports/task-complexity-report_tdd-workflow-phase-0.json
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Use AI to generate detailed subtasks within the current tag context, considering complexity analysis for subtask counts and ensuring proper IDs for newly created subtasks.
Applied to files:
.taskmaster/reports/task-complexity-report_tdd-workflow-phase-0.json
📚 Learning: 2025-07-18T17:10:12.881Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/dev_workflow.mdc:0-0
Timestamp: 2025-07-18T17:10:12.881Z
Learning: Applies to .taskmaster/state.json : Track Taskmaster's current tag context and migration status in `.taskmaster/state.json`, which is automatically created and managed by the system.
Applied to files:
.taskmaster/state.json
🧬 Code graph analysis (5)
apps/cli/src/commands/autopilot.command.ts (4)
apps/cli/src/index.ts (2)
AutopilotCommand(14-14)TaskMasterCore(40-40)packages/tm-core/src/index.ts (4)
TaskMasterCore(8-8)createTaskMasterCore(9-9)PreflightChecker(78-78)TaskLoaderService(79-79)packages/tm-core/src/services/preflight-checker.service.ts (1)
PreflightChecker(61-316)packages/tm-core/src/services/task-loader.service.ts (1)
TaskLoaderService(59-400)
apps/cli/src/command-registry.ts (2)
apps/cli/src/commands/autopilot.command.ts (1)
AutopilotCommand(38-435)apps/cli/src/index.ts (1)
AutopilotCommand(14-14)
packages/tm-core/src/utils/git-utils.ts (2)
packages/tm-core/src/utils/index.ts (15)
GitHubRepoInfo(32-32)isGitRepository(18-18)isGitRepositorySync(19-19)getCurrentBranch(20-20)getCurrentBranchSync(21-21)getLocalBranches(22-22)getRemoteBranches(23-23)isGhCliAvailable(24-24)getGitHubRepoInfo(25-25)getGitRepositoryRoot(26-26)getDefaultBranch(27-27)isOnDefaultBranch(28-28)insideGitWorkTree(29-29)sanitizeBranchNameForTag(30-30)isValidBranchForTag(31-31)scripts/modules/utils/git-utils.js (7)
stdout(342-345)repoInfo(230-230)commonDefaults(244-244)branches(245-245)defaultBranch(269-269)reservedBranches(169-169)sanitized(175-175)
packages/tm-core/src/services/preflight-checker.service.ts (2)
packages/tm-core/src/utils/git-utils.ts (3)
isGitRepository(23-34)isGhCliAvailable(145-155)getDefaultBranch(201-236)packages/tm-core/src/utils/index.ts (3)
isGitRepository(18-18)isGhCliAvailable(24-24)getDefaultBranch(27-27)
packages/tm-core/src/services/task-loader.service.ts (1)
packages/tm-core/src/types/index.ts (1)
Subtask(88-92)
🪛 GitHub Actions: CI
packages/tm-core/src/utils/git-utils.ts
[error] 145-151: Formatter would have printed content with corrected formatting. biome format detected formatting issues in git-utils.ts and reported 1 error. Please run 'npm run format-check' (or 'biome format .') to apply fixes.
🪛 markdownlint-cli2 (0.18.1)
.taskmaster/docs/tdd-workflow-phase-0-spike.md
3-3: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
6-6: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
11-11: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
19-19: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
25-25: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
31-31: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
43-43: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
96-96: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
102-102: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
109-109: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
115-115: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
120-120: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
123-123: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
.taskmaster/docs/tdd-workflow-phase-2-pr-resumability.md
3-3: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
6-6: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
19-19: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
44-44: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
44-44: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
107-107: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
112-112: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
128-128: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
142-142: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
162-162: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
185-185: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
198-198: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
223-223: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
240-240: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
261-261: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
317-317: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
353-353: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
384-384: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
391-391: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
397-397: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
404-404: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
409-409: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
412-412: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
425-425: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
.taskmaster/docs/tdd-workflow-phase-1-core-rails.md
3-3: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
8-8: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
11-11: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
30-30: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
39-39: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
51-51: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
154-154: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
154-154: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
182-182: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
229-229: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
250-250: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
256-256: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
262-262: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
268-268: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
274-274: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
280-280: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
286-286: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
294-294: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
355-355: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
361-361: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
364-364: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
docs/contributor-docs/worktree-setup.md
45-45: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
52-52: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
77-77: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
119-119: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
215-215: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
221-221: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
230-230: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
238-238: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
246-246: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
257-257: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
265-265: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
273-273: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
291-291: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
301-301: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
314-314: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
361-361: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
369-369: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
382-382: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
.taskmaster/docs/tdd-workflow-phase-3-extensibility-guardrails.md
3-3: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
6-6: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
18-18: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
55-55: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
82-82: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
109-109: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
140-140: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
172-172: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
182-182: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
199-199: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
199-199: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
220-220: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
273-273: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
281-281: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
306-306: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
328-328: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
346-346: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
382-382: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
405-405: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
432-432: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
476-476: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
484-484: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
492-492: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
498-498: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
506-506: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
511-511: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
514-514: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
527-527: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
🔇 Additional comments (30)
.taskmaster/docs/tdd-workflow-phase-1-orchestrator.md (1)
1-369: Strong, clear Phase 1 orchestrator planArchitecture, APIs, state machine, and persistence are well-scoped and consistent with Phase 0. LGTM.
.taskmaster/reports/task-complexity-report_tdd-workflow-phase-0.json (1)
1-93: Confirm this report is tool‑generated (do not hand‑edit)Per repo practices, reports under .taskmaster/reports should be generated via Taskmaster commands, not edited manually. Please confirm provenance (e.g., task-master analyze-complexity or complexity-report).
Based on learnings
.taskmaster/reports/task-complexity-report_autonomous-tdd-git-workflow.json (1)
1-196: Verify this complexity report was produced by Taskmaster CLIPlease confirm this artifact was generated (not hand-edited) using the sanctioned command (e.g., task-master analyze-complexity --research or complexity-report).
Based on learnings
.taskmaster/docs/autonomous-tdd-git-workflow.md (1)
1-912: Excellent comprehensive design documentation!This document provides a thorough blueprint for the autonomous TDD workflow, covering:
- Clear workflow phases and state transitions
- Detailed preflight checks and validation
- Configuration schema and environment variables
- Example traces for happy path and error recovery
- Design decisions with clear rationale
- Phased roadmap with scope boundaries
The orchestration model (lines 640-688) is particularly well thought out, separating state management from execution. The extensive examples and configuration schemas will serve as valuable references during implementation.
packages/tm-core/src/utils/git-utils.ts (6)
1-18: LGTM!The module header and GitHubRepoInfo interface are well-documented and align with gh CLI's JSON output format.
20-53: LGTM!Both
isGitRepositoryandisGitRepositorySyncfollow consistent error handling patterns:
- Proper input validation with clear error messages for the async variant
- Graceful fallback to false on errors
- Appropriate stdio handling in the sync variant
55-92: LGTM!Both getCurrentBranch functions handle errors gracefully by returning null, allowing callers to determine appropriate fallback behavior. Input validation is consistent with the async variant throwing and sync returning null.
94-140: LGTM!Both branch listing functions are well-implemented:
- Use
git branch --formatfor consistent output- Proper filtering of empty lines and HEAD references
- Remote branch function correctly strips the origin prefix
178-253: Excellent fallback strategy!The
getDefaultBranchfunction implements a robust three-tier detection strategy:
- GitHub CLI query (authoritative)
- Git symbolic-ref (reliable for repos with configured remotes)
- Common defaults fallback (main/master)
This ensures maximum compatibility across different repository configurations.
255-304: LGTM!The branch sanitization and validation functions are well-implemented:
sanitizeBranchNameForTag: Comprehensive sanitization with safe fallbackisValidBranchForTag: Proper validation including reserved branch checkinsideGitWorkTree: Simple and effective checkAll functions handle edge cases appropriately.
packages/tm-core/src/utils/index.ts (1)
16-33: LGTM!All git utility exports correctly match the definitions in git-utils.ts. The type export for
GitHubRepoInfois properly included.apps/cli/src/commands/autopilot.command.ts (10)
1-32: LGTM!The command structure follows Commander's native class pattern correctly. The interfaces provide clear type definitions for options and results. The fileoverview JSDoc appropriately describes this as a "thin presentation layer" over tm-core's functionality.
34-59: LGTM!The constructor properly configures the command using Commander's fluent API. The option naming follows CLI conventions (kebab-case for flags, camelCase for option properties).
61-117: LGTM!The main execution flow is well-structured:
- Early validation with clear error messages
- Progressive spinners for user feedback
- Proper error handling with spinner cleanup
- Result storage for programmatic access
The use of
process.exit(1)is appropriate for a CLI command on failure.
119-140: LGTM!Both validation methods are well-implemented:
validateOptions: Clear format validation with helpful error messagesvalidateTaskId: Appropriate regex pattern allowing numeric task IDs and subtask IDs (e.g., "1.2.3")
142-165: LGTM!The initialization and task loading methods follow good patterns:
- Lazy initialization of TaskMasterCore
- Graceful error handling with null returns
- Clear error when core is not initialized
167-192: LGTM!The task info display is user-friendly:
- Clear visual formatting with boxen
- Includes dry-run indicator
- Responsive width calculation
194-299: LGTM!The autopilot execution logic is well-structured:
- Proper separation of preflight checks and task validation
- Dynamic import to avoid circular dependencies
- Clear error handling at each stage
- Cleanup of resources (TaskLoaderService)
- Informative execution plan display with dependencies
- Clear distinction between dry-run and actual execution
The flow correctly implements the Phase 0 dry-run requirements without performing any actual operations.
301-385: LGTM!The display methods provide excellent user feedback:
- Clear visual indicators (✓/✗)
- Color-coded status (green/red)
- Formatted boxen output for results
- Both JSON and text formats supported
387-415: LGTM!Error handling is well-implemented:
- Supports both standard and custom error formats
- Conditional stack trace display (development/DEBUG)
- Result storage enables programmatic testing
417-435: LGTM!The cleanup and registration methods follow best practices:
- Proper resource cleanup with reference clearing
- Static registration method for easy integration
- Returns instance for potential chaining
.taskmaster/state.json (1)
2-3: LGTM!State file correctly updated to reflect the Phase 0 tag context ("tdd-workflow-phase-0") with an appropriate timestamp. This aligns with the PR's Phase 0 implementation scope.
Based on learnings: This file tracks Taskmaster's current tag context and is automatically managed by the system.
apps/cli/src/index.ts (1)
14-14: LGTM!AutopilotCommand export added correctly to the public CLI API, maintaining alphabetical order with other command exports.
apps/cli/src/command-registry.ts (2)
16-16: LGTM!AutopilotCommand import added correctly to support the new command registration.
67-72: LGTM!The autopilot command is properly registered in the command registry:
- Clear description
- Correct command class reference
- Appropriate category ('development')
- Follows the existing pattern used by other commands
packages/tm-core/src/index.ts (1)
76-85: Re-exports look correct and aligned with services index.Public surface expansion is consistent; no issues.
.taskmaster/docs/tdd-workflow-phase-1-core-rails.md (1)
115-117: File path inconsistency:.tsvs.service.ts.Doc references
workflow-orchestrator.ts, but elsewhere/types useworkflow-orchestrator.service.ts. Align the filename to avoid confusion.packages/tm-core/src/services/index.ts (1)
9-10: Service and type exports are correct.Type-only exports prevent runtime duplication; aligns with top-level re-exports.
Also applies to: 16-24
.taskmaster/docs/tdd-workflow-phase-2-pr-resumability.md (2)
52-92: Run report path conflicts with Phase 1 storage model.Phase 1 stores artifacts under
~/.taskmaster/projects/.../runs/..., but PR body references.taskmaster/reports/runs/{runId}/in-repo. Clarify whether Phase 2 switches to local storage or keep global with a symlink/export step; update paths and.gitignoreaccordingly.Also applies to: 86-92
162-176: Remove inconsistency note—docs are consistent. All occurrences usetm autopilot --resume; there is notm autopilot resumesubcommand in.taskmaster/docs.Likely an incorrect or invalid review comment.
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 7
♻️ Duplicate comments (2)
packages/tm-core/src/services/preflight-checker.service.ts (2)
159-165: Distinguish GH install vs auth to avoid mislabeling.Current check conflates presence with authentication; report installation separately (version) and message auth status.
- // Check gh CLI - const ghAvailable = await isGhCliAvailable(this.projectRoot); - tools.push({ - name: 'gh', - available: ghAvailable, - message: ghAvailable ? 'GitHub CLI available' : 'GitHub CLI not available' - }); + // Check gh CLI (installation + auth) + tools.push(await this.checkGhCli());Add this helper near checkTool():
private async checkGhCli(): Promise<ToolCheck> { try { const version = execSync('gh --version', { cwd: this.projectRoot, encoding: 'utf-8', stdio: 'pipe' }) .trim() .split('\n')[0]; const authed = await isGhCliAvailable(this.projectRoot); return { name: 'gh', available: true, version, message: authed ? 'GitHub CLI installed (authenticated)' : 'GitHub CLI installed (not authenticated)' }; } catch { return { name: 'gh', available: false, message: 'GitHub CLI not found' }; } }Based on learnings
167-171: Optionally enforce Node >= 18 (clearer preflight failure).Parse Node version and fail the check if major < 18.
- // Check node - tools.push(this.checkTool('node', ['--version'])); + // Check node (enforce >= 18) + const nodeTool = this.checkTool('node', ['--version']); + const major = Number((nodeTool.version ?? '').match(/^v?(\d+)/)?.[1] ?? 0); + if (nodeTool.available && major < 18) { + nodeTool.available = false; + nodeTool.message = `${nodeTool.version} found; Node >= 18 required`; + } + tools.push(nodeTool); // Check npm tools.push(this.checkTool('npm', ['--version']));Based on learnings
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
.taskmaster/state.json(1 hunks)packages/tm-core/src/services/preflight-checker.service.ts(1 hunks)packages/tm-core/src/utils/git-utils.ts(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-07-18T17:10:12.881Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/dev_workflow.mdc:0-0
Timestamp: 2025-07-18T17:10:12.881Z
Learning: Applies to .taskmaster/state.json : Track Taskmaster's current tag context and migration status in `.taskmaster/state.json`, which is automatically created and managed by the system.
Applied to files:
.taskmaster/state.json
🔇 Additional comments (1)
packages/tm-core/src/services/preflight-checker.service.ts (1)
124-141: Clean, HEAD-safe working-tree check.Using
git status --porcelainavoids HEAD-less errors and catches untracked changes. LGTM.
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
Crunchyman-ralph
force-pushed
the
ralph/feat/tdd.workflow
branch
from
32cf8cd to
ad9355f
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
scripts/create-worktree.sh (1)
37-42: Improve UX when worktree path exists (optional).Show whether the path is already an attached worktree and which branch, not only the filesystem presence.
Example insertion above this block:
# Optional: if a worktree already exists on this path, show details if git worktree list --porcelain | awk -v p="$WORKTREE_PATH" '$0 ~ "^worktree " p"$" {f=1} f && /^branch /{print " Existing worktree branch:", $2; exit}'; then : fi
♻️ Duplicate comments (1)
packages/tm-core/src/services/preflight-checker.service.ts (1)
219-261: LGTM with optional recommendation.The tool validation correctly distinguishes between GH CLI installation and authentication status. However, the optional Node >= 18 enforcement from a previous review was not implemented.
If you'd like to enforce Node >= 18 (Commander 12 baseline), add this after line 223:
// Always check git and gh CLI tools.push(this.checkTool('git', ['--version'])); + const nodeTool = this.checkTool('node', ['--version']); + // Enforce Node >= 18 + const major = Number((nodeTool.version ?? '').match(/^v?(\d+)/)?.[1] ?? 0); + if (nodeTool.available && major > 0 && major < 18) { + nodeTool.available = false; + nodeTool.message = `${nodeTool.version} found; Node >= 18 required`; + } + tools.push(nodeTool); tools.push(await this.checkGhCli());Then remove the node check from lines 191-193 in the toolMap to avoid duplicate checks.
Based on learnings
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (5)
.coderabbit.yaml(0 hunks)packages/tm-core/src/services/preflight-checker.service.ts(1 hunks)packages/tm-core/src/services/task-loader.service.ts(1 hunks)packages/tm-core/src/utils/git-utils.ts(1 hunks)scripts/create-worktree.sh(2 hunks)
💤 Files with no reviewable changes (1)
- .coderabbit.yaml
🔇 Additional comments (13)
packages/tm-core/src/utils/git-utils.ts (1)
1-328: LGTM! Past review feedback thoroughly addressed.All previously identified issues have been properly resolved:
- Buffer overflow protection added for branch listing commands
- Remote prefix stripping generalized for non-origin remotes
- Default branch detection made robust with fallback chain
- Tag sanitization permits dots while maintaining safety
- Reserved branch check case-insensitive
The implementation is solid and handles edge cases appropriately.
packages/tm-core/src/services/task-loader.service.ts (1)
1-401: LGTM! Execution order logic fixed and validation flow is robust.The previously identified execution-order bug has been properly resolved with correct progress tracking (
let added = falseandadded = true). The comprehensive validation pipeline is well-structured:
- Task loading with graceful error handling
- Status validation rejecting completed/cancelled tasks
- Subtask existence check with helpful expansion guidance
- Structure validation for required fields
- Dependency validation catching both missing references and cycles
- Topological sort with safety fallback
The DFS-based circular dependency detection correctly uses backtracking with copied visited sets.
scripts/create-worktree.sh (2)
6-11: Good hardening and repo-root handling.Strict mode and cd to project root are correct and address prior concerns.
14-21: Detached HEAD guard is correct.Clean, early failure with a clear message. LGTM.
packages/tm-core/src/services/preflight-checker.service.ts (9)
21-56: LGTM!The type definitions are well-structured and provide clear contracts for check results.
61-69: LGTM!Constructor validation is appropriate and provides a clear error message.
74-108: LGTM!The test command detection correctly handles missing files and parse errors with specific error messages.
113-148: LGTM!The git working tree check correctly uses
git status --porcelainto handle HEAD-less repos and detect all types of changes.
184-214: LGTM!Tool mapping is comprehensive and covers all detected project types.
266-289: LGTM!The tool check correctly executes commands and captures version information.
294-315: LGTM!The GH CLI check correctly distinguishes between installation and authentication, addressing the previous review feedback.
320-343: LGTM!Default branch detection properly delegates to the utility function and handles errors appropriately.
348-393: LGTM!The orchestration method correctly runs all checks and builds a comprehensive summary with dynamically computed totals.
Implements the complete Phase 0 spike for autonomous TDD workflow with orchestration architecture. ## What's New ### Core Services (tm-core) - **PreflightChecker**: Validates environment prerequisites - Test command detection from package.json - Git working tree status validation - Required tools availability (git, gh, node, npm) - Default branch detection - **TaskLoaderService**: Comprehensive task validation - Task existence and structure validation - Subtask dependency analysis with circular detection - Execution order calculation via topological sort - Helpful expansion suggestions for unready tasks ### CLI Command - **autopilot command**: `tm autopilot <taskId> --dry-run` - Displays complete execution plan without executing - Shows preflight check results - Lists subtasks in dependency order - Preview RED/GREEN/COMMIT phases per subtask - Registered in command registry ### Architecture Documentation - **Phase 0 completion**: Marked tdd-workflow-phase-0-spike.md as complete - **Orchestration model**: Added execution model section to main workflow doc - Clarifies orchestrator guides AI sessions vs direct execution - WorkflowOrchestrator API design (getNextWorkUnit, completeWorkUnit) - State machine approach for phase transitions - **Phase 1 roadmap**: New tdd-workflow-phase-1-orchestrator.md - Detailed state machine specifications - MCP integration plan with new tool definitions - Implementation checklist with 6 clear steps - Example usage flows ## Technical Details **Preflight Checks**: - ✅ Test command detection - ✅ Git working tree status - ✅ Required tools validation - ✅ Default branch detection **Task Validation**: - ✅ Task existence check - ✅ Status validation (no completed/cancelled tasks) - ✅ Subtask presence validation - ✅ Dependency resolution with circular detection - ✅ Execution order calculation **Architecture Decision**: Adopted orchestration model where WorkflowOrchestrator maintains state and generates work units, while Claude Code (via MCP) executes the actual work. This provides: - Clean separation of concerns - Human-in-the-loop capability - Simpler implementation (no AI integration in orchestrator) - Flexible executor support ## Out of Scope (Phase 0) - Actual test generation - Actual code implementation - Git operations (commits, branches, PR) - Test execution → All deferred to Phase 1 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
- Fix git-utils import in PreflightChecker using require() with type casting - Fix ConfigManager initialization in TaskLoaderService (use async factory) - Fix TaskService.getTask return type (returns Task | null directly) - Export PreflightChecker and TaskLoaderService from @tm/core - Fix unused parameter and type annotations in autopilot command - Add boolean fallback for optional dryRun parameter All turbo:typecheck errors resolved. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Move git utilities from scripts/modules/utils/git-utils.js to packages/tm-core/src/utils/git-utils.ts for better type safety and reusability. ## Changes **New File**: `packages/tm-core/src/utils/git-utils.ts` - Converted from JavaScript to TypeScript with full type annotations - Added `GitHubRepoInfo` interface for type safety - Includes all essential git functions needed for Phase 1: - `isGitRepository`, `isGitRepositorySync` - `getCurrentBranch`, `getCurrentBranchSync` - `getLocalBranches`, `getRemoteBranches` - `isGhCliAvailable`, `getGitHubRepoInfo` - `getDefaultBranch`, `isOnDefaultBranch` - `sanitizeBranchNameForTag`, `isValidBranchForTag` **Updated Files**: - `preflight-checker.service.ts`: Now imports from local git-utils - `packages/tm-core/src/utils/index.ts`: Exports git utilities ## Rationale Phase 1 will need git operations for: - Creating feature branches (WorkflowOrchestrator) - Checking git status before execution - Validating clean working tree - Branch naming validation Having these utilities in tm-core provides: - Type safety (no more `require()` hacks) - Better testability - Cleaner imports - Reusability across services ## Verification ✅ All tests pass (1298 passed, 121 test suites) ✅ Typecheck passes (5/5 successful) ✅ Build successful 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Crunchyman-ralph
force-pushed
the
tdd-phase-0-implementation
branch
from
24b7da2 to
4b6ad19
Compare
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 9
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
scripts/create-worktree.sh (1)
14-24: Handle missing argument safely underset -u.With
set -uin effect, referencing$1when no arguments are supplied triggersbash: $1: unbound variable, so the script now aborts in the normal “no-arg” flow that should auto-derive a branch name. Guard via$#or${1-}before expanding the positional parameter. Suggested change:-if [ -z "$1" ]; then +if [ $# -eq 0 ]; then
♻️ Duplicate comments (2)
.taskmaster/config.json (1)
2-43: Revert manual edits to Taskmaster config.
.taskmaster/config.jsonis tool-managed. Please undo these direct edits and reapply the desired settings through the Taskmaster CLI/MCP (task-master models ...) to avoid config drift. As per coding guidelines.packages/tm-core/src/services/preflight-checker.service.ts (1)
217-259: Enforce Node >= 18 in preflight (Commander 12 baseline).Fail early if Node < 18 to avoid runtime issues. Based on learnings
@@ for (const type of projectTypes) { const typeTools = this.getToolsForProjectType(type); for (const tool of typeTools) { tools.push(this.checkTool(tool.command, tool.args)); } } + // Enforce minimal Node version if present (Commander v12 requires Node >= 18) + const nodeTool = tools.find((t) => t.name === 'node'); + if (nodeTool?.available) { + const major = Number((nodeTool.version ?? '').match(/^v?(\d+)/)?.[1] ?? 0); + if (major > 0 && major < 18) { + nodeTool.available = false; + nodeTool.message = `${nodeTool.version} found; Node >= 18 required`; + } + }
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (19)
.coderabbit.yaml(0 hunks).taskmaster/config.json(1 hunks).taskmaster/docs/autonomous-tdd-git-workflow.md(2 hunks).taskmaster/docs/tdd-workflow-phase-0-spike.md(1 hunks).taskmaster/docs/tdd-workflow-phase-1-orchestrator.md(1 hunks).taskmaster/reports/task-complexity-report_autonomous-tdd-git-workflow.json(1 hunks).taskmaster/reports/task-complexity-report_tdd-workflow-phase-0.json(1 hunks).taskmaster/state.json(1 hunks).taskmaster/tasks/tasks.json(50 hunks)apps/cli/src/command-registry.ts(2 hunks)apps/cli/src/commands/autopilot.command.ts(1 hunks)apps/cli/src/index.ts(1 hunks)packages/tm-core/src/index.ts(1 hunks)packages/tm-core/src/services/index.ts(1 hunks)packages/tm-core/src/services/preflight-checker.service.ts(1 hunks)packages/tm-core/src/services/task-loader.service.ts(1 hunks)packages/tm-core/src/utils/git-utils.ts(1 hunks)packages/tm-core/src/utils/index.ts(1 hunks)scripts/create-worktree.sh(2 hunks)
💤 Files with no reviewable changes (1)
- .coderabbit.yaml
🧰 Additional context used
🧠 Learnings (22)
📚 Learning: 2025-07-18T17:10:12.881Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/dev_workflow.mdc:0-0
Timestamp: 2025-07-18T17:10:12.881Z
Learning: Applies to .taskmaster/state.json : Track Taskmaster's current tag context and migration status in `.taskmaster/state.json`, which is automatically created and managed by the system.
Applied to files:
.taskmaster/state.json
📚 Learning: 2025-07-18T17:13:30.188Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tags.mdc:0-0
Timestamp: 2025-07-18T17:13:30.188Z
Learning: Applies to scripts/modules/* : Do not hard-code tag resolution (e.g., const tag = options.tag || 'master';); always use getCurrentTag
Applied to files:
.taskmaster/state.json
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to scripts/modules/utils.js : Use tag resolution functions for all task data access, provide backward compatibility with legacy format, and default to 'master' tag when no tag is specified.
Applied to files:
.taskmaster/state.json
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : The default tag 'master' must be used for all existing and new tasks unless otherwise specified.
Applied to files:
.taskmaster/state.json
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Tasks must be organized into separate contexts (tags) within tasks.json, using the tagged format: {"master": {"tasks": [...]}, "feature-branch": {"tasks": [...]}}. Legacy format {"tasks": [...]} must be silently migrated to the tagged format on first use.
Applied to files:
.taskmaster/state.json
📚 Learning: 2025-07-18T17:13:30.188Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tags.mdc:0-0
Timestamp: 2025-07-18T17:13:30.188Z
Learning: Applies to scripts/modules/* : All commands must resolve the tag using the pattern: options.tag || getCurrentTag(projectRoot) || 'master'
Applied to files:
.taskmaster/state.json
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Use tag resolution functions to maintain backward compatibility, returning legacy format to core functions and not exposing the tagged structure to existing core logic.
Applied to files:
.taskmaster/state.json
📚 Learning: 2025-07-31T22:07:49.716Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-31T22:07:49.716Z
Learning: Applies to scripts/modules/commands.js : Export the registerCommands function and keep the CLI setup code clean and maintainable.
Applied to files:
apps/cli/src/index.tsapps/cli/src/command-registry.ts
📚 Learning: 2025-09-26T19:05:47.555Z
Learnt from: Crunchyman-ralph
PR: eyaltoledano/claude-task-master#1252
File: packages/ai-sdk-provider-grok-cli/package.json:11-13
Timestamp: 2025-09-26T19:05:47.555Z
Learning: In the eyaltoledano/claude-task-master repository, internal tm/ packages use a specific export pattern where the "exports" field points to TypeScript source files (./src/index.ts) while "main" points to compiled output (./dist/index.js) and "types" points to source files (./src/index.ts). This pattern is used consistently across internal packages like tm/core and tm/ai-sdk-provider-grok-cli because they are consumed directly during build-time bundling with tsdown rather than being published as separate packages.
Applied to files:
packages/tm-core/src/index.ts.taskmaster/tasks/tasks.json
📚 Learning: 2025-07-18T17:10:02.683Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/dev_workflow.mdc:0-0
Timestamp: 2025-07-18T17:10:02.683Z
Learning: Applies to .taskmaster/config.json : Store Taskmaster configuration settings (AI model selections, parameters, logging level, default subtasks/priority, project name, tag management) in `.taskmaster/config.json` in the project root. Do not configure these via environment variables.
Applied to files:
.taskmaster/config.json
📚 Learning: 2025-09-24T15:12:58.855Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: assets/AGENTS.md:0-0
Timestamp: 2025-09-24T15:12:58.855Z
Learning: Applies to assets/.taskmaster/config.json : Never manually edit .taskmaster/config.json; use task-master models to change AI model settings
Applied to files:
.taskmaster/config.json
📚 Learning: 2025-07-18T17:10:12.881Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/dev_workflow.mdc:0-0
Timestamp: 2025-07-18T17:10:12.881Z
Learning: Applies to .taskmaster/config.json : Store Taskmaster configuration settings (AI model selections, parameters, logging level, default subtasks/priority, project name, etc.) in the `.taskmaster/config.json` file located in the project root directory. Do not configure non-API key settings via environment variables.
Applied to files:
.taskmaster/config.json
📚 Learning: 2025-07-18T17:10:12.881Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/dev_workflow.mdc:0-0
Timestamp: 2025-07-18T17:10:12.881Z
Learning: Applies to .taskmaster/config.json : Do not manually edit `.taskmaster/config.json` unless you are certain of the changes; use the `task-master models` command or `models` MCP tool for configuration.
Applied to files:
.taskmaster/config.json
📚 Learning: 2025-07-31T22:08:16.039Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/taskmaster.mdc:0-0
Timestamp: 2025-07-31T22:08:16.039Z
Learning: Applies to .taskmaster/config.json : Do not manually edit the .taskmaster/config.json file; always use the provided CLI or MCP tools for configuration changes.
Applied to files:
.taskmaster/config.json
📚 Learning: 2025-07-31T22:08:16.039Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/taskmaster.mdc:0-0
Timestamp: 2025-07-31T22:08:16.039Z
Learning: Applies to .taskmaster/config.json : Do not manually edit the .taskmaster/config.json file. Use the included commands either in the MCP or CLI format as needed. Always prioritize MCP tools when available and use the CLI as a fallback.
Applied to files:
.taskmaster/config.json
📚 Learning: 2025-07-31T22:08:16.039Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/taskmaster.mdc:0-0
Timestamp: 2025-07-31T22:08:16.039Z
Learning: Applies to .taskmaster/config.json : All other Taskmaster settings (model choice, max tokens, temperature, log level, custom endpoints) are managed in .taskmaster/config.json via the task-master models command or models MCP tool.
Applied to files:
.taskmaster/config.json
📚 Learning: 2025-07-31T22:08:16.039Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/taskmaster.mdc:0-0
Timestamp: 2025-07-31T22:08:16.039Z
Learning: Applies to {.taskmaster/tasks/tasks.json,.taskmaster/reports/task-complexity-report.json,.taskmaster/docs/research/**} : Do not manually edit generated files such as .taskmaster/tasks/tasks.json, .taskmaster/reports/task-complexity-report.json, or files in .taskmaster/docs/research/. Always use Taskmaster commands to modify these files.
Applied to files:
.taskmaster/config.json
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Use consistent formatting for task files, include all task properties in text files, and format dependencies with status indicators.
Applied to files:
.taskmaster/tasks/tasks.json
📚 Learning: 2025-07-18T17:09:40.548Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/dependencies.mdc:0-0
Timestamp: 2025-07-18T17:09:40.548Z
Learning: Applies to scripts/modules/dependency-manager.js : Support both task and subtask dependencies in cycle detection
Applied to files:
.taskmaster/tasks/tasks.json
📚 Learning: 2025-09-24T15:12:12.658Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: assets/.windsurfrules:0-0
Timestamp: 2025-09-24T15:12:12.658Z
Learning: Follow the Task File Format template when writing task files: include ID, title, status, dependencies, priority, details, test strategy, and subtasks
Applied to files:
.taskmaster/tasks/tasks.json
📚 Learning: 2025-07-18T17:10:31.810Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/git_workflow.mdc:0-0
Timestamp: 2025-07-18T17:10:31.810Z
Learning: Subtask commit messages must follow the format: feat(task-X): Complete subtask X.Y - [Subtask Title] with a detailed body describing implementation, key changes, and notes
Applied to files:
.taskmaster/tasks/tasks.json
📚 Learning: 2025-07-18T17:10:31.810Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/git_workflow.mdc:0-0
Timestamp: 2025-07-18T17:10:31.810Z
Learning: Pull Request descriptions must use the provided template, including Task Overview, Subtasks Completed, Implementation Details, Testing, Breaking Changes, and Related Tasks
Applied to files:
.taskmaster/tasks/tasks.json
🪛 markdownlint-cli2 (0.18.1)
.taskmaster/docs/tdd-workflow-phase-1-orchestrator.md
3-3: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
6-6: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
11-11: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
19-19: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
25-25: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
31-31: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
43-43: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
96-96: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
102-102: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
109-109: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
115-115: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
120-120: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
123-123: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
.taskmaster/docs/autonomous-tdd-git-workflow.md
667-667: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Test
🔇 Additional comments (12)
.taskmaster/state.json (1)
2-3: LGTM! State transition reflects Phase 0 completion.The
currentTagswitch from"tdd-workflow-phase-0"to"master"and the updatedlastSwitchedtimestamp correctly reflect the completion of Phase 0 and return to the master tag context. As previously confirmed,currentTagis independent ofbranchTagMappingand does not require a corresponding entry.Based on learnings
apps/cli/src/commands/autopilot.command.ts (7)
42-59: LGTM! Clean Commander.Command extension.The class correctly extends Commander's
Commandand uses the fluent API to configure description, arguments, and options. The action handler properly uses an arrow function to maintainthisbinding.Based on learnings
122-140: LGTM! Validation logic is clear and correct.Both
validateOptionsandvalidateTaskIdprovide proper validation with clear error messages. The task ID regex^\d+(\.\d+)*$correctly matches the expected format (e.g., "1" or "1.2").
142-165: LGTM! Core initialization follows singleton pattern.The
initializeCoremethod correctly checks for existing instance before creating, andloadTaskappropriately handles errors by returningnullfor user-friendly error handling upstream.
197-299: LGTM! Well-structured autopilot execution flow.The method properly:
- Uses dynamic imports for code splitting
- Runs preflight checks before task validation
- Cleans up resources (
await taskLoader.cleanup())- Provides clear execution plan visualization
- Handles dry-run mode appropriately
390-401: LGTM! Robust error handling with environment awareness.The error handler properly:
- Sanitizes error details with fallback chain
- Respects
NODE_ENVandDEBUGfor stack trace display- Uses appropriate color coding
420-434: LGTM! Clean resource management and registration pattern.The
cleanupmethod properly awaitstmCore.close()and clears the reference. The staticregistermethod follows Commander's best practices for command registration.
64-117: Consider cleanup before process.exit.The error handling calls
process.exit(1)immediately, which prevents any cleanup hooks from running. While acceptable for a CLI tool, consider adding afinallyblock to ensure spinners are always stopped and resources cleaned up before exiting.Apply this diff to ensure cleanup:
private async executeCommand( taskId: string, options: AutopilotCommandOptions ): Promise<void> { let spinner: Ora | null = null; try { // Validate options if (!this.validateOptions(options)) { process.exit(1); } // ... rest of the code ... } catch (error: any) { if (spinner) { spinner.fail('Operation failed'); } this.handleError(error); process.exit(1); + } finally { + // Ensure cleanup happens even if process.exit is called + if (spinner && !spinner.isSpinning) { + spinner.stop(); + } } }⛔ Skipped due to learnings
Learnt from: joedanz PR: eyaltoledano/claude-task-master#748 File: scripts/modules/task-manager/parse-prd.js:726-733 Timestamp: 2025-07-21T17:51:07.239Z Learning: In CLI contexts within task-manager modules like scripts/modules/task-manager/parse-prd.js, using process.exit(1) for validation failures and error conditions is correct and preferred over throwing errors, as it provides immediate termination with appropriate exit codes for scripting. The code should distinguish between MCP contexts (throw errors) and CLI contexts (use process.exit)..taskmaster/docs/tdd-workflow-phase-0-spike.md (1)
1-9: LGTM! Documentation accurately reflects Phase 0 completion.The status update clearly marks Phase 0 as complete and provides a direct link to the implementation. This properly closes the loop between planning and execution.
apps/cli/src/index.ts (1)
14-14: LGTM! Export follows established pattern.The
AutopilotCommandexport is correctly placed with other command exports and follows the existing convention in the file.Based on learnings
apps/cli/src/command-registry.ts (2)
16-16: LGTM! Import follows existing pattern.The
AutopilotCommandimport is correctly placed with other command imports and follows the established ordering.Based on learnings
67-72: LGTM! Command registration is consistent.The autopilot command metadata properly:
- Uses the 'development' category (appropriate for TDD workflow tooling)
- Provides clear description
- Follows the same pattern as existing commands (including the
as anycast)Based on learnings
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (1)
apps/cli/src/commands/autopilot.command.ts (1)
187-187: Address the width calculation as noted in previous review.The current fallback logic treats
0as falsy and returns100instead of computing0 * 0.95. Whileprocess.stdout.columnsbeing exactly0is rare, using nullish coalescing would be more semantically correct.Apply this diff:
- width: process.stdout.columns ? process.stdout.columns * 0.95 : 100 + width: (process.stdout.columns ?? 100) * 0.95
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
apps/cli/src/commands/autopilot.command.ts(1 hunks)packages/tm-core/src/services/preflight-checker.service.ts(1 hunks)packages/tm-core/src/utils/git-utils.ts(1 hunks)
🔇 Additional comments (8)
apps/cli/src/commands/autopilot.command.ts (1)
70-116: LGTM on CLI error handling pattern.The use of
process.exit(1)is appropriate for a CLI command entrypoint. The error paths are clear and provide useful feedback to users before exiting.packages/tm-core/src/utils/git-utils.ts (3)
102-141: LGTM! Past review comments have been thoroughly addressed.The branch listing functions now include:
maxBufferto handle large repos- Generalized remote prefix stripping with deduplication
- Proper filtering and trimming
These improvements make the utilities robust for production use.
207-258: LGTM! Default branch detection is now robust.The multi-layered fallback strategy correctly handles:
- GH CLI when available
- Non-origin remotes via dynamic detection
git remote showparsing with increased buffer- Symbolic-ref fallback
- Common default names checked against both local and remote branches
This addresses all concerns from previous reviews.
362-395: LGTM! Worktree parsing is now robust.The parser correctly:
- Flushes the previous entry when a new
worktreeline appears- Handles the final entry after the loop
- Handles missing blank-line separators
This resolves the parsing edge cases flagged in previous reviews.
packages/tm-core/src/services/preflight-checker.service.ts (4)
124-142: LGTM! Git working tree check now handles HEAD-less repos.Using
git status --porcelainas the single source of truth correctly handles repos without commits and catches all types of changes (staged, unstaged, untracked). The timeout safeguard is also a good addition.
173-175: LGTM! .NET detection is now correct.Using
readdirSyncwithendsWithchecks properly detects.csprojand.slnfiles, fixing the glob pattern bug from previous reviews.
294-316: LGTM! GH CLI check now distinguishes install from authentication.The separate
checkGhClimethod correctly:
- Detects installation via
gh --version- Checks authentication separately via
isGhCliAvailable- Provides clear messaging for each state
- Includes timeout protection
This resolves the confusion flagged in previous reviews.
379-382: LGTM! Summary message uses dynamic total.Computing the total as
passed.length + failed.lengthensures the summary remains accurate if the number of checks changes, addressing the hardcoded "/4" issue from previous reviews.
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
1 participant
🎯 Overview
Implements Phase 0 of the autonomous TDD workflow system - a complete dry-run foundation with orchestration architecture for future execution.
This PR delivers a working
tm autopilot <taskId> --dry-runcommand that validates the environment, analyzes tasks, and displays a complete execution plan without making any changes.✨ What's New
🏗️ Core Services (
tm-core)PreflightChecker (
packages/tm-core/src/services/preflight-checker.service.ts)Validates environment prerequisites before autopilot execution:
package.jsongit,gh,node,npm)TaskLoaderService (
packages/tm-core/src/services/task-loader.service.ts)Comprehensive task validation and dependency analysis:
🖥️ CLI Command
Autopilot Command (
apps/cli/src/commands/autopilot.command.ts)New command:
tm autopilot <taskId> [options]Options:
--dry-run- Show execution plan without performing actions--format <text|json>- Output format (default: text)--project <path>- Project root directoryFeatures:
📚 Architecture Documentation
Phase 0 Completion (
.taskmaster/docs/tdd-workflow-phase-0-spike.md)Orchestration Model Clarification (
.taskmaster/docs/autonomous-tdd-git-workflow.md)Added "Execution Model" section clarifying the orchestration approach:
Orchestrator Role (tm-core):
Executor Role (Claude Code/AI via MCP):
Why This Architecture?
Phase 1 Roadmap (
.taskmaster/docs/tdd-workflow-phase-1-orchestrator.md)New comprehensive specification for next phase:
getNextWorkUnit,completeWorkUnit,getRunState)🚀 Example Usage
🔧 Technical Details
Preflight Validation
The
PreflightCheckerruns 4 comprehensive checks:package.jsonhas a test scriptgit,gh,node,npmavailabilityTask Validation
The
TaskLoaderServiceperforms multi-step validation:Error Handling
Comprehensive error types with actionable suggestions:
task_not_found→ suggests usingtask-master listtask_completed→ suggests choosing different taskno_subtasks→ suggeststask-master expand --id=<id>circular_dependencies→ shows dependency chainmissing_dependencies→ lists invalid referencesinvalid_structure→ suggests re-expansion🎨 Architecture Highlights
State Machine Design
Phase transitions follow strict rules:
Preconditions:
Work Unit API (Phase 1)
MCP Integration (Phase 1)
New tools to be added:
mcp__task_master_ai__autopilot_start(taskId, dryRun?)mcp__task_master_ai__autopilot_next_work_unit(runId)mcp__task_master_ai__autopilot_complete_work_unit(runId, workUnitId, result)mcp__task_master_ai__autopilot_get_state(runId)mcp__task_master_ai__autopilot_pause/resume(runId)📦 Files Changed
New Files
apps/cli/src/commands/autopilot.command.ts(425 lines)packages/tm-core/src/services/preflight-checker.service.ts(317 lines)packages/tm-core/src/services/task-loader.service.ts(390 lines).taskmaster/docs/tdd-workflow-phase-1-orchestrator.md(500+ lines)Modified Files
apps/cli/src/command-registry.ts- Added autopilot commandapps/cli/src/index.ts- Exported AutopilotCommandpackages/tm-core/src/services/index.ts- Exported new services.taskmaster/docs/autonomous-tdd-git-workflow.md- Added execution model section.taskmaster/docs/tdd-workflow-phase-0-spike.md- Marked complete.taskmaster/tasks/tasks.json- Updated task statuses✅ Success Criteria Met
tm autopilot <taskId> --dry-runcommand functional🚫 Out of Scope (Phase 0)
The following are intentionally deferred to Phase 1:
🔜 Next Steps (Phase 1)
Phase 1 will implement the WorkflowOrchestrator state machine:
.taskmaster/reports/runs/See
.taskmaster/docs/tdd-workflow-phase-1-orchestrator.mdfor detailed roadmap.🧪 Testing
Manual Testing Performed
npm run buildsuccessfulAutomated Tests
📝 Migration Notes
No breaking changes - This is purely additive:
tm autopilot@tm/core🤝 Review Focus
Please review:
🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Documentation
Chores