@openprd/cli 0.1.9 → 0.1.11

package/.openprd/design/themes/theme-catalog.json

@@ -0,0 +1,77 @@
+{
+  "version": 1,
+  "themes": [
+    {
+      "id": "quiet-sand",
+      "useFor": ["editorial-contrast", "catalog-clarity"],
+      "summary": "Warm neutral editorial theme with restrained contrast.",
+      "bodyFont": "\"Inter\", \"PingFang SC\", sans-serif",
+      "headlineFont": "\"Iowan Old Style\", \"Noto Serif SC\", \"Songti SC\", serif",
+      "surfacePreset": "paper-grid",
+      "tokens": {
+        "background": "#F6F1E8",
+        "surface": "#FFFDF8",
+        "text": "#1F1A17",
+        "muted": "#6B625C",
+        "accent": "#A64B2A",
+        "border": "#D8CEC1",
+        "radius": "8px",
+        "shadow": "0 12px 32px rgba(31,26,23,0.08)"
+      }
+    },
+    {
+      "id": "deep-launch",
+      "useFor": ["product-launch", "immersive-showcase"],
+      "summary": "Dark, cinematic launch theme with controlled highlight color.",
+      "bodyFont": "\"Inter\", \"PingFang SC\", sans-serif",
+      "headlineFont": "\"Inter\", \"PingFang SC\", sans-serif",
+      "surfacePreset": "dark-mesh",
+      "tokens": {
+        "background": "#0D1117",
+        "surface": "#131A23",
+        "text": "#F5F7FA",
+        "muted": "#A0A8B3",
+        "accent": "#34D3A2",
+        "border": "#243140",
+        "radius": "8px",
+        "shadow": "0 16px 40px rgba(0,0,0,0.35)"
+      }
+    },
+    {
+      "id": "warm-editorial",
+      "useFor": ["editorial-contrast", "product-launch"],
+      "summary": "Bright magazine-like theme with warmer accents and layered typography.",
+      "bodyFont": "\"Avenir Next\", \"PingFang SC\", sans-serif",
+      "headlineFont": "\"Iowan Old Style\", \"Noto Serif SC\", \"Songti SC\", serif",
+      "surfacePreset": "paper-grid",
+      "tokens": {
+        "background": "#FFF9F1",
+        "surface": "#FFFFFF",
+        "text": "#1B1714",
+        "muted": "#6A6258",
+        "accent": "#D96B34",
+        "border": "#E7D8C7",
+        "radius": "6px",
+        "shadow": "0 10px 24px rgba(27,23,20,0.07)"
+      }
+    },
+    {
+      "id": "tool-neutral",
+      "useFor": ["operational-density", "catalog-clarity"],
+      "summary": "Quiet operational theme for work-focused interfaces.",
+      "bodyFont": "\"Avenir Next\", \"PingFang SC\", sans-serif",
+      "headlineFont": "\"Inter\", \"PingFang SC\", sans-serif",
+      "surfacePreset": "workbench-grid",
+      "tokens": {
+        "background": "#F4F6F8",
+        "surface": "#FFFFFF",
+        "text": "#17212B",
+        "muted": "#5F6B76",
+        "accent": "#2F80ED",
+        "border": "#D9E1E8",
+        "radius": "6px",
+        "shadow": "0 6px 18px rgba(23,33,43,0.06)"
+      }
+    }
+  ]
+}

package/.openprd/engagements/active/prd.md

@@ -1,84 +1,88 @@
-# OpenPrd 首轮项目画像与自适应需求初始化
+# OpenPrd loop 隔离 worktree 提交闭环
 > 语言规则：默认用简体中文生成 PRD、spec、tasks 和用户可见说明；除 PRD、OpenPrd、OpenSpec、API、SDK、CLI、TypeScript、JSON、HTTP、WebSocket、字段 key、命令名、品牌名、产品名和协议名等必要专有名词外，其余内容优先写成简体中文。
-- 版本: v0005
+- 版本: v0006
 - 负责人: Codex
-- 产品类型: agent
-- 模板包: agent
+- 产品场景: 以 Agent 为主要使用场景
+- 场景模板: 以 Agent 为主要使用场景
 - 状态: synthesized
-- 生成时间: 2026-06-02 13:28:35
+- 生成时间: 2026-06-07 13:07:07
 ## 元信息
 
-- 标题: OpenPrd 首轮项目画像与自适应需求初始化
+- 标题: OpenPrd loop 隔离 worktree 提交闭环
 - 负责人: Codex
 - 状态: clarifying
-- 版本: v0005
-- 产品类型: agent
-- 日期: 2026-06-02
+- 版本: v0006
+- 产品场景: 以 Agent 为主要使用场景
+- 日期: 2026-06-07
 
 ## 问题
 
-- 问题陈述: OpenPrd 在用户第一次提需求时虽然已经有 consumer / b2b / agent 分流、clarify 和后续 review/change/tasks 流程，但缺少一个项目级的首轮画像层。结果是 Agent 容易直接围绕局部需求推进，而没有先确认用户群体、产品形态、第一版切片、先不做什么、不能破坏什么，以及是否命中技术和业务风险。
-- 为什么是现在: 用户明确指出 Vibe Coding 场景下的首轮需求往往模糊：如果不先建立整体轮廓，后续容易返工；如果一上来就强制填写重问卷，又会压垮首轮体验。因此需要把初始化改成轻量项目画像加条件追问。
+- 问题陈述: OpenPrd 的 loop 虽然支持逐任务 finish 和可选 commit，但最近没有稳定形成“隔离 worktree + 单任务 commit + 可审查回归”的闭环。当前 loop --run 不会自动切到隔离环境，loop --finish --commit 仍按全仓 git add -A 提交，主工作区一旦有脏改动就容易把无关内容卷进来，导致任务虽然 done 却没有可靠的 commit 留痕。
+- 为什么是现在: 最近一个月里 loop 仍有 finish 通过，但没有稳定产出你期望的逐任务 commit 闭环；当前 openprd 仓库也出现了 done 任务没有 commitSha 的情况。要把 L2 和长程实现真正挂到 loop 上，就需要先把隔离执行、提交流程和状态留痕补齐。
 - 证据:
