create-harness-vibe-coding 0.3.0 → 0.3.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README-CN.md CHANGED
@@ -1,8 +1,14 @@
1
1
  # create-harness-vibe-coding 中文说明
2
2
 
3
- 0-1 产品 Harness 脚手架,用于 AI 辅助工程:从想法、调研、PRD、架构、计划,到实现、验证和反馈闭环。
3
+ 0-1 产品 Harness 脚手架,AI 辅助工程全流程。English: [README.md](README.md)
4
4
 
5
- English README: [README.md](README.md)
5
+ ## 一条命令
6
+
7
+ ```bash
8
+ npx create-harness-vibe-coding@latest my-project
9
+ ```
10
+
11
+ ---
6
12
 
7
13
  ## 一句话交给 Agent
8
14
 
@@ -12,77 +18,74 @@ English README: [README.md](README.md)
12
18
 
13
19
  ## 两种安装方式
14
20
 
15
- ### 1. npx 安装
16
-
17
- 适合需要确定性写入、明确冲突策略、可重复 dry-run 的场景。
18
-
19
- ### 2. 直接把链接丢给 agent
20
-
21
- 适合老项目、老架构升级、已有复杂 `CLAUDE.md` / `AGENTS.md` / `.claude/` 的场景。agent 应该读取这个仓库 README,理解当前项目结构,执行或模拟 dry-run,然后给出最小迁移方案。
21
+ ### npx 安装
22
+ 适合确定性写入、明确冲突策略、可重复 dry-run 的场景。
23
+
24
+ ### 直接把链接丢给 Agent
25
+ 适合老项目升级。Agent 会读取仓库 README,理解当前项目结构,执行或模拟 dry-run,给出最小迁移方案。如果已有 `CLAUDE.md`,Agent 必须先请求用户确认再合并。
26
+
27
+ ## Harness 工作流
28
+
29
+ ```mermaid
30
+ graph TD
31
+ A[ /wf 进入工作流 ] --> B[ 探索: 3个并行subagent ]
32
+ B --> C[ 二阶段计划 ]
33
+ C --> D[ 构建: test write加implement ]
34
+ D --> E[ 双门禁审查 ]
35
+ E --> F{ 通过? }
36
+ F -->| 否 | G[ debugger 修复 循环 ]
37
+ G --> E
38
+ F -->| 是 | H[ 收尾: context加memory ]
39
+ H --> I[ wf update 增量更新 ]
40
+ ```
22
41
 
23
- 如果项目里已经有 `CLAUDE.md`,agent 必须先告诉用户:`CLAUDE.md` 是根 agent 入口合同,不能静默覆盖或乱合并。正确流程是先请求用户确认是否重构/合并 `CLAUDE.md`,再在保留原项目规则的基础上补入 Harness 的 startup、memory、router、workflow、subagents 编排约束。
42
+ ## 核心文件
24
43
 
25
- Agent-link 安装前置问题,编辑前先问:
44
+ | 文件 | 用途 |
45
+ |------|------|
46
+ | `CLAUDE.md` | Claude Code 根入口,保持短小 |
47
+ | `Harness/README.md` | 文档路由器——按任务关键词加载最少文档 |
48
+ | `Harness/WF.md` | 长任务工作流:摄入 → 探索 → 计划 → 构建 → 审查 → 验证 → 恢复 |
49
+ | `Harness/PROGRESS.md` | 全局任务索引 |
50
+ | `Harness/tasks/<id>/` | 每任务胶囊:PROGRESS.md(进度+心跳)+ PLAN.md(实施+证据) |
51
+ | `.claude/agents/` | 11 个通用 Agent:planner, researcher, architect, implementer, reviewer, debugger, verifier, memory-master, context-master... |
52
+ | `.claude/skills/` | wf-mode, subagent-orchestrator, wf-update, harness-router... |
26
53
 
27
- 只询问会影响写入、架构、安全或工作流的选择。开始时最多问 3 个 blocking 问题,其余采用安全默认值并记录到计划里,等真正触发时再继续追问。
54
+ ## WF 模式
28
55
 
