create-harness-vibe-coding 0.8.2 → 0.8.4

package/templates/common/Harness/WF-AUTO.md

@@ -15,9 +15,15 @@ This fills the gap between:
 - `/wf-max` — task-bounded, stops on completion, just faster
 - `/wf-auto` — **unbounded, self-directed, perpetual improvement**
 
-## Organization Model
-
-```
+## Organization Model
+
+WF-AUTO uses the same acceptance-driven mother flow per cycle. Each selected
+optimization becomes a Mini PRD with AC IDs, a test/validation plan, bounded
+implementation, independent validation, review, debug if needed, and memory.
+Autonomy changes who chooses the next improvement; it does not make
+implementation or tests the source of truth.
+
+```
 CEO(1) ──┬── Angle-Agent₁ (correctness)
          ├── Angle-Agent₂ (performance)
          ├── Angle-Agent₃ (security)
@@ -235,9 +241,17 @@ reversibility: easy-to-revert=1.2, hard-to-revert=0.5
 
 CEO picks the SINGLE highest-scoring finding. One change per cycle keeps each iteration bounded and reviewable.
 
-If multiple findings tie, prefer: correctness > security > robustness > performance > architecture > maintainability > test-coverage > ux-dx.
-
-### W2: IMPLEMENT
+If multiple findings tie, prefer: correctness > security > robustness > performance > architecture > maintainability > test-coverage > ux-dx.
+
+Before W2, CEO writes a cycle Mini PRD:
+
+- Goal
+- Scope and non-scope
+- AC IDs
+- UI/API/state contracts, if touched
+- Verification commands and evidence expected
+
+### W2: IMPLEMENT
 
 Modeled on WF's build loop but scoped to ONE change:
 
@@ -247,7 +261,13 @@ Modeled on WF's build loop but scoped to ONE change:
 
 CEO NEVER writes production code — this rule is inherited from WF-MAX (AP1: CEO-as-Worker).
 
-### W3: REVIEW
+Acceptance-specific implementation rules:
+
+- Dispatch `test-writer` when AC IDs need new or updated tests.
+- Dispatch `implementer` with forbidden truth files: PRD, AC, UI/API contracts, test plan, and validation report.
+- Implementer may not rewrite ACs/contracts to make the implementation pass.
+
+### W3: REVIEW
 
 Two-gate review (from WF/subagents.md):
 
@@ -271,7 +291,10 @@ If review or verification fails:
 - For API changes: real request/response check
 - Record evidence in `Harness/tasks/auto/PROGRESS.md`
 
-### RECORD
+Validation must include AC-by-AC evidence in `Harness/tasks/auto/PROGRESS.md`,
+not only a generic pass/fail command result.
+
+### RECORD
 
 Every cycle writes one entry to `Harness/tasks/auto/PROGRESS.md`:
 