-  - 本轮用户明确指出第一次提需缺少 to C / to B / agent、用户群体、商业模式、功能架构和技术边界的前置梳理。
-  - 本地代码检查显示现有 base intake 只覆盖问题、用户、成功、范围与成本信号，缺少独立的首轮项目画像层。
-  - 外部调研表明 Vibe Coding 更适合轻量画像加条件追问，而不是重型初始化问卷。
+  - 最近一个月能查到多次 loop finish 通过，但没有对应的 Commit 记录。
+  - 当前 openprd/.openprd/harness/feature-list.json 里 22 个 done 任务的 commitSha 为空。
+  - 现有 loop --run 直接在当前 cwd 执行，未自动创建或切换 worktree。
+  - 现有 loop --finish --commit 仍按 git add -A 提交，提交范围过宽。
+  - 当前隔离副本多为 detached HEAD，缺少稳定的 branch / worktree / commit 绑定。
 
 ## 用户与相关方
 
 - 主要用户:
-  - 第一次用 OpenPrd 梳理产品想法的产品经理、独立开发者与 Vibe Coding 用户
-  - 需要在模糊需求下帮助用户收敛方向并继续落地的 Agent 协作者
+  - 需要用 OpenPrd loop 执行中等到长程实现的维护者
+  - 希望逐任务 commit、可审查、可回归且不污染主工作区的 Agent 协作者
 - 次要用户:
   - 待补充
 - 相关方:
-  - 维护 OpenPrd requirement-intake、workflow 和模板的开发者
-  - 后续需要基于已确认上下文继续实现的多轮 Agent 会话
+  - OpenPrd 维护者
+  - 在脏仓库或长程任务中依赖 loop 的项目协作者
 
 ## 目标与成功标准
 
 - 目标:
-  - 在第一次提需时先形成一页轻量项目画像，而不是直接跳进局部需求修改
-  - 让系统优先归纳 to C / to B / agent、目标用户、产品形态、第一版切片、非目标和保护项，再请用户确认
-  - 当信息不足时，用条件追问或候选原型方向补齐，而不是要求用户一开始回答完整技术和商业问卷
+  - 让 loop 在需要时显式进入隔离 worktree / branch 中执行，而不是默认污染主工作区。
+  - 让逐任务 commit 只包含当前任务的改动，便于单独审查和回归。
+  - 让 worktree、branch、commitSha 和 session 形成完整可追踪链路。
 - 成功指标:
-  - 首轮 clarify 能输出结构化的项目画像摘要，并包含用户群体、产品形态、第一版先做、先不做和不能破坏项
-  - 复杂或模糊需求会触发技术/风险追问，简单明确需求仍保持轻量
-  - 默认 clarify 仍在对话内完成，不新增新的 clarify HTML
-  - 用户能够更快确认方向，后续 PRD 和实现阶段减少返工与错题
+  - loop --run 可以显式创建或接入 worktree / branch，或提供等价包装入口。
+  - 主工作区脏时，loop --finish --commit 默认阻断，只有显式豁免才允许继续。
+  - 逐任务 commit 不再使用全仓 git add -A，而是基于 write-scope 或本轮 touched files。
+  - loop-state.json 与 agent-sessions.jsonl 能记录 worktreePath、branch、commitSha。
 - 验收目标:
-  - workspace-workflow 能生成首轮项目画像、风险探针和更贴近用户语言的确认问题
-  - workspace-core 的冷启动 kickoff 问题升级为画像导向问题
-  - intake 模板、skills、docs、CLI 文本输出和测试与新流程保持一致
+  - 在隔离 worktree 中连续完成多个 loop 任务时，每个任务都能生成独立 commit，并把 commitSha 写回状态。
+  - 在脏主工作区直接尝试 finish --commit 时，会收到明确阻断和豁免提示。
+  - 从状态文件和 session 日志可以追溯每个任务对应的 worktree、branch、commit 和测试报告。
+  - 新能力不破坏现有 loop 的 plan、next、run、finish、verify 基本路径。
 
 ## 范围与非目标
 
 - 范围内:
-  - 在 clarify、intake-reflection 和 interview 中加入首轮项目画像层
-  - 让系统先推断 consumer / b2b / agent 与项目形态，再结合第一版切片、非目标、保护项组织追问
-  - 命中技术和业务风险信号时再展开前后端、数据、账号、AI、外部服务、收费等边界问题
-  - 同步更新模板、技能说明、基础文档、CLI 输出和相关测试
+  - 给 openprd loop --run 增加显式 --worktree / --branch，或提供先创建隔离 worktree 再执行的包装入口。
+  - 在 commit 前增加主工作区脏状态门禁和显式 override 机制。
+  - 把提交范围从 git add -A 收窄到 task write-scope 或本轮 touched files。
+  - 把 worktreePath、branch、commitSha 写入 loop-state.json、agent-sessions.jsonl 以及相关状态输出。
 - 范围外:
-  - 不把首次提需改成一份重型强制问卷
-  - 不把商业模式或技术架构变成所有场景的硬必填 schema
-  - 不新增默认 clarify HTML 或额外前端评审页面
-  - 不让局部小修进入完整项目画像重流程
+  - 不在这次能力里自动 push、开 PR 或发布。
+  - 不做复杂的交互式冲突解决或自动合并策略。
+  - 不强制把每个 task 都拆成独立 worktree；第一版优先支持一个 change / 一段 loop 使用一个隔离 worktree。
+  - 不先重做整套 release / publish 工作流。
 
 ## 场景与流程
 
 - 主流程:
-  - 用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第一版先做、先不做、不能破坏、技术落点和风险探针
-  - 如果用户表达已经足够清楚，Agent 直接用系统归纳的画像摘要请用户确认
-  - 如果用户表达模糊，Agent 先追问少量高价值问题，必要时给 2 到 3 个方向或行业原型供用户选择
-  - 画像确认后再进入后续 PRD、review、change 和 tasks 流程
+  - 用户为一个 change 进入 loop 开发时，OpenPrd 可显式创建或接入隔离 worktree 与命名分支，再在其中逐任务运行和提交。
+  - 每个任务验证通过后执行 finish --commit，只提交当前任务 write-scope / touched files，并把 commit 信息写回状态。
+  - 评审或回归时，维护者可从状态文件直接定位 worktree、branch、commitSha 和测试报告。
 - 边界情况:
