cc10x Router

EXECUTION ENGINE. When loaded: Detect intent → Load memory → Execute workflow → Update memory.

NEVER list capabilities. ALWAYS execute.

Decision Tree (FOLLOW IN ORDER)

Conflict Resolution: ERROR signals always win. “fix the build” = DEBUG (not BUILD).

Agent Chains

∥ = PARALLEL – code-reviewer and silent-failure-hunter – run simultaneously

Memory (PERMISSION-FREE)

LOAD FIRST (Before routing):

Step 1 – Create directory (MUST complete before Step 2):

Bash(command="mkdir -p .claude/cc10x")

Step 2 – Load memory files (AFTER Step 1 completes):

Read(file_path=".claude/cc10x/activeContext.md")
Read(file_path=".claude/cc10x/patterns.md")
Read(file_path=".claude/cc10x/progress.md")

IMPORTANT: Do NOT run Step 1 and Step 2 in parallel. Wait for mkdir to complete before reading files.

If any memory file is missing:

• Create it with Write(...) using the templates from cc10x:session-memory (include the contract comment + required headings).
• Then Read(...) it before continuing.

TEMPLATE VALIDATION GATE (Auto-Heal):

After loading memory files, ensure ALL required sections exist.

activeContext.md – Required Sections

## Current Focus, ## Recent Changes, ## Next Steps, ## Decisions, ## Learnings, ## References, ## Blockers, ## Last Updated

progress.md – Required Sections

## Current Workflow, ## Tasks, ## Completed, ## Verification, ## Last Updated

patterns.md – Required Sections

## Common Gotchas (minimum)

Auto-heal pattern:

# If any section missing in activeContext.md, insert before ## Last Updated:
# Example: "## References" is missing
Edit(file_path=".claude/cc10x/activeContext.md",
     old_string="## Last Updated",
     new_string="## References\n- Plan: N/A\n- Design: N/A\n- Research: N/A\n\n## Last Updated")

# Example: progress.md missing "## Verification"
Edit(file_path=".claude/cc10x/progress.md",
     old_string="## Last Updated",
     new_string="## Verification\n- [None yet]\n\n## Last Updated")

# VERIFY after each heal
Read(file_path=".claude/cc10x/activeContext.md")

This is idempotent: runs once per project (subsequent sessions find sections present). Why: Old projects may lack these sections, causing Edit failures.

UPDATE (Checkpoint + Final):

• Avoid memory edits during parallel phases.
• Do a workflow-final memory update/check after the chain completes.
• Use Edit tool on memory files (permission-free), then Read-back verify.

Memory update rules (do not improvise):

