create-harness-vibe-coding 0.8.7 → 0.8.8

package/templates/common/.opencode/agents/verifier.md

@@ -0,0 +1,37 @@
+---
+description: Use to run verification commands, inspect results, and record evidence. Final acceptance still waits for cross-review PASS and reflector PASS.
+mode: subagent
+permission:
+  edit: deny
+  task: deny
+  websearch: deny
+  webfetch: deny
+---
+
+# Verifier
+
+You are a verification agent for this project harness.
+
+Load first:
+
+- `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md` when available
+- current feature doc when present
+- verification commands and acceptance criteria
+
+Rules:
+
+- Do not write code.
+- Run only declared verification commands unless asked to expand coverage.
+- If a command is unavailable, record why and suggest a manual check.
+- Mark results as pass, fail, or not run with notes.
+- Do not mark work verified without evidence.
+- Do not claim final acceptance. Verification evidence is necessary but final
+  acceptance waits for cross-review PASS and reflector PASS.
+
+Return:
+
+- commands run
+- result per command
+- acceptance criteria status
+- residual risk
+- patch-ready verification update for `PLAN.md` or feature doc

package/templates/common/.opencode/commands/wf-help.md

@@ -0,0 +1,23 @@
+---
+description: Show the Harness WF command table
+---
+
+Return this help table directly. Do not invoke a skill, do not start WF mode,
+do not dispatch agents, and do not edit files.
+
+| Command | Type | Usage | Purpose |
+| --- | --- | --- | --- |
+| `/wf-help` | direct command | `/wf-help` | Show this command table. |
+| `/wf <task>` | workflow skill | `/wf fix failing login flow` | Standard acceptance-driven workflow for long, uncertain, multi-file, browser/API, or recovery work. |
+| `/wf-max <task>` | workflow skill | `/wf-max refactor auth module` | WF strict superset: complete role chain plus maximum fan-out, CEO -> Manager -> Worker dispatch, cross-CLI overflow when the current runtime agent pool is exhausted. |
+| `/wf-auto` | workflow skill | `/wf-auto` | Perpetual auto-optimization loop using bounded cycles, 8-angle exhaustion, evidence ledger, and optional wf-auto-only tick hook. |
+| `/wf-auto-spark` | workflow skill | `/wf-auto-spark` | Perpetual inspiration mode with roadmap anchoring and external spark search. |
+| `/wf-review <focus>` | workflow skill | `/wf-review security and test coverage` | Cross-model peer review through the other CLI; use for second opinions and risk checks. |
+| `/wf-learn` | workflow skill | `/wf-learn` | Force context-master -> memory-master learning cycle after repeated failures or closeout. |
+| `/wf-readme <task>` | workflow skill | `/wf-readme polish quickstart` | Preserve, merge, or improve README docs without trampling existing project documentation. |
+| `/wf-update` | workflow skill | `/wf-update` | Check/apply Harness scaffold updates with safe file classification and conflict handling. |
+| `/wf-remove` | workflow skill | `/wf-remove` | Safely remove Harness files while preserving project/user data unless explicitly purged. |
+
+Source of truth: `Harness/README.md#Skill Commands` plus installed skills under
+`.claude/skills/` (Claude Code) or `.agents/skills/` (Codex). In OpenCode the
+same skills load from `.claude/skills/`, `.agents/skills/`, and `.opencode/skills/`.

package/templates/common/CLAUDE.md

@@ -1,89 +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`.
-- Keep task records compact: PLAN holds goal, decisions, scope, risks; PROGRESS holds status/next, changes, verification. Link logs or outputs instead of pasting them.
-- 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.
+# 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 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|verifier|reviewer|reflector`). 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.
+- 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/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
 
@@ -55,17 +65,18 @@ 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` | 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), [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 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 |
@@ -85,7 +96,7 @@ 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.
+- 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`.
@@ -136,7 +147,7 @@ Routing priority: if a request explicitly says `/wf <task>`, `$wf`, `wf mode`, `
 |---|---|---|
 | `/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 auto-optimization: never stops until 8-angle exhaustion |
+| `/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 |

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.

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

@@ -6,13 +6,13 @@
 
 - User explicitly invokes `/wf-auto-spark` or `$wf-auto-spark`
 - Auto-degrade from `/wf-auto` when user can't clarify direction at Re-Anchor Gate
-- Auto-activate when 8-angle scan returns empty for 3+ consecutive cycles AND oracle also empty
+- Auto-activate when adaptive internal coverage returns empty for 3+ consecutive cycles AND oracle also empty
 
 ## Core Philosophy
 
 **"Inspiration never runs dry, but direction must hold."**
 
-Spark mode replaces the 8-angle internal scan with EXTERNAL inspiration search. Unlike vanilla `/wf-auto` which can stop when no internal improvements are found, spark mode NEVER stops — it always looks outward for the next idea.
+Spark mode replaces the adaptive internal probe scan with EXTERNAL inspiration search. Unlike vanilla `/wf-auto` which can stop when no internal improvements are found, spark mode NEVER stops — it always looks outward for the next idea.
 
 But perpetual search without direction = drift. The **Roadmap** is the anchor.
 
@@ -77,7 +77,7 @@ Answers: "What does success look like in 6-12 months?">
 STARTUP: Declare roadmap (North Star + Milestones) → user confirms
   ↓
 ┌─────────────────────────────────────────────────────────┐
-│ SPARK: 8 parallel external searches → gather sparks     │
+│ SPARK: parallel external searches → gather sparks     │
 │   ↓                                                     │
 │ FILTER: Keep only sparks relevant to project stack/size  │
 │   ↓                                                     │
@@ -207,14 +207,14 @@ If CEO CANNOT write a convincing value reflection → spark was NOT valuable →
 | SP3 | **Copycat without context** | "Project X does Y so we should too" | Value Gate question 1 |
 | SP4 | **Silent North Star drift** | Small changes accumulate, direction shifts without noticing | Cumulative deviation check every 10 cycles |
 | SP5 | **Milestone rot** | Milestones become irrelevant but aren't updated | Milestone review at Re-Anchor Gate |
-| SP6 | **Spark tunnel vision** | Only looking at one type of source | Rotate through all 8 sources, don't skip any for >3 cycles |
+| SP6 | **Spark tunnel vision** | Only looking at one type of source | Rotate through the registered source families and record skipped sources |
 
 ## Integration with /wf-auto
 
 ```text
 /wf-auto (autonomous optimization)
   ↓
-Internal 8-angle scan per cycle
+Internal adaptive coverage scan per cycle
   ↓
 Re-Anchor Gate (every preset interval)
   ├── User gives clear direction → refine, continue /wf-auto