@openprd/cli 0.1.0 → 0.1.8

package/.openprd/state/current.json

@@ -2,7 +2,7 @@
   "version": 1,
   "status": "synthesized",
   "activeEngagement": "active",
-  "prdVersion": 1,
+  "prdVersion": 5,
   "productType": "agent",
   "templatePack": "agent",
   "projectRoot": ".",
@@ -25,145 +25,481 @@
   "captureMeta": {
     "meta.productType": {
       "source": "user-confirmed",
-      "capturedAt": "2026-05-24 01:55:15"
+      "capturedAt": "2026-06-02 11:39:56"
     },
     "problem.problemStatement": {
       "source": "user-confirmed",
-      "capturedAt": "2026-05-24 01:56:48"
+      "capturedAt": "2026-06-02 13:28:35"
     },
     "problem.whyNow": {
       "source": "user-confirmed",
-      "capturedAt": "2026-05-24 01:56:48"
+      "capturedAt": "2026-06-02 13:28:35"
     },
     "users.primaryUsers": {
       "source": "user-confirmed",
-      "capturedAt": "2026-05-24 01:55:27"
+      "capturedAt": "2026-06-02 13:28:21"
     },
     "goals.goals": {
       "source": "user-confirmed",
-      "capturedAt": "2026-05-24 01:55:31"
+      "capturedAt": "2026-06-02 13:28:21"
     },
     "goals.successMetrics": {
       "source": "user-confirmed",
-      "capturedAt": "2026-05-24 01:55:36"
+      "capturedAt": "2026-06-02 13:28:21"
     },
     "scope.inScope": {
       "source": "user-confirmed",
-      "capturedAt": "2026-05-24 01:55:40"
+      "capturedAt": "2026-06-02 13:28:21"
     },
     "scope.outOfScope": {
       "source": "user-confirmed",
-      "capturedAt": "2026-05-24 01:55:44"
+      "capturedAt": "2026-06-02 13:28:21"
     },
     "scenarios.primaryFlows": {
       "source": "user-confirmed",
-      "capturedAt": "2026-05-24 01:55:49"
+      "capturedAt": "2026-06-02 13:28:21"
     },
     "goals.acceptanceGoals": {
       "source": "user-confirmed",
-      "capturedAt": "2026-05-24 01:56:11"
+      "capturedAt": "2026-06-02 13:28:21"
     },
     "scenarios.failureModes": {
       "source": "user-confirmed",
-      "capturedAt": "2026-05-24 01:56:15"
+      "capturedAt": "2026-06-02 13:28:21"
     },
     "risks.openQuestions": {
       "source": "user-confirmed",
-      "capturedAt": "2026-05-24 01:56:20"
+      "capturedAt": "2026-06-02 13:28:21"
     },
     "typeSpecific.fields.humanAgentContract": {
       "source": "user-confirmed",
-      "capturedAt": "2026-05-24 01:56:24"
+      "capturedAt": "2026-06-02 13:28:21"
     },
     "typeSpecific.fields.autonomyBoundary": {
       "source": "user-confirmed",
-      "capturedAt": "2026-05-24 01:56:28"
+      "capturedAt": "2026-06-02 13:28:21"
     },
     "typeSpecific.fields.toolBoundary": {
       "source": "user-confirmed",
-      "capturedAt": "2026-05-24 01:56:32"
+      "capturedAt": "2026-06-02 13:28:21"
     },
     "typeSpecific.fields.stateModel": {
       "source": "user-confirmed",
-      "capturedAt": "2026-05-24 01:56:37"
+      "capturedAt": "2026-06-02 13:28:21"
     },
     "typeSpecific.fields.evalPlan": {
       "source": "user-confirmed",
-      "capturedAt": "2026-05-24 01:56:41"
+      "capturedAt": "2026-06-02 13:28:21"
     },
     "meta.title": {
       "source": "user-confirmed",
-      "capturedAt": "2026-05-24 01:56:48"
+      "capturedAt": "2026-06-02 13:28:35"
     },
     "meta.owner": {
       "source": "user-confirmed",
-      "capturedAt": "2026-05-24 01:56:48"
+      "capturedAt": "2026-06-02 13:28:35"
+    },
+    "users.stakeholders": {
+      "source": "user-confirmed",
+      "capturedAt": "2026-06-02 13:28:21"
+    },
+    "scenarios.edgeCases": {
+      "source": "user-confirmed",
+      "capturedAt": "2026-06-02 13:28:21"
+    },
+    "requirements.functional": {
+      "source": "user-confirmed",
+      "capturedAt": "2026-06-02 13:28:21"
+    },
+    "requirements.nonFunctional": {
+      "source": "user-confirmed",
+      "capturedAt": "2026-06-02 13:28:21"
+    },
+    "requirements.businessRules": {
+      "source": "user-confirmed",
+      "capturedAt": "2026-06-02 13:28:21"
+    },
+    "constraints.technical": {
+      "source": "user-confirmed",
+      "capturedAt": "2026-06-02 13:28:21"
+    },
+    "constraints.dependencies": {
+      "source": "user-confirmed",
+      "capturedAt": "2026-06-02 13:28:21"
+    },
+    "risks.assumptions": {
+      "source": "user-confirmed",
+      "capturedAt": "2026-06-02 13:28:21"
+    },
+    "risks.risks": {
+      "source": "user-confirmed",
+      "capturedAt": "2026-06-02 13:28:21"
+    },
+    "handoff.owner": {
+      "source": "user-confirmed",
+      "capturedAt": "2026-06-02 13:28:21"
+    },
+    "handoff.nextStep": {
+      "source": "user-confirmed",
+      "capturedAt": "2026-06-02 13:28:21"
+    },
+    "handoff.targetSystem": {
+      "source": "user-confirmed",
+      "capturedAt": "2026-06-02 13:28:21"
+    },
+    "businessGuardrails.costDrivers": {
+      "source": "user-confirmed",
+      "capturedAt": "2026-06-02 13:28:21"
+    },
+    "businessGuardrails.usageLimits": {
+      "source": "user-confirmed",
+      "capturedAt": "2026-06-02 13:28:21"
+    },
+    "businessGuardrails.abusePrevention": {
+      "source": "user-confirmed",
+      "capturedAt": "2026-06-02 13:28:21"
+    },
+    "businessGuardrails.monitoringSignals": {
+      "source": "user-confirmed",
+      "capturedAt": "2026-06-02 13:28:21"
+    },
+    "businessGuardrails.alertThresholds": {
+      "source": "user-confirmed",
+      "capturedAt": "2026-06-02 13:28:21"
+    },
+    "businessGuardrails.stopLossActions": {
+      "source": "user-confirmed",
+      "capturedAt": "2026-06-02 13:28:21"
+    },
+    "problem.evidence": {
+      "source": "user-confirmed",
+      "capturedAt": "2026-06-02 13:28:28"
+    },
+    "constraints.compliance": {
+      "source": "user-confirmed",
+      "capturedAt": "2026-06-02 13:28:28"
     }
   },
