claude-code-workflow 7.2.23 → 7.2.24

package/.codex/skills/team-perf-opt/roles/profiler/role.md

@@ -1,73 +1,73 @@
----
-role: profiler
-prefix: PROFILE
-inner_loop: false
-message_types:
-  success: profile_complete
-  error: error
----
-
-# Performance Profiler
-
-Profile application performance to identify CPU, memory, I/O, network, and rendering bottlenecks. Produce quantified baseline metrics and a ranked bottleneck report.
-
-## Phase 2: Context & Environment Detection
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Task description | From task subject/description | Yes |
-| Session path | Extracted from task description | Yes |
-| .msg/meta.json | <session>/.msg/meta.json | No |
-
-1. Extract session path and target scope from task description
-2. Detect project type by scanning for framework markers:
-
-| Signal File | Project Type | Profiling Focus |
-|-------------|-------------|-----------------|
-| package.json + React/Vue/Angular | Frontend | Render time, bundle size, FCP/LCP/CLS |
-| package.json + Express/Fastify/NestJS | Backend Node | CPU hotspots, memory, DB queries |
-| Cargo.toml / go.mod / pom.xml | Native/JVM Backend | CPU, memory, GC tuning |
-| Mixed framework markers | Full-stack | Split into FE + BE profiling passes |
-| CLI entry / bin/ directory | CLI Tool | Startup time, throughput, memory peak |
-| No detection | Generic | All profiling dimensions |
-
-3. Use ACE search or CLI tools to map performance-critical code paths within target scope
-4. Detect available profiling tools (test runners, benchmark harnesses, linting tools)
-
-## Phase 3: Performance Profiling
-
-Execute profiling based on detected project type:
-
-**Frontend profiling**:
-- Analyze bundle size and dependency weight via build output
-- Identify render-blocking resources and heavy components
-- Check for unnecessary re-renders, large DOM trees, unoptimized assets
-
-**Backend profiling**:
-- Trace hot code paths via execution analysis or instrumented runs
-- Identify slow database queries, N+1 patterns, missing indexes
-- Check memory allocation patterns and potential leaks
-
-**CLI / Library profiling**:
-- Measure startup time and critical path latency
-- Profile throughput under representative workloads
-- Identify memory peaks and allocation churn
-
-**All project types**:
-- Collect quantified baseline metrics (timing, memory, throughput)
-- Rank top 3-5 bottlenecks by severity (Critical / High / Medium)
-- Record evidence: file paths, line numbers, measured values
-
-## Phase 4: Report Generation
-
-1. Write baseline metrics to `<session>/artifacts/baseline-metrics.json`:
-   - Key metric names, measured values, units, measurement method
-   - Timestamp and environment details
-
-2. Write bottleneck report to `<session>/artifacts/bottleneck-report.md`:
-   - Ranked list of bottlenecks with severity, location (file:line), measured impact
-   - Evidence summary per bottleneck
-   - Detected project type and profiling methods used
-
-3. Update `<session>/.msg/meta.json` under `profiler` namespace:
-   - Read existing -> merge `{ "profiler": { project_type, bottleneck_count, top_bottleneck, scope } }` -> write back
+---
+role: profiler
+prefix: PROFILE
+inner_loop: false
+message_types:
+  success: profile_complete
+  error: error
+---
+
+# Performance Profiler
+
+Profile application performance to identify CPU, memory, I/O, network, and rendering bottlenecks. Produce quantified baseline metrics and a ranked bottleneck report.
+
+## Phase 2: Context & Environment Detection
+
+| Input | Source | Required |
+|-------|--------|----------|
+| Task description | From task subject/description | Yes |
+| Session path | Extracted from task description | Yes |
+| .msg/meta.json | <session>/.msg/meta.json | No |
+
+1. Extract session path and target scope from task description
+2. Detect project type by scanning for framework markers:
+
+| Signal File | Project Type | Profiling Focus |
+|-------------|-------------|-----------------|
+| package.json + React/Vue/Angular | Frontend | Render time, bundle size, FCP/LCP/CLS |
+| package.json + Express/Fastify/NestJS | Backend Node | CPU hotspots, memory, DB queries |
+| Cargo.toml / go.mod / pom.xml | Native/JVM Backend | CPU, memory, GC tuning |
+| Mixed framework markers | Full-stack | Split into FE + BE profiling passes |
+| CLI entry / bin/ directory | CLI Tool | Startup time, throughput, memory peak |
+| No detection | Generic | All profiling dimensions |
+
+3. Use ACE search or CLI tools to map performance-critical code paths within target scope
+4. Detect available profiling tools (test runners, benchmark harnesses, linting tools)
+
+## Phase 3: Performance Profiling
+
+Execute profiling based on detected project type:
+
+**Frontend profiling**:
+- Analyze bundle size and dependency weight via build output
+- Identify render-blocking resources and heavy components
+- Check for unnecessary re-renders, large DOM trees, unoptimized assets
+
+**Backend profiling**:
+- Trace hot code paths via execution analysis or instrumented runs
+- Identify slow database queries, N+1 patterns, missing indexes
+- Check memory allocation patterns and potential leaks
+
+**CLI / Library profiling**:
+- Measure startup time and critical path latency
+- Profile throughput under representative workloads
+- Identify memory peaks and allocation churn
+
+**All project types**:
+- Collect quantified baseline metrics (timing, memory, throughput)
+- Rank top 3-5 bottlenecks by severity (Critical / High / Medium)
+- Record evidence: file paths, line numbers, measured values
+
+## Phase 4: Report Generation
+
+1. Write baseline metrics to `<session>/artifacts/baseline-metrics.json`:
+   - Key metric names, measured values, units, measurement method
+   - Timestamp and environment details
+
+2. Write bottleneck report to `<session>/artifacts/bottleneck-report.md`:
+   - Ranked list of bottlenecks with severity, location (file:line), measured impact
+   - Evidence summary per bottleneck
+   - Detected project type and profiling methods used
+
+3. Update `<session>/.msg/meta.json` under `profiler` namespace:
+   - Read existing -> merge `{ "profiler": { project_type, bottleneck_count, top_bottleneck, scope } }` -> write back

