mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-03-30 20:21:09 +08:00
- team-lifecycle-v4: executor inner_loop true→dynamic, add dynamicImplDispatch for PLAN-001 callback - team-testing: executor inner_loop true→dynamic for comprehensive pipeline parallel TESTRUN - team-quality-assurance: executor inner_loop true→dynamic for full mode parallel QARUN - team-perf-opt: optimizer inner_loop true→dynamic for fan-out/independent parallel IMPL branches - team-arch-opt: refactorer inner_loop true→dynamic for fan-out/independent parallel REFACTOR branches - team-coordinate: fix dependency_graph schema mismatch, needs_research sequencing, handleSpawnNext role→task level check, add output_tag to template, precise inner_loop rules All handleSpawnNext now read task description InnerLoop: field instead of role-level default, enabling same-role workers to run in parallel when tasks have no mutual dependencies. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2.9 KiB
2.9 KiB
Pipeline Definitions — Team Coordinate
Dynamic Pipeline Model
team-coordinate does NOT have a static pipeline. All pipelines are generated at runtime from task-analysis.json based on the user's task description.
Pipeline Generation Process
Phase 1: analyze-task.md
-> Signal detection -> capability mapping -> dependency graph
-> Output: task-analysis.json
Phase 2: dispatch.md
-> Read task-analysis.json dependency graph
-> Create TaskCreate entries per dependency node
-> Set blockedBy chains from graph edges
-> Output: TaskList with correct DAG
Phase 3-N: monitor.md
-> handleSpawnNext: spawn ready tasks as team-worker agents
-> handleCallback: mark completed, advance pipeline
-> Repeat until all tasks done
Dynamic Task Naming
| Capability | Prefix | Example |
|---|---|---|
| researcher | RESEARCH | RESEARCH-001 |
| developer | IMPL | IMPL-001 |
| analyst | ANALYSIS | ANALYSIS-001 |
| designer | DESIGN | DESIGN-001 |
| tester | TEST | TEST-001 |
| writer | DRAFT | DRAFT-001 |
| planner | PLAN | PLAN-001 |
| (default) | TASK | TASK-001 |
Dependency Graph Structure
task-analysis.json encodes the pipeline as adjacency list (task ID -> blockedBy array):
{
"dependency_graph": {
"RESEARCH-001": [],
"IMPL-001": ["RESEARCH-001"],
"TEST-001": ["IMPL-001"]
}
}
Role mapping comes from task-analysis.json#capabilities[].tasks[], not from the dependency graph itself.
Role-Worker Map
Dynamic — loaded from session role-specs at runtime:
<session>/role-specs/<role-name>.md -> team-worker agent
Role-spec files contain YAML frontmatter:
---
role: <role-name>
prefix: <PREFIX>
inner_loop: <true|false>
output_tag: "[<role-name>]"
message_types:
success: <type>
error: error
---
Checkpoint
| Trigger | Behavior |
|---|---|
| capability_gap reported | handleAdapt: generate new role-spec, spawn new worker |
| consensus_blocked HIGH | Create REVISION task or pause for user |
| All tasks complete | handleComplete: interactive completion action |
Specs Reference
- role-spec-template.md — Template for generating dynamic role-specs
- quality-gates.md — Quality thresholds and scoring dimensions
- knowledge-transfer.md — Context transfer protocols between roles
Quality Gate Integration
Dynamic pipelines reference quality thresholds from specs/quality-gates.md.
| Gate Point | Trigger | Criteria Source |
|---|---|---|
| After artifact production | Producer role Phase 4 | Behavioral Traits in role-spec |
| After validation tasks | Tester/analyst completion | quality-gates.md thresholds |
| Pipeline completion | All tasks done | Aggregate scoring |
Issue classification: Error (blocks) > Warning (proceed with justification) > Info (log for future).