-  "classifiedAt": "2026-05-24 01:55:15",
-  "problemStatement": "修复 OpenPrd 的 verify 边界，让 run/verify 和 standards/quality 默认不再把仓库中的外部参考目录当作当前项目源码或 reference discovery 结果混入主验证。",
-  "lastCapturedAt": "2026-05-24 01:56:41",
-  "whyNow": "现有行为会让历史项目的 verify 被外部参考目录噪音阻塞，也会把 reference discovery 直接带进 run 上下文，影响可用性和对门禁结果的信任。",
+  "classifiedAt": "2026-06-02 11:39:56",
+  "problemStatement": "OpenPrd 在用户第一次提需求时虽然已经有 consumer / b2b / agent 分流、clarify 和后续 review/change/tasks 流程，但缺少一个项目级的首轮画像层。结果是 Agent 容易直接围绕局部需求推进，而没有先确认用户群体、产品形态、第一版切片、先不做什么、不能破坏什么，以及是否命中技术和业务风险。",
+  "lastCapturedAt": "2026-06-02 13:28:28",
+  "whyNow": "用户明确指出 Vibe Coding 场景下的首轮需求往往模糊：如果不先建立整体轮廓，后续容易返工；如果一上来就强制填写重问卷，又会压垮首轮体验。因此需要把初始化改成轻量项目画像加条件追问。",
   "primaryUsers": [
-    "维护 OpenPrd 的 Agent 工程师",
-    "使用 OpenPrd 管理历史项目的项目维护者"
+    "第一次用 OpenPrd 梳理产品想法的产品经理、独立开发者与 Vibe Coding 用户",
+    "需要在模糊需求下帮助用户收敛方向并继续落地的 Agent 协作者"
   ],
   "goals": [
-    "让主验证只关注当前项目源码和当前实现门禁",
-    "让历史项目刷新后默认获得更干净的 verify 体验"
+    "在第一次提需时先形成一页轻量项目画像，而不是直接跳进局部需求修改",
+    "让系统优先归纳 to C / to B / agent、目标用户、产品形态、第一版切片、非目标和保护项，再请用户确认",
+    "当信息不足时，用条件追问或候选原型方向补齐，而不是要求用户一开始回答完整技术和商业问卷"
   ],
   "successMetrics": [
-    "存在 reference discovery 时 openprd run . --context 不再默认展示它",
-    "仓库内常见外部参考目录在未人工归类前不再直接把 standards verify 阻塞成大面积说明书噪音",
-    "openprd fleet 更新后历史项目生成物包含这次修复"
+    "首轮 clarify 能输出结构化的项目画像摘要，并包含用户群体、产品形态、第一版先做、先不做和不能破坏项",
+    "复杂或模糊需求会触发技术/风险追问，简单明确需求仍保持轻量",
+    "默认 clarify 仍在对话内完成，不新增新的 clarify HTML",
+    "用户能够更快确认方向，后续 PRD 和实现阶段减少返工与错题"
   ],
   "inScope": [
-    "调整 run context 与 run verify 对 discovery 的纳入规则",
-    "调整 standards/source-manual 默认对明显外部参考目录的处理策略",
-    "为历史项目执行 openprd fleet 更新与必要回填"
+    "在 clarify、intake-reflection 和 interview 中加入首轮项目画像层",
+    "让系统先推断 consumer / b2b / agent 与项目形态，再结合第一版切片、非目标、保护项组织追问",
+    "命中技术和业务风险信号时再展开前后端、数据、账号、AI、外部服务、收费等边界问题",
+    "同步更新模板、技能说明、基础文档、CLI 输出和相关测试"
   ],
   "outOfScope": [
-    "不自动替每个历史项目猜测所有业务目录的 externalReferences 清单",
-    "不修改历史项目的业务代码或需求内容",
-    "不把人工确认 external reference 的能力删除"
+    "不把首次提需改成一份重型强制问卷",
+    "不把商业模式或技术架构变成所有场景的硬必填 schema",
+    "不新增默认 clarify HTML 或额外前端评审页面",
+    "不让局部小修进入完整项目画像重流程"
   ],
   "primaryFlows": [
-    "维护者运行 openprd run . --context 或 openprd run . --verify 时，只看到当前项目主验证状态；仓库中存在 research、toolkit-sources、marketplace-candidates 等参考目录时，默认不会被当成本项目源码说明书缺口直接淹没结果；维护者可以继续按需显式 classify-external。"
+    "用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第一版先做、先不做、不能破坏、技术落点和风险探针",
+    "如果用户表达已经足够清楚，Agent 直接用系统归纳的画像摘要请用户确认",
+    "如果用户表达模糊，Agent 先追问少量高价值问题，必要时给 2 到 3 个方向或行业原型供用户选择",
+    "画像确认后再进入后续 PRD、review、change 和 tasks 流程"
   ],
   "acceptanceGoals": [
-    "run/verify 的默认结果不再把 reference discovery 或明显外部参考目录当成主门禁噪音",
-    "历史项目刷新后生成物能承接这次边界修复",
-    "对需要人工确认的 external reference 仍保留显式 classify-external 路径"
+    "workspace-workflow 能生成首轮项目画像、风险探针和更贴近用户语言的确认问题",
+    "workspace-core 的冷启动 kickoff 问题升级为画像导向问题",
+    "intake 模板、skills、docs、CLI 文本输出和测试与新流程保持一致"
   ],
   "failureModes": [
-    "reference discovery 仍然混入 run context 或 run verify",
-    "standards verify 继续被 research 或 toolkit-sources 之类参考目录的说明书缺口淹没",
-    "fleet 更新后历史项目仍保留旧的 verify 噪音行为"
+    "入口过重，导致 Vibe Coding 用户在第一次提需时无法回答",
+    "入口过轻，导致 Agent 没有先确认项目边界就直接落地",
+    "错误复用旧 active change 或旧 PRD 上下文，导致实现偏题"
   ],
   "openQuestions": [
-    "本次只收敛默认边界，不自动猜测每个历史项目全部 external reference 清单；如果某些项目还需要更细的目录级归类，仍由维护者显式确认和补充"
-  ],
-  "humanAgentContract": "Agent 可以识别并提示 reference discovery 与外部参考目录边界，但把目录正式归类为 external reference 仍需要人确认；批量刷新历史项目可以自动执行。",
-  "autonomyBoundary": "Agent 可以修改 OpenPrd CLI、补测试、更新文档、运行 fleet dry-run 与 update-openprd/backfill-work-units，并验证结果；不得静默把任意历史目录永久归类为 external reference。",
-  "toolBoundary": "使用本地代码检索、OpenPrd CLI、自带测试、fleet 更新、doctor 与 verify 完成实现和验证；本次不需要外部第三方文档调研。",
-  "stateModel": "需要保留三类状态：当前项目源码验证状态、reference discovery 状态、standards external reference 显式配置；主 run/verify 只默认消费第一类，其他两类按边界显式暴露。",
-  "evalPlan": "通过针对 run-harness、standards 和 fleet 的单测与集成验证评估；再用历史项目 dry-run 与 update-openprd/backfill-work-units 验证刷新结果。",
-  "latestVersionId": "v0001",
-  "latestVersionDigest": "dc988d7a94c07d2a8070968a71ddacffb374eaeee12aa85eb93231e06dd7b077",
-  "activeWorkUnitId": "wu-20260524015648-6d33ded7",
+    "后续是否需要单独的 profile review artifact 或 diagram，用于更复杂的多系统场景"
+  ],
+  "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。",
   "targetRoot": "/Users/chaojifeng/Projects/harness-engineer/openprd",
   "reviewStatus": {
-    "versionId": "v0001",
-    "workUnitId": "wu-20260524015648-6d33ded7",
+    "versionId": "v0005",
+    "workUnitId": "wu-20260602132835-695429e8",
     "status": "confirmed",
+    "reviewPath": "/Users/chaojifeng/Projects/harness-engineer/openprd/.openprd/reviews/v0005.html",
+    "entryPath": "/Users/chaojifeng/Projects/harness-engineer/openprd/.openprd/engagements/active/review.html",
     "artifact": "/Users/chaojifeng/Projects/harness-engineer/openprd/.openprd/engagements/active/review.html",
-    "stableArtifact": "/Users/chaojifeng/Projects/harness-engineer/openprd/.openprd/reviews/v0001.html",
-    "updatedAt": "2026-05-24 01:56:54",
-    "notes": "用户已明确要求直接修复 verify 边界并刷新历史项目。",
-    "reviewPath": "/Users/chaojifeng/Projects/harness-engineer/openprd/.openprd/reviews/v0001.html",
-    "entryPath": "/Users/chaojifeng/Projects/harness-engineer/openprd/.openprd/engagements/active/review.html"
+    "stableArtifact": "/Users/chaojifeng/Projects/harness-engineer/openprd/.openprd/reviews/v0005.html",
+    "updatedAt": "2026-06-02 13:29:01",
+    "notes": null
   },