29
- | 主题 | 什么时候问 | 没回答时的默认值 |
30
- | --- | --- | --- |
31
- | 根 agent 入口 | 已存在 `CLAUDE.md`、`AGENTS.md`、`.claude/` 或其他 agent 入口文件 | 保留现有文件;合并 Harness 入口合同前必须询问用户 |
32
- | Harness 存放位置 | `docs/` 已经用于 GitHub Pages、产品文档或生成文档 | 默认使用根目录 `Harness/`;不要把 Harness 文档写进 `docs/` |
33
- | README 归属 | 根 `README.md` 是公开产品页、包文档或已有大量自定义内容 | 保留现有 README,只提议追加最小 Development section |
34
- | README 优化 | 已有 README 过时、太单薄、缺少命令表格,或用户想要架构图/更生动的文档 | 可推荐 `readme-optimizer`;默认只追加 Development notes,结构化优化或重写必须先得到用户确认 |
35
- | 扩展能力 | ECC、Superpowers、自定义 rules 或栈相关 skills 可能有用 | 先推荐;只有用户同意后才安装 |
36
- | Skills | 技术栈已明确,测试、前端、后端、review、浏览器证据可用 optional skills 增强 | 用户同意后只安装 1-2 个最相关 skills |
37
- | CI/CD | 已有 CI 配置,或项目缺少测试/构建 gate | 先记录现有命令;只有用户同意后才新增或规范 CI/CD |
38
- | 验证深度 | 涉及浏览器可见行为、API、数据库、鉴权、支付或部署 | 必须有真实命令证据;相关场景必须有浏览器/API 证据 |
39
- | Memory/隐私 | 仓库包含敏感领域数据、客户数据、密钥或私有流程 | 只启用 memory index;禁止记录 secrets 或私有数据 |
40
- | Branch/worktree | 存在未提交改动、风险迁移或并行实现 lane | 保护当前工作区;大改前先提议 branch/worktree |
41
- | 包管理器/技术栈 | 存在多个包管理器、monorepo apps 或技术栈边界不清 | 写文件前先确认当前 workspace/app 范围 |
42
-
43
- ## 一条命令
56
+ 输入 `/wf`、`wf mode`、`workflow mode` `wk mode` 进入长任务工作流。默认启动 3 个并行只读 subagent 做探索,然后二阶段计划 → 实现 → 双门禁审查 → 验证。失败时自动进入恢复循环(debugger → review → verify)。收尾时 context-master 提取知识,memory-master 写入记忆。
44
57
 
45
58
  ```bash
46
- npx create-harness-vibe-coding@latest my-project
59
+ # 进入 WF 模式
60
+ "用 /wf 处理这个长任务迁移。"
61
+ "wf mode — 帮我重构认证层。"
47
62
  ```
48
63
 
49
- ## 现有项目渐进安装
64
+ ## WF Update
50
65
 
51
- 先预览,不写文件:
66
+ 从 GitHub 增量更新脚手架,校验和安全。
52
67
 
53
68
  ```bash
54
- npx create-harness-vibe-coding@latest my-app . -y --dry-run
69
+ /wf update --check # 只检查
70
+ /wf update # 完整更新
55
71
  ```
56
72
 
57
- 再保留现有文件,只补缺失的 Harness 文件:
73
+ ## 已有项目安装
58
74
 
59
75
  ```bash
76
+ # 先预览
77
+ npx create-harness-vibe-coding@latest my-app . -y --dry-run
78
+
79
+ # 保留现有文件,只补缺失
60
80
  npx create-harness-vibe-coding@latest my-app . -y --on-conflict skip
61
81
  ```
62
82
 
63
- 安装后让 agent 先读 `Harness/SETUP.md`,再开始正常工作。
64
-
65
- ## 核心约束
66
-
67
- - `CLAUDE.md` 只做薄入口和路由,不放项目架构、构建脚本、git 规范。
68
- - 项目开发命令、构建、测试、git、发布流程放根目录 `README.md`。
69
- - 架构说明放 `Harness/architecture.md` 或当前 feature 文档。
70
- - Harness 文档、状态、记忆、工作流默认放根目录 `Harness/`。
71
- - 如果已有 `AGENTS.md`,agent 必须先询问用户是否同意修改。
72
- - 长任务、多文件、多 subagents、低置信度或重复失败时使用 `/wf`、`wf-mode` 和 `Harness/WF.md`。
73
-
74
- ## 常用生成物
75
-
76
- | 文件 | 用途 |
77
- | --- | --- |
78
- | `CLAUDE.md` | Claude Code 根入口,保持短小 |
79
- | `Harness/README.md` | Harness 路由器 |
80
- | `Harness/SETUP.md` | 初次安装和 bootstrap 指南 |
81
- | `Harness/MEMORY.md` | agents、skills、记忆文件索引 |
82
- | `Harness/PLAN.md` | 当前计划、heartbeat、handoff、验证证据 |
83
- | `Harness/WF.md` | 长链路 workflow 和恢复循环 |
84
- | `Harness/subagents.md` | 多 subagents 编排方法论 |
85
- | `.claude/skills/*` | Claude Code 可加载的 Harness skills |
83
+ | 冲突模式 | 含义 |
84
+ |----------|------|
85
+ | `fail`(默认) | 目标文件已存在则停止 |
86
+ | `skip` | 保留现有文件,只创建缺失 |
87
+ | `backup` | 备份 → 写入新文件 |
88
+ | `overwrite` | 直接覆盖 |
86
89
 
