create-harness-vibe-coding 0.8.6 → 0.8.7

package/templates/common/Harness/WF.md

@@ -34,41 +34,51 @@ 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 uses at least three role passes before the second plan.
+  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.
 
-## Multi-Subagent Requirement
-
-WF mode requires multi-subagent orchestration by default.
-
-Normative rule: Explicit `/wf`, `$wf`, `wf mode`, `workflow mode`, or `wk mode` MUST use at least 3 distinct role passes before second planning.
-
-- Explicit `/wf`, `$wf`, `wf mode`, `workflow mode`, or `wk mode` MUST use at
-  least 3 distinct role passes before second planning. Use real subagents when
-  the runtime supports them; otherwise emulate those roles as bounded passes and
-  record the fallback.
+## 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 -> always multi-role, no exceptions.
-  - 3+ files changed -> multi-role at minimum: planner, implementer, reviewer.
-  - Cross-layer change -> architect plus implementers plus reviewer.
-  - Uncertain scope or approach -> planner plus researcher plus architect.
+  - 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 initial fan-out: `planner`, `researcher` or `docs-researcher`, and
-  `architect`. Add `test-writer`, `reviewer`, `debugger`, or `verifier` when
-  the phase needs them.
+- 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.
-- [ ] At least 3 distinct role types, each with one specific question.
+- [ ] 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
@@ -93,8 +103,9 @@ Intake
 -> test-writer
 -> implementer
 -> independent validator
--> reviewers
--> if failed: debugger -> review -> e2e/API validation -> loop
+-> cross-review: spec/AC reviewer + code/architecture/test reviewer
+-> reflector
+-> if failed: debugger -> verifier -> cross-review -> reflector -> loop
 -> memory closeout with evidence
 ```
 
@@ -166,9 +177,12 @@ The second plan must pass:
 
 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 acceptance result matrix.
-4. At least one `reviewer` checks diff, architecture, risks, missing tests, and AC traceability.
-5. For cross-layer or risky work, run separate reviewers for spec/AC compliance, architecture, and test adequacy.
+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
 
@@ -197,9 +211,10 @@ If verification fails:
 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 reviewer again.
-5. Run verifier again.
-6. Repeat until verified or blocked by missing user input/external state.
+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`.
@@ -207,6 +222,8 @@ 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`:
 
@@ -224,9 +241,10 @@ equivalent bounded pass to append a compression suggestion to the task heartbeat
 
 Close only when:
 
-- PRD-GATE, AC-GATE, CONTRACT-GATE, TEST-GATE, VALIDATION-GATE, and REVIEW-GATE are satisfied
+- 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
-- reviewer has no unresolved critical/high findings
+- 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

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

@@ -1,5 +1,5 @@
-# Agent Workflow
-
+# Agent Workflow
+
 Use when implementing, reviewing, debugging, or coordinating subagents.
 
 This workflow is acceptance-driven. PRD-derived Acceptance Criteria are the
@@ -8,33 +8,47 @@ must trace to AC IDs. Load [ACCEPTANCE_PROTOCOL.md](ACCEPTANCE_PROTOCOL.md) for
 gate rules, [TDD-GUIDE.md](TDD-GUIDE.md) for AC-linked RED tests,
 [HARNESS_BRIDGE.md](HARNESS_BRIDGE.md) for UI/API/browser evidence, and
 [AGENT_ISOLATION.md](AGENT_ISOLATION.md) before role splits.
-
-## ReAct Loop
-
-```text
-Observe -> Load minimal context -> Plan -> Act -> Verify -> Update Harness/tasks/<task-id>/PROGRESS.md
-```
-
-If context grows, load [context-loading.md](context-loading.md) and split the work. If more than one agent is useful, load [subagents.md](subagents.md) and [dispatch.md](dispatch.md).
-
-## Feature Packet
-
-Every PRD scope item must be covered by AC IDs and a task plan at `Harness/tasks/<task-id>/PLAN.md`
-created from `Harness/tasks/_template/PLAN.md` (the primary work tracking system).
-**Cohesion rule**: if multiple PRD scope items share the same write set, the same
-test/verification path, and the same review boundary, group them into a single
-feature doc. The PRD owns scope decomposition; the feature doc owns the
-implementation unit. The number of feature docs should reflect the number of
-distinguishable implementation units, not the number of PRD checkboxes.
-
-**Minimum bar**: a task plan is required when the implementation touches more than one
-file or changes user-visible behavior. Record the plan in `Harness/tasks/<task-id>/PLAN.md`.
-For single-file fixes with no behavior change, a brief note in `PROGRESS.md` is enough.
-
-**New vs iterate**: if a PRD scope item overlaps with an existing task, reopen the existing
-task capsule and append to its `PROGRESS.md`. Only create a new task capsule when the
-scope is substantially different. When unsure, ask.
-
+
+## ReAct Loop
+
+```text
+Observe -> Load minimal context -> Plan -> Act -> Verify -> Update Harness/tasks/<task-id>/PROGRESS.md
+```
+
+If context grows, load [context-loading.md](context-loading.md) and split the
+work. If more than one agent is useful, load [subagents.md](subagents.md) and
+[dispatch.md](dispatch.md).
+
+## Feature Packet
+
+Every PRD scope item must be covered by AC IDs and a task plan at
+`Harness/tasks/<task-id>/PLAN.md` created from
+`Harness/tasks/_template/PLAN.md` (the primary work tracking system).
+
+**Cohesion rule**: if multiple PRD scope items share the same write set, the
+same test/verification path, and the same review boundary, group them into a
+single feature doc. The PRD owns scope decomposition; the feature doc owns the
+implementation unit.
+
+**Minimum bar**: a task plan is required when the implementation touches more
+than one file or changes user-visible behavior. Record the plan in
+`Harness/tasks/<task-id>/PLAN.md`. For single-file fixes with no behavior
+change, a brief note in `PROGRESS.md` is enough.
+
+Use the compact task template by default. `PLAN.md` owns goal, decisions,
+scope/write set, agents, verification intent, and risks. `PROGRESS.md` owns
+status/next/blocker, completed tasks, changed files, verification evidence, and
+notes. Expand sections only when they change an implementation or review
+decision.
+
+**AC record size**: default to 1-3 concise ACs. Use full UI/API contracts and an
+AC-by-AC validation matrix only for browser-visible, API/integration,
+security/data-loss, cross-module, or other high-risk behavior.
+
+**New vs iterate**: if a PRD scope item overlaps with an existing task, reopen
+the existing task capsule and append to its `PROGRESS.md`. Only create a new
+task capsule when the scope is substantially different. When unsure, ask.
+
 ## Acceptance-Driven Build Loop
 
 ```text
