Skip to content

fix(tasks): ensure skip parameter treats parent+subtasks as single unit#7

Merged
wbisschoff13 merged 4 commits intomainfrom
task/9-skip-logic-unit-tests
Jan 8, 2026
Merged

fix(tasks): ensure skip parameter treats parent+subtasks as single unit#7
wbisschoff13 merged 4 commits intomainfrom
task/9-skip-logic-unit-tests

Conversation

@wbisschoff13
Copy link
Owner

Fix a critical bug in the skip logic where parent tasks with eligible subtasks were incorrectly included in the top-level eligible task list, causing the skip parameter to count them twice. When using --skip, parent task hierarchies (parent + all subtasks) must be treated as a single unit in the skip index.

Key changes

  • Bug fix: Modified task-service.ts to exclude parent tasks with eligible subtasks from top-level consideration during skip indexing (lines 458-489)
  • Validation: Added comprehensive unit test suite with 28 tests covering all skip logic scenarios (720+ lines)
  • Test coverage: Basic skip indexing, boundary conditions, priority sorting, dependency resolution, subtask hierarchies, backward compatibility, performance with large task sets, error handling, and edge cases

How to test

Automated Tests

  • npm run turbo:typecheck - TypeScript compilation passes
  • npx vitest run packages/tm-core/src/modules/tasks/services/task-service.spec.ts - All 28 skip logic tests pass

Manual Testing

# Create a project with in-progress task containing subtasks
task-master init
task-master parse-prd .taskmaster/docs/prd.md

# Set a parent task to in-progress
task-master set-status --id=1 --status=in-progress

# Verify skip parameter correctly treats parent+subtasks as single unit
# skip=0 should return first subtask (1.1)
task-master next --skip=0
# skip=2 should return third subtask (1.3) or next task if no third subtask
task-master next --skip=2
# skip=3 should skip the ENTIRE parent hierarchy and return next top-level task
task-master next --skip=3

Risk Assessment

Low risk - This is a targeted bug fix with comprehensive test coverage. The change only affects the skip logic path when parent tasks have eligible subtasks. Backward compatibility is maintained for all other scenarios.

Technical details

The bug occurred because parent tasks with eligible subtasks were being included in both the candidateSubtasks array (for their subtasks) AND the top-level eligibleTasks array. This meant a parent with 3 subtasks would consume 4 skip positions (1 for parent + 3 for subtasks) instead of 3 (just the subtasks).

The fix checks if a parent task has any pending subtasks with satisfied dependencies, and if so, excludes the parent from the top-level eligible tasks list. This ensures the entire hierarchy is treated as a single unit.

Checklist

  • Tests added - 28 comprehensive unit tests for skip logic
  • Documentation updated - JSDoc comments updated with parent hierarchy behavior
  • Backwards compatible - Existing behavior preserved for non-hierarchical scenarios
  • No secrets or credentials in code

Task: TM-009 - Write comprehensive unit tests for skip logic

Fixed critical bug where parent tasks with eligible subtasks were included
in the top-level eligible tasks array, causing incorrect skip counting.
Now the entire parent task hierarchy (parent + all eligible subtasks) is
treated as a single logical unit in the skip index.

Changes:
- Added logic to exclude parent tasks with eligible subtasks from eligibleTasks
- Updated JSDoc with "Parent Task Hierarchy" section and concrete examples
- Added 33 comprehensive unit tests covering all skip scenarios
- Tests verify skip behavior with subtasks, dependencies, priorities, and boundaries

Example behavior:
- Task 1 has subtasks 1.1, 1.2, 1.3; task 2 exists
- skip=0 → 1.1, skip=1 → 1.2, skip=2 → 1.3, skip=3 → task 2
- Previously skip=3 would incorrectly return task 1 (parent) instead of task 2

Test coverage:
- Basic skip indexing (0, 1, N)
- Boundary conditions (exceeds available, equals count, negative)
- Priority sorting with skip
- Duplicate priority tiebreakers (ID, dependency count)
- Dependency resolution with skip
- Subtasks from in-progress parents (critical fix)
- Backward compatibility (undefined defaults to 0)
- Tag filtering and status filtering
- Performance with large task sets (1000+ tasks)