@@ -293,11 +316,46 @@ Every cycle writes one entry to `Harness/tasks/auto/PROGRESS.md`:
 - Residual risk: none
 ```
 
-### LOOP → W0
-
-IMMEDIATELY return to W0. No pause between cycles — the only breaks are the adaptive Intent Checkpoint and the A-GATE.
-
-### Intent Checkpoint (adaptive re-anchoring)
+### LOOP → W0
+
+IMMEDIATELY return to W0. No pause between cycles — the only breaks are the adaptive Intent Checkpoint and the A-GATE.
+
+### WF-AUTO Hook Exception
+
+Runtime hooks are disabled by default across the Harness scaffold. The only
+allowed exception is an explicitly enabled `/wf-auto` tick hook for long-running
+auto-optimization.
+
+The hook is not a role-enforcement mechanism, not a memory injection mechanism,
+and not WF-MAX state. It is only a bounded tick trigger:
+
+```text
+wf-auto hook event
+-> confirm /wf-auto is active in Harness/tasks/auto/
+-> check STOP/paused/user-interrupt state
+-> request exactly one W0-W5 tick or one Intent Checkpoint
+-> append heartbeat/evidence to Harness/tasks/auto/PROGRESS.md
+-> exit
+```
+
+Hard boundaries:
+
+- no hook is installed or registered by default
+- only `/wf-auto` may use a runtime hook
+- the hook must run one bounded tick, not an unbounded process
+- the hook must respect `Harness/tasks/auto/STOP`, `state=paused`, user stop,
+  and the 8-Angle Exhaustion Gate
+- the hook must not enforce WF-MAX roles, writeSet, or agent identity
+- the hook must not inject memory directly; use `MEMORY_PROTOCOL.md` scenario
+  hints through controller/context-master
+- the hook must not write production files outside the normal W0-W5 gated flow
+- repeated hook failures must pause auto mode and record evidence, not keep
+  retrying silently
+
+Perpetual behavior comes from repeated bounded ticks with durable evidence, not
+from a single runaway hook process.
+
+### Intent Checkpoint (adaptive re-anchoring)
 
 WF-AUTO is autonomous but not blind. Every N cycles, the CEO pauses briefly to verify alignment. This is NOT a hard stop — it's a lightweight drift check.
 
@@ -471,9 +529,12 @@ Before W2, CEO checks: does this change delete functionality, change public API,
 - Codebase is <100 lines → angle scan overhead > benefit
 - Production hotfix needed urgently → direct fix, not optimization loop
 
-## /wf vs /wf-max vs /wf-auto
-
-| Dimension | /wf | /wf-max | /wf-auto |
+## /wf vs /wf-max vs /wf-auto
+
+Acceptance source is PRD-derived AC IDs in `/wf` and `/wf-max`, and cycle
+Mini PRD-derived AC IDs in `/wf-auto`.
+
+| Dimension | /wf | /wf-max | /wf-auto |
 |-----------|-----|---------|----------|
 | Scope | Task-bounded | Task-bounded | Unbounded |
 | Stop condition | Task complete | Task complete | 8-angle exhaustion + oracle + spark exhausted + 2 confirm rounds |

package/templates/common/Harness/WF-MAX.md

@@ -24,7 +24,15 @@ Managers: scope, coordinate. No source edits. Reviewers: read only.
 If tempted to Read/Edit/Bash a source file → STOP. Spawn a Worker.
 ```
 
-## Trigger
+WF-MAX is the maximum-parallelism version of the same acceptance-driven flow used
+by `/wf`: Mini PRD -> Acceptance Criteria -> UI/API Contracts -> Test Plan ->
+Implementation Dispatch -> Independent Validation -> Review -> Debug -> Memory.
+The hierarchy changes; the source of truth does not. PRD-derived AC IDs govern
+every worker dispatch, test, review, validation result, debug handoff, and memory
+entry. See [ACCEPTANCE_PROTOCOL.md](ACCEPTANCE_PROTOCOL.md),
+[AGENT_ISOLATION.md](AGENT_ISOLATION.md), and [HARNESS_BRIDGE.md](HARNESS_BRIDGE.md).
+
+## Trigger
 
 - Explicit: `/wf-max [task]`
 - Auto: WF task with write-set ≥5 files AND clear disjoint boundaries
@@ -60,19 +68,46 @@ CEO(1) ──┬── Manager₁(span) ──┬── Worker₁..ₙ
 
 The Decomposition Gate is a hard stop. No code changes, no Worker spawns until the gate passes. The CEO MUST produce a Dispatch Table artifact and pass the Self-Audit Checklist. This is the single most important enforcement mechanism in WF-MAX — it exists because **models default to "do it myself" rather than "decompose and delegate."**
 
