claude-code-workflow 7.2.9 → 7.2.11

package/.claude/skills/team-issue/role-specs/integrator.md

@@ -1,86 +0,0 @@
----
-prefix: MARSHAL
-inner_loop: false
-message_types:
-  success: queue_ready
-  conflict: conflict_found
-  error: error
----
-
-# Issue Integrator
-
-Queue orchestration, conflict detection, and execution order optimization. Uses CLI tools for intelligent queue formation with DAG-based parallel groups.
-
-## Phase 2: Collect Bound Solutions
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Issue IDs | Task description (GH-\d+ or ISS-\d{8}-\d{6}) | Yes |
-| Bound solutions | `ccw issue solutions <id> --json` | Yes |
-| .msg/meta.json | <session>/wisdom/.msg/meta.json | No |
-
-1. Extract issue IDs from task description via regex
-2. Verify all issues have bound solutions:
-
-```
-Bash("ccw issue solutions <issueId> --json")
-```
-
-3. Check for unbound issues:
-
-| Condition | Action |
-|-----------|--------|
-| All issues bound | Proceed to Phase 3 |
-| Any issue unbound | Report error to coordinator, STOP |
-
-## Phase 3: Queue Formation via CLI
-
-**CLI invocation**:
-
-```
-Bash("ccw cli -p \"
-PURPOSE: Form execution queue for <count> issues with conflict detection and optimal ordering; success = DAG-based queue with parallel groups written to execution-queue.json
-
-TASK: • Load all bound solutions from .workflow/issues/solutions/ • Analyze file conflicts between solutions • Build dependency graph • Determine optimal execution order (DAG-based) • Identify parallel execution groups • Write queue JSON
-
-MODE: analysis
-
-CONTEXT: @.workflow/issues/solutions/**/*.json | Memory: Issues to queue: <issueIds>
-
-EXPECTED: Queue JSON with: ordered issue list, conflict analysis, parallel_groups (issues that can run concurrently), depends_on relationships
-Write to: .workflow/issues/queue/execution-queue.json
-
-CONSTRAINTS: Resolve file conflicts | Optimize for parallelism | Maintain dependency order
-\" --tool gemini --mode analysis", { run_in_background: true })
-```
-
-**Parse queue result**:
-
-```
-Read(".workflow/issues/queue/execution-queue.json")
-```
-
-**Queue schema**:
-
-```json
-{
-  "queue": [{ "issue_id": "", "solution_id": "", "order": 0, "depends_on": [], "estimated_files": [] }],
-  "conflicts": [{ "issues": [], "files": [], "resolution": "" }],
-  "parallel_groups": [{ "group": 0, "issues": [] }]
-}
-```
-
-## Phase 4: Conflict Resolution & Reporting
-
-**Queue validation**:
-
-| Condition | Action |
-|-----------|--------|
-| Queue file exists, no unresolved conflicts | Report `queue_ready` |
-| Queue file exists, has unresolved conflicts | Report `conflict_found` for user decision |
-| Queue file not found | Report `error`, STOP |
-
-**Queue metrics for report**: queue size, parallel group count, resolved conflict count, execution order list.
-
-Update `<session>/wisdom/.msg/meta.json` under `integrator` namespace:
-- Read existing -> merge `{ "integrator": { queue_size, parallel_groups, conflict_count } }` -> write back

package/.claude/skills/team-issue/role-specs/planner.md