All 33 tests pass successfully.
Add comprehensive PR description for the skip logic bug fix that ensures
parent task hierarchies are treated as a single unit in the skip index.

Also fix TypeScript type errors in the new test file by adding all required
IStorage interface methods and completing Subtask interface fields.
@gemini-code-assist
Copy link

Summary of Changes

Hello @wbisschoff13, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a significant bug in the task skip logic, specifically how it handles parent tasks with subtasks. The core issue was that parent tasks were being double-counted in the skip index when they had eligible subtasks, leading to incorrect task retrieval. The fix ensures that an entire parent-subtask hierarchy is considered a single unit for skipping purposes, thereby providing accurate and predictable behavior for the --skip parameter. This change is backed by extensive new unit tests to guarantee correctness and maintain backward compatibility.

Highlights

  • Bug Fix: Corrected a critical bug in the skip logic where parent tasks with eligible subtasks were incorrectly counted twice, ensuring parent+subtask hierarchies are treated as a single unit for skipping.
  • Validation: Introduced a comprehensive unit test suite with 28 new tests for the skip logic, covering basic indexing, boundary conditions, priority sorting, dependency resolution, subtask hierarchies, and error handling.
  • Documentation: Updated JSDoc comments in task-service.ts to clearly describe the new skip logic behavior, especially concerning parent task hierarchies.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This is an excellent pull request that addresses a critical bug in the task skipping logic. The fix in task-service.ts is clear and correctly prevents parent tasks from being double-counted when they have eligible subtasks. The addition of a comprehensive 700+ line test suite in task-service.spec.ts is particularly impressive and provides strong confidence in the correctness and robustness of the solution. I have a few suggestions to improve maintainability and test readability.

Comment on lines 463 to 474
const hasEligibleSubtask = task.subtasks.some((st) => {
const stStatus = (st.status || 'pending').toLowerCase();
if (stStatus !== 'pending' && stStatus !== 'in-progress') return false;

const fullDeps =
st.dependencies?.map((d) => toFullSubId(String(task.id), d)) ?? [];
const depsSatisfied =
fullDeps.length === 0 ||
fullDeps.every((depId) => completedIds.has(String(depId)));

return depsSatisfied;
});

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

There's an opportunity to reduce code duplication here. The logic to determine if a subtask is eligible is now present in two places: here in the eligibleTasks filter, and earlier when populating candidateSubtasks (lines 397-407).

To improve maintainability, consider extracting this logic into a private helper method, for example isSubtaskEligible(subtask, parentTask, completedIds). This would ensure that any future changes to the definition of an 'eligible subtask' only need to be made in one place.

Comment on lines 713 to 720
try {
await service.getNextTask('master', -1);
expect.fail('Should have thrown TaskMasterError');
} catch (error) {
expect(error).toBeInstanceOf(TaskMasterError);
expect((error as TaskMasterError).code).toBe(ERROR_CODES.VALIDATION_ERROR);
}
});

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

This test can be simplified by using the rejects.toHaveProperty matcher from vitest. This avoids the try/catch block and expect.fail, making the test more concise and idiomatic.

			await expect(service.getNextTask('master', -1)).rejects.toHaveProperty(
				'code',
				ERROR_CODES.VALIDATION_ERROR
			);