-  "title": "Verify 边界与历史项目刷新",
+  "title": "OpenPrd 首轮项目画像与自适应需求初始化",
   "owner": "Codex",
-  "synthesizedAt": "2026-05-24 01:56:48"
+  "synthesizedAt": "2026-06-02 13:28:35",
+  "stakeholders": [
+    "维护 OpenPrd requirement-intake、workflow 和模板的开发者",
+    "后续需要基于已确认上下文继续实现的多轮 Agent 会话"
+  ],
+  "edgeCases": [
+    "用户一开始只有一句模糊想法，需要先给候选方向而不是硬追问技术细节",
+    "已有项目上下文时应优先沿用已知事实，而不是把所有画像问题重问一遍",
+    "局部 copy、样式或小交互修正不应被错误升级成重画像流程"
+  ],
+  "functional": [
+    "clarify 生成的 intake-reflection 应包含首轮项目画像和风险探针",
+    "inline clarification 应显式展示适用对象、产品形态、第一版先做、先不做、不能破坏和技术落点",
+    "冷启动 kickoff 问题改成画像导向问题，而不是抽象的通用提问",
+    "类型专项 intake 模板改成更贴近产品与业务语言的提问方式"
+  ],
+  "nonFunctional": [
+    "默认澄清仍要保持对话内、轻量、可扫读",
+    "对已有 schema 和生成流程的侵入应尽量小",
+    "输出语言优先面向产品和业务用户，而不是工程内部黑话"
+  ],
+  "businessRules": [
+    "优先由系统归纳后请用户确认，而不是一开始把所有字段抛给用户",
+    "只有命中风险信号时才展开技术、账号、数据、外部服务或成本相关追问",
+    "consumer / b2b / agent 优先由系统推断，必要时再请用户确认",
+    "clarify 阶段默认不生成 HTML，正式可视化仍留给 review 或 diagram 阶段"
+  ],
+  "technical": [
+    "主要修改 src/workspace-workflow.js、src/workspace-core.js、CLI 文本输出、.openprd intake 模板、skills/docs 和测试",
+    "避免新增新的硬性必填 schema 字段，优先通过 intake 和 clarification 层完成增强"
+  ],
+  "dependencies": [
+    "依赖现有 requirement-intake gate、clarify/capture/synthesize/review/change/tasks 工作流",
+    "依赖现有 base / consumer / b2b / agent 模板与评审产物体系"
+  ],
+  "assumptions": [
+    "Vibe Coding 用户更愿意确认系统总结，而不是先填写长问卷",
+    "现有 lens 分类能力可保留，只需要前移到项目画像语境里"
+  ],
+  "risks": [
+    "如果问题过多，会损伤首次提需体验",
+    "如果画像层和现有 capture/analysis 脱节，会造成重复提问",
+    "如果没有处理旧上下文切换，hook 可能继续把代码修改指向错误 change"
+  ],
+  "handoffOwner": "Codex",
+  "nextStep": "生成新的 change 和 tasks，并按首轮项目画像流程修改 workflow、模板、文档和测试。",
+  "targetSystem": "OpenPrd",
+  "costDrivers": [
+    "本次没有新增第三方付费调用；成本主要来自不准确需求初始化带来的返工和错题"
+  ],
+  "usageLimits": [
+    "不应让每个首次提需都退化成长问卷；默认只问最少必要问题"
+  ],
+  "abusePrevention": [
+    "系统不能把未确认的推断当作最终需求事实",
+    "命中账号、数据、外部服务、AI 或收费信号时，必须显式提醒边界与风险"
+  ],
+  "monitoringSignals": [
+    "观察首轮 clarify 是否仍然过长、是否反复追问同一类信息、是否错误复用旧 change 上下文"
+  ],
+  "alertThresholds": [
+    "如果简单需求被连续升级成深度追问，或复杂需求仍缺少画像摘要，应在测试中显式暴露"
+  ],
+  "stopLossActions": [
+    "当系统无法准确归纳时，退回到少量高价值确认问题，不假装已经清楚",
+    "当当前工作区上下文明显与本轮需求不匹配时，先刷新到新的 change/task 再实现"
+  ],
+  "previousLatestVersionId": null,
+  "previousLatestVersionDigest": null,
+  "previousActiveWorkUnitId": null,
+  "evidence": [
+    "本轮用户明确指出第一次提需缺少 to C / to B / agent、用户群体、商业模式、功能架构和技术边界的前置梳理。",
+    "本地代码检查显示现有 base intake 只覆盖问题、用户、成功、范围与成本信号，缺少独立的首轮项目画像层。",
+    "外部调研表明 Vibe Coding 更适合轻量画像加条件追问，而不是重型初始化问卷。"
+  ],
+  "compliance": [
+    "继续遵守现有 requirement gate、review gate 和 hook 安全边界，不绕过已确认的需求流程。",
+    "新增提示和用户可见文案应保持面向产品与业务语言，不直接暴露内部技术细节。"
+  ],
+  "latestVersionId": "v0005",
+  "latestVersionDigest": "7f0e2d2730982a2ae96647d2377f6204e54f8adadf1b18b05f4bc7167046c575",
+  "activeWorkUnitId": "wu-20260602132835-695429e8",
+  "versionId": "v0005",
+  "versionNumber": 5,
+  "workUnitId": "wu-20260602132835-695429e8",
+  "sections": {
+    "meta": {
+      "title": "OpenPrd 首轮项目画像与自适应需求初始化",
+      "owner": "Codex",
+      "status": "clarifying",
+      "version": "v0005",
+      "productType": "agent",
+      "date": "2026-06-02"
+    },
+    "problem": {
+      "problemStatement": "OpenPrd 在用户第一次提需求时虽然已经有 consumer / b2b / agent 分流、clarify 和后续 review/change/tasks 流程，但缺少一个项目级的首轮画像层。结果是 Agent 容易直接围绕局部需求推进，而没有先确认用户群体、产品形态、第一版切片、先不做什么、不能破坏什么，以及是否命中技术和业务风险。",
+      "whyNow": "用户明确指出 Vibe Coding 场景下的首轮需求往往模糊：如果不先建立整体轮廓，后续容易返工；如果一上来就强制填写重问卷，又会压垮首轮体验。因此需要把初始化改成轻量项目画像加条件追问。",
+      "evidence": [
+        "本轮用户明确指出第一次提需缺少 to C / to B / agent、用户群体、商业模式、功能架构和技术边界的前置梳理。",
+        "本地代码检查显示现有 base intake 只覆盖问题、用户、成功、范围与成本信号，缺少独立的首轮项目画像层。",
+        "外部调研表明 Vibe Coding 更适合轻量画像加条件追问，而不是重型初始化问卷。"
+      ]
+    },
+    "users": {
+      "primaryUsers": [
+        "第一次用 OpenPrd 梳理产品想法的产品经理、独立开发者与 Vibe Coding 用户",
+        "需要在模糊需求下帮助用户收敛方向并继续落地的 Agent 协作者"
+      ],
+      "secondaryUsers": [],
+      "stakeholders": [
+        "维护 OpenPrd requirement-intake、workflow 和模板的开发者",
+        "后续需要基于已确认上下文继续实现的多轮 Agent 会话"
+      ]
+    },
+    "goals": {
+      "goals": [
+        "在第一次提需时先形成一页轻量项目画像，而不是直接跳进局部需求修改",
+        "让系统优先归纳 to C / to B / agent、目标用户、产品形态、第一版切片、非目标和保护项，再请用户确认",
+        "当信息不足时，用条件追问或候选原型方向补齐，而不是要求用户一开始回答完整技术和商业问卷"
+      ],
+      "successMetrics": [
+        "首轮 clarify 能输出结构化的项目画像摘要，并包含用户群体、产品形态、第一版先做、先不做和不能破坏项",
+        "复杂或模糊需求会触发技术/风险追问，简单明确需求仍保持轻量",
+        "默认 clarify 仍在对话内完成，不新增新的 clarify HTML",
+        "用户能够更快确认方向，后续 PRD 和实现阶段减少返工与错题"
+      ],
+      "acceptanceGoals": [
+        "workspace-workflow 能生成首轮项目画像、风险探针和更贴近用户语言的确认问题",
+        "workspace-core 的冷启动 kickoff 问题升级为画像导向问题",
+        "intake 模板、skills、docs、CLI 文本输出和测试与新流程保持一致"
+      ]
+    },
+    "scope": {
+      "inScope": [
+        "在 clarify、intake-reflection 和 interview 中加入首轮项目画像层",
+        "让系统先推断 consumer / b2b / agent 与项目形态，再结合第一版切片、非目标、保护项组织追问",
+        "命中技术和业务风险信号时再展开前后端、数据、账号、AI、外部服务、收费等边界问题",
+        "同步更新模板、技能说明、基础文档、CLI 输出和相关测试"
+      ],
+      "outOfScope": [
+        "不把首次提需改成一份重型强制问卷",
+        "不把商业模式或技术架构变成所有场景的硬必填 schema",
+        "不新增默认 clarify HTML 或额外前端评审页面",
+        "不让局部小修进入完整项目画像重流程"
+      ]
+    },
+    "scenarios": {
+      "primaryFlows": [
+        "用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第一版先做、先不做、不能破坏、技术落点和风险探针",
+        "如果用户表达已经足够清楚，Agent 直接用系统归纳的画像摘要请用户确认",
+        "如果用户表达模糊，Agent 先追问少量高价值问题，必要时给 2 到 3 个方向或行业原型供用户选择",
+        "画像确认后再进入后续 PRD、review、change 和 tasks 流程"
+      ],
+      "edgeCases": [
+        "用户一开始只有一句模糊想法，需要先给候选方向而不是硬追问技术细节",
+        "已有项目上下文时应优先沿用已知事实，而不是把所有画像问题重问一遍",
+        "局部 copy、样式或小交互修正不应被错误升级成重画像流程"
+      ],
+      "failureModes": [
+        "入口过重，导致 Vibe Coding 用户在第一次提需时无法回答",
+        "入口过轻，导致 Agent 没有先确认项目边界就直接落地",
+        "错误复用旧 active change 或旧 PRD 上下文，导致实现偏题"
+      ]
+    },
+    "requirements": {
+      "functional": [
+        "clarify 生成的 intake-reflection 应包含首轮项目画像和风险探针",
+        "inline clarification 应显式展示适用对象、产品形态、第一版先做、先不做、不能破坏和技术落点",
+        "冷启动 kickoff 问题改成画像导向问题，而不是抽象的通用提问",
+        "类型专项 intake 模板改成更贴近产品与业务语言的提问方式"
+      ],
+      "nonFunctional": [
+        "默认澄清仍要保持对话内、轻量、可扫读",
+        "对已有 schema 和生成流程的侵入应尽量小",
+        "输出语言优先面向产品和业务用户，而不是工程内部黑话"
+      ],
+      "businessRules": [
+        "优先由系统归纳后请用户确认，而不是一开始把所有字段抛给用户",
+        "只有命中风险信号时才展开技术、账号、数据、外部服务或成本相关追问",
+        "consumer / b2b / agent 优先由系统推断，必要时再请用户确认",
+        "clarify 阶段默认不生成 HTML，正式可视化仍留给 review 或 diagram 阶段"
+      ]
+    },
+    "businessGuardrails": {
+      "costDrivers": [
+        "本次没有新增第三方付费调用；成本主要来自不准确需求初始化带来的返工和错题"
+      ],
+      "usageLimits": [
+        "不应让每个首次提需都退化成长问卷；默认只问最少必要问题"
+      ],
+      "abusePrevention": [
+        "系统不能把未确认的推断当作最终需求事实",
+        "命中账号、数据、外部服务、AI 或收费信号时，必须显式提醒边界与风险"
+      ],
+      "monitoringSignals": [
+        "观察首轮 clarify 是否仍然过长、是否反复追问同一类信息、是否错误复用旧 change 上下文"
+      ],
+      "alertThresholds": [
+        "如果简单需求被连续升级成深度追问，或复杂需求仍缺少画像摘要，应在测试中显式暴露"
+      ],
+      "stopLossActions": [
+        "当系统无法准确归纳时，退回到少量高价值确认问题，不假装已经清楚",
+        "当当前工作区上下文明显与本轮需求不匹配时，先刷新到新的 change/task 再实现"
+      ]
+    },
+    "constraints": {
+      "technical": [
+        "主要修改 src/workspace-workflow.js、src/workspace-core.js、CLI 文本输出、.openprd intake 模板、skills/docs 和测试",
+        "避免新增新的硬性必填 schema 字段，优先通过 intake 和 clarification 层完成增强"
+      ],
+      "compliance": [
+        "继续遵守现有 requirement gate、review gate 和 hook 安全边界，不绕过已确认的需求流程。",
+        "新增提示和用户可见文案应保持面向产品与业务语言，不直接暴露内部技术细节。"
+      ],
+      "dependencies": [
+        "依赖现有 requirement-intake gate、clarify/capture/synthesize/review/change/tasks 工作流",
+        "依赖现有 base / consumer / b2b / agent 模板与评审产物体系"
+      ]
+    },
+    "risks": {
+      "assumptions": [
+        "Vibe Coding 用户更愿意确认系统总结，而不是先填写长问卷",
+        "现有 lens 分类能力可保留，只需要前移到项目画像语境里"
+      ],
+      "risks": [
+        "如果问题过多，会损伤首次提需体验",
+        "如果画像层和现有 capture/analysis 脱节，会造成重复提问",
+        "如果没有处理旧上下文切换，hook 可能继续把代码修改指向错误 change"
+      ],
+      "openQuestions": [
+        "后续是否需要单独的 profile review artifact 或 diagram，用于更复杂的多系统场景"
+      ]
+    },
+    "handoff": {
+      "owner": "Codex",
+      "nextStep": "生成新的 change 和 tasks，并按首轮项目画像流程修改 workflow、模板、文档和测试。",
+      "targetSystem": "OpenPrd"
+    },
+    "typeSpecific": {
+      "kind": "agent",
+      "title": "Agent 专项",
+      "fields": {
+        "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。"
+      }
+    }
+  },
+  "content": "# OpenPrd 首轮项目画像与自适应需求初始化\n> 语言规则：默认用简体中文生成 PRD、spec、tasks 和用户可见说明；除 PRD、OpenPrd、OpenSpec、API、SDK、CLI、TypeScript、JSON、HTTP、WebSocket、字段 key、命令名、品牌名、产品名和协议名等必要专有名词外，其余内容优先写成简体中文。\n- 版本: v0005\n- 负责人: Codex\n- 产品类型: agent\n- 模板包: agent\n- 状态: synthesized\n- 生成时间: 2026-06-02 13:28:35\n## 元信息\n\n- 标题: OpenPrd 首轮项目画像与自适应需求初始化\n- 负责人: Codex\n- 状态: clarifying\n- 版本: v0005\n- 产品类型: agent\n- 日期: 2026-06-02\n\n## 问题\n\n- 问题陈述: OpenPrd 在用户第一次提需求时虽然已经有 consumer / b2b / agent 分流、clarify 和后续 review/change/tasks 流程，但缺少一个项目级的首轮画像层。结果是 Agent 容易直接围绕局部需求推进，而没有先确认用户群体、产品形态、第一版切片、先不做什么、不能破坏什么，以及是否命中技术和业务风险。\n- 为什么是现在: 用户明确指出 Vibe Coding 场景下的首轮需求往往模糊：如果不先建立整体轮廓，后续容易返工；如果一上来就强制填写重问卷，又会压垮首轮体验。因此需要把初始化改成轻量项目画像加条件追问。\n- 证据:\n  - 本轮用户明确指出第一次提需缺少 to C / to B / agent、用户群体、商业模式、功能架构和技术边界的前置梳理。\n  - 本地代码检查显示现有 base intake 只覆盖问题、用户、成功、范围与成本信号，缺少独立的首轮项目画像层。\n  - 外部调研表明 Vibe Coding 更适合轻量画像加条件追问，而不是重型初始化问卷。\n\n## 用户与相关方\n\n- 主要用户:\n  - 第一次用 OpenPrd 梳理产品想法的产品经理、独立开发者与 Vibe Coding 用户\n  - 需要在模糊需求下帮助用户收敛方向并继续落地的 Agent 协作者\n- 次要用户:\n  - 待补充\n- 相关方:\n  - 维护 OpenPrd requirement-intake、workflow 和模板的开发者\n  - 后续需要基于已确认上下文继续实现的多轮 Agent 会话\n\n## 目标与成功标准\n\n- 目标:\n  - 在第一次提需时先形成一页轻量项目画像，而不是直接跳进局部需求修改\n  - 让系统优先归纳 to C / to B / agent、目标用户、产品形态、第一版切片、非目标和保护项，再请用户确认\n  - 当信息不足时，用条件追问或候选原型方向补齐，而不是要求用户一开始回答完整技术和商业问卷\n- 成功指标:\n  - 首轮 clarify 能输出结构化的项目画像摘要，并包含用户群体、产品形态、第一版先做、先不做和不能破坏项\n  - 复杂或模糊需求会触发技术/风险追问，简单明确需求仍保持轻量\n  - 默认 clarify 仍在对话内完成，不新增新的 clarify HTML\n  - 用户能够更快确认方向，后续 PRD 和实现阶段减少返工与错题\n- 验收目标:\n  - workspace-workflow 能生成首轮项目画像、风险探针和更贴近用户语言的确认问题\n  - workspace-core 的冷启动 kickoff 问题升级为画像导向问题\n  - intake 模板、skills、docs、CLI 文本输出和测试与新流程保持一致\n\n## 范围与非目标\n\n- 范围内:\n  - 在 clarify、intake-reflection 和 interview 中加入首轮项目画像层\n  - 让系统先推断 consumer / b2b / agent 与项目形态，再结合第一版切片、非目标、保护项组织追问\n  - 命中技术和业务风险信号时再展开前后端、数据、账号、AI、外部服务、收费等边界问题\n  - 同步更新模板、技能说明、基础文档、CLI 输出和相关测试\n- 范围外:\n  - 不把首次提需改成一份重型强制问卷\n  - 不把商业模式或技术架构变成所有场景的硬必填 schema\n  - 不新增默认 clarify HTML 或额外前端评审页面\n  - 不让局部小修进入完整项目画像重流程\n\n## 场景与流程\n\n- 主流程:\n  - 用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第一版先做、先不做、不能破坏、技术落点和风险探针\n  - 如果用户表达已经足够清楚，Agent 直接用系统归纳的画像摘要请用户确认\n  - 如果用户表达模糊，Agent 先追问少量高价值问题，必要时给 2 到 3 个方向或行业原型供用户选择\n  - 画像确认后再进入后续 PRD、review、change 和 tasks 流程\n- 边界情况:\n  - 用户一开始只有一句模糊想法，需要先给候选方向而不是硬追问技术细节\n  - 已有项目上下文时应优先沿用已知事实，而不是把所有画像问题重问一遍\n  - 局部 copy、样式或小交互修正不应被错误升级成重画像流程\n- 失败模式:\n  - 入口过重，导致 Vibe Coding 用户在第一次提需时无法回答\n  - 入口过轻，导致 Agent 没有先确认项目边界就直接落地\n  - 错误复用旧 active change 或旧 PRD 上下文，导致实现偏题\n\n## 可视化图表\n\n### 产品流程\n\n```mermaid\nflowchart LR\n  entry[\"入口触发<br/>用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第一版先做、先不做、不能破坏、技术落点和风险探针\"]\n  experience[\"产品内步骤<br/>如果用户表达已经足够清楚，Agent 直接用系统归纳的画像摘要请用户确认\"]\n  decision{\"决策点<br/>用户一开始只有一句模糊想法，需要先给候选方向而不是硬追问技术细节\"}\n  success([\"成功结果<br/>首轮 clarify 能输出结构化的项目画像摘要，并包含用户群体、产品形态、第一版先做、先不做和不能破坏项\"])\n  failure[[\"失败与恢复<br/>入口过重，导致 Vibe Coding 用户在第一次提需时无法回答\"]]\n  entry -->|\"用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第一版…\"| experience\n  experience -->|\"如果用户表达已经足够清楚，Agent 直接用系统归纳的画像摘要请用户确认\"| decision\n  decision -->|\"在第一次提需时先形成一页轻量项目画像，而不是直接跳进局部需求修改\"| success\n  decision -.->|\"入口过重，导致 Vibe Coding 用户在第一次提需时无法回答\"| failure\n```\n\n### 架构\n\n```mermaid\nflowchart LR\n  users[\"主要用户<br/>第一次用 OpenPrd 梳理产品想法的产品经理、独立开发者与 Vibe Coding 用户 · 需要在模糊需求下帮助用户收敛…\"]\n  subgraph solution[\"方案边界\"]\n    experience[\"Agent 运行层<br/>用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第一版先做、先不做、不能破坏、技术落点和风险探针 …\"]\n    core[\"核心产品逻辑<br/>OpenPrd 在用户第一次提需求时虽然已经有 consumer / b2b / agent 分流、clarify 和后续 r…\"]\n    integrations[\"依赖与集成<br/>依赖现有 requirement-intake gate、clarify/capture/synthesize/review/…\"]\n    governance[[\"约束与可靠性<br/>继续遵守现有 requirement gate、review gate 和 hook 安全边界，不绕过已确认的需求流程。 · …\"]]\n    delivery[\"验证与交接<br/>首轮 clarify 能输出结构化的项目画像摘要，并包含用户群体、产品形态、第一版先做、先不做和不能破坏项 · 复杂或模糊需求…\"]\n  end\n  users -->|\"用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第…\"| experience\n  experience -->|\"产品动作与编排\"| core\n  core -->|\"依赖与外部服务\"| integrations\n  core -.->|\"策略、可靠性与合规\"| governance\n  core -->|\"成功标准与交接\"| delivery\n  integrations -->|\"运营就绪\"| delivery\n  governance -.->|\"评审与确认\"| delivery\n```\n\n## 需求\n\n- 功能需求:\n  - clarify 生成的 intake-reflection 应包含首轮项目画像和风险探针\n  - inline clarification 应显式展示适用对象、产品形态、第一版先做、先不做、不能破坏和技术落点\n  - 冷启动 kickoff 问题改成画像导向问题，而不是抽象的通用提问\n  - 类型专项 intake 模板改成更贴近产品与业务语言的提问方式\n- 非功能需求:\n  - 默认澄清仍要保持对话内、轻量、可扫读\n  - 对已有 schema 和生成流程的侵入应尽量小\n  - 输出语言优先面向产品和业务用户，而不是工程内部黑话\n- 业务规则:\n  - 优先由系统归纳后请用户确认，而不是一开始把所有字段抛给用户\n  - 只有命中风险信号时才展开技术、账号、数据、外部服务或成本相关追问\n  - consumer / b2b / agent 优先由系统推断，必要时再请用户确认\n  - clarify 阶段默认不生成 HTML，正式可视化仍留给 review 或 diagram 阶段\n\n## 业务护栏\n\n- 成本来源:\n  - 本次没有新增第三方付费调用；成本主要来自不准确需求初始化带来的返工和错题\n- 额度与限制:\n  - 不应让每个首次提需都退化成长问卷；默认只问最少必要问题\n- 滥用防护:\n  - 系统不能把未确认的推断当作最终需求事实\n  - 命中账号、数据、外部服务、AI 或收费信号时，必须显式提醒边界与风险\n- 监控信号:\n  - 观察首轮 clarify 是否仍然过长、是否反复追问同一类信息、是否错误复用旧 change 上下文\n- 报警阈值:\n  - 如果简单需求被连续升级成深度追问，或复杂需求仍缺少画像摘要，应在测试中显式暴露\n- 止损动作:\n  - 当系统无法准确归纳时，退回到少量高价值确认问题，不假装已经清楚\n  - 当当前工作区上下文明显与本轮需求不匹配时，先刷新到新的 change/task 再实现\n\n## 约束、依赖与风险\n\n- 技术约束:\n  - 主要修改 src/workspace-workflow.js、src/workspace-core.js、CLI 文本输出、.openprd intake 模板、skills/docs 和测试\n  - 避免新增新的硬性必填 schema 字段，优先通过 intake 和 clarification 层完成增强\n- 合规要求:\n  - 继续遵守现有 requirement gate、review gate 和 hook 安全边界，不绕过已确认的需求流程。\n  - 新增提示和用户可见文案应保持面向产品与业务语言，不直接暴露内部技术细节。\n- 依赖:\n  - 依赖现有 requirement-intake gate、clarify/capture/synthesize/review/change/tasks 工作流\n  - 依赖现有 base / consumer / b2b / agent 模板与评审产物体系\n- 假设:\n  - Vibe Coding 用户更愿意确认系统总结，而不是先填写长问卷\n  - 现有 lens 分类能力可保留，只需要前移到项目画像语境里\n- 风险:\n  - 如果问题过多，会损伤首次提需体验\n  - 如果画像层和现有 capture/analysis 脱节，会造成重复提问\n  - 如果没有处理旧上下文切换，hook 可能继续把代码修改指向错误 change\n- 开放问题:\n  - 后续是否需要单独的 profile review artifact 或 diagram，用于更复杂的多系统场景\n\n## 类型专项模块\n\n- 类型: Agent 专项\n- humanAgentContract: Agent 先归纳用户群体、产品形态、第一版切片、边界与风险，再请求用户确认；如果信息不足，只能提出候选方向，不能把猜测当成定论。\n- autonomyBoundary: Agent 可以根据当前需求和已有工作区状态推断首轮项目画像，但在用户确认前不得把推断直接写成最终需求事实或越过需求入口去改实现。\n- toolBoundary: 仅使用本地 OpenPrd workflow、模板、测试和文档完成这次改动，不依赖新的外部运行时。\n- stateModel: 新需求进入时先形成 project framing，再进入 requirement clarification、review/change/tasks 与实现。\n- evalPlan: 通过 workspace flow、requirement gate、CLI 输出和模板相关测试验证新流程，同时运行 dev-check、standards、quality 与 run verify。\n\n## 交接\n\n- 负责人: Codex\n- 下一步: 生成新的 change 和 tasks，并按首轮项目画像流程修改 workflow、模板、文档和测试。\n- 目标系统: OpenPrd\n",
+  "digest": "7f0e2d2730982a2ae96647d2377f6204e54f8adadf1b18b05f4bc7167046c575",
+  "reviewPresentationMeta": null
 }