maestro-flow 0.4.10 → 0.4.11

package/.agents/skills/team-coordinate/SKILL.md

@@ -0,0 +1,268 @@
+---
+name: team-coordinate
+description: Universal team coordination skill with dynamic role generation. Uses team-worker agent architecture with role-spec files. Only coordinator is built-in -- all worker roles are generated at runtime as role-specs and spawned via team-worker agent. Beat/cadence model for orchestration. Triggers on "Team Coordinate ".
+allowed-tools: team_create(*), team_delete(*), send_message(*), task_create(*), task_update(*), task_list(*), task_get(*), agent(*), ask_user_question(*), read(*), write(*), edit(*), bash(*), glob(*), grep(*), mcp__ccw-tools__team_msg(*)
+---
+<!-- Open-standard mirror generated by scripts/build-agents-standard.mjs — do not edit; re-run after editing .claude/ source. -->
+
+
+# Team Coordinate 
+
+Universal team coordination skill: analyze task -> generate role-specs -> dispatch -> execute -> deliver. Only the **coordinator** is built-in. All worker roles are **dynamically generated** as lightweight role-spec files and spawned via the `team-worker` agent.
+
+
+## Architecture
+
+```
++---------------------------------------------------+
+|  invoke_skill(skill="team-coordinate")                 |
+|  args="task description"                           |
++-------------------+-------------------------------+
+                    |
+         Orchestration Mode (auto -> coordinator)
+                    |
+              Coordinator (built-in)
+              Phase 0-5 orchestration
+                    |
+    +-------+-------+-------+-------+
+    v       v       v       v       v
+ [team-worker agents, each loaded with a dynamic role-spec]
+  (roles generated at runtime from task analysis)
+
+  CLI Tools (callable by any worker):
+    maestro delegate --mode analysis  - analysis and exploration
+    maestro delegate --mode write     - code generation and modification
+```
+
+## Shared Constants
+
+| Constant | Value |
+|----------|-------|
+| Session prefix | `TC` |
+| Session path | `.workflow/.team/TC-<slug>-<date>/` |
+| Worker agent | `team-worker` |
+| Message bus | `mcp__ccw-tools__team_msg(session_id=<session-id>, ...)` |
+| CLI analysis | `maestro delegate --mode analysis` |
+| CLI write | `maestro delegate --mode write` |
+| Max roles | 5 |
+
+## Role Router
+
+This skill is **coordinator-only**. Workers do NOT invoke this skill -- they are spawned as `team-worker` agents directly.
+
+### Input Parsing
+
+Parse `$ARGUMENTS`. No `--role` needed -- always routes to coordinator.
+
+### Role Registry
+
+Only coordinator is statically registered. All other roles are dynamic, stored as role-specs in session.
+
+| Role | File | Type |
+|------|------|------|
+| coordinator | [roles/coordinator/role.md](roles/coordinator/role.md) | built-in orchestrator |
+| (dynamic) | `<session>/role-specs/<role-name>.md` | runtime-generated role-spec |
+
+### CLI Tool Usage
+
+Workers can use CLI tools for analysis and code operations:
+
+| Tool | Purpose |
+|------|---------|
+| maestro delegate --mode analysis | Analysis, exploration, pattern discovery |
+| maestro delegate --mode write | Code generation, modification, refactoring |
+
+### Dispatch
+
+Always route to coordinator. Coordinator reads `roles/coordinator/role.md` and executes its phases.
+
+### Orchestration Mode
+
+User just provides task description.
+
+**Invocation**: `invoke_skill(skill="team-coordinate", args="task description")`
+
+**Lifecycle**:
+```
+User provides task description
+  -> coordinator Phase 1: task analysis (detect capabilities, build dependency graph)
+  -> coordinator Phase 2: generate role-specs + initialize session
+  -> coordinator Phase 3: create task chain from dependency graph
+  -> coordinator Phase 4: spawn first batch workers (background) -> STOP
+  -> Worker executes -> send_message callback -> coordinator advances next step
+  -> Loop until pipeline complete -> Phase 5 report + completion action
+```
+
+**User Commands** (wake paused coordinator):
+
+| Command | Action |
+|---------|--------|
+| `check` / `status` | Output execution status graph, no advancement |
+| `resume` / `continue` | Check worker states, advance next step |
+| `revise <TASK-ID> [feedback]` | Revise specific task with optional feedback |
+| `feedback <text>` | Inject feedback into active pipeline |
+| `improve [dimension]` | Auto-improve weakest quality dimension |
+
+---
+
+## Coordinator Spawn Template
+
+### v2 Worker Spawn (all roles)
+
+When coordinator spawns workers, use `team-worker` agent with role-spec path:
+
+```
+delegate_subagent({
+  subagent_type: "team-worker",
+  description: "Spawn <role> worker",
+  team_name: <team-name>,
+  name: "<role>",
+  run_in_background: true,
+  prompt: `## Role Assignment
+role: <role>
+role_spec: <session-folder>/role-specs/<role>.md
+session: <session-folder>
+session_id: <session-id>
+team_name: <team-name>
+requirement: <task-description>
+inner_loop: <true|false>
+
+## Progress Milestones
+session_id: <session-id>
+Report progress via team_msg at natural phase boundaries (context loaded -> core work done -> verification).
+Report blockers immediately via team_msg type="blocker".
+Report completion via team_msg type="task_complete" after final send_message.
+
+Read role_spec file to load Phase 2-4 domain instructions.
+Execute built-in Phase 1 (task discovery) -> role-spec Phase 2-4 -> built-in Phase 5 (report).`
+})
+```
+
+**Inner Loop roles** (role has 2+ serial same-prefix tasks): Set `inner_loop: true`. The team-worker agent handles the loop internally.
+
+**Single-task roles**: Set `inner_loop: false`.
+
+---
+
+## Completion Action
+
+When pipeline completes (all tasks done), coordinator presents an interactive choice:
+
+```
+ask_user({
+  questions: [{
+    question: "Team pipeline complete. What would you like to do?",
+    header: "Completion",
+    multiSelect: false,
+    options: [
+      { label: "Archive & Clean (Recommended)", description: "Archive session, clean up team" },
+      { label: "Keep Active", description: "Keep session for follow-up work" },
+      { label: "Export Results", description: "Export deliverables to target directory, then clean" }
+    ]
+  }]
+})
+```
+
+### Action Handlers
+
+| Choice | Steps |
+|--------|-------|
+| Archive & Clean | Update session status="completed" -> delete_team -> output final summary with artifact paths |
+| Keep Active | Update session status="paused" -> output: "Resume with: invoke_skill(skill='team-coordinate', args='resume')" |
+| Export Results | ask_user(target path) -> copy artifacts to target -> Archive & Clean |
+
+---
+
+## Specs Reference
+
+| Spec | Purpose |
+|------|---------|
+| [specs/pipelines.md](specs/pipelines.md) | Dynamic pipeline model, task naming, dependency graph |
+| [specs/role-spec-template.md](specs/role-spec-template.md) | Template for dynamic role-spec generation |
+| [specs/quality-gates.md](specs/quality-gates.md) | Quality thresholds and scoring dimensions |
+| [specs/knowledge-transfer.md](specs/knowledge-transfer.md) | Context transfer protocols between roles |
+
+---
+
+## Session Directory
+
+```
+.workflow/.team/TC-<slug>-<date>/
++-- team-session.json           # Session state + dynamic role registry
++-- task-analysis.json          # Phase 1 output: capabilities, dependency graph
++-- role-specs/                 # Dynamic role-spec definitions (generated Phase 2)
+|   +-- <role-1>.md             # Lightweight: frontmatter + Phase 2-4 only
+|   +-- <role-2>.md
++-- artifacts/                  # All MD deliverables from workers
+|   +-- <artifact>.md
++-- .msg/                       # Team message bus + state
+|   +-- messages.jsonl          # Message log
+|   +-- meta.json               # Session metadata + cross-role state
++-- wisdom/                     # Cross-task knowledge
+|   +-- learnings.md
+|   +-- decisions.md
+|   +-- issues.md
++-- explorations/               # Shared explore cache
+|   +-- cache-index.json
+|   +-- explore-<angle>.json
++-- discussions/                # Inline discuss records
+|   +-- <round>.md
+```
+
+### team-session.json Schema
+
+```json
+{
+  "session_id": "TC-<slug>-<date>",
+  "task_description": "<original user input>",
+  "status": "active | paused | completed",
+  "team_name": "<team-name>",
+  "roles": [
+    {
+      "name": "<role-name>",
+      "prefix": "<PREFIX>",
+      "responsibility_type": "<type>",
+      "inner_loop": false,
+      "role_spec": "role-specs/<role-name>.md"
+    }
+  ],
+  "pipeline": {
+    "dependency_graph": {},
+    "tasks_total": 0,
+    "tasks_completed": 0
+  },
+  "active_workers": [],
+  "completed_tasks": [],
+  "completion_action": "interactive",
+  "created_at": "<timestamp>"
+}
+```
+
+---
+
+## Session Resume
+
+Coordinator supports `resume` / `continue` for interrupted sessions:
+
+1. Scan `.workflow/.team/TC-*/team-session.json` for active/paused sessions
+2. Multiple matches -> ask_user for selection
+3. Audit list_tasks -> reconcile session state <-> task status
+4. Reset in_progress -> pending (interrupted tasks)
+5. Rebuild team and spawn needed workers only
+6. Create missing tasks, set dependencies via update_task({ addBlockedBy })
+7. Kick first executable task -> Phase 4 coordination loop
+
+---
+
+## Error Handling
+
+| Scenario | Resolution |
+|----------|------------|
+| Unknown command | Error with available command list |
+| Dynamic role-spec not found | Error, coordinator may need to regenerate |
+| Command file not found | Fallback to inline execution |
+| CLI tool fails | Worker proceeds with direct implementation, logs warning |
+| Explore cache corrupt | Clear cache, re-explore |
+| Fast-advance spawns wrong task | Coordinator reconciles on next callback |
+| capability_gap reported | Coordinator generates new role-spec via handleAdapt |
+| Completion action fails | Default to Keep Active, log warning |