-### Gate Artifact: Dispatch Table
-
-CEO MUST write this table in the task PLAN.md after W1 architecture defines the write-set and before W2 implementation dispatch:
-
-```
-| File | Concern | Worker Type | Worker Label | Read-Only? |
-|------|---------|------------|--------------|------------|
-| src/a.ts | Auth middleware | implementer | impl-auth | No |
-| src/b.ts | DB schema | implementer | impl-db | No |
-| docs/arch.md | Research existing patterns | researcher | res-arch | Yes |
-```
-
-### Gate Rules (any violation = gate fail, retry)
+### Gate Artifact: Dispatch Table
+
+WF-MAX gate order:
+
+```text
+PRD-GATE
+-> AC-GATE
+-> CONTRACT-GATE
+-> TEST-GATE
+-> D-GATE
+-> IMPLEMENT-GATE
+-> VALIDATION-GATE
+-> REVIEW-GATE
+```
+
+D-GATE answers "who may change which file." The earlier gates answer "what must
+be accepted, how it will be tested, and which truth files are forbidden to
+implementers." The Dispatch Table must map each write Worker to the AC IDs it
+implements.
+
+CEO MUST write this table in the task PLAN.md after W1 architecture defines the write-set and before W2 implementation dispatch:
+
+```
+| File | Concern | Worker Type | Worker Label | Read-Only? |
+|------|---------|------------|--------------|------------|
+| src/a.ts | Auth middleware | implementer | impl-auth | No |
+| src/b.ts | DB schema | implementer | impl-db | No |
+| docs/arch.md | Research existing patterns | researcher | res-arch | Yes |
+```
+
+For acceptance-driven work, add an `AC IDs` column to this table and list every
+criterion the Worker is allowed to satisfy.
+
+### Gate Rules (any violation = gate fail, retry)
+
+Acceptance-specific gate rules:
+
+1. PRD, AC, UI/API contracts, and test plan must exist before implementation dispatch.
+2. Every write Worker row must cite AC IDs.
+3. Implementer forbidden set must include PRD, AC, UI/API contracts, test plan, and validation report unless an approved Change Request is recorded.
 
 1. **Every file in the write-set MUST have exactly one write Worker.** Unassigned files = fail. This is the anti-bundling rule — one Worker touching >1 write file = fail. (Read Workers may span multiple files.)
 2. **Manager count MUST ≥ span_min = ceil(sqrt(write_files) / 3).** This is the anti-under-decomposition rule at the domain level. Fewer than the minimum number of Managers means domains are too coarse. "One Manager can handle everything" is NOT valid in WF-MAX — if the task were that simple, degrade to /wf.
@@ -96,7 +131,11 @@ If the CEO finds itself reaching for Edit/Write/Bash on source files, it is viol
 
 ### Self-Audit Checklist
 
-After producing the Dispatch Table, CEO MUST answer all before proceeding:
+After producing the Dispatch Table, CEO MUST answer all before proceeding:
+
+- [ ] Do PRD, AC, contracts, and test plan exist before implementation dispatch?
+- [ ] Does every implementation Worker row cite AC IDs?
+- [ ] Are truth files excluded from implementer write sets unless Change Request is approved?
 
 - [ ] Did I assign myself any source file? (must be **No** — PLAN.md/PROGRESS.md writes are the exception)
 - [ ] Is every file with planned changes assigned to exactly one write Worker? (must be **Yes**)
@@ -194,9 +233,25 @@ total(depth, span) = Σ span^L for L=0..depth
 
 - Worker failure: retry 1× → on 2nd failure, Manager absorbs or escalates to CEO for replan.
 
-## Wave Orchestration
-
-```
+## Wave Orchestration
+
+WF-MAX expands `/wf` by turning each acceptance phase into a manager/worker
+wave when useful:
+
+```text
+Product Manager Group -> PRD-GATE
+Acceptance Manager -> AC-GATE
+Contract Manager -> CONTRACT-GATE
+Test Manager -> TEST-GATE
+Architecture Manager -> boundary/interface contract
+Implementation Manager -> AC-mapped D-GATE and write-set coloring
+Validation Manager -> E2E/screenshot/trace/contract validation matrix
+Review Manager -> spec/code/test/UX/security review
+Debug Manager -> AC failure root-cause loop
+Memory Master -> durable lessons
+```
+
+```
 W0:    Explore-Mgr    → N parallel researchers → synthesize → CEO
 E-GATE:               → Exploration Gate: CEO verifies all exploration questions answered, findings synthesized (lightweight; see WF.md Decomposition Gate)
 W1:    Architect-Mgr  → 3 parallel → boundary decisions + interface contract → CEO approval
