maestro-flow 0.4.6 → 0.4.8

package/.codex/skills/team-lifecycle-v4/roles/coordinator/role.md

@@ -1,189 +0,0 @@
-# Coordinator Role
-
-Orchestrate team-lifecycle-v4: analyze -> dispatch -> spawn -> monitor -> report.
-
-## 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` / `send_message` / `followup_task` calls
-- Status reports to the user
-- `request_user_input` prompts
-
-**FORBIDDEN actions** (even if the task seems trivial):
-```
-WRONG: Read("src/...")                              — worker work
-WRONG: Grep/Glob on project source                  — worker work
-WRONG: Bash("maestro delegate '...' --role analyze")     — worker work
-WRONG: Edit/Write on project source files            — worker work
-WRONG: Bash("npm test"), Bash("tsc"), etc.           — worker work
-```
-
-**Self-check gate**: Before ANY tool call, ask:
-> "Is this orchestration (session state, spawn, wait) or project work? If project work → STOP → spawn worker."
-
----
-
-## Identity
-- Name: coordinator | Tag: [coordinator]
-- Responsibility: Analyze task -> Create session -> Dispatch tasks -> Monitor progress -> Report results
-
-## Boundaries
-
-### MUST
-- Parse task description (text-level only, no codebase reading)
-- Create session folder and spawn team_worker agents via spawn_agent
-- Dispatch tasks with proper dependency chains (tasks.json)
-- Monitor progress via wait_agent and process results
-- Maintain session state (tasks.json)
-- Handle capability_gap reports
-- 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 explore codebase (delegate to workers)
-- Execute task work directly (even for single-role low-complexity tasks)
-- Modify task output artifacts
-- Spawn workers with general-purpose agent (MUST use team_worker)
-- Generate more than 5 worker roles
-- Call CLI tools (maestro delegate) — only workers use CLI
-
-## Command Execution Protocol
-When coordinator needs to execute a specific phase:
-1. Read `commands/<command>.md`
-2. Follow the workflow defined in the command
-3. Commands are inline execution guides, NOT separate agents
-4. Execute synchronously, complete before proceeding
-
-## Entry Router
-
-| Detection | Condition | Handler |
-|-----------|-----------|---------|
-| Status check | Args contain "check" or "status" | -> handleCheck (monitor.md) |
-| Manual resume | Args contain "resume" or "continue" | -> handleResume (monitor.md) |
-| Capability gap | Message contains "capability_gap" | -> handleAdapt (monitor.md) |
-| Pipeline complete | All tasks completed | -> handleComplete (monitor.md) |
-| Interrupted session | Active session in .workflow/.team/TLV4-* | -> Phase 0 |
-| New session | None of above | -> Phase 1 |
-
-For check/resume/adapt/complete: load @commands/monitor.md, execute handler, STOP.
-
-## Phase 0: Session Resume Check
-
-1. Scan .workflow/.team/TLV4-*/tasks.json for active/paused sessions
-2. No sessions -> Phase 1
-3. Single session -> reconcile:
-   a. Read tasks.json, reset in_progress -> pending
-   b. Rebuild active_agents map
-   c. If pipeline has CHECKPOINT tasks AND `supervision !== false`:
-      - Respawn supervisor via `spawn_agent({ agent_type: "team_supervisor" })` with `recovery: true`
-      - Supervisor auto-rebuilds context from existing CHECKPOINT-*-report.md files
-   d. Kick first ready task via handleSpawnNext
-4. Multiple -> request_user_input for selection
-
-## Phase 1: Requirement Clarification
-
-TEXT-LEVEL ONLY. No source code reading.
-
-1. Parse task description
-2. Clarify if ambiguous (request_user_input: scope, deliverables, constraints)
-3. Delegate to @commands/analyze.md
-4. Output: task-analysis.json
-5. **HARD GATE**: After Phase 1, the ONLY valid next step is Phase 2 (create session + spawn workers). There is NO path to "just do it directly."
-   - Complexity=Low → still spawn worker
-   - Single file task → still spawn worker
-   - "Seems trivial" → still spawn worker
-
-## Phase 2: Create Session + Initialize
-
-1. Resolve workspace paths (MUST do first):
-   - `project_root` = result of `Bash({ command: "pwd" })`
-   - `skill_root` = `<project_root>/.codex/skills/team-lifecycle-v4`
-2. Generate session ID: TLV4-<slug>-<date>
-3. Create session folder structure:
-   ```bash
-   mkdir -p .workflow/.team/${SESSION_ID}/{artifacts,discoveries,wisdom,role-specs}
-   ```
-4. Read specs/pipelines.md -> select pipeline
-5. Register roles in tasks.json metadata
-6. Initialize shared infrastructure (wisdom/*.md, explorations/cache-index.json)
-7. Write initial tasks.json:
-   ```json
-   {
-     "session_id": "<id>",
-     "pipeline": "<mode>",
-     "requirement": "<original requirement>",
-     "created_at": "<ISO timestamp>",
-     "supervision": true,
-     "completed_waves": [],
-     "active_agents": {},
-     "tasks": {}
-   }
-   ```
-8. Spawn resident supervisor (if pipeline has CHECKPOINT tasks AND `supervision !== false`):
-   - Use SKILL.md Supervisor Spawn Template:
-     ```javascript
-     const supervisorId = spawn_agent({
-       agent_type: "team_supervisor",
-       message: `## Role Assignment
-     role: supervisor
-     role_spec: ${skillRoot}/roles/supervisor/role.md
-     session: ${sessionFolder}
-     session_id: ${sessionId}
-     requirement: ${requirement}
-
-     Read role_spec file to load checkpoint definitions.
-     Init: load baseline context, report ready, go idle.`
-     })
-     ```
-   - Record supervisorId in tasks.json active_agents with `resident: true` flag
-   - Proceed to Phase 3
-
-## Phase 3: Create Task Chain
-
-Delegate to @commands/dispatch.md:
-1. Read dependency graph from task-analysis.json
-2. Read specs/pipelines.md for selected pipeline's task registry
-3. Topological sort tasks
-4. Write tasks to tasks.json with deps arrays
-5. Update tasks.json metadata (total count, wave assignments)
-
-## Phase 4: Spawn-and-Wait
-
-Delegate to @commands/monitor.md#handleSpawnNext:
-1. Find ready tasks (pending + deps resolved)
-2. Spawn team_worker agents via spawn_agent
-3. Wait for completion via wait_agent
-4. Process results, advance pipeline
-5. Repeat until all waves complete or pipeline blocked
-
-## Phase 5: Report + Completion Action
-
-1. Generate summary (deliverables, pipeline stats, discussions)
-2. Execute completion action per tasks.json completion_action:
-   - interactive -> request_user_input (Archive/Keep/Export)
-   - auto_archive -> Archive & Clean (rm -rf session folder)
-   - auto_keep -> Keep Active
-
-## 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 too vague | request_user_input for clarification |
-| Session corruption | Attempt recovery, fallback to manual |
-| Worker crash | Reset task to pending in tasks.json, respawn via spawn_agent |
-| Supervisor crash | Respawn via spawn_agent({ agent_type: "team_supervisor" }) with recovery: true |
-| Dependency cycle | Detect in analysis, halt |
-| Role limit exceeded | Merge overlapping roles |

package/.codex/skills/team-lifecycle-v4/schemas/tasks-schema.md

@@ -1,100 +0,0 @@
-# Tasks Schema — team-lifecycle-v4
-
-> Base schema: `~/.maestro/templates/cli/schemas/team-tasks-schema.json`
-
-This file documents lifecycle-v4 specific extensions to the universal team tasks schema.
-
-## Session ID Format
-
-`tlv4-<topic>-<YYYYMMDD>` (e.g., `tlv4-auth-system-20260324`)
-
-## Valid Roles
-
-Must match a directory in `.codex/skills/team-lifecycle-v4/roles/`:
-
-| Role | Task Prefix | Description |
-|------|-------------|-------------|
-| analyst | RESEARCH | Domain research and analysis |
-| writer | DRAFT | Document generation (product brief, requirements, etc.) |
-| planner | PLAN | Architecture and planning |
-| executor | IMPL | Code implementation |
-| tester | TEST | Testing and validation |
-| reviewer | REVIEW / QUALITY | Code and spec review |
-| supervisor | CHECKPOINT | Quality gate verification |
-| coordinator | (orchestrator) | Pipeline orchestration (not a task role) |
-
-## Valid Pipeline Phases
-
-From `specs/pipelines.md`:
-
-| Phase | Wave | Description |
-|-------|------|-------------|
-| research | 1 | Domain exploration |
-| product-brief | 2 | Vision and problem definition |
-| requirements | 3 | Functional/non-functional requirements |
-| architecture | 4 | System design |
-| epics | 5 | Epic and story breakdown |
-| readiness | 6 | Pre-implementation readiness check |
-| checkpoint | varies | Supervision gates |
-| planning | 7 | Detailed implementation planning |
-| arch-detail | 8 | Architecture refinement |
-| orchestration | 9 | Task orchestration |
-| implementation | 10+ | Code writing |
-| validation | varies | Testing |
-| review | varies | Code/spec review |
-
-## Valid Pipelines
-
-| Pipeline | Description |
-|----------|-------------|
-| spec-only | Research → Brief → Requirements → Architecture → Epics → Readiness |
-| impl-only | Planning → Implementation → Validation → Review |
-| full-lifecycle | spec-only + impl-only combined |
-| fe-only | Frontend-specific implementation |
-| fullstack | Full-stack implementation |
-| full-lifecycle-fe | Full lifecycle with frontend focus |
-
-## Example
-
-```json
-{
-  "session_id": "tlv4-auth-system-20260324",
-  "skill": "team-lifecycle-v4",
-  "pipeline": "full-lifecycle",
-  "requirement": "Design and implement user authentication system with OAuth2 and RBAC",
-  "created_at": "2026-03-24T10:00:00+08:00",
-  "supervision": true,
-  "completed_waves": [1],
-  "active_agents": { "DRAFT-001": "agent-abc123" },
-  "tasks": {
-    "RESEARCH-001": {
-      "title": "Domain research",
-      "description": "Explore auth domain: OAuth2 flows, RBAC patterns, competitor analysis",
-      "role": "analyst",
-      "pipeline_phase": "research",
-      "deps": [],
-      "context_from": [],
-      "wave": 1,
-      "status": "completed",
-      "findings": "Identified OAuth2+RBAC pattern, 5 integration points, SSO requirement",
-      "quality_score": null,
-      "supervision_verdict": null,
-      "error": null
-    },
-    "DRAFT-001": {
-      "title": "Product brief",
-      "description": "Generate product brief from research context",
-      "role": "writer",
-      "pipeline_phase": "product-brief",
-      "deps": ["RESEARCH-001"],
-      "context_from": ["RESEARCH-001"],
-      "wave": 2,
-      "status": "in_progress",
-      "findings": null,
-      "quality_score": null,
-      "supervision_verdict": null,
-      "error": null
-    }
-  }
-}
-```

package/.codex/skills/team-lifecycle-v4/specs/knowledge-transfer.md

@@ -1,204 +0,0 @@
-# Knowledge Transfer Protocols
-
-## 1. Transfer Channels
-
-| Channel | Method | Producer | Consumer |
-|---------|--------|----------|----------|
-| Artifacts | Files in `<session>/artifacts/` | Task executor | Next task in pipeline |
-| Discoveries | Files in `<session>/discoveries/{task_id}.json` | Task executor | Coordinator + downstream |
-| Wisdom | Append to `<session>/wisdom/*.md` | Any role | All roles |
-| Context Accumulator | In-memory aggregation | Inner loop only | Current task |
-| Exploration Cache | `<session>/explorations/` | Analyst / researcher | All roles |
-| **Progress Milestones** | `team_msg` type=progress/blocker/task_complete | Worker (all roles) | Coordinator + Human (CLI) |
-| **Cross-Worker Handoff** | `send_message` from coordinator to running worker | Coordinator | Running worker |
-
-## 2. Context Loading Protocol (Before Task Execution)
-
-Every role MUST load context in this order before starting work.
-
-| Step | Action | Required |
-|------|--------|----------|
-| 1 | Read `<session>/tasks.json` -- locate upstream task entries, check status and findings | Yes |
-| 2 | Read `<session>/discoveries/{upstream_id}.json` for each upstream dependency -- get detailed findings and artifact paths | Yes |
-| 3 | Read artifact files from upstream discovery's `artifacts_produced` paths | Yes |
-| 4 | Read `<session>/wisdom/*.md` if exists | Yes |
-| 5 | Check `<session>/explorations/cache-index.json` before new exploration | If exploring |
-
-**Loading rules**:
-- Never skip step 1 -- tasks.json contains task status, wave progression, and summary findings
-- Never skip step 2 -- discoveries contain detailed key_findings, decisions, and artifact references
-- If artifact path in discovery does not exist, log warning and continue
-- Wisdom files are append-only -- read all entries, newest last
-
-## 3. Context Publishing Protocol (After Task Completion)
-
-| Step | Action | Required |
-|------|--------|----------|
-| 1 | Write deliverable to `<session>/artifacts/<task-id>-<name>.md` | Yes |
-| 2 | Write `<session>/discoveries/{task_id}.json` with payload (see schema below) | Yes |
-| 3 | Append wisdom entries for learnings, decisions, issues found | If applicable |
-
-## 4. Discovery File Schema
-
-Written to `<session>/discoveries/{task_id}.json` on task completion.
-
-```json
-{
-  "task_id": "<TASK-NNN>",
-  "worker": "<TASK-NNN>",
-  "timestamp": "2026-03-24T10:15:00+08:00",
-  "type": "<pipeline_phase>",
-  "status": "completed | failed",
-  "findings": "Summary string (max 500 chars)",
-  "quality_score": null,
-  "supervision_verdict": null,
-  "error": null,
-  "data": {
-    "key_findings": [
-      "Finding 1",
-      "Finding 2"
-    ],
-    "decisions": [
-      "Decision with rationale"
-    ],
-    "files_modified": [
-      "path/to/file.ts"
-    ],
-    "verification": "self-validated | peer-reviewed | tested"
-  },
-  "artifacts_produced": [
-    "<session>/artifacts/<task-id>-<name>.md"
-  ]
-}
-```
-
-**Field rules**:
-- `artifacts_produced`: Always artifact paths, never inline content
-- `data.key_findings`: Max 5 items, each under 100 chars
-- `data.decisions`: Include rationale, not just the choice
-- `data.files_modified`: Only for implementation tasks
-- `data.verification`: One of `self-validated`, `peer-reviewed`, `tested`
-
-**Supervisor-specific extensions** (CHECKPOINT tasks only):
-
-```json
-{
-  "supervision_verdict": "pass | warn | block",
-  "supervision_score": 0.85,
-  "data": {
-    "risks_logged": 0,
-    "blocks_detected": 0
-  }
-}
-```
-
-- `supervision_verdict`: Required for CHECKPOINT tasks. Determines pipeline progression.
-- `supervision_score`: Float 0.0-1.0. Aggregate of individual check scores.
-- `data.risks_logged`: Count of risks written to wisdom/issues.md.
-- `data.blocks_detected`: Count of blocking issues found. >0 implies verdict=block.
-
-## 5. Exploration Cache Protocol
-
-Prevents redundant research across tasks.
-
-| 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
-
-## 6. Progress Milestone Protocol
-
-Workers report progress during execution via `team_msg`. This provides:
-- **Human CLI monitoring**: `maestro agent-msg list -s <session-id> --type progress` works while coordinator is blocked in `wait_agent`
-- **Coordinator post-wait trace**: Full execution history for forensics and status display
-- **Blocker awareness**: Coordinator knows where worker got stuck on timeout
-
-### Message Types
-
-| Type | When | Purpose |
-|------|------|---------|
-| `progress` | At natural phase boundaries | Report milestone reached + progress % |
-| `blocker` | Immediately on error | Report blocking issue without waiting |
-| `task_complete` | After `report_agent_job_result` | Final status for coordinator trace |
-
-### Progress Message Schema
-
-```javascript
-mcp__maestro-tools__team_msg({
-  operation: "log",
-  session_id: "<session_id>",
-  from: "<task_id>",           // e.g., "IMPL-001"
-  to: "coordinator",
-  type: "progress",            // or "blocker" or "task_complete"
-  summary: "[<task_id>] <phase description> (<pct>%)",
-  data: {
-    task_id: "<task_id>",
-    role: "<role>",
-    status: "in_progress",     // in_progress | blocked | completed
-    progress_pct: 0-100,
-    phase: "<what just completed>",
-    key_info: "<most important finding>"
-  }
-})
-```
-
-### Timing Constraint
-
-`wait_agent` is **blocking** — coordinator cannot read team_msg during wait. Progress is only consumed:
-1. On `handleCheck` (user types "check" while coordinator is idle)
-2. On `handleResume` after `wait_agent` returns (drain bus before collecting discoveries)
-3. By human via `maestro agent-msg list` CLI (works anytime, independent of coordinator)
-
-### Relationship to Discoveries
-
-- **Progress milestones** = lightweight trace during execution (via team_msg)
-- **Discovery files** = authoritative final output (via `discoveries/{task_id}.json`)
-- If team_msg fails, worker continues — discovery file is ground truth
-- Coordinator always reads both: team_msg for trace, discoveries for results
-
-## 7. Cross-Worker Handoff Protocol
-
-When worker A completes and worker B is still running, coordinator pushes A's findings to B via `send_message`:
-
-```javascript
-// In handleSpawnNext, after collecting A's discovery:
-send_message({
-  target: "IMPL-002",        // B's task_name
-  message: `## Supplementary Context from IMPL-001\n${findingsFromA}`
-})
-// Note: send_message queues info without interrupting B's current work
-```
-
-**When to send**: After each wave of discoveries is collected, if any running worker could benefit from the new findings.
-**What to send**: Key findings and decisions from completed tasks, especially those listed in `context_from` deps.
-
-## 8. Platform Mapping Reference
-
-| Claude Code Operation | Codex Equivalent |
-|----------------------|------------------|
-| `team_msg(operation="get_state", role=<upstream>)` | Read `tasks.json` + Read `discoveries/{upstream_id}.json` |
-| `team_msg(type="state_update", payload={...})` | Write `discoveries/{task_id}.json` |
-| `TaskCreate` / `TaskUpdate` status fields | Read/Write `tasks.json` task entries |
-| In-memory state aggregation | Parse `tasks.json` + glob `discoveries/*.json` |

package/.codex/skills/team-quality-assurance/roles/coordinator/commands/analyze.md

@@ -1,72 +0,0 @@
-# Analyze Task
-
-Parse user task -> detect QA capabilities -> build dependency graph -> design roles.
-
-**CONSTRAINT**: Text-level analysis only. NO source code reading, NO codebase exploration.
-
-## Signal Detection
-
-| Keywords | Capability | Prefix |
-|----------|------------|--------|
-| scan, discover, find issues, audit | scout | SCOUT |
-| strategy, plan, test layers, coverage | strategist | QASTRAT |
-| generate tests, write tests, create tests | generator | QAGEN |
-| run tests, execute, fix tests | executor | QARUN |
-| analyze, report, quality score | analyst | QAANA |
-
-## QA Mode Detection
-
-| Condition | Mode |
-|-----------|------|
-| Keywords: discovery, scan, issues, bug-finding | discovery |
-| Keywords: test, coverage, TDD, unit, integration | testing |
-| Both keyword types OR no clear match | full |
-
-## Dependency Graph
-
-Natural ordering tiers for QA pipeline:
-- Tier 0: scout (issue discovery)
-- Tier 1: strategist (strategy requires scout discoveries)
-- Tier 2: generator (generation requires strategy)
-- Tier 3: executor (execution requires generated tests)
-- Tier 4: analyst (analysis requires execution results)
-
-## Pipeline Definitions
-
-```
-Discovery Mode: SCOUT -> QASTRAT -> QAGEN(L1) -> QARUN(L1) -> QAANA
-Testing Mode: QASTRAT -> QAGEN(L1) -> QARUN(L1) -> QAGEN(L2) -> QARUN(L2) -> QAANA
-Full Mode: SCOUT -> QASTRAT -> [QAGEN(L1) || QAGEN(L2)] -> [QARUN(L1) || QARUN(L2)] -> QAANA -> SCOUT(regression)
-```
-
-## Complexity Scoring
-
-| Factor | Points |
-|--------|--------|
-| Per capability | +1 |
-| Cross-domain (test + discovery) | +2 |
-| Parallel tracks | +1 per track |
-| Serial depth > 3 | +1 |
-
-Results: 1-3 Low, 4-6 Medium, 7+ High
-
-## Role Minimization
-
-- Cap at 6 roles (coordinator + 5 workers)
-- Merge overlapping capabilities
-- Absorb trivial single-step roles
-
-## Output
-
-Write <session>/task-analysis.json:
-```json
-{
-  "task_description": "<original>",
-  "pipeline_mode": "<discovery|testing|full>",
-  "capabilities": [{ "name": "<cap>", "prefix": "<PREFIX>", "keywords": ["..."] }],
-  "dependency_graph": { "<TASK-ID>": { "role": "<role>", "addBlockedBy": ["..."], "priority": "P0|P1|P2" } },
-  "roles": [{ "name": "<role>", "prefix": "<PREFIX>", "inner_loop": false }],
-  "complexity": { "score": 0, "level": "Low|Medium|High" },
-  "gc_loop_enabled": true
-}
-```

package/.codex/skills/team-quality-assurance/roles/coordinator/commands/dispatch.md

@@ -1,108 +0,0 @@
-# Dispatch Tasks
-
-Create task chains from dependency graph with proper blockedBy relationships.
-
-## Workflow
-
-1. Read task-analysis.json -> extract pipeline_mode and dependency_graph
-2. Read specs/pipelines.md -> get task registry for selected pipeline
-3. Topological sort tasks (respect blockedBy)
-4. Validate all owners exist in role registry (SKILL.md)
-5. For each task (in order):
-   - Build JSON entry with structured description (see template below)
-   - Set blockedBy and owner fields in the entry
-6. Write all entries to `<session>/tasks.json`
-7. Update session.json with pipeline.tasks_total
-8. Validate chain (no orphans, no cycles, all refs valid)
-
-## Task Description Template
-
-Each task is a JSON entry in the tasks array:
-
-```json
-{
-  "id": "<TASK-ID>",
-  "subject": "<TASK-ID>",
-  "description": "PURPOSE: <goal> | Success: <criteria>\nTASK:\n  - <step 1>\n  - <step 2>\nCONTEXT:\n  - Session: <session-folder>\n  - Layer: <L1-unit|L2-integration|L3-e2e> (if applicable)\n  - Upstream artifacts: <list>\n  - Shared memory: <session>/wisdom/.msg/meta.json\nEXPECTED: <artifact path> + <quality criteria>\nCONSTRAINTS: <scope limits>\n---\nInnerLoop: <true|false>\nRoleSpec: ~  or <project>/.codex/skills/team-quality-assurance/roles/<role>/role.md",
-  "status": "pending",
-  "owner": "<role>",
-  "blockedBy": ["<dependency-list>"]
-}
-```
-
-## Pipeline Task Registry
-
-### Discovery Mode
-```
-SCOUT-001 (scout): Multi-perspective issue scanning
-  blockedBy: []
-QASTRAT-001 (strategist): Test strategy formulation
-  blockedBy: [SCOUT-001]
-QAGEN-001 (generator): L1 unit test generation
-  blockedBy: [QASTRAT-001], meta: layer=L1
-QARUN-001 (executor): L1 test execution + fix cycles
-  blockedBy: [QAGEN-001], inner_loop: true, meta: layer=L1
-QAANA-001 (analyst): Quality analysis report
-  blockedBy: [QARUN-001]
-```
-
-### Testing Mode
-```
-QASTRAT-001 (strategist): Test strategy formulation
-  blockedBy: []
-QAGEN-L1-001 (generator): L1 unit test generation
-  blockedBy: [QASTRAT-001], meta: layer=L1
-QARUN-L1-001 (executor): L1 test execution + fix cycles
-  blockedBy: [QAGEN-L1-001], inner_loop: true, meta: layer=L1
-QAGEN-L2-001 (generator): L2 integration test generation
-  blockedBy: [QARUN-L1-001], meta: layer=L2
-QARUN-L2-001 (executor): L2 test execution + fix cycles
-  blockedBy: [QAGEN-L2-001], inner_loop: true, meta: layer=L2
-QAANA-001 (analyst): Quality analysis report
-  blockedBy: [QARUN-L2-001]
-```
-
-### Full Mode
-```
-SCOUT-001 (scout): Multi-perspective issue scanning
-  blockedBy: []
-QASTRAT-001 (strategist): Test strategy formulation
-  blockedBy: [SCOUT-001]
-QAGEN-L1-001 (generator-1): L1 unit test generation
-  blockedBy: [QASTRAT-001], meta: layer=L1
-QAGEN-L2-001 (generator-2): L2 integration test generation
-  blockedBy: [QASTRAT-001], meta: layer=L2
-QARUN-L1-001 (executor-1): L1 test execution + fix cycles
-  blockedBy: [QAGEN-L1-001], inner_loop: true, meta: layer=L1
-QARUN-L2-001 (executor-2): L2 test execution + fix cycles
-  blockedBy: [QAGEN-L2-001], inner_loop: true, meta: layer=L2
-QAANA-001 (analyst): Quality analysis report
-  blockedBy: [QARUN-L1-001, QARUN-L2-001]
-SCOUT-002 (scout): Regression scan after fixes
-  blockedBy: [QAANA-001]
-```
-
-## InnerLoop Flag Rules
-
-- true: executor roles (run-fix cycles)
-- false: scout, strategist, generator, analyst roles
-
-## Dependency Validation
-
-- No orphan tasks (all tasks have valid owner)
-- No circular dependencies
-- All blockedBy references exist
-- Session reference in every task description
-- RoleSpec reference in every task description
-
-## Log After Creation
-
-```
-mcp__maestro-tools__team_msg({
-  operation: "log",
-  session_id: <session-id>,
-  from: "coordinator",
-  type: "pipeline_selected",
-  data: { pipeline: "<mode>", task_count: <N> }
-})
-```