Rework single-agent workflows; add write-tests; remove comparative-plan

- claude-agent → standard-agent (complexity≥8, spec_adherence≥9 → Sonnet-class)
- smart-agent: complexity≥9 → Opus; documents MiniMax not in registry
- functional-agent: labels=[airouter], cost_efficiency≥9 → Qwen3.6
- write-tests: two-node DAG (write_tests → review_coverage), spec-driven
  test authoring with coverage gap report in JSON
- Remove comparative-plan (superseded by tdd-impl audit pattern)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

workflows/comparative-plan.yaml

@@ -1,173 +0,0 @@
-name: comparative-plan
-version: 1
-description: "3-way comparative planning: two models plan independently, cross-review, then synthesize"
-
-params:
-  required:
-    task_description:
-      type: string
-      description: "What to plan — the task or feature to design"
-    project_id:
-      type: string
-      description: "Target project identifier"
-  optional:
-    model_a:
-      type: string
-      default: null
-      description: "Override model A endpoint (auto-selected from registry if omitted)"
-    model_b:
-      type: string
-      default: null
-      description: "Override model B endpoint (auto-selected from registry if omitted)"
-    best_practices:
-      type: list
-      default:
-        - api-design
-        - spec-driven-development
-        - test-driven-development
-        - security-architecture
-      description: "Best practice topics to review against"
-    repo:
-      type: string
-      default: null
-      description: "Git repo URL to clone for context (optional)"
-
-nodes:
-  plan_a:
-    name: "Plan A"
-    prompt: |
-      Create a detailed implementation plan for the following task:
-
-      {{ task_description }}
-
-      ## Instructions
-      - Follow spec-driven development methodology
-      - Structure your plan with: Overview, Phases, Files to create/modify, Test strategy, Dependencies
-      - Be specific about data models, API contracts, and interfaces
-      - Consider security, error handling, and edge cases
-      - Write your final plan to /workspace/project/output.md
-    harness: planning/v1
-    requirements:
-      min_scores:
-        complexity: 7
-        spec_adherence: 8
-
-  plan_b:
-    name: "Plan B"
-    prompt: |
-      Create a detailed implementation plan for the following task:
-
-      {{ task_description }}
-
-      ## Instructions
-      - Follow spec-driven development methodology
-      - Structure your plan with: Overview, Phases, Files to create/modify, Test strategy, Dependencies
-      - Be specific about data models, API contracts, and interfaces
-      - Consider security, error handling, and edge cases
-      - Write your final plan to /workspace/project/output.md
-    harness: planning/v1
-    requirements:
-      min_scores:
-        complexity: 7
-        spec_adherence: 8
-
-  review_a_of_b:
-    name: "Review: A reviews B's plan"
-    depends_on: [plan_a, plan_b]
-    prompt: |
-      You are reviewing an implementation plan against best practices.
-
-      ## Best Practices to Check Against
-      Read and apply these best practice topics: {{ best_practices | join(', ') }}
-
-      ## Plan to Review
-      The following plan was produced by another model. Review it critically.
-
-      <<ARTIFACT:plan_b:output>>
-
-      ## Instructions
-      1. Read each relevant best practice file from /best-practices/
-      2. Check the plan against each practice
-      3. List specific, numbered improvement points
-      4. For each point, cite which best practice it violates or could better follow
-      5. Be concrete — say what should change, not just that something is wrong
-
-      Write your review to /workspace/project/output.md
-    harness: planning/v1
-    requirements:
-      min_scores:
-        spec_adherence: 8
-
-  review_b_of_a:
-    name: "Review: B reviews A's plan"
-    depends_on: [plan_a, plan_b]
-    prompt: |
-      You are reviewing an implementation plan against best practices.
-
-      ## Best Practices to Check Against
-      Read and apply these best practice topics: {{ best_practices | join(', ') }}
-
-      ## Plan to Review
-      The following plan was produced by another model. Review it critically.
-
-      <<ARTIFACT:plan_a:output>>
-
-      ## Instructions
-      1. Read each relevant best practice file from /best-practices/
-      2. Check the plan against each practice
-      3. List specific, numbered improvement points
-      4. For each point, cite which best practice it violates or could better follow
-      5. Be concrete — say what should change, not just that something is wrong
-
-      Write your review to /workspace/project/output.md
-    harness: planning/v1
-    requirements:
-      min_scores:
-        spec_adherence: 8
-
-  synthesize:
-    name: "Synthesize final plan"
-    depends_on: [review_a_of_b, review_b_of_a]
-    prompt: |
-      You are synthesizing a final implementation plan from two competing plans and their cross-reviews.
-
-      ## Original Task
-      {{ task_description }}
-
-      ## Plan A
-      <<ARTIFACT:plan_a:output>>
-
-      ## Plan B
-      <<ARTIFACT:plan_b:output>>
-
-      ## Review of Plan B (by the model that wrote Plan A)
-      <<ARTIFACT:review_a_of_b:output>>
-
-      ## Review of Plan A (by the model that wrote Plan B)
-      <<ARTIFACT:review_b_of_a:output>>
-
-      ## Instructions
-      1. Identify the strongest elements from each plan
-      2. Address all improvement points raised in both reviews
-      3. Synthesize a single, improved plan that combines the best of both
-      4. Structure: Overview, Phases, Files, Test strategy, Dependencies
-      5. Flag any unresolved disagreements between the reviews
-
-      Write the final synthesized plan to /workspace/project/output.md
-    harness: planning/v1
-    requirements:
-      min_scores:
-        complexity: 8
-        spec_adherence: 9
-        creativity: 7
-
-scoring:
-  type: comparative_review
-  reviews:
-    - review_node: review_a_of_b
-      scored_model_node: plan_b
-      dimension: spec_adherence
-    - review_node: review_b_of_a
-      scored_model_node: plan_a
-      dimension: spec_adherence
-  method: fewer_improvement_points_wins

