src/plugins/trackers/builtin/beads/index.test.ts (1)

447-539: Good coverage of the happy-path enrichment scenarios.

The three new tests cover the core enrichment flow, merge/dedup, and defensive filtering well. Consider adding tests for the two error/fallback branches in enrichTaskDependencies:

1. Non-zero exit from bd dep list — verifies the task's existing dependsOn is preserved and no crash occurs.
2. Unparseable JSON from bd dep list — verifies the catch fallback path.
3. dependency_type field variant — all current tests use the type field; a test using dependency_type instead would exercise the coalescing logic at line 479 of index.ts.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/plugins/trackers/builtin/beads/index.test.ts` around lines 447 - 539, Add
three unit tests exercising enrichTaskDependencies error/fallback branches: (1)
simulate a non-zero exit from the bd dep list spawn response and assert existing
task.dependsOn is preserved and no exception is thrown (use
createInitializedPlugin and plugin.getTasks as in other tests), (2) simulate
unparseable JSON stdout from bd dep list and assert the catch fallback preserves
existing dependsOn, and (3) simulate dependency rows that use dependency_type
instead of type to verify the coalescing logic in enrichTaskDependencies picks
up that field; reference the same mockSpawnResponses and mockSpawnArgs pattern
used in the existing tests to drive each scenario.

src/plugins/trackers/builtin/beads/index.ts (1)

432-455: Consider skipping enrichment for tasks whose dependencies are already fully populated.

Currently every task with dependency_count > 0 triggers a bd dep list subprocess, even when the initial bd list output already provided the full dependencies array. For large task sets this could double the number of subprocess calls unnecessarily.

♻️ Suggested optimisation

-    const tasksToEnrich = tasks.filter((t) => depCountMap.has(t.id));
+    const tasksToEnrich = tasks.filter((t) => {
+      const expectedCount = depCountMap.get(t.id);
+      if (expectedCount === undefined) return false;
+      // Skip if existing dependsOn already matches the advertised count
+      return (t.dependsOn?.length ?? 0) < expectedCount;
+    });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/plugins/trackers/builtin/beads/index.ts` around lines 432 - 455, Skip
calling enrichTaskDependencies for tasks whose dependencies are already
complete: in enrichDependencies, when building tasksToEnrich, check each
TrackerTask's dependencies array length against the raw bead's dependency_count
(use depCountMap or raw.dependency_count lookup) and only include tasks where
dependency_count is greater than the existing task.dependencies.length; keep the
batching/concurrency logic and still call this.enrichTaskDependencies(task) only
for those that need additional enrichment.

src/commands/run.tsx (1)

599-599: (default workers: 3) in help text may not reflect stored config.

The actual default resolves as storedConfig?.parallel?.maxWorkers ?? 3 (line 3119), so the stated "3" is only accurate when no maxWorkers is persisted. Users who have configured a different value in their project config would see a misleading hint.

✏️ Suggested wording

-  --parallel [N]      Force parallel execution with optional max workers (default workers: 3)
+  --parallel [N]      Force parallel execution with optional max workers (default: 3, or value from config)

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/run.tsx` at line 599, The help string that currently reads
"--parallel [N]      Force parallel execution with optional max workers (default
workers: 3)" is misleading because the real default is computed as
storedConfig?.parallel?.maxWorkers ?? 3; update the help text generation in
src/commands/run.tsx to reflect the actual default by computing the effective
default (e.g., const effectiveDefault = storedConfig?.parallel?.maxWorkers ?? 3)
and inserting that value into the help string or rewording to "default: config
value or 3" so the displayed hint matches the value used at runtime.