feat: improve taskMaestro watch mode status detection accuracy

[JeremyDev87]

Purpose

The current taskMaestro watch mode misclassifies stuck/errored workers as "working" because it only checks the last 5-8 lines of capture-pane output and relies on the OMC status bar's "thinking" indicator. This leads to workers remaining stuck without intervention.

Background

Observed in 2026-03-22 Wave 4 execution:

• Pane 2 (feat(mcp): session-isolated context documents to prevent multi-session overwrites #843) had a test failure (Cannot find package '@nestjs/common') due to missing node_modules in worktree
• The error message was at the TOP of the visible pane (line ~10-15), but the status check only read the BOTTOM 5-8 lines
• OMC status bar showed thinking (Claude generating error recovery response), which the watch classified as "working"
• Result: worker was stuck for multiple watch cycles before manual intervention

Root Cause Chain

capture-pane tail -8  →  Only sees: OMC status bar + prompt (❯)
                     →  Sees "thinking" in status bar
                     →  Classifies as "working" ✗
                     →  Misses "FAIL" / "Error:" on line 10-15
                     →  No nudge sent
                     →  Worker stays stuck

Changes

• .claude/skills/taskmaestro/SKILL.md — Enhance status detection in watch and status subcommands

Solution: Two-Pass Status Detection

Current (broken)

# Only checks last 8 lines
CAPTURED=$(tmux capture-pane -t "$PANE" -p -S -30 | tail -8)
if echo "$CAPTURED" | grep -q "thinking"; then STATUS="working"; fi

Proposed (two-pass)

# Pass 1: Error scan (broad range — last 30 lines)
FULL_CAPTURE=$(tmux capture-pane -t "$PANE" -p -S -30)
ERROR_SCAN=$(echo "$FULL_CAPTURE" | grep -iE "FAIL|Error:|Cannot find|fatal:|AssertionError|panic|ENOENT")

# Pass 2: Activity check (last 8 lines for prompt/thinking)
TAIL_CAPTURE=$(echo "$FULL_CAPTURE" | tail -8)
HAS_THINKING=$(echo "$TAIL_CAPTURE" | grep -c "thinking\|Running\|Inferring\|Brewing")
HAS_PROMPT=$(echo "$TAIL_CAPTURE" | grep -cE "⏵⏵|❯")

# Classification logic
if [ -n "$ERROR_SCAN" ] && [ "$HAS_PROMPT" -gt 0 ] && [ "$HAS_THINKING" -eq 0 ]; then
  STATUS="error_idle"   # Error visible + at prompt + not thinking → STUCK
elif [ -n "$ERROR_SCAN" ] && [ "$HAS_THINKING" -gt 0 ]; then
  STATUS="error_recovering"  # Error visible + thinking → give it one more cycle
elif [ "$HAS_THINKING" -gt 0 ]; then
  STATUS="working"      # Thinking, no errors → normal
elif [ "$HAS_PROMPT" -gt 0 ]; then
  STATUS="idle"          # At prompt, not thinking, no errors → idle
else
  STATUS="unknown"
fi

Status Classification Table

Error Visible	Thinking	At Prompt	Classification	Action
No	Yes	-	working	None
No	No	Yes	idle	Nudge if 2+ cycles
Yes	No	Yes	error_idle	Nudge immediately
Yes	Yes	-	error_recovering	Wait 1 cycle, then nudge
No	No	No	crashed	Alert conductor

Additional: Worktree Dependency Pre-check

Add to start subcommand after worktree creation:

# Pre-install dependencies in worktrees that have package.json
for WT in $WORKTREES; do
  if [ -f "$WT/package.json" ] && [ ! -d "$WT/node_modules" ]; then
    # Symlink node_modules from main repo if monorepo
    ln -s "$REPO/node_modules" "$WT/node_modules" 2>/dev/null || true
    # Or for monorepos with workspaces:
    cd "$WT" && yarn install --frozen-lockfile 2>/dev/null &
  fi
done

Acceptance Criteria

• Two-pass status detection: error scan (30 lines) + activity check (8 lines)
• error_idle state detected and nudged immediately (not waiting 2 cycles)
• error_recovering state given 1 extra cycle grace period before nudge
• Error patterns include: FAIL, Error:, Cannot find, fatal:, AssertionError, ENOENT
• OMC "thinking" alone no longer sufficient to classify as "working" when errors present
• Optional: worktree dependency pre-check (symlink or install node_modules)
• SKILL.md watch and status subcommands updated
• Existing non-error behavior unchanged

References

• taskMaestro skill: .claude/skills/taskmaestro/SKILL.md
• Related: feat: auto-nudge stuck workers with 'continue' in taskMaestro watch mode #861 (auto-nudge stuck workers — this issue improves detection accuracy for that feature)
• Incident: 2026-03-22 Wave 4 pane 2 misclassified as "working" for 3+ watch cycles

[JeremyDev87]

Additional Detection Gap: Duration-Based Stall Detection

Discovered: 2026-03-22 Wave A pane 4 (#842)

Problem

Worker showed ✽ Implementing service/serializer/parser… (5m 4s) with a visible spinner, which the 2-pass detection classified as WORKING. But the worker was actually stalled — same step for 5+ minutes with no token count increase.

Root Cause

Current detection only checks presence of activity indicators (spinner text, "thinking"). It does NOT track:

• Duration on the same step
• Token count changes between cycles
• Step progress (same step name across consecutive checks)

Proposed Addition to 2-pass Detection

3rd pass: Duration/progress tracking

For each watch cycle, record per-worker:
  - current_step (extracted from spinner text)
  - token_count (from OMC status bar)
  - timestamp

Compare with previous cycle:
  - Same step + same token count for 2+ cycles → STALLED
  - Same step + increasing tokens → WORKING (slow but progressing)
  - Different step → WORKING (normal progress)

Updated Classification Table

Error	Thinking/Spinner	Duration	Classification
No	Yes	< 5min or tokens changing	working
No	Yes	≥ 5min AND tokens unchanged	stalled → nudge
No	No	-	idle → nudge if 2+ cycles

This complements the existing 2-pass (error scan + activity check) with a 3rd pass for temporal analysis.

[JeremyDev87]

Additional Detection Gap: Active vs Completed Spinner Discrimination

Discovered: 2026-03-22 Wave A pane 3 (#840)

Problem

Worker showed ✻ Crunched for 2m 10s (past tense completion message) but detection matched the spinner unicode ✻ and classified as WORKING. Worker was actually idle.

Active vs Completed Patterns

Pattern	Meaning	Example
✻ Verb-ing… (Xm · ↓ tokens)	ACTIVE — currently processing	✻ Implementing… (2m · ↓ 5.3k tokens)
✻ Past-tense for Xm Ys	COMPLETED — finished, now idle	✻ Crunched for 2m 10s
✻ Verb-ed for Xm Ys	COMPLETED	✻ Sautéed for 5m 7s

Fix

Match active spinners by requiring ongoing indicators:

# WRONG: just check for spinner unicode
SPINNER=$(echo "$FULL" | grep -oE "✽|✳|✶|✻|✢")

# RIGHT: require active pattern (verb-ing + duration with token stream)
ACTIVE_SPINNER=$(echo "$FULL" | grep -E "(✽|✳|✶|✻|✢).*\.\.\." | grep -E "· ↓|· thinking|tokens" | head -1)

Key discriminators for ACTIVE:

• … (ellipsis) after verb = ongoing
• · ↓ or · thinking = streaming/thinking
• Verb ends in -ing = present participle

Key discriminators for COMPLETED:

• for Xm Ys without ellipsis = past tense
• Verb is past tense (Crunched, Sautéed, Brewed, Worked)

[JeremyDev87]

ROOT CAUSE FOUND: Unicode Ellipsis Mismatch

This is the root cause of ALL active spinner misclassification in this session.

Problem

Claude Code spinners use … (U+2026, single unicode ellipsis character), but the grep pattern used \.\.\. which only matches ... (three literal dots).

# BROKEN: never matches Claude Code output
grep -E "\.\.\." | grep -E "· ↓|· ↑"

# FIXED: matches unicode ellipsis
grep -E "…" | grep -E "· ↓|· ↑"
# or
grep -E "(\.\.\.|…)" | grep -E "· ↓|· ↑"

Impact

Every active spinner check in this session failed silently:

• ✽ Cascading… (3m · ↑ 5.1k tokens) → classified as IDLE (not ACTIVE)
• ✳ Running tests… (1m · ↓ 433 tokens) → classified as IDLE
• Multiple unnecessary nudges sent to working panes

Fix for #864 implementation

The active spinner pattern MUST use unicode ellipsis:

ACTIVE=$(echo "$FULL" | grep -E "…" | grep -E "· ↓|· ↑|· thinking|tokens" | head -1)