87
90
  ## 验证
88
91
 
@@ -90,5 +93,3 @@ npx create-harness-vibe-coding@latest my-app . -y --on-conflict skip
90
93
  npm test
91
94
  node Harness/scripts/validate-harness.mjs
92
95
  ```
93
-
94
- 生成项目后,`Harness/scripts/validate-harness.mjs` 用于检查 Harness 结构、注册关系和必要规范是否完整。
package/README.md CHANGED
@@ -11,14 +11,16 @@
11
11
  <sub>Idea -> Research -> PRD -> Architecture -> Plan -> Build -> Verify -> Feedback.</sub>
12
12
  </p>
13
13
 
14
- ---
15
-
16
14
  ## One Command
17
15
 
18
16
  ```bash
19
17
  npx create-harness-vibe-coding@latest my-project
20
18
  ```
21
19
 
20
+ Chinese README: [README-CN.md](README-CN.md)
21
+
22
+ ---
23
+
22
24
  | What You Get | Purpose |
23
25
  |-------------|---------|
24
26
  | `CLAUDE.md` + `Harness/README.md` | Thin root entry and dynamic doc router |
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "create-harness-vibe-coding",
3
- "version": "0.3.0",
3
+ "version": "0.3.1",
4
4
  "description": "Scaffold a 0-1 product harness for AI-assisted research, PRD, planning, architecture, build, test, and feedback loops",
5
5
  "type": "module",
6
6
  "bin": {
@@ -0,0 +1,28 @@
1
+ # /wf max
2
+
3
+ Enter maximum-parallelism workflow mode. Splits tasks into minimal non-conflicting units and dispatches as many subagents as possible in parallel waves.
4
+
5
+ ## Required
6
+
7
+ - Load `wf-max` skill.
8
+ - MUST run exploration fan-out with as many read-only subagents as useful.
9
+ - MUST partition implementation into disjoint write sets across parallel waves.
10
+ - MUST run parallel reviewers per dimension after each implementation wave.
11
+
12
+ ## Loop
13
+
14
+ ```text
15
+ intake
16
+ -> max-parallel exploration (5-14 read-only agents)
17
+ -> synthesis + write-set coloring → dependency graph
18
+ -> wave 1: N parallel implementers (disjoint file claims)
19
+ -> wave 1 review: parallel spec/code/security reviewers
20
+ -> wave 2: M parallel implementers (depend on wave 1)
21
+ -> wave 2 review
22
+ -> verifier integration
23
+ -> closeout with context-master + memory-master
24
+ ```
25
+
26
+ Full organization model, span formula, Manager types, leaf condition, and synthesis protocol: [WF-MAX.md](Harness/WF-MAX.md).
27
+
28
+ Keep `Harness/tasks/<task-id>/PROGRESS.md#Heartbeat` current.
@@ -0,0 +1,95 @@
1
+ ---
2
+ name: wf-max
3
+ description: Use for /wf max or maximum parallelism. Three-tier CEO→Manager→Worker hierarchy with recursive depth, per-domain span caps, and leaf-condition stop rules.
4
+ ---
5
+
6
+ # WF Max
7
+
8
+ CEO → Managers → Workers. Scale to 1000 agents via recursive depth. Full spec: `Harness/WF-MAX.md`.
9
+
10
+ ## Load
11
+
12
+ - `Harness/WF-MAX.md` — organization model, span formula, wave orchestration
13
+ - `Harness/subagents.md` — agent roster, controller role
14
+ - `Harness/dispatch.md` — File claim, Concurrency group handoff fields
15
+ - `Harness/agent-workflow.md` — cohesion rule (feature doc < Worker granularity)
16
+
17
+ ## Organization
18
+
19
+ ```
20
+ CEO(1) → Managers(span) → Workers(leaf) or Sub-Managers(depth≥3)
21
+ ```
22
+
23
+ - CEO: intent, scope, integration, final verification.
24
+ - Manager: domain partition → parallel dispatch → synthesize → report.
25
+ - Worker: single file (write) or single dimension (read). File claims must be file-level disjoint.
26
+ - depth≥3: Manager spawns Sub-Manager (span≤7). No mixed Worker+Sub-Manager in same wave.
27
+
28
+ ## Span Formula
29
+
30
+ ```
31
+ span = min(ceil(sqrt(files)), domain_cap)
32
+ Architecture: 3
33
+ Implementation: 5-7
34
+ Review: 7-10
35
+ Research: 10-12
36
+ ```
37
+
38
+ ## Total Agents
39
+
40
+ ```
41
+ total(depth, span) = Σ span^L for L=0..depth
42
+ ```
43
+
44
+ No hard cap. Governed by leaf condition + overhead filter.
45
+
46
+ ## Leaf Condition
47
+
48
+ ```
49
+ stop if: files ≤ span×2 | avgLines < 50 | overhead > 0.30
50
+ ```
51
+
52
+ Overhead threshold: `overhead > 0.30 → degrade to /wf`
53
+
54
+ ## Manager Types (4)
55
+
56
+ | Type | Span | Workers |
57
+ |------|------|---------|
58
+ | Explore-Mgr | 5-10 | researcher₁..ₙ, domain-explorer₁..ₙ |
59
+ | Architect-Mgr | 3 | boundary-researcher, interface-designer, data-flow-mapper |
60
+ | Implement-Mgr | 5-7 | implementer₁..ₙ (1 file_claim/Worker) |
61
+ | Review-Mgr | 3-4 | reviewer-spec, reviewer-code, reviewer-security |
62
+
63
+ ## Manager Synthesis
64
+
65
+ ```
66
+ 1. COLLECT → 2. DEDUPLICATE → 3. CONFLICT (flag, no silent resolve) → 4. SYNTHESIZE → 5. REPORT
67
+ ```
68
+ Worker failure: retry 1× → absorb or escalate to CEO.
69
+
70
+ ## Wave Orchestration
71
+
72
+ ```
73
+ W0: Explore-Mgr → N parallel → synthesize → CEO
74
+ W1: Architect-Mgr → 3 parallel → boundary contract → CEO approval
75
+ W2: Implement-Mgr → write-set coloring → wave dispatch: N parallel → merge → CEO
76
+ W2R: Review-Mgr → 3-4 parallel → dedupe+severity → CEO assigns fixes
77
+ W3+: Dependent waves (repeat W2)
78
+ CLOSEOUT: CEO → context-master + memory-master (direct)
79
+ ```
80
+
81
+ ## When NOT to Use
82
+
83
+ - files <5 → /wf
84
+ - all changes share single interface → serial
85
+ - overhead > 30% → degrade
86
+
87
+ ## /wf vs /wf max
88
+
89
+ | | /wf | /wf max |
90
+ |---|-----|------|
91
+ | Organization | flat | CEO→Mgr→Worker (3-tier) |
92
+ | Span formula | none | sqrt(files) + domain cap |
93
+ | Recursive depth | 0 | 1-3 (scales to 1000) |
94
+ | Granularity floor | none | <50 lines no split |
95
+ | Context threshold | ~85% | ~70% |
@@ -11,7 +11,7 @@ Root entry for Claude Code. Keep this file short.
11
11
  - `Harness/README.md` is the task router. For every request, check `Harness/README.md#Load By Task`; if a row matches, read and follow those docs before acting.
