create-dwy 0.15.0 → 0.16.0

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-commercial/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: dwy-commercial
+description: "【dwy·商业分析】产品 0 到 1 立项阶段（闸1 之后）。触发场景：用户说『商业分析 / 商业模式 / 怎么赚钱 / 变现 / 定价 / 单位经济 / CAC/LTV / GTM 获客 / 商业可行性 / commercial』，要在需求验证后判断商业模式跑不跑得通、能不能赚钱时。startup（创业/产品）模式下是硬闸门：商业不可行即停流程；builder（练手/学习）模式跳过不挡流程。"
+---
+
+## 职责（单一）
+盘商业模式 + 变现路径 + 定价 + 单位经济 + GTM 获客，给商业可行性 **pass/fail** 结论。**startup 模式硬闸门**：过不了流程停，不进闸 2（POC）。**builder 模式跳过**：读 `confirmed.idea.mode`，builder 直接回 skipped、不挡流程、不产出。
+
+## 输入（从哪读）
+- state.json 的 `confirmed.idea`（含 `mode` = startup/builder、`target_user`、`narrowest_wedge`、`value_prop`、`key_assumptions`——变现与定价对着这个人和这点切入定）
+- state.json 的 `confirmed.competitors`（竞品定价、现有变现方式对着它定差异化）
+- `.dwy/prod/[项目]/01-立项/想法收敛.md`、`竞品分析.md`、`需求市场验证.md`
+
+## 模式分流（开工第一步）
+读 `confirmed.idea.mode`：
+- **builder**（练手 / 学习 / 开源 / hackathon / 纯兴趣）→ 不逼商业，回写 `confirmed.commercial = { mode: "builder", pass: true, skipped: true, reason: "builder 模式不评估商业可行性" }`，不产出文件、不挡流程，直接放行进闸 2
+- **startup**（奔着有人用、可能收钱、要做成产品）→ 走下面完整商业分析
+
+## 实现
+[包装型] 用全局本地 skill（位于 `~/.dwy/skills/<外部skill名>/`）：
+读其 `SKILL.md`（及同目录 scripts/、配套 .md），按它的方式与用户交互/提问，产出按下方「产出契约」落地。
+- **提问形式（Claude Code 下强制）**：借用外部 skill 的「问什么、怎么一步步收敛」方法论，但**每个要用户选择/拍板的问题用 `AskUserQuestion` 工具弹点选卡片**，不在正文列 A/B/C/D 让用户打字；保留「一次一问、答完再问下一个」的节奏，开放式补充靠卡片的「Other」兜底。其他工具（Codex 等无此组件）退回外部 skill 原生的正文问答。
+- 本 skill 依赖的外部 skill（各对应 `~/.dwy/skills/<名>/`）：
+  - `startup-canvas` — 整体盘点（战略 9 节 + 商业模式 2 节），作为引子框架，先跑它把商业全貌摸一遍
+  - `business-model` — 商业模式画布 9 模块（详细展开成本结构 / 收入流）
+  - `monetization-strategy` — 3-5 个变现方案（含 CAC/LTV/回本/毛利单位经济 + 低成本验证实验）
+  - `pricing-strategy` — 定价模型选型 + 分层 + 价值计量 + 价格敏感度
+  - `porters-five-forces` — 赛道竞争结构（补「赛道」维度，判断利润空间是否被结构压扁）
+  - `gtm-strategy` — 首批用户从哪来、渠道、获客成本估算、90 天路线
+- 若 `~/.dwy/skills/<名>/` 不存在：提示用户先跑 `dwy skills install`（或 `dwy claude sync` 会自动装），不要自己用内置能力顶替。
+
+### 推荐跑法（顺序，可按上下文跳）
+1. `startup-canvas` 先出整体画布（摸商业全貌 + 战略一致性）
+2. `monetization-strategy` 出 3-5 个变现方案 + 各自单位经济 → 用户选 1-2 个主攻
+3. `pricing-strategy` 对选定方案细化定价
+4. `porters-five-forces` 判赛道结构是否压扁利润（利润空间 → 可行性）
+5. `gtm-strategy` 出首批获客路径
+6. 综合给可行性结论（pass/fail）
+
+### 可行性判据（pass/fail 怎么判）
+startup 模式给 pass 至少满足：
+- 能讲通一条**具体变现路径**（不是「以后可以收钱」）
+- 单位经济估算**合理**：LTV/CAC ≥ 3（或能说清到达该值的路径），毛利率不为负
+- 有**低成本验证实验**可证伪付费意愿（落地页/预售/访谈愿付价）
+- `porters-five-forces` 没暴露致命结构（如：供方垄断 + 买方集中 + 无差异化壁垒 → 利润被压扁）
+四条任一明显不成立 → fail，写清哪条挂了、缺什么证据。
+
+## 产出契约（硬约束）
+- 落到：`.dwy/prod/[项目]/01-立项/商业分析.md`
+- 固定章节：
+  - 商业模式画布（9 模块 或 startup-canvas 摘要）
+  - 变现路径（3-5 个方案，每个含：怎么收钱 + 单位经济 CAC/LTV/毛利率/回本周期估算 + 风险；**标注用户主攻的 1-2 个**）
+  - 定价策略（模型选型 + 2-4 层分层 + 价值计量 + 价格敏感度判断）
+  - 赛道结构（波特五力摘要 + 利润空间判断）
+  - GTM 获客路径（首批用户来源 + 渠道 + 获客成本估算 + 90 天动作）
+  - **可行性结论 pass/fail**（含理由 + 必须先验证的关键假设 + 对应低成本实验）
+- 回写 state.json：`confirmed.commercial`（含 `mode`、`pass` 布尔、`skipped` 布尔、`monetization` 主攻方案、`unit_economics` 关键数字、`gtm` 首批渠道）
+- **startup 模式 fail 时流程必须中断**，不进闸 2（POC）；builder 模式不写 fail

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-competitor/SKILL.md

@@ -7,12 +7,13 @@ description: "【dwy·竞品分析】产品 0 到 1 立项阶段。触发场景
 盘点已有竞品 + 估算市场规模，找出差异化切入点。
 
 ## 输入（从哪读）
-- state.json 的 `confirmed.idea`
+- state.json 的 `confirmed.idea`（含 explore 逼出的具体目标人 target_user、最窄切入 narrowest_wedge——差异化对着这个人定）
 - `.dwy/prod/[项目]/01-立项/想法收敛.md`
 
 ## 实现
 [包装型] 用全局本地 skill（位于 `~/.dwy/skills/<外部skill名>/`）：
 读其 `SKILL.md`（及同目录 scripts/、配套 .md），按它的方式与用户交互/提问，产出按下方「产出契约」落地。