@@ -212,7 +267,8 @@ CLOSEOUT:   CEO → context-master + memory-master (direct, no Manager)
 - **D-GATE** (Write Decomposition Gate): applies AFTER architecture defines the write-set, BEFORE any implementation Worker spawns. Dispatch Table covers the actual write-set. Gate is non-negotiable.
 - W2 dispatch: ALL Workers for a wave MUST be spawned in a single message — not one per turn. Batching is what makes parallelism real.
 
-- Wave scheduling: Managers serial across domains, Workers parallel within domain.
+- Acceptance gates apply before D-GATE. D-GATE decomposes the write set; it does not define the acceptance truth.
+- Wave scheduling: Managers serial across domains, Workers parallel within domain.
 - CEO validates wave output before starting next wave. No pipelining.
 
 ## Overhead & Cost Filter
@@ -233,9 +289,12 @@ These conditions govern **auto-trigger degradation only** (wf-max → /wf). They
 - import/re-export refactor → global consistency required
 - communication overhead > 30% → degrade
 
-## /wf vs /wf-max
-
-| Dimension        | /wf              | /wf-max                          |
+## /wf vs /wf-max
+
+Both modes use the same acceptance-driven mother flow. `/wf-max` changes the
+organization and amount of parallelism, not the PRD-derived source of truth.
+
+| Dimension        | /wf              | /wf-max                          |
 |------------------|------------------|----------------------------------|
 | Organization     | flat             | CEO → Mgr → Worker (3-tier)      |
 | Exploration      | 3-5 serial       | Mgr → 10 parallel                |

package/templates/common/Harness/WF.md

@@ -7,6 +7,13 @@ 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 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.
+
 ## Trigger
 
 Enter WF mode when any of these are true:
@@ -78,22 +85,25 @@ see [WF-MAX.md](WF-MAX.md).
 Intake
 -> confidence gate
 -> parallel planner / researcher / docs-researcher / architect roles
--> synthesis
+-> Mini PRD
+-> Acceptance Criteria
+-> UI/API contracts
+-> test plan
 -> second plan
 -> test-writer
 -> implementer
+-> independent validator
 -> reviewers
--> verifier
--> if failed: debugger -> review -> e2e/API verification -> loop
--> close with evidence
+-> if failed: debugger -> review -> e2e/API validation -> loop
+-> memory closeout with evidence
 ```
 
 ## Intake
 
 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, and write
-   boundaries.
+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
@@ -138,20 +148,27 @@ Use `Harness/subagents.md` as the orchestration methodology and
 ## Second Plan
 
 After exploration, synthesize facts found, assumptions, risks,
-accepted/rejected options, tasks, read/write sets, verification path, and
-rollback or recovery plan.
+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 a failing test or written manual check first.
-2. `implementer` changes only the declared write set.
-3. At least one `reviewer` checks diff, architecture, risks, and missing tests.
-4. For cross-layer or risky work, run separate reviewers for architecture and
-   test adequacy.
-5. `verifier` runs the declared checks and records exact evidence.
+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.
 
 ## Browser And API Evidence
 
@@ -164,6 +181,8 @@ Chrome DevTools, CDP, Playwright, or a documented real-browser run:
 - 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
@@ -175,9 +194,9 @@ If verification fails:
 
 1. Update `Harness/tasks/<task-id>/PROGRESS.md#Heartbeat` with failure count
    and blocker.
-2. Dispatch `debugger` with the failing command, error output, and smallest
-   relevant files.
-3. Fix the smallest reproduced failure.
+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.
@@ -205,7 +224,8 @@ equivalent bounded pass to append a compression suggestion to the task heartbeat
 
 Close only when:
 
-- acceptance criteria are satisfied
+- PRD-GATE, AC-GATE, CONTRACT-GATE, TEST-GATE, VALIDATION-GATE, and REVIEW-GATE are satisfied
+- acceptance criteria are satisfied and reported by AC ID
 - reviewer has no unresolved critical/high findings
 - test/API/browser evidence is recorded
 - affected Harness docs are synced

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

@@ -1,6 +1,13 @@
 # Agent Workflow
 