12
12
  - `Harness/PROGRESS.md` is the global task index. Load at session start to see active task and task history.
13
13
  - If work spans more than one step, create a task capsule from `Harness/tasks/_template/` and update `Harness/tasks/<task-id>/PROGRESS.md`.
14
- - Use `/wf`, `wf-mode`, `wf mode`, `workflow mode`, `wk mode`, or `Harness/WF.md` for long, difficult, uncertain, multi-file, or repeated-failure work.
14
+ - Use `/wf`, `/wf max`, `wf-mode`, `wf mode`, `workflow mode`, `wk mode`, `Harness/WF.md`, or `Harness/WF-MAX.md` for long, difficult, uncertain, multi-file, or repeated-failure work.
15
15
  - Use `subagent-orchestrator` and `Harness/subagents.md` when coordinating multiple subagents.
16
16
  - Use `/wf update` to check for and apply scaffold updates from GitHub. See `.claude/skills/wf-update/SKILL.md`.
17
17
  - Subagents are readers and reporters. Only the main agent writes to `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md`.
@@ -30,6 +30,7 @@ Stack-specific agents can be added after the product shape is known.
30
30
  - [subagent-orchestrator](../.claude/skills/subagent-orchestrator/SKILL.md) — controller-led subagent orchestration, parallel read-only passes, review gates, and recovery handoffs.
31
31
  - [readme-optimizer](../.claude/skills/readme-optimizer/SKILL.md) — README preservation, append-only development sections, structured tables, and approved architecture diagrams.
32
32
  - [wf-update](../.claude/skills/wf-update/SKILL.md) — GitHub-based incremental harness update, checksum comparison, and safe in-place updates.
33
+ - [wf-max](../.claude/skills/wf-max/SKILL.md) — maximum-parallelism workflow: write-set coloring, wave dispatch, parallel review per dimension.
33
34
 