+- **提问形式（Claude Code 下强制）**：借用外部 skill 的「问什么、怎么一步步收敛」方法论，但**每个要用户选择/拍板的问题用 `AskUserQuestion` 工具弹点选卡片**，不在正文列 A/B/C/D 让用户打字；保留「一次一问、答完再问下一个」的节奏，开放式补充靠卡片的「Other」兜底。其他工具（Codex 等无此组件）退回外部 skill 原生的正文问答。
 - 本 skill 依赖的外部 skill：`competitor-analysis`、`market-sizing`（各对应 `~/.dwy/skills/<名>/`）
 - 若 `~/.dwy/skills/<名>/` 不存在：提示用户先跑 `dwy skills install`（或 `dwy claude sync` 会自动装），不要自己用内置能力顶替。
 

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-explore/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: dwy-explore
+description: "【dwy·想法探索收敛】产品 0 到 1 立项第一步，帮『想做但还不清楚』的人想清楚做什么、值不值得做，并收敛成结构化想法定义。触发场景：用户说『我想做个东西 / 有个想法但不清楚 / 帮我想想做什么 / 这个值不值得做 / 想做但没想好 / 想法收敛 / explore / ideate』，在还没想清楚要做什么、写任何代码或文档之前。借鉴 YC office-hours 的 forcing questions 方法论（自写，无外部依赖）。"
+---
+
+## 职责（单一）
+立项第一步，一次干完两件事：① 用 YC 式 forcing questions 逼用户把模糊想法想清楚（做什么、给谁、值不值、最窄切入）；② 把想清楚的结论**收敛成结构化的产品想法定义**。"想不清楚或不值得"的想法在这里就被劝退，想清楚的直接产出可供下游用的 `confirmed.idea`。
+
+## 输入（从哪读）
+- 用户口述的模糊想法（立项最前端，无上游产出）
+
+## 实现（自写，内化方法论）
+
+借鉴 gstack 的 office-hours（Garry Tan / YC，MIT），把它的 forcing questions 方法论内化到这里。**不装 gstack、不依赖任何外部 skill**。
+
+### 提问形式（Claude Code 下强制）
+- 每个问题用 `AskUserQuestion` 工具弹点选卡片，**一次只问一个**，答完再问下一个，不在正文列 A/B/C/D 让用户打字。
+- 开放式补充靠卡片的「Other」兜底。
+- 其他工具（Codex 等无此组件）退回正文逐问。
+
+### 第一步：判模式
+先判断用户在做什么，决定走哪条线：
+- **创业/产品线（startup）**：奔着有人用、可能收钱、要做成产品 → 走六个 forcing questions
+- **Builder 线**：练手 / 学习 / 开源 / hackathon / 纯兴趣 → **不逼商业**，走轻量设计思维 brainstorm（帮想清楚要做成什么样、技术怎么选、范围多大），跳过下面六问
+
+### 六个 forcing questions（startup 线，一次一问）
+逐个问，**追问到答案具体、有证据、让人不舒服为止**。舒服 = 没想够深。
+
+- **Q1 需求真实性**：「最强的证据是什么——证明真有人要这个？不是『感兴趣』、不是 waitlist，而是没了会抓狂、要重新凑合。」
+  - 逼到：具体行为、有人付钱、有人扩大使用、有人把工作流搭在上面。
+  - 红旗：「大家说有意思」「攒了 500 个 waitlist」「VC 看好这赛道」——这些都不是需求。
+  - 追问后还要查：关键词有没有定义清楚（「AI 化」「无缝体验」要能量化）？藏了什么没验证的假设？是真痛点还是脑补（「我觉得开发者会想要」是假设，「我前公司三个开发者每周花 10 小时干这个」是真的）。
+- **Q2 现状替代**：「用户现在怎么凑合解决这个问题——哪怕很烂？这个凑合花他多少时间/钱？」
+  - 逼到：具体工作流、花的小时数、浪费的钱、拼凑的工具、专门雇人手工做。
+  - 红旗：「现在没方案，所以机会大」——真没人凑合，往往是痛点不够痛、不值得行动。
+- **Q3 极致具体**：「点名最需要它的那个**具体的人**。什么头衔？什么让他升职、什么让他被开、什么让他失眠？」
+  - 逼到：一个名字、一个角色、一个不解决会面临的具体后果，最好是亲耳从那人嘴里听到的。
+  - 红旗：类别级答案——「医疗企业」「中小公司」「营销团队」。类别不是人，你没法给一个类别发邮件。
+  - B2B 说职业影响、消费品说日常痛点/社交时刻、个人/开源说被解锁的周末项目——后果要贴合领域，但绝不能停在「用户」「产品经理」。
+- **Q4 最窄切入**：「本周就有人肯付真钱的最小版本是什么？不是建完整个平台之后。」
+  - 逼到：一个功能、一个工作流，可能简单到一封周报邮件或一个自动化。能在几天内发出去、有人愿意付。
+  - 红旗：「得先建完整平台才能用」「砍了就没差异化了」——这是迷恋架构、不是迷恋价值。
+  - 加问：「如果用户什么都不用做就能拿到价值——不登录、不集成、不配置——会是什么样？」
+- **Q5 观察意外**：「你真坐下来看过别人用、且没在旁边帮忙吗？他做了什么让你意外的？」
+  - 逼到：一个具体的意外，用户做了违背你假设的事。没有意外 = 要么没看、要么没在意。
+  - 红旗：「发了问卷」「做了几个 demo 电话」「没啥意外，符合预期」——问卷会撒谎、demo 是表演、「符合预期」= 被既有假设过滤了。
+  - 金矿：用户拿产品干了它没被设计来干的事——那常是真正的产品在冒头。
+- **Q6 未来契合**：「3 年后世界明显不同了（一定会），你的产品变更必需、还是更没用？」
+  - 逼到：关于用户世界如何变、为什么这个变化让产品更有价值的具体主张。
+  - 红旗：「市场每年涨 20%」（增长率不是愿景）、「AI 越来越好我们就越好」（每个对手都能这么说的水涨船高论）。
+
+### Smart routing（按阶段只问相关的，不是每次六问全砸）
+- 纯想法 / 还没产品 → Q1, Q2, Q3
+- 已有用户 → Q2, Q4, Q5
+- 已有付费客户 → Q4, Q5, Q6
+- 纯工程 / 基建 → Q2, Q4
+- 内部项目（intrapreneurship）→ Q4 改问「让你 VP/赞助人点头的最小 demo 是什么」，Q6 改问「换个领导/重组后它还活得下来吗」
+- 前面答案已覆盖后面的问题 → 跳过，只问还不清楚的
+
+### Anti-sycophancy（不拍马屁，硬性）
+- 好答案 → 点名哪里好，**立刻换更狠的追问**，不停留。最好的奖励是下一个更难的问题。
+- 答案模糊 → 先重述帮用户看清「我理解你其实想做的是 X，对吗」，再逼具体，别耗 10 分钟。
+- 用户不耐烦（「别问了直接做」）→ 说「硬问题才是价值，跳过等于不考试直接开药。再问两个最关键的就走」，按该阶段 routing 挑最关键的 2 个，问完直接进结论。第二次还推 → 尊重，立即进结论，不问第三次。
+- 只有用户给出完整方案 + 真证据（现有用户/收入数字/具体客户名）才允许全跳，但仍要给出结论。
+
+## 问运行模式（idea 收敛后，需求讨论完的点）
+idea 收敛、放行进竞品分析前，**问一次运行模式**（`AskUserQuestion`：`standard` 逐步推进、每阶段我介入确认 / `auto` 全自动跑到底、AI 自主决策最后出结果，适合 demo）。写回 `state.json` 顶层 `run_mode`。
+- 这是**运行模式**（怎么跑），区别于本 skill 判的 `confirmed.idea.mode`（startup/builder **产品类型**），两者独立。
+- 后续总控阶段间询问 + 各 stage 内门控都读 `run_mode`；`auto` 下仍保留硬闸门（validate/poc/高风险不可逆）。
+
+## 产出契约（硬约束）
+- 落到：`.dwy/prod/[项目]/01-立项/想法收敛.md`
+- 固定章节（前半逼问纪要 + 后半结构化定义，一次产出）：
+  - 模式判定（startup / builder + 理由）
+  - 六问答案纪要（实际问了哪几个 + 用户答案 + 逼出的具体结论；builder 模式写设计思维结论）
+  - **核心问题**（一句话：这产品解决什么）
+  - **目标用户**（Q3 逼出的那个具体的人，不是类别）
+  - **价值主张**（为什么用户非用不可）
+  - **关键假设**（成立则产品成立的几条前提，供下游 validate 去验）
+  - **最窄切入**（Q4：本周就有人付钱的最小版本，供下游 mvp 砍范围）
+  - **边界与不做什么**
+  - 红旗与是否放行（触红旗的答案；想清楚 → 放行进竞品分析；想不清楚或明显不值 → 建议停下重想）
+- 回写 state.json：`confirmed.idea`（含产品类型 mode / 是否放行 pass + 上述结构化定义；原 exploration 的方向并入此字段，不另列）+ 顶层 `run_mode`（standard/auto）

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-mvp/SKILL.md

