create-harness-vibe-coding 0.8.6 → 0.8.8

package/templates/common/CLAUDE.md

@@ -1,88 +1,86 @@
-# CLAUDE.md
-
-This repository dogfoods the generated Harness scaffold. Scaffold source files live under `templates/common/` and `templates/optional/`; generated dogfood runtime files live under root `Harness/` and `.claude/`.
-
-## 1. Harness Binding & Startup
-
-- If `Harness/` exists, this repository is governed by the Harness contract. Treat these files as mandatory operating instructions, not optional references.
-- Every session: load `Harness/MEMORY.md` first, then `Harness/README.md`.
-- If `Harness/SETUP.md` exists, follow it before normal project work; it is the install/bootstrap contract and may be deleted after setup is complete.
-
-### 1a. WF-MAX Role Contract (ACTIVE ONLY when /wf-max invoked)
-
-`/wf-max` active -> top-level orchestrator is **CEO**. Delegated Workers follow dispatch packet, edit only assigned writeSet. **Global mode != every agent is CEO.** There is no runtime hook enforcement; role/writeSet compliance is enforced by dispatch packets, review, validation, and durable task evidence.
-
-| ALLOWED (W0 CEO) | FORBIDDEN (always on source) |
-|---|---|
-| Read Harness docs, CLAUDE.md | Edit / Write / MultiEdit |
-| Grep/Glob for scoping | Bash (except `ls`/`dir`/`tree`/`git`) |
-| Agent spawn (ONE message) | Deep source reads → delegate to Worker |
-| Write PLAN.md / PROGRESS.md | Sequential spawn (AP6) |
-
-**Tempted to edit source? STOP. Spawn a Worker with explicit writeSet.**
-
-- `Harness/MEMORY.md` is the memory/resource router: agents, skills, durable memories, and cross-session lessons. Follow its registrations when selecting agents/skills or recording memory.
-- `Harness/README.md` is the task router. For every request, check `Harness/README.md#Load By Task` and `Harness/README.md#Skill Commands`; invoke via `/wf-*` skills or `$wf-*` skills.
-- `Harness/PROGRESS.md` is the global task index. Load at session start to see active task and task history.
-- If work spans more than one step, create a task capsule from `Harness/tasks/_template/` and update `Harness/tasks/<task-id>/PROGRESS.md`.
-- Subagents are readers and reporters. Only the main agent writes to `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md`.
-- Invoke multi-agent work via `subagent-orchestrator` and `Harness/subagents.md`. Update harness via `/wf-update` (see `.claude/skills/wf-update/SKILL.md`).
-- For memory writing, dispatch `memory-master`. For context analysis, dispatch `context-master`.
-- Never bulk-read `Harness/`; route through `Harness/README.md` and `Harness/MEMORY.md`.
-- Scaffold source files live under `templates/common/` and `templates/optional/`; generated dogfood runtime files live under root `Harness/` and `.claude/`.
-
-## 2. Think Before Coding
-
-- You must have **>=95% confidence** in user intent before writing implementation code.
-- If confidence is below 95%, stop and ask up to 3 blocking questions.
-- If multiple valid approaches exist and the choice affects architecture, scope, stack, or user-facing behavior, present trade-offs instead of picking silently.
-- State assumptions before implementation and record durable assumptions, decisions, blockers, handoffs, and verification evidence in `Harness/tasks/<task-id>/PLAN.md`.
-- If something is unclear, stop. Name what is unclear and ask instead of guessing.
-- Before asserting a fact about the codebase, read the file that proves it. If you cannot cite the file and line, do not assert.
-
-## 3. Simplicity First
-
-- No features beyond what was asked.
-- No abstractions for single-use code.
-- No unrequested flexibility, configurability, or speculative error handling.
-- Use explicit interfaces or state models only when they protect a real boundary, clarify ownership, or make verification/recovery simpler.
-- If a simpler approach exists, say so and prefer the smallest change that satisfies the request.
-- If the solution is growing faster than the problem, reduce scope before coding more.
-
-## 4. Surgical Changes
-
-- Touch only files and lines required by the task.
-- Do not improve adjacent code, comments, formatting, or architecture unless it is required for the task.
-- Match existing style even when you would choose a different style in a new project.
-- Clean up imports, variables, functions, and files made unused by your own changes; do not delete pre-existing dead code unless asked.
-- Keep every changed line traceable to the user's request.
-
-## 5. Goal-Driven Execution
-
-- Define verifiable success criteria before implementation.
-- For bugs, reproduce the failure or document why reproduction is impossible before fixing.
-- For multi-step work, keep `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md` current. The main agent is the only state committer; subagents return suggestions only.
-- State assumptions before implementation and record durable assumptions, decisions, blockers, handoffs, and verification evidence in `Harness/tasks/<task-id>/PLAN.md`.
-- Every task needs a test, build check, validator run, or recorded manual check.
-- Do not claim web/UI acceptance without real-browser evidence from Chrome DevTools, CDP, Playwright, or documented manual browser checks.
-- Do not place project build scripts, git conventions, run commands, or release process in this file. Put them in `README.md`.
-- Do not place code architecture here. Put architecture in `Harness/architecture.md` or the current feature doc.
-- If this file has accumulated unrelated project notes, pause and propose moving them to the right place: `README.md` for development operations, `Harness/architecture.md` for architecture, `Harness/WF.md` or `Harness/workflows/` for workflow rules.
-
-## 6. Memory & Self-Learning
-
-- `Harness/MEMORY.md` is the resource index. Detailed durable memory lives in `Harness/memory/`.
-- **Tool reflection trigger**: record a lightweight reflection when the same tool/use pattern fails 3+ times, or when a better command pattern/environment fix is found. Write it newest-first in `Harness/memory/tool-usage-reflections.md`.
-- **User correction trigger**: record a lightweight preference/correction when the user asks to remember it, or when the user corrects the same assumption/pattern 2+ times. Write it newest-first in `Harness/memory/user-corrections-preferences.md`.
-- **Agent lesson trigger**: record reusable lessons from review/debug loops in `Harness/memory/agent-lessons-patterns.md` when they would prevent recurrence.
-- **WF auto-trigger**: before WF closeout, dispatch `context-master` then `memory-master` (or use `/wf-learn`). The old "3x same failure" auto-trigger is unreliable — make this a mandatory closeout gate.
-- **Context threshold trigger**: when context approaches ~85% of the window, dispatch `context-master` to analyze and write a non-blocking compression suggestion to `Harness/tasks/<task-id>/PROGRESS.md#Heartbeat`.
-- **Closeout trigger**: during WF closeout, dispatch `context-master` to extract durable knowledge, then `memory-master` to consolidate into `Harness/memory/*`.
-- Never record secrets, credentials, tokens, or private data in memory.
-
-## 7. Mode Constraints
-
-- Never call `EnterPlanMode` — delegate planning to `planner` subagents (see `Harness/WF.md`).
-- Never write code directly in `/wf` or `/wf-max` CEO mode — delegate all implementation to Workers via dispatch packets with explicit writeSet.
-- **WF-MAX three-layer architecture**: global mode (`wf-max`) != agent role (`ceo|manager|worker|reviewer`). Workers follow dispatch packet (writeSet, forbidden, verification). Missing role/writeSet means the controller must not proceed with source edits.
-- **Enforcement**: `.claude/settings.json` denies `EnterPlanMode` via the `deny` list. WF-MAX role/writeSet compliance is not hook-enforced; it is maintained through dispatch packets, independent review, validation evidence, and the task capsule. Role contract is in [Section 1a](#1a-wf-max-role-contract-active-only-when-wf-max-invoked) - read it first.
+# CLAUDE.md
+
+## 1. Harness Binding & Startup
+
+If `Harness/` exists, this repository is governed by the Harness contract.
+
+Use **direct mode** for simple, single-step, low-risk requests: commit, push, one-line fix, file read, code question, git log, git status, or similar small operations.
+
+In direct mode, do not load the full Harness router. Inspect only the files needed for the task and execute directly.
+
+Use **workflow mode** when the user explicitly invokes a `/wf-*` command, or when the task is multi-step, ambiguous, risky, architectural, cross-file, or requires coordination.
+
+In workflow mode, load `Harness/MEMORY.md` first, then `Harness/README.md`.
+
+If `Harness/SETUP.md` exists, follow it before normal project work; it is the install/bootstrap contract and may be deleted after setup is complete.
+
+### 1a. WF-MAX Role Contract
+
+This section is active only when `/wf-max` is invoked.
+
+In `/wf-max`, the top-level agent is the **CEO**. The CEO owns task framing, decomposition, dispatch, review coordination, and task evidence.
+
+The CEO must not edit source files directly. Source edits must be delegated to Workers through dispatch packets with explicit boundaries.
+
+Each Worker dispatch must define: role, objective, allowed writeSet, forbidden files/actions, required verification, and expected return evidence.
+
+Workers may edit only inside their assigned writeSet. Reviewers and verifiers must be independent from the Worker whose output they evaluate.
+
+Detailed WF-MAX role rules live in `Harness/WF-MAX.md` and `Harness/subagents.md`.
+
+## 2. Think Before Coding
+
+- You must have **>=95% confidence** in user intent before writing implementation code.
+- If confidence is below 95%, stop and ask up to 3 blocking questions.
+- If multiple valid approaches exist and the choice affects architecture, scope, stack, or user-facing behavior, present trade-offs instead of picking silently.
+- State assumptions before implementation and record only durable assumptions, decisions, blockers, handoffs, and verification evidence in `Harness/tasks/<task-id>/PLAN.md`.
+- If something is unclear, stop. Name what is unclear and ask instead of guessing.
+- Before asserting a fact about the codebase, read the file that proves it. If you cannot cite the file and line, do not assert.
+
+## 3. Simplicity First
+
+- No features beyond what was asked.
+- No abstractions for single-use code.
+- No unrequested flexibility, configurability, or speculative error handling.
+- Use explicit interfaces or state models only when they protect a real boundary, clarify ownership, or make verification/recovery simpler.
+- If a simpler approach exists, say so and prefer the smallest change that satisfies the request.
+- If the solution is growing faster than the problem, reduce scope before coding more.
+
+## 4. Surgical Changes
+
+- Touch only files and lines required by the task.
+- Do not improve adjacent code, comments, formatting, or architecture unless it is required for the task.
+- Match existing style even when you would choose a different style in a new project.
+- Clean up imports, variables, functions, and files made unused by your own changes; do not delete pre-existing dead code unless asked.
+- Keep every changed line traceable to the user's request.
+
+## 5. Goal-Driven Execution
+
+- Define verifiable success criteria before implementation.
+- For bugs, reproduce the failure or document why reproduction is impossible before fixing.
+- For multi-step work, keep `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md` current. The main agent is the only state committer; subagents return suggestions only.
+- State assumptions before implementation and record durable assumptions, decisions, blockers, handoffs, and verification evidence in `Harness/tasks/<task-id>/PLAN.md`.
+- Every task needs a test, build check, validator run, or recorded manual check.
+- Do not claim web/UI acceptance without real-browser evidence from Chrome DevTools, CDP, Playwright, or documented manual browser checks.
+- Do not place project build scripts, git conventions, run commands, or release process in this file. Put them in `README.md`.
+- Do not place code architecture here. Put architecture in `Harness/architecture.md` or the current feature doc.
+- If this file has accumulated unrelated project notes, pause and propose moving them to the right place: `README.md` for development operations, `Harness/architecture.md` for architecture, `Harness/WF.md` or `Harness/workflows/` for workflow rules.
+
+## 6. Memory & Self-Learning
+
+`Harness/MEMORY.md` is the memory and resource router. Detailed durable memory lives under `Harness/memory/`.
+
+Do not write memory directly unless the selected workflow allows it. For workflow closeout, use the registered context and memory workflow to extract durable lessons, decisions, corrections, and reusable patterns.
+
+Keep memory compact, durable, and reusable. Do not record transient logs, raw command output, speculative notes, or information that belongs in task-local PLAN.md / PROGRESS.md.
+
+Never record secrets, credentials, tokens, or private data in memory.
+
+## 7. Mode Constraints
+
+- Never call `EnterPlanMode`. Delegate planning to `planner` subagents (see `Harness/WF.md`).
+- In `/wf` or `/wf-max`, follow the selected workflow role contract instead of improvising execution flow.
+- In `/wf-max`, the CEO must not edit source files directly. Implementation must be delegated to Workers with explicit writeSet boundaries.
+- If a Worker dispatch is missing role, objective, writeSet, forbidden scope, or verification requirements, the controller must not proceed with source edits.
+
+Keep CLAUDE.md as a thin routing and global-behavior file. Put detailed workflows in `Harness/WF.md` or `Harness/workflows/`, subagent rules in `Harness/subagents.md`, architecture in `Harness/architecture.md`, and project operations in `README.md`.

package/templates/common/Harness/ACCEPTANCE_PROTOCOL.md

@@ -16,8 +16,10 @@ Context Load
 -> Test Plan
 -> Implementation Dispatch
 -> Independent Validation
--> Review
--> Debug
+-> Cross-Review
+-> Reflector PASS
+-> Final Acceptance
+-> Debug/iterate if needed
 -> Memory
 ```
 
@@ -25,8 +27,8 @@ Mode differences are organizational only:
 
 | Mode | Organization | Same Acceptance Flow |
 | --- | --- | --- |
-| `/wf` / `$wf` | Small team, mostly serial | yes |
-| `/wf-max` / `$wf-max` | CEO -> Manager -> Worker hierarchy | yes |
+| `/wf` / `$wf` | Complete role chain | yes |
+| `/wf-max` / `$wf-max` | Complete role chain plus CEO -> Manager -> Worker fan-out | yes |
 | `/wf-auto` / `$wf-auto` | Repeating optimization loop | yes, per cycle |
 
 ## Gates
@@ -42,6 +44,7 @@ These gates apply before implementation unless the user explicitly asks for a sm
 | IMPLEMENT-GATE | Implementer may not modify acceptance truth files except through Change Request. | dispatch write set and forbidden set |
 | VALIDATION-GATE | Validator must be independent and must validate AC IDs against running behavior. | validation report with evidence matrix |
 | REVIEW-GATE | Reviewer reads PRD, AC, diff, and run evidence directly. | findings with AC IDs |
+| REFLECT-GATE | Reflector reads verifier evidence and reviewer findings before final acceptance. | PASS, RETURN_TO_DEBUG, or BLOCKED verdict |
 
 Truth files are:
 
@@ -55,6 +58,8 @@ Truth files are:
 ## Mini PRD Minimum
 
 Every task that changes behavior needs a Mini PRD. It can live in `Harness/research/PRD.md`, a feature doc, or `Harness/tasks/<task-id>/PLAN.md`.
+For routine scoped work, keep the Mini PRD compact. Do not expand into a long
+product brief unless scope, risk, or user-facing behavior requires it.
 
 Minimum fields:
 
@@ -71,6 +76,9 @@ Minimum fields:
 ## Acceptance Criteria Format
 
 Each AC must be independently testable and use a stable ID:
+Default to 1-3 concise ACs in the task PLAN. Expand to full UI/API contracts,
+test plan, and AC-by-AC validation matrix only for browser-visible,
+API/integration, security/data-loss, cross-module, or other high-risk behavior.
 
 ```markdown
 ## AC-001: Empty phone number cannot request verification code

package/templates/common/Harness/PROGRESS.md

@@ -1,17 +1,17 @@
-# PROGRESS.md
-
-Global task index. Load at session start to see what is active and what was done.
-
-## Active Task
-
-None — create a new task from `Harness/tasks/_template/` when work spans more than one step.
-
-## Task Index
-
-| ID | Goal | Phase | Closed |
-|----|------|-------|--------|
-
-## Cross-Task Decisions
-
-| Date | Decision | Reason |
-|------|----------|--------|
+# PROGRESS.md
+
+Global task index. Load at session start to see what is active and what was done.
+
+## Active Task
+
+None — create a new task from `Harness/tasks/_template/` when work spans more than one step.
+
+## Task Index
+
+| ID | Goal | Phase | Closed |
+|----|------|-------|--------|
+
+## Cross-Task Decisions
+
+| Date | Decision | Reason |
+|------|----------|--------|

package/templates/common/Harness/README.md

@@ -2,7 +2,17 @@
 
 Purpose: route humans and agents to the smallest useful context. `Harness/README.md` is the primary router.
 
-Default load: `CLAUDE.md`, `Harness/MEMORY.md`, this file, and `Harness/PROGRESS.md` when work is active. Do not read the whole `Harness/` tree.
+Default load: `CLAUDE.md`. When the task is complex or a `/wf-*` command is invoked, also load `Harness/MEMORY.md`, this file, and `Harness/PROGRESS.md` when work is active. Do not read the whole `Harness/` tree.
+
+## Direct Mode (Degradation Path)
+
+When the user does NOT invoke `/wf-*` and the request is simple, single-step, and low-risk — commit, push, one-line fix, read file, code question, git log, status check — operate in **direct mode**. Skip the router entirely. Execute the task. Do not load `Harness/MEMORY.md`, `Harness/README.md`, or `Harness/PROGRESS.md`.
+
+Escalate to the router (next section) only when:
+- User explicitly invokes `/wf-*`, `$wf-*`, `wf mode`, `workflow mode`, or `wk mode`
+- Task is multi-step, ambiguous, high-risk, or touches many files
+- Task involves subagent orchestration, architecture changes, or cross-cutting concerns
+- You've failed the same operation twice and need structured recovery
 
 ## 0-1 Flow
 
@@ -18,6 +28,7 @@ For the full phase contract, load [lifecycle.md](lifecycle.md).
 - If the task does not clearly match a row below, search by keywords before loading more docs.
 - 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 the current task's `tasks/<id>/PROGRESS.md` and `tasks/<id>/PLAN.md`, the current feature doc, `Harness/MEMORY.md`, or `Harness/memory/*` as appropriate.
+- Task records are compact by default: PLAN holds goal, decisions, scope, risks; PROGRESS holds status/next, changes, verification. Do not paste command logs, full transcripts, or broad PRDs when a link or one-line evidence entry is enough.
 - Build commands, git conventions, and release notes belong in root `README.md`, not `CLAUDE.md`.
 - README rewrites are optional project-doc work. Use `wf-readme` and preserve existing public docs unless the user approves a broader restructure.
 - Code architecture belongs in [architecture.md](architecture.md) or the current feature doc, not `CLAUDE.md`.
@@ -54,24 +65,24 @@ Keywords are retrieval hints, not project facts.
 
 Load the matching row only. Add adjacent docs only when the loaded doc directly names them.
 
-Routing priority: if a request explicitly says `/wf <task>`, `$wf`, `wf mode`, `workflow mode`, or `wk mode`, or is long, difficult, uncertain, repeated-failure, migration, architecture-heavy, browser-visible, or broad multi-agent implementation work, choose the WF row first. Load `Harness/WF.md` directly, then delegate subagent coordination to `subagent-orchestrator`. If the request says `/wf-auto`, `$wf-auto`, `wf auto`, or `auto mode`, choose the WF-AUTO row and load `Harness/WF-AUTO.md`.
+Routing priority: **direct mode is the default** when no `/wf-*` command is present and the task is simple. If a request explicitly says `/wf <task>`, `$wf`, `wf mode`, `workflow mode`, or `wk mode`, or is long, difficult, uncertain, repeated-failure, migration, architecture-heavy, browser-visible, or broad multi-agent implementation work, choose the WF row first. Load `Harness/WF.md` directly, then delegate subagent coordination to `subagent-orchestrator`. If the request says `/wf-auto`, `$wf-auto`, `wf auto`, or `auto mode`, choose the WF-AUTO row and load `Harness/WF-AUTO.md`.
 
 | When to Read | Keywords | Load | Output |
 | --- | --- | --- | --- |
+| **Direct mode (default)** | simple, single-step, low-risk, commit, push, one-line, read, question, status, no /wf-* command | Nothing beyond CLAUDE.md | Direct execution; no router load |
 | Raw idea or vague product request | idea, vague, clarify, goal, non-goal, lifecycle | [lifecycle.md](lifecycle.md), [research/PRD.md](research/PRD.md) | clarified goal, non-goals, first questions |
 | Need market/tech direction | research, market, competitor, stack, library, pricing, policy | [research/README.md](research/README.md), [research/research-results.md](research/research-results.md) | research protocol, adopted/rejected choices |
 | Need MVP/spec | PRD, MVP, scope, requirement, acceptance, non-goal | [research/PRD.md](research/PRD.md), [ACCEPTANCE_PROTOCOL.md](ACCEPTANCE_PROTOCOL.md) | Mini PRD with AC IDs and verifiable acceptance criteria |
 | Need architecture or boundaries | architecture, boundary, layer, port, adapter, dependency | [architecture.md](architecture.md) | layer map, ports, constraints |
 | Need WF command help | /wf-help, wf help, command list, list wf commands | `.claude/commands/wf-help.md` | direct command table; no skill invocation |
-| Need WF mode | wf, /wf, $wf, wf mode, workflow mode, wk mode, long task, difficult, stuck, repeated failure | [WF.md](WF.md), [PROGRESS.md](PROGRESS.md), the current task `tasks/<id>/PROGRESS.md` and `tasks/<id>/PLAN.md` | exploration plan, second plan, heartbeat, recovery loop; explicit WF/WK loads subagent docs immediately |
-| Need perpetual auto-optimization | /wf-auto, $wf-auto, wf auto, auto mode, never stop, self-improve, continuous optimize | [WF-AUTO.md](WF-AUTO.md), [subagents.md](subagents.md), [dispatch.md](dispatch.md) | perpetual loop, bounded ticks, optional wf-auto-only hook exception, 8-angle scan, spark search, intent checkpoint, evidence ledger; CEO never writes code |
-| Need perpetual inspiration mode | /wf-auto-spark, $wf-auto-spark, wf auto spark, spark mode, external inspiration, discover mode, never stop | [WF-AUTO-SPARK.md](WF-AUTO-SPARK.md), [WF-AUTO.md](WF-AUTO.md), [subagents.md](subagents.md), [dispatch.md](dispatch.md) | roadmap-anchored: North Star + milestones; external spark search; ≤50% deviation guard; never auto-stops |
-| Need WF-MAX mode | /wf-max, $wf-max, wf max, maximum parallelism, CEO, Manager, Worker, fan-out | [WF-MAX.md](WF-MAX.md), [subagents.md](subagents.md), [dispatch.md](dispatch.md) | CEO-only dispatch, W0 fan-out, D-GATE, wave evidence |
+| Need WF mode | wf, /wf, $wf, wf mode, workflow mode, wk mode, long task, difficult, stuck, repeated failure | [WF.md](WF.md), [PROGRESS.md](PROGRESS.md), the current task `tasks/<id>/PROGRESS.md` and `tasks/<id>/PLAN.md` | complete role chain, heartbeat, recovery loop; explicit WF/WK loads subagent docs immediately |
+| Need perpetual auto-optimization | /wf-auto, $wf-auto, wf auto, auto mode, never stop, self-improve, continuous optimize | [WF-AUTO.md](WF-AUTO.md), [WF-AUTO-ANGLES.md](WF-AUTO-ANGLES.md), [subagents.md](subagents.md), [dispatch.md](dispatch.md) | perpetual loop, adaptive probe selection, dynamic risk obligations, spark search, intent checkpoint, evidence ledger; CEO never writes code |
+| Need perpetual inspiration mode | /wf-auto-spark, $wf-auto-spark, wf auto spark, spark mode, external inspiration, discover mode, never stop | [WF-AUTO-SPARK.md](WF-AUTO-SPARK.md), [WF-AUTO.md](WF-AUTO.md), [subagents.md](subagents.md), [dispatch.md](dispatch.md) | roadmap-anchored: North Star + milestones; external spark search; <=50% deviation guard; never auto-stops |
+| Need WF-MAX mode | /wf-max, $wf-max, wf max, maximum parallelism, CEO, Manager, Worker, fan-out | [WF-MAX.md](WF-MAX.md), [subagents.md](subagents.md), [dispatch.md](dispatch.md) | WF strict superset: complete role chain plus maximum fan-out, current runtime subagents first, cross-CLI overflow when available |
 | Need peer review | /wf-review, $wf-review, peer review, second opinion, cross-check, stuck | `.claude/skills/wf-review/SKILL.md`, `.agents/skills/wf-review/SKILL.md`, `Harness/README.md` | cross-model multi-dimension review with severity classification |
 | Adding harness to existing project | existing project, onboarding, migrate, bootstrap, preserve, conflict | [extension.md](extension.md), [PROGRESS.md](PROGRESS.md), root `README.md` and package/CI files | discovered project facts, preserved config, manual registration plan |
 | README optimization | README, docs, quickstart, install docs, architecture diagram, command table, documentation polish | root `README.md`, `.claude/skills/wf-readme/SKILL.md`, [PROGRESS.md](PROGRESS.md), [architecture.md](architecture.md) as needed | approved README mode, preserved sections, proposed diff plan |
 | Need implementation plan | plan, task, write set, verify, milestone, progress | [PROGRESS.md](PROGRESS.md), the current task `tasks/<id>/PROGRESS.md` and `tasks/<id>/PLAN.md`, [agent-workflow.md](agent-workflow.md), [ACCEPTANCE_PROTOCOL.md](ACCEPTANCE_PROTOCOL.md) | tasks, AC IDs, write set, verification commands |
-| Browser E2E testing or automation | /wf-browser, browser, e2e, web automation, form fill, screenshot verify, page test, browser test, Playwright AI, Browser Use, CDP | browser-e2e workflow, [HARNESS_BRIDGE.md](HARNESS_BRIDGE.md), wf-browser skill, Browser Use skill | UI/API contract, CLI commands, screenshots, traces, validation matrix |
 | Optional workflow installed | workflow, optional, ui-ux-review, github-pr-review, python-backend, ts-react-frontend | matching `workflows/*.md` (if installed), [extension.md](extension.md) | workflow-specific evidence, commands, fallback path |
 | Need durable memory or reflection | memory, remember, preference, correction, tool failure, lesson, reflection, scenario memory | [MEMORY.md](MEMORY.md), [MEMORY_PROTOCOL.md](MEMORY_PROTOCOL.md), `Harness/memory/tool-usage-reflections.md`, `Harness/memory/user-corrections-preferences.md`, `Harness/memory/agent-lessons-patterns.md` | concise newest-first memory entry, scenario memory hint, or no-op rationale |
 | Need subagents | subagent, role pack, context, inject, return format, orchestrator, isolation | [subagents.md](subagents.md), [context-loading.md](context-loading.md), [dispatch.md](dispatch.md), [AGENT_ISOLATION.md](AGENT_ISOLATION.md) | controller plan, role-specific context pack, isolation-aware dispatch pack |
@@ -85,9 +96,9 @@ Routing priority: if a request explicitly says `/wf <task>`, `$wf`, `wf mode`, `
 
 - Move phases in order unless the user asks for a fast lane.
 - Use `/wf <task>` in Claude Code, `$wf` in Codex, `/wf-max [task]` or `$wf-max`, `wf mode`, `workflow mode`, or `wk mode` when a task is long, difficult, uncertain, multi-file, or repeatedly failing.
-- Use `/wf-auto` for perpetual self-directed optimization that never stops until 8-angle exhaustion.
-- **WF-MAX Role Contract**: Three-layer architecture — global mode (`wf-max`), agent role (`ceo|manager|worker|reviewer`), dispatch permission (`writeSet`, `forbidden`, `verification`). CEO never writes source code. Workers edit only dispatch.writeSet. Compliance is checked through dispatch packets, independent review, validation evidence, and task capsules. See `CLAUDE.md` §1a.
-- **WF-REVIEW Anti-Self-Review**: Must invoke the OTHER CLI (Codex↔Claude). Same-model simulation is forbidden.
+- Use `/wf-auto` for perpetual self-directed optimization. It selects probes from project evidence and stops only after dynamic risk obligations and two different empty confirmation passes are recorded.
+- **WF-MAX Role Contract**: Three-layer architecture: global mode (`wf-max`), agent role (`ceo|manager|worker|verifier|reviewer|reflector`), dispatch permission (`writeSet`, `forbidden`, `verification`). CEO never writes source code. Workers edit only dispatch.writeSet. Compliance is checked through dispatch packets, independent review, validation evidence, and task capsules. See `CLAUDE.md#1a`.
+- **WF-REVIEW Anti-Self-Review**: Must invoke the OTHER CLI (Codex -> Claude, or Claude -> Codex). Same-model simulation is forbidden.
 - WF-MAX has no runtime hook state. The durable state is the task capsule, dispatch table, review findings, and validation evidence. The only runtime hook exception in Harness is the optional `/wf-auto` bounded tick hook described in `WF-AUTO.md`.
 - Do not code before PRD-GATE, AC-GATE, CONTRACT-GATE, and TEST-GATE are satisfied or explicitly compressed into a documented fast lane.
 - PRD-derived Acceptance Criteria are the source of truth. Code, tests, reviews, validation, debug, and memory must trace to AC IDs.
@@ -102,7 +113,7 @@ Routing priority: if a request explicitly says `/wf <task>`, `$wf`, `wf mode`, `
 - In WF Max mode, D-GATE (Dispatch Table + Self-Audit Checklist) is mandatory before W2 implementation dispatch.
 - Do not add stack-specific agents or skills without following `extension.md`.
 - Do not close work without tests or recorded manual verification.
-- Do not mark work `Verified` until evidence is recorded in the current task's `tasks/<id>/PROGRESS.md` and `tasks/<id>/PLAN.md` or the feature doc.
+- Do not mark work `Verified` until evidence is recorded, cross-review has passed, and reflector verdict is PASS.
 - Run `node Harness/scripts/validate-harness.mjs` for install-complete scaffold structure; run `node Harness/scripts/validate-harness.mjs --strict` only after bootstrap resolves project-fact placeholders and before release.
 - If a doc still has `{{...}}`, treat that section as a template, not project fact.
 
@@ -134,13 +145,12 @@ Routing priority: if a request explicitly says `/wf <task>`, `$wf`, `wf mode`, `
 
 | Claude Code | Codex | Purpose |
 |---|---|---|
-| `/wf <task>` | `$wf <task>` | Long-task workflow: explore -> plan -> implement -> review -> verify |
-| `/wf-max [task]` | `$wf-max [task]` | Maximum parallelism: CEO -> Manager -> Worker hierarchy |
-| `/wf-auto` | `$wf-auto` | Perpetual auto-optimization: never stops until 8-angle exhaustion |
-| `/wf-auto-spark` | `$wf-auto-spark` | Perpetual inspiration: spark search, roadmap-anchored, ≤50% deviation guard, never auto-stops |
+| `/wf <task>` | `$wf <task>` | Complete role chain: plan, research/docs, architecture, test, implement, validation, cross-review, reflector, acceptance |
+| `/wf-max [task]` | `$wf-max [task]` | WF strict superset with maximum parallelism: CEO -> Manager -> Worker, cross-CLI overflow |
+| `/wf-auto` | `$wf-auto` | Perpetual adaptive auto-optimization: dynamic probes, risk obligations, evidence-based exhaustion |
+| `/wf-auto-spark` | `$wf-auto-spark` | Perpetual inspiration: spark search, roadmap-anchored, <=50% deviation guard, never auto-stops |
 | `/wf-review [focus]` | `$wf-review [focus]` | Cross-model peer review via Codex <-> Claude |
 | `/wf-learn` | `$wf-learn` | Force learning cycle: context-master -> memory-master |
-| `/wf-browser [task]` | `$wf-browser [task]` | AI-driven browser automation for E2E testing |
 | `/wf-readme [task]` | `$wf-readme [task]` | README preservation, merge, and documentation improvement workflow |
 | `/wf-update` | `$wf-update` | Script-driven harness update: fetch + compare + apply |
 | `/wf-remove` | `$wf-remove` | Safe harness removal: auto-delete SAFE, confirm MODIFIED, preserve USER DATA |

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

@@ -0,0 +1,170 @@
+# WF-AUTO Adaptive Coverage Protocol
+
+`wf-auto` does not need a permanent number of angles. It needs enough
+independent evidence to discover a valuable next change without repeatedly
+scanning irrelevant surfaces.
+
+## Design goals
+
+- Select probes from evidence, not from a fixed checklist.
+- Keep safety and user intent visible in every cycle.
+- Spend more context on risky or recently changed areas.
+- Record skipped probes and the reason they were skipped.
+- Stop only after the relevant coverage obligations are satisfied and two
+  different confirmation passes produce no actionable finding.
+
+## Probe catalog
+
+The catalog is extensible. These are probe families, not mandatory agents:
+
+| Probe | Primary question | Trigger signals |
+|---|---|---|
+| Goal / value | Is this change still moving the project toward the user's outcome? | user goal, roadmap, product behavior, repeated scope drift |
+| Context / memory quality | Does the agent receive the right context at the right time without noise or loss? | long tasks, repeated rediscovery, oversized prompts, stale memory |
+| Correctness / safety | Can the change be wrong, destructive, or inconsistent? | changed logic, state transitions, file writes, data mutations |
+| Security / privacy | Can an attacker or accidental disclosure exploit this path? | auth, permissions, input, secrets, network, personal data |
+| Reliability / recovery | What happens on timeout, interruption, retry, partial failure, or restart? | external calls, queues, persistence, background work, flaky tests |
+| Performance / cost | Is time, memory, token, I/O, or bundle cost becoming material? | hot paths, large data, repeated scans, slow tests, cost evidence |
+| Architecture / changeability | Will this make the next change harder or violate boundaries? | new dependency, cross-layer edit, duplicated state, large diff |
+| Test / verification | Is the claimed behavior actually checked with the right evidence? | new behavior, changed acceptance criteria, weak or missing tests |
+| Evaluation / outcome quality | Can we tell whether the agent or product actually improved? | AI behavior, subjective output, benchmark drift, vague success claims |
+| Maintainability | Will a future maintainer understand and safely change this? | duplication, dead code, naming, stale comments, complex functions |
+| UX / DX / observability | Can a user or developer understand, operate, and diagnose it? | CLI/API changes, errors, docs, logs, metrics, browser-visible flow |
+| Dependency / ecosystem | Is an external assumption stale, unsafe, or unnecessarily costly? | package changes, deprecations, API version changes, external research |
+
+Add a probe when the project domain requires it. Do not force every project to
+run every probe.
+
+## Selection algorithm
+
+At the start of every W0 cycle, the CEO builds a project profile from the
+repository, task capsule, recent diff, failures, and user direction. For each
+candidate probe, score these signals from 0 to 5:
+
+```text
+priority =
+  0.30 * risk
+  + 0.25 * changeRelevance
+  + 0.20 * evidenceGap
+  + 0.15 * expectedUserValue
+  + 0.10 * novelty
+  - 0.10 * scanCost
+```
+
+The score is a ranking aid, not a claim of mathematical precision. The CEO
+must record the evidence behind the top scores.
+
+Select probes until one of these conditions is met:
+
+1. all high-risk obligations are covered;
+2. the next probe's expected value is below the scan-cost threshold;
+3. the cycle context budget is spent; or
+4. the selected probes have overlapping scope and the next one adds no new
+   coverage.
+
+Every cycle includes the two guardrails **Goal / value** and
+**Correctness / safety**, unless the CEO records why a project has no relevant
+user outcome or executable behavior. Other probes are conditional. A normal
+low-risk cycle may use only a few probes; a dependency, security, data, or
+production incident cycle should select more.
+
+## Dynamic obligations
+
+The project profile creates obligations instead of a fixed angle count:
+
+| Evidence in the project | Required probe families |
+|---|---|
+| Auth, permissions, secrets, personal data | Security / privacy + Correctness / safety |
+| Database, queue, filesystem, network, background jobs | Reliability / recovery + Correctness / safety |
+| Public API, CLI, SDK, schema, or config contract | Goal / value + Test / verification + UX / DX |
+| Hot path, large data, slow suite, cost complaint | Performance / cost + Test / verification |
+| Cross-layer or dependency-boundary change | Architecture / changeability + Correctness / safety |
+| Browser-visible behavior | UX / DX / observability + Test / verification + real browser evidence |
+| Documentation-only change | Goal / value + UX / DX / observability; skip code probes unless triggered |
+
+If multiple rows match, merge their obligations and deduplicate overlapping
+probes. A skipped obligation must have a reason in the cycle ledger.
+
+## Common probe recipes
+
+These recipes are starting points, not another fixed checklist. Select only the
+probes supported by the current evidence:
+
+| Project or change type | Start with | Add when triggered |
+|---|---|---|
+| Web app / API | Goal / value, Correctness / safety, Test / verification, UX / DX | Security for auth/input; Reliability for external calls; Performance for hot paths |
+| CLI / SDK / public package | Goal / value, contract compatibility, UX / DX, Test / verification | Dependency for version changes; Maintainability for API surface growth |
+| AI agent / workflow system | Goal / value, Context quality, Correctness / safety, Evaluation / verification | Security for tool access; Cost for token/tool growth; Recovery for long-running state |
+| Data pipeline / async jobs | Correctness / safety, Reliability / recovery, Test / verification | Performance for volume; Security for sensitive data; Observability for production diagnosis |
+| Documentation / README / growth copy | Goal / value, UX / DX / discoverability, factuality, link integrity | Dependency for install commands; Accessibility for rendered UI or diagrams |
+
+For an AI agent repository, **context quality**, **tool safety**, **evaluation**,
+and **recovery** are usually more valuable than a generic maintainability scan.
+For a docs-only change, do not spend a cycle pretending to optimize algorithmic
+performance.
+
+## Scan strategies
+
+Confirmation passes must change the search strategy, not merely repeat the same
+prompt:
+
+- **Breadth** — map affected modules, interfaces, tests, and user paths.
+- **Depth** — trace one high-risk path from input to observable outcome.
+- **Change-first** — inspect the latest diff, failures, and touched boundaries.
+- **Failure-first** — start from flaky tests, incidents, TODOs, and user reports.
+- **Contract-first** — compare behavior against PRD, acceptance criteria, API,
+  CLI, or documentation promises.
+
+Rotate strategies when a pass is empty. Re-run a probe when its confidence is
+below 0.8 or its relevant surface coverage is below 80%.
+
+## Exhaustion gate
+
+The A-GATE is evidence-based:
+
+1. all dynamic high-risk obligations for the current project profile are
+   covered;
+2. every selected probe returns structured findings, confidence, and surface
+   coverage;
+3. no selected probe has an actionable finding above the current value gate;
+4. two confirmation passes use different strategies and produce no new
+   actionable finding; and
+5. the CEO records unresolved uncertainty, skipped probes, and why oracle or
+   spark search was or was not needed.
+
+The cross-model oracle is triggered by unresolved high-risk uncertainty or a
+borderline exhaustion result. Spark search is triggered by a genuine value gap,
+not merely because a catalog was empty. This prevents both premature stopping
+and pointless full-tree scanning.
+
+## Cycle ledger
+
+Each W0 entry records compact JSON-like evidence:
+
+```text
+profile: web-api + public-auth + recent-db-change
+goal: reduce failed checkout recovery time
+selected: correctness/safety, reliability/recovery, security/privacy, test/verification
+skipped: performance/cost (no hot-path signal); dependency/ecosystem (no dependency change)
+strategy: change-first
+coverage: 0.92
+findings: 2
+next: reliability finding, priority 4.3/5
+```
+
+The ledger makes angle choice explainable, lets the next cycle avoid duplicate
+work, and gives `/wf-review` or the user enough evidence to challenge the
+selection.
+
+## User controls
+
+Users can steer selection in natural language without learning hidden flags:
+
+```text
+/wf-auto 重点优化安全和数据恢复，忽略没有证据支持的性能优化
+/wf-auto 只关注 CLI 易用性、文档和错误提示
+/wf-auto 先扫描最近改动和失败测试，再决定本轮分析探针
+```
+
+The agent must treat these as priorities, not permission to skip safety or
+verification for a change that can affect data or production behavior.