package/.agents/skills/team-coordinate/roles/coordinator/commands/analyze-task.md

@@ -0,0 +1,247 @@
+# Command: analyze-task
+
+## Purpose
+
+Parse user task description -> detect required capabilities -> build dependency graph -> design dynamic roles with role-spec metadata. Outputs structured task-analysis.json with frontmatter fields for role-spec generation.
+
+## CRITICAL CONSTRAINT
+
+**TEXT-LEVEL analysis only. MUST NOT read source code or explore codebase.**
+
+**Allowed:**
+- Parse user task description text
+- ask_user for clarification
+- Keyword-to-capability mapping
+- Write `task-analysis.json`
+
+If task context requires codebase knowledge, set `needs_research: true`. Phase 2 will spawn researcher worker.
+
+## When to Use
+
+| Trigger | Condition |
+|---------|-----------|
+| New task | Coordinator Phase 1 receives task description |
+| Re-analysis | User provides revised requirements |
+| Adapt | handleAdapt extends analysis for new capability |
+
+## Strategy
+
+- **Delegation**: Inline execution (coordinator processes directly)
+- **Mode**: Text-level analysis only (no codebase reading)
+- **Output**: `<session>/task-analysis.json`
+
+## Phase 2: Context Loading
+
+| Input | Source | Required |
+|-------|--------|----------|
+| Task description | User input from Phase 1 | Yes |
+| Clarification answers | ask_user results (if any) | No |
+| Session folder | From coordinator Phase 2 | Yes |
+
+## Phase 3: Task Analysis
+
+### Step 1: Signal Detection
+
+Scan task description for capability keywords:
+
+| Signal | Keywords | Capability | Prefix | Responsibility Type |
+|--------|----------|------------|--------|---------------------|
+| Research | investigate, explore, compare, survey, find, research, discover, benchmark, study | researcher | RESEARCH | orchestration |
+| Writing | write, draft, document, article, report, blog, describe, explain, summarize, content | writer | DRAFT | code-gen (docs) |
+| Coding | implement, build, code, fix, refactor, develop, create app, program, migrate, port | developer | IMPL | code-gen (code) |
+| Design | design, architect, plan, structure, blueprint, model, schema, wireframe, layout | designer | DESIGN | orchestration |
+| Analysis | analyze, review, audit, assess, evaluate, inspect, examine, diagnose, profile | analyst | ANALYSIS | read-only |
+| Testing | test, verify, validate, QA, quality, check, assert, coverage, regression | tester | TEST | validation |
+| Planning | plan, breakdown, organize, schedule, decompose, roadmap, strategy, prioritize | planner | PLAN | orchestration |
+
+**Multi-match**: A task may trigger multiple capabilities.
+
+**No match**: Default to a single `general` capability with `TASK` prefix.
+
+### Step 2: Artifact Inference
+
+Each capability produces default output artifacts:
+
+| Capability | Default Artifact | Format |
+|------------|-----------------|--------|
+| researcher | Research findings | `<session>/artifacts/research-findings.md` |
+| writer | Written document(s) | `<session>/artifacts/<doc-name>.md` |
+| developer | Code implementation | Source files + `<session>/artifacts/implementation-summary.md` |
+| designer | Design document | `<session>/artifacts/design-spec.md` |
+| analyst | Analysis report | `<session>/artifacts/analysis-report.md` |
+| tester | Test results | `<session>/artifacts/test-report.md` |
+| planner | Execution plan | `<session>/artifacts/execution-plan.md` |
+
+### Step 2.5: Key File Inference
+
+For each task, infer relevant files based on capability type and task keywords:
+
+| Capability | File Inference Strategy |
+|------------|------------------------|
+| researcher | Extract domain keywords → map to likely directories (e.g., "auth" → `src/auth/**`, `middleware/auth.ts`) |
+| developer | Extract feature/module keywords → map to source files (e.g., "payment" → `src/payments/**`, `types/payment.ts`) |
+| designer | Look for architecture/config keywords → map to config/schema files |
+| analyst | Extract target keywords → map to files under analysis |
+| tester | Extract test target keywords → map to source + test files |
+| writer | Extract documentation target → map to relevant source files for context |
+| planner | No specific files (planning is abstract) |
+
+**Inference rules:**
+- Extract nouns and verbs from task description
+- Match against common directory patterns (src/, lib/, components/, services/, utils/)
+- Include related type definition files (types/, *.d.ts)
+- For "fix bug" tasks, include error-prone areas (error handlers, validation)
+- For "implement feature" tasks, include similar existing features as reference
+
+### Step 3: Dependency Graph Construction
+
+Build a DAG of work streams using natural ordering tiers:
+
+| Tier | Capabilities | Description |
+|------|-------------|-------------|
+| 0 | researcher, planner | Knowledge gathering / planning |
+| 1 | designer | Design (requires context from tier 0 if present) |
+| 2 | writer, developer | Creation (requires design/plan if present) |
+| 3 | analyst, tester | Validation (requires artifacts to validate) |
+
+### Step 4: Complexity Scoring
+
+| Factor | Weight | Condition |
+|--------|--------|-----------|
+| Capability count | +1 each | Number of distinct capabilities |
+| Cross-domain factor | +2 | Capabilities span 3+ tiers |
+| Parallel tracks | +1 each | Independent parallel work streams |
+| Serial depth | +1 per level | Longest dependency chain length |
+
+| Total Score | Complexity | Role Limit |
+|-------------|------------|------------|
+| 1-3 | Low | 1-2 roles |
+| 4-6 | Medium | 2-3 roles |
+| 7+ | High | 3-5 roles |
+
+### Step 5: Role Minimization
+
+Apply merging rules to reduce role count (cap at 5).
+
+### Step 6: Role-Spec Metadata Assignment
+
+For each role, determine frontmatter and generation hints:
+
+| Field | Derivation |
+|-------|------------|
+| `prefix` | From capability prefix (e.g., RESEARCH, DRAFT, IMPL) |
+| `inner_loop` | `true` if role has 2+ serial same-prefix tasks |
+| `CLI tools` | Suggested, not mandatory — coordinator may adjust based on task needs |
+| `pattern_hint` | Reference pattern name from role-spec-template (research/document/code/analysis/validation) — guides coordinator's Phase 2-4 composition, NOT a rigid template selector |
+| `output_type` | `artifact` (new files in session/artifacts/) / `codebase` (modify existing project files) / `mixed` (both) — determines verification strategy in Behavioral Traits |
+| `message_types.success` | `<prefix>_complete` |
+| `message_types.error` | `error` |
+
+**output_type derivation**:
+
+| Task Signal | output_type | Example |
+|-------------|-------------|---------|
+| "write report", "analyze", "research" | `artifact` | New analysis-report.md in session |
+| "update docs", "modify code", "fix bug" | `codebase` | Modify existing project files |
+| "implement feature + write summary" | `mixed` | Code changes + implementation summary |
+
+## Phase 4: Output
+
+Write `<session-folder>/task-analysis.json`:
+
+```json
+{
+  "task_description": "<original user input>",
+  "capabilities": [
+    {
+      "name": "researcher",
+      "prefix": "RESEARCH",
+      "responsibility_type": "orchestration",
+      "tasks": [
+        {
+          "id": "RESEARCH-001",
+          "goal": "What this task achieves and why",
+          "steps": [
+            "step 1: specific action with clear verb",
+            "step 2: specific action with clear verb",
+            "step 3: specific action with clear verb"
+          ],
+          "key_files": [
+            "src/path/to/relevant.ts",
+            "src/path/to/other.ts"
+          ],
+          "upstream_artifacts": [],
+          "success_criteria": "Measurable completion condition",
+          "constraints": "Scope limits, focus areas"
+        }
+      ],
+      "artifacts": ["research-findings.md"]
+    }
+  ],
+  "dependency_graph": {
+    "RESEARCH-001": [],
+    "DRAFT-001": ["RESEARCH-001"],
+    "ANALYSIS-001": ["DRAFT-001"]
+  },
+  "roles": [
+    {
+      "name": "researcher",
+      "prefix": "RESEARCH",
+      "responsibility_type": "orchestration",
+      "task_count": 1,
+      "inner_loop": false,
+      "role_spec_metadata": {
+        "CLI tools": ["explore"],
+        "pattern_hint": "research",
+        "output_type": "artifact",
+        "message_types": {
+          "success": "research_complete",
+          "error": "error"
+        }
+      }
+    }
+  ],
+  "complexity": {
+    "capability_count": 2,
+    "cross_domain_factor": false,
+    "parallel_tracks": 0,
+    "serial_depth": 2,
+    "total_score": 3,
+    "level": "low"
+  },
+  "needs_research": false,
+  "artifacts": [
+    { "name": "research-findings.md", "producer": "researcher", "path": "artifacts/research-findings.md" }
+  ]
+}
+```
+
+## Complexity Interpretation
+
+**CRITICAL**: Complexity score is for **role design optimization**, NOT for skipping team workflow.
+
+| Complexity | Team Structure | Coordinator Action |
+|------------|----------------|-------------------|
+| Low (1-2 roles) | Minimal team | Generate 1-2 role-specs, create team, spawn workers |
+| Medium (2-3 roles) | Standard team | Generate role-specs, create team, spawn workers |
+| High (3-5 roles) | Full team | Generate role-specs, create team, spawn workers |
+
+**All complexity levels use team-worker architecture**:
+- Single-role tasks still spawn team-worker agent
+- Coordinator NEVER executes task work directly
+- Team infrastructure provides session management, message bus, fast-advance
+
+**Purpose of complexity score**:
+- ✅ Determine optimal role count (merge vs separate)
+- ✅ Guide dependency graph design
+- ✅ Inform user about task scope
+- ❌ NOT for deciding whether to use team workflow
+
+## Error Handling
+
+| Scenario | Resolution |
+|----------|------------|
+| No capabilities detected | Default to single `general` role with TASK prefix |
+| Circular dependency in graph | Break cycle at lowest-tier edge, warn |
+| Task description too vague | Return minimal analysis, coordinator will ask_user |
+| All capabilities merge into one | Valid -- single-role execution via team-worker |

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