@@ -7,12 +7,13 @@ description: "【dwy·MVP定义】产品 0 到 1 立项阶段（闸3）。触发
 从想法+验证结果，收敛出第一版 MVP 功能清单。**功能硬上限 ≤7 个**，超出的进后续版本。
 
 ## 输入（从哪读）
-- state.json 的 `confirmed.idea`、`confirmed.validation`、`confirmed.poc`
+- state.json 的 `confirmed.idea`（含 explore 逼出的最窄切入 narrowest_wedge——MVP 砍 ≤7 直接对着它砍）、`confirmed.validation`、`confirmed.poc`
 - `.dwy/prod/[项目]/01-立项/想法收敛.md`、`需求市场验证.md`、`技术验证.md`
 
 ## 实现
 [包装型] 用全局本地 skill（位于 `~/.dwy/skills/<外部skill名>/`）：
 读其 `SKILL.md`（及同目录 scripts/、配套 .md），按它的方式与用户交互/提问，产出按下方「产出契约」落地。
+- **提问形式（Claude Code 下强制）**：借用外部 skill 的「问什么、怎么一步步收敛」方法论，但**每个要用户选择/拍板的问题用 `AskUserQuestion` 工具弹点选卡片**，不在正文列 A/B/C/D 让用户打字；保留「一次一问、答完再问下一个」的节奏，开放式补充靠卡片的「Other」兜底。其他工具（Codex 等无此组件）退回外部 skill 原生的正文问答。
 - 本 skill 依赖的外部 skill：`prioritize-features`、`opportunity-solution-tree`（各对应 `~/.dwy/skills/<名>/`）
 - 若 `~/.dwy/skills/<名>/` 不存在：提示用户先跑 `dwy skills install`（或 `dwy claude sync` 会自动装），不要自己用内置能力顶替。
 

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-prd/SKILL.md

@@ -13,6 +13,7 @@ description: "【dwy·PRD生成】产品 0 到 1 需求规划阶段。触发场
 ## 实现
 [包装型] 用全局本地 skill（位于 `~/.dwy/skills/<外部skill名>/`）：
 读其 `SKILL.md`（及同目录 scripts/、配套 .md），按它的方式与用户交互/提问，产出按下方「产出契约」落地。
+- **提问形式（Claude Code 下强制）**：借用外部 skill 的「问什么、怎么一步步收敛」方法论，但**每个要用户选择/拍板的问题用 `AskUserQuestion` 工具弹点选卡片**，不在正文列 A/B/C/D 让用户打字；保留「一次一问、答完再问下一个」的节奏，开放式补充靠卡片的「Other」兜底。其他工具（Codex 等无此组件）退回外部 skill 原生的正文问答。
 - 本 skill 依赖的外部 skill：`create-prd`（对应 `~/.dwy/skills/create-prd/`）
 - 若 `~/.dwy/skills/create-prd/` 不存在：提示用户先跑 `dwy skills install`（或 `dwy claude sync` 会自动装），不要自己用内置能力顶替。
 

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-product-launcher/SKILL.md

@@ -6,8 +6,10 @@ description: "【dwy·全流程总控】从模糊想法到上线产品的唯一
 ## 职责（总控·编排层）
 从模糊想法到产品的唯一入口。按顺序串 5 个阶段 skill，维护 state.json（进度 + 已确认结论），并做多版本子 Agent 编排。**不掺产出内容**，产出由阶段内原子 skill 落地。
 
