create-harness-vibe-coding 0.8.8 → 0.8.9

package/templates/common/Harness/WF.md

@@ -1,255 +1,135 @@
-# WF Mode - Long Task Workflow
+# WF Mode — Dynamic Orchestration Kernel
 
-Use this when work is long, difficult, uncertain, multi-file, multi-agent, or
-user-triggered with `/wf`, `$wf`, `wf mode`, `workflow mode`, or `wk mode`.
+`/wf` is a **dynamic workflow kernel**, not a fixed serial pipeline. The orchestrator (main agent) makes decisions, dispatches agents, synthesizes returns, and owns final acceptance. It does NOT do bulk source reading, log scraping, or task-state paperwork — those are delegated to appropriate subagents.
 
-This is a Ralph-style harness loop: keep moving through evidence, bounded
-exploration, second planning, implementation, review, verification, and recovery
-instead of stalling on the first obstacle.
+WF is **explicit only**. Complexity does not auto-trigger WF.
 
-WF is acceptance-driven. The source of truth is not the implementation, not the
-tests, and not the agent's summary. The source of truth is the PRD-derived
-Acceptance Criteria. Code, tests, review, validation, debug, and memory must
-trace to AC IDs. Load [ACCEPTANCE_PROTOCOL.md](ACCEPTANCE_PROTOCOL.md) for the
-gate contract, [AGENT_ISOLATION.md](AGENT_ISOLATION.md) for role separation, and
-[HARNESS_BRIDGE.md](HARNESS_BRIDGE.md) for UI/API/browser evidence.
+## Shared Kernel
+
+All WF variants (`/wf`, `/wf-max`, `/wf-auto`, `/wf-auto-spark`, `/wf-review`, `/wf-browser`) share the orchestration engine defined in [WF-KERNEL.md](WF-KERNEL.md). That file is the authoritative source for:
+
+- Role / Model Matrix (which agent, which model tier, for which work)
+- Dynamic ready-queue pseudocode
+- Dispatch packet fields
+- Task type → agent/skill routing
+- Tier-aware acceptance gates
+- State ownership rules (controller + task-scribe)
+
+Resumable state follows [WF-STATE.md](WF-STATE.md): STATE.json is the machine-readable resume truth; the ready queue is persisted there across sessions.
+
+This file defines the `/wf` user contract, tiers, and the standard orchestration loop.
 
 ## Trigger
 