-  - 用户一开始只有一句模糊想法，需要先给候选方向而不是硬追问技术细节
-  - 已有项目上下文时应优先沿用已知事实，而不是把所有画像问题重问一遍
-  - 局部 copy、样式或小交互修正不应被错误升级成重画像流程
+  - 用户在脏主工作区里直接尝试 finish --commit。
+  - 当前任务没有可确定的 write-scope，需要回退到 touched files 或明确失败提示。
+  - 已有 worktree 存在但 branch 缺失、处于 detached HEAD 或命名不规范。
+  - 任务验证通过但 commit 写回状态失败，需要保持任务未完全收口并给出修复入口。
 - 失败模式:
-  - 入口过重，导致 Vibe Coding 用户在第一次提需时无法回答
-  - 入口过轻，导致 Agent 没有先确认项目边界就直接落地
-  - 错误复用旧 active change 或旧 PRD 上下文，导致实现偏题
+  - 误把主工作区无关改动一起提交。
+  - loop 在 detached HEAD 或错误分支上提交，后续难以审查和回放。
+  - 状态里只标 done 但缺少 commitSha / worktree 信息，导致无法追溯。
+  - 隔离 worktree 创建成功，但后续 run / finish 没有使用同一执行环境。
 
 ## 可视化图表
 