package/.codex/skills/team-perf-opt/roles/reviewer/role.md

@@ -1,75 +1,75 @@
----
-role: reviewer
-prefix: REVIEW
-inner_loop: false
-additional_prefixes: [QUALITY]
-discuss_rounds: [DISCUSS-REVIEW]
-message_types:
-  success: review_complete
-  error: error
-  fix: fix_required
----
-
-# Optimization Reviewer
-
-Review optimization code changes for correctness, side effects, regression risks, and adherence to best practices. Provide structured verdicts with actionable feedback.
-
-## Phase 2: Context Loading
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Optimization code changes | From IMPL task artifacts / git diff | Yes |
-| Optimization plan / detail | Varies by mode (see below) | Yes |
-| Benchmark results | Varies by mode (see below) | No |
-| .msg/meta.json | <session>/.msg/meta.json | Yes |
-
-1. Extract session path from task description
-2. **Detect branch/pipeline context** from task description:
-
-| Task Description Field | Value | Context |
-|----------------------|-------|---------|
-| `BranchId: B{NN}` | Present | Fan-out branch -- review only this branch's changes |
-| `PipelineId: {P}` | Present | Independent pipeline -- review pipeline-scoped changes |
-| Neither present | - | Single mode -- review all optimization changes |
-
-3. **Load optimization context by mode**:
-   - Single: Read `<session>/artifacts/optimization-plan.md`
-   - Fan-out branch: Read `<session>/artifacts/branches/B{NN}/optimization-detail.md`
-   - Independent: Read `<session>/artifacts/pipelines/{P}/optimization-plan.md`
-
-4. Load .msg/meta.json for scoped optimizer namespace
-5. Identify changed files from optimizer context -- read ONLY files modified by this branch/pipeline
-6. If benchmark results available, read from scoped path
-
-## Phase 3: Multi-Dimension Review
-
-Analyze optimization changes across five dimensions:
-
-| Dimension | Focus | Severity |
-|-----------|-------|----------|
-| Correctness | Logic errors, off-by-one, race conditions, null safety | Critical |
-| Side effects | Unintended behavior changes, API contract breaks, data loss | Critical |
-| Maintainability | Code clarity, complexity increase, naming, documentation | High |
-| Regression risk | Impact on unrelated code paths, implicit dependencies | High |
-| Best practices | Idiomatic patterns, framework conventions, optimization anti-patterns | Medium |
-
-Per-dimension review process:
-- Scan modified files for patterns matching each dimension
-- Record findings with severity (Critical / High / Medium / Low)
-- Include specific file:line references and suggested fixes
-
-If any Critical findings detected, use CLI tools for multi-perspective validation (DISCUSS-REVIEW round) to validate the assessment before issuing verdict.
-
-## Phase 4: Verdict & Feedback
-
-Classify overall verdict based on findings:
-
-| Verdict | Condition | Action |
-|---------|-----------|--------|
-| APPROVE | No Critical or High findings | Send review_complete |
-| REVISE | Has High findings, no Critical | Send fix_required with detailed feedback |
-| REJECT | Has Critical findings or fundamental approach flaw | Send fix_required + flag for strategist escalation |
-
-1. Write review report to scoped output path (single/fan-out/independent)
-2. Update `<session>/.msg/meta.json` under scoped namespace
-3. If DISCUSS-REVIEW was triggered, record discussion summary in discussions directory
+---
+role: reviewer
+prefix: REVIEW
+inner_loop: false
+additional_prefixes: [QUALITY]
+discuss_rounds: [DISCUSS-REVIEW]
+message_types:
+  success: review_complete
+  error: error
+  fix: fix_required
+---
+
+# Optimization Reviewer
+
+Review optimization code changes for correctness, side effects, regression risks, and adherence to best practices. Provide structured verdicts with actionable feedback.
+
+## Phase 2: Context Loading
+
+| Input | Source | Required |
+|-------|--------|----------|
+| Optimization code changes | From IMPL task artifacts / git diff | Yes |
+| Optimization plan / detail | Varies by mode (see below) | Yes |
+| Benchmark results | Varies by mode (see below) | No |
+| .msg/meta.json | <session>/.msg/meta.json | Yes |
+
+1. Extract session path from task description
+2. **Detect branch/pipeline context** from task description:
+
+| Task Description Field | Value | Context |
+|----------------------|-------|---------|
+| `BranchId: B{NN}` | Present | Fan-out branch -- review only this branch's changes |
+| `PipelineId: {P}` | Present | Independent pipeline -- review pipeline-scoped changes |
+| Neither present | - | Single mode -- review all optimization changes |
+
+3. **Load optimization context by mode**:
+   - Single: Read `<session>/artifacts/optimization-plan.md`
+   - Fan-out branch: Read `<session>/artifacts/branches/B{NN}/optimization-detail.md`
+   - Independent: Read `<session>/artifacts/pipelines/{P}/optimization-plan.md`
+
+4. Load .msg/meta.json for scoped optimizer namespace
+5. Identify changed files from optimizer context -- read ONLY files modified by this branch/pipeline
+6. If benchmark results available, read from scoped path
+
+## Phase 3: Multi-Dimension Review
+
+Analyze optimization changes across five dimensions:
+
+| Dimension | Focus | Severity |
+|-----------|-------|----------|
+| Correctness | Logic errors, off-by-one, race conditions, null safety | Critical |
+| Side effects | Unintended behavior changes, API contract breaks, data loss | Critical |
+| Maintainability | Code clarity, complexity increase, naming, documentation | High |
+| Regression risk | Impact on unrelated code paths, implicit dependencies | High |
+| Best practices | Idiomatic patterns, framework conventions, optimization anti-patterns | Medium |
+
+Per-dimension review process:
+- Scan modified files for patterns matching each dimension
+- Record findings with severity (Critical / High / Medium / Low)
+- Include specific file:line references and suggested fixes
+
+If any Critical findings detected, use CLI tools for multi-perspective validation (DISCUSS-REVIEW round) to validate the assessment before issuing verdict.
+
+## Phase 4: Verdict & Feedback
+
+Classify overall verdict based on findings:
+
+| Verdict | Condition | Action |
+|---------|-----------|--------|
+| APPROVE | No Critical or High findings | Send review_complete |
+| REVISE | Has High findings, no Critical | Send fix_required with detailed feedback |
+| REJECT | Has Critical findings or fundamental approach flaw | Send fix_required + flag for strategist escalation |
+
+1. Write review report to scoped output path (single/fan-out/independent)
+2. Update `<session>/.msg/meta.json` under scoped namespace
+3. If DISCUSS-REVIEW was triggered, record discussion summary in discussions directory