-Enter WF mode when any of these are true:
-
-- The user explicitly says `/wf`, `$wf`, `wf mode`, `workflow mode`, `wk mode`,
-  or asks for the full workflow.
-- The task needs more than one step, more than three files, or more than one
-  subsystem.
-- The task needs research, architecture judgment, browser/API validation, or
-  migration planning.
-- Confidence in intent, architecture, or implementation is below 95%.
-- The same command, test, tool, or approach fails twice.
-- The user explicitly says `/wf-max [task]`, `$wf-max [task]`, or `wf max` (for
-  maximum-parallelism mode, see [WF-MAX.md](WF-MAX.md)).
-
-Two distinct trigger classes; do not conflate them:
-
-- Explicit invocation (`/wf`, `$wf`, `wf mode`, `workflow mode`, `wk mode`,
-  `/wf-max`, `$wf-max`): role fan-out is mandatory and unconditional. File
-  count, task size, and subsystem count are irrelevant. A one-file task invoked
-  with WF still schedules the complete role chain before closeout.
-- Auto-triggering decides whether the harness enters WF mode on its own. It can
-  only escalate into WF, never downgrade an explicit command out of WF.
-
-## Complete Role Chain Requirement
-
-WF mode requires the complete role chain by default.
-
-Normative rule: Explicit `/wf`, `$wf`, `wf mode`, `workflow mode`, or `wk mode` MUST cover every mandatory role class before closeout: Plan, Research, Architecture, Test, Implement, Independent Validation, Cross-Review, Reflect, and Final Acceptance.
-
-- Explicit `/wf`, `$wf`, `wf mode`, `workflow mode`, or `wk mode` MUST schedule
-  the complete role chain at intake. Use real subagents when the runtime
-  supports them; otherwise emulate those roles as bounded passes and record the
-  fallback.
-- Mandatory role classes:
-  - Plan: `planner`
-  - Research: `researcher` or `docs-researcher`; use both when local and external/current facts matter
-  - Architecture: `architect`
-  - Test: `test-writer`
-  - Implement: `implementer` and `debugger` when needed
-  - Independent Validation: `verifier` records AC-mapped evidence before cross-review
-  - Cross-Review: at least two independent review lenses after implementation
-  - Reflect: `reflector`
-  - Final Acceptance: controller accepts only after cross-review passes and `reflector` returns PASS
-- Runtime mapping:
-  - Claude Code: prefer subagents from `.claude/agents/`.
-  - Codex: prefer the available Codex subagent surface; if unavailable, use
-    bounded passes with the same roles and evidence contract.
-- Collaboration decision tree (replaces the old "7:3" heuristic with concrete
-  conditions):
-  - Explicit WF/WK mode -> complete role chain, no exceptions.
-  - 3+ files changed -> complete role chain.
-  - Cross-layer change -> complete role chain plus separate architecture review.
-  - Uncertain scope or approach -> complete role chain with both researcher and architect passes.
-  - 1-2 files, well-understood, not in WF mode -> solo is acceptable.
-  - Repeated failure on the same task -> stop solo and switch to multi-role.
-- Default `/wf` startup records the full chain in the task plan. Dependency-bound
-  roles run when their phase is ready; they are not optional.
-
-## Exploration Gate
-
-- [ ] Controller has not read source files directly; only Harness docs, root
-  agent entries, and subagent or bounded-pass returns.
-- [ ] Complete role chain is scheduled in the task plan.
-- [ ] Plan, Research, and Architecture role passes each have one specific question before second planning.
-- [ ] Role passes were dispatched together when the runtime supports parallel
-  dispatch.
-- [ ] Agent count is at least `max(3, ceil(estimated_dirs / 2))`; estimate from
-  prompt/docs and run a second wave if returns reveal more.
-- [ ] Fallbacks are recorded in `Harness/tasks/<task-id>/PLAN.md`.
-
-For maximum-parallelism mode (write-set coloring, wave dispatch, parallel
-reviewers), use `/wf-max [task]` in Claude Code or `$wf-max [task]` in Codex and
-see [WF-MAX.md](WF-MAX.md).
-
-## WF Loop
+WF is **explicit only**. Enter WF ONLY when the user explicitly types:
+- `/wf`, `$wf`, `/skills wf`
+
+These are NOT WF triggers:
+- Multi-step work, multi-file changes, complexity, uncertainty, architecture scope, browser/API behavior, repeated failure
+- Those may need planning, subagents, or tests — but not WF
+
+## Memory Preflight
+
+1. Load `CLAUDE.md`, `Harness/MEMORY.md` index only, then `Harness/README.md`.
+2. Load `Harness/memory/*` only when `MEMORY_PROTOCOL.md` scenario hints match.
+3. Record `Memory preflight: done` and `Memory hints: none | <file/path + reason>`.
+
+## Standard Orchestration Loop
+
+The `/wf` kernel follows a dependency-driven ready-queue, NOT a fixed serial phase list.
 
 ```text
 Intake
--> confidence gate
--> parallel planner / researcher / docs-researcher / architect roles
--> Mini PRD
--> Acceptance Criteria
--> UI/API contracts
--> test plan
--> second plan
--> test-writer
--> implementer
--> independent validator
--> cross-review: spec/AC reviewer + code/architecture/test reviewer
--> reflector
--> if failed: debugger -> verifier -> cross-review -> reflector -> loop
--> memory closeout with evidence
+-> Understand user goal; ask <=3 blocking decision questions (each with recommendation)
+-> Requirement analysis: scope, non-goals, risks, acceptance direction
+-> Mini PRD (compact, not a large document)
+-> 1-3 ACs (expand only for high-risk triggers)
+-> Plan: task split, dependencies, readSet/writeSet, verification commands, subagent dispatch
+
+// Ready-queue dispatch (NOT serial phase)
+while task not accepted:
+    update readyQueue from dependency graph
+
+    // Read-only and chore — always parallel when ready
+    dispatch codebase-explorer(s) for scoped source reading
+    dispatch docs-researcher / researcher as needed
+    dispatch planner for decomposition (unless already done)
+    dispatch task-scribe alongside any work
+
+    // Write gate
+    for each independent writeSet:
+        dispatch implementer (one file_claim each)
+        when wave complete: dispatch verifier
+
+    // Review gate — wave-level, not end-of-task
+    when verifier evidence exists for a wave:
+        dispatch reviewer(s) on that wave
+
+    // Fix gate — on-demand
+    if review finding or failed AC:
+        dispatch debugger or implementer (smallest fix)
+        re-run verifier
+
+    // Reflect gate — WF-Full only or risk-triggered
+    if WF-Full or unresolved contradiction:
+        dispatch reflector
+
+    // Closeout
+    task-scribe records final state
+    if durable lesson: context-master -> memory-master
+
+    stop on: accepted | blocked | user decision required
 ```
 