-Use when implementing, reviewing, debugging, or coordinating subagents.
+Use when implementing, reviewing, debugging, or coordinating subagents.
+
+This workflow is acceptance-driven. PRD-derived Acceptance Criteria are the
+source of truth; implementation, tests, review, validation, debug, and memory
+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
 
@@ -12,8 +19,8 @@ If context grows, load [context-loading.md](context-loading.md) and split the wo
 
 ## Feature Packet
 
-Every PRD scope item must be covered by a task plan at `Harness/tasks/<task-id>/PLAN.md`
-created from `Harness/tasks/_template/PLAN.md` (the primary work tracking system).
+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
@@ -28,17 +35,32 @@ For single-file fixes with no behavior change, a brief note in `PROGRESS.md` is
 task capsule and append to its `PROGRESS.md`. Only create a new task capsule when the
 scope is substantially different. When unsure, ask.
 
-## Standard Build Loop
-
-```text
-PRD/task plan
--> failing test or manual check
--> minimal implementation
--> verification
--> review
--> docs sync
--> close or iterate
-```
+## Acceptance-Driven Build Loop
+
+```text
+Mini PRD
+-> Acceptance Criteria
+-> UI/API contracts
+-> test plan
+-> failing test or manual check
+-> minimal implementation
+-> independent validation
+-> review
+-> debug if needed
+-> docs sync
+-> memory
+-> close or iterate
+```
+
+Rules:
+
+- No PRD, no implementation.
+- No acceptance criteria, no tests.
+- No acceptance criteria, no code.
+- Browser-visible behavior must have a real user-path test or documented browser validation; syntax-only checks are not acceptance.
+- 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
 
@@ -60,11 +82,13 @@ 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.
-- Test Writer writes tests before Implementer writes production code.
-- Implementer only writes inside its declared write set.
-- Writing agents run serially unless write sets are disjoint.
-- Debugger fixes the smallest failing path, not adjacent design.
-- Main agent integrates summaries, resolves conflicts, and runs final verification.
+- 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.
+- Writing agents run serially unless write sets are disjoint.
+- 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
 