@@ -45,7 +59,9 @@ Mini PRD
 -> failing test or manual check
 -> minimal implementation
 -> independent validation
--> review
+-> cross-review (spec/AC + code/architecture/test)
+-> reflector PASS
+-> final acceptance
 -> debug if needed
 -> docs sync
 -> memory
@@ -61,27 +77,31 @@ Rules:
 - Frontend-backend behavior must include network/API assertions against the contract.
 - Implementer cannot modify PRD, acceptance criteria, UI/API contracts, test plan, or validation report unless a Change Request is recorded.
 - Validator must be independent from implementer and must produce an AC-by-AC result matrix.
-
-## Subagent Use
-
-Use subagents when a task needs broad reading, parallel work, cross-layer changes, independent review, or isolated debugging. Follow [subagents.md](subagents.md) for controller-led orchestration and [dispatch.md](dispatch.md) for the dispatch table.
-
-Before spawn, define:
-
-- role
-- task
-- mode
-- read boundary
-- write boundary
-- dependency
-- injected docs from [context-loading.md](context-loading.md)
-- return format
-
-Rules:
-
-- Explorer Pass, Reviewer, and Verifier are read-only.
-- Researcher and Docs Researcher are read-only unless explicitly asked to return a docs patch.
-- Planner and Architect are read-only unless explicitly asked to return a docs patch.
+- Cross-review and reflector PASS are required before final acceptance.
+
+## Subagent Use
+
+Use subagents when a task needs broad reading, parallel work, cross-layer
+changes, independent review, or isolated debugging. Follow
+[subagents.md](subagents.md) for controller-led orchestration and
+[dispatch.md](dispatch.md) for the dispatch table.
+
+Before spawn, define:
+
+- role
+- task
+- mode
+- read boundary
+- write boundary
+- dependency
+- injected docs from [context-loading.md](context-loading.md)
+- return format
+
+Rules:
+
+- Explorer Pass, Reviewer, Verifier, and Reflector are read-only.
+- Researcher and Docs Researcher are read-only unless explicitly asked to return a docs patch.
+- Planner and Architect are read-only unless explicitly asked to return a docs patch.
 - Test Writer writes tests before Implementer writes production code.
 - Implementer only writes inside its declared write set.
 - Implementer forbidden set includes PRD, acceptance criteria, UI/API contracts, test plan, and validation report by default.