package/.codex/skills/team-perf-opt/roles/strategist/role.md

@@ -1,94 +1,94 @@
----
-role: strategist
-prefix: STRATEGY
-inner_loop: false
-discuss_rounds: [DISCUSS-OPT]
-message_types:
-  success: strategy_complete
-  error: error
----
-
-# Optimization Strategist
-
-Analyze bottleneck reports and baseline metrics to design a prioritized optimization plan with concrete strategies, expected improvements, and risk assessments.
-
-## Phase 2: Analysis Loading
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Bottleneck report | <session>/artifacts/bottleneck-report.md | Yes |
-| Baseline metrics | <session>/artifacts/baseline-metrics.json | Yes |
-| .msg/meta.json | <session>/.msg/meta.json | Yes |
-| Wisdom files | <session>/wisdom/patterns.md | No |
-
-1. Extract session path from task description
-2. Read bottleneck report -- extract ranked bottleneck list with severities
-3. Read baseline metrics -- extract current performance numbers
-4. Load .msg/meta.json for profiler findings (project_type, scope)
-5. Assess overall optimization complexity:
-
-| Bottleneck Count | Severity Mix | Complexity |
-|-----------------|-------------|------------|
-| 1-2 | All Medium | Low |
-| 2-3 | Mix of High/Medium | Medium |
-| 3+ or any Critical | Any Critical present | High |
-
-## Phase 3: Strategy Formulation
-
-For each bottleneck, select optimization approach by type:
-
-| Bottleneck Type | Strategies | Risk Level |
-|----------------|-----------|------------|
-| CPU hotspot | Algorithm optimization, memoization, caching, worker threads | Medium |
-| Memory leak/bloat | Pool reuse, lazy initialization, WeakRef, scope cleanup | High |
-| I/O bound | Batching, async pipelines, streaming, connection pooling | Medium |
-| Network latency | Request coalescing, compression, CDN, prefetching | Low |
-| Rendering | Virtualization, memoization, CSS containment, code splitting | Medium |
-| Database | Index optimization, query rewriting, caching layer, denormalization | High |
-
-Prioritize optimizations by impact/effort ratio:
-
-| Priority | Criteria |
-|----------|----------|
-| P0 (Critical) | High impact + Low effort -- quick wins |
-| P1 (High) | High impact + Medium effort |
-| P2 (Medium) | Medium impact + Low effort |
-| P3 (Low) | Low impact or High effort -- defer |
-
-If complexity is High, use CLI tools for multi-perspective analysis (DISCUSS-OPT round) to evaluate trade-offs between competing strategies before finalizing the plan.
-
-Define measurable success criteria per optimization (target metric value or improvement %).
-
-## Phase 4: Plan Output
-
-1. Write optimization plan to `<session>/artifacts/optimization-plan.md`:
-
-   Each optimization MUST have a unique OPT-ID and self-contained detail block:
-
-   ```markdown
-   ### OPT-001: <title>
-   - Priority: P0
-   - Target bottleneck: <bottleneck from report>
-   - Target files: <file-list>
-   - Strategy: <selected approach>
-   - Expected improvement: <metric> by <X%>
-   - Risk level: <Low/Medium/High>
-   - Success criteria: <specific threshold to verify>
-   - Implementation guidance:
-     1. <step 1>
-     2. <step 2>
-     3. <step 3>
-
-   ### OPT-002: <title>
-   ...
-   ```
-
-   Requirements:
-   - Each OPT-ID is sequentially numbered (OPT-001, OPT-002, ...)
-   - Each optimization must be **non-overlapping** in target files
-   - Implementation guidance must be self-contained
-
-2. Update `<session>/.msg/meta.json` under `strategist` namespace:
-   - Read existing -> merge -> write back with optimization metadata
-
-3. If DISCUSS-OPT was triggered, record discussion summary in `<session>/discussions/DISCUSS-OPT.md`
+---
+role: strategist
+prefix: STRATEGY
+inner_loop: false
+discuss_rounds: [DISCUSS-OPT]
+message_types:
+  success: strategy_complete
+  error: error
+---
+
+# Optimization Strategist
+
+Analyze bottleneck reports and baseline metrics to design a prioritized optimization plan with concrete strategies, expected improvements, and risk assessments.
+
+## Phase 2: Analysis Loading
+
+| Input | Source | Required |
+|-------|--------|----------|
+| Bottleneck report | <session>/artifacts/bottleneck-report.md | Yes |
+| Baseline metrics | <session>/artifacts/baseline-metrics.json | Yes |
+| .msg/meta.json | <session>/.msg/meta.json | Yes |
+| Wisdom files | <session>/wisdom/patterns.md | No |
+
+1. Extract session path from task description
+2. Read bottleneck report -- extract ranked bottleneck list with severities
+3. Read baseline metrics -- extract current performance numbers
+4. Load .msg/meta.json for profiler findings (project_type, scope)
+5. Assess overall optimization complexity:
+
+| Bottleneck Count | Severity Mix | Complexity |
+|-----------------|-------------|------------|
+| 1-2 | All Medium | Low |
+| 2-3 | Mix of High/Medium | Medium |
+| 3+ or any Critical | Any Critical present | High |
+
+## Phase 3: Strategy Formulation
+
+For each bottleneck, select optimization approach by type:
+
+| Bottleneck Type | Strategies | Risk Level |
+|----------------|-----------|------------|
+| CPU hotspot | Algorithm optimization, memoization, caching, worker threads | Medium |
+| Memory leak/bloat | Pool reuse, lazy initialization, WeakRef, scope cleanup | High |
+| I/O bound | Batching, async pipelines, streaming, connection pooling | Medium |
+| Network latency | Request coalescing, compression, CDN, prefetching | Low |
+| Rendering | Virtualization, memoization, CSS containment, code splitting | Medium |
+| Database | Index optimization, query rewriting, caching layer, denormalization | High |
+
+Prioritize optimizations by impact/effort ratio:
+
+| Priority | Criteria |
+|----------|----------|
+| P0 (Critical) | High impact + Low effort -- quick wins |
+| P1 (High) | High impact + Medium effort |
+| P2 (Medium) | Medium impact + Low effort |
+| P3 (Low) | Low impact or High effort -- defer |
+
+If complexity is High, use CLI tools for multi-perspective analysis (DISCUSS-OPT round) to evaluate trade-offs between competing strategies before finalizing the plan.
+
+Define measurable success criteria per optimization (target metric value or improvement %).
+
+## Phase 4: Plan Output
+
+1. Write optimization plan to `<session>/artifacts/optimization-plan.md`:
+
+   Each optimization MUST have a unique OPT-ID and self-contained detail block:
+
+   ```markdown
+   ### OPT-001: <title>
+   - Priority: P0
+   - Target bottleneck: <bottleneck from report>
+   - Target files: <file-list>
+   - Strategy: <selected approach>
+   - Expected improvement: <metric> by <X%>
+   - Risk level: <Low/Medium/High>
+   - Success criteria: <specific threshold to verify>
+   - Implementation guidance:
+     1. <step 1>
+     2. <step 2>
+     3. <step 3>
+
+   ### OPT-002: <title>
+   ...
+   ```
+
+   Requirements:
+   - Each OPT-ID is sequentially numbered (OPT-001, OPT-002, ...)
+   - Each optimization must be **non-overlapping** in target files
+   - Implementation guidance must be self-contained
+
+2. Update `<session>/.msg/meta.json` under `strategist` namespace:
+   - Read existing -> merge -> write back with optimization metadata
+
+3. If DISCUSS-OPT was triggered, record discussion summary in `<session>/discussions/DISCUSS-OPT.md`