@@ -0,0 +1,131 @@
+# Command: dispatch
+
+## Purpose
+
+Create task chains from dynamic dependency graphs. Builds pipelines from the task-analysis.json produced by Phase 1. Workers are spawned as team-worker agents with role-spec paths.
+
+## When to Use
+
+| Trigger | Condition |
+|---------|-----------|
+| After analysis | Phase 1 complete, task-analysis.json exists |
+| After adapt | handleAdapt created new roles, needs new tasks |
+| Re-dispatch | Pipeline restructuring (rare) |
+
+## Strategy
+
+- **Delegation**: Inline execution (coordinator processes directly)
+- **Inputs**: task-analysis.json + team-session.json
+- **Output**: create_task calls with dependency chains
+
+## 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):
+
+```
+create_task({
+  subject: "<PREFIX>-<NNN>",
+  description: "PURPOSE: <goal> | Success: <success_criteria>
+TASK:
+  - <step 1>
+  - <step 2>
+  - <step 3>
+CONTEXT:
+  - Session: <session-folder>
+  - Upstream artifacts: <artifact-1.md>, <artifact-2.md>
+  - Key files: <file1>, <file2>
+  - Shared state: team_msg(operation="get_state", session_id=<session-id>)
+EXPECTED: <deliverable path> + <quality criteria>
+CONSTRAINTS: <scope limits>
+---
+InnerLoop: <true|false>
+RoleSpec: <session-folder>/role-specs/<role-name>.md"
+})
+update_task({ taskId: "<PREFIX>-<NNN>", addBlockedBy: [<dependency-list from graph>], owner: "<role-name>" })
+```
+
+5. **Update team-session.json** with pipeline and tasks_total
+6. **Validate** created chain
+
+### Task Description Template
+
+Every task description includes structured fields for clarity:
+
+```
+PURPOSE: <goal from task-analysis.json#tasks[].goal> | Success: <success_criteria from task-analysis.json#tasks[].success_criteria>
+TASK:
+  - <step 1 from task-analysis.json#tasks[].steps[]>
+  - <step 2 from task-analysis.json#tasks[].steps[]>
+  - <step 3 from task-analysis.json#tasks[].steps[]>
+CONTEXT:
+  - Session: <session-folder>
+  - Upstream artifacts: <comma-separated list from task-analysis.json#tasks[].upstream_artifacts[]>
+  - Key files: <comma-separated list from task-analysis.json#tasks[].key_files[]>
+  - Shared state: team_msg(operation="get_state", session_id=<session-id>)
+EXPECTED: <artifact path from task-analysis.json#capabilities[].artifacts[]> + <quality criteria based on capability type>
+CONSTRAINTS: <constraints from task-analysis.json#tasks[].constraints>
+---
+InnerLoop: <true|false>
+RoleSpec: <session-folder>/role-specs/<role-name>.md
+```
+
+**Field Mapping**:
+- `PURPOSE`: From `task-analysis.json#capabilities[].tasks[].goal` + `success_criteria`
+- `TASK`: From `task-analysis.json#capabilities[].tasks[].steps[]`
+- `CONTEXT.Upstream artifacts`: From `task-analysis.json#capabilities[].tasks[].upstream_artifacts[]`
+- `CONTEXT.Key files`: From `task-analysis.json#capabilities[].tasks[].key_files[]`
+- `EXPECTED`: From `task-analysis.json#capabilities[].artifacts[]` + quality criteria
+- `CONSTRAINTS`: From `task-analysis.json#capabilities[].tasks[].constraints`
+
+### 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>` |
+| RoleSpec reference | Every task description contains `RoleSpec: <path>` |
+
+## 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 |
+| create_task fails | Log error, report to coordinator |
+| Duplicate task subject | Skip creation, log warning |
+| Empty dependency graph | Error, task analysis may have failed |