claude-code-workflow 6.3.54 → 7.0.0

package/.claude/skills/team-coordinate/roles/coordinator/commands/dispatch.md

@@ -0,0 +1,85 @@
+# Command: dispatch
+
+## Purpose
+
+Create task chains from dynamic dependency graphs. Unlike v4's static mode-to-pipeline mapping, team-coordinate builds pipelines from the task-analysis.json produced by Phase 1.
+
+## Phase 2: Context Loading
+
+| Input | Source | Required |
+|-------|--------|----------|
+| Task analysis | `<session-folder>/task-analysis.json` | Yes |
+| Session file | `<session-folder>/team-session.json` | Yes |
+| Role registry | `team-session.json#roles` | Yes |
+| Scope | User requirements description | Yes |
+
+## Phase 3: Task Chain Creation
+
+### Workflow
+
+1. **Read dependency graph** from `task-analysis.json#dependency_graph`
+2. **Topological sort** tasks to determine creation order
+3. **Validate** all task owners exist in role registry
+4. **For each task** (in topological order):
+
+```
+TaskCreate({
+  subject: "<PREFIX>-<NNN>",
+  owner: "<role-name>",
+  description: "<task description from task-analysis>\nSession: <session-folder>\nScope: <scope>\nInnerLoop: <true|false>",
+  blockedBy: [<dependency-list from graph>],
+  status: "pending"
+})
+```
+
+5. **Update team-session.json** with pipeline and tasks_total
+6. **Validate** created chain
+
+### Task Description Template
+
+Every task description includes session path and inner loop flag:
+
+```
+<task description>
+Session: <session-folder>
+Scope: <scope>
+InnerLoop: <true|false>
+```
+
+### InnerLoop Flag Rules
+
+| Condition | InnerLoop |
+|-----------|-----------|
+| Role has 2+ serial same-prefix tasks | true |
+| Role has 1 task | false |
+| Tasks are parallel (no dependency between them) | false |
+
+### Dependency Validation
+
+| Check | Criteria |
+|-------|----------|
+| No orphan tasks | Every task is reachable from at least one root |
+| No circular deps | Topological sort succeeds without cycle |
+| All owners valid | Every task owner exists in team-session.json#roles |
+| All blockedBy valid | Every blockedBy references an existing task subject |
+| Session reference | Every task description contains `Session: <session-folder>` |
+
+## Phase 4: Validation
+
+| Check | Criteria |
+|-------|----------|
+| Task count | Matches dependency_graph node count |
+| Dependencies | Every blockedBy references an existing task subject |
+| Owner assignment | Each task owner is in role registry |
+| Session reference | Every task description contains `Session:` |
+| Pipeline integrity | No disconnected subgraphs (warn if found) |
+
+## Error Handling
+
+| Scenario | Resolution |
+|----------|------------|
+| Circular dependency detected | Report cycle, halt task creation |
+| Owner not in role registry | Error, coordinator must fix roles first |
+| TaskCreate fails | Log error, report to coordinator |
+| Duplicate task subject | Skip creation, log warning |
+| Empty dependency graph | Error, task analysis may have failed |

package/.claude/skills/team-coordinate/roles/coordinator/commands/monitor.md