workflows/functional-agent.yaml

@@ -0,0 +1,49 @@
+name: functional-agent
+version: 1
+description: >
+  Cost-efficient single-agent workflow via Airouter (Qwen3.6). Routes exclusively to
+  the airouter dispatcher (labels: [airouter], cost_efficiency ≥ 9). Use for narrow,
+  well-scoped tasks where throughput and cost matter — parallel subsystem work,
+  bulk fixes, or tasks with explicit instructions.
+
+  Hard cap: 3 concurrent airouter tasks. No web search available in container.
+  Keep prompts directive and single-file/single-concern scoped for best results.
+
+params:
+  required:
+    task_description:
+      type: string
+      description: "Task prompt for the agent"
+    project_id:
+      type: string
+      description: "Project identifier for task grouping"
+    repo_url:
+      type: string
+      description: "Git repo URL for the agent to clone"
+    agent_repo_url:
+      type: string
+      description: "Agent repo URL for branch-per-task persistence"
+  optional:
+    harness:
+      type: string
+      default: "code-airouter-repo/v1"
+      description: "Harness to use. Override to change context/credentials (default: code-airouter-repo/v1)"
+    space_id:
+      type: string
+      default: "default"
+      description: "Space identifier"
+
+nodes:
+  agent:
+    name: "agent"
+    prompt: "{{ task_description }}"
+    harness: "{{ harness }}"
+    requirements:
+      labels: [airouter]
+      min_scores:
+        cost_efficiency: 9
+    on_success:
+      - type: commit_pr
+        params:
+          repo_url: "{{ repo_url }}"
+          agent_repo_url: "{{ agent_repo_url }}"

workflows/smart-agent.yaml

@@ -0,0 +1,48 @@
+name: smart-agent
+version: 1
+description: >
+  High-capability single-agent workflow. Routes to the best available reasoning model
+  (complexity ≥ 9 — currently claude-opus-4). Use for complex implementation, planning,
+  or analysis tasks where quality matters more than cost.
+
+  MiniMax is not in the model registry and will not be auto-selected; use the
+  minimax-code-repo or minimax-planning task templates directly for MiniMax tasks.
+
+params:
+  required:
+    task_description:
+      type: string
+      description: "Task prompt for the agent"
+    project_id:
+      type: string
+      description: "Project identifier for task grouping"
+    repo_url:
+      type: string
+      description: "Git repo URL for the agent to clone"
+    agent_repo_url:
+      type: string
+      description: "Agent repo URL for branch-per-task persistence"
+  optional:
+    harness:
+      type: string
+      default: "code-opus-repo/v1"
+      description: "Harness to use. Override to change context/credentials (default: code-opus-repo/v1)"
+    space_id:
+      type: string
+      default: "default"
+      description: "Space identifier"
+
+nodes:
+  agent:
+    name: "agent"
+    prompt: "{{ task_description }}"
+    harness: "{{ harness }}"
+    requirements:
+      min_scores:
+        complexity: 9
+        spec_adherence: 8
+    on_success:
+      - type: commit_pr
+        params:
+          repo_url: "{{ repo_url }}"
+          agent_repo_url: "{{ agent_repo_url }}"

workflows/standard-agent.yaml

@@ -1,15 +1,15 @@
-name: claude-agent
+name: standard-agent
 version: 1
 description: >
-  Minimal single-agent workflow. One Claude code agent node.
+  Standard single-agent workflow. Routes to a capable, balanced model
-  Use this as the standard wrapper when submitting simple single-agent tasks
+  (complexity ≥ 8, spec_adherence ≥ 9 — currently selects from Sonnet-class models).
-  via POST /tasks with a workflow field.
+  Default for most implementation tasks where quality and cost are balanced.
 
 params:
   required:
     task_description:
       type: string
-      description: "Task prompt for the Claude agent"
+      description: "Task prompt for the agent"
     project_id:
       type: string
       description: "Project identifier for task grouping"