-## 渐进式推进（核心交互）
-**不在入口预问"走到哪个阶段"。** 直接从立项第一步开始往下走，一步一步推进，每个阶段准出后问一句「继续下一步 / 到此为止」，由用户当场决定走不走。终点不预设——走一步看一步，用户随时可喊停。
+## 渐进式推进（核心交互，读 run_mode）
+**不在入口预问"走到哪个阶段"。** 直接从立项第一步开始往下走。`dwy-explore` 在 idea 收敛后会问一次 `run_mode`（standard/auto），之后推进节奏读它：
+- **standard**：每个阶段准出后问一句「继续下一步 / 到此为止」，用户当场决定。终点不预设、随时可喊停。
+- **auto**：阶段间不问，自动连跑到底、最后出结果；**仅硬闸门未过才停**（立项的 validate/poc、高风险不可逆操作）。
 
 ```
 开始 → dwy-stage-launch（立项·三闸门）
@@ -23,12 +25,12 @@ description: "【dwy·全流程总控】从模糊想法到上线产品的唯一
 
 规则：
 - **从第一步直接开始**，不让用户提前选终点
-- 每阶段准出后**只问"继不继续"**，不问"要走到哪"
-- 闸门内（立项的需求验证/POC）若没过，自动停在当前阶段，不往下走
+- standard 下每阶段准出后**只问"继不继续"**，不问"要走到哪"；auto 下不问、直接流转
+- 闸门内（立项的需求验证/POC）若没过，**无论 standard/auto 都自动停**在当前阶段，不往下走
 - 用户喊停时，已完成阶段的产出和 state.json 都已落盘，下次可断点续跑
 
 按序的五阶段：
-1. **dwy-stage-launch** — 立项（三闸门：需求验证 → POC → MVP）
+1. **dwy-stage-launch** — 立项（闸门：需求验证 → 商业可行性[startup 硬闸] → POC → MVP）
 2. **dwy-stage-prd** — 需求版本
 3. **dwy-stage-design** — 设计架构
 4. **dwy-stage-dev** — TDD 开发
@@ -36,20 +38,23 @@ description: "【dwy·全流程总控】从模糊想法到上线产品的唯一
 
 进度以 `state.json` 的 `current_stage` 为准；可从任意阶段断点续跑。
 
+## 读 state 先检 schema 版本（老项目升级入口）
+读到**已存在**的 `state.json` 时，**先检 `schema_version`**：缺失或低于当前（`"3"`）→ 按 `references/state-and-contract.md`「七、schema 版本与迁移」逐级迁移（v1→v2→v3），迁移后再续跑。这是老用户旧 state 无感升级的入口。
+
 ## 首次初始化（只建根，不建阶段目录）
 新项目首次进入时，**只**做两件最小事：
-- 建项目根目录 `.dwy/prod/[项目]/`（不建 01~04 任何阶段子目录）
-- 初始化 `state.json`
+- 建项目根目录 `.dwy/prod/[项目]/`（不建 01~05 任何阶段子目录）
+- 初始化 `state.json`（写 `schema_version = "3"`）
 
 产品产出 `.dwy/prod/[项目]/` 入库，无需改 `.gitignore`（外部 skill 在全局 `~/.dwy/skills/`，不落项目）。若包装型原子 skill 触发时 `~/.dwy/skills/<name>/` 不存在，提示用户先跑 `dwy skills install`。
 
-**阶段目录渐进式按需建**：`01-立项/` 进立项时才建，`02-需求规划/` 进需求阶段才建……不要一次把四个阶段目录全建出来（那不是渐进式）。state schema、各 skill 的 `confirmed.*` 字段契约、外部 skill 全局安装见 `references/state-and-contract.md`。
+**阶段目录渐进式按需建**：`01-立项/` 进立项时才建，`02-需求规划/` 进需求阶段才建……不要一次把五个阶段目录全建出来（那不是渐进式）。state schema、各 skill 的 `confirmed.*` 字段契约、外部 skill 全局安装见 `references/state-and-contract.md`。
 
 ## state.json（进度 + 结论）
 落 `.dwy/prod/[项目]/state.json`，含：
 - `current_stage` — 当前阶段
 - `current_version` — 当前版本（如 `V1.0`）
-- `confirmed.*` — 各原子的已确认结论引用（idea / competitors / validation / poc / mvp_features / prd / version_plan / tasks / prototype / architecture / dev_progress / acceptance / release）
+- `confirmed.*` — 各原子的已确认结论引用（idea / competitors / validation / commercial / poc / mvp_features / prd / version_plan / tasks / prototype / architecture / dev_progress / acceptance / release）
 - `versions` — 各版本状态（路线图 + 完成情况）
 
 ## 多版本编排逻辑

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-product-launcher/references/state-and-contract.md

@@ -4,15 +4,16 @@
 
 ## 一、产出与缓存目录（最终全貌，**渐进式按需创建**）
 
-下面是流程全部走完后的**目标结构**，不是初始化时一次建好的。**渐进式原则：每个阶段真正开始时，才创建它自己那一级目录和文件**——初始化只建项目根 + state.json，`01-立项/` 进立项才建，`02-需求规划/` 进需求阶段才建，以此类推。不要上来就把 01~04 四个阶段目录全建出来。
+下面是流程全部走完后的**目标结构**，不是初始化时一次建好的。**渐进式原则：每个阶段真正开始时，才创建它自己那一级目录和文件**——初始化只建项目根 + state.json，`01-立项/` 进立项才建，`02-需求规划/` 进需求阶段才建，以此类推。不要上来就把 01~05 五个阶段目录全建出来。
 
 ```
 .dwy/prod/
   [项目名]/                  # 产品产出，入库（git 跟踪）
     01-立项/
-      想法收敛.md
+      想法收敛.md           # dwy-explore：YC 6问逼清 + 收敛成结构化定义
       竞品分析.md
       需求市场验证.md         # 闸1·总闸门
+      商业分析.md            # 商业闸门·startup 硬闸（builder 跳过）
       技术验证.md            # 闸2
       poc/                  # 最小 POC 代码
       MVP清单.md            # 闸3·≤7
@@ -20,12 +21,14 @@
       PRD.md
       版本路线图.md
       开发任务拆解.md
-    03-设计与架构/
-      prototypes/           # dwy-whiteboard-prototype 白板 HTML
+    03-原型设计/
+      wireframe/            # dwy-prototype 第一轮：低保真线框初稿（静态 HTML，一页一图）
+      hifi/                 # dwy-prototype 第二轮：高保真平面图（静态 HTML，一页一图）
+    04-架构设计/
       技术架构.md
-      数据库设计.md
+      数据库设计.md          # 有后端时才出
       接口契约.md
-    04-上线交付/
+    05-上线交付/
       验收报告.md
       上架物料.md
       埋点与指标.md