@@ -0,0 +1,296 @@
+# Command: monitor
+
+## Purpose
+
+Event-driven pipeline coordination with Spawn-and-Stop pattern. Adapted from v4 for dynamic roles -- role names are read from `team-session.json#roles` instead of hardcoded. Includes `handleAdapt` for mid-pipeline capability gap handling.
+
+## Constants
+
+| Constant | Value | Description |
+|----------|-------|-------------|
+| SPAWN_MODE | background | All workers spawned via `Task(run_in_background: true)` |
+| ONE_STEP_PER_INVOCATION | true | Coordinator does one operation then STOPS |
+| FAST_ADVANCE_AWARE | true | Workers may skip coordinator for simple linear successors |
+
+## Phase 2: Context Loading
+
+| Input | Source | Required |
+|-------|--------|----------|
+| Session file | `<session-folder>/team-session.json` | Yes |
+| Task list | `TaskList()` | Yes |
+| Active workers | session.active_workers[] | Yes |
+| Role registry | session.roles[] | Yes |
+
+**Dynamic role resolution**: Known worker roles are loaded from `session.roles[].name` rather than a static list. This is the key difference from v4.
+
+## Phase 3: Handler Routing
+
+### Wake-up Source Detection
+
+Parse `$ARGUMENTS` to determine handler:
+
+| Priority | Condition | Handler |
+|----------|-----------|---------|
+| 1 | Message contains `[<role-name>]` from session roles | handleCallback |
+| 2 | Contains "capability_gap" | handleAdapt |
+| 3 | Contains "check" or "status" | handleCheck |
+| 4 | Contains "resume", "continue", or "next" | handleResume |
+| 5 | None of the above (initial spawn after dispatch) | handleSpawnNext |
+
+---
+
+### Handler: handleCallback
+
+Worker completed a task. Verify completion, update state, auto-advance.
+
+```
+Receive callback from [<role>]
+  +- Find matching active worker by role (from session.roles)
+  +- Is this a progress update (not final)? (Inner Loop intermediate task completion)
+  |   +- YES -> Update session state, do NOT remove from active_workers -> STOP
+  +- Task status = completed?
+  |   +- YES -> remove from active_workers -> update session
+  |   |   +- -> handleSpawnNext
+  |   +- NO -> progress message, do not advance -> STOP
+  +- No matching worker found
+      +- Scan all active workers for completed tasks
+      +- Found completed -> process each -> handleSpawnNext
+      +- None completed -> STOP
+```
+
+**Fast-advance note**: A worker may have already spawned its successor via fast-advance. When processing a callback:
+1. Check if the expected next task is already `in_progress` (fast-advanced)
+2. If yes -> skip spawning that task, update active_workers to include the fast-advanced worker
+3. If no -> normal handleSpawnNext
+
+---
+
+### Handler: handleCheck
+
+Read-only status report. No pipeline advancement.
+
+**Output format**:
+
+```
+[coordinator] Pipeline Status
+[coordinator] Progress: <completed>/<total> (<percent>%)
+
+[coordinator] Execution Graph:
+  <visual representation of dependency graph with status icons>
+
+  done=completed  >>>=running  o=pending  .=not created
+
+[coordinator] Active Workers:
+  > <subject> (<role>) - running <elapsed> [inner-loop: N/M tasks done]
+
+[coordinator] Ready to spawn: <subjects>
+[coordinator] Commands: 'resume' to advance | 'check' to refresh
+```
+
+**Icon mapping**: completed=done, in_progress=>>>, pending=o, not created=.
+
+**Graph rendering**: Read dependency_graph from task-analysis.json, render each node with status icon. Show parallel branches side-by-side.
+
+Then STOP.
+
+---
+
+### Handler: handleResume
+
+Check active worker completion, process results, advance pipeline.
+
+```
+Load active_workers from session
+  +- No active workers -> handleSpawnNext
+  +- Has active workers -> check each:
+      +- status = completed -> mark done, log
+      +- status = in_progress -> still running, log
+      +- other status -> worker failure -> reset to pending
+      After processing:
+        +- Some completed -> handleSpawnNext
+        +- All still running -> report status -> STOP
+        +- All failed -> handleSpawnNext (retry)
+```
+
+---
+
+### Handler: handleSpawnNext
+
+Find all ready tasks, spawn workers in background, update session, STOP.
+
+```
+Collect task states from TaskList()
+  +- completedSubjects: status = completed
+  +- inProgressSubjects: status = in_progress
+  +- readySubjects: pending + all blockedBy in completedSubjects
+
+Ready tasks found?
+  +- NONE + work in progress -> report waiting -> STOP
+  +- NONE + nothing in progress -> PIPELINE_COMPLETE -> Phase 5
+  +- HAS ready tasks -> for each:
+      +- Is task owner an Inner Loop role AND that role already has an active_worker?
+      |   +- YES -> SKIP spawn (existing worker will pick it up via inner loop)
+      |   +- NO -> normal spawn below
+      +- TaskUpdate -> in_progress
+      +- team_msg log -> task_unblocked (team=<session-id>, NOT team name)
+      +- Spawn worker (see spawn tool call below)
+      +- Add to session.active_workers
+      Update session file -> output summary -> STOP
+```
+
+**Spawn worker tool call** (one per ready task):
+
+```
+Task({
+  subagent_type: "general-purpose",
+  description: "Spawn <role> worker for <subject>",
+  team_name: <team-name>,
+  name: "<role>",
+  run_in_background: true,
+  prompt: "<worker prompt from SKILL.md Coordinator Spawn Template>"
+})
+```
+
+---
+
+### Handler: handleAdapt
+
+Handle mid-pipeline capability gap discovery. A worker reports `capability_gap` when it encounters work outside its scope.
+
+**CONSTRAINT**: Maximum 5 worker roles per session (per coordinator/role.md). handleAdapt MUST enforce this limit.
+
+```
+Parse capability_gap message:
+  +- Extract: gap_description, requesting_role, suggested_capability
+  +- Validate gap is genuine:
+      +- Check existing roles in session.roles -> does any role cover this?
+      |   +- YES -> redirect: SendMessage to that role's owner -> STOP
+      |   +- NO -> genuine gap, proceed to role generation
+  +- CHECK ROLE COUNT LIMIT (MAX 5 ROLES):
+      +- Count current roles in session.roles
+      +- If count >= 5:
+          +- Attempt to merge new capability into existing role:
+              +- Find best-fit role by responsibility_type
+              +- If merge possible:
+                  +- Update existing role file with new capability
+                  +- Create task assigned to existing role
+                  +- Log via team_msg (type: warning, summary: "Capability merged into existing role")
+                  +- STOP
+              +- If merge NOT possible:
+                  +- PAUSE session
+                  +- Report to user:
+                     "Role limit (5) reached. Cannot generate new role for: <gap_description>
+                      Options:
+                      1. Manually extend an existing role
+                      2. Re-run team-coordinate with refined task to consolidate roles
+                      3. Accept limitation and continue without this capability"
+                  +- STOP
+  +- Generate new role:
+      1. Read specs/role-template.md
+      2. Fill template with capability details from gap description
+      3. Write new role file to <session-folder>/roles/<new-role>.md
+      4. Add to session.roles[]
+  +- Create new task(s):
+      TaskCreate({
+        subject: "<NEW-PREFIX>-001",
+        owner: "<new-role>",
+        description: "<gap_description>\nSession: <session-folder>\nInnerLoop: false",
+        blockedBy: [<requesting task if sequential>],
+        status: "pending"
+      })
+  +- Update team-session.json: add role, increment tasks_total
+  +- Spawn new worker -> STOP
+```
+
+---
+
+### Worker Failure Handling
+
+When a worker has unexpected status (not completed, not in_progress):
+
+1. Reset task -> pending via TaskUpdate
+2. Log via team_msg (type: error)
+3. Report to user: task reset, will retry on next resume
+
+### Fast-Advance Failure Recovery
+
+When coordinator detects a fast-advanced task has failed (task in_progress but no callback and worker gone):
+
+```
+handleCallback / handleResume detects:
+  +- Task is in_progress (was fast-advanced by predecessor)
+  +- No active_worker entry for this task
+  +- Original fast-advancing worker has already completed and exited
+  +- Resolution:
+      1. TaskUpdate -> reset task to pending
+      2. Remove stale active_worker entry (if any)
+      3. Log via team_msg (type: error, summary: "Fast-advanced task <ID> failed, resetting for retry")
+      4. -> handleSpawnNext (will re-spawn the task normally)
+```
+
+**Detection in handleResume**:
+
+```
+For each in_progress task in TaskList():
+  +- Has matching active_worker? -> normal, skip
+  +- No matching active_worker? -> orphaned (likely fast-advance failure)
+      +- Check creation time: if > 5 minutes with no progress callback
+      +- Reset to pending -> handleSpawnNext
+```
+
+**Prevention**: Fast-advance failures are self-healing. The coordinator reconciles orphaned tasks on every `resume`/`check` cycle.
+
+### Consensus-Blocked Handling
+
+When a worker reports `consensus_blocked` in its callback:
+
+```
+handleCallback receives message with consensus_blocked flag
+  +- Extract: divergence_severity, blocked_round, action_recommendation
+  +- Route by severity:
+      |
+      +- severity = HIGH
+      |   +- Create REVISION task:
+      |       +- Same role, same doc type, incremented suffix (e.g., DRAFT-001-R1)
+      |       +- Description includes: divergence details + action items from discuss
+      |       +- blockedBy: none (immediate execution)
+      |       +- Max 1 revision per task (DRAFT-001 -> DRAFT-001-R1, no R2)
+      |       +- If already revised once -> PAUSE, escalate to user
+      |   +- Update session: mark task as "revised", log revision chain
+      |
+      +- severity = MEDIUM
+      |   +- Proceed with warning: include divergence in next task's context
+      |   +- Log action items to wisdom/issues.md
+      |   +- Normal handleSpawnNext
+      |
+      +- severity = LOW
+          +- Proceed normally: treat as consensus_reached with notes
+          +- Normal handleSpawnNext
+```
+
+## Phase 4: Validation
+
+| Check | Criteria |
+|-------|----------|
+| Session state consistent | active_workers matches TaskList in_progress tasks |
+| No orphaned tasks | Every in_progress task has an active_worker entry |
+| Dynamic roles valid | All task owners exist in session.roles |
+| Completion detection | readySubjects=0 + inProgressSubjects=0 -> PIPELINE_COMPLETE |
+| Fast-advance tracking | Detect tasks already in_progress via fast-advance, sync to active_workers |
+| Fast-advance orphan check | in_progress tasks without active_worker entry -> reset to pending |
+
+## Error Handling
+
+| Scenario | Resolution |
+|----------|------------|
+| Session file not found | Error, suggest re-initialization |
+| Worker callback from unknown role | Log info, scan for other completions |
+| All workers still running on resume | Report status, suggest check later |
+| Pipeline stall (no ready, no running) | Check for missing tasks, report to user |
+| Fast-advance conflict | Coordinator reconciles, no duplicate spawns |
+| Fast-advance task orphaned | Reset to pending, re-spawn via handleSpawnNext |
+| Dynamic role file not found | Error, coordinator must regenerate from task-analysis |
+| capability_gap from completed role | Validate gap, generate role if genuine |
+| capability_gap when role limit (5) reached | Attempt merge into existing role, else pause for user |
+| consensus_blocked HIGH | Create revision task (max 1) or pause for user |
+| consensus_blocked MEDIUM | Proceed with warning, log to wisdom/issues.md |