@@ -89,31 +109,43 @@ Rules:
 - Debugger fixes the smallest failing path, not adjacent design.
 - Debugger receives failed AC IDs, evidence, and failing layer hypothesis before editing.
 - Main agent integrates summaries, resolves conflicts, and runs final verification.
-
-## Parallel Dispatch
-
-Use [subagents.md](subagents.md) and [dispatch.md](dispatch.md) for multi-agent work. Default to at most three active agents (WF mode overrides this; see [WF.md](WF.md)). In `/wf max`, the CEO/Manager/Worker hierarchy in [WF-MAX.md](WF-MAX.md) overrides this limit entirely with wave-based parallel dispatch. Prefer parallel read-only work first, then serial writes.
-
-Every dispatched agent returns the handoff format defined in [dispatch.md](dispatch.md).
-
-## Conflict Rule
-
-If PRD, acceptance criteria, UI/API contracts, task PLAN.md, architecture, ports, tests, or code disagree:
-
-1. stop implementation
-2. record the conflict in `Harness/tasks/<task-id>/PROGRESS.md` or the feature doc
-3. choose the smallest reversible decision
-4. ask the maintainer when user-visible behavior or security is affected
-
-## Completion Gate
-
-Close only when:
-
+
+## Parallel Dispatch
+
+Use [subagents.md](subagents.md) and [dispatch.md](dispatch.md) for multi-agent work.
+
+**Agent count by mode:**
+| 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) |
+
+Prefer parallel read-only work first, then serial writes.
+
+Every dispatched agent returns the handoff format defined in [dispatch.md](dispatch.md).
+
+## Conflict Rule
+
+If PRD, acceptance criteria, UI/API contracts, task PLAN.md, architecture,
+ports, tests, or code disagree:
+
+1. stop implementation
+2. record the conflict in `Harness/tasks/<task-id>/PROGRESS.md` or the feature doc
+3. choose the smallest reversible decision
+4. ask the maintainer when user-visible behavior or security is affected
+
+## Completion Gate
+
+Close only when:
+
 - acceptance criteria are satisfied by AC ID
 - validation result matrix exists for user-visible behavior
 - verification evidence is recorded
-- architecture docs are synced if affected
-- no unresolved critical/high review findings remain
-- any optimistic UI mutation has a declared and verified rollback path
-- any file declared as DONE in PLAN.md or PROGRESS.md exists on disk (chat output is not durable evidence)
-- `Harness/tasks/<task-id>/PROGRESS.md` states the final status or next iteration
+- cross-review has passed with no unresolved critical/high findings
+- reflector verdict is PASS
+- architecture docs are synced if affected
+- no unresolved critical/high review findings remain
+- any optimistic UI mutation has a declared and verified rollback path
+- any file declared as DONE in PLAN.md or PROGRESS.md exists on disk (chat output is not durable evidence)
+- `Harness/tasks/<task-id>/PROGRESS.md` states the final status or next iteration

package/templates/common/Harness/dispatch.md

@@ -1,105 +1,106 @@
-# Dispatch Protocol
-
-Purpose: coordinate a small set of subagents without building a scheduler.
-
-Use [subagents.md](subagents.md) for orchestration strategy. Use this file for the dispatch table, handoff format, and status protocol.
-
-Use when work needs parallel reading, independent review, cross-layer analysis, or more than one bounded implementation pass.
-
-## Principles
-
-- Main agent owns the final decision, integration, and verification.
-- project files are the only durable communication channel; chat/subagent transcript state is non-authoritative.
+# Dispatch Protocol
+
+Purpose: coordinate a small set of subagents without building a scheduler.
+
+Use [subagents.md](subagents.md) for orchestration strategy. Use this file for the dispatch table, handoff format, and status protocol.
+
+Use when work needs parallel reading, independent review, cross-layer analysis, or more than one bounded implementation pass.
+
+## Principles
+
+- 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.
 - 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 ≥3 distinct subagents from `.claude/agents/` before second plan; `/wf max` removes the cap entirely (governed by span formula in WF-MAX.md). See [WF.md](WF.md) and [WF-MAX.md](WF-MAX.md) for the authoritative rules.
-- 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.
-
-## Scope
-
-`agent-workflow.md` owns the build/review loop. `subagents.md` owns orchestration strategy and agent roster. This file owns the dispatch input and subagent handoff formats.
-
-## 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 |
-| `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 |
-
-## Dispatch Rules
-
-- Every dispatch row needs task, agent, mode, read set, write set, dependency, output, and status.
-- A write set of `none` means read-only.
-- 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.
-
-## Dispatch Input (Controller → Subagent)
-
-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>
+- 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).
+- 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.
+
+## Scope
+
+`agent-workflow.md` owns the build/review loop. `subagents.md` owns orchestration strategy and agent roster. This file owns the dispatch input and subagent handoff formats.
+
+## 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 |
+
+## Dispatch Rules
+
+- Every dispatch row needs task, agent, mode, read set, write set, dependency, output, and status.
+- A write set of `none` means read-only.
+- 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.
+
+## Dispatch Input (Controller -> Subagent)
+
+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>
-```
-
-## Handoff Format (Subagent → Controller)
-
-Subagents return summaries in this shape:
-
-```text
-Agent:
-Task:
-Mode:
-ECC loaded:         <which ECC rule files were actually loaded. Should match dispatch ECC field.>
-Skills active:      <which skills were active. Should match dispatch Skills field.>
-API contract:       <path to contract file used, if applicable>
+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>
+```
+
+## Handoff Format (Subagent -> Controller)
+
+Subagents return summaries in this shape:
+
+```text
+Agent:
+Task:
+Mode:
+ECC loaded:         <which ECC rule files were actually loaded. Should match dispatch ECC field.>
+Skills active:      <which skills were active. Should match dispatch Skills field.>
+API contract:       <path to api/openapi.yaml, if frontend<->backend task. Omit if N/A>
 Acceptance IDs:     <AC IDs handled or validated>
 Files read:
-Files changed:
-Findings:
-Evidence:
-Risks:
-Next:
+Files changed:
+Findings:
+Evidence:
+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.>
-Granularity floor:  <50 avgLines → do NOT spawn. Apply leaf condition from WF-MAX.md.>
-```
-
-Use `Files changed: none` for read-only agents. Use `PLAN patch: none` when no state update is needed.
-If a handoff matters after context loss, write it to `Harness/tasks/<task-id>/PROGRESS.md`, `Harness/tasks/<task-id>/PLAN.md`, the current feature doc, or `Harness/memory/*`; do not rely on chat transcript state.
-
-## Statuses
-
-Allowed dispatch statuses: Pending / In Progress / Returned / Integrated / Blocked / Verified.
+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.>
+```
+
+Use `Files changed: none` for read-only agents. Use `PLAN patch: none` when no state update is needed.
+If a handoff matters after context loss, write it to `Harness/tasks/<task-id>/PROGRESS.md`, `Harness/tasks/<task-id>/PLAN.md`, the current feature doc, or `Harness/memory/*`; do not rely on chat transcript state.
+
+## Statuses
+
+Allowed dispatch statuses: Pending / In Progress / Returned / Integrated / Blocked / Verified.

package/templates/common/Harness/extension.md

@@ -49,7 +49,7 @@ Every added skill must state:
 - whether to update `Harness/PROGRESS.md` and task files
 - whether to use [subagents.md](subagents.md) and [dispatch.md](dispatch.md)
 
-Skills should extend the harness. They should not replace `Harness/README.md`, `Harness/PROGRESS.md`, `subagents.md`, `context-loading.md`, `dispatch.md`, or `agent-workflow.md`.
+Skills should extend the harness. They should not replace `Harness/README.md`, `Harness/PROGRESS.md`, `subagents.md`, `context-loading.md`, `dispatch.md`, or `agent-workflow.md`.
 
 ## Rules