34
35
  Stack-specific skills can be added after the product shape is known.
35
36
 
@@ -46,6 +47,7 @@ Located under `.claude/rules/ecc/`, auto-loaded by the CC engine:
46
47
  - [Task directory](tasks/)
47
48
  - [Docs router](README.md)
48
49
  - [WF mode](WF.md)
50
+ - [WF Max mode](WF-MAX.md)
49
51
  - [0-1 lifecycle](lifecycle.md)
50
52
  - [Research protocol](research/README.md)
51
53
  - [Context loading protocol](context-loading.md)
@@ -51,7 +51,7 @@ Keywords are retrieval hints, not project facts.
51
51
 
52
52
  Load the matching row only. Add adjacent docs only when the loaded doc directly names them.
53
53
 
54
- Routing priority: if a request explicitly says `/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. `wf-mode` MUST then delegate subagent coordination to `subagent-orchestrator`.
54
+ Routing priority: if a request explicitly says `/wf`, `/wf max`, `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. `wf-mode` MUST then delegate subagent coordination to `subagent-orchestrator`.
55
55
 
56
56
  | When to Read | Keywords | Load | Output |
57
57
  | --- | --- | --- | --- |
@@ -60,6 +60,7 @@ Routing priority: if a request explicitly says `/wf`, `wf mode`, `workflow mode`
60
60
  | Need MVP/spec | PRD, MVP, scope, requirement, acceptance, non-goal | [research/PRD.md](research/PRD.md) | one-page PRD with verifiable acceptance criteria |
61
61
  | Need architecture or boundaries | architecture, boundary, layer, domain, port, adapter, dependency | [architecture.md](architecture.md), [domain/ports.md](domain/ports.md) | layer map, ports, constraints |
62
62
  | Need WF mode | 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 |
63
+ | Need WF Max mode | /wf max, wf max, maximum parallelism, max parallel | [WF-MAX.md](WF-MAX.md), [WF.md](WF.md), [subagents.md](subagents.md), [dispatch.md](dispatch.md) | max-parallel exploration, write-set coloring, wave dispatch |
63
64
  | 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 |
64
65
  | README optimization | README, docs, quickstart, install docs, architecture diagram, command table, documentation polish | root `README.md`, `.claude/skills/readme-optimizer/SKILL.md`, [PROGRESS.md](PROGRESS.md), [architecture.md](architecture.md) as needed | approved README mode, preserved sections, proposed diff plan |
65
66
  | 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) | tasks, write set, verification commands |
@@ -88,6 +89,7 @@ Routing priority: if a request explicitly says `/wf`, `wf mode`, `workflow mode`
88
89
  - Do not run writing agents in parallel unless write sets are disjoint.
89
90
  - Before coordinating multiple agents, fill `Harness/tasks/<task-id>/PLAN.md#Subagent Dispatch` and follow `subagents.md` plus `dispatch.md`; if the work also matches WF triggers, enter WF mode first.
90
91
  - In WF mode, update `Harness/tasks/<task-id>/PROGRESS.md#Heartbeat` before long commands, after failures, and at closeout.
92
+ - In WF Max mode, never dispatch two implementers with overlapping file claims. Verify disjointness before each wave.
91
93
  - Do not add stack-specific agents or skills without following `extension.md`.
92
94
  - Do not close work without tests or recorded manual verification.
93
95
  - 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.
@@ -104,6 +106,9 @@ Harness/tasks/<id>/PROGRESS.md per-task progress, phase, heartbeat
104
106
  Harness/tasks/<id>/PLAN.md per-task implementation plan and evidence
105
107
  Harness/tasks/_template/ task capsule template (copy to create new task)
106
108
  Harness/WF.md long-task workflow and recovery loop
109
+ Harness/WF-MAX.md max-parallelism workflow with wave dispatch
110
+ .claude/skills/wf-max/SKILL.md max-parallelism skill loader
111
+ .claude/commands/wf-max.md /wf max slash command bridge
107
112
  Harness/lifecycle.md 0-1 product flow
108
113
  Harness/subagents.md controller-led subagent orchestration
109
114
  Harness/context-loading.md dynamic loading and subagent packs