@@ -48,41 +51,50 @@
 
 ```json
 {
+  "schema_version": "3",
   "version": "1.0",
   "project_name": "...",
   "current_stage": 1,
   "current_round": "stage1_round1",
+  "run_mode": "standard | auto",
   "confirmed": {
-    "idea": {},
+    "idea": { "mode": "startup | builder", "pass": true, "core_problem": "...", "target_user": "...", "value_prop": "...", "key_assumptions": [], "narrowest_wedge": "...", "boundaries": "..." },
     "competitors": {},
     "validation": { "pass": true, "evidence": "...", "method": "..." },
+    "commercial": { "mode": "startup | builder", "pass": true, "skipped": false, "monetization": "...", "unit_economics": {}, "gtm": "..." },
     "poc": { "pass": true, "deadlock": "...", "result": "..." },
     "mvp_features": [],
     "prd": {},
     "version_plan": {},
     "tasks": {},
+    "wireframe": {},
     "prototype": {},
     "architecture": {},
-    "dev_progress": { "<module>": "todo | done" },
+    "dev_progress": { "<module>": { "<task>": "todo | done" } },
     "acceptance": {},
     "release": {}
   }
 }
 ```
 
+- `schema_version` — **state 结构版本**，当前 `"3"`，升级破坏性结构时 bump（迁移见第七节）。
+- `version` — **产品版本**（用户 app 的 V1.0/V1.1 迭代号），与 schema_version 无关，别混。
+
 字段名是各 skill 的对外契约，**回写方与读取方必须用同一名字**：
 
 | 原子 skill | 回写字段 | 下游读取方 |
 |---|---|---|
-| dwy-ideate | confirmed.idea | dwy-competitor |
+| dwy-explore | confirmed.idea（逼问理清 + 收敛成结构化定义） | dwy-competitor（target_user/wedge 定位）+ dwy-validate（core_problem/assumptions 转定量）+ dwy-mvp（wedge 砍范围）+ dwy-prd |
 | dwy-competitor | confirmed.competitors | dwy-validate |
-| dwy-validate | confirmed.validation | dwy-poc（仅 pass=true 才执行） |
+| dwy-validate | confirmed.validation | dwy-commercial（仅 pass=true 才执行） + dwy-poc |
+| dwy-commercial | confirmed.commercial | dwy-poc（startup 模式仅 pass=true 或 skipped 才执行；builder 跳过） |
 | dwy-poc | confirmed.poc | dwy-mvp |
 | dwy-mvp | confirmed.mvp_features | dwy-stage-prd |
 | dwy-prd | confirmed.prd | dwy-version |
 | dwy-version | confirmed.version_plan | dwy-tasks / dwy-stage-design |
 | dwy-tasks | confirmed.tasks | dwy-stage-dev |
-| dwy-prototype | confirmed.prototype | — |
+| dwy-prototype（第一轮·线框初稿） | confirmed.wireframe | dwy-prototype 第二轮（基于线框升保真） |
+| dwy-prototype（第二轮·高保真平面图） | confirmed.prototype | dwy-architecture（原型定稿后才进架构） |
 | dwy-architecture | confirmed.architecture | dwy-stage-dev |
 | dwy-tdd-dev | confirmed.dev_progress | dwy-stage-ship |
 | dwy-acceptance | confirmed.acceptance | dwy-release |
@@ -90,7 +102,7 @@
 
 ## 四、外部 skill 全局安装 `~/.dwy/skills/`
 
-包装型原子 skill（dwy-ideate / dwy-competitor / dwy-validate / dwy-mvp / dwy-prd / dwy-version / dwy-tasks / dwy-tdd-dev / dwy-acceptance / dwy-release）依赖 pm-skills / superpowers 的外部 skill，装在**全局** `~/.dwy/skills/<name>/`：
+包装型原子 skill（dwy-competitor / dwy-validate / dwy-commercial / dwy-mvp / dwy-prd / dwy-version / dwy-tasks / dwy-tdd-dev / dwy-acceptance / dwy-release）依赖 pm-skills / superpowers 的外部 skill，装在**全局** `~/.dwy/skills/<name>/`：
 
 - 每个外部 skill 是**整个目录**（含 scripts/ 与配套 .md，不止 SKILL.md）
 - 由 cli 命令 `dwy skills install` 安装/更新（clone 两仓库的指定 stable tag → 搬整目录 + LICENSE → 写 `VERSIONS.json`）
@@ -98,6 +110,46 @@
 - 当前 stable：pm-skills **v2.0.0** | superpowers **v6.0.3**（升级改 cli 的 `skills-install.js` 清单 tag）
 - 原子 skill 运行时**只读** `~/.dwy/skills/<name>/`，缺失则提示用户先 `dwy skills install`，不自己拉、不降级
 
-## 五、断点续跑
+## 五、运行模式与流转（run_mode）
+
+`state.json` 顶层 `run_mode`，取值 `standard | auto`，由 `dwy-explore` 在 idea 收敛后问一次写入（区别于 `confirmed.idea.mode` 的 startup/builder **产品类型**，`run_mode` 是**怎么跑**）。总控与每个 `dwy-stage-*` 都读它：
+
+| run_mode | 阶段间 | stage 内门控（原型两轮 / PRD 确认等） | 硬闸门（validate 没人要 / poc 做不出 / 高风险不可逆） |
+|---|---|---|---|
+| `standard` | 每阶段准出后问「继续 / 停」 | 照常问用户 | 停 |
+| `auto` | 不问，自动连跑到底出结果 | 全部 AI 自动决策、不问 | **仍停**（auto 不绕硬闸门） |
+
+**流转规则**：每个 stage 准出 = 回写 `current_stage` + 按 `run_mode` 决定「问后流转」（standard）或「直接触发下一 `dwy-stage-*`」（auto）。总控 `dwy-product-launcher` 与单独触发某 stage **行为一致**，都走这套流转。最后一阶段 ship 无下游，正常结束。
+
+**stage 独立触发 + 上游补齐**：单独触发某 `dwy-stage-*` 时上游 `confirmed.*` 缺失 → 不报错，基于已聊上下文 + 现有产出文件**轻量补齐**够本阶段用的上游结论，写回对应 `confirmed.*` 标注「上下文补齐」。**安全边界**：可补产出文档/范围类（prd/version_plan/tasks/prototype/architecture/mvp_features 范围）；**禁止**凭空标硬闸门 `pass=true`（`validation`/`poc` 只能由 launch 真实跑出）。
+
+## 六、断点续跑
 
 会话中断后，总控读 `state.json` 的 `current_stage` + `current_round`，从中断处续跑。已确认字段不重做。