-## Intake
+## WF Tiers
 
-1. Read `CLAUDE.md`, `Harness/MEMORY.md`, `Harness/README.md`,
-   `Harness/PROGRESS.md`, and the active task capsule if present.
-2. State the goal, non-goals, confidence level, known risks, acceptance truth
-   files, and write boundaries.
-3. Ask up to three blocking questions only when the next action cannot reach
-   95% confidence.
-4. Update `Harness/tasks/<task-id>/PROGRESS.md#Heartbeat` before dispatching
-   roles or running long commands.
-5. Load `Harness/subagents.md` before coordinating multiple roles.
+### WF-Light
+1-2 files, well-understood, low risk.
+- planner + test-writer + implementer + verifier
+- task-scribe maintains state
+- codebase-explorer optional
+- **Acceptance**: verification passes = closeout
+- Cross-review and reflector NOT mandatory
+
+### WF-Standard
+Multi-file or behavior change.
+- WF-Light baseline + research/docs + at least one independent review lens
+- Parallel: codebase-explorer(s), docs-researcher/researcher, planner, task-scribe
+- **Acceptance**: verifier evidence + one review PASS = closeout
+- Reflector: only when risk, contradiction, or high impact triggers
+
+### WF-Full
+High-risk, cross-layer, security/data-loss, browser/API acceptance, ambiguous architecture.
+- Full chain per [WF-KERNEL.md](WF-KERNEL.md) Role/Model Matrix
+- **Acceptance**: cross-review PASS + reflector PASS
+
+## State Ownership
+
+Per [WF-KERNEL.md](WF-KERNEL.md):
+- **Controller** (main agent): decisions, decomposition, synthesis, final verification
+- **task-scribe** (haiku): writes task state (PLAN, PROGRESS, ARTIFACTS, NOTES). Controller supplies structured updates; task-scribe formats and writes.
+- **Production source agents**: write ONLY their assigned writeSet. Never write task state.
 
 ## Exploration
 
-Use read-only role passes first. For automatic WF triggers, default to 3-5
-active agents or bounded passes unless the task is clearly small enough for the
-solo exception.
-
-| Role | Purpose | Writes |
-| --- | --- | --- |
-| `planner` | map local project facts, commands, app entry points, existing docs, and initial decomposition | none |
-| `researcher` | product, ecosystem, dependency, and external context | none unless returning a docs patch |
-| `docs-researcher` | official docs, SDK/API versions, browser/tool limits | none unless returning a docs patch |
-| `architect` | boundaries, ports, data flow, state impact, migration risks | none unless returning a docs patch |
-
-Use local files first. Use web search or official docs only when the decision
-needs current or external evidence. Record tool choice and limitations in
-`Harness/research/research-results.md` or the task plan.
-
-## Subagent Orchestration
-
-Use `Harness/subagents.md` as the orchestration methodology and
-`Harness/dispatch.md` as the dispatch table protocol.
-
-- The main agent is the controller and owns synthesis, integration, and final
-  verification.
-- Subagents are readers and reporters. Only the main agent writes task
-  `PROGRESS.md` and `PLAN.md`.
-- Parallelize read-only exploration; serialize writers unless write sets are
-  disjoint and isolated.
-- Every role gets a dispatch pack with role, goal, mode, read set, write set,
-  forbidden scope, injected docs, evidence, stop condition, and return format.
-- After implementation, run spec review before code-quality or architecture
-  review.
-- If subagents are unavailable, emulate the same roles as bounded passes and
-  record the fallback.
-
-## Second Plan
-
-After exploration, synthesize facts found, assumptions, risks,
-accepted/rejected options, Mini PRD, AC IDs, UI/API contracts, tasks,
-read/write sets, verification path, and rollback or recovery plan.
-
-Write the result to `Harness/tasks/<task-id>/PLAN.md` before implementation.
-Update `Harness/tasks/<task-id>/PROGRESS.md#Heartbeat`.
-
-The second plan must pass:
-
-- PRD-GATE: goal, scope, non-scope, user flow, and verification commands exist.
-- AC-GATE: each behavior has an AC ID and Given/When/Then.
-- CONTRACT-GATE: UI/API/state contracts exist when the feature touches UI/API/state.
-- TEST-GATE: verification commands and test levels map to AC IDs.
-- IMPLEMENT-GATE: implementer forbidden set includes PRD, AC, UI/API contracts, test plan, and validation report unless a Change Request is approved.
-
-## Build And Review
-
-1. `test-writer` defines failing tests or written manual checks from AC IDs and contracts first.
-2. `implementer` changes only the declared write set and may not edit truth files without Change Request.
-3. `verifier` or independent validator runs AC-mapped checks against running behavior and records an evidence matrix before cross-review.
-4. Cross-review is mandatory: at least two independent review lenses must pass before acceptance.
-   - Spec/AC review checks request, scope, contracts, and non-goals.
-   - Code/architecture/test review checks implementation risk, maintainability, security, and verification adequacy.
-5. `reflector` reads verifier evidence and reviewer findings, resolves contradictions with the controller, and returns PASS before final acceptance.
-6. For cross-layer or risky work, run separate reviewers for spec/AC compliance, architecture, security, and test adequacy.
-
-## Browser And API Evidence
-
-For browser-visible changes, typecheck/build/unit tests are not enough. Use
-Chrome DevTools, CDP, Playwright, or a documented real-browser run:
-
-- start the app and record URL/port
-- click through the critical flow
-- capture frontend console/runtime errors
-- capture failed network requests
-- collect backend logs when the flow crosses an API
-- record screenshot, trace, video, or manual evidence path
-- produce an AC-by-AC acceptance result matrix
-- for frontend-backend paths, check UI selectors and API behavior against `HARNESS_BRIDGE.md`
-
-For API changes, run the project API/integration test path or a documented real
-request against a local service and record request, response, logs, and failure
-behavior.
-
-## Recovery Loop
-
-If verification fails:
-
-1. Update `Harness/tasks/<task-id>/PROGRESS.md#Heartbeat` with failure count
-   and blocker.
-2. Dispatch `debugger` with the failed AC ID, failing command, error output,
-   trace/screenshot/network evidence, and smallest relevant files.
-3. Classify the failure layer using [DEBUG_PROTOCOL.md](DEBUG_PROTOCOL.md), then fix the smallest reproduced failure.
-4. Run verifier again and record fresh AC-mapped evidence.
-5. Run cross-review again.
-6. Run reflector again.
-7. Repeat until verified or blocked by missing user input/external state.
-
-Before asking the user after repeated failures, run the context-master then
-memory-master learning cycle or use `wf-learn`.
-
-## Heartbeat Protocol
-
-Heartbeat is a lightweight recovery protocol, not a background daemon.
-Keep heartbeat entries to one or two lines: phase, blocker/failure, next action,
-and evidence pointer. Do not paste command logs or subagent transcripts.
-
-Update `Harness/tasks/<task-id>/PROGRESS.md#Heartbeat`:
-
-- before a long command
-- after a long command
-- before spawning subagents or bounded passes
-- after integrating returns
-- after each failed verification
-- before stopping for user input
-
-When context approaches about 85% of the window, run context-master or the
-equivalent bounded pass to append a compression suggestion to the task heartbeat.
+Controller delegates source reading to subagents. Controller does NOT read source files directly before dispatch.
+
+First wave — dispatch in parallel:
+- codebase-explorer(s): scoped source discovery
+- planner: decomposition, dependencies, writeSet
+- researcher / docs-researcher: external context as needed
+- task-scribe: compact heartbeat and dispatch ledger
+
+Second wave — after synthesis:
+- architect (if cross-layer or architecture risk)
+- test-writer: failing tests from AC IDs
+
+## Browser and API Evidence
+
+See [HARNESS_BRIDGE.md](HARNESS_BRIDGE.md) and [WF-KERNEL.md](WF-KERNEL.md) Task Type Routing for UI/browser and API/backend task types.
+
+Agents live under `.claude/agents/` and `.opencode/agents/`. Task state lives under `Harness/tasks/<task-id>/`.
 
 ## Closeout
 
-Close only when:
-
-- PRD-GATE, AC-GATE, CONTRACT-GATE, TEST-GATE, VALIDATION-GATE, REVIEW-GATE, and REFLECT-GATE are satisfied
-- acceptance criteria are satisfied and reported by AC ID
-- cross-review has passed with no unresolved critical/high findings
-- reflector verdict is PASS
-- test/API/browser evidence is recorded
-- affected Harness docs are synced
-- context-master has analyzed the session and extracted durable knowledge
-- memory-master has consolidated extracted knowledge into `Harness/memory/*`
-- current task PROGRESS.md and PLAN.md are archived under `Harness/tasks/<task-id>/`
-  with Phase set to Verified
-- `Harness/PROGRESS.md` task index is updated and Active Task is cleared or set
-  to the next task
+Closeout is tier-aware. WF-Light: verification + task state update = done. WF-Full: full gate chain per [WF-KERNEL.md](WF-KERNEL.md).

package/templates/common/Harness/agent-workflow.md

@@ -118,8 +118,8 @@ Use [subagents.md](subagents.md) and [dispatch.md](dispatch.md) for multi-agent
 | Mode | Agent Count Rule | Source |
 |------|-----------------|--------|
 | Default (non-WF) | up to 3 active agents by default | This file |
-| `/wf` | complete role chain mandatory before closeout | [WF.md](WF.md) |
-| `/wf max` | complete WF role chain plus maximum useful fan-out | [WF-MAX.md](WF-MAX.md) |
+| `/wf` | WF-KERNEL tier selection (Light/Standard/Full) by risk and scope; full role chain only at WF-Full | [WF.md](WF.md) |
+| `/wf-max` | WF kernel plus maximum useful fan-out (WF-Max-Useful default; WF-Max-Strict explicit only) | [WF-MAX.md](WF-MAX.md) |
 
 Prefer parallel read-only work first, then serial writes.
 

package/templates/common/Harness/context-loading.md

@@ -4,7 +4,7 @@ Use when context is growing, subagents are needed, or an agent is unsure which h
 
 ## Routing Authority
 
-`Harness/README.md` is the primary router. This file is a secondary context-splitting protocol for subagents and long tasks.
+`CLAUDE.md` is the session entry router. `Harness/README.md` is the primary Harness documentation router. This file is a secondary context-splitting protocol for subagents and long tasks.
 
 If this file and `Harness/README.md` disagree, follow `Harness/README.md`, record the assumption in `Harness/tasks/<task-id>/PROGRESS.md`, and update this file later.
 
@@ -33,8 +33,8 @@ Load other docs only by trigger.
 | research, competitors, stack choice | `Harness/research/README.md`, `Harness/research/research-results.md` |
 | task split, owner, write set | `Harness/tasks/<task-id>/PROGRESS.md`, `Harness/tasks/<task-id>/PLAN.md`, `Harness/agent-workflow.md` |
 | parallel agents, dispatch, worktree decision | `Harness/subagents.md`, `Harness/dispatch.md`, `Harness/tasks/<task-id>/PLAN.md` |
-| `/wf` mode, long task, multi-file, multi-agent | `Harness/WF.md`, `Harness/subagents.md`, `Harness/dispatch.md`, `Harness/tasks/<task-id>/PLAN.md` |
-| `/wf max`, 5+ disjoint files, maximum parallelism | `Harness/WF-MAX.md`, `Harness/subagents.md`, `Harness/dispatch.md`, `Harness/tasks/<task-id>/PLAN.md` |
+| `/wf` mode (explicit only) | [Harness/WF.md](WF.md), [Harness/subagents.md](subagents.md), [Harness/dispatch.md](dispatch.md), [Harness/tasks/<task-id>/PLAN.md](tasks/<task-id>/PLAN.md) |
+| `/wf-max` (explicit only) | [Harness/WF-MAX.md](WF-MAX.md), [Harness/subagents.md](subagents.md), [Harness/dispatch.md](dispatch.md), [Harness/tasks/<task-id>/PLAN.md](tasks/<task-id>/PLAN.md) |
 | memory, scenario memory, repeated tool failure, repeated user correction, reusable lesson | `Harness/MEMORY.md`, `Harness/MEMORY_PROTOCOL.md`, the relevant `Harness/memory/*.md` file |
 | subagent spawn | `Harness/subagents.md`, `Harness/AGENT_ISOLATION.md`, this file plus the role pack below |
 

package/templates/common/Harness/dispatch.md

@@ -11,13 +11,14 @@ Use when work needs parallel reading, independent review, cross-layer analysis,
 - Main agent owns the final decision, integration, and verification.
 - project files are the only durable communication channel; chat/subagent transcript state is non-authoritative.
 - Important assumptions, decisions, blockers, evidence, and handoffs must be written to `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md`, the current feature doc, `Harness/MEMORY.md`, or `Harness/memory/*` as appropriate.
+- Resumable state is governed by [WF-STATE.md](WF-STATE.md). On session start, the controller reads STATE.json before building a fresh dispatch table.
 - PRD-derived Acceptance Criteria are the source of truth. Dispatch packets must carry the relevant AC IDs and contracts.
-- Agent count: default (non-WF) <=3 active agents; `/wf` requires the complete role chain by default; `/wf max` inherits that chain and removes the Harness default cap through the span formula. Real concurrency is still bounded by runtime thread budget, config, billing, and local resources. Use current runtime subagents first, close completed agents, then cross-CLI overflow. Generated Codex config defaults to `agents.max_threads = 12` and `agents.max_depth = 1`; ask the user before raising `agents.max_threads` above that default. See [WF.md](WF.md) and [WF-MAX.md](WF-MAX.md).
+- Agent count: default (non-WF) <=3 active agents; `/wf` selects a tier dynamically per [WF-KERNEL.md](WF-KERNEL.md) (Light/Standard/Full); `/wf-max` inherits the selected tier and adds maximum safe fan-out (WF-Max-Useful default; WF-Max-Strict explicit only), removing the Harness default cap through the span formula. Real concurrency is still bounded by runtime thread budget, config, billing, and local resources. Use current runtime subagents first, close completed agents, then cross-CLI overflow. Generated Codex config defaults to `agents.max_threads = 12` and `agents.max_depth = 1`; ask the user before raising `agents.max_threads` above that default. See [WF.md](WF.md) and [WF-MAX.md](WF-MAX.md).
 - Read-only agents may run in parallel.
 - Writing agents run serially unless write sets are disjoint.
 - Use a worktree when two agents may touch overlapping files or long-running branches.
 - Only summaries enter main context. Load named files directly when details are needed.
-- Subagents read task files, return findings and PLAN patch suggestions. Only the main agent commits changes to PROGRESS.md and PLAN.md.
+- Only the controller or task-scribe writes task state (PROGRESS.md, PLAN.md). Production source agents (implementer, debugger, test-writer) never write task state unless explicitly dispatched as task-scribe.
 
 ## Scope
 
@@ -25,24 +26,26 @@ Use when work needs parallel reading, independent review, cross-layer analysis,
 
 ## Agent Roster
 
-| Agent | Mode | Purpose |
-| --- | --- | --- |
-| `planner` | Read | split goal into tasks, dependencies, write sets |
-| `researcher` | Read | product, market, ecosystem, dependency research |
-| `docs-researcher` | Read | official docs, API, SDK, version, limits |
-| `architect` | Read | layer boundaries, ports, data flow, state impact |
-| `test-writer` | Write | failing test or manual verification plan |
-| `implementer` | Write | minimal change inside declared write set |
-| `debugger` | Write | smallest fix for a reproduced failure |
-| `reviewer` | Read | diff review, risks, missing tests |
-| `verifier` | Read | run checks and record evidence |
-| `reflector` | Read | synthesize review/evidence and decide acceptance readiness |
-| `memory-master` | Write | write/consolidate memory entries |
-| `context-master` | Read | analyze context, recommend compression |
-| `explore-manager` | Read | WF-MAX W0: spawn researchers, synthesize |
-| `architect-manager` | Read | WF-MAX W1: spawn architects, synthesize |
-| `implement-manager` | Write | WF-MAX W2: spawn implementers |
-| `review-manager` | Read | WF-MAX W2R: spawn reviewers, deduplicate |
+| Agent | Mode | Model Tier | Purpose |
+| --- | --- | --- | --- |
+| `task-scribe` | Write | small-fast | Task state, heartbeat, dispatch ledger, evidence pointers |
+| `codebase-explorer` | Read | small-fast | Scoped read-only source exploration, file discovery |
+| `planner` | Read | standard | Split goal into tasks, dependencies, write sets |
+| `researcher` | Read | standard | Product, market, ecosystem, dependency research |
+| `docs-researcher` | Read | standard | Official docs, API, SDK, version, limits |
+| `architect` | Read | standard | Layer boundaries, ports, data flow, state impact |
+| `test-writer` | Write | standard | Failing test or manual verification plan |
+| `implementer` | Write | standard | Minimal change inside declared write set |
+| `debugger` | Write | standard | Smallest fix for a reproduced failure |
+| `reviewer` | Read | standard | Diff review, risks, missing tests |
+| `verifier` | Read | standard or small-fast | Run checks and record evidence |
+| `reflector` | Read | standard | Synthesize review/evidence and decide acceptance readiness |
+| `memory-master` | Write | standard | Write/consolidate memory entries |
+| `context-master` | Read | small-fast | Analyze context, recommend compression |
+| `explore-manager` | Read | standard | WF-MAX W0: spawn researchers, synthesize |
+| `architect-manager` | Read | standard | WF-MAX W1: spawn architects, synthesize |
+| `implement-manager` | Write | standard | WF-MAX W2: spawn implementers |
+| `review-manager` | Read | standard | WF-MAX W2R: spawn reviewers, deduplicate |
 
 ## Dispatch Rules
 
@@ -51,7 +54,7 @@ Use when work needs parallel reading, independent review, cross-layer analysis,
 - If two write sets overlap, do not run those agents in parallel.
 - If an agent returns uncertainty, mark the row `Blocked` or add a follow-up row.
 - If docs, tests, and code disagree, stop implementation and record the conflict in `Harness/tasks/<task-id>/PROGRESS.md`.
-- In /wf max, file claims must respect WF-MAX.md leaf condition: no split below 50 avgLines, no split when files <= span*2.
+- In /wf-max, file claims must respect WF-MAX.md leaf condition: no split below 50 avgLines, no split when files <= span*2.
 
 ## Dispatch Input (Controller -> Subagent)
 
@@ -59,18 +62,23 @@ The controller MUST include these fields in the subagent's dispatch packet.
 Without them, the subagent has no way to know which rules or contracts to load.
 
 ```text
-Role:               <installed agent name or bounded role, e.g. planner, implementer-fe, reviewer, memory-master>
-Task:               <one-sentence goal>
-ECC:                <which ECC rules to load, e.g. web/design-quality.md, python/fastapi.md. See context-loading.md#ecc-rules-per-role>
-Skills:             <which skills to activate, e.g. react-review, tdd-guide>
-PRD:                <path or task PLAN section containing Mini PRD>
-Acceptance IDs:     <AC-001, AC-002, or "none" for non-behavioral work>
-UI contract:        <path to UI_CONTRACT.md or task PLAN section, if UI task>
-API contract:       <path to api/openapi.yaml, if frontend<->backend task. Omit if N/A>
-Read set:           <files and directories the subagent may read>
-Write set:          <files the subagent may modify. "none" = read-only>
-Forbidden:          <commands, paths, or patterns the subagent must not touch>
-Verification:       <commands to run after implementation, e.g. npm test>
+Role:               <installed agent name or bounded role, e.g. task-scribe, planner, implementer>
+Objective:           <one-sentence goal>
+TaskType:            ui-browser | api-backend | architecture-migration | docs-readme | dependency-sdk | bug-fix | refactor | chore
+ModelTier:           small-fast | standard | high-reasoning
+AgentName:           <the agent file name, e.g. task-scribe, codebase-explorer, implementer>
+Skills:              <which skills to activate, e.g. tdd, browser-e2e>
+ECC:                 <which ECC rules to load, e.g. web/design-quality.md, python/fastapi.md>
+PRD:                 <path or task PLAN section containing Mini PRD>
+Acceptance IDs:      <AC-001, AC-002, or "none" for non-behavioral work>
+UI contract:         <path to UI_CONTRACT.md or task PLAN section, if UI task>
+API contract:        <path to api/openapi.yaml, if frontend<->backend task. Omit if N/A>
+Read set:            <files and directories the subagent may read>
+Write set:           <files the subagent may modify. "none" = read-only>
+Forbidden:           <commands, paths, or patterns the subagent must not touch>
+Verification:        <commands to run after implementation, e.g. npm test>
+MaxReturnTokens:     <token budget for return>
+ReturnSchema:        <expected fields in return>
 ```
 
 ## Handoff Format (Subagent -> Controller)
@@ -93,8 +101,8 @@ Risks:
 Next:
 PLAN patch:
 Validation matrix:  <AC-by-AC pass/fail/block evidence, for validators>
-Concurrency group:  <wave number - 0=exploration, 1,2,3,...=implementation waves. Optional; only used in /wf max.>
-File claim:         <list of exact file paths this agent exclusively owns. Optional; only used in /wf max.>
+Concurrency group:  <wave number - 0=exploration, 1,2,3,...=implementation waves. Optional; only used in /wf-max.>
+File claim:         <list of exact file paths this agent exclusively owns. Optional; only used in /wf-max.>
 Granularity floor:  <50 avgLines -> do NOT spawn. Apply leaf condition from WF-MAX.md.>
 ```