@@ -23,7 +23,7 @@ params:
     harness:
       type: string
       default: "code-sonnet-repo/v1"
-      description: "Harness to use (default: code-sonnet-repo/v1)"
+      description: "Harness to use. Override to change context/credentials (default: code-sonnet-repo/v1)"
     space_id:
       type: string
       default: "default"
@@ -34,6 +34,10 @@ nodes:
     name: "agent"
     prompt: "{{ task_description }}"
     harness: "{{ harness }}"
+    requirements:
+      min_scores:
+        complexity: 8
+        spec_adherence: 9
     on_success:
       - type: commit_pr
         params:

workflows/write-tests.yaml

@@ -0,0 +1,117 @@
+name: write-tests
+version: 1
+description: >
+  Two-node spec-driven test writing workflow. First node writes tests from the spec
+  (one test per requirement, edge cases, property tests where applicable). Second node
+  reviews coverage — checking every numbered requirement has a corresponding test and
+  flagging any gaps.
+
+  Output: test files committed to the agent-repo branch; coverage gap report in the
+  review node's output artifact.
+
+params:
+  required:
+    spec_file:
+      type: string
+      description: "Path to the spec file in the repo (e.g. spec/my-feature.md)"
+    project_id:
+      type: string
+      description: "Target project identifier"
+    repo_url:
+      type: string
+      description: "Git repo URL containing the spec"
+    agent_repo_url:
+      type: string
+      description: "Agent repo URL for branch-per-task output persistence"
+  optional:
+    task_description:
+      type: string
+      default: ""
+      description: "Additional context about what is being tested (supplements the spec)"
+    test_output_dir:
+      type: string
+      default: "tests/"
+      description: "Directory to write test files into (default: tests/)"
+    test_framework:
+      type: string
+      default: "pytest"
+      description: "Test framework to use (default: pytest)"
+    writer_harness:
+      type: string
+      default: "test-writing-opus-repo/v1"
+      description: "Harness for the test-writing node (default: test-writing-opus-repo/v1)"
+    reviewer_harness:
+      type: string
+      default: "planning/v1"
+      description: "Harness for the coverage review node (default: planning/v1)"
+
+nodes:
+  write_tests:
+    name: "Write tests from spec"
+    prompt: |
+      You are writing a test suite from a spec file. Tests are the contract — they will
+      be run against an agent's implementation. Write them now, before the implementation exists.
+
+      ## Spec file
+      Read the spec at `{{ spec_file }}` in the cloned repo at `/workspace/project/`.
+
+      {% if task_description %}
+      ## Additional context
+      {{ task_description }}
+      {% endif %}
+
+      ## Instructions
+      1. Read the spec carefully. Identify every numbered requirement (e.g. MY-1, MY-2...).
+      2. For each requirement, write at least one test function named `test_<req_id>_<short_description>`.
+      3. Cover edge cases explicitly — empty inputs, boundary values, error paths.
+      4. Add property-based tests (Hypothesis) where the requirement involves ranges or invariants.
+      5. Write tests to `{{ test_output_dir }}` — one file per logical group (mirrors spec sections).
+      6. Use `{{ test_framework }}` conventions. Tests should fail immediately (no implementation exists).
+      7. Do NOT write any implementation code. Only test files.
+
+      After writing all tests, write a coverage summary to `/workspace/project/output.md`:
+      - List every requirement ID from the spec
+      - For each: which test function(s) cover it
+      - Note any requirements you could not write a test for (and why)
+    harness: "{{ writer_harness }}"
+    requirements:
+      min_scores:
+        spec_adherence: 9
+        test_pass_rate: 8
+
+  review_coverage:
+    name: "Review test coverage"
+    depends_on: [write_tests]
+    prompt: |
+      You are reviewing the coverage of a freshly written test suite against its spec.
+
+      ## Spec file
+      Read the spec at `{{ spec_file }}` in the cloned repo at `/workspace/project/`.
+
+      ## Test summary written by the previous agent
+      <<ARTIFACT:write_tests:output>>
+
+      ## Instructions
+      1. Read the spec and extract every numbered requirement.
+      2. Cross-reference each requirement against the test summary above.
+      3. For each requirement, determine: fully covered / partially covered / not covered.
+      4. Flag any test functions that appear to test behaviour NOT in the spec (over-specification).
+
+      Write your review to `/workspace/project/output.md` as:
+
+      ```json
+      {
+        "covered": ["REQ-1", "REQ-2"],
+        "partial": [{"id": "REQ-3", "reason": "happy path only, error case missing"}],
+        "missing": ["REQ-4", "REQ-5"],
+        "over_specified": ["test_something_not_in_spec"],
+        "summary": "one paragraph"
+      }
+      ```
+
+      Then list specific, actionable improvements for any partial or missing coverage.
+    harness: "{{ reviewer_harness }}"
+    requirements:
+      min_scores:
+        complexity: 8
+        spec_adherence: 9