+
+## 七、schema 版本与迁移（单一来源）
+
+**当前 `schema_version = "3"`。** 缺失或 `< 3` = 老结构，**读 state 的 skill（总控 / 任一 stage）必须先迁移再继续**——这是老用户无感升级的唯一入口。迁移**逐级叠加**（v1 项目走 v1→v2→v3）。新建项目直接写 `schema_version = "3"`。
+
+### v1 → v2 迁移规则（AI 执行，幂等）
+老 state（无 `schema_version`，或 dev_progress 是平层）按序处理：
+
+1. **dev_progress 平层 → 嵌套**：`{"<module>": "todo|done"}` → `{"<module>": {"_legacy": "todo|done"}}`（旧模块整体视为一个已完成/待办任务占位；本版本新任务在该 module 下追加 `<task>`）
+2. **旧 prototypes/ 原型归档**：`prototypes/` 目录下的旧原型文件 → 移到 `prototypes/wireframe/`，在该目录 `index` 注明「旧版原型（可交互白板），仅历史保留」；旧 `confirmed.prototype` **保留**，但标注「旧版产物，新两轮（线框 → 高保真平面图）可按需重跑」
+3. **补 `confirmed.wireframe`**（若无）= 引用迁移后的 `prototypes/wireframe/`
+4. **补顶层 `run_mode`**（若无）= `"standard"`
+5. **写 `schema_version = "2"`**（继续走 v2→v3）
+6. 迁移完在 `09-开发日志.md` 记一行（迁移前版本 / 改了什么）
+
+### v2 → v3 迁移规则（AI 执行，幂等）
+v2 把原型与架构拆成独立平级阶段目录、上线交付目录顺延。`schema_version = "2"`（或 v1→v2 刚处理完）的项目按序处理：
+
+1. **原型目录独立**：`03-设计与架构/prototypes/wireframe|hifi/` → 移到 `03-原型设计/wireframe|hifi/`
+2. **架构文档独立**：`03-设计与架构/{技术架构,数据库设计,接口契约}.md` → 移到 `04-架构设计/`
+3. **上线交付顺延**：`04-上线交付/` 整体改名 `05-上线交付/`
+4. 删空的 `03-设计与架构/`
+5. **写 `schema_version = "3"`**
+6. 迁移完在 `09-开发日志.md` 记一行
+
+### 未来再升级
+bump `schema_version` + 在本节追加 `vN → vN+1` 规则；**旧规则保留**，以支持跨多版本逐级迁移（v1→v2→v3→…）。

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-prototype/SKILL.md

@@ -1,23 +1,42 @@
 ---
 name: dwy-prototype
-description: "【dwy·UI原型】产品 0 到 1 设计与架构阶段。触发场景：用户说『画原型 / 出原型 / 做 UI 原型 / 把页面画出来 / prototype』，要在写 UI 代码前把页面与交互流程画成白板原型时。"
+description: "【dwy·UI原型】产品 0 到 1 设计与架构阶段。触发场景：用户说『画原型 / 出原型 / 做 UI 原型 / 把页面画出来 / prototype』，要在写 UI 代码前把页面画成静态原型图时。两轮串行门控：先低保真线框初稿，用户讨论通过后再做高保真平面图，过了才进架构。"
 ---
 
 ## 职责（单一）
-把 PRD 的页面与交互画成白板 HTML 原型。**不重复造**，直接调用现有的 `dwy-whiteboard-prototype` skill。
+把 PRD 的页面画成**静态原型图**，两轮串行、每轮门控：**① 线框初稿（低保真）→ 用户讨论通过 → ② 高保真平面图 → 用户讨论通过**。
+
+两轮都是**静态、按页出图**，区别只在保真度——都不做可交互（无拖拽/缩放/连线/点击跳转），浏览器直接展示，速度优先。本流程不调用白板引擎，纯静态 HTML 自写。
 
 ## 输入（从哪读）
 - state.json 的 `confirmed.prd`、`confirmed.tasks`
 - `.dwy/prod/[项目]/02-需求规划/PRD.md`
 
-## 实现
-[自写型]
-1. 直接调用现有 skill `dwy-whiteboard-prototype`（位于 `skills/开发流程/dwy-whiteboard-prototype/`）
-2. 按其规范画白板：每页一个 HTML，状态全、跳转清
-3. **不另起炉灶手搓白板引擎**，复用其 `assets/template.html`
-4. 产出目录改为本阶段约定路径（见产出契约）
+## 判设备形态（两轮共用，先做）
+读 PRD/上下文判目标端，决定页面外框，**不写死尺寸**：
+- 移动端 → 套手机框（iOS 用 iPhone 逻辑尺寸如 390×844、鸿蒙用对应 vp）
+- 网页端 → 不套设备框，用浏览器视口比例
+- 平板 → 用平板真实比例
+
+## 第一轮·线框初稿（低保真静态）
+1. 一个页面一张**低保真静态线框图**：灰阶/占位块表达布局结构，重点让用户看**页面齐不齐、布局对不对、信息层级合不合理**，不纠结视觉、不上色、不做交互。
+2. 图标用占位（稳定图标库的字符或内联 SVG 占位），**不用 emoji** 作功能性图标。
+3. 每图带一句**用途说明** + 关键**边界**（空态/加载/错误等该页适用项），纯文字描述。
+4. 形式：静态 HTML，一页一文件 `<页面>.html` + 总览 `index.html`（平铺各页缩略，可点下钻到单页，仅此导航，无页面内交互）。设备外框按上面判得的形态（网页端不套框）。
+5. 产出：`.dwy/prod/[项目]/03-原型设计/wireframe/`
+6. **门控**：产出后向用户汇报线框覆盖情况，明确问「线框初稿是否通过，可进高保真？」。未通过按反馈改，改完再问。通过后回写 `confirmed.wireframe`。
+
+## 第二轮·高保真平面图（静态，一页一图）
+1. 前置校验 `confirmed.wireframe` 存在，否则报错提示先过线框初稿。
+2. **基于已定稿的线框逐页升保真**：保持线框确定的页面清单与布局，上真实色板/明暗调/真实图标（稳定图标库，不用 emoji）/真实文案。仍是静态、不做可交互。
+3. 配色按产品定位定（金融稳重 / 社交活泼 / 工具中性）；**反 AI 套路**：不堆渐变 blob、不用 emoji 功能图标、用语义色板、≤2 字体。
+4. **每图必带说明**：用途 + 关键交互说明（文字描述「点 X 去 Y」即可，不做可点跳转）+ 边界。
+5. 形式：静态 HTML，一页一文件 `<页面>.html` + 总览 `index.html`，浏览器直接展示。**速度优先**。
+6. 产出：`.dwy/prod/[项目]/03-原型设计/hifi/`
+7. **门控**：产出后汇报，问「高保真平面图是否通过，可进架构？」。通过后回写 `confirmed.prototype`。
 
 ## 产出契约（硬约束）