@@ -0,0 +1,134 @@
1
+ # WF-MAX — Maximum Parallelism Workflow
2
+
3
+ ## Trigger
4
+
5
+ - Explicit: `/wf max`
6
+ - Auto: WF task with write-set ≥5 files AND clear disjoint boundaries
7
+ - parallelismScore = (files × avgLines × 3 / 800) × independenceFactor
8
+ - spawn ≥2.0 | maybe 1.0-2.0 | skip <1.0 (degrade to /wf)
9
+
10
+ ## Companion Docs
11
+
12
+ - [subagents.md](subagents.md) — agent roster, controller role, efficiency ladder
13
+ - [dispatch.md](dispatch.md) — handoff format, File claim, Concurrency group fields
14
+ - [agent-workflow.md](agent-workflow.md) — build/test/review loop, cohesion rule, completion gate
15
+
16
+ ## Organization Model
17
+
18
+ ```
19
+ CEO(1) ──┬── Manager₁(span) ──┬── Worker₁..ₙ
20
+ │ └── Sub-Manager(span) → Worker₁..ₙ [depth ≥3]
21
+ └── Manager₂(span) ── Worker₁..ₙ
22
+ ```
23
+
24
+ - CEO: intent, scope, integration, final verification. Direct reports 3-5 Managers.
25
+ - Manager: domain partition → parallel dispatch → synthesize → report. Serial across domains; parallel within domain.
26
+ - Worker: single file per write Worker (implementer, one file_claim). Single dimension/topic per read Worker (reviewer, researcher). File claims must be file-level disjoint. Topic-level splitting within a single file is only allowed for read-only Workers.
27
+ - depth ≥3: Manager spawns Sub-Manager (span ≤7) instead of Worker. Recursive until leaf condition met.
28
+
29
+ ## Span Formula
30
+
31
+ ```
32
+ span = min(ceil(sqrt(files)), domain_cap)
33
+ Architecture: cap = 3
34
+ Implementation: cap = 5-7
35
+ Review: cap = 7-10
36
+ Research: cap = 10-12
37
+ ```
38
+
39
+ ## Total Agents (recursive, scales to 1000)
40
+
41
+ ```
42
+ total(depth, span) = Σ span^L for L=0..depth
43
+ ```
44
+
45
+ - depth=0: CEO + Workers only (XS)
46
+ - depth=1: CEO + Managers + Workers
47
+ - depth=2: CEO + Managers + Workers
48
+ - depth≥3: CEO + Managers + Sub-Managers + Workers (recursive)
49
+ - no hard agent cap; recursion governed by leaf condition + overhead filter
50
+
51
+ ## Sizing Table
52
+
53
+ | Scale | Files | Depth | CEO | Mgrs | Workers | Total |
54
+ |-------|---------|-------|-----|------|---------|-------|
55
+ | XS | 1-4 | 0 | 1 | 0 | 1-3 | 2-4 |
56
+ | S | 5-12 | 1 | 1 | 2 | 6 | 9 |
57
+ | M | 13-30 | 1 | 1 | 3 | 15 | 19 |
58
+ | L | 31-60 | 2 | 1 | 5 | 35 | 41 |
59
+ | XL | 61-200 | 2 | 1 | 7 | 49 | 57 |
60
+ | XXL | 201-500 | 3 | 1 | 7 | 343 | 351 |
61
+ | XXXL | 501-1000| 3 | 1 | 7 | 686 | 694 |
62
+
63
+ - depth≥3: Managers spawn Sub-Managers (span≤7). No mixed Worker+Sub-Manager dispatch in same wave.
64
+
65
+ ## Leaf Condition (stop splitting)
66
+
67
+ - files ≤ span×2
68
+ - OR avgLines < 50
69
+ - OR overhead > 0.30 (degrade to /wf)
70
+
71
+ ## Manager Types (4)
72
+
73
+ | Type | Trigger | Span | Worker Roles |
74
+ |---------------|-------------------------------|------|---------------------------------------------------------------|
75
+ | Architect-Mgr | cross-file interfaces, new ports | 3 | boundary-researcher, interface-designer, data-flow-mapper |
76
+ | Implement-Mgr | write-set defined | 5-7 | implementer₁..ₙ (1 file_claim each) |
77
+ | Review-Mgr | implementation wave complete | 3-4 | reviewer-spec, reviewer-code, reviewer-security |
78
+ | Explore-Mgr | L+ project, uncertain scope | 5-10 | researcher₁..ₙ, domain-explorer₁..ₙ |
79
+
80
+ ## Manager Synthesis Protocol
81
+
82
+ ```
83
+ 1. COLLECT → await all Worker returns
84
+ 2. DEDUPLICATE → dedupe, merge overlap
85
+ 3. CONFLICT → flag contradictions (file_claim overlap, interface mismatch); no silent resolve
86
+ 4. SYNTHESIZE → single integrated artifact
87
+ 5. REPORT → CEO-actionable synthesis + raw Worker returns (audit)
88
+ ```
89
+
90
+ - Worker failure: retry 1× → on 2nd failure, Manager absorbs or escalates to CEO for replan.
91
+
92
+ ## Wave Orchestration
93
+
94
+ ```
95
+ W0: Explore-Mgr → N parallel researchers → synthesize → CEO
96
+ W1: Architect-Mgr → 3 parallel → boundary decisions + interface contract → CEO approval
97
+ W2: Implement-Mgr → write-set coloring → wave dispatch: N parallel implementers (disjoint file_claims) → merge → CEO
98
+ W2R: Review-Mgr → 3-4 parallel reviewers → dedupe + severity → CEO assigns fixes
99
+ W3+: Dependent implementation waves (repeat W2 pattern)
100
+ INTEGRATION: CEO → verifier → fail → debugger → loop (cap=3)
101
+ CLOSEOUT: CEO → context-master + memory-master (direct, no Manager)
102
+ ```
103
+
104
+ - Wave scheduling: Managers serial across domains, Workers parallel within domain.
105
+ - CEO validates wave output before starting next wave. No pipelining.
106
+
107
+ ## Overhead & Cost Filter
108
+
109
+ ```
110
+ overhead(depth) = 0.10 (depth≤2) | 0.20 (depth=3) | 0.35 (depth≥4)
111
+ ```
112
+
113
+ - overhead > 0.30 → degrade to /wf
114
+ - independenceFactor: 1.0 (no deps) | 0.3-0.7 (shared imports)
115
+
116
+ ## When NOT to use /wf max
117
+
118
+ - files < 5 → use /wf
119
+ - all changes share single interface → serial dependency
120
+ - import/re-export refactor → global consistency required
121
+ - communication overhead > 30% → degrade
122
+
123
+ ## /wf vs /wf max
124
+
125
+ | Dimension | /wf | /wf max |
126
+ |------------------|------------------|----------------------------------|
127
+ | Organization | flat | CEO → Mgr → Worker (3-tier) |
128
+ | Exploration | 3-5 serial | Mgr → 10 parallel |
129
+ | Implementation | 1 serial | Mgr → N parallel (span 5-7) |
130
+ | Review | 1-2 serial gate | Mgr → 3-4 parallel dimensions |
131
+ | Span formula | none | sqrt(files) + domain cap |
132
+ | Recursive depth | 0 | 1-3 (scales to 1000 agents) |
133
+ | Context threshold| ~85% | ~70% |
134
+ | Granularity floor| none | <50 lines → no split |
@@ -13,6 +13,7 @@ Enter WF mode when any of these are true:
13
13
  - The task needs research, architecture judgment, browser/API validation, or migration planning.
