orch discovery hard-crashes (0/0 tasks) with an opaque, self-contradictory error when a task lists an unsatisfiable/not-in-batch dependency

[HenryLach]

Summary

/orch (Runtime V2) batch discovery hard-crashes — killing the entire batch — when a targeted task's ## Dependencies block references a task that is neither complete nor included in the batch (e.g. a soft/"coordinate"/future/cross-epic reference). Instead of gracefully blocking or skipping the affected task, planning fails with 0/0 tasks and an opaque, self-contradictory error. Independent, fully-schedulable tasks in the same batch are killed as collateral.

The inadequate error reporting is arguably the bigger problem: recovery took ~10 minutes of log/worktree/structural forensics only because the error named nothing — the actual fix was 30 seconds.

Environment

• taskplane 0.30.4
• @earendil-works/pi-coding-agent 0.82.1
• Windows (git-bash)

Repro

1. One batch targeting two tasks: Task A whose ## Dependencies lists Task B, where B is NOT complete and NOT in the batch; and Task C with no dependencies.
2. orch_start(<A/PROMPT.md> <C/PROMPT.md>).
3. Batch ends in ~14s, phase failed, 0/0 tasks.

Observed

• Batch summary: Result: 0/0 tasks succeeded, Phase: failed, Incidents → Errors: "Discovery had fatal errors — cannot proceed".
• Blast radius: Task C (zero deps, perfectly schedulable) is killed too — discovery does not isolate per-task planning failures.
• Reporting is inadequate:
  1. The error names no offending task and no dependency — just "Discovery had fatal errors."
  2. 0/0 tasks erases the fact that 2 tasks were targeted.
  3. The engine stderr log (.pi/telemetry/<batch>-engine-worker-stderr.log) contains exactly one line — [orch] batch/<id>: starting batch planning — the actual exception is swallowed (no message, no stack).
  4. The summary is self-contradictory: Incidents → Errors: "Discovery had fatal errors — cannot proceed" appears directly above Recommendations: "No recommendations — batch ran smoothly."

Expected

• A dependency on a not-done / not-in-batch task is a normal condition (soft/"coordinate"/future references are common in hand-authored PROMPTs). Discovery should fail soft, per task: mark Task A blocked (with a reason) or skipped, and still schedule Task C.
• If the batch must fail, the error must be actionable, naming the task and the unsatisfied dependency, e.g. "TP-1609 depends on TP-1326, which is not complete and not included in this batch."
• The planning exception (message + stack) should be surfaced in the stderr log and/or summary, and the summary's Recommendations must not claim "ran smoothly" when discovery had fatal errors.

Root cause (inferred) + workaround

In a real batch, TP-1609 listed TP-1326 (a soft "coordinate" reference — Not Started, not in the batch) in its hard ## Dependencies. Discovery crashed as above. Reclassifying TP-1326 as a non-blocking note — leaving only satisfied/in-batch tasks in ## Dependencies — made discovery succeed and both lanes run. Strong evidence the unsatisfiable dependency is the trigger.

Impact

A single soft-dependency metadata quirk in one hand-authored PROMPT takes down an entire batch (including unrelated tasks) with an error that provides no path to diagnosis. Robustness and observability defect.

Suggested fixes

• Per-task fail-soft in discovery (block/skip the offending task; schedule the rest).
• Actionable planning errors that name the task + unsatisfied dependency.
• Stop swallowing the planning exception; log message + stack.
• Fix the summary generator so Recommendations is consistent with Incidents.
• (Optionally) distinguish "hard dep" from "coordinate/soft reference" in the task-file schema so soft references never enter the scheduling graph — see the companion task-format-resilience issue.