-- 落到：`.dwy/prod/[项目]/03-设计与架构/prototypes/`，每页一个 `<页面>-spec.html` + `index-spec.html` 总览
-- 固定要求：覆盖 PRD 所有页面、状态全、跨白板跳转清
-- 回写 state.json：`confirmed.prototype`
+- 两轮目录分开：`03-原型设计/wireframe/` 与 `03-原型设计/hifi/`，各含每页 `<页面>.html` + `index.html` 总览
+- 两轮都要：覆盖 PRD 所有页面、每图带说明、设备形态贴合目标端
+- 高保真轮额外：布局与线框定稿一致
+- 回写 state.json：线框轮 `confirmed.wireframe`、高保真轮 `confirmed.prototype`

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-release/SKILL.md

@@ -8,17 +8,18 @@ description: "【dwy·上架迭代】产品 0 到 1 上架迭代阶段（终点
 
 ## 输入（从哪读）
 - state.json 的 `confirmed.acceptance`、`confirmed.prd`、`confirmed.version_plan`
-- `.dwy/prod/[项目]/04-上线交付/验收报告.md`
+- `.dwy/prod/[项目]/05-上线交付/验收报告.md`
 - `.dwy/prod/[项目]/02-需求规划/版本路线图.md`
 
 ## 实现
 [包装型] 用全局本地 skill（位于 `~/.dwy/skills/<外部skill名>/`）：
 读其 `SKILL.md`（及同目录 scripts/、配套 .md），按它的方式与用户交互/提问，产出按下方「产出契约」落地。
+- **提问形式（Claude Code 下强制）**：借用外部 skill 的「问什么、怎么一步步收敛」方法论，但**每个要用户选择/拍板的问题用 `AskUserQuestion` 工具弹点选卡片**，不在正文列 A/B/C/D 让用户打字；保留「一次一问、答完再问下一个」的节奏，开放式补充靠卡片的「Other」兜底。其他工具（Codex 等无此组件）退回外部 skill 原生的正文问答。
 - 本 skill 依赖的外部 skill：`release-notes`、`gtm-strategy`、`metrics-dashboard`、`north-star-metric`（各对应 `~/.dwy/skills/<名>/`）
 - 若 `~/.dwy/skills/<名>/` 不存在：提示用户先跑 `dwy skills install`（或 `dwy claude sync` 会自动装），不要自己用内置能力顶替。
 
 ## 产出契约（硬约束）
-- 落到：`.dwy/prod/[项目]/04-上线交付/上架物料.md`、`埋点与指标.md`、`下一版迭代规划.md`
+- 落到：`.dwy/prod/[项目]/05-上线交付/上架物料.md`、`埋点与指标.md`、`下一版迭代规划.md`
 - 固定章节：
   - 上架物料.md：发布说明 / GTM 策略 / 渠道文案
   - 埋点与指标.md：北极星指标 / 埋点清单 / 指标看板设计

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-stage-design/SKILL.md

@@ -1,23 +1,30 @@
 ---
 name: dwy-stage-design
-description: "【dwy·设计架构阶段】产品 0 到 1 的第三阶段编排。触发场景：用户说『画原型 + 定架构 / 做设计 / 出原型出架构 / 需求定了开始设计 / 设计和技术架构一起搞』，要把 PRD 同时展开成交互原型和技术架构时。可独立触发——需求已定，只想做设计架构，就触发我。"
+description: "【dwy·设计架构阶段】产品 0 到 1 的第三阶段编排。触发场景：用户说『画原型 + 定架构 / 做设计 / 出原型出架构 / 需求定了开始设计 / 设计和技术架构一起搞』，要把 PRD 先展开成原型、原型定稿后再做技术架构时。可独立触发——需求已定，只想做设计架构，就触发我。"
 ---
 
 ## 职责（单一·编排层）
-并行调度设计架构阶段的两条原子线，不掺产出内容。设计线与架构线互不依赖，**两线并行**。
+**串行**调度设计架构阶段，不掺产出内容：先原型（内部两轮门控），原型全部确认后才进架构。**架构依赖原型定稿**，原型未定不进架构。
 
 ## 前置校验（开工前读 state）
 - 读 `.dwy/prod/[项目]/state.json`
-- 校验上游完整：`confirmed.prd` + `confirmed.version_plan` 必须存在
-- 缺失 → 报错中断，提示先跑 dwy-stage-prd
+- **先检 `schema_version`**：缺失或低于当前版本 → 按 `dwy-product-launcher/references/state-and-contract.md`「schema 版本与迁移」升级 state 再继续
+- 上游 `confirmed.prd` / `confirmed.version_plan` 缺失（如单独触发本阶段）→ **不报错**，基于已聊上下文 + 现有产出**轻量补齐**够本阶段用的简版 PRD / 版本范围，写回对应 `confirmed.*` 标注「上下文补齐」。仅当上下文完全不足才提示用户补信息。
+- `run_mode` 缺失 → 默认 `standard`，或按用户当下意图问一次。
 
-## 编排（并行两线）
-两条线无依赖，**用子 Agent 并发执行**（各自独立上下文）：
-- **dwy-prototype** — 交互原型设计
-- **dwy-architecture** — 技术架构设计
+## 编排（串行两步）
+1. 调 **dwy-prototype** 走「线框初稿 → 高保真平面图」两轮门控；两轮分别回写 `confirmed.wireframe`、`confirmed.prototype`。
+2. `confirmed.prototype` 写入后，才调 **dwy-architecture** 出技术架构。
 
-两个子 Agent 只向主窗口返回成果摘要，产出落各自文件。
+子 skill 只向主窗口返回成果摘要，产出落各自文件。
+
+## run_mode 感知
+- `standard`：原型两轮门控照常问用户「线框是否通过 / 高保真是否通过」。
+- `auto`：两轮门控由 AI 自动决策推进、不问用户，仍按「线框定稿 → 高保真 → 架构」顺序串。
+
+## 自动流转（准出后）
+- 回写 `current_stage = "dev"`，按 `run_mode`：`standard` 问「继续 TDD 开发 / 停」、`auto` 直接触发 `dwy-stage-dev`。
 
 ## 准出条件（硬约束）
 - 设计与架构**均确认**：`confirmed.prototype` + `confirmed.architecture` 均写入