@@ -1,83 +0,0 @@
----
-prefix: SOLVE
-inner_loop: false
-additional_prefixes: [SOLVE-fix]
-message_types:
-  success: solution_ready
-  multi: multi_solution
-  error: error
----
-
-# Issue Planner
-
-Design solutions and decompose into implementation tasks. Uses CLI tools for ACE exploration and solution generation. For revision tasks (SOLVE-fix), design alternative approaches addressing reviewer feedback.
-
-## Phase 2: Context Loading
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Issue ID | Task description (GH-\d+ or ISS-\d{8}-\d{6}) | Yes |
-| Explorer context | `<session>/explorations/context-<issueId>.json` | No |
-| Review feedback | Task description (for SOLVE-fix tasks) | No |
-| .msg/meta.json | <session>/wisdom/.msg/meta.json | No |
-
-1. Extract issue ID from task description via regex: `(?:GH-\d+|ISS-\d{8}-\d{6})`
-2. If no issue ID found -> report error, STOP
-3. Load explorer context report (if available):
-
-```
-Read("<session>/explorations/context-<issueId>.json")
-```
-
-4. Check if this is a revision task (SOLVE-fix-N):
-   - If yes, extract reviewer feedback from task description
-   - Design alternative approach addressing reviewer concerns
-5. Load wisdom files for accumulated codebase knowledge
-
-## Phase 3: Solution Generation via CLI
-
-**CLI invocation**:
-
-```
-Bash("ccw cli -p \"
-PURPOSE: Design solution for issue <issueId> and decompose into implementation tasks; success = solution bound to issue with task breakdown
-
-TASK: • Load issue details from ccw issue status • Analyze explorer context • Design solution approach • Break down into implementation tasks • Generate solution JSON • Bind solution to issue
-
-MODE: analysis
-
-CONTEXT: @**/* | Memory: Issue <issueId> - <issue.title> (Priority: <issue.priority>)
-Explorer findings: <explorerContext.key_findings>
-Relevant files: <explorerContext.relevant_files>
-Complexity: <explorerContext.complexity_assessment>
-
-EXPECTED: Solution JSON with: issue_id, solution_id, approach, tasks (ordered list with descriptions), estimated_files, dependencies
-Write to: <session>/solutions/solution-<issueId>.json
-Then bind: ccw issue bind <issueId> <solution_id>
-
-CONSTRAINTS: Follow existing patterns | Minimal changes | Address reviewer feedback if SOLVE-fix task
-\" --tool gemini --mode analysis", { run_in_background: true })
-```
-
-**Expected CLI output**: Solution file path and binding confirmation
-
-**Parse result**:
-
-```
-Read("<session>/solutions/solution-<issueId>.json")
-```
-
-## Phase 4: Solution Selection & Reporting
-
-**Outcome routing**:
-
-| Condition | Message Type | Action |
-|-----------|-------------|--------|
-| Single solution auto-bound | `solution_ready` | Report to coordinator |
-| Multiple solutions pending | `multi_solution` | Report for user selection |
-| No solution generated | `error` | Report failure to coordinator |
-
-Write solution summary to `<session>/solutions/solution-<issueId>.json`.
-
-Update `<session>/wisdom/.msg/meta.json` under `planner` namespace:
-- Read existing -> merge `{ "planner": { issue_id, solution_id, task_count, is_revision } }` -> write back

package/.claude/skills/team-issue/role-specs/reviewer.md

@@ -1,89 +0,0 @@
----
-prefix: AUDIT
-inner_loop: false
-message_types:
-  success: approved
-  concerns: concerns
-  rejected: rejected
-  error: error
----
-
-# Issue Reviewer
-
-Review solution plans for technical feasibility, risk, and completeness. Quality gate role between plan and execute phases. Provides clear verdicts: approved, rejected, or concerns.
-
-## Phase 2: Context & Solution Loading
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Issue IDs | Task description (GH-\d+ or ISS-\d{8}-\d{6}) | Yes |
-| Explorer context | `<session>/explorations/context-<issueId>.json` | No |
-| Bound solution | `ccw issue solutions <id> --json` | Yes |
-| .msg/meta.json | <session>/wisdom/.msg/meta.json | No |
-
-1. Extract issue IDs from task description via regex
-2. Load explorer context reports for each issue
-3. Load bound solutions for each issue:
-
-```
-Bash("ccw issue solutions <issueId> --json")
-```
-
-## Phase 3: Multi-Dimensional Review
-
-Review each solution across three weighted dimensions:
-
-**Technical Feasibility (40%)**:
-
-| Criterion | Check |
-|-----------|-------|
-| File Coverage | Solution covers all affected files from explorer context |
-| Dependency Awareness | Considers dependency cascade effects |
-| API Compatibility | Maintains backward compatibility |
-| Pattern Conformance | Follows existing code patterns (ACE semantic validation) |
-
-**Risk Assessment (30%)**:
-
-| Criterion | Check |
-|-----------|-------|
-| Scope Creep | Solution stays within issue boundary (task_count <= 10) |
-| Breaking Changes | No destructive modifications |
-| Side Effects | No unforeseen side effects |
-| Rollback Path | Can rollback if issues occur |
-
-**Completeness (30%)**:
-
-| Criterion | Check |
-|-----------|-------|
-| All Tasks Defined | Task decomposition is complete (count > 0) |
-| Test Coverage | Includes test plan |
-| Edge Cases | Considers boundary conditions |
-
-**Score calculation**:
-
-```
-total_score = round(
-  technical_feasibility.score * 0.4 +
-  risk_assessment.score * 0.3 +
-  completeness.score * 0.3
-)
-```
-
-**Verdict rules**:
-
-| Score | Verdict | Message Type |
-|-------|---------|-------------|
-| >= 80 | approved | `approved` |
-| 60-79 | concerns | `concerns` |
-| < 60 | rejected | `rejected` |
-
-## Phase 4: Compile Audit Report
-
-1. Write audit report to `<session>/audits/audit-report.json`:
-   - Per-issue: issueId, solutionId, total_score, verdict, per-dimension scores and findings
-   - Overall verdict (any rejected -> overall rejected)
-
-2. Update `<session>/wisdom/.msg/meta.json` under `reviewer` namespace:
-   - Read existing -> merge `{ "reviewer": { overall_verdict, review_count, scores } }` -> write back
-
-3. For rejected solutions, include specific rejection reasons and actionable feedback for SOLVE-fix task creation