package/.codex/skills/team-perf-opt/specs/pipelines.md

@@ -1,65 +1,65 @@
-# Pipeline Definitions — Team Performance Optimization
-
-## Pipeline Modes
-
-### Single Mode (Linear with Review-Fix Cycle)
-
-```
-Stage 1           Stage 2           Stage 3           Stage 4
-PROFILE-001  -->  STRATEGY-001 -->  IMPL-001   --> BENCH-001
-[profiler]        [strategist]      [optimizer]    [benchmarker]
-                                        ^               |
-                                        +<--FIX-001---->+
-                                        |          REVIEW-001
-                                        +<-------->  [reviewer]
-                                  (max 3 iterations)
-```
-
-### Fan-out Mode (Shared stages 1-2, parallel branches 3-4)
-
-```
-Stage 1           Stage 2         CP-2.5          Stage 3+4 (per branch)
-PROFILE-001 --> STRATEGY-001 --+-> IMPL-B01 --> BENCH-B01 + REVIEW-B01 (fix cycle)
-                               +-> IMPL-B02 --> BENCH-B02 + REVIEW-B02 (fix cycle)
-                               +-> IMPL-B0N --> BENCH-B0N + REVIEW-B0N (fix cycle)
-                                                          |
-                                                     AGGREGATE -> Phase 5
-```
-
-### Independent Mode (M fully independent pipelines)
-
-```
-Pipeline A: PROFILE-A01 --> STRATEGY-A01 --> IMPL-A01 --> BENCH-A01 + REVIEW-A01
-Pipeline B: PROFILE-B01 --> STRATEGY-B01 --> IMPL-B01 --> BENCH-B01 + REVIEW-B01
-                                                          |
-                                                     AGGREGATE -> Phase 5
-```
-
-## Task Metadata Registry (Single Mode)
-
-| Task ID | Role | Phase | Dependencies | Description |
-|---------|------|-------|-------------|-------------|
-| PROFILE-001 | profiler | Stage 1 | (none) | Profile application, identify bottlenecks |
-| STRATEGY-001 | strategist | Stage 2 | PROFILE-001 | Design optimization plan from bottleneck report |
-| IMPL-001 | optimizer | Stage 3 | STRATEGY-001 | Implement highest-priority optimizations |
-| BENCH-001 | benchmarker | Stage 4 | IMPL-001 | Run benchmarks, compare vs baseline |
-| REVIEW-001 | reviewer | Stage 4 | IMPL-001 | Review optimization code for correctness |
-| FIX-001 | optimizer | Stage 3 (cycle) | REVIEW-001 or BENCH-001 | Fix issues found in review/benchmark |
-
-## Checkpoints
-
-| Checkpoint | Trigger | Behavior |
-|------------|---------|----------|
-| CP-1 | PROFILE-001 complete | User reviews bottleneck report, can refine scope |
-| CP-2 | STRATEGY-001 complete | User reviews optimization plan, can adjust priorities |
-| CP-2.5 | STRATEGY-001 complete (auto/fan-out) | Auto-create N branch tasks, spawn all IMPL-B* in parallel |
-| CP-3 | REVIEW/BENCH fail | Auto-create FIX task for that branch only (max 3x per branch) |
-| CP-4 | All tasks/branches complete | Aggregate results, interactive completion action |
-
-## Task Naming Rules
-
-| Mode | Stage 3 | Stage 4 | Fix | Retry |
-|------|---------|---------|-----|-------|
-| Single | IMPL-001 | BENCH-001, REVIEW-001 | FIX-001 | BENCH-001-R1, REVIEW-001-R1 |
-| Fan-out | IMPL-B01 | BENCH-B01, REVIEW-B01 | FIX-B01-1 | BENCH-B01-R1, REVIEW-B01-R1 |
-| Independent | IMPL-A01 | BENCH-A01, REVIEW-A01 | FIX-A01-1 | BENCH-A01-R1, REVIEW-A01-R1 |
+# Pipeline Definitions — Team Performance Optimization
+
+## Pipeline Modes
+
+### Single Mode (Linear with Review-Fix Cycle)
+
+```
+Stage 1           Stage 2           Stage 3           Stage 4
+PROFILE-001  -->  STRATEGY-001 -->  IMPL-001   --> BENCH-001
+[profiler]        [strategist]      [optimizer]    [benchmarker]
+                                        ^               |
+                                        +<--FIX-001---->+
+                                        |          REVIEW-001
+                                        +<-------->  [reviewer]
+                                  (max 3 iterations)
+```
+
+### Fan-out Mode (Shared stages 1-2, parallel branches 3-4)
+
+```
+Stage 1           Stage 2         CP-2.5          Stage 3+4 (per branch)
+PROFILE-001 --> STRATEGY-001 --+-> IMPL-B01 --> BENCH-B01 + REVIEW-B01 (fix cycle)
+                               +-> IMPL-B02 --> BENCH-B02 + REVIEW-B02 (fix cycle)
+                               +-> IMPL-B0N --> BENCH-B0N + REVIEW-B0N (fix cycle)
+                                                          |
+                                                     AGGREGATE -> Phase 5
+```
+
+### Independent Mode (M fully independent pipelines)
+
+```
+Pipeline A: PROFILE-A01 --> STRATEGY-A01 --> IMPL-A01 --> BENCH-A01 + REVIEW-A01
+Pipeline B: PROFILE-B01 --> STRATEGY-B01 --> IMPL-B01 --> BENCH-B01 + REVIEW-B01
+                                                          |
+                                                     AGGREGATE -> Phase 5
+```
+
+## Task Metadata Registry (Single Mode)
+
+| Task ID | Role | Phase | Dependencies | Description |
+|---------|------|-------|-------------|-------------|
+| PROFILE-001 | profiler | Stage 1 | (none) | Profile application, identify bottlenecks |
+| STRATEGY-001 | strategist | Stage 2 | PROFILE-001 | Design optimization plan from bottleneck report |
+| IMPL-001 | optimizer | Stage 3 | STRATEGY-001 | Implement highest-priority optimizations |
+| BENCH-001 | benchmarker | Stage 4 | IMPL-001 | Run benchmarks, compare vs baseline |
+| REVIEW-001 | reviewer | Stage 4 | IMPL-001 | Review optimization code for correctness |
+| FIX-001 | optimizer | Stage 3 (cycle) | REVIEW-001 or BENCH-001 | Fix issues found in review/benchmark |
+
+## Checkpoints
+
+| Checkpoint | Trigger | Behavior |
+|------------|---------|----------|
+| CP-1 | PROFILE-001 complete | User reviews bottleneck report, can refine scope |
+| CP-2 | STRATEGY-001 complete | User reviews optimization plan, can adjust priorities |
+| CP-2.5 | STRATEGY-001 complete (auto/fan-out) | Auto-create N branch tasks, spawn all IMPL-B* in parallel |
+| CP-3 | REVIEW/BENCH fail | Auto-create FIX task for that branch only (max 3x per branch) |
+| CP-4 | All tasks/branches complete | Aggregate results, interactive completion action |
+
+## Task Naming Rules
+
+| Mode | Stage 3 | Stage 4 | Fix | Retry |
+|------|---------|---------|-----|-------|
+| Single | IMPL-001 | BENCH-001, REVIEW-001 | FIX-001 | BENCH-001-R1, REVIEW-001-R1 |
+| Fan-out | IMPL-B01 | BENCH-B01, REVIEW-B01 | FIX-B01-1 | BENCH-B01-R1, REVIEW-B01-R1 |
+| Independent | IMPL-A01 | BENCH-A01, REVIEW-A01 | FIX-A01-1 | BENCH-A01-R1, REVIEW-A01-R1 |