@@ -74,7 +98,7 @@ Every dispatched agent returns the handoff format defined in [dispatch.md](dispa
 
 ## Conflict Rule
 
-If PRD, task PLAN.md, architecture, ports, tests, or code disagree:
+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
@@ -85,8 +109,9 @@ If PRD, task PLAN.md, architecture, ports, tests, or code disagree:
 
 Close only when:
 
-- acceptance criteria are satisfied
-- verification evidence is recorded
+- 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

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

@@ -28,14 +28,15 @@ Load other docs only by trigger.
 
 | Trigger | Load |
 | --- | --- |
-| idea, scope, MVP | `Harness/lifecycle.md`, `Harness/research/PRD.md` |
-| research, competitors, stack choice | `Harness/research/README.md`, `Harness/research/research-results.md` |
+| idea, scope, MVP | `Harness/lifecycle.md`, `Harness/research/PRD.md`, `Harness/ACCEPTANCE_PROTOCOL.md` |
+| acceptance, AC, criteria, contract, validation matrix | `Harness/ACCEPTANCE_PROTOCOL.md`, `Harness/AGENT_ISOLATION.md`, `Harness/HARNESS_BRIDGE.md` as needed |
+| 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` |
-| memory, repeated tool failure, repeated user correction, reusable lesson | `Harness/MEMORY.md`, the relevant `Harness/memory/*.md` file |
-| subagent spawn | `Harness/subagents.md`, this file plus the role pack below |
+| 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 |
 
 ## ECC Rules Per Role
 
@@ -51,7 +52,7 @@ Each subagent role loads a specific ECC rule subset. The dispatcher MUST include
 | **Implementer (BE)** | N/A | `common/patterns.md`, `python/fastapi.md` or `golang/patterns.md` | Backend subset |
 | **Test Writer** | `web/testing.md`, `typescript/testing.md` | Stack testing rules | Both |
 | **Reviewer** | `web/design-quality.md`, `web/security.md`, `web/performance.md` | Stack security + testing rules | All |
-| **Debugger** | Stack-specific hooks + coding-style | Stack-specific hooks + coding-style | Context-dependent |
+| **Debugger** | Stack-specific coding-style + patterns | Stack-specific coding-style + patterns | Context-dependent |
 | **Verifier** | `web/testing.md` | Stack testing rules | Both |
 
 ## Subagent Packs
@@ -64,11 +65,11 @@ Explorer Pass:
 - forbid: writes
 - return: files found, facts, risks, suggested tests
 
-Planner:
-- ecc: `common/patterns.md` + `common/development-workflow.md`
-- inject: user goal, lifecycle phase, PRD or PLAN section, dispatch constraints
-- forbid: production code
-- return: tasks, dependencies, read/write sets, dispatch table, gates, open questions
+Planner:
+- ecc: `common/patterns.md` + `common/development-workflow.md`
+- inject: user goal, lifecycle phase, PRD or PLAN section, acceptance gate status, dispatch constraints
+- forbid: production code
+- return: tasks, dependencies, read/write sets, dispatch table, gates, open questions
 
 Researcher:
 - ecc: none (uses WebSearch/WebFetch, not code rules)
@@ -88,11 +89,11 @@ Architect:
 - forbid: implementation
 - return: boundary decision, affected docs, risks
 
-Test Writer:
-- ecc: `common/testing.md` + stack-specific testing rules
-- inject: acceptance criteria, feature doc, test write set
-- forbid: production code
-- return: failing tests and test intent
+Test Writer:
+- ecc: `common/testing.md` + stack-specific testing rules
+- inject: acceptance criteria, UI/API contracts, feature doc, test write set
+- forbid: production code
+- return: failing tests, AC ID mapping, and test intent
 
 Implementer (Frontend):
 - ecc: `web/design-quality.md`, `web/patterns.md`, `web/performance.md`, `typescript/patterns.md`
@@ -106,23 +107,23 @@ Implementer (Backend):
 - forbid: unrelated refactor and test loosening
 - return: changed files and implementation notes
 
-Reviewer:
-- ecc: `web/design-quality.md` (FE), `web/security.md` (FE), `common/security.md`, stack security
-- inject: diff, acceptance criteria, architecture docs
-- forbid: writes
-- return: findings by severity, missing tests, boundary issues
-
-Debugger:
-- ecc: stack-specific coding-style + hooks rules
-- inject: failing command, error output, related files
-- forbid: broad rewrites
-- return: root cause, fix, proof
-
-Verifier:
-- ecc: stack-specific testing rules
-- inject: verification commands and acceptance criteria
-- forbid: code changes
-- return: commands run, results, residual risk
+Reviewer:
+- ecc: `web/design-quality.md` (FE), `web/security.md` (FE), `common/security.md`, stack security
+- inject: PRD, acceptance criteria, UI/API contracts, diff, test/validation evidence, architecture docs
+- forbid: writes
+- return: findings by severity, AC traceability, missing tests, boundary issues
+
+Debugger:
+- ecc: stack-specific coding-style + patterns
+- inject: failed AC ID, failing command, error output, trace/screenshot/network evidence, related files
+- forbid: broad rewrites
+- return: failure layer, root cause, fix, proof
+
+Verifier:
+- ecc: stack-specific testing rules
+- inject: verification commands, acceptance criteria, UI/API contracts, running app/API endpoint
+- forbid: code changes
+- return: commands run, AC-by-AC validation matrix, evidence paths, residual risk
 
 Memory Master:
 - inject: trigger reason, current failure/user-correction/closeout context, task PROGRESS.md section

package/templates/common/Harness/dispatch.md

@@ -10,7 +10,8 @@ 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.
+- 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.
@@ -60,7 +61,10 @@ Without them, the subagent has no way to know which rules or contracts to load.
 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>
+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>
@@ -79,13 +83,15 @@ 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>
-Files read:
+Acceptance IDs:     <AC IDs handled or validated>
+Files read:
 Files changed:
 Findings:
 Evidence:
 Risks:
 Next:
-PLAN patch:
+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.>