package/.claude/skills/team-iterdev/role-specs/architect.md

@@ -1,64 +0,0 @@
----
-prefix: DESIGN
-inner_loop: false
-message_types:
-  success: design_ready
-  revision: design_revision
-  error: error
----
-
-# Architect
-
-Technical design, task decomposition, and architecture decision records for iterative development.
-
-## Phase 2: Context Loading + Codebase Exploration
-
-| 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 |
-| Wisdom files | <session>/wisdom/ | No |
-
-1. Extract session path and requirement from task description
-2. Read .msg/meta.json for shared context (architecture_decisions, implementation_context)
-3. Read wisdom files if available (learnings.md, decisions.md, conventions.md)
-4. Explore codebase for existing patterns, module structure, dependencies:
-   - Use mcp__ace-tool__search_context for semantic discovery
-   - Identify similar implementations and integration points
-
-## Phase 3: Technical Design + Task Decomposition
-
-**Design strategy selection**:
-
-| Condition | Strategy |
-|-----------|----------|
-| Single module change | Direct inline design |
-| Cross-module change | Multi-component design with integration points |
-| Large refactoring | Phased approach with milestones |
-
-**Outputs**:
-
-1. **Design Document** (`<session>/design/design-<num>.md`):
-   - Architecture decision: approach, rationale, alternatives
-   - Component design: responsibility, dependencies, files, complexity
-   - Task breakdown: files, estimated complexity, dependencies, acceptance criteria
-   - Integration points and risks with mitigations
-
-2. **Task Breakdown JSON** (`<session>/design/task-breakdown.json`):
-   - Array of tasks with id, title, files, complexity, dependencies, acceptance_criteria
-   - Execution order for developer to follow
-
-## Phase 4: Design Validation
-
-| Check | Method | Pass Criteria |
-|-------|--------|---------------|
-| Components defined | Verify component list | At least 1 component |
-| Task breakdown exists | Verify task list | At least 1 task |
-| Dependencies mapped | All components have dependencies field | All present (can be empty) |
-| Integration points | Verify integration section | Key integrations documented |
-
-1. Run validation checks above
-2. Write architecture_decisions entry to .msg/meta.json:
-   - design_id, approach, rationale, components, task_count
-3. Write discoveries to wisdom/decisions.md and wisdom/conventions.md

package/.claude/skills/team-iterdev/role-specs/developer.md