package/.claude/skills/team-coordinate/roles/coordinator/role.md

@@ -0,0 +1,283 @@
+# Coordinator Role
+
+Orchestrate the team-coordinate workflow: task analysis, dynamic role generation, task dispatching, progress monitoring, session state. The sole built-in role -- all worker roles are generated at runtime.
+
+## Identity
+
+- **Name**: `coordinator` | **Tag**: `[coordinator]`
+- **Responsibility**: Analyze task -> Generate roles -> Create team -> Dispatch tasks -> Monitor progress -> Report results
+
+## Boundaries
+
+### MUST
+- Analyze user task to detect capabilities and build dependency graph
+- Dynamically generate worker roles from specs/role-template.md
+- Create team and spawn worker subagents in background
+- Dispatch tasks with proper dependency chains from task-analysis.json
+- Monitor progress via worker callbacks and route messages
+- Maintain session state persistence (team-session.json)
+- Handle capability_gap reports (generate new roles mid-pipeline)
+- Handle consensus_blocked HIGH verdicts (create revision tasks or pause)
+- Detect fast-advance orphans on resume/check and reset to pending
+
+### MUST NOT
+- Execute task work directly (delegate to workers)
+- Modify task output artifacts (workers own their deliverables)
+- Call implementation subagents (code-developer, etc.) directly
+- Skip dependency validation when creating task chains
+- Generate more than 5 worker roles (merge if exceeded)
+- Override consensus_blocked HIGH without user confirmation
+
+> **Core principle**: coordinator is the orchestrator, not the executor. All actual work is delegated to dynamically generated worker roles.
+
+---
+
+## Command Execution Protocol
+
+When coordinator needs to execute a command (analyze-task, dispatch, monitor):
+
+1. **Read the command file**: `roles/coordinator/commands/<command-name>.md`
+2. **Follow the workflow** defined in the command file (Phase 2-4 structure)
+3. **Commands are inline execution guides** - NOT separate agents or subprocesses
+4. **Execute synchronously** - complete the command workflow before proceeding
+
+Example:
+```
+Phase 1 needs task analysis
+  -> Read roles/coordinator/commands/analyze-task.md
+  -> Execute Phase 2 (Context Loading)
+  -> Execute Phase 3 (Task Analysis)
+  -> Execute Phase 4 (Output)
+  -> Continue to Phase 2
+```
+
+---
+
+## Entry Router
+
+When coordinator is invoked, first detect the invocation type:
+
+| Detection | Condition | Handler |
+|-----------|-----------|---------|
+| Worker callback | Message contains `[role-name]` from session roles | -> handleCallback |
+| Status check | Arguments contain "check" or "status" | -> handleCheck |
+| Manual resume | Arguments contain "resume" or "continue" | -> handleResume |
+| Capability gap | Message contains "capability_gap" | -> handleAdapt |
+| Interrupted session | Active/paused session exists in `.workflow/.team/TC-*` | -> Phase 0 (Resume Check) |
+| New session | None of above | -> Phase 1 (Task Analysis) |
+
+For callback/check/resume/adapt: load `commands/monitor.md` and execute the appropriate handler, then STOP.
+
+### Router Implementation
+
+1. **Load session context** (if exists):
+   - Scan `.workflow/.team/TC-*/team-session.json` for active/paused sessions
+   - If found, extract `session.roles[].name` for callback detection
+
+2. **Parse $ARGUMENTS** for detection keywords
+
+3. **Route to handler**:
+   - For monitor handlers: Read `commands/monitor.md`, execute matched handler section, STOP
+   - For Phase 0: Execute Session Resume Check below
+   - For Phase 1: Execute Task Analysis below
+
+---
+
+## Phase 0: Session Resume Check
+
+**Objective**: Detect and resume interrupted sessions before creating new ones.
+
+**Workflow**:
+1. Scan `.workflow/.team/TC-*/team-session.json` for sessions with status "active" or "paused"
+2. No sessions found -> proceed to Phase 1
+3. Single session found -> resume it (-> Session Reconciliation)
+4. Multiple sessions -> AskUserQuestion for user selection
+
+**Session Reconciliation**:
+1. Audit TaskList -> get real status of all tasks
+2. Reconcile: session.completed_tasks <-> TaskList status (bidirectional sync)
+3. Reset any in_progress tasks -> pending (they were interrupted)
+4. Detect fast-advance orphans (in_progress without recent activity) -> reset to pending
+5. Determine remaining pipeline from reconciled state
+6. Rebuild team if disbanded (TeamCreate + spawn needed workers only)
+7. Create missing tasks with correct blockedBy dependencies
+8. Verify dependency chain integrity
+9. Update session file with reconciled state
+10. Kick first executable task's worker -> Phase 4
+
+---
+
+## Phase 1: Task Analysis
+
+**Objective**: Parse user task, detect capabilities, build dependency graph, design roles.
+
+**Workflow**:
+
+1. **Parse user task description**
+
+2. **Clarify if ambiguous** via AskUserQuestion:
+   - What is the scope? (specific files, module, project-wide)
+   - What deliverables are expected? (documents, code, analysis reports)
+   - Any constraints? (timeline, technology, style)
+
+3. **Delegate to `commands/analyze-task.md`**:
+   - Signal detection: scan keywords -> infer capabilities
+   - Artifact inference: each capability -> default output type (.md)
+   - Dependency graph: build DAG of work streams
+   - Complexity scoring: count capabilities, cross-domain factor, parallel tracks
+   - Role minimization: merge overlapping, absorb trivial, cap at 5
+
+4. **Output**: Write `<session>/task-analysis.json`
+
+**Success**: Task analyzed, capabilities detected, dependency graph built, roles designed.
+
+**CRITICAL - Team Workflow Enforcement**:
+
+Regardless of complexity score or role count, coordinator MUST:
+- ✅ **Always proceed to Phase 2** (generate roles)
+- ✅ **Always create team** and spawn workers
+- ❌ **NEVER execute task work directly**, even for single-role low-complexity tasks
+- ❌ **NEVER skip team workflow** based on complexity assessment
+
+**Single-role execution is still team-based** - just with one worker. The team architecture provides:
+- Consistent message bus communication
+- Session state management
+- Artifact tracking
+- Fast-advance capability
+- Resume/recovery mechanisms
+
+---
+
+## Phase 2: Generate Roles + Initialize Session
+
+**Objective**: Create session, generate dynamic role files, initialize shared infrastructure.
+
+**Workflow**:
+
+1. **Generate session ID**: `TC-<slug>-<date>` (slug from first 3 meaningful words of task)
+
+2. **Create session folder structure**:
+   ```
+   .workflow/.team/<session-id>/
+   +-- roles/
+   +-- artifacts/
+   +-- wisdom/
+   +-- explorations/
+   +-- discussions/
+   +-- .msg/
+   ```
+
+3. **Call TeamCreate** with team name derived from session ID
+
+4. **Read `specs/role-template.md`** + `task-analysis.json`
+
+5. **For each role in task-analysis.json#roles**:
+   - Fill role template with:
+     - role_name, prefix, responsibility_type from analysis
+     - Phase 2-4 content from responsibility type reference sections in template
+     - inner_loop flag from analysis (true if role has 2+ serial tasks)
+     - Task-specific instructions from task description
+   - Write generated role file to `<session>/roles/<role-name>.md`
+
+6. **Register roles** in team-session.json#roles
+
+7. **Initialize shared infrastructure**:
+   - `wisdom/learnings.md`, `wisdom/decisions.md`, `wisdom/issues.md` (empty with headers)
+   - `explorations/cache-index.json` (`{ "entries": [] }`)
+   - `shared-memory.json` (`{}`)
+   - `discussions/` (empty directory)
+
+8. **Write team-session.json** with: session_id, task_description, status="active", roles, pipeline (empty), active_workers=[], created_at
+
+**Success**: Session created, role files generated, shared infrastructure initialized.
+
+---
+
+## Phase 3: Create Task Chain
+
+**Objective**: Dispatch tasks based on dependency graph with proper dependencies.
+
+Delegate to `commands/dispatch.md` which creates the full task chain:
+1. Reads dependency_graph from task-analysis.json
+2. Topological sorts tasks
+3. Creates tasks via TaskCreate with correct blockedBy
+4. Assigns owner based on role mapping from task-analysis.json
+5. Includes `Session: <session-folder>` in every task description
+6. Sets InnerLoop flag for multi-task roles
+7. Updates team-session.json with pipeline and tasks_total
+
+**Success**: All tasks created with correct dependency chains, session updated.
+
+---
+
+## Phase 4: Spawn-and-Stop
+
+**Objective**: Spawn first batch of ready workers in background, then STOP.
+
+**Design**: Spawn-and-Stop + Callback pattern, with worker fast-advance.
+- Spawn workers with `Task(run_in_background: true)` -> immediately return
+- Worker completes -> may fast-advance to next task OR SendMessage callback -> auto-advance
+- User can use "check" / "resume" to manually advance
+- Coordinator does one operation per invocation, then STOPS
+
+**Workflow**:
+1. Load `commands/monitor.md`
+2. Find tasks with: status=pending, blockedBy all resolved, owner assigned
+3. For each ready task -> spawn worker (see SKILL.md Coordinator Spawn Template)
+   - Use Standard Worker template for single-task roles
+   - Use Inner Loop Worker template for multi-task roles
+4. Output status summary with execution graph
+5. STOP
+
+**Pipeline advancement** driven by three wake sources:
+- Worker callback (automatic) -> Entry Router -> handleCallback
+- User "check" -> handleCheck (status only)
+- User "resume" -> handleResume (advance)
+
+---
+
+## Phase 5: Report + Next Steps
+
+**Objective**: Completion report and follow-up options.
+
+**Workflow**:
+1. Load session state -> count completed tasks, duration
+2. List all deliverables with output paths in `<session>/artifacts/`
+3. Include discussion summaries (if inline discuss was used)
+4. Summarize wisdom accumulated during execution
+5. Update session status -> "completed"
+6. Offer next steps: exit / view artifacts / extend with additional tasks
+
+**Output format**:
+
+```
+[coordinator] ============================================
+[coordinator] TASK COMPLETE
+[coordinator]
+[coordinator] Deliverables:
+[coordinator]   - <artifact-1.md> (<producer role>)
+[coordinator]   - <artifact-2.md> (<producer role>)
+[coordinator]
+[coordinator] Pipeline: <completed>/<total> tasks
+[coordinator] Roles: <role-list>
+[coordinator] Duration: <elapsed>
+[coordinator]
+[coordinator] Session: <session-folder>
+[coordinator] ============================================
+```
+
+---
+
+## Error Handling
+
+| Error | Resolution |
+|-------|------------|
+| Task timeout | Log, mark failed, ask user to retry or skip |
+| Worker crash | Respawn worker, reassign task |
+| Dependency cycle | Detect in task analysis, report to user, halt |
+| Task description too vague | AskUserQuestion for clarification |
+| Session corruption | Attempt recovery, fallback to manual reconciliation |
+| Role generation fails | Fall back to single general-purpose role |
+| capability_gap reported | handleAdapt: generate new role, create tasks, spawn |
+| All capabilities merge to one | Valid: single-role execution, reduced overhead |
+| No capabilities detected | Default to single general role with TASK prefix |