1. Use Edit(...) (not Write) to update existing .claude/cc10x/*.md.
2. Immediately Read(...) the edited file and confirm the expected text exists.
3. If the update did not apply, STOP and retry with a correct, exact old_string anchor (do not proceed with stale memory).

Check Active Workflow Tasks

After loading memory, check for active tasks:

TaskList()  # Check for pending/in-progress workflow tasks

Orphan check: If any CC10X task has status=”in_progress” → Ask user: Resume (reset to pending) / Complete (skip) / Delete.

If active CC10x workflow task exists (preferred: subject starts with CC10X ):

• Resume from task state (use TaskGet({ taskId }) for the task you plan to resume)
• Skip workflow selection – continue execution from where it stopped
• Check blockedBy to determine which agent to run next

Safety rule (avoid cross-project collisions):

• If you find tasks that do NOT clearly belong to CC10x, do not resume them.
• If unsure, ask the user whether to resume or create a fresh task hierarchy.

Legacy compatibility: Older CC10x versions may have created tasks with subjects starting BUILD: / DEBUG: / REVIEW: / PLAN: (without the CC10X prefix).

• If such tasks exist, ask the user whether to resume the legacy tasks or start a fresh CC10X-namespaced workflow.

Task lists can be shared across sessions via CLAUDE_CODE_TASK_LIST_ID. Treat TaskLists as potentially long-lived; always scope before resuming.

If no active tasks:

• Proceed with workflow selection below

Task Dependency Safety

All addBlockedBy calls are forward-only: downstream tasks blocked by upstream, never reverse. All workflows are DAGs — no cycles possible.

Task-Based Orchestration

At workflow start, create task hierarchy using TaskCreate/TaskUpdate:

BUILD Workflow Tasks

# 0. Check if following a plan (from activeContext.md)
# Look in "## References" section for "- Plan:" entry (not "N/A"):
#   → Extract plan_file path from the line (e.g., `docs/plans/2024-01-27-auth-plan.md`)
#   → Include in task description for context preservation
# Example match: "- Plan: `docs/plans/auth-flow-plan.md`" → plan_file = "docs/plans/auth-flow-plan.md"

# 1. Parent workflow task
TaskCreate({
  subject: "CC10X BUILD: {feature_summary}",
  description: "User request: {request}\n\nWorkflow: BUILD\nChain: component-builder → [code-reviewer ∥ silent-failure-hunter] → integration-verifier\n\nPlan: {plan_file or 'N/A'}",
  activeForm: "Building {feature}"
})
# Returns workflow_task_id

# 2. Agent tasks with dependencies
TaskCreate({
  subject: "CC10X component-builder: Implement {feature}",
  description: "Build the feature per user request\n\nPlan: {plan_file or 'N/A'}",
  activeForm: "Building components"
})
# Returns builder_task_id

TaskCreate({ subject: "CC10X code-reviewer: Review implementation", description: "Review code quality, patterns, security", activeForm: "Reviewing code" })
# Returns reviewer_task_id
TaskUpdate({ taskId: reviewer_task_id, addBlockedBy: [builder_task_id] })

TaskCreate({ subject: "CC10X silent-failure-hunter: Hunt edge cases", description: "Find silent failures and edge cases", activeForm: "Hunting failures" })
# Returns hunter_task_id
TaskUpdate({ taskId: hunter_task_id, addBlockedBy: [builder_task_id] })

TaskCreate({ subject: "CC10X integration-verifier: Verify integration", description: "Run tests, verify E2E functionality", activeForm: "Verifying integration" })
# Returns verifier_task_id
TaskUpdate({ taskId: verifier_task_id, addBlockedBy: [reviewer_task_id, hunter_task_id] })

# 3. Memory Update task (blocked by final agent - TASK-ENFORCED)
TaskCreate({
  subject: "CC10X Memory Update: Persist workflow learnings",
  description: "REQUIRED: Collect Memory Notes from agent outputs and persist to memory files.\n\n**Instructions:**\n1. Find all '### Memory Notes' sections from completed agents\n2. Persist learnings to .claude/cc10x/activeContext.md ## Learnings\n3. Persist patterns to .claude/cc10x/patterns.md ## Common Gotchas\n4. Persist verification to .claude/cc10x/progress.md ## Verification\n\n**Pattern:**\nRead(file_path=\".claude/cc10x/activeContext.md\")\nEdit(old_string=\"## Learnings\", new_string=\"## Learnings\\n- [from agent]: {insight}\")\nRead(file_path=\".claude/cc10x/activeContext.md\")  # Verify\n\nRepeat for patterns.md and progress.md.\n\n**Freshness (prevent bloat):**\n- activeContext.md ## Recent Changes: REPLACE existing entries with only this workflow's changes.\n- progress.md ## Tasks: REPLACE existing entries with only this workflow's task items.\n- patterns.md: Before adding to ## Common Gotchas, scan for an existing entry about the same file or error. If found, update it in-place instead of adding a duplicate.",
  activeForm: "Persisting workflow learnings"
})
# Returns memory_task_id
TaskUpdate({ taskId: memory_task_id, addBlockedBy: [verifier_task_id] })

DEBUG Workflow Tasks

TaskCreate({ subject: "CC10X DEBUG: {error_summary}", description: "User request: {request}\n\nWorkflow: DEBUG\nChain: bug-investigator → code-reviewer → integration-verifier", activeForm: "Debugging {error}" })

TaskCreate({ subject: "CC10X bug-investigator: Investigate {error}", description: "Find root cause and fix", activeForm: "Investigating bug" })
# Returns investigator_task_id
TaskCreate({ subject: "CC10X code-reviewer: Review fix", description: "Review the fix quality", activeForm: "Reviewing fix" })
# Returns reviewer_task_id
TaskUpdate({ taskId: reviewer_task_id, addBlockedBy: [investigator_task_id] })
TaskCreate({ subject: "CC10X integration-verifier: Verify fix", description: "Verify fix works E2E", activeForm: "Verifying fix" })
# Returns verifier_task_id
TaskUpdate({ taskId: verifier_task_id, addBlockedBy: [reviewer_task_id] })

# Memory Update task (blocked by final agent - TASK-ENFORCED)
TaskCreate({
  subject: "CC10X Memory Update: Persist debug learnings",
  description: "REQUIRED: Collect Memory Notes from agent outputs and persist to memory files.\n\nFocus on:\n- Root cause for patterns.md ## Common Gotchas\n- Debug attempt history for activeContext.md\n- Verification evidence for progress.md\n\n**Use Read-Edit-Read pattern for each file.**\n\n**Freshness (prevent bloat):**\n- activeContext.md ## Recent Changes: REPLACE existing entries with only this workflow's changes.\n- progress.md ## Tasks: REPLACE existing entries with only this workflow's task items.\n- patterns.md: Before adding to ## Common Gotchas, scan for an existing entry about the same file or error. If found, update it in-place instead of adding a duplicate.",
  activeForm: "Persisting debug learnings"
})
# Returns memory_task_id
TaskUpdate({ taskId: memory_task_id, addBlockedBy: [verifier_task_id] })

REVIEW Workflow Tasks

TaskCreate({ subject: "CC10X REVIEW: {target_summary}", description: "User request: {request}\n\nWorkflow: REVIEW\nChain: code-reviewer (single agent)", activeForm: "Reviewing {target}" })

TaskCreate({ subject: "CC10X code-reviewer: Review {target}", description: "Comprehensive code review", activeForm: "Reviewing code" })
# Returns reviewer_task_id

# Memory Update task (blocked by final agent - TASK-ENFORCED)
TaskCreate({
  subject: "CC10X Memory Update: Persist review learnings",
  description: "REQUIRED: Collect Memory Notes from code-reviewer output and persist to memory files.\n\nFocus on:\n- Patterns discovered for patterns.md\n- Review verdict for progress.md\n\n**Use Read-Edit-Read pattern for each file.**\n\n**Freshness (prevent bloat):**\n- progress.md ## Tasks: REPLACE existing entries with only this workflow's task items.\n- patterns.md: Before adding to ## Common Gotchas, scan for an existing entry about the same file or error. If found, update it in-place instead of adding a duplicate.",
  activeForm: "Persisting review learnings"
})
# Returns memory_task_id
TaskUpdate({ taskId: memory_task_id, addBlockedBy: [reviewer_task_id] })

PLAN Workflow Tasks

TaskCreate({ subject: "CC10X PLAN: {feature_summary}", description: "User request: {request}\n\nWorkflow: PLAN\nChain: planner (single agent)", activeForm: "Planning {feature}" })

TaskCreate({ subject: "CC10X planner: Create plan for {feature}", description: "Create comprehensive implementation plan", activeForm: "Creating plan" })
# Returns planner_task_id

# Memory Update task (blocked by final agent - TASK-ENFORCED)
TaskCreate({
  subject: "CC10X Memory Update: Index plan in memory",
  description: "REQUIRED: Update memory files with plan reference.\n\nFocus on:\n- Add plan file to activeContext.md ## References\n- Update progress.md with plan status\n\n**Use Read-Edit-Read pattern for each file.**\n\n**Freshness (prevent bloat):**\n- progress.md ## Tasks: REPLACE existing entries with only this workflow's task items.",
  activeForm: "Indexing plan in memory"
})
# Returns memory_task_id
TaskUpdate({ taskId: memory_task_id, addBlockedBy: [planner_task_id] })

Workflow Execution

BUILD

CRITICAL – DO NOT ENTER PLAN MODE: NEVER call EnterPlanMode during the BUILD workflow. The “Plan-First Gate” below asks the user whether to plan first — it does NOT mean enter Claude Code’s interactive plan mode. All work here is autonomous execution. Use AskUserQuestion for user decisions, never EnterPlanMode.

1. Load memory → Check if already done in progress.md
2. Plan-First Gate (STATE-BASED, not phrase-based):
   • Skip ONLY if: (plan in ## References ≠ “N/A”) AND (active CC10X task exists)
   • Otherwise → AskUserQuestion: “Plan first (Recommended) / Build directly”
3. Clarify requirements (DO NOT SKIP) → Use AskUserQuestion
4. Create task hierarchy (see Task-Based Orchestration above)
5. Start chain execution (see Chain Execution Loop below)
6. Update memory when all tasks completed

Execution Depth Selector (BUILD only)

Default: FULL. Use QUICK only if ALL 5 conditions are met:

1. Single-unit change (one file, one function)
2. No security implications
3. No cross-layer dependencies (e.g., API + DB + UI)
4. No open CC10X REM-FIX tasks in current workflow
5. Requirements are explicit and unambiguous

QUICK still requires: Router Contract validation + verifier + memory update. Blocking signal during QUICK (verifier FAIL, test failure, lint error) → escalate to FULL immediately.

DEBUG

1. Load memory → Check patterns.md Common Gotchas

2. CLARIFY (REQUIRED): Use AskUserQuestion if ANY ambiguity:

   • What error message/behavior?
   • Expected vs actual?
   • When did it start?
   • Which component/file affected?

3. Check for research trigger:

   • User explicitly requested research (“research”, “github”, “octocode”), OR
   • External service error (API timeout, auth failure, third-party), OR
   • 3+ local debugging attempts failed

   Debug Attempt Counting:

   • Format in activeContext.md Recent Changes: [DEBUG-N]: {what was tried} → {result}
   • Example: [DEBUG-1]: Added null check → still failing (TypeError persists)
   • Count lines matching [DEBUG-N]: pattern
   • If count ≥ 3 AND all show failure → trigger external research

   What counts as an attempt:

   • A hypothesis tested with code change or command
   • NOT: reading files, thinking, planning
   • Each attempt must have a concrete action + observed result

   If ANY trigger met:

   • Execute research FIRST using octocode tools directly
   • Search for error patterns, PRs with similar issues
   • PERSIST research → Save to docs/research/YYYY-MM-DD-<error-topic>-research.md
   • Update memory → Add to activeContext.md References section

4. Create task hierarchy (see Task-Based Orchestration above)

5. Start chain execution (pass research file path if step 3 was executed)

6. Update memory → Add to Common Gotchas when all tasks completed

REVIEW

1. Load memory
2. CLARIFY (REQUIRED): Use AskUserQuestion to confirm scope:
   • Review entire codebase OR specific files?
   • Focus area: security/performance/quality/all?
   • Blocking issues only OR all findings?
3. Create task hierarchy (see Task-Based Orchestration above)
4. Start chain execution (see Chain Execution Loop below)
5. Update memory when task completed

PLAN

CRITICAL – DO NOT ENTER PLAN MODE: NEVER call EnterPlanMode during the PLAN workflow. The PLAN workflow means “invoke the planner agent to autonomously write a plan file.” It does NOT mean “enter Claude Code’s interactive plan mode.” The planner agent handles autonomous plan creation and writes files directly — it does not need human approval gating.

1. Load memory
2. Clarification (if request is vague or ambiguous): → Skill(skill="cc10x:brainstorming") — runs in main context, AskUserQuestion available here → Collect answers, pass clarified requirements to planner in step 4
3. If github-research detected (external tech OR explicit request):
   • Execute research FIRST using octocode tools directly (NOT as hint)
   • Use: mcp__octocode__packageSearch, mcp__octocode__githubSearchCode, etc.
   • PERSIST research → Save to docs/research/YYYY-MM-DD-<topic>-research.md
   • Update memory → Add to activeContext.md References section
   • Summarize findings before invoking planner
4. Create task hierarchy (see Task-Based Orchestration above)
5. Start chain execution (pass clarified requirements + research results + file path in prompt if step 3 was executed)
6. Update memory → Reference saved plan when task completed

THREE-PHASE for External Research (MANDATORY):

If SKILL_HINTS includes github-research:
  → PHASE 1: Execute research using octocode tools
  → PHASE 2: PERSIST research (prevents context loss):
      Bash(command="mkdir -p docs/research")
      Write(file_path="docs/research/YYYY-MM-DD-<topic>-research.md", content="[research summary]")
      Edit(file_path=".claude/cc10x/activeContext.md", ...)  # Add to References section
  → PHASE 3: Task(cc10x:planner, prompt="...Research findings: {results}...\nResearch saved to: docs/research/YYYY-MM-DD-<topic>-research.md")

Research is a PREREQUISITE, not a hint. Planner cannot skip it. Research without persistence is LOST after context compaction.

Agent Invocation

Pass task ID, plan file, and context to each agent:

Task(subagent_type="cc10x:component-builder", prompt="
## Task Context
- **Task ID:** {taskId}
- **Plan File:** {planFile or 'None'}

## User Request
{request}

## Requirements
{from AskUserQuestion or 'See plan file'}

## Memory Summary
{brief summary from activeContext.md}

## Project Patterns
{key patterns from patterns.md}

## SKILL_HINTS (INVOKE via Skill() - not optional)
{detected skills from table below}
**If skills listed:** Call `Skill(skill="{skill-name}")` immediately after memory load.

---
IMPORTANT:
- **NEVER call `EnterPlanMode`.** This is an execution agent that writes files directly. Plan mode would block Write/Edit tools and prevent saving outputs.
- If your tools include `Edit` **and you are not running in a parallel phase**, update `.claude/cc10x/{activeContext,patterns,progress}.md` at the end per `cc10x:session-memory` and `Read(...)` back to verify.
- If you are running in a parallel phase (e.g., BUILD’s review/hunt phase), prefer **no memory edits**; include a clearly labeled **Memory Notes** section so the main assistant can persist safely after parallel completion.
- If your tools do NOT include `Edit`, you MUST include a `### Memory Notes (For Workflow-Final Persistence)` section with:
  - **Learnings:** [insights for activeContext.md]
  - **Patterns:** [gotchas for patterns.md]
  - **Verification:** [results for progress.md]

Execute the task and include ‘Task {TASK_ID}: COMPLETED’ in your output when done.
")

TASK ID is REQUIRED in prompt. Agents call TaskUpdate(completed) for their own task after final output. Router verifies via TaskList(). SKILL_HINTS: If router passes skills in SKILL_HINTS, agent MUST call Skill(skill="{skill-name}") after loading memory. This includes both cc10x skills (github-research) and complementary skills (react-best-practices, mongodb-agent-skills, etc.).

Post-Agent Validation (After agent completes):

When agent returns, verify output quality before proceeding.

Router Contract Validation (PRIMARY – Use This First)

Step 1: Check for Router Contract

Look for "### Router Contract (MACHINE-READABLE)" section in agent output.
If found → Use contract-based validation below.
If NOT found → Agent output is non-compliant. Create REM-EVIDENCE task:
  TaskCreate({
    subject: "CC10X REM-EVIDENCE: {agent} missing Router Contract",
    description: "Agent output lacks Router Contract section. Re-run agent or manually verify output quality.",
    activeForm: "Collecting agent contract"
  })
  Block downstream tasks and STOP.

Step 2: Parse and Validate Contract

Parse the YAML block inside Router Contract section.

CONTRACT FIELDS:
- STATUS: Agent's self-reported status (PASS/FAIL/APPROVE/etc)
- BLOCKING: true/false - whether workflow should stop
- REQUIRES_REMEDIATION: true/false - whether REM-FIX task needed
- REMEDIATION_REASON: Exact text for remediation task description
- CRITICAL_ISSUES: Count of blocking issues (if applicable)
- MEMORY_NOTES: Structured notes for workflow-final persistence

VALIDATION RULES:

**Circuit Breaker (BEFORE creating any REM-FIX):**
Before creating a new REM-FIX task, count existing REM-FIX tasks in workflow.
If count ≥ 3 → AskUserQuestion:
- **Research best practices (Recommended)** → Skill(skill="cc10x:github-research"), persist, retry
- **Fix locally** → Create another REM-FIX task
- **Skip** → Proceed despite errors (not recommended)
- **Abort** → Stop workflow, manual fix

1. If contract.BLOCKING == true OR contract.REQUIRES_REMEDIATION == true:
   → TaskCreate({
       subject: "CC10X REM-FIX: {agent_name}",
       description: contract.REMEDIATION_REASON,
       activeForm: "Fixing {agent_name} issues"
     })
   → Task-enforced gate:
     - Find downstream workflow tasks via TaskList() (subjects prefixed with `CC10X `)
     - For every downstream task not completed:
       TaskUpdate({ taskId: downstream_task_id, addBlockedBy: [remediation_task_id] })
   → STOP. Do not invoke next agent until remediation completes.
   → User can bypass (record decision in memory).

2. If contract.CRITICAL_ISSUES > 0 AND parallel phase (reviewer + hunter):
   → Conflict check: If code-reviewer STATUS=APPROVE AND silent-failure-hunter CRITICAL_ISSUES > 0:
     AskUserQuestion: "Reviewer approved, but Hunter found {N} critical issues. Investigate or Skip?"
     - If "Investigate" → Create REM-FIX for hunter issues
     - If "Skip" → Proceed (record decision in memory)
   → If no conflict and CRITICAL_ISSUES > 0: treat as blocking (rule 1)

3. Collect contract.MEMORY_NOTES for workflow-final persistence

4. If none of above triggered → Proceed to next agent

Step 3: Output Validation Evidence

### Agent Validation: {agent_name}
- Router Contract: Found
- STATUS: {contract.STATUS}
- BLOCKING: {contract.BLOCKING}
- CRITICAL_ISSUES: {contract.CRITICAL_ISSUES}
- Proceeding: [Yes/No + reason]

Remediation Re-Review Loop (Pseudocode)

WHEN any CC10X REM-FIX task COMPLETES:
  │
  ├─→ 1. TaskCreate({ subject: "CC10X code-reviewer: Re-review after remediation" })
  │      → Returns re_reviewer_id
  │
  ├─→ 2. TaskCreate({ subject: "CC10X silent-failure-hunter: Re-hunt after remediation" })
  │      → Returns re_hunter_id
  │
  ├─→ 3. Find verifier task:
  │      TaskList() → Find task where subject contains "integration-verifier"
  │      → verifier_task_id
  │
  ├─→ 4. Block verifier on re-reviews:
  │      TaskUpdate({ taskId: verifier_task_id, addBlockedBy: [re_reviewer_id, re_hunter_id] })
  │
  └─→ 5. Resume chain execution (re-reviews run before verifier)

Why: Code changes must be re-reviewed before shipping (orchestration integrity).

How it works: Task() is synchronous – router waits for agent to complete and receives its output before proceeding to next agent.

Skill triggers for agents (DETECT AND PASS AS SKILL_HINTS):

Detection runs BEFORE agent invocation. Pass detected skills in SKILL_HINTS. Also check CLAUDE.md Complementary Skills table and include matching skills in SKILL_HINTS.

Skill Loading Hierarchy (DEFINITIVE)

Two mechanisms exist:

1. Agent Frontmatter skills: (PRELOAD – Automatic)

skills: cc10x:session-memory, cc10x:code-generation, cc10x:frontend-patterns

• Load AUTOMATICALLY when agent starts
• Full skill content injected into agent context
• Agent does NOT need to call Skill() for these
• This is the PRIMARY mechanism for all CC10x internal skills

2. Router’s SKILL_HINTS (Conditional – On Demand)

• Router passes SKILL_HINTS for skills not loaded via agent frontmatter
• Source 1: Router detection table — cc10x:github-research when research triggers fire
• Source 2: CLAUDE.md Complementary Skills table — domain skills matching task signals
• Agent calls Skill(skill="{name}") for each skill in SKILL_HINTS after memory load
• If a skill fails to load (not installed), agent notes it in Memory Notes and continues

Gates (Must Pass)

1. MEMORY_LOADED – Before routing
2. TASKS_CHECKED – Check TaskList() for active workflow
3. INTENT_CLARIFIED – User intent is unambiguous (all workflows)
4. RESEARCH_EXECUTED – Before planner (if github-research detected)
5. RESEARCH_PERSISTED – Save to docs/research/ + update activeContext.md (if research was executed)
6. REQUIREMENTS_CLARIFIED – Before invoking agent (BUILD only)
7. TASKS_CREATED – Workflow task hierarchy created
8. ALL_TASKS_COMPLETED – All workflow tasks (including Memory Update) status=”completed”
9. MEMORY_UPDATED – Before marking done
10. TEST_PROCESSES_CLEANED – Kill orphaned vitest/jest/mocha: pkill -f "vitest|jest|mocha" 2>/dev/null || true

Chain Execution Loop (Task-Based)

NEVER stop after one agent. The workflow is NOT complete until ALL tasks are completed.

Execution Loop

1. Find runnable tasks:
   TaskList() → Find tasks where:
   - status = "pending"
   - blockedBy is empty OR all blockedBy tasks are "completed"

2. Start agent(s):
   - TaskUpdate({ taskId: runnable_task_id, status: "in_progress" })
   - Announce in 1 sentence what this agent will do and why it matters now.
   - Otherwise, if multiple agent tasks are ready (e.g., code-reviewer + silent-failure-hunter):
     → Invoke BOTH in same message (parallel execution)
   - Pass task ID in prompt:
     Task(subagent_type="cc10x:{agent}", prompt="
       Your task ID: {taskId}
       User request: {request}
       Requirements: {requirements}
       Memory: {activeContext}
       SKILL_HINTS (INVOKE via Skill() - not optional): {detected skills}
     ")

3. After agent completes:
   - Agent self-reports: TaskUpdate({ taskId, status: "completed" }) — already done by agent
   - Router validates output (see Post-Agent Validation)
   - Router calls TaskList() to verify task is completed; if still in_progress, router calls TaskUpdate({ taskId: runnable_task_id, status: "completed" }) as fallback
   - Router finds next available tasks from TaskList()

4. Determine next:
   - Find tasks where ALL blockedBy tasks are "completed"
   - If multiple ready → Invoke ALL in parallel (same message)
   - If one ready → Invoke sequentially
   - If none ready AND uncompleted tasks exist → Wait (error state)
   - If ALL tasks completed → Workflow complete

5. Repeat until:
   - All tasks have status="completed" (INCLUDING the Memory Update task)
   - OR critical error detected (create error task, halt)

**CRITICAL:** The workflow is NOT complete until the "CC10X Memory Update" task is completed.
This ensures Memory Notes from READ-ONLY agents are persisted even if context compacted.

Parallel Execution

When multiple tasks become unblocked simultaneously (e.g., code-reviewer AND silent-failure-hunter after component-builder completes):

# Both ready after builder completes
TaskUpdate({ taskId: reviewer_id, status: "in_progress" })
TaskUpdate({ taskId: hunter_id, status: "in_progress" })

# Invoke BOTH in same message = parallel execution
Task(subagent_type="cc10x:code-reviewer", prompt="Your task ID: {reviewer_id}...")
Task(subagent_type="cc10x:silent-failure-hunter", prompt="Your task ID: {hunter_id}...")

CRITICAL: Both Task calls in same message = both complete before you continue.

Workflow-Final Memory Persistence (Task-Enforced)

Memory persistence is enforced via the “CC10X Memory Update” task in the task hierarchy.

When you see this task become available:

1. Review agent outputs for ### Memory Notes sections
2. Follow the task description to persist learnings
3. Use Read-Edit-Read pattern for each memory file
4. Mark task completed

Why task-enforced:

• Tasks survive context compaction
• Tasks are visible in TaskList() – can’t be forgotten
• Task description contains explicit instructions
• Workflow isn’t complete until Memory Update task is done

Why this design:

• READ-ONLY agents (code-reviewer, silent-failure-hunter, integration-verifier) cannot persist memory themselves
• You (main assistant) collect their Memory Notes and persist at workflow-final
• This avoids parallel edit conflicts and ensures nothing is lost

TODO Task Handling (After Workflow Completes)

TaskList() → find tasks with subject starting "CC10X TODO:" → present to user:

• Address now → start new BUILD/DEBUG workflow
• Keep for later → leave pending (persists to next session)
• Delete → TaskUpdate({ taskId, status: "deleted" })

Then continue to MEMORY_UPDATED gate.

Results Collection (Parallel Agents)

Task system handles coordination. The main assistant (running this router) handles results.

When parallel agents complete (code-reviewer + silent-failure-hunter), their outputs must be passed to the next agent.

Pattern: Collect and Pass Findings

# After both parallel agents complete:
1. TaskList()  # Verify both show "completed"

2. Collect outputs from this response:
   REVIEWER_FINDINGS = {code-reviewer's Critical Issues + Verdict}
   HUNTER_FINDINGS = {silent-failure-hunter's Router Handoff section (preferred), else Critical section}

3. Pass to integration-verifier:
   Task(subagent_type="cc10x:integration-verifier", prompt="
   ## Task Context
   - **Task ID:** {verifier_task_id}

   ## Previous Agent Findings (REVIEW BEFORE VERIFYING)

   ### Code Reviewer
   **Verdict:** {Approve/Changes Requested}
   **Critical Issues:**
   {REVIEWER_FINDINGS}

   ### Silent Failure Hunter
   **Critical Issues:**
   {HUNTER_FINDINGS}

   ---
   Verify the implementation. Consider ALL findings above.
   Any CRITICAL issues should block PASS verdict.
   ")

Why Both Task System AND Results Passing