@@ -1,73 +0,0 @@
----
-prefix: DEV
-inner_loop: true
-message_types:
-  success: dev_complete
-  progress: dev_progress
-  error: error
----
-
-# Developer
-
-Code implementer. Implements code according to design, incremental delivery. Acts as Generator in Generator-Critic loop (paired with reviewer).
-
-## Phase 2: Context Loading
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Task description | From task subject/description | Yes |
-| Session path | Extracted from task description | Yes |
-| .msg/meta.json | <session>/.msg/meta.json | Yes |
-| Design document | <session>/design/design-001.md | For non-fix tasks |
-| Task breakdown | <session>/design/task-breakdown.json | For non-fix tasks |
-| Review feedback | <session>/review/*.md | For fix tasks |
-| Wisdom files | <session>/wisdom/ | No |
-
-1. Extract session path from task description
-2. Read .msg/meta.json for shared context
-3. Detect task type:
-
-| Task Type | Detection | Loading |
-|-----------|-----------|---------|
-| Fix task | Subject contains "fix" | Read latest review file for feedback |
-| Normal task | No "fix" in subject | Read design document + task breakdown |
-
-4. Load previous implementation_context from .msg/meta.json
-5. Read wisdom files for conventions and known issues
-
-## Phase 3: Code Implementation
-
-**Implementation strategy selection**:
-
-| Task Count | Complexity | Strategy |
-|------------|------------|----------|
-| <= 2 tasks | Low | Direct: inline Edit/Write |
-| 3-5 tasks | Medium | Single agent: one code-developer for all |
-| > 5 tasks | High | Batch agent: group by module, one agent per batch |
-
-**Fix Task Mode** (GC Loop):
-- Focus on review feedback items only
-- Fix critical issues first, then high, then medium
-- Do NOT change code that was not flagged
-- Maintain existing code style and patterns
-
-**Normal Task Mode**:
-- Read target files, apply changes using Edit or Write
-- Follow execution order from task breakdown
-- Validate syntax after each major change
-
-## Phase 4: Self-Validation
-
-| Check | Method | Pass Criteria |
-|-------|--------|---------------|
-| Syntax | tsc --noEmit or equivalent | No errors |
-| File existence | Verify all planned files exist | All files present |
-| Import resolution | Check no broken imports | All imports resolve |
-
-1. Run syntax check: `tsc --noEmit` / `python -m py_compile` / equivalent
-2. Auto-fix if validation fails (max 2 attempts)
-3. Write dev log to `<session>/code/dev-log.md`:
-   - Changed files count, syntax status, fix task flag, file list
-4. Update implementation_context in .msg/meta.json:
-   - task, changed_files, is_fix, syntax_clean
-5. Write discoveries to wisdom/learnings.md

package/.claude/skills/team-iterdev/role-specs/reviewer.md

@@ -1,65 +0,0 @@
----
-prefix: REVIEW
-inner_loop: false
-message_types:
-  success: review_passed
-  revision: review_revision
-  critical: review_critical
-  error: error
----
-
-# Reviewer
-
-Code reviewer. Multi-dimensional review, quality scoring, improvement suggestions. Acts as Critic in Generator-Critic loop (paired with developer).
-
-## Phase 2: Context Loading
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Task description | From task subject/description | Yes |
-| Session path | Extracted from task description | Yes |
-| .msg/meta.json | <session>/.msg/meta.json | Yes |
-| Design document | <session>/design/design-001.md | For requirements alignment |
-| Changed files | Git diff | Yes |
-
-1. Extract session path from task description
-2. Read .msg/meta.json for shared context and previous review_feedback_trends
-3. Read design document for requirements alignment
-4. Get changed files via git diff, read file contents (limit 20 files)
-
-## Phase 3: Multi-Dimensional Review
-
-**Review dimensions**:
-
-| Dimension | Weight | Focus Areas |
-|-----------|--------|-------------|
-| Correctness | 30% | Logic correctness, boundary handling |
-| Completeness | 25% | Coverage of design requirements |
-| Maintainability | 25% | Readability, code style, DRY |
-| Security | 20% | Vulnerabilities, input validation |
-
-Per-dimension: scan modified files, record findings with severity (CRITICAL/HIGH/MEDIUM/LOW), include file:line references and suggestions.
-
-**Scoring**: Weighted average of dimension scores (1-10 each).
-
-**Output review report** (`<session>/review/review-<num>.md`):
-- Files reviewed count, quality score, issue counts by severity
-- Per-finding: severity, file:line, dimension, description, suggestion
-- Scoring breakdown by dimension
-- Signal: CRITICAL / REVISION_NEEDED / APPROVED
-- Design alignment notes
-
-## Phase 4: Trend Analysis + Verdict
-
-1. Compare with previous review_feedback_trends from .msg/meta.json
-2. Identify recurring issues, improvement areas, new issues
-
-| Verdict Condition | Message Type |
-|-------------------|--------------|
-| criticalCount > 0 | review_critical |
-| score < 7 | review_revision |
-| else | review_passed |
-
-3. Update review_feedback_trends in .msg/meta.json:
-   - review_id, score, critical count, high count, dimensions, gc_round
-4. Write discoveries to wisdom/learnings.md

package/.claude/skills/team-iterdev/role-specs/tester.md

@@ -1,87 +0,0 @@
----
-prefix: VERIFY
-inner_loop: false
-message_types:
-  success: verify_passed
-  failure: verify_failed
-  fix: fix_required
-  error: error
----
-
-# Tester
-
-Test validator. Test execution, fix cycles, and regression detection.
-
-## Phase 2: 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 | Yes |
-| Changed files | Git diff | Yes |
-
-1. Extract session path from task description
-2. Read .msg/meta.json for shared context
-3. Get changed files via git diff
-4. Detect test framework and command:
-
-| Detection | Method |
-|-----------|--------|
-| Test command | Check package.json scripts, pytest.ini, Makefile |
-| Coverage tool | Check for nyc, coverage.py, jest --coverage config |
-
-Common commands: npm test, pytest, go test ./..., cargo test
-
-## Phase 3: Execution + Fix Cycle
-
-**Iterative test-fix cycle** (max 5 iterations):
-
-| Step | Action |
-|------|--------|
-| 1 | Run test command |
-| 2 | Parse results, check pass rate |
-| 3 | Pass rate >= 95% -> exit loop (success) |
-| 4 | Extract failing test details |
-| 5 | Apply fix using CLI tool |
-| 6 | Increment iteration counter |
-| 7 | iteration >= MAX (5) -> exit loop (report failures) |
-| 8 | Go to Step 1 |
-
-**Fix delegation**: Use CLI tool to fix failing tests:
-
-```bash
-ccw cli -p "PURPOSE: Fix failing tests; success = all listed tests pass
-TASK: • Analyze test failure output • Identify root cause in changed files • Apply minimal fix
-MODE: write
-CONTEXT: @<changed-files> | Memory: Test output from current iteration
-EXPECTED: Code fixes that make failing tests pass without breaking other tests
-CONSTRAINTS: Only modify files in changed list | Minimal changes
-Test output: <test-failure-details>
-Changed files: <file-list>" --tool gemini --mode write --rule development-debug-runtime-issues
-```
-
-Wait for CLI completion before re-running tests.
-
-## Phase 4: Regression Check + Report
-
-1. Run full test suite for regression: `<test-command> --all`
-
-| Check | Method | Pass Criteria |
-|-------|--------|---------------|
-| Regression | Run full test suite | No FAIL in output |
-| Coverage | Run coverage tool | >= 80% (if configured) |
-
-2. Write verification results to `<session>/verify/verify-<num>.json`:
-   - verify_id, pass_rate, iterations, passed, timestamp, regression_passed
-
-3. Determine message type:
-
-| Condition | Message Type |
-|-----------|--------------|
-| passRate >= 0.95 | verify_passed |
-| passRate < 0.95 && iterations >= MAX | fix_required |
-| passRate < 0.95 | verify_failed |
-
-4. Update .msg/meta.json with test_patterns entry
-5. Write discoveries to wisdom/issues.md

package/.claude/skills/team-perf-opt/role-specs/benchmarker.md

@@ -1,110 +0,0 @@
----
-prefix: BENCH
-inner_loop: false
-message_types:
-  success: bench_complete
-  error: error
-  fix: fix_required
----
-
-# Performance Benchmarker
-
-Run benchmarks comparing before/after optimization metrics. Validate that improvements meet plan success criteria and detect any regressions.
-
-## Phase 2: Environment & Baseline Loading
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Baseline metrics | <session>/artifacts/baseline-metrics.json (shared) | Yes |
-| Optimization plan / detail | Varies by mode (see below) | Yes |
-| .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 -- benchmark only this branch's metrics |
-| `PipelineId: {P}` | Present | Independent pipeline -- use pipeline-scoped baseline |
-| Neither present | - | Single mode -- full benchmark |
-
-3. **Load baseline metrics**:
-   - Single / Fan-out: Read `<session>/artifacts/baseline-metrics.json` (shared baseline)
-   - Independent: Read `<session>/artifacts/pipelines/{P}/baseline-metrics.json`
-
-4. **Load optimization context**:
-   - Single: Read `<session>/artifacts/optimization-plan.md` -- all success criteria
-   - Fan-out branch: Read `<session>/artifacts/branches/B{NN}/optimization-detail.md` -- only this branch's criteria
-   - Independent: Read `<session>/artifacts/pipelines/{P}/optimization-plan.md`
-
-5. Load .msg/meta.json for project type and optimization scope
-6. Detect available benchmark tools from project:
-
-| Signal | Benchmark Tool | Method |
-|--------|---------------|--------|
-| package.json + vitest/jest | Test runner benchmarks | Run existing perf tests |
-| package.json + webpack/vite | Bundle analysis | Compare build output sizes |
-| Cargo.toml + criterion | Rust benchmarks | cargo bench |
-| go.mod | Go benchmarks | go test -bench |
-| Makefile with bench target | Custom benchmarks | make bench |
-| No tooling detected | Manual measurement | Timed execution via Bash |
-
-7. Get changed files scope from shared-memory:
-   - Single: `optimizer` namespace
-   - Fan-out: `optimizer.B{NN}` namespace
-   - Independent: `optimizer.{P}` namespace
-
-## Phase 3: Benchmark Execution
-
-Run benchmarks matching detected project type:
-
-**Frontend benchmarks**:
-- Compare bundle size before/after (build output analysis)
-- Measure render performance for affected components
-- Check for dependency weight changes
-
-**Backend benchmarks**:
-- Measure endpoint response times for affected routes
-- Profile memory usage under simulated load
-- Verify database query performance improvements
-
-**CLI / Library benchmarks**:
-- Measure execution time for representative workloads
-- Compare memory peak usage
-- Test throughput under sustained load
-
-**All project types**:
-- Run existing test suite to verify no regressions
-- Collect post-optimization metrics matching baseline format
-- Calculate improvement percentages per metric
-
-**Branch-scoped benchmarking** (fan-out mode):
-- Only benchmark metrics relevant to this branch's optimization (from optimization-detail.md)
-- Still check for regressions across all metrics (not just branch-specific ones)
-
-## Phase 4: Result Analysis
-
-Compare against baseline and plan criteria:
-
-| Metric | Threshold | Verdict |
-|--------|-----------|---------|
-| Target improvement vs baseline | Meets plan success criteria | PASS |
-| No regression in unrelated metrics | < 5% degradation allowed | PASS |
-| All plan success criteria met | Every criterion satisfied | PASS |
-| Improvement below target | > 50% of target achieved | WARN |
-| Regression detected | Any unrelated metric degrades > 5% | FAIL -> fix_required |
-| Plan criteria not met | Any criterion not satisfied | FAIL -> fix_required |
-
-1. Write benchmark results to output path:
-   - Single: `<session>/artifacts/benchmark-results.json`
-   - Fan-out: `<session>/artifacts/branches/B{NN}/benchmark-results.json`
-   - Independent: `<session>/artifacts/pipelines/{P}/benchmark-results.json`
-   - Content: Per-metric: name, baseline value, current value, improvement %, verdict; Overall verdict: PASS / WARN / FAIL; Regression details (if any)
-
-2. Update `<session>/.msg/meta.json` under scoped namespace:
-   - Single: merge `{ "benchmarker": { verdict, improvements, regressions } }`
-   - Fan-out: merge `{ "benchmarker.B{NN}": { verdict, improvements, regressions } }`
-   - Independent: merge `{ "benchmarker.{P}": { verdict, improvements, regressions } }`
-
-3. If verdict is FAIL, include detailed feedback in message for FIX task creation:
-   - Which metrics failed, by how much, suggested investigation areas