14
14
  - Confidence in intent, architecture, or implementation is below 95%.
15
15
  - The same command, test, tool, or approach fails twice.
16
+ - The user explicitly says `/wf max` or `wf max` (for maximum-parallelism mode, see [WF-MAX.md](WF-MAX.md)).
16
17
 
17
18
  ## Multi-Subagent Requirement
18
19
 
@@ -24,6 +25,8 @@ WF mode requires multi-subagent orchestration by default.
24
25
  - Record every dispatch or bounded-pass fallback in `Harness/tasks/<task-id>/PLAN.md#Subagent Dispatch`.
25
26
  - If subagents are unavailable, emulate the same roles as separate bounded passes and record why the fallback was used.
26
27
 
28
+ For maximum-parallelism mode (write-set coloring, wave dispatch, parallel reviewers), use `/wf max` and see [WF-MAX.md](WF-MAX.md).
29
+
27
30
  ## WF Loop
28
31
 
29
32
  ```text
@@ -68,7 +68,7 @@ Rules:
68
68
 
69
69
  ## Parallel Dispatch
70
70
 
71
- Use [subagents.md](subagents.md) and [dispatch.md](dispatch.md) for multi-agent work. Default to at most three active agents (WF mode overrides this; see [WF.md](WF.md)). Prefer parallel read-only work first, then serial writes.
71
+ Use [subagents.md](subagents.md) and [dispatch.md](dispatch.md) for multi-agent work. Default to at most three active agents (WF mode overrides this; see [WF.md](WF.md)). In `/wf max`, the CEO/Manager/Worker hierarchy in [WF-MAX.md](WF-MAX.md) overrides this limit entirely with wave-based parallel dispatch. Prefer parallel read-only work first, then serial writes.
72
72
 
73
73
  Every dispatched agent returns the handoff format defined in [dispatch.md](dispatch.md).
74
74
 
@@ -65,6 +65,7 @@ Goal
65
65
  - If two write sets overlap, do not run those agents in parallel.
66
66
  - If an agent returns uncertainty, mark the row `Blocked` or add a follow-up row.
67
67
  - If docs, tests, and code disagree, stop implementation and record the conflict in `Harness/tasks/<task-id>/PROGRESS.md`.
68
+ - In /wf max, file claims must respect WF-MAX.md leaf condition: no split below 50 avgLines, no split when files ≤ span×2.
68
69
 
69
70
  ## Handoff Format
70
71
 
@@ -81,6 +82,9 @@ Evidence:
81
82
  Risks:
82
83
  Next:
83
84
  PLAN patch:
85
+ Concurrency group: <wave number — 0=exploration, 1,2,3,...=implementation waves. Optional; only used in /wf max.>
86
+ File claim: <list of exact file paths this agent exclusively owns. Optional; only used in /wf max.>
87
+ Granularity floor: <50 avgLines → do NOT spawn. Apply leaf condition from WF-MAX.md.>
84
88
  ```