Comment on lines 726 to 733
try {
await service.getNextTask('master', -5);
expect.fail('Should have thrown TaskMasterError');
} catch (error) {
expect(error).toBeInstanceOf(TaskMasterError);
const taskError = error as TaskMasterError;
expect(taskError.context?.provided).toBe(-5);
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Similarly to the test above, this can be refactored to use rejects.toHaveProperty for a more concise and idiomatic test case.

			await expect(service.getNextTask('master', -5)).rejects.toHaveProperty(
				'context.provided',
				-5
			);

Context:
- Task: PR #7 Review Feedback
- Source: #7

Notes:
- Extracted isSubtaskEligible() helper to eliminate duplication in subtask eligibility logic
- Refactored 2 error-handling tests to use idiomatic vitest rejects.toHaveProperty matcher
- Changes reduce code by 7 lines net while improving maintainability
- All 1,483 tests pass
@wbisschoff13 wbisschoff13 merged commit 16fe63e into main Jan 8, 2026
@wbisschoff13 wbisschoff13 deleted the task/9-skip-logic-unit-tests branch January 8, 2026 13:46
wbisschoff13 added a commit that referenced this pull request Jan 17, 2026
* feat(tasks): add skipCount parameter to getNextTask method

Task: TM-001 - Add skipCount parameter to service layer

Subtasks:
- TM-001.1: Update method signature with TypeScript types
- TM-001.2: Implement skip indexing logic with array bounds checking
- TM-001.3: Add input validation for skipCount parameter
- TM-001.4: Ensure backward compatibility with existing calls
- TM-001.5: Add comprehensive inline documentation

Notes:
- Added optional skipCount parameter to getNextTask(tag?: string, skipCount?: number)
- Implemented skip indexing: returns task at index skipCount from eligible tasks
- Validates skipCount must be non-negative integer; throws TaskMasterError if invalid
- Returns null if skipCount exceeds eligible tasks length
- Backward compatible: default skipCount=0 preserves existing behavior
- Applied to both subtask and top-level task selection logic
- Updated JSDoc with usage examples and parameter descriptions
- Includes .taskmaster/tasks.json with task completion status

Files modified:
- packages/tm-core/src/modules/tasks/services/task-service.ts

* docs(pr): add PR description for task/1-add-skipcount-parameter

* docs(pr): rename description to PR #1

* fix(tasks): correct skip count propagation in getNextTask

Fix logical flaw in skipCount parameter handling where falling through
from subtasks to top-level tasks didn't adjust the skip value. This
caused incorrect number of top-level tasks to be skipped.

Changes:
- Change skip variable from const to let for mutability
- Decrement skip by candidateSubtasks.length when falling through

Fixes bug where skipCount=2 with 2 available subtasks would incorrectly
skip the first 2 top-level tasks instead of returning the first one.

feat(tasks): add skipCount parameter to getNext domain method (#2)

* feat(tasks): add skipCount parameter to getNext domain method

Task: TM-2 - Update domain facade with skipCount parameter

Added optional skipCount parameter to TasksDomain.getNext() method to support
skipping eligible tasks when retrieving the next available task. This enables
use cases like retrying task selection after skipping previously attempted
tasks.

Implementation:
- Updated getNext method signature to accept optional skipCount parameter
- Added comprehensive JSDoc documentation with usage examples
- Parameter pass-through to taskService.getNextTask() maintaining architecture
- Full backward compatibility (undefined default preserves existing behavior)
- Added 7 unit tests covering all skipCount scenarios and edge cases

Test coverage includes:
- Parameter pass-through verification
- Backward compatibility (undefined skipCount)
- skipCount=0 (first eligible task)
- skipCount>0 (skip N tasks)
- Error propagation from service layer
- Return value handling (task and null cases)
- Type safety verification

Files modified:
- packages/tm-core/src/modules/tasks/tasks-domain.ts:152-172
- packages/tm-core/src/modules/tasks/tasks-domain.spec.ts (new file)
- .taskmaster/tasks/tasks.json (task status updated to done)

* docs(tasks): clarify skipCount fallthrough logic in getNextTask

Task: TM-002 - Update domain facade with skipCount parameter

Notes:
- Improved comment clarity for skipCount parameter fallthrough behavior
- Clarifies that skipCount is relative to combined eligible pool of subtasks and tasks
- Helps future developers understand the two-stage task selection logic
- No functional changes - documentation improvement only

File: packages/tm-core/src/modules/tasks/services/task-service.ts:436-440

* docs(pr): add PR description for task/2-domain-skipcount-parameter

* docs(pr): rename description to PR #2

* test(tasks): improve type safety in domain test mocks

Replace inline mock object creation with type-safe helper function.
Adds createMockTaskService() factory to reduce 'as any' casting
and improve test maintainability without adding dependencies.

Addresses PR review feedback on mock type safety.

feat(cli): add --skip parameter with integer validation (#3)

* feat(cli): add --skip parameter with integer validation

Enable parallel workflows by allowing users to skip eligible tasks.
Validates that skip count is a non-negative integer to prevent
invalid input like --skip 1.5

* docs(pr): add PR description for task/3-cli-skip-param

Generated comprehensive PR description for the --skip parameter feature,
including technical implementation details, testing steps, and risk
assessment.

* docs(pr): rename description to PR #3

* fix(cli): handle Commander string option for skip parameter

Commander passes CLI options as strings, not numbers. The previous
validation logic incorrectly used Number.isInteger() on a string,
which always returns false and rejects valid inputs like "1".

Changes:
- Update skip type to number | string to accept Commander input
- Parse string to number before validation
- Assign numeric value back to options.skip for use in getNextTask
- Add type assertion when passing to tm-core (guaranteed number)

Fixes validation failure for: task-master next --skip 1

test(cli): add comprehensive tests for --skip parameter validation (#4)

* chore(task-master): mark task #4 as done after CLI implementation

Task: TM-004 - Add --skip CLI option with Commander.js

Notes:
- Task implementation completed in commits 85a6066, 3cef35f, and 41b319a
- Updates task status from "pending" to "done"
- Increments completedCount from 3 to 4
- Includes .taskmaster/tasks.json with task status update

* test(cli): add comprehensive tests for --skip parameter validation

Task: TM-005 - Add CLI validation for skip parameter

Notes:
- Tests cover validation logic for negative values, zero, and positive integers
- Tests verify decimal values are rejected with descriptive error messages
- Tests confirm undefined skip parameter passes validation (optional)
- Tests verify skip functionality correctly skips eligible tasks
- Validates Commander.js string-to-number conversion handling
- Includes .taskmaster/tasks/tasks.json with task #5 status updated to "done"

Validation logic was implemented in commit 41b319a; this commit adds the
corresponding test coverage as specified in the task's test strategy.

* docs(pr): add PR description for --skip parameter test coverage

* docs(pr): rename description to PR #4

* test(cli): strengthen --skip parameter test assertions

Applied PR review feedback to improve test quality:
- Strengthen non-numeric skip test to verify proper error handling
  * Add exitCode assertion (should be 1)
  * Verify error message contains "Invalid skip count"
  * Verify error message contains "non-negative integer"

- Refactor --skip functionality tests to reduce duplication
  * Extract test data setup into beforeEach hook
  * Add specific assertions verifying exact task IDs returned
  * Split into clearer, focused tests for each skip value

All 19 tests pass successfully.

refactor(cli): improve error handling and code reuse for --skip parameter (#5)

* chore(task-master): mark task #6 as done - CLI skip parameter integration complete

Task: TM-006 - Update CLI getNextTask call with skip parameter

Notes:
- Task #6 implementation was completed in commit 6dd6ab0 (test(cli): add comprehensive tests for --skip parameter validation)
- The getNextTask method already passes skip parameter to tmCore.tasks.getNext()
- This commit updates Task-Master state to reflect completion
- Skip parameter is properly validated and passed through from CLI options to domain layer
- All tests passing and backward compatibility maintained

* refactor(skip): improve error handling, naming, and code reuse

Code quality improvements from code review:

- Use TaskMasterError consistently in CLI validation
- Improve skip error messages with quoted values and examples
- Rename 'skip' to 'remainingSkip' for clearer fallthrough logic
- Extract getSkipIndex() utility to eliminate duplicate bounds checking
- Fix TypeScript compilation error in test mock

* docs(pr): add PR description for task/6-cli-next-skip-param

Generated comprehensive PR description covering:
- Refactoring of skip parameter error handling
- Code reuse improvements with getSkipIndex() helper
- Enhanced validation error messages
- Test verification results

Risk assessment: Low risk internal refactoring

* docs(pr): rename description to PR #5

* chore: address PR review feedback

Applied 2 review comments from PR #5:
- Add quotes around invalid format value in error message for consistency
- Make getSkipIndex method static since it doesn't use instance state
- Update method calls to use static syntax

* refactor(skip): simplify getSkipIndex with nullish coalescing

Applied PR review feedback from PR #5:
- Simplified getSkipIndex helper using nullish coalescing operator (??)
- Method already static, no changes needed there
- Format validation error already correctly quotes invalid value

The refactored implementation is more concise while maintaining
the same behavior: returns the item at the skip index or null
if out of bounds.

feat(cli): add skip-exceeded detection with user-friendly messaging (#6)

* feat(cli): add skip-exceeded detection with user-friendly messaging

Task: TM-007 - Update skip logic in display text output

Implementation:
- Added skipValue and availableTaskCount to NextTaskResult interface
- Calculate eligible tasks (pending/deferred with no unmet dependencies)
- Detect when --skip exceeds available eligible tasks
- Display clear message with actual skip value and available count
- Provide helpful tip to get last available task

Notes:
- Maintains existing behavior for non-skip null task cases
- Preserves JSON output format (only affects text display)
- Uses existing chalk formatting patterns for consistency
- Edge cases: skip=0 returns first task, skip>=count shows message
- Includes .taskmaster/tasks.json with task status updated to "done"

Files changed:
- apps/cli/src/commands/next.command.ts: Display logic enhancements
- .taskmaster/tasks/tasks.json: Task 7 marked complete

* refactor(cli): extract eligibility logic to improve testability

Extract task eligibility calculation into separate helper methods:

- Add countEligibleTasks() to count tasks available for work
- Add areAllDependenciesDone() to check dependency completion
- Improve type assertion documentation for clarity

This refactoring improves testability, reusability, and maintainability
by separating concerns. The main getNextTask() method is now more
readable and the eligibility logic can be independently tested.

* docs(pr): add PR description for task/7-update-skip-display-logic

* docs(pr): rename description to PR #6

* perf(cli): optimize dependency lookup with Map for O(N) complexity

Use Map instead of Array.find() for dependency lookups in eligibility
calculation. Reduces time complexity from O(N²) to O(N) and fixes
correctness issue where missing dependencies were silently ignored.

Addresses PR #6 review feedback on performance optimization.

fix(tasks): ensure skip parameter treats parent+subtasks as single unit (#7)

* fix(tasks): ensure skip parameter treats parent+subtasks as single unit

Task: TM-009 - Write comprehensive unit tests for skip logic

Fixed critical bug where parent tasks with eligible subtasks were included
in the top-level eligible tasks array, causing incorrect skip counting.
Now the entire parent task hierarchy (parent + all eligible subtasks) is
treated as a single logical unit in the skip index.

Changes:
- Added logic to exclude parent tasks with eligible subtasks from eligibleTasks
- Updated JSDoc with "Parent Task Hierarchy" section and concrete examples
- Added 33 comprehensive unit tests covering all skip scenarios
- Tests verify skip behavior with subtasks, dependencies, priorities, and boundaries

Example behavior:
- Task 1 has subtasks 1.1, 1.2, 1.3; task 2 exists
- skip=0 → 1.1, skip=1 → 1.2, skip=2 → 1.3, skip=3 → task 2
- Previously skip=3 would incorrectly return task 1 (parent) instead of task 2

Test coverage:
- Basic skip indexing (0, 1, N)
- Boundary conditions (exceeds available, equals count, negative)
- Priority sorting with skip
- Duplicate priority tiebreakers (ID, dependency count)
- Dependency resolution with skip
- Subtasks from in-progress parents (critical fix)
- Backward compatibility (undefined defaults to 0)
- Tag filtering and status filtering
- Performance with large task sets (1000+ tasks)

All 33 tests pass successfully.

* docs(pr): add PR description and fix test type errors

Add comprehensive PR description for the skip logic bug fix that ensures
parent task hierarchies are treated as a single unit in the skip index.

Also fix TypeScript type errors in the new test file by adding all required
IStorage interface methods and completing Subtask interface fields.

* docs(pr): rename description to PR #7

* refactor(tasks): address PR review feedback - code quality improvements

Context:
- Task: PR #7 Review Feedback
- Source: #7

Notes:
- Extracted isSubtaskEligible() helper to eliminate duplication in subtask eligibility logic
- Refactored 2 error-handling tests to use idiomatic vitest rejects.toHaveProperty matcher
- Changes reduce code by 7 lines net while improving maintainability
- All 1,483 tests pass

test(cli): add JSON output tests for skip parameter (#8)

* test(cli): add JSON output tests for skip parameter

Task: TM-008 - Add skip parameter tests for JSON output

Subtasks: None (single logical unit)

Notes:
- Added 21 comprehensive integration tests for JSON output with --skip
- Enhanced parseJsonOutput helper to extract JSON from mixed output
- Tests cover edge cases: skip=0, skip exceeds available, empty task lists
- Verified compatibility with --tag, --silent, and --format options
- Validated backward compatibility with existing JSON structure
- All 40 tests passing (19 existing + 21 new)
- No code changes needed - existing JSON output was already correct
- Includes .taskmaster/tasks.json with task status updated to "done"

* docs(pr): add PR description for task/8-json-skip-tests

* docs(pr): rename description to PR #8

* test(cli): refactor JSON tests to apply review feedback

- Combine duplicate JSON structure validation tests using it.each
- Improve skip=0 comparison to verify entire object, not just task ID

feat(expand): add complexity threshold filtering to expand --all (#9)

* feat(expand): add complexity threshold filtering to expand --all

Add optional --threshold flag to filter tasks by minimum complexity score
(1-10) before expansion. Requires complexity report from analyze-complexity
command. Gracefully degrades when report is missing.

Features:
- MCP tool: threshold parameter in expand-all schema with range validation
- CLI: --threshold / -t flag for expand command
- Core: filter tasks by complexity score before expansion
- Tests: 5 test cases covering filtering edge cases
- UX: improved error messages guide users to run analyze-complexity
- Tests: removed global fs mock, use local spyOn with cleanup

Implementation details:
- Validates threshold is between 1-10, warns and ignores if invalid
- Logs before/after counts when threshold filtering is active
- Provides actionable error message when complexity report is missing
- Test isolation improved by removing global fs mock

* docs(pr): add PR description for complexity threshold filtering feature

* docs(pr): rename description to PR #9

* refactor(expand): optimize threshold filtering and improve test isolation

Simplify null check using loose equality and optimize O(N*M) complexity
to O(N+M) using Map for task analysis lookups. Add proper mock cleanup
in tests to prevent state leakage between test runs.

Changes:
- Use != null instead of !== null && !== undefined for concise null check
- Replace array.find() with Map.get() for O(1) lookup performance
- Add spy mockRestore() calls to threshold filtering tests

test(cli): fix integration tests for --skip parameter alignment (#10)

* test(cli): fix integration tests for --skip parameter alignment

Task: TM-010 - Write comprehensive integration tests for CLI

Subtasks:
- TM-010.1: Set up test infrastructure with temporary directories and test projects

Notes:
- Removed 8 incorrect tests that expected --tag to filter by task tags property
- --tag parameter is for file section selection (legacy format), not task tags filtering
- Fixed timeout syntax for parallel workflow tests (3 tests use 30s timeout)
- Adjusted default vitest timeouts: root 10s→5s, cli 30s→10s
- All 44 integration tests now passing
- Includes .taskmaster/tasks/tasks.json with task status update

* docs(pr): add PR description for task/10-cli-integration-tests

* docs(pr): rename description to PR #10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant