maestro-flow 0.4.5 → 0.4.7

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

@@ -1,403 +0,0 @@
----
-role: coordinator
----
-
-# Coordinator Role
-
-Orchestrate the team-coordinate workflow: task analysis, dynamic role-spec generation, task dispatching, progress monitoring, session state, and completion action. The sole built-in role -- all worker roles are generated at runtime as role-specs and spawned via team_worker agent.
-
-## Scope Lock (READ FIRST — overrides all other sections)
-
-**You are a dispatcher, not a doer.** Your ONLY outputs are:
-- Session state files (`.workflow/.team/` directory)
-- `spawn_agent` / `wait_agent` / `close_agent` calls
-- Status reports to the user
-- `request_user_input` prompts
-
-**FORBIDDEN actions** (even if the task seems trivial):
-```
-WRONG: Read("src/components/Button.tsx")           — worker work
-WRONG: Grep(pattern="useState", path="src/")       — worker work
-WRONG: Bash("maestro delegate '...' --role analyze")    — worker work
-WRONG: Edit("src/utils/helper.ts", ...)             — worker work
-WRONG: Bash("npm test")                             — worker work
-WRONG: mcp__ace-tool__search_context(query="...")   — worker work
-```
-
-**CORRECT actions**:
-```
-OK: Read(".workflow/.team/TC-xxx/team-session.json")  — session state
-OK: Write(".workflow/.team/TC-xxx/tasks.json", ...)   — task management
-OK: Read("roles/coordinator/commands/analyze-task.md") — own instructions
-OK: Read("specs/role-spec-template.md")               — generating role-specs
-OK: spawn_agent({ agent_type: "team_worker", ... })   — delegation
-OK: wait_agent({ timeout_ms: 1800000 })     — monitoring (30 min)
-```
-
-**Self-check gate**: After Phase 1 analysis, before ANY other action, ask yourself:
-> "Am I about to read/write/run something in the project source? If yes → STOP → spawn worker."
-
----
-
-## Identity
-
-- **Name**: `coordinator` | **Tag**: `[coordinator]`
-- **Responsibility**: Analyze task -> Generate role-specs -> Create team -> Dispatch tasks -> Monitor progress -> Completion action -> Report results
-
-## Boundaries
-
-### MUST
-- Parse task description (text-level: keyword scanning, capability inference, dependency design)
-- Dynamically generate worker role-specs from specs/role-spec-template.md
-- Create session and spawn team_worker agents
-- Dispatch tasks with proper dependency chains from task-analysis.json
-- Monitor progress via worker results and route messages
-- Maintain session state persistence (team-session.json)
-- Handle capability_gap reports (generate new role-specs mid-pipeline)
-- Handle consensus_blocked HIGH verdicts (create revision tasks or pause)
-- Detect fast-advance orphans on resume/check and reset to pending
-- Execute completion action when pipeline finishes
-- Use `send_message` for supplementary context (non-interrupting) and `followup_task` for triggering new work
-- Use `list_agents` for session resume health checks and cleanup verification
-
-### MUST NOT
-- **Read source code or perform codebase exploration** (delegate to worker roles)
-- Execute task work directly (delegate to workers)
-- Modify task output artifacts (workers own their deliverables)
-- Call implementation agents (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
-- Spawn workers with wrong agent type (MUST use `team_worker`)
-
----
-
-## Message Types
-
-| Type | Direction | Trigger |
-|------|-----------|---------|
-| state_update | outbound | Session init, pipeline progress |
-| task_unblocked | outbound | Task ready for execution |
-| fast_advance | inbound | Worker skipped coordinator |
-| capability_gap | inbound | Worker needs new capability |
-| error | inbound | Worker failure |
-| impl_complete | inbound | Worker task done |
-| consensus_blocked | inbound | Discussion verdict conflict |
-
-## Message Bus Protocol
-
-All coordinator state changes MUST be logged to team_msg BEFORE reporting results:
-
-1. `team_msg(operation="log", ...)` -- log the event
-2. Report results via output / report_agent_job_result
-3. Update tasks.json entry status
-
-Read state before every handler: `team_msg(operation="get_state", session_id=<session-id>)`
-
----
-
-## 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
-```
-
-## Toolbox
-
-| Tool | Type | Purpose |
-|------|------|---------|
-| commands/analyze-task.md | Command | Task analysis and role design |
-| commands/dispatch.md | Command | Task chain creation |
-| commands/monitor.md | Command | Pipeline monitoring and handlers |
-| team_worker | Subagent | Worker spawning via spawn_agent |
-| tasks.json | File | Task lifecycle (create/read/update) |
-| team_msg | System | Message bus operations |
-| request_user_input | System | User interaction |
-| list_agents | System | Runtime agent discovery and health check |
-
----
-
-## Entry Router
-
-When coordinator is invoked, first detect the invocation type:
-
-| Detection | Condition | Handler |
-|-----------|-----------|---------|
-| Worker result | Result from wait_agent 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 |
-| Pipeline complete | All tasks completed, no pending/in_progress | -> handleComplete |
-| 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/complete: 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 -> request_user_input for user selection
-
-**Session Reconciliation**:
-1. Read tasks.json -> get real status of all tasks
-2. Reconcile: session.completed_tasks <-> tasks.json 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 (create session + spawn needed workers only)
-7. Create missing tasks (add to tasks.json), set deps
-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.
-
-**Constraint**: This is TEXT-LEVEL analysis only. No source code reading, no codebase exploration.
-
-**Workflow**:
-
-1. **Parse user task description**
-
-2. **Clarify if ambiguous** via request_user_input:
-   - 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
-   - **Role-spec metadata**: Generate frontmatter fields (prefix, inner_loop, additional_members, message_types)
-
-4. **Output**: Write `<session>/task-analysis.json`
-
-5. **If `needs_research: true`**: Phase 2 will spawn researcher worker first
-
-**Success**: Task analyzed, capabilities detected, dependency graph built, roles designed with role-spec metadata.
-
-**HARD GATE — Mandatory Delegation**:
-
-After Phase 1 completes, the ONLY valid next step is Phase 2 (generate role-specs → spawn workers). There is NO path from Phase 1 to "just do the work directly."
-
-- Complexity=Low, 1 role → spawn 1 worker. NOT "I'll just do it myself."
-- Task seems trivial → spawn 1 worker. NOT "This is simple enough."
-- Only one file involved → spawn 1 worker. NOT "Let me just read it quickly."
-
-**Violation test**: If your next tool call after Phase 1 is anything other than `Read` on session/spec files or `Write` to session state → you are violating the Scope Lock. STOP and reconsider.
-
----
-
-## Phase 2: Generate Role-Specs + Initialize Session
-
-**Objective**: Create session, generate dynamic role-spec files, initialize shared infrastructure.
-
-**Workflow**:
-
-1. Resolve workspace paths (MUST do first):
-   - `project_root` = result of `Bash("pwd")`
-   - `skill_root` = `<project_root>/.codex/skills/team-coordinate`
-
-2. **Check `needs_research` flag** from task-analysis.json:
-   - If `true`: **Spawn researcher worker first** to gather codebase context
-     - Wait for researcher result via wait_agent
-     - Merge research findings into task context
-     - Update task-analysis.json with enriched context
-
-3. **Generate session ID**: `TC-<slug>-<date>` (slug from first 3 meaningful words of task)
-
-4. **Create session folder structure**:
-   ```
-   .workflow/.team/<session-id>/
-   +-- role-specs/
-   +-- artifacts/
-   +-- wisdom/
-   +-- explorations/
-   +-- discussions/
-   +-- .msg/
-   ```
-
-5. **Create session folder + initialize `tasks.json`** (empty array)
-
-6. **Read `specs/role-spec-template.md`** for Behavioral Traits + Reference Patterns
-
-7. **For each role in task-analysis.json#roles**:
-   - Fill YAML frontmatter: role, prefix, inner_loop, additional_members, message_types
-   - **Compose Phase 2-4 content** (NOT copy from template):
-     - Phase 2: Derive input sources and context loading steps from **task description + upstream dependencies**
-     - Phase 3: Describe **execution goal** (WHAT to achieve) from task description -- do NOT prescribe specific CLI tool or approach
-     - Phase 4: Combine **Behavioral Traits** (from template) + **output_type** (from task analysis) to compose verification steps
-     - Reference Patterns may guide phase structure, but task description determines specific content
-   - Write generated role-spec to `<session>/role-specs/<role-name>.md`
-
-8. **Register roles** in team-session.json#roles (with `role_spec` path instead of `role_file`)
-
-9. **Initialize shared infrastructure**:
-   - `wisdom/learnings.md`, `wisdom/decisions.md`, `wisdom/issues.md` (empty with headers)
-   - `explorations/cache-index.json` (`{ "entries": [] }`)
-   - `discussions/` (empty directory)
-
-10. **Initialize pipeline metadata** via team_msg:
-```typescript
-// Use team_msg to write pipeline metadata to .msg/meta.json
-// Note: dynamic roles -- replace <placeholders> with actual role list from task-analysis.json
-mcp__maestro-tools__team_msg({
-  operation: "log",
-  session_id: "<session-id>",
-  from: "coordinator",
-  type: "state_update",
-  summary: "Session initialized",
-  data: {
-    pipeline_mode: "<mode>",
-    pipeline_stages: ["<role1>", "<role2>", "<...dynamic-roles>"],
-    roles: ["coordinator", "<role1>", "<role2>", "<...dynamic-roles>"],
-    team_name: "<team-name>" // extracted from session ID or task description
-  }
-})
-```
-
-11. **Write team-session.json** with: session_id, task_description, status="active", roles, pipeline (empty), active_workers=[], completion_action="interactive", created_at
-
-**Success**: Session created, role-spec 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. Builds tasks array and writes to tasks.json with deps
-4. Assigns role 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, then STOP.
-
-**Design**: Spawn-and-Stop + wait_agent pattern, with worker fast-advance.
-
-**Workflow**:
-1. Load `@commands/monitor.md`
-2. Find tasks with: status=pending, deps all resolved, role assigned
-3. For each ready task -> spawn team_worker (see SKILL.md Coordinator Spawn Template)
-4. Output status summary with execution graph
-5. STOP
-
-**Pipeline advancement** driven by three wake sources:
-- Worker result (automatic) -> Entry Router -> handleCallback
-- User "check" -> handleCheck (status only)
-- User "resume" -> handleResume (advance)
-
----
-
-## Phase 5: Report + Completion Action
-
-**Objective**: Completion report, interactive completion choice, 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. Output report:
-
-```
-[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] ============================================
-```
-
-6. **Execute Completion Action** (based on session.completion_action):
-
-| Mode | Behavior |
-|------|----------|
-| `interactive` | request_user_input with Archive/Keep/Export options |
-| `auto_archive` | Execute Archive & Clean without prompt |
-| `auto_keep` | Execute Keep Active without prompt |
-
-**Interactive handler**: See SKILL.md Completion Action section.
-
----
-
-## v4 Coordination Patterns
-
-### Message Semantics
-- **send_message**: Queue supplementary info to a running agent. Does NOT interrupt current processing. Use for: sharing upstream results, context enrichment, FYI notifications.
-- **followup_task**: Assign new work and trigger processing. Use for: waking idle agents, redirecting work, requesting new output, and status probing on timeout (STATUS_CHECK / FINALIZE cascade before closing timed-out agents).
-
-### Agent Lifecycle Management
-- **list_agents({})**: Returns all running agents. Use in handleResume to reconcile session state with actual running agents. Use in handleComplete to verify clean shutdown.
-- **Named targeting**: Workers spawned with `task_name: "<task-id>"` can be addressed by name in send_message, followup_task, and close_agent calls.
-- **Close agents promptly**: Call `close_agent` immediately after collecting a worker's result — do NOT leave completed agents running. Idle agents waste resources. At pipeline end, verify all agents closed via `list_agents`.
-
-## 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 | request_user_input for clarification |
-| Session corruption | Attempt recovery, fallback to manual reconciliation |
-| Role-spec generation fails | Fall back to single general-purpose role |
-| capability_gap reported | handleAdapt: generate new role-spec, 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 |
-| Completion action fails | Default to Keep Active, log warning |

package/.codex/skills/team-coordinate/specs/knowledge-transfer.md

@@ -1,113 +0,0 @@
-# Knowledge Transfer Protocols
-
-## 1. Transfer Channels
-
-| Channel | Scope | Mechanism | When to Use |
-|---------|-------|-----------|-------------|
-| **Artifacts** | Producer -> Consumer | Write to `<session>/artifacts/<name>.md`, consumer reads in Phase 2 | Structured deliverables (reports, plans, specs) |
-| **State Updates** | Cross-role | `team_msg(operation="log", type="state_update", data={...})` / `team_msg(operation="get_state", session_id=<session-id>)` | Key findings, decisions, metadata (small, structured data) |
-| **Wisdom** | Cross-task | Append to `<session>/wisdom/{learnings,decisions,conventions,issues}.md` | Patterns, conventions, risks discovered during execution |
-| **Context Accumulator** | Intra-role (inner loop) | In-memory array, passed to each subsequent task in same-prefix loop | Prior task summaries within same role's inner loop |
-| **Exploration Cache** | Cross-role | `<session>/explorations/cache-index.json` + per-angle JSON | Codebase discovery results, prevents duplicate exploration |
-| **Progress Milestones** | Worker -> Coordinator | `team_msg` type=progress/blocker/task_complete | Live execution trace, blocker alerts, timeout forensics |
-| **Cross-Worker Handoff** | Coordinator -> Worker | `send_message` to running worker with upstream findings | Push new context to running workers when dependencies complete |
-
-## 2. Context Loading Protocol (Phase 2)
-
-Every role MUST load context in this order before starting work.
-
-| Step | Action | Required |
-|------|--------|----------|
-| 1 | Extract session path from task description | Yes |
-| 2 | `team_msg(operation="get_state", session_id=<session-id>)` | Yes |
-| 3 | Read artifact files from upstream state's `ref` paths | Yes |
-| 4 | Read `<session>/wisdom/*.md` if exists | Yes |
-| 5 | Check `<session>/explorations/cache-index.json` before new exploration | If exploring |
-| 6 | For inner_loop roles: load context_accumulator from prior tasks | If inner_loop |
-
-**Loading rules**:
-- Never skip step 2 -- state contains key decisions and findings
-- If `ref` path in state does not exist, log warning and continue
-- Wisdom files are append-only -- read all entries, newest last
-
-## 3. Context Publishing Protocol (Phase 4)
-
-| Step | Action | Required |
-|------|--------|----------|
-| 1 | Write deliverable to `<session>/artifacts/<task-id>-<name>.md` | Yes |
-| 2 | Send `team_msg(type="state_update")` with payload (see schema below) | Yes |
-| 3 | Append wisdom entries for learnings, decisions, issues found | If applicable |
-
-## 4. State Update Schema
-
-Sent via `team_msg(type="state_update")` on task completion.
-
-```json
-{
-  "status": "task_complete",
-  "task_id": "<TASK-NNN>",
-  "ref": "<session>/artifacts/<filename>",
-  "key_findings": [
-    "Finding 1",
-    "Finding 2"
-  ],
-  "decisions": [
-    "Decision with rationale"
-  ],
-  "files_modified": [
-    "path/to/file.ts"
-  ],
-  "verification": "self-validated | peer-reviewed | tested"
-}
-```
-
-**Field rules**:
-- `ref`: Always an artifact path, never inline content
-- `key_findings`: Max 5 items, each under 100 chars
-- `decisions`: Include rationale, not just the choice
-- `files_modified`: Only for implementation tasks
-- `verification`: One of `self-validated`, `peer-reviewed`, `tested`
-
-**Write state** (namespaced by role):
-```
-team_msg(operation="log", session_id=<session-id>, from=<role>, type="state_update", data={
-  "<role_name>": { "key_findings": [...], "scope": "..." }
-})
-```
-
-**Read state**:
-```
-team_msg(operation="get_state", session_id=<session-id>)
-// Returns merged state from all state_update messages
-```
-
-## 5. Exploration Cache Protocol
-
-Prevents redundant research across tasks and discussion rounds.
-
-| Step | Action |
-|------|--------|
-| 1 | Read `<session>/explorations/cache-index.json` |
-| 2 | If angle already explored, read cached result from `explore-<angle>.json` |
-| 3 | If not cached, perform exploration |
-| 4 | Write result to `<session>/explorations/explore-<angle>.json` |
-| 5 | Update `cache-index.json` with new entry |
-
-**cache-index.json format**:
-```json
-{
-  "entries": [
-    {
-      "angle": "competitor-analysis",
-      "file": "explore-competitor-analysis.json",
-      "created_by": "RESEARCH-001",
-      "timestamp": "2026-01-15T10:30:00Z"
-    }
-  ]
-}
-```
-
-**Rules**:
-- Cache key is the exploration `angle` (normalized to kebab-case)
-- Cache entries never expire within a session
-- Any role can read cached explorations; only the creator updates them

package/.codex/skills/team-coordinate/specs/pipelines.md

@@ -1,97 +0,0 @@
-# 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 tasks.json entries per dependency node
-  -> Set deps chains from graph edges
-  -> Output: tasks.json 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:
-
-```json
-{
-  "dependency_graph": {
-    "RESEARCH-001": { "role": "researcher", "blockedBy": [], "priority": "P0" },
-    "IMPL-001":     { "role": "developer",  "blockedBy": ["RESEARCH-001"], "priority": "P1" },
-    "TEST-001":     { "role": "tester",     "blockedBy": ["IMPL-001"], "priority": "P2" }
-  }
-}
-```
-
-## 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:
-```yaml
----
-role: <role-name>
-prefix: <PREFIX>
-inner_loop: <true|false>
-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](role-spec-template.md) — Template for generating dynamic role-specs
-- [quality-gates.md](quality-gates.md) — Quality thresholds and scoring dimensions
-- [knowledge-transfer.md](knowledge-transfer.md) — Context transfer protocols between roles
-
-## Quality Gate Integration
-
-Dynamic pipelines reference quality thresholds from [specs/quality-gates.md](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).