85
89
 
86
90
  Use `Files changed: none` for read-only agents. Use `PLAN patch: none` when no state update is needed.
@@ -85,6 +85,7 @@ Choose the cheapest coordination level that is safe.
85
85
  | Parallel read-only | broad reading, research, architecture, multiple independent failures | 2-3 read-only agents |
86
86
  | Serial build lane | normal feature or fix | test-writer -> implementer -> reviewers -> verifier |
87
87
  | Isolated lanes | disjoint write sets or competing approaches | separate worktrees, then review and merge |
88
+ | Max parallelism | 5+ disjoint files, fan-out benefit > coordination cost | /wf max: write-set coloring -> wave dispatch -> parallel review |
88
89
 
89
90
  Default for automatic WF triggers: 3-5 active read-only agents before second planning. For explicit WF/WK mode, never use the solo pass unless subagents are unavailable; use bounded role passes as the recorded fallback.
90
91
 
@@ -106,6 +107,18 @@ controller intake
106
107
 
107
108
  Use this shape for `/wf`, long tasks, multi-file changes, architecture work, migrations, browser/API behavior, or repeated failures.
108
109
 
110
+ ```text
111
+ /wf max orchestration shape:
112
+ controller intake
113
+ -> wave 0: max-parallel exploration (4-14 read-only agents)
114
+ -> controller synthesis: dependency graph + write-set coloring
115
+ -> wave 1: N parallel implementers (disjoint file claims)
116
+ -> wave 1 review: parallel spec/code/security reviewers
117
+ -> wave 2+: dependent implementers (if any)
118
+ -> integration verifier
119
+ -> closeout with evidence
120
+ ```
121
+
109
122
  ## Dispatch Pack
110
123
 
111
124
  Every subagent dispatch must be self-contained:
@@ -37,6 +37,7 @@ const commonSkills = [
37
37
  'harness-build-loop',
38
38
  'wf-mode',
39
39
  'wf-update',
40
+ 'wf-max',
40
41
  'subagent-orchestrator',
41
42
  'readme-optimizer',
42
43
  ];
@@ -53,9 +54,11 @@ const required = [
53
54
  'README.md',
54
55
  'Harness/MEMORY.md',
55
56
  'Harness/WF.md',
57
+ 'Harness/WF-MAX.md',
56
58
  ...memoryFiles,
57
59
  '.claude/settings.json',
58
60
  '.claude/commands/wf.md',
61
+ '.claude/commands/wf-max.md',
59
62
  '.claude/rules/ecc/common.md',
60
63
  ...commonAgents.map(agent => `.claude/agents/${agent}.md`),
61
64
  ...commonSkills.map(skill => `.claude/skills/${skill}/SKILL.md`),
@@ -436,6 +439,14 @@ requireText('Harness/architecture.md', 'Avoid speculative abstraction', 'anti-ov
436
439
  requireText('CLAUDE.md', 'Use explicit interfaces or state models only when they protect a real boundary', 'CLAUDE interface/state simplicity rule');
437
440
  requireText('CLAUDE.md', '/wf update', 'wf update startup instruction');
438
441
  requireText('Harness/README.md', 'Need harness update', 'update routing row');
442
+ requireText('Harness/WF-MAX.md', 'write-set coloring', 'WF-MAX coloring algorithm');
443
+ requireText('Harness/WF-MAX.md', 'wave dispatch', 'WF-MAX wave dispatch');
444
+ requireText('Harness/README.md', '/wf max', 'wf max router alias');
445
+ requireText('Harness/README.md', 'WF-MAX.md', 'WF-MAX router reference');
446
+ requireText('Harness/subagents.md', 'Max parallelism', 'subagents max parallelism row');
447
+ requireText('Harness/dispatch.md', 'Concurrency group', 'dispatch concurrency group field');
448
+ requireText('Harness/dispatch.md', 'File claim', 'dispatch file claim field');
449
+ requireText('CLAUDE.md', '/wf max', 'wf max startup instruction');
439
450
 
440
451
  if (errors.length) {
441
452
  console.error(`Harness validation failed${strict ? ' (strict)' : ''}:`);