-- 回写 `state.json`：`current_stage = "dev"`
+- 回写 `state.json`：`current_stage = "dev"`，按 run_mode 流转下一阶段

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-stage-dev/SKILL.md

@@ -4,19 +4,51 @@ description: "【dwy·TDD开发阶段】产品 0 到 1 的第四阶段编排。
 ---
 
 ## 职责（单一·编排层）
-调度 TDD 开发原子 skill 按模块循环，不掺产出内容。版本内互不依赖的模块**多模块并发**。
+**任务级 block 分析 + 动态调度**，不掺产出内容。读任务依赖图，无 block 的任务多 Agent 并发、有 block 的串行，逐任务验收推进。
 
 ## 前置校验（开工前读 state）
 - 读 `.dwy/prod/[项目]/state.json`
-- 校验上游完整：`confirmed.prototype` + `confirmed.architecture` + `confirmed.tasks` 必须存在
-- 缺失 → 报错中断，提示先跑 dwy-stage-design
+- **先检 `schema_version`**：缺失或低于当前版本 → 按 `dwy-product-launcher/references/state-and-contract.md`「schema 版本与迁移」升级 state 再继续
+- 上游 `confirmed.prototype` / `confirmed.architecture` / `confirmed.tasks` 缺失（如单独触发本阶段）→ **不报错**，基于已聊上下文 + 现有产出**轻量补齐**够本阶段用的架构/任务拆解结论，写回对应 `confirmed.*` 标注「上下文补齐」。仅当上下文完全不足才提示用户补信息。
+- `run_mode` 缺失 → 默认 `standard`，或按用户当下意图问一次。
+- `auto` 下开发全程自动跑（block 分析 → agent 池 → 逐任务验收 → 覆盖回查）；`standard` 同样自动跑（开发阶段本就无逐模块人工验收），区别仅在准出后是否问「继续上架」。
 
-## 编排（按模块循环 + 并发）
-- 按 `confirmed.tasks` 的模块清单逐个调 **dwy-tdd-dev**
-- 互不依赖的模块用多个子 Agent 并发；改同一批文件时各自独立 worktree 防冲突
-- 有依赖的模块按依赖顺序串行
+## 编排（block 分析 → agent 池调度）
+
+### 第一步·block 分析（硬约束，先做）
+调度前**必须先分析每个任务的前后 block 关系**（由任务 Interfaces 推出：`Consumes`=被谁 block、`Produces`=block 谁）。判定铁律：
+- **无 block 的任务 → 多 Agent 并行**
+- **有 block 的任务 → 串行**，被 block 的下游必须等其所有前置 block 任务 done 才能启动
+- 与 `ai-tools/CLAUDE.md`「任务执行前必须先分析 block；无 block 的任务用多 Agent 并行」一致
+
+### 第二步·agent 池调度
+- 按 block 分析结果建 **ready 队列**（所有前置 block 已 done 的任务，即当前无 block 的）
+- 多个子 Agent 并发领取 ready 队列任务，每个 agent 调 **dwy-tdd-dev** 跑单任务 RED→GREEN→REFACTOR
+- 任务 done → 解锁被它 block 的下游 → 下游 block 全清进 ready → 空闲 agent 继续领；任务多时吞吐高
+- **冲突隔离**：改同一批文件的并行任务各自独立 git worktree，完成后按 block 顺序合并；无文件交叠的并行任务无需隔离
+- 落地用 Claude Code 原生 Agent 工具并发派发 + worktree
+
+### 第三步·逐任务验收闭环（防漏需求）
+- 每个任务 done 时，承做 agent 走闭环：**核验**（对照验证标准跑通，未过保持 `todo` 不跳过）→ **标记** `confirmed.dev_progress.<module>.<task> = done` → **记日志**（`09-开发日志.md` 一行：任务/验证结果/关键决策）→ **独立提交**（该任务源码+测试单独 commit，一任务一 commit，并发时各自在 worktree 内提交）
+- worktree 内提交后，编排层按 block 顺序合并各任务分支
+
+### 第四步·合并后全量收口闸（硬约束，编排层独占执行）
+
+并发的根本问题：各 agent 在**自己 worktree、自己领任务那一刻的代码态**下自报「全绿」，但它们并发提交、互相看到的是中间失败态——**单任务绿是必要不充分**，真实准出态只能由「全部分支合并后、在同一棵统一工作树上、一次性跑的全量」定义。所以所有任务分支合并完成后、覆盖回查之前，**必须由编排层自己跑一道收口闸**，不派给任何承做 agent（杜绝「自述全绿」）：
+
+1. **统一工作树**：确认所有任务分支已按 block 顺序合并到主干，在合并后的统一工作树上执行（不在任何子 worktree 内）。
+2. **跑全量**：在合并后代码上**一次性跑全量单测 + 构建打包**（含项目级类型检查——类型错应在 build/打包这条线暴露）。**命令读项目上下文 + 基线自行判定**（前端/后端/全栈各异），不写死具体命令。目标=**消除合并后才暴露的报错，产物可运行**。
+3. **失败 → 编排层修复 + 重跑整闸**：任何失败由编排层走 systematic-debugging 修（典型来源：跨任务共享类型/接口签名变更、共享 fixture、合并冲突遗留），**修完重跑整道闸**（不是只跑挂的那条），循环到**一次性全绿**才算过。此闸是硬闸，`auto` 模式也必须修到绿，不跳过。
+4. **记录**：收口结果记 `09-开发日志.md` 一行（跑了什么、修了什么）。
+
+### 第五步·收尾覆盖回查
+- 收口闸全绿后，对照 `开发任务拆解.md` 任务清单 + PRD 页面/功能逐项点检，确认无遗漏任务、无「标 done 实则未实现」
+- 发现缺口 → 补任务再跑（补完重过第四步收口闸），不直接进 ship
+
+## 自动流转（准出后）
+- 回写 `current_stage = "ship"`，按 `run_mode`：`standard` 问「继续上架迭代 / 停」、`auto` 直接触发 `dwy-stage-ship`。
 
 ## 准出条件（硬约束）
-- 当前版本（V1.0）**全模块测试通过**
-- `confirmed.dev_progress` 写入（记录已完成模块与测试状态）
-- 回写 `state.json`：`current_stage = "ship"`
+- 当前版本（V1.0）**合并后全量收口闸一次性全绿**（全量单测 + 构建打包通过，非各 agent 自报）+ 覆盖回查无遗漏
+- `confirmed.dev_progress` 全 done（任务级记录 `<module>.<task>`）
+- 回写 `state.json`：`current_stage = "ship"`，按 run_mode 流转下一阶段