bug: expand ignores recommendedSubtasks: 0 from the complexity report and creates 5 subtasks instead

Description

When analyze-complexity assigns recommendedSubtasks: 0 to a task — its way of saying "this task is simple enough, it does not need expansion" — expand and expand --all discard that value and generate defaultSubtasks (5) subtasks instead.

The cause is a truthy check on a value that is legitimately 0.

File: scripts/modules/task-manager/expand-task.js#L186-L207

const explicitNumSubtasks = parseInt(numSubtasks, 10);
if (!Number.isNaN(explicitNumSubtasks) && explicitNumSubtasks >= 0) {
    finalSubtaskCount = explicitNumSubtasks;                       // correct: >= 0
} else if (taskAnalysis?.recommendedSubtasks) {
    // 0 is falsy -> this branch is skipped when recommendedSubtasks === 0
    finalSubtaskCount = parseInt(taskAnalysis.recommendedSubtasks, 10);
} else {
    finalSubtaskCount = getDefaultSubtasks(session);               // 0 lands here -> 5
}
if (Number.isNaN(finalSubtaskCount) || finalSubtaskCount < 0) {
    finalSubtaskCount = 3;
}

Note that the branch directly above gets this right: the explicit --num flag is accepted via >= 0, so --num=0 behaves differently from a complexity report saying 0. The Number.isNaN || < 0 guard below does not catch the case either, because by then the value is a perfectly valid 5.

The schema explicitly permits zero — recommendedSubtasks: z.number().int().nonnegative() — so 0 is a value the analysis step is expected to produce, not a malformed one.

This is not the same bug as #1287. That PR (merged 2025-10-11, shipped well before 0.43.1) fixed expand_all never computing and passing complexityReportPath, so taskAnalysis was undefined for every task and the report was ignored wholesale. The report now arrives correctly; this issue is about the report arriving, containing 0, and that specific value being dropped. The user-visible symptom is the same ("5 subtasks instead of the recommendation"), which makes the two easy to confuse.

Steps to Reproduce

Deterministic version, without needing an AI call to produce a 0:

1. Run task-master analyze-complexity on a project.
2. Edit .taskmaster/reports/task-complexity-report.json and set "recommendedSubtasks": 0 for one task.
3. Run task-master expand --id=<that task id>.

Alternatively, run task-master analyze-complexity on a project containing trivial tasks and wait for the model to assign 0 on its own, then run task-master expand --all.

Expected Behavior

recommendedSubtasks: 0 is honoured. The task is left unexpanded and, ideally, reported as skipped — that is what the analysis step meant by 0.

Actual Behavior

The value is ignored, the default of 5 is used, and the task is expanded into 5 subtasks. The log states:

Using default number of subtasks: 5

which is misleading — a recommendation was present and was silently discarded, and the message reads as if no report existed at all.

Suggested Fix

The condition needs a null check rather than a truthy check:

} else if (taskAnalysis?.recommendedSubtasks != null) {
    finalSubtaskCount = parseInt(taskAnalysis.recommendedSubtasks, 10);

That alone makes 0 reach finalSubtaskCount, and the < 0 guard already lets it pass. What should happen next is a design decision I would rather leave to you: sending a "generate 0 subtasks" request to the model is wasteful and its result is not obvious, so skipping expansion for that task entirely — and counting it as skipped in the expand --all summary — seems the more useful behaviour. Happy to open a PR for whichever variant you prefer.

Worth checking as part of the same fix: whether expand --all has a matching filter, so that tasks recommended at 0 are skipped before any AI call is made rather than after.

Environment

• Task Master version: 0.43.1 (current latest on npm). Also verified present in 1.1.0-rc.0 and in the current main branch source.
• Node.js version: 24.19.0
• Operating system: Ubuntu 24.04 LTS (devcontainer)
• IDE (if applicable): VS Code

Additional Context

Verified against three artifacts: the published 0.43.1 bundle, the 1.1.0-rc.0 prerelease bundle, and the unminified source on main — the condition is identical in all three.