@@ -86,30 +90,30 @@
 
 ```mermaid
 flowchart LR
-  entry["入口触发<br/>用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第一版先做、先不做、不能破坏、技术落点和风险探针"]
-  experience["产品内步骤<br/>如果用户表达已经足够清楚，Agent 直接用系统归纳的画像摘要请用户确认"]
-  decision{"决策点<br/>用户一开始只有一句模糊想法，需要先给候选方向而不是硬追问技术细节"}
-  success(["成功结果<br/>首轮 clarify 能输出结构化的项目画像摘要，并包含用户群体、产品形态、第一版先做、先不做和不能破坏项"])
-  failure[["失败与恢复<br/>入口过重，导致 Vibe Coding 用户在第一次提需时无法回答"]]
-  entry -->|"用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第一版…"| experience
-  experience -->|"如果用户表达已经足够清楚，Agent 直接用系统归纳的画像摘要请用户确认"| decision
-  decision -->|"在第一次提需时先形成一页轻量项目画像，而不是直接跳进局部需求修改"| success
-  decision -.->|"入口过重，导致 Vibe Coding 用户在第一次提需时无法回答"| failure
+  entry["入口触发<br/>用户为一个 change 进入 loop 开发时，OpenPrd 可显式创建或接入隔离 worktree 与命名分支，再在其中…"]
+  experience["产品内步骤<br/>每个任务验证通过后执行 finish --commit，只提交当前任务 write-scope / touched files…"]
+  decision{"决策点<br/>用户在脏主工作区里直接尝试 finish --commit。"}
+  success(["成功结果<br/>loop --run 可以显式创建或接入 worktree / branch，或提供等价包装入口。"])
+  failure[["失败与恢复<br/>误把主工作区无关改动一起提交。"]]
+  entry -->|"用户为一个 change 进入 loop 开发时，OpenPrd 可显式创建或接入…"| experience
+  experience -->|"每个任务验证通过后执行 finish --commit，只提交当前任务 write…"| decision
+  decision -->|"让 loop 在需要时显式进入隔离 worktree / branch 中执行，而…"| success
+  decision -.->|"误把主工作区无关改动一起提交。"| failure
 ```
 
 ### 架构
 
 ```mermaid
 flowchart LR
-  users["主要用户<br/>第一次用 OpenPrd 梳理产品想法的产品经理、独立开发者与 Vibe Coding 用户 · 需要在模糊需求下帮助用户收敛…"]
+  users["主要用户<br/>需要用 OpenPrd loop 执行中等到长程实现的维护者 · 希望逐任务 commit、可审查、可回归且不污染主工作区的 …"]
   subgraph solution["方案边界"]
-    experience["Agent 运行层<br/>用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第一版先做、先不做、不能破坏、技术落点和风险探针 …"]
-    core["核心产品逻辑<br/>OpenPrd 在用户第一次提需求时虽然已经有 consumer / b2b / agent 分流、clarify 和后续 r…"]
-    integrations["依赖与集成<br/>依赖现有 requirement-intake gate、clarify/capture/synthesize/review/…"]
-    governance[["约束与可靠性<br/>继续遵守现有 requirement gate、review gate 和 hook 安全边界，不绕过已确认的需求流程。 · …"]]
-    delivery["验证与交接<br/>首轮 clarify 能输出结构化的项目画像摘要，并包含用户群体、产品形态、第一版先做、先不做和不能破坏项 · 复杂或模糊需求…"]
+    experience["Agent 使用场景层<br/>用户为一个 change 进入 loop 开发时，OpenPrd 可显式创建或接入隔离 worktree 与命名分支，再在其中…"]
+    core["核心产品逻辑<br/>OpenPrd 的 loop 虽然支持逐任务 finish 和可选 commit，但最近没有稳定形成“隔离 worktree …"]
+    integrations["依赖与集成<br/>Git worktree 能力。 · 现有 loop task executionStrategy.writeScope 与 …"]
+    governance[["约束与可靠性<br/>提交与状态写回不能泄露用户本地无关改动或敏感信息。"]]
+    delivery["验证与交接<br/>loop --run 可以显式创建或接入 worktree / branch，或提供等价包装入口。 · 主工作区脏时，loop…"]
   end
-  users -->|"用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第…"| experience
+  users -->|"用户为一个 change 进入 loop 开发时，OpenPrd 可显式创建或…"| experience
   experience -->|"产品动作与编排"| core
   core -->|"依赖与外部服务"| integrations
   core -.->|"策略、可靠性与合规"| governance
@@ -121,69 +125,76 @@ flowchart LR
 ## 需求
 
 - 功能需求:
-  - clarify 生成的 intake-reflection 应包含首轮项目画像和风险探针
-  - inline clarification 应显式展示适用对象、产品形态、第一版先做、先不做、不能破坏和技术落点
-  - 冷启动 kickoff 问题改成画像导向问题，而不是抽象的通用提问
-  - 类型专项 intake 模板改成更贴近产品与业务语言的提问方式
+  - 支持显式 worktree / branch 配置，或提供隔离运行包装命令。
+  - 支持检测主工作区脏状态，并在 finish --commit 前阻断高风险路径。
+  - 支持基于 write-scope 或 touched files 生成本任务提交集。
+  - 支持在 loop 状态、session 日志和测试报告中记录 commit 关联信息。
+  - 支持为未满足 commit 前置条件的任务给出清晰诊断与恢复指引。
 - 非功能需求:
-  - 默认澄清仍要保持对话内、轻量、可扫读
-  - 对已有 schema 和生成流程的侵入应尽量小
-  - 输出语言优先面向产品和业务用户，而不是工程内部黑话
+  - 默认路径必须安全，不能把无关改动静默卷入 commit。
+  - 行为必须可追踪，可从状态文件复原任务执行链路。
+  - 对现有 loop 用户保持兼容，新增能力应尽量显式开启或有明确默认策略。
+  - 失败路径必须可恢复，不能留下半记录状态。
 - 业务规则:
-  - 优先由系统归纳后请用户确认，而不是一开始把所有字段抛给用户
-  - 只有命中风险信号时才展开技术、账号、数据、外部服务或成本相关追问
-  - consumer / b2b / agent 优先由系统推断，必要时再请用户确认
-  - clarify 阶段默认不生成 HTML，正式可视化仍留给 review 或 diagram 阶段
+  - 逐任务 commit 只在任务验证通过后允许执行。
+  - 主工作区脏时默认禁止高风险 commit，除非用户显式豁免。
+  - 状态留痕必须与实际 commit 结果一致，不能先写成功后提交失败。
 
 ## 业务护栏
 
 - 成本来源:
-  - 本次没有新增第三方付费调用；成本主要来自不准确需求初始化带来的返工和错题
+  - 这次主要要避免无关改动混入 commit、回滚成本升高，以及逐任务审查和回归失去抓手。
 - 额度与限制:
-  - 不应让每个首次提需都退化成长问卷；默认只问最少必要问题
+  - 默认不允许在脏主工作区直接完成高风险 commit；需要显式进入隔离路径或明确豁免。
 - 滥用防护:
-  - 系统不能把未确认的推断当作最终需求事实
-  - 命中账号、数据、外部服务、AI 或收费信号时，必须显式提醒边界与风险
+  - 不能把未在当前任务范围内的文件静默加入 commit。
+  - 不能把 detached HEAD 上的匿名提交伪装成可回归的标准 loop 结果。
 - 监控信号:
-  - 观察首轮 clarify 是否仍然过长、是否反复追问同一类信息、是否错误复用旧 change 上下文
+  - 需要持续看 loop 任务完成后是否稳定写回 commitSha。
+  - 需要看 worktreePath、branch、commitSha 是否在状态和 session 日志里一致。
+  - 需要看脏主工作区门禁是否挡住了无关改动被带进提交。
 - 报警阈值:
-  - 如果简单需求被连续升级成深度追问，或复杂需求仍缺少画像摘要，应在测试中显式暴露
+  - 只要出现用户要求 commit 但任务完成后没有 commitSha，就算这条闭环没有打通。
+  - 只要出现主工作区无关改动被带进 loop commit，就应立即视为高风险回退。
 - 止损动作:
-  - 当系统无法准确归纳时，退回到少量高价值确认问题，不假装已经清楚
-  - 当当前工作区上下文明显与本轮需求不匹配时，先刷新到新的 change/task 再实现
+  - 无法安全判定提交范围时，停止自动 commit，保留任务验证结果并提示人工处理。
+  - worktree / branch 状态异常时，不把任务标记为已完成提交。
 
 ## 约束、依赖与风险
 
 - 技术约束:
-  - 主要修改 src/workspace-workflow.js、src/workspace-core.js、CLI 文本输出、.openprd intake 模板、skills/docs 和测试
-  - 避免新增新的硬性必填 schema 字段，优先通过 intake 和 clarification 层完成增强
+  - 基于现有 openprd loop / git 流程扩展，不重写整套任务调度。
+  - 兼容当前 feature-list、loop-state、agent-sessions 与 test-reports 结构。
+  - 需要同时考虑 worktree、命名分支与 detached HEAD 的兼容行为。
 - 合规要求:
-  - 继续遵守现有 requirement gate、review gate 和 hook 安全边界，不绕过已确认的需求流程。
-  - 新增提示和用户可见文案应保持面向产品与业务语言，不直接暴露内部技术细节。
+  - 提交与状态写回不能泄露用户本地无关改动或敏感信息。
 - 依赖:
-  - 依赖现有 requirement-intake gate、clarify/capture/synthesize/review/change/tasks 工作流
-  - 依赖现有 base / consumer / b2b / agent 模板与评审产物体系
+  - Git worktree 能力。
+  - 现有 loop task executionStrategy.writeScope 与 finish / verify 流程。
+  - OpenPrd 的状态文件、review / change / tasks 主流程。
 - 假设:
-  - Vibe Coding 用户更愿意确认系统总结，而不是先填写长问卷
-  - 现有 lens 分类能力可保留，只需要前移到项目画像语境里
+  - 第一版默认以一个 change / 一段 loop 对应一个隔离 worktree 为优先模型，而不是每个 task 一个 worktree。
+  - 已有 task write-scope 在多数实现任务里足够收窄 commit 范围；不足时需要 touched files 补位。
 - 风险:
-  - 如果问题过多，会损伤首次提需体验
-  - 如果画像层和现有 capture/analysis 脱节，会造成重复提问
-  - 如果没有处理旧上下文切换，hook 可能继续把代码修改指向错误 change
+  - 如果 worktree / branch 生命周期设计不清，会显著抬高 loop 使用复杂度。
+  - 如果 touched files 收集不稳定，可能出现漏提或误提。
+  - 如果状态写回与 git 操作顺序不当，会出现 done / commitSha 不一致。
 - 开放问题:
-  - 后续是否需要单独的 profile review artifact 或 diagram，用于更复杂的多系统场景
+  - 第一版是否明确采用一个 change 一个 worktree、一个 task 一个 commit。
+  - worktree / branch 命名规范是否要产品化成 CLI 默认值。
+  - override 脏仓库门禁时，CLI 需要多强的显式确认语义。
 
 ## 类型专项模块
 
-- 类型: Agent 专项
-- humanAgentContract: Agent 先归纳用户群体、产品形态、第一版切片、边界与风险，再请求用户确认；如果信息不足，只能提出候选方向，不能把猜测当成定论。
-- autonomyBoundary: Agent 可以根据当前需求和已有工作区状态推断首轮项目画像，但在用户确认前不得把推断直接写成最终需求事实或越过需求入口去改实现。
-- toolBoundary: 仅使用本地 OpenPrd workflow、模板、测试和文档完成这次改动，不依赖新的外部运行时。
-- stateModel: 新需求进入时先形成 project framing，再进入 requirement clarification、review/change/tasks 与实现。
-- evalPlan: 通过 workspace flow、requirement gate、CLI 输出和模板相关测试验证新流程，同时运行 dev-check、standards、quality 与 run verify。
+- 类型: Agent 使用场景专项
+- humanAgentContract: 用户决定是否进入 loop、是否要求 commit、是否接受 override；Agent 负责在安全前提下创建隔离执行环境，并维护状态与证据闭环。
+- autonomyBoundary: Agent 可以在 loop 运行前准备 worktree、检查脏状态并收集 touched files，但不能在用户未授权 commit 的情况下自动提交，也不能在高风险脏仓库里静默绕过门禁。
+- toolBoundary: 优先使用本地 Git 与 OpenPrd loop 状态完成这次能力，不引入新的远端托管或发布前置依赖。
+- stateModel: change 进入 loop 后，先绑定隔离执行环境，再逐任务 run / verify / finish / commit，并把 worktree、branch、commit 与测试报告写回同一条状态链。
+- evalPlan: 通过 loop 单测、worktree / dirty repo 场景测试、状态持久化测试，以及一次真实隔离 worktree 的串行回归验证这次改动。
 
 ## 交接
 
 - 负责人: Codex
-- 下一步: 生成新的 change 和 tasks，并按首轮项目画像流程修改 workflow、模板、文档和测试。
+- 下一步: 完成 review 确认后生成 change 和 tasks，再实现 loop 的隔离 worktree 提交闭环。
 - 目标系统: OpenPrd

package/.openprd/schema/prd.schema.yaml

@@ -27,6 +27,31 @@ sections:
       - successMetrics
       - acceptanceGoals
 
+  validation:
+    requiredFields:
+      - community
+      - seedUsers
+      - communityFit
+      - currentAlternative
+      - painEvidence
+      - manualPath
+      - manualPlaybook
+      - commitmentSignals
+      - firstValidationStep
+      - defaultAlivePlan
+      - paymentProof
+      - mvpSlice
+      - weekendTest
+      - smallestExecution
+      - productizeGate
+      - firstCustomerPath
+      - pricingHypothesis
+      - customerOneProfitability
+      - growthDiscipline
+      - reversibility
+      - customerTruth
+      - valuesFit
+
   scope:
     requiredFields:
       - inScope

package/.openprd/templates/base/intake.md

@@ -6,8 +6,25 @@
 
 - 我们要解决什么问题？
 - 主要是给谁用的？他们会在什么场景下最先感受到价值？如果你愿意，也可以直接说它更偏面向个人消费者、面向企业服务，还是以 Agent 为主。
+- 第一批最容易触达、最可能愿意给真实反馈的社区、渠道或人群是谁？
+- 你为什么算这个社区里的“自己人”？他们平时主要在哪里聚集、为什么你现在就能触达？这是不是一个足够小、足够集中的切口？
 - 第一版最小可用切片，最希望先让用户完成什么关键动作？
 - 当前临时解决方式是什么？
+- 这个问题到底有多痛？用户现在是不是已经在为更差的办法花时间、花钱，或者至少在强行 workaround？如果一句话描述客户和痛点，会怎么说？
+- 如果先不做完整产品，能不能先靠手工服务、半自动流程或轻量交付把价值跑出来？
+- 如果先手工交付，这份“手工作战卡”该怎么写：触发条件、关键步骤、用什么工具、单客大概花多久、谁来接力？
+- 如果今天禁止你写复杂代码，只能用 spreadsheet、表单、Zapier/Notion/Airtable 这类现成工具，你会怎么把第一版跑起来？哪些东西现在明确先不 build？如果已经不得不做产品，也只自动化最重复的一步，先压成 forms / lists / CRUD 这种最轻骨架。
+- 第一版到底只做哪一件事？它能不能被压成一个周末级 MVP、一个顾问式试跑，或一个更轻的验证动作？
+- 你现在至少能不能点出 3 到 10 个具体的人、团队或客户样本？如果已经聊过，里面有多少人真的愿意付费、预约试跑、导入真实数据，或者给出同等级别的承诺？
+- 第一批客户最现实的触达顺序是什么？先熟人、现有客户、社区，还是陌生线索？
+- 从第一个客户开始准备怎么收费？什么价格既是 no-brainer，又不会因为免费而失真？
+- 什么真实承诺最能证明这不是口头兴趣，比如付费、预约、提交真实素材、拉人进群或导入数据？
+- 最低成本先验证哪一步最关键？如果验证结果一般，什么情况下应该先停，或者先换更轻的方式继续？
+- 如果只拿到第一个客户，这条路怎么打平时间和交付成本？更接近 default alive 还是 default dead？
+- 你准备在什么条件下才允许自己“产品化”或继续加功能？例如已经服务了 10+ 付费客户、需求已经稳定几周、手工步骤几乎不再变化。一旦真的开始做产品，默认也只自动化一小步，不直接做大平台。
+- 销售和增长这条线准备怎么守纪律？是不是先熟人、再社区、再陌生线索；100 个付费客户前不把 launch 当获客策略；先花时间别先花钱；有自然增长前不急着投广告或招人。
+- 如果结果一般，这个方向有多可逆？更像是在解决客户真问题，还是在满足我们自己的技术冲动？
+- 这条路是否符合团队现在想坚持的价值观和做事方式？如果连续这样做 3 到 5 年，你还愿意住在这套业务里吗？
 - 哪些内容这轮先不做？
 - 哪些既有能力、流程、体验或业务结果不能被破坏？
 - 成功后，用户会明显感受到什么变化？我们怎么判断它值得做成？

package/.openprd/templates/base/prd.md

@@ -27,24 +27,49 @@
 - 成功指标:
 - 验收目标:
 
-## 5. 范围与非目标
+## 5. 验证与创业闭环
+
+- 可触达社区:
+- 第一批种子用户:
+- 社区契合与触达依据:
+- 当前替代方案:
+- 痛点与替代证据:
+- 手工交付路径:
+- 手工作战卡:
+- 承诺信号:
+- 首个低成本验证:
+- 先活下来方案:
+- 付费验证信号:
+- 第一版只做一件事:
+- 周末级验证:
+- 最小工具桥接:
+- 产品化门槛:
+- 第一批客户路径:
+- 初始收费假设:
+- 客户 1 盈利路径:
+- 销售与增长纪律:
+- 可逆性判断:
+- 客户真问题校验:
+- 价值观一致性:
+
+## 6. 范围与非目标
 
 - 范围内:
 - 范围外:
 
-## 6. 场景与流程
+## 7. 场景与流程
 
 - 主流程:
 - 边界情况:
 - 失败模式:
 
-## 7. 需求
+## 8. 需求
 
 - 功能需求:
 - 非功能需求:
 - 业务规则:
 
-## 8. 业务护栏
+## 9. 业务护栏
 
 - 成本来源:
 - 额度与限制:
@@ -53,14 +78,14 @@
 - 报警阈值:
 - 止损动作:
 
-## 9. 约束、依赖与风险
+## 10. 约束、依赖与风险
 
 - 技术约束:
 - 依赖:
 - 风险:
 - 开放问题:
 
-## 10. 交接
+## 11. 交接
 
 - 下一步:
 - 目标系统:

package/AGENTS.md

@@ -13,9 +13,10 @@
 - 先读 `skills/openprd-router/SKILL.md`；在生成的 Codex / Claude 环境里，优先读同名 `openprd-router` skill。
 - 需要具体命令时，优先读 `.openprd/harness/command-catalog.md`，不要继续把命令清单膨胀回 `AGENTS.md`。
 - `$openprd-shared`：共用语言、文档影响、敏感信息、浏览器安全、小程序验证、产品文案与 i18n 规则。
-- `$openprd-requirement-intake`：需求入口分流、用户可见需求类型与内部 L0/L1/L2 路由码对照、PRD 场景视角选择。
+- `$openprd-requirement-intake`：需求入口分流、用户可见需求类型与内部 L0/L1/L2 路由码对照、PRD 场景视角选择，以及创业验证闭环。
 - `$openprd-test-strategy`：测试策略分流、分层验证、任务级 evidence-plan、升级原因与豁免理由。
 - `$openprd-harness`：主工作流、`run/loop`、review/change/tasks 与执行节奏。
+- `$openprd-frontend-design`：前端设计框架、审美资产库、设计主题/骨架/组件/配方/模板，以及事实、素材、图片和方向前置门。
 - `$openprd-benchmark-router`：外部技术、公开 GitHub 仓库、benchmark/对标/最佳实践路由。
 - `$openprd-standards` / `$openprd-quality`：`docs/basic/`、就绪验证、EVO 门禁、知识沉淀。
 - `$openprd-diagram-review` / `$openprd-discovery-loop`：可视评审与长时间只读挖掘。
@@ -24,18 +25,20 @@
 
 1. 动手前先从 `.openprd/` 重建状态，并先运行 `openprd run . --context`；它是建议上下文，不是自动执行指令。
 2. 规划、分析、架构评审、“怎么改”或“会动哪些文件”类请求保持只读；只有用户明确要求实现、继续任务、深度调研、对标复刻或提交时才进入执行。
-3. 先分流再执行：`openprd-requirement-intake` 按影响面、未知数、决策成本和验证成本判断需求类型，并保留内部路由码对照：快速修正=L0，现有功能优化=L1，新功能/新流程方案=L2。用户审查默认把路由码并进“需求类型：快速修正（L0）”这类标签里；只有内部排障确实受益时，才额外附“内部路由码”。快速修正可直接处理并事后说明，不打开正式 PRD/review/change/tasks；现有功能优化先在对话内给 mini-plan 再执行，默认不生成正式 PRD/change/tasks；如果用户刚刚已经确认了 L1 mini-plan、范围边界或正式产品边界，后续承接要写成“已确认，我按这个继续”，不要用“确认，我们就按这个……”这类像再次索取确认的句子。只有新功能/新流程方案才先走 requirement intake、对话内 requirement 摘要确认，再 `review/change/tasks`，最后才实现。L2 的 requirement 摘要默认按“需求判断 / 需求理解 / 功能范围 / 技术方案”来写，其中“功能范围”和“技术方案”优先用 Markdown 表格，帮助用户一眼看清。L2 的首轮澄清只能承诺“我先整理需求摘要给你确认”，不能把 requirement 摘要确认、review 和实现压成一句“你回我一句我就开始实现”。单纯的“请帮我实现/继续实现”只表示有执行意图，不表示可以跳过 requirement 摘要确认、`capture/classify/synthesize` 写入路径或 review；只有用户明确表示“不需要进行任何确认”时，才允许静默走完整 requirement write path。`review.html` 是稳定评审 artifact，不再默认等于唯一的人类停顿点；默认按 decision-points approval policy 执行，只有当前 lane 仍要求人类决策时才在 final answer 主体里停下请求确认；当 review 已确认且 tasks 已就绪但还需要执行授权时，先给执行确认清单再请用户确认。
+3. 先分流再执行：`openprd-requirement-intake` 按影响面、未知数、决策成本和验证成本判断需求类型，并保留内部路由码对照：直接处理=L0，现有功能优化=L1，新功能/新流程方案=L2。用户审查默认把路由码并进“需求类型：直接处理（L0）”这类标签里；只有内部排障确实受益时，才额外附“内部路由码”。直接处理类需求可直接处理并事后说明，不打开正式 PRD/review/change/tasks；现有功能优化先在对话内给 mini-plan 再执行，默认不生成正式 PRD/change/tasks；如果用户刚刚已经确认了 L1 mini-plan、范围边界或正式产品边界，后续承接要写成“已确认，我按这个继续”，不要用“确认，我们就按这个……”这类像再次索取确认的句子。只有新功能/新流程方案才先走 requirement intake、对话内 requirement 摘要确认，再 `review/change/tasks`，最后才实现。L2 的 requirement 摘要默认按“需求判断 / 需求理解 / 功能范围 / 技术方案”来写，其中“功能范围”和“技术方案”优先用 Markdown 表格，帮助用户一眼看清；`需求判断` 和 `需求理解` 先用 1 到 2 句轻量主句说清这次是什么、核心问题和第一版目标，边界、风险、异常例子和技术细节下沉到后面的分项或表格，不要把它们都塞进一整段长话里，也不要把某条示例文案写成固定模板。若当前仍在 0 到 1 探索、脑暴或值不值得做的判断，摘要里还要主动补上“验证与创业闭环”：第一批最容易触达的社区或种子用户、你为什么算这个社区里的自己人、当前替代方案和痛点证据、先怎么手工交付、手工作战卡怎么写、能不能先用 spreadsheet / 表单 / no-code 跑起来、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、第一版只做哪一件事、能不能压成周末级 MVP、第一批客户路径、从第一个客户开始怎么收费、客户 1 如何打平成本、有没有 10 个样本和更强付费信号、达到什么条件才允许产品化、增长阶段守什么纪律、这条路是否可逆、是否真在解决客户问题、以及是否符合团队价值观、是不是你愿意长期住进去的业务形态。L2 的首轮澄清只能承诺“我先整理需求摘要给你确认”，不能把 requirement 摘要确认、review 和实现压成一句“你回我一句我就开始实现”。如果 `openprd run . --context` 仍然建议 `clarify-user`，当前这轮回复的目标就只能是 `需求摘要` 或 `1 个最高价值澄清点`，不要写成“我先按默认方案实现”。如果用户的下一条回复只是承接上一轮 requirement 摘要的短跟进，而不是提出新范围、改目标或重新发起分析请求，就把它当成对上一轮摘要、默认方向或选项的继续确认，不要重新开一轮泛化 clarify；应直接按当前对话上下文把已确认事实用 canonical capture 路径、`user-confirmed` 来源写回，而不是继续写 `agent-inferred/project-derived` 的用户澄清字段。单纯的“请帮我实现/继续实现”只表示有执行意图，不表示可以跳过 requirement 摘要确认、`capture/classify/synthesize` 写入路径或 review；只有用户明确表示“不需要进行任何确认”时，才允许静默走完整 requirement write path。`review.html` 是稳定评审 artifact，不再默认等于唯一的人类停顿点；默认按 decision-points approval policy 执行，只有当前 lane 仍要求人类决策时才在 final answer 主体里停下请求确认；当 review 已确认且 tasks 已就绪但还需要执行授权时，先给执行确认清单再请用户确认。
 4. change/tasks 就绪后，用 `openprd-test-strategy` 按风险选择单元、集成、端到端、人工、视觉、小程序、性能或安全验证组合，并在任务或报告中保留 evidence-plan；同时根据任务边界记录 execution strategy：小范围修正保持 `serial`，中等规模 L1/L2 可推荐 `parallel-workers`，高风险或大规模实现再升级到 `parallel-workers-isolated`；70/20/10 只作健康形状参考，不作硬门禁。
-5. 纯图片、封面图、配图、海报、插画、图标、贴纸、mockup 或“先看样子”请求默认直接使用 `imagegen`，也就是 Codex 原生 Image 2；其中 logo、icon、avatar、badge 等开发素材在用户未明确要求场景化展示时，默认按独立素材输出（standalone asset）生成：全画布单主体，不额外添加卡片、设备框或其他展示容器；只有实际发生 `imagegen` 调用后，才能汇报生图结果、失败或限流；进入实现阶段时，已有参考图用 `openprd visual-compare --reference/--actual`，无参考图但改动界面用 `openprd visual-compare --before/--after`，局部细节重点则补 `openprd visual-compare --board <focus-board.json>`，多方向实验则补 `openprd visual-compare --board <parallel-board.json>`。
-6. 用户给出会话 ID 并要求继续时，按工具无关的历史会话续接；不要要求工具专属 ID，也不要用当前 active change 或相似历史替代指定会话。
-7. 单个 task 收尾时只运行本任务最小足够验证，并通过 `--evidence`、测试报告或任务 metadata 留下 task-scoped evidence；代码修改完成后、最终回复前，针对本轮实际 touched code files 运行 `openprd dev-check . <file...>`。阶段收口、全部实现完成、handoff/commit/release/publish 前，再运行 `openprd standards . --verify`、`openprd quality . --verify` 和 `openprd run . --verify`。
-8. 微信小程序相关任务默认按“最小足够验证”执行：只有用户明确要求小程序实测、截图、抓日志/网络、复现问题，或当前改动必须依赖运行态证据时，才升级到本地小程序运行态验证；默认沿用当前小程序运行态或开发者工具会话连续验证，不要为了验证自动重开应用；只有用户明确要求从 0 到 1、冷启动或重开时，才从头启动。如果当前客户端没有相应工具，不要假定已经安装，也不要把缺少工具当成阻断。
-9. `openprd init/setup/update/doctor` 记录的 `optionalCapabilities` 是非阻断式增强建议。当前任务明显受益但能力还未配置时，可在后续建议里说明它能帮什么、附官方文档 / GitHub 链接，并询问用户是否需要按当前客户端补配置；不要因为它未配置就阻断当前任务。
+5. 纯图片、封面图、配图、海报、插画、图标、贴纸、mockup 或“先看样子”请求默认直接使用 `imagegen`，也就是 Codex 原生 Image 2；其中 logo、icon、avatar、badge 等开发素材在用户未明确要求场景化展示时，默认按独立素材输出（standalone asset）生成：全画布单主体，不额外添加卡片、设备框或其他展示容器；只有实际发生 `imagegen` 调用后，才能汇报生图结果、失败或限流。生图结果先当候选效果图，不要默认登记到 `.openprd/harness/visual-reviews/`。Agent 要主动确认是否符合预期、是否纳入后续效果图/实现截图对比、以及是否按此继续实现；只有确认后，才把选定方向、整张图或其中子图整理成 reference-set 并进入实现。进入实现阶段时，已有确认参考图用 `openprd visual-compare --reference/--actual`；如果参考图是一张整板、网格图或多对象组合，先运行 `openprd visual-prepare --reference <效果图> --grid <列>x<行>` 或 `--boxes <plan.json>`，确认 contact sheet 后再逐项对比；没有参考图时先判断新建界面还是修改既有界面，新建界面先按用户目标、信息架构变化、视觉决策成本和验证风险完成 3 方向方案评审，修改既有界面用 `openprd visual-compare --before/--after`；局部细节重点则补 `openprd visual-compare --board <focus-board.json>`，多方向实验则补 `openprd visual-compare --board <parallel-board.json>`。用户后续如果说“跟效果图”“不一致”“好丑”“复刻”，不能只口头说对比过了，至少先产出一份视觉证据图。如果用户目标是把工作转成可学习、可复用、可回看、可教学或可沉淀的材料，先按期望产物是否需要章节结构、证据锚点、图文讲解、检索练习、工作示例或长期阅读体验来判断；需要时优先走 `openprd learn .` 生成学习包和阅读器，不要用关键词表触发。
+6. 界面、页面、视觉、样式、信息架构或前端体验任务进入实现前，先读取 `$openprd-frontend-design`，并用 `.openprd/design/active/` 补齐 `facts-sheet / asset-spec / image-preflight / direction-plan / selected-direction`；空白工作区优先从 `.openprd/design/templates/` 选最近模板。若用户已经给了效果图、设计稿、参考截图或其他明确参考图，先把它当成主参考源；只有现有 starter、theme、layout 足够接近时才复用，不接近就允许偏离默认组合，以参考图为准。若当前轮用户已经把页面主题、模块范围或“直接实现”的意图说清，优先运行 `openprd run . --context --message <用户原话>`。若页面主题和模块范围已经明确，优先运行 `openprd design-starter . --starter <starter-id> --out index.html --brief "<页面主题>" --sections "<模块1|模块2|模块3>"` 起第一版真实页面；只有这个页面本来就不依赖外部产品事实、品牌素材或真实图片时，才在 active design artifacts 写清无依赖并补 `--no-external-facts --no-brand-assets --no-real-images`；若题目更像旅游、导览、展览、博物馆、城市、自然观察或案例内容页，先不要带 `--no-real-images`，让 starter 先尝试补首批真实图片；若这类冷启动即使带 message 仍短暂返回 `clarify-user`，把它当成摘要级提醒，先用 3 到 5 行 mini-plan 收口，再继续。starter 落地后默认进入 `Patch Mode`，必须直接在生成的入口文件上补丁修改；即使结构要大改，也是在同一路径内覆盖，不做 delete-first，更不要删除 `index.html` 后另起新稿。如果确实要整页重写，先把完整新稿写到 sibling draft，例如 `index.next.html`，确认内容成形后再覆盖回 `index.html`，不要让正式入口出现空窗；starter 一落地后，只允许做一轮就地对焦：快速读一次生成的入口文件和必要的 active design artifacts；这轮对焦结束后，下一步就必须是真实写入口，不要再回头搜网页、翻 `docs/basic/` 或继续模板漫游；把最后一批必要的查事实、查图、读模板动作放在口头宣布之前做完；一旦已经说“开始覆盖入口文件”或“开始整页重写”，下一步必须出现真实写文件动作，而不是继续只读浏览、压图或停在口头承诺；必要时 hook 会把这类非写入动作挡回去；`Patch Mode` 完成不等于只补合同、只下载素材或只写计划；至少要把入口文件本体改完、主要占位清掉，并把已准备好的真实图片或参考约束真正落进页面；没有明确参考方向时，不要直接落回同一种安全极简解。
+7. 用户给出会话 ID 并要求继续时，按工具无关的历史会话续接；不要要求工具专属 ID，也不要用当前 active change 或相似历史替代指定会话。
+8. 单个 task 收尾时只运行本任务最小足够验证，并通过 `--evidence`、测试报告或任务 metadata 留下 task-scoped evidence；代码修改完成后、最终回复前，针对本轮实际 touched code files 运行 `openprd dev-check . <file...>`。阶段收口、全部实现完成、handoff/commit/release/publish 前，再运行 `openprd standards . --verify`、`openprd quality . --verify` 和 `openprd run . --verify`；L2 或跨页面实现的最终回复必须列出最新 HTML 质量报告和 task-scoped Markdown/HTML 测试报告路径。如果还没有 `.openprd/harness/test-reports/` 下的 Markdown / HTML 测试报告，就不要把状态表述成项目级已经闭环。
+9. 微信小程序相关任务默认按“最小足够验证”执行：只有用户明确要求小程序实测、截图、抓日志/网络、复现问题，或当前改动必须依赖运行态证据时，才升级到本地小程序运行态验证；默认沿用当前小程序运行态或开发者工具会话连续验证，不要为了验证自动重开应用；只有用户明确要求从 0 到 1、冷启动或重开时，才从头启动。如果当前客户端没有相应工具，不要假定已经安装，也不要把缺少工具当成阻断。
+10. `openprd init/setup/update/doctor` 记录的 `optionalCapabilities` 是非阻断式增强建议。当前任务明显受益但能力还未配置时，可在后续建议里说明它能帮什么、附官方文档 / GitHub 链接，并询问用户是否需要按当前客户端补配置；不要因为它未配置就阻断当前任务。
 
 ### Hook-Enforced Gates
 
 - requirement：需求未完成 `clarify/review/change/tasks` 前阻断实现写入；tasks 就绪后，只有用户原始意图已明确要求实现，或后续在看过执行确认清单后明确发出执行指令时才放行。
 - research：公开 GitHub 架构/对标先 DeepWiki；第三方技术用法、配置、限制、版本差异或迁移先查本地证据，不足时再按 `resolve_library_id -> query_docs` 使用 Context7。
+- design：界面、页面、视觉和前端体验任务进入实现前，先读取 `$openprd-frontend-design`，并补齐 `.openprd/design/active/` 下的事实、素材、图片和方向合同。
 - skill-visualization：修改 skill、`SKILL.md`、`AGENTS.md` 或相关 workflow 前，先输出彩色 Mermaid 方案并等待用户确认。
 - secrets / weapp / browser / copy：分别处理 `secrets-vault`、按需的小程序运行态验证、窗口归属与 i18n/普通用户文案提醒。
 - 需要细节时，读 router 指向的 skill 和 command catalog，而不是继续扩写 `AGENTS.md`。