@openprd/cli 0.1.21 → 0.1.22

package/AGENTS.md

@@ -28,10 +28,10 @@
 1a. 互动或显式启用 OpenPrd 的场景，再从 `.openprd/` 重建状态，并先运行 `openprd run . --context`；它是建议上下文，不是自动执行指令。
 1a. 代码搜索默认从当前任务相关源码、测试和 change/task 文件起步；不要把 `.openprd/quality/reports/`、`.openprd/harness/` 或 `.openprd/learning/` 当源码目录做 repo-wide `rg`。质量报告只在需要审阅就绪证据时按最新报告路径显式读取。
 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 表格，帮助用户一眼看清；`需求判断` 和 `需求理解` 先用 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 已就绪但还需要执行授权时，先给执行确认清单再请用户确认。
+3. 先分流再执行：`openprd-requirement-intake` 按影响面、未知数、决策成本和验证成本判断需求类型，并保留内部路由码对照：直接处理=L0，现有功能优化=L1，新功能/新流程方案=L2。用户审查默认把路由码并进“需求类型：直接处理（L0）”这类标签里；只有内部排障确实受益时，才额外附“内部路由码”。直接处理类需求可直接处理并事后说明，不打开正式 PRD/review/change/tasks；现有功能优化先在对话内给 mini-plan 再执行，默认不生成正式 PRD/change/tasks；如果用户刚刚已经确认了 L1 mini-plan、范围边界或正式产品边界，后续承接要写成“已确认，我按这个继续”，不要用“确认，我们就按这个……”这类像再次索取确认的句子。新功能/新流程方案的 requirement、PRD、review、change 和 tasks 由 Agent 在后台维护，不阻断用户已经要求的实现。L2 的 requirement 摘要默认按“需求判断 / 需求理解 / 功能范围 / 技术方案”来写，其中“功能范围”和“技术方案”优先用 Markdown 表格，帮助用户一眼看清；`需求判断` 和 `需求理解` 先用 1 到 2 句轻量主句说清这次是什么、核心问题和第一版目标，边界、风险、异常例子和技术细节下沉到后面的分项或表格，不要把它们都塞进一整段长话里，也不要把某条示例文案写成固定模板。若当前仍在 0 到 1 探索、脑暴或值不值得做的判断，摘要里还要主动补上“验证与创业闭环”：第一批最容易触达的社区或种子用户、你为什么算这个社区里的自己人、当前替代方案和痛点证据、先怎么手工交付、手工作战卡怎么写、能不能先用 spreadsheet / 表单 / no-code 跑起来、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、第一版只做哪一件事、能不能压成周末级 MVP、第一批客户路径、从第一个客户开始怎么收费、客户 1 如何打平成本、有没有 10 个样本和更强付费信号、达到什么条件才允许产品化、增长阶段守什么纪律、这条路是否可逆、是否真在解决客户问题、以及是否符合团队价值观、是不是你愿意长期住进去的业务形态。L2 的需求摘要是 Agent 后台维护材料，不创建用户确认停顿。如果 `openprd run . --context` 建议 `clarify-user`，Agent 优先选择可逆默认方案并显式说明假设；是否提问由 Agent 自行判断。如果用户的下一条回复只是承接上一轮 requirement 摘要的短跟进，而不是提出新范围、改目标或重新发起分析请求，就把它当成对上一轮摘要、默认方向或选项的继续确认，不要重新开一轮泛化 clarify；应直接按当前对话上下文把已确认事实用 canonical capture 路径、`user-confirmed` 来源写回，而不是继续写 `agent-inferred/project-derived` 的用户澄清字段。“请帮我实现/继续实现”表示执行意图；requirement、capture/classify/synthesize 和 review 由 Agent 在后台维护，不追加 OpenPrd 确认门禁。`review.html` 是稳定评审 artifact，不是授权门禁；Agent 自行记录并继续，OpenPrd 不要求用户批准评审稿或执行清单。
 4. change/tasks 就绪后，用 `openprd-test-strategy` 按风险选择单元、集成、端到端、人工、视觉、小程序、性能或安全验证组合，并在任务或报告中保留 evidence-plan；同时根据任务边界记录 execution strategy：小范围修正保持 `serial`，中等规模 L1/L2 可推荐 `parallel-workers`，高风险或大规模实现再升级到 `parallel-workers-isolated`；70/20/10 只作健康形状参考，不作硬门禁。
-5. 纯图片、封面图、配图、海报、插画、图标、贴纸、mockup 或“先看样子”请求按生图路由选工具：先判断当前对话工具面，Codex 环境用原生 `imagegen`（Image 2），Cursor 环境用内置 `GenerateImage`，两者都是工具内免费能力；都不可用或无法判断时，先读 `.openprd/harness/image-generation-preference.json` 的用户已确认偏好，没有偏好就先问用户选哪种生图方式，并把答复以 `user-confirmed` 来源写回该文件作为下次默认；绝不擅自调用用户本地或自有付费生图 API。生图工具是工具路径，不是审美豁免，生成前先写清用途、受众、气质、约束和记忆点，并用 anti-slop 避免默认紫白/蓝紫渐变、通用字体、白底卡片堆叠和无语境装饰；其中 logo、icon、avatar、badge 等开发素材在用户未明确要求场景化展示时，默认按独立素材输出（standalone asset）生成：全画布单主体，不额外添加卡片、设备框或其他展示容器；只有实际发生生图工具调用后，才能汇报生图结果、失败或限流。生图结果先当候选效果图，不要默认登记到 `.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>`；普通截图、Computer/Browser/Playwright 实测截图要作为证据时补 `openprd visual-compare --board <verification-board.json>`；同构列表、卡片、网格、表格或用户反馈没对齐时补 `openprd visual-compare --board <alignment-board.json>`，并同时覆盖容器轨道与内部内容槽位轨道；单个 logo、icon、avatar、badge、按钮图形或图片内部居中/视觉重心/偏心问题补 `openprd visual-compare --board <centering-board.json>`，并同时覆盖画布中心、主体外接框中心和视觉重心偏移。visual evidence 同时检查气质、层级、字体/色彩/表面角色和记忆点，不只检查截图是否存在。用户后续如果说“跟效果图”“不一致”“好丑”“复刻”，不能只口头说对比过了，至少先产出一份视觉证据图。如果用户目标是把工作转成可学习、可复用、可回看、可教学或可沉淀的材料，先按期望产物是否需要章节结构、证据锚点、图文讲解、检索练习、工作示例或长期阅读体验来判断；需要时优先走 `openprd learn .` 生成学习包和阅读器，不要用关键词表触发；“仙侠风格的学习材料”这类短请求也按学习型交付物处理，风格只作为 `--genre` 题材参数。
-5a. 对 logo、icon、avatar、badge、贴纸、空态插画、单物件 UI 位图等开发素材，如果最终要接入 UI 并需要透明背景，默认走“候选评审 -> 资产工程化 -> 接入验证”的图标资产链路：先基于用途、受众、气质、约束和记忆点生成 3 个差异足够大的独立素材候选方向，并保持纯 `#00ff00` 绿幕、无文字、无 UI 容器、主体居中且留足裁切边距；用户选定前不写入项目文件。用户选定后再定位源图或 contact sheet，保留绿幕源图，用 `remove_chroma_key.py` 抠成透明 PNG/WebP，按真实 UI 需要裁切居中并导出 384px 或多尺寸资产；接入时按首页卡片、工具格、吸顶栏、偏好预览等实际场景分别调显示比例，而不是只换图片路径。收口时同步写回 `.openprd/design/active/asset-spec.md` 和 `selected-direction.md`，说明选中的方向、资产路径、透明产物、接入位置和验证结果；最终回复必须区分绿幕源图、透明产物和是否已经接入。
+5. 纯图片、封面图、配图、海报、插画、图标、贴纸、mockup 或“先看样子”请求按生图路由选工具：先判断当前对话工具面，Codex 环境用原生 `imagegen`（Image 2），Cursor 环境用内置 `GenerateImage`，两者都是工具内免费能力；都不可用或无法判断时，先读 `.openprd/harness/image-generation-preference.json` 的用户已确认偏好，没有偏好就先问用户选哪种生图方式，并把答复以 `user-confirmed` 来源写回该文件作为下次默认；绝不擅自调用用户本地或自有付费生图 API。生图工具是工具路径，不是审美豁免，生成前先写清用途、受众、气质、约束和记忆点，并用 anti-slop 避免默认紫白/蓝紫渐变、通用字体、白底卡片堆叠和无语境装饰；其中 logo、icon、avatar、badge 等开发素材在用户未明确要求场景化展示时，默认按独立素材输出（standalone asset）生成：全画布单主体，不额外添加卡片、设备框或其他展示容器；只有实际发生生图工具调用后，才能汇报生图结果、失败或限流。生图结果先当候选效果图，不要默认登记到 `.openprd/harness/visual-reviews/`。Agent 应展示候选方向并说明采用的可逆默认方向；OpenPrd 不强制等待确认，用户明确选择时再覆盖默认方向并更新 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>`；普通截图、Computer/Browser/Playwright 实测截图要作为证据时补 `openprd visual-compare --board <verification-board.json>`；同构列表、卡片、网格、表格或用户反馈没对齐时补 `openprd visual-compare --board <alignment-board.json>`，并同时覆盖容器轨道与内部内容槽位轨道；单个 logo、icon、avatar、badge、按钮图形或图片内部居中/视觉重心/偏心问题补 `openprd visual-compare --board <centering-board.json>`，并同时覆盖画布中心、主体外接框中心和视觉重心偏移。visual evidence 同时检查气质、层级、字体/色彩/表面角色和记忆点，不只检查截图是否存在。用户后续如果说“跟效果图”“不一致”“好丑”“复刻”，不能只口头说对比过了，至少先产出一份视觉证据图。如果用户目标是把工作转成可学习、可复用、可回看、可教学或可沉淀的材料，先按期望产物是否需要章节结构、证据锚点、图文讲解、检索练习、工作示例或长期阅读体验来判断；需要时优先走 `openprd learn .` 生成学习包和阅读器，不要用关键词表触发；“仙侠风格的学习材料”这类短请求也按学习型交付物处理，风格只作为 `--genre` 题材参数。
+5a. 对 logo、icon、avatar、badge、贴纸、空态插画、单物件 UI 位图等开发素材，如果最终要接入 UI 并需要透明背景，默认走“候选评审 -> 资产工程化 -> 接入验证”的图标资产链路：先基于用途、受众、气质、约束和记忆点生成 3 个差异足够大的独立素材候选方向，并保持纯 `#00ff00` 绿幕、无文字、无 UI 容器、主体居中且留足裁切边距；Agent 可先保留候选源图并选择可逆默认方向；用户明确选定时优先采用。进入资产工程化后再定位源图或 contact sheet，保留绿幕源图，用 `remove_chroma_key.py` 抠成透明 PNG/WebP，按真实 UI 需要裁切居中并导出 384px 或多尺寸资产；接入时按首页卡片、工具格、吸顶栏、偏好预览等实际场景分别调显示比例，而不是只换图片路径。收口时同步写回 `.openprd/design/active/asset-spec.md` 和 `selected-direction.md`，说明选中的方向、资产路径、透明产物、接入位置和验证结果；最终回复必须区分绿幕源图、透明产物和是否已经接入。
 5b. 卡片宽度、间距、留白、对齐、颜色、圆角、字号、按钮或图标等轻量 UI 可视优化，仍可按 L0/L1 小范围修正推进，不自动升级成大界面 3 方向方案评审；但它是用户可见变化，动手前要有一句审美意图和记忆点，收口必须补 `visual-compare` 修改前后图、局部焦点证据板、截图实测证据板、对齐辅助线证据板或内部居中证据板，并检查气质、层级、颜色、字号、间距和表面角色是否成立。只要界面里有同构列表、卡片、网格或表格，就把容器轨道以及标题、副标题、描述、标签、状态、价格、按钮、图标、操作区等相同文案类型/相同组件槽位的对齐当作默认验收项，不等用户先投诉；只量外框、列宽或行顶不算完整对齐验收。只要任务在判断单个素材/图标/头像/徽标/按钮图形的内部居中、偏心或视觉重心，就把 centering-board 当作默认验收项；单张原始截图或主观“看起来居中”不算完整居中验收。build、package、`openprd dev-check` 和单张原始截图不能替代视觉证据。`visual-compare` 每次都会返回 `chatEmbed` markdown；生成证据板后必须把这行 `![视觉证据: ...](路径)` 直接嵌入最终回复，让证据在对话流里可见，不要只报告文件路径；`openprd dev-check` 在触达界面文件且最近 24 小时没有证据板时也会输出视觉证据提醒，收口前按提醒补齐。
 5c. 大界面三方向是 Agent 的默认责任，不要求用户另行提出生图；轻量 UI 微调不触发。已有界面时，Codex 原生 App 用 Computer Use、Codex 网页环境用 Chrome 插件任务专用窗口、Cursor 用可用浏览器或项目预览能力截图；三个方向必须共享同一张当前截图作为 image-to-image 参考。除非用户明确要求换风格，否则锁定字体角色、色彩系统、明暗模式、表面语言、圆角/边框/阴影、图标语言、平台框架和信息密度，只探索布局、信息层级、导航、关键路径与空间构图。冷启动没有现有界面时才使用 design brief，不伪造修改前截图。候选图先明确用途、目标用户、业务约束、核心动作、气质和唯一记忆点，并检查字体、色彩、空间、层级、表面/图标语言和动效含义；拒绝无依据蓝紫渐变、默认字体、等权白卡堆叠、过量大圆角、无语境装饰和只换颜色的伪方向。
 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` 完成不等于只补合同、只下载素材或只写计划；至少要把入口文件本体改完、主要占位清掉，并把已准备好的真实图片或参考约束真正落进页面；没有明确参考方向时，不要直接落回同一种安全极简解。
@@ -46,11 +46,11 @@
 ### Hook-Enforced Gates
 
 - automation-safe：识别到 Codex automation、Claude Code headless、cron、scheduled 或 unattended task 时，hook 默认不注入 OpenPrd context、不阻断写入、不要求 dev-check / quality / doctor；只有 OpenPrd 维护任务或显式启用 OpenPrd 时才恢复这些门禁。
-- requirement：需求未完成 `clarify/review/change/tasks` 前阻断实现写入；tasks 就绪后，只有用户原始意图已明确要求实现，或后续在看过执行确认清单后明确发出执行指令时才放行。
+- requirement：requirement、PRD、review、change 和 tasks 是 Agent 后台维护材料，不阻断实现、不索取用户确认。
 - 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 方案并等待用户确认。
-- autonomy-risk：即使已经授权实现，也默认阻断未经当前用户明确批准的云端热修复、生产远端写入、业务兜底、写死逻辑、客户端/服务端补业务数据或缓存补行。
+- skill-visualization：修改 skill、`SKILL.md`、`AGENTS.md` 或相关 workflow 前，用彩色 Mermaid 说明方案；它是可视说明，不是用户授权门禁，用户已要求修改时可继续执行。
+- autonomy-risk：风险识别只向 Agent 提供配置化、迁移、标准状态机、幂等脚本和可回滚发布路径建议，不承担授权审批；OpenPrd 不因生产、支付、删除、账号切换、兜底、写死或材料缺失阻断工具调用，也不索取用户确认，是否需要确认由当前 Agent 依据宿主安全规则和真实上下文自行判断。
 - secrets / weapp / browser / copy：分别处理 `secrets-vault`、按需的小程序运行态验证、窗口归属与 i18n/普通用户文案提醒。
 - 需要细节时，读 router 指向的 skill 和 command catalog，而不是继续扩写 `AGENTS.md`。
 

package/README.md

@@ -2,7 +2,7 @@
 
 简体中文 | [English](./README_EN.md)
 
-> 帮团队先把需求说清楚、确认清楚，再更稳地交付的 AI 原生 PRD 工作区与 CLI。
+> 帮团队和 Agent 把需求说清楚、持续做下去并用证据交付的 AI 原生 PRD 工作区与 CLI。
 
 [![License: MIT](https://img.shields.io/badge/license-MIT-green.svg)](./LICENSE)
 [![Node.js](https://img.shields.io/badge/node-%3E%3D20.19.0-339933.svg)](https://nodejs.org/)
@@ -11,12 +11,19 @@
 OpenPrd 是一个轻量但结构化的 **PRD harness**。你只需要先把问题说出来，它会帮团队和 Agent 把需求整理成：
 
 - 需求澄清
-- 用户确认
+- Agent 后台维护的需求事实与决策记录
 - 图形化评审
-- 冻结前关卡控制
+- 非阻断式风险提醒与交付检查
 - 面向执行系统的结构化交接
 
-它把关键确认点沉淀成稳定的 HTML 产物，而不是把版本状态散落在聊天记录或终端输出里。
+它把需求、决策和验证结果沉淀成稳定的 HTML 产物，而不是把状态散落在聊天记录或终端输出里。OpenPrd 的职责是帮助 Agent 做事：PRD、review、change、tasks、设计合同与测试证据由 Agent 在后台维护，不再要求用户回复指定内容才能继续。
+
+## 0.1.22：不再把流程材料变成用户门禁
+
+- OpenPrd 不再因需求摘要、评审稿、设计合同、测试证据或风险分类缺失而阻断实现。
+- 生产、支付、删除、账号切换、兜底与写死等信号只给 Agent 安全建议，不由 OpenPrd 索取用户确认。
+- Skill / AGENTS 方案图和大界面候选方向用于帮助理解，不再成为写入或实现授权门槛。
+- Codex、Claude Code、Cursor 共用同一套“Agent 后台维护、用户任务优先”的规则。
 
 ![OpenPrd 能力总览](https://raw.githubusercontent.com/mileson/openprd/main/docs/assets/openprd-capability-overview-zh.png)
 
@@ -25,7 +32,7 @@ OpenPrd 是一个轻量但结构化的 **PRD harness**。你只需要先把问
 如果你希望：
 
 - 在写 PRD 前先澄清需求
-- 区分用户确认、项目已有事实和 Agent 推断
+- 区分用户原始表达、项目已有事实和 Agent 推断
 - 在 freeze 前插入架构图 / 流程图评审
 - 让 Agent 遵循 repo 内置的协同规则
 
@@ -52,12 +59,12 @@ OpenPrd 解决的问题，不只是“把 spec 写出来”，也不只是“把
 
 | 工具 | 重心 | 用户主要看到的产物 | 更适合什么 |
 |------|------|--------------------|------------|
-| **OpenPrd** | 需求澄清、HTML 优先协作、交付门禁 | `review.html`、学习阅读器、质量报告、图示、结构化 change/task 状态 | 需要把人机协同、评审确认、执行推进和交付判断串起来的团队 |
+| **OpenPrd** | 需求澄清、HTML 优先协作、Agent 后台上下文维护 | `review.html`、学习阅读器、质量报告、图示、结构化 change/task 状态 | 希望用户只说目标、Agent 自动维护上下文并持续推进的团队 |
 | **OpenSpec** | spec / change 生命周期 | Markdown proposal、spec、design、tasks | 更关注 spec 增量治理和变更编排的团队 |
 | **Superpowers** | skill 驱动的编码执行流 | skills、plans、worktree / subagent 流程、代码评审检查点 | 更关注 AI Agent 如何规划、编码、review、收尾的工程团队 |
 
-OpenPrd 最有特色的地方，在于它把“这次到底在做什么、谁来确认、凭什么继续往下走”
-做成稳定可见的协作面，而不是只留在 spec 文件或 prompt 流程里。
+OpenPrd 最有特色的地方，在于它把“这次到底在做什么、Agent 依据什么继续、最后如何验证”
+做成稳定可见的协作面，而不是让用户记住 spec 文件、内部口令或 prompt 流程。
 
 ## 典型真实场景
 
@@ -66,7 +73,7 @@ OpenPrd 最有特色的地方，在于它把“这次到底在做什么、谁来
 
 | 场景 | 为什么这里更像 OpenPrd 的强项 | 主要产物 |
 |------|--------------------------------|----------|
-| 模糊产品需求，先别急着写代码 | 先澄清，再区分用户确认事实与 Agent 推断，最后把结果沉淀成稳定评审页。 | `clarify`、`capture`、`synthesize`、`review.html` |
+| 模糊产品需求，需要边做边收敛 | 区分用户原始表达、项目事实与 Agent 推断，在推进中持续沉淀稳定评审页。 | `clarify`、`capture`、`synthesize`、`review.html` |
 | 已有流程或登录入口改造 | 先从仓库与运行态重建当前事实，再决定下一步 change，而不是直接拍脑袋改。 | `discovery`、`diagram`、`review.html`、`change` |
 | 流程图、界面或架构确认 | 把理解差异放到图示和可评审产物里，而不是埋在聊天记录里。 | `diagram`、`visual-compare`、左右对比 JPG |
 | 长程 Agent 执行链路 | 把确认后的工作拆成按依赖可执行的小任务，每次新会话只推进一个任务并带验证门禁。 | `tasks`、`loop`、任务提示词、进度日志、验证报告 |
@@ -219,12 +226,12 @@ npx @openprd/cli@latest init /path/to/project --template-pack agent
 
 `init` 会创建 `.openprd/`、`docs/basic/`、`AGENTS.md`，并生成 Codex / Claude / Cursor 三端引导。`.openprd/` 是项目内唯一的 OpenPrd 工作区；change、spec、task 和 archive 产物都会收敛到 `.openprd/changes/`、`.openprd/specs/` 和 `.openprd/archive/changes/`，不再在仓库根目录生成单独的 `openprd/` 目录。Codex 项目会同时写入 `.codex/config.toml`、`.codex/hooks.json`、`.codex/hooks/openprd-hook.mjs`，并开启用户级 Codex `hooks = true`。
 
-Codex hooks 默认使用 `lite` 模式：安装 `UserPromptSubmit`、轻量
-`PreToolUse` 写入门禁，以及轻量 `Stop` 收工回顾。明确提到 OpenPrd、PRD、深度调研、深度对标、复刻、
+Codex hooks 默认使用 `lite` 模式：安装 `UserPromptSubmit`、非阻断式
+`PreToolUse` 建议，以及轻量 `Stop` 收工回顾。明确提到 OpenPrd、PRD、深度调研、深度对标、复刻、
 standards、fleet、文档标准化，或看起来像新产品 / 模块 / 流程需求的提示词都会
-注入上下文；`lite` 写入门禁只匹配直接编辑工具，让只读 shell 探查保持安静；`Stop`
+注入上下文；`PreToolUse` 只向 Agent 提供风险与材料维护建议，不因 OpenPrd 流程材料阻断用户任务；`Stop`
 会在本轮结束前回顾是否值得沉淀项目经验。
-需要连 shell 命令也进入写入门禁时使用 `guarded`，只有临时深度诊断才使用
+需要让 shell 命令也获得更完整的风险提示时使用 `guarded`，只有临时深度诊断才使用
 `full`。
 如果用户给出报错、日志、复现、根因排查等明确故障证据，并要求直接修复，
 hook 会按小型 bugfix 处理，不开启需求入口；“确认修复”这类确认词也会关闭
@@ -259,7 +266,7 @@ openprd release /path/to/project
 
 如果 OpenPrd 自身要把新版本发布到 GitHub，默认还要推送匹配的版本 tag，并配套 GitHub Release。可以先用 `node scripts/openprd-github-release-notes.mjs /path/to/project --version 0.1.23 --tag v0.1.23 --out /tmp/openprd-release.md` 预览发布文案；仓库内的 `github-release` workflow 会在 tag push 或手动触发时，基于同一份 `release-ledger` 自动创建或更新 GitHub Release。
 
-### 3. 先向用户澄清
+### 3. Agent 后台整理需求
 
 ```bash
 openprd clarify /path/to/project
@@ -270,8 +277,8 @@ openprd clarify /path/to/project
 OpenPrd 会先按用户可见的需求类型接住这句话，而不是先让你填一堆表单：
 
 - **直接处理**：通常直接做，做完告诉你改了什么、怎么验。
-- **现有功能优化**：先给一版 mini-plan，你确认方向后再继续。
-- **新功能 / 新流程方案**：先把场景、范围、第一版和风险说清楚，再进入 `review`、`change` 和 `tasks`。
+- **现有功能优化**：Agent 用 mini-plan 收敛范围并继续执行，显式说明采用的假设。
+- **新功能 / 新流程方案**：Agent 在后台整理场景、范围、第一版和风险，并持续维护 `review`、`change` 和 `tasks`，不要求用户批准这些内部材料。
 
 ### 4. 写回答案
 
@@ -314,18 +321,11 @@ openprd review /path/to/project --open
 openprd review /path/to/project --mark confirmed --version <id> --digest <sha256> --work-unit <id>
 ```
 
-`review.html` 是当前 PRD 的稳定评审稿，但默认 approval policy 是
-`decision-points`，不是“每次都必须停在这里”。常规 lane 下，一句自然语言
-确认（例如“确认这版，继续”，容忍“确认 v0276 评审稿”这类版本号插写）就足够：
-hook 会自动把确认绑定到当前精确的 `--version`、`--digest`、`--work-unit`，
-Agent 不允许反过来向用户索要 digest、work-unit 或完整命令。当这句确认同时
-带有“继续执行”意图，或此前已确认过需求摘要时，一次确认会解锁整条链：评审
-记录、change、tasks 与实现全程直通，不再逐环节停下（一次确认合同）。
-`silent-record` lane 只有在用户一开始已经明确要求直接做、并显式表示不需要
-额外评审或确认时，才允许直接记录当前这份精确 artifact。不要把实现授权当成
-给任意评审稿补确认，也不要把评审记录当成实现授权。当前 artifact 记录完成后，
-再生成 OpenPrd change 和任务拆解；如果用户原始意图已明确要求实现，tasks
-就绪后即可直接执行，否则等待一句明确的执行指令：
+`review.html` 是当前 PRD 的稳定评审稿，也是用户随时可以查看的协作结果，但不是
+OpenPrd 授权门禁。Agent 自动绑定当前精确的 `--version`、`--digest`、`--work-unit`，
+自行记录 review、生成 change、拆解 tasks 并继续用户已经要求的工作；不得反过来要求
+用户粘贴 digest、work-unit、完整命令或批准内部材料。信息不完整时，Agent 优先选择
+可逆默认方案并说明假设；是否真的需要提问由当前 Agent 根据宿主安全规则与真实上下文判断：
 
 ```bash
 openprd change /path/to/project --generate --change <change-id>
@@ -687,7 +687,7 @@ openprd loop /path/to/project --run --agent codex --dry-run
 `--dry-run`，预演时只打印安装和刷新命令，不修改 CLI、项目、registry 或 harness 状态。
 
 这套 harness 是有状态的，但 hook 重量由 profile 控制。默认 `lite` 保留轻量
-PreToolUse 写入门禁，并把匹配范围限制在直接编辑工具上，同时在 `Stop` 做一轮轻量项目经验回顾，避免只读 shell 噪声和完整工具级遥测；`guarded` 会额外覆盖 shell 工具，`full` 只建议用于临时深度诊断。`freeze`、`handoff`、accepted spec apply/archive、commit、push、release、publish 等高风险动作会先经过 `openprd run . --verify`，覆盖标准化、工作区校验、激活 change 校验和激活 discovery 校验。
+PreToolUse 非阻断式建议，并把匹配范围限制在直接编辑工具上，同时在 `Stop` 做一轮轻量项目经验回顾，避免只读 shell 噪声和完整工具级遥测；`guarded` 会额外覆盖 shell 工具，`full` 只建议用于临时深度诊断。`freeze`、`handoff`、accepted spec apply/archive、commit、push、release、publish 等动作会运行 `openprd run . --verify`，帮助 Agent 检查标准化、工作区、激活 change 和 discovery 状态，但不要求用户补流程确认。
 
 `openprd run . --context` 是类似 Ralph 的循环控制面。它会从激活 change 任务、discovery coverage 或普通 OpenPrd 工作流状态里选择下一项可执行单元，并把 hook turn 记录到 `.openprd/harness/iterations.jsonl`。
 

package/README_EN.md

@@ -2,7 +2,7 @@
 
 [简体中文](./README.md) | English
 
-> An AI-native PRD workspace and CLI that helps teams clarify requests, confirm direction, and ship with evidence.
+> An AI-native PRD workspace and CLI that helps teams and agents clarify requests, keep moving, and ship with evidence.
 
 [![License: MIT](https://img.shields.io/badge/license-MIT-green.svg)](./LICENSE)
 [![Node.js](https://img.shields.io/badge/node-%3E%3D20.19.0-339933.svg)](https://nodejs.org/)
@@ -11,11 +11,18 @@
 OpenPrd is a lightweight **PRD harness**. Start by describing the problem in plain language, and it helps teams and agents turn that request into:
 
 - requirement clarification
-- shared confirmation
+- agent-maintained requirement facts and decisions
 - visual review
 - structured handoff into execution
 
-Instead of hiding key decisions in prompts or terminal logs, OpenPrd keeps people and agents aligned around stable HTML artifacts such as `review.html`, learning readers, and quality reports.
+Instead of hiding key decisions in prompts or terminal logs, OpenPrd keeps people and agents aligned around stable HTML artifacts such as `review.html`, learning readers, and quality reports. OpenPrd helps the agent do the work: PRDs, reviews, changes, tasks, design contracts, and evidence are maintained in the background without requiring the user to reply with a prescribed confirmation.
+
+## 0.1.22: workflow artifacts are no longer user gates
+
+- Missing requirement summaries, review artifacts, design contracts, test evidence, or risk classifications no longer block implementation.
+- Production, payment, deletion, account-switching, fallback, and hardcoding signals provide safety guidance to the agent; OpenPrd does not request user approval.
+- Skill/AGENTS diagrams and large-UI design candidates explain decisions without becoming write or implementation gates.
+- Codex, Claude Code, and Cursor share the same agent-maintained, user-task-first behavior.
 
 ![OpenPrd capability overview](https://raw.githubusercontent.com/mileson/openprd/main/docs/assets/openprd-capability-overview-en.png)
 
@@ -25,14 +32,14 @@ OpenPrd is designed for the gap between:
 
 - vague product ideas that need clarification
 - agent-assisted requirement drafting
-- human confirmation at the right decision points before implementation
+- durable decisions and evidence without forcing process stops before implementation
 - structured handoff into execution systems
 
 It is especially useful when you want:
 
 - **clarify before drafting** instead of jumping straight to implementation
 - **source-aware capture** so user-confirmed facts stay separate from repo-derived, agent-inferred, or agent-normalized context
-- **policy-based review gates** that keep stable artifacts without forcing the same stop every time
+- **non-blocking review artifacts** that preserve context without turning process material into user approval gates
 - **agent-facing skills** shipped with the tool, not hidden in a local environment
 
 If your teammates often say “we kind of know what we want, but it is not fully shaped yet”, that is usually the moment when OpenPrd is most useful.
@@ -261,13 +268,13 @@ npx @openprd/cli@latest init /path/to/project --template-pack agent
 
 `init` creates `.openprd/`, `docs/basic/`, `AGENTS.md`, and generated Codex / Claude / Cursor guidance. Codex projects also get `.codex/config.toml`, `.codex/hooks.json`, `.codex/hooks/openprd-hook.mjs`, and user-level Codex `hooks = true`.
 
-Codex hooks default to `lite`: `UserPromptSubmit`, a lightweight `PreToolUse`
-write gate, and a lightweight `Stop` end-of-turn review. Context is injected for prompts that explicitly mention OpenPrd,
+Codex hooks default to `lite`: `UserPromptSubmit`, non-blocking `PreToolUse`
+guidance, and a lightweight `Stop` end-of-turn review. Context is injected for prompts that explicitly mention OpenPrd,
 PRD, deep research/benchmarking, replication, standards, fleet, documentation
 standards, or look like new product/module/workflow requirements. The lite write
-gate only matches direct editing tools so read-only shell exploration stays
-quiet, while `Stop` reviews whether the current turn produced a reusable project
-pattern; use `guarded` when shell commands should also pass through the write gate,
+guidance helps the agent maintain context and choose safer paths without blocking
+the requested task, while `Stop` reviews whether the current turn produced a reusable project
+pattern; use `guarded` when shell commands should also receive fuller risk guidance,
 and `full` only for temporary deep diagnostics.
 Concrete bugfix prompts with diagnostic evidence such as errors, logs, repro
 steps, or root-cause investigation skip requirement intake when the user asks to
@@ -308,7 +315,7 @@ openprd release /path/to/project
 
 When OpenPrd itself publishes a new version to GitHub, the release should also include a matching version tag and GitHub Release. You can preview the body with `node scripts/openprd-github-release-notes.mjs /path/to/project --version 0.1.23 --tag v0.1.23 --out /tmp/openprd-release.md`; the repo `github-release` workflow will create or update the GitHub Release from the same `release-ledger` on tag push or manual dispatch.
 
-### 3. Clarify with the user
+### 3. Maintain requirement context in the background
 
 ```bash
 openprd clarify /path/to/project
@@ -319,8 +326,8 @@ Clarification stays in the conversation as an inline outline or short checklist.
 OpenPrd first routes the request by user-visible need type instead of forcing a long intake form:
 
 - **Quick fix**: usually handle it directly, then report what changed and how it was verified.
-- **Existing-flow improvement**: first share a mini-plan in plain language, then continue after direction is confirmed.
-- **New feature / new workflow**: first clarify the scenario, scope, first version, and risks, then move into `review`, `change`, and `tasks`.
+- **Existing-flow improvement**: maintain a plain-language mini-plan, state assumptions, and keep moving.
+- **New feature / new workflow**: maintain the scenario, scope, first version, risks, `review`, `change`, and `tasks` in the background without asking the user to approve those internal artifacts.
 
 ### 4. Capture answers back into the workspace
 
@@ -363,25 +370,13 @@ openprd review /path/to/project --open
 openprd review /path/to/project --mark confirmed --version <id> --digest <sha256> --work-unit <id>
 ```
 
-`review.html` is the stable review artifact for the current PRD, but the default
-approval policy is `decision-points`, not “always stop here”. In a normal lane,
-one plain natural-language confirmation (for example “确认这版，继续”, including
-wording with an inline version id such as “确认 v0276 评审稿”) is enough: the
-hook binds it to the exact current `--version`, `--digest`, and `--work-unit`
-tuple automatically, and the agent must never ask the user to paste a digest,
-work-unit id, or a full command. When that confirmation also carries a
-continue-execution intent, or a requirement summary was already confirmed
-earlier, one confirmation authorizes the whole chain: review recording, change,
-tasks, and implementation proceed without further stops (the one-time
-confirmation contract). In a `silent-record` lane, OpenPrd can record the exact
-current artifact without an extra stop only when the user already made direct
-execution intent explicit and explicitly opted out of additional review
-confirmation. Do not treat implementation approval as permission to mark a
-different review artifact, and do not treat review recording as execution
-authorization. After the current artifact is recorded, generate the OpenPrd
-change and task breakdown. If the user originally asked to implement, execution
-can continue once tasks are ready; otherwise wait for an explicit execution
-request:
+`review.html` is a stable collaboration artifact, not an OpenPrd authorization
+gate. The agent binds the exact current `--version`, `--digest`, and `--work-unit`,
+records the review, generates the change and tasks, and continues the work the
+user requested. It must not ask the user to paste a digest, work-unit id, command,
+or approval for internal process material. When information is incomplete, the
+agent should choose a reversible default and state the assumption; whether a real
+question is necessary is decided by the active agent and host safety rules:
 
 ```bash
 openprd change /path/to/project --generate --change <change-id>
@@ -797,15 +792,15 @@ or, with `--fleet`, `fleet <root> --update-openprd`. Both commands support
 modifying the CLI, project, registry, or harness state.
 
 The harness is stateful, but hooks are proportional to the chosen profile.
-Default `lite` keeps a lightweight `PreToolUse` write gate for requirement
-intake and limits it to direct editing tools, while `Stop` performs a lightweight
+Default `lite` keeps lightweight, non-blocking `PreToolUse` guidance for requirement
+context and limits it to direct editing tools, while `Stop` performs a lightweight
 end-of-turn knowledge review instead of full telemetry. This avoids read-only shell hook
-noise while still nudging the agent to capture reusable project patterns. `guarded` also gates shell tools, while
+noise while still nudging the agent to capture reusable project patterns. `guarded` also covers shell tools, while
 `full` restores SessionStart/PreToolUse/PostToolUse/Stop telemetry for temporary
-diagnostics. High-risk actions such as freeze, handoff, accepted spec
-apply/archive, commit, push, release, or publish are gated by
-`openprd run . --verify`, which covers standards, workspace validation, active
-change validation, and active discovery verification.
+diagnostics. Actions such as freeze, handoff, accepted spec apply/archive,
+commit, push, release, or publish run `openprd run . --verify` to help the agent
+check standards, workspace validation, active change validation, and active
+discovery verification without requesting process confirmation from the user.
 
 `openprd run . --context` is the Ralph-style loop surface for agents. It selects
 the next executable unit from active change tasks, discovery coverage, or normal

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@openprd/cli",
-  "version": "0.1.21",
+  "version": "0.1.22",
   "description": "AI-native PRD workspace and lifecycle CLI",
   "type": "module",
   "license": "MIT",

package/skills/openprd-harness/SKILL.md

@@ -54,8 +54,8 @@ description: 驱动 OpenPrd 工作区完成从澄清到 handoff 的主流程。
 20. 用户要求日志、链路追踪、业务成本护栏、免费额度、滥用防护、评估执行环境、冒烟覆盖、性能基线、极端场景、HTML 质量评估报告或项目级经验 Skill 时，路由到 `$openprd-quality`
 21. 用户需要可视化说明，或系统/产品形态仍不清晰时，在进入需求定稿前路由到 `$openprd-diagram-review`
 22. 默认保持 Codex hooks 轻量。除非项目明确需要完整工具级遥测，否则 `openprd setup/update` 使用 `--hook-profile lite`；默认 `lite` 会保留 `Stop` 收工回顾，用于在本轮结束前提醒是否值得沉淀项目经验，并要求 Agent 用“本次情况 / 准备整理成的经验 / 以后如何复用 / 只保留在当前项目里”的结构化人话向用户确认
-23. hook 会强制阻断几类场景：需求入口未完成就写实现、外部证据不足就直接改第三方集成、skill/AGENTS 变更未先可视化确认、敏感信息场景下直接读原始 vault 文件，以及未经当前用户明确批准的云端热修复、生产远端写入、业务兜底、写死逻辑或缓存补行
-24. 即使用户已经授权实现，也不自动授权云端热修复、生产远端写入、客户端/服务端补业务数据、接口临时插入业务行、缓存补行、硬编码或写死逻辑。发现这类路径时先停下，说明为什么标准源码/迁移/配置路径不够、影响范围、回滚方式、本地同步计划和验证方式；只有用户明确说允许热修复、允许临时兜底或允许写死后才执行。
+23. hook 默认不因 PRD、review、change、tasks、设计合同、测试报告或视觉证据尚未补齐而阻断用户要求的正常实现。缺失材料由 Agent 在后台自动补齐；来不及补齐时继续完成安全范围内的工作，并在收口如实说明证据状态，不把流程作业转嫁给用户。
+24. 风险识别只向 Agent 提供提醒和更安全的实现建议，不承担授权审批。命中“兜底、写死、补数据、权益、额度、生产、支付、删除、账号”等词时先看真实动作对象，优先改成配置、迁移、标准状态机、幂等脚本或可回滚发布路径并继续。OpenPrd 不因风险词或动作类型阻断工具调用，也不向用户索取确认、指定句子、摘要、digest、work-unit id 或命令；是否需要确认由当前 Agent 依据宿主安全规则和真实上下文自行判断。
 25. 当 `doctor` 报告生成引导漂移时，读取 `.openprd/harness/drift-report.json`
 26. `openprd run . --context` 会返回 `runtimeEnvironment`。先按 `.openprd/harness/runtime-environment.json` 和 install manifest 的 `platformCapabilityPacks` 判断当前对话是在 Codex、Claude Code 还是 Cursor，再启用对应能力；Codex Image 2、Computer Use、Codex-owned browser window、对话协同画布和当前线程文本桥接都必须有当前 surface 或 hook/session 证据，不能只凭 Codex CLI 或配置文件存在来启用。当前线程桥接只在 Codex App 明确提供线程发送工具时使用；画布图片仍以导出路径或 Markdown 图片引用作为证据，不宣称网页能自动直发附件。
 
@@ -83,7 +83,7 @@ description: 驱动 OpenPrd 工作区完成从澄清到 handoff 的主流程。
   - 不要把 `run --context` 建议当作直接用户命令
   - 用户给出会话 ID 续接历史任务时，使用 `openprd run <path> --context --message <用户原话或会话ID>` 保留通用会话 ID 语义；先恢复指定会话，不要让当前 active change 抢主线
   - 用户没有给 ID、但明确描述了已有需求/任务对象时，也使用 `openprd run <path> --context --message <用户原话>`；先解析对应的 change/task/work unit，再决定是否沿用当前工作区状态
-  - 默认 lite Codex hooks 会为明确的 OpenPrd、PRD、深度调研、对标复刻、standards、fleet、文档标准化提示词，以及结构上较复杂的需求注入 `$openprd-requirement-intake` 分流提示；直接处理(L0)不打开 requirement gate，现有功能优化(L1)用对话内 mini-plan 承接，新功能/新流程方案(L2)才进入 PRD/review/change/tasks；轻量 `PreToolUse` 写入门禁会在需求入口未确认前阻断过早实现；本轮准备结束时，`Stop` 会基于 touched files 和 verify/finish 信号回顾是否要生成项目经验草案，并要求 Agent 先用人话向用户确认是否保留到当前项目里
+  - 默认 lite Codex hooks 会为明确的 OpenPrd、PRD、深度调研、对标复刻、standards、fleet、文档标准化提示词，以及结构上较复杂的需求注入 `$openprd-requirement-intake` 分流提示；直接处理(L0)不打开 requirement 维护，现有功能优化(L1)用对话内 mini-plan 承接，新功能/新流程方案(L2)在后台维护 PRD/review/change/tasks；`PreToolUse` 不因这些材料缺失阻断实现；`Stop` 只提醒 Agent 评估是否值得生成项目经验草案，不强制用户确认
   - 只有当项目确实需要完整 hook 遥测或临时深度诊断时，才用 `openprd update <path> --hook-profile full`
 - 长程实现循环使用：
   - `openprd loop <path> --init`
@@ -99,7 +99,7 @@ description: 驱动 OpenPrd 工作区完成从澄清到 handoff 的主流程。
   - 只有在当前用户消息明确要求开发、继续任务、深度调研、对标复刻或提交时，才运行 `openprd loop <path> --run`
   - 代码修改完成后、最终回复前，运行 `openprd dev-check <path> <file...>`；自动优化开启（默认）时需要关注的文件先本轮完成拆分，再以 **OpenPRD 自动优化报告** 表格呈现（列：影响对象、问题级别、源文件规模、优化原因、本次处理结果、后续建议）并附开关确认；关闭后以 **后续建议** 表格呈现（列：影响对象、关注程度、规模信号、预警原因、本次处理结果、后续建议）。两种模式都按 🔴 → 🟠 → 🟡 排序
   - 用户只是要求生成图片、封面图、配图、海报、插画、图标、贴纸、头像、banner、主视觉/KV、运营图、效果图、视觉稿、mockup 或先看样子时，默认调用 `imagegen`（Codex 原生 Image 2）生成图片；Image 2 是工具路径，不是审美豁免，生成前先写清用途、受众、气质、约束和记忆点；除非用户明确指定 HTML/SVG/CSS/Canvas/代码稿，不要生成临时 HTML 再截图；未调用 `imagegen` 前，不要声称生图已完成、失败或限流。生图结果先当候选效果图，不要默认纳入验收
-  - 大界面改动不直接开工：先按用户目标、信息架构变化、视觉决策成本和验证风险判断方案评审形态；已有界面时用 Codex Computer Use 打开产品内对应功能并截图，冷启动没有现有界面时用已确认 PRD、用户群体、第一版切片、视觉目标、气质端点和记忆点生成设计 brief；再用 `imagegen`（Codex 原生 Image 2）生成至少 3 个设计方向，横向拼接成一张带 1/2/3 序号的大图作为候选效果图给用户确认；每个方向都要有具体审美主张和 anti-slop 自检；主动确认是否符合预期、是否纳入后续效果图/实现截图对比、以及是否按此继续实现；只有确认后，再把它作为实现参考图进入后续任务
+  - 大界面改动先按用户目标、信息架构变化、视觉决策成本和验证风险判断方案评审形态；已有界面时用 Codex Computer Use 打开产品内对应功能并截图，冷启动没有现有界面时用当前 PRD、用户群体、第一版切片、视觉目标、气质端点和记忆点生成 design brief；再用 `imagegen`（Codex 原生 Image 2）生成至少 3 个设计方向，横向拼接成一张带 1/2/3 序号的大图作为候选效果图；每个方向都要有具体审美主张和 anti-slop 自检。候选图用于帮助用户判断，但 OpenPrd 不强制停下等待确认；Agent 可按最符合目标且可逆的方向继续，并清楚说明采用的假设
   - 如果已有确认参考效果图、图片资产、设计稿、截图或用户给图并进入实现阶段，阶段性完成后必须生成实现截图，并用 `openprd visual-compare <path> --reference <效果图> --actual <实现截图> --locale <zh-CN|en>` 输出 JPG 视觉对比图；如果参考图里有多个子图、网格或对象，先运行 `openprd visual-prepare <path> --reference <效果图> --grid <列>x<行>` 或 `--boxes <plan.json>`，检查 contact sheet 后按 compare-plan 逐项对比；如果局部细节更重要，再补 `--board <focus-board.json>` 输出局部焦点证据板；如果没有明确参考图，先判断新建界面还是修改既有界面：新建界面先完成 3 方向方案评审，修改既有界面动手前先生成修改前截图，完成后生成修改后截图，并用 `openprd visual-compare <path> --before <修改前截图> --after <修改后截图> --locale <zh-CN|en>` 输出 JPG 自检图；如果并行试了多个优化方向，再补 `--board <parallel-board.json>` 输出并行实验证据板；如果新功能或改动包含同构列表、卡片、网格、表格，或用户反馈没对齐/排版漂移，再补 `--board <alignment-board.json>` 输出对齐辅助线证据板。未查看对比图，或对比图仍有明显结构、气质、层级、字体/色彩/表面角色、记忆点差异/漂移时，不要声称界面视觉完成；如果用户后续说“跟效果图”“不一致”“好丑”“复刻”，至少先产出一份视觉证据图
   - `openprd loop <path> --finish` 前，先完成文档影响检查并更新缺失或过期的 `docs/basic/`、文件说明书和文件夹 README；涉及后端、脚本、Agent、工具链、服务或数据处理变更时，同步评估 CLI 与 API 两个接入面
   - 声称单个任务完成前，只运行本任务最小足够验证，并通过 `--evidence`、测试报告或任务 metadata 留下 task-scoped evidence；不要在每个任务里反复运行 `openprd quality <path> --verify` 或全局 `openprd run <path> --verify`
@@ -121,7 +121,7 @@ description: 驱动 OpenPrd 工作区完成从澄清到 handoff 的主流程。
 - 使用：
   - `openprd clarify <path>`
 - 当关键产品事实缺失时，先查看 `intake-reflection.md` 的需求入口自省，再把压缩后的必须确认问题问给用户
-- 当需求模糊、起点只有一句想法，或需要先做方案探索时，先查看生成的 `intake-reflection.md`，先把用户群体、产品形态、第一版切片、暂不处理、不能破坏和风险探针整理成首轮项目画像，再把压缩后的目标、范围、非目标、验收方式和必须确认问题放在对话里请用户确认；不要生成或打开澄清 HTML
+- 当需求模糊、起点只有一句想法，或需要先做方案探索时，先查看生成的 `intake-reflection.md`，把用户群体、产品形态、第一版切片、暂不处理、不能破坏和风险探针整理成首轮项目画像；Agent 选择最可逆的默认方案继续，把假设和验收方式说清楚，不把 OpenPrd 摘要变成用户确认门禁；不要生成或打开澄清 HTML
 - Agent 在对话里先用业务和产品语言复述：这次主要给谁、什么场景、先解决什么、先不碰什么、不能影响什么、会带来哪些业务风险。默认先追问 1 个最高价值问题，而不是一次性抛一整墙技术问题。
 - `需求判断` 和 `需求理解` 先用 1 到 2 句轻量主句说清结论：这次是什么、核心问题在哪里、第一版先做到什么；边界、风险、异常例子和技术细节下沉到后续分项或表格，不要揉成一大段重话。
 - 如果当前还是 L2 的首轮澄清或 requirement 摘要确认阶段，只能承诺“我先整理需求摘要给你确认，确认后再进入 PRD / review 流程”；不要写成“你回我一句我就开始实现”，也不要把 requirement 摘要确认、review 和实现压成一步。
@@ -155,7 +155,7 @@ description: 驱动 OpenPrd 工作区完成从澄清到 handoff 的主流程。
 - L1/L2 中只有语义判断为大界面改动、视觉决策成本高或需要用户选方向时，才在 review-presentation 写入前自动补交互方向评审；轻量 UI 微调不触发。按当前工具面用 Codex `imagegen`（Image 2）或 Cursor `GenerateImage` 生成 3 个差异足够大的交互稿方向，图片保存到 `.openprd/design/active/`，再把每个方向的 `id/title/image/summary/tradeoff` 写入 `reviewPresentation.designDirections.directions[]`（title 15 字内、summary/tradeoff 30 字内）。已有界面时三个方向必须共享同一张当前截图作为 image-to-image 参考并默认保持视觉 DNA；冷启动才使用 design brief。review.html 会渲染 3 方向评审卡片，用户点“选这个方向”后回传 `openprd review <path> --mark confirmed --direction <id>` 命令；选定方向会记录进评审状态，后续实现必须按选定方向推进。不涉及界面或只是轻量微调时不要携带 designDirections 字段
 - 用户想在交互稿上圈选、批注或做视觉级反馈时，引导走画布评审协同：画布右栏顶部“评审协同”区显示当前 7 步流程位置，“导入评审方向”会把当前 review 的 designDirections 连图带说明摆上画布（已选定方向会标出），用户圈选批注后用“发送给 Codex”回传反馈
 - 用户问“现在到哪一步了”“接下来做什么”“OpenPrd 到底是干嘛的”时，先运行 `openprd guide <path>`：它按工作区状态输出 7 步流程（需求澄清 → 需求摘要 → 评审确认 → 交互方向选择 → 任务拆解 → 实现执行 → 验证收口）、当前位置和下一步动作，用它的输出向用户解释，不要口头即兴复述流程
-- 把生成的 `review.html` 当作首选稳定评审 artifact。默认 approval policy 是 `decision-points`：当前 lane 仍需要人类决策时，请用户先评审问题定义、范围、主流程、风险和开放问题，再运行带精确 `--version`、`--digest`、`--work-unit` 的 `openprd review <path> --mark confirmed`。L2 下先确认对话内 requirement 摘要，再写回确认事实、classify/synthesize，并进入这一步 review。若用户一开始已经明确要求直接做，并显式表示“不需要进行任何确认”，lane 才可进入 `silent-record`；单纯的“请帮我实现/继续实现”或“不要评审”都不触发这个豁免。进入 `silent-record` 后也只允许记录当前精确匹配的稳定 artifact，不能借机替别的版本补确认。review 记录完成且 tasks 就绪后，如果用户刚刚确认的是现有功能优化（L1）的 mini-plan、范围边界或正式产品边界，后续承接要写成“已确认，我按这个继续”，不要写成“确认，我们就按这个……”这种像再次索取确认的句子；如果用户原始意图已经明确要求实现，可直接继续执行；否则先输出执行确认清单，列出本轮目标、将执行内容、不做事项、验证方式和已知风险，再请求明确执行授权，不能只要求用户回复一句确认
+- 把生成的 `review.html` 当作稳定评审 artifact，但它是 Agent 后台维护和用户随时可看的结果，不是授权门禁。Agent 用精确 `--version`、`--digest`、`--work-unit` 记录当前稳定 artifact，自行完成 requirement 写回、classify/synthesize、review、change 和 tasks；不得要求用户批准摘要、评审稿或执行清单，也不得因这些材料尚未完成阻断用户已经要求的实现
 - 在 L2 的 requirement 摘要确认前，不要承诺“确认后我就开始实现”；正确顺序是：先确认摘要，再写回事实、进入 classify/synthesize/review，review 和 tasks 就绪后才谈执行。
 
 ### 6. 需要时生成可视化评审产物

package/skills/openprd-shared/SKILL.md

@@ -33,7 +33,7 @@ description: OpenPrd 工作区与产物的共用守则。凡是需要查看、
    - 只读命令：`status`、`validate`、`next`、`history`、`diff`、`interview`、`doctor`
    - 写入命令：`init`、`setup`、`update`、`classify`、`synthesize`、`diagram`、`release`、`freeze`、`handoff`
    - 执行命令：`loop --run`、`tasks --advance`、`discovery --advance`、`loop --finish --commit`、git commit、git push，必须有当前用户明确执行意图。
-   - 实现授权不包含云端热修复、生产远端写入、业务兜底、写死逻辑、客户端/服务端补业务数据或缓存补行；这些动作需要当前用户单独明确批准，并给出本地源码/配置/迁移同步与回滚计划。
+   - 用户要求实现、继续、修复、部署或发布时，OpenPrd 不再追加授权门禁。风险词和动作类型只用于提醒 Agent 优先选择配置化、可回滚、幂等或标准状态机方案，不触发 OpenPrd 阻断或用户确认；是否需要确认由当前 Agent 依据宿主安全规则和真实上下文自行判断，禁止要求用户复述固定授权口令。
 3. 不要虚构 OpenPrd 命令或产物类型。
    - 不确定时先对照 `openprd --help`。
 4. 共用规则放在这里，领域规则放到对应 skill。
@@ -100,7 +100,7 @@ description: OpenPrd 工作区与产物的共用守则。凡是需要查看、
    - 触发条件：会明显改变页面信息架构、主视觉、核心布局、关键路径、组件层级/密度，或用户需要先选择设计方向。
    - 位置：需求分流之后、PRD 定稿或实现开工之前；它不是 `review.html`，也不是实现后的 `visual-compare`。
    - 步骤：用户不需要额外提出生图。已有界面时，Codex 原生 App 用 Computer Use、Codex 网页环境用 Chrome 插件任务专用窗口、Cursor 用可用浏览器或项目预览能力截当前真实界面；三个方向都以同一截图做 image-to-image，除非用户明确要求换风格，否则保持现有视觉 DNA。冷启动没有现有界面时，基于已确认 PRD、用户群体、第一版切片、视觉目标、气质端点和记忆点生成 design brief；按工具面用 Codex `imagegen`（Image 2）或 Cursor `GenerateImage` 至少生成 3 个不同设计思想方向；每个方向都要有具体审美主张和 anti-slop 自检；把效果图横向拼成一张大图，每张左上角标注 1/2/3，先作为候选效果图展示。
-   - 交互：主动确认是否符合预期、是否纳入后续效果图/实现截图对比、以及是否按此继续实现；只有确认后才把选定方向、整张图或其中子图整理到 `.openprd/harness/visual-reviews/`。用户确认前，不进入大 UI 实现，也不要声称界面方案已定。
+   - 交互：把候选方向直接给用户看，并说明 Agent 采用了哪个可逆默认方向及原因；OpenPrd 不强制等待用户确认，也不阻断大 UI 实现。用户明确选择时再覆盖默认方向并写入 `.openprd/harness/visual-reviews/`。
 14. 界面任务进入实现前，先用 `.openprd/design/` 锁定设计框架。
    - 页面涉及具体产品事实、版本、发布时间、规格、价格、引用数据或地点事实时，先补 `.openprd/design/active/facts-sheet.md`，不要凭记忆写页面。
    - 页面依赖 logo、产品图、UI 图、摄影图、插图、图表或品牌色字体时，先补 `.openprd/design/active/asset-spec.md`。
@@ -146,7 +146,7 @@ description: OpenPrd 工作区与产物的共用守则。凡是需要查看、
 21. 修改 skill、`SKILL.md`、`AGENTS.md` 或相关 workflow 前，先可视化确认。
    - 先读取当前 skill / AGENTS 现状，再输出一张彩色 Mermaid 方案图。
    - Mermaid 必须区分 `unchanged`、`added`、`changed`、`removed`，并在图后用短说明写清新增、修改、保持不变、删除或阻断。
-   - 必须等待用户明确确认后，才能修改相关文件。
+   - Mermaid 用于帮助用户理解变更；OpenPrd 不把它变成写入授权门禁。Agent 可在输出方案图后按用户已提出的修改目标继续。
 22. 涉及微信小程序运行态时，只在明确需要运行态证据时再升级到本地验证。
    - 只有当用户明确要求小程序实测、验证、复现、页面操作、截图、日志、网络请求、开发者工具自动化，或当前改动高风险到必须依赖运行态证据时，才升级到小程序本地验证。
    - 一旦进入小程序运行态验证，默认沿用当前小程序运行态或开发者工具会话连续验证，不要为了验证自动重开应用；只有用户明确要求从 0 到 1、冷启动、重开或重新打开时，才从头启动。
@@ -170,8 +170,8 @@ description: OpenPrd 工作区与产物的共用守则。凡是需要查看、
 - 单纯的“请帮我实现/继续实现”只表示有执行意图，不表示可以跳过 requirement 摘要确认、`capture/classify/synthesize` 写入路径或 review；只有用户明确表示“不需要进行任何确认”时，才允许静默走完整 requirement write path。
 - 声称实现就绪前，要说明文档影响检查是新增、更新，还是有意保持 `docs/basic/`、文件说明书和文件夹 README 不变。
 - 用户要求生成图片、封面图、配图、海报、插画、图标、贴纸、头像、banner、主视觉/KV、运营图、效果图、视觉稿、mockup、先看样子或先确认设计方向时，最终回复应给出 `imagegen` 生成的图片结果；只有实际发生 `imagegen` 调用后，才能汇报生图结果、失败或限流。Image 2 是工具路径，不是审美豁免；最终回复要能说明候选图是否满足用途、受众、气质和记忆点。生图结果先当候选效果图，并主动确认是否符合预期、是否纳入后续效果图/实现截图对比、以及是否按此继续实现。进入实现阶段后，已有确认参考图才给出 `openprd visual-compare --reference/--actual` 生成的 JPG 路径；如果参考图是一张整板、网格图或多对象组合，先运行 `openprd visual-prepare --reference <效果图> --grid <列>x<行>` 或 `--boxes <plan.json>` 并说明 contact sheet / compare-plan；没有参考图时先判断新建界面还是修改既有界面，新建界面先完成 3 方向方案评审，修改既有界面给出 `openprd visual-compare --before/--after` 生成的 JPG 路径；普通截图实测补 `openprd visual-compare --board <verification-board.json>`，同构列表、卡片、网格、表格或用户反馈没对齐时补 `openprd visual-compare --board <alignment-board.json>`，并说明相同槽位 spread 是否仍有偏差；最终同时说明是否仍有结构、气质、层级、颜色、字号、间距或记忆点差异。
-- 大界面改动进入实现前，最终回复或阶段性回复应给出 3 方向横向候选效果图大图，并明确等待用户确认是否纳入后续对比和继续实现；只有确认后再进入实现。
-- 在系统形态、产品流程或外部依赖仍有实质不确定性时，需求定稿前先向用户确认。
+- 大界面改动应给出 3 方向横向候选效果图大图；Agent 可选最符合目标且可逆的方向继续，OpenPrd 不强制等待确认。用户明确选择时优先采用用户方向。
+- 在系统形态、产品流程或外部依赖仍有实质不确定性时，Agent 先选择可逆默认方案并显式说明假设；是否需要提问由 Agent 自行判断，不由 OpenPrd 强制。
 - 当用户还没看过最新的 synthesize 产物或图示产物时，handoff 前先确认。
 - 当用户要求可视化说明，或当前解释明显包含复杂关系、路径、对比、边界或风险传播时，路由到 `$openprd-diagram-review`；优先判断是否适合轻量解释型 SVG，而不是默认进入正式评审图。
 

package/src/agent-integration.js

@@ -476,7 +476,7 @@ async function writeProjectCommandCatalog(projectRoot, options, changes) {
 }
 
 function agentContractBody() {
-  return [
+  const lines = [
     '## OpenPrd Harness',
     '',
     '本项目由 OpenPrd 管理。Agent 应优先遵循 repo-local skills 和 hooks；`AGENTS.md` 只保留轻量入口合同。',
@@ -527,8 +527,8 @@ function agentContractBody() {
     '- 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 方案并等待用户确认。',
-    '- autonomy-risk：即使已经授权实现，也默认阻断未经当前用户明确批准的云端热修复、生产远端写入、业务兜底、写死逻辑、客户端/服务端补业务数据或缓存补行。',
+    '- skill-visualization：修改 skill、`SKILL.md`、`AGENTS.md` 或相关 workflow 前，用彩色 Mermaid 说明方案；它是可视说明，不是用户授权门禁，用户已要求修改时可继续执行。',
+    '- autonomy-risk：风险识别只向 Agent 提供配置化、迁移、标准状态机、幂等脚本和可回滚发布路径建议，不承担授权审批；OpenPrd 不因生产、支付、删除、账号切换、兜底、写死或材料缺失阻断工具调用，也不索取用户确认，是否需要确认由当前 Agent 依据宿主安全规则和真实上下文自行判断。',
     '- secrets / weapp / browser / copy：分别处理 `secrets-vault`、按需的小程序运行态验证、窗口归属与 i18n/普通用户文案提醒。',
     '- 需要细节时，读 router 指向的 skill 和 command catalog，而不是继续扩写 `AGENTS.md`。',
     '',
@@ -538,7 +538,25 @@ function agentContractBody() {
     'If the quality report says `productionReady=false`, do not claim overall readiness. Reuse `openprd run . --verify` to separate current-task status from workspace-level debt, list the missing evidence or gates, and when only `feature-coverage` is pending describe it as task-ledger or evidence debt rather than a failed implementation.',
     'The only baseline documentation path is `docs/basic/`.',
     '',
-  ].join('\n');
+  ];
+  const overrides = new Map([
+    ['- requirement：', '- requirement：requirement、PRD、review、change 和 tasks 是 Agent 后台维护材料，不阻断实现、不索取用户确认。'],
+  ]);
+  return lines.map((line) => {
+    for (const [prefix, replacement] of overrides) {
+      if (line.startsWith(prefix)) {
+        return replacement;
+      }
+    }
+    return line
+      .replace('只有新功能/新流程方案才先走 requirement intake、对话内 requirement 摘要确认，再 `review/change/tasks`，最后才实现。', '新功能/新流程方案的 requirement、PRD、review、change 和 tasks 由 Agent 在后台维护，不阻断用户已经要求的实现。')
+      .replace('L2 的首轮澄清只能承诺“我先整理需求摘要给你确认”，不能把 requirement 摘要确认、review 和实现压成一句“你回我一句我就开始实现”。', 'L2 的需求摘要是 Agent 后台维护材料，不创建用户确认停顿。')
+      .replace('如果 `openprd run . --context` 仍然建议 `clarify-user`，当前这轮回复的目标就只能是 `需求摘要` 或 `1 个最高价值澄清点`，不要写成“我先按默认方案实现”。', '如果 `openprd run . --context` 建议 `clarify-user`，Agent 优先选择可逆默认方案并显式说明假设；是否提问由 Agent 自行判断。')
+      .replace('单纯的“请帮我实现/继续实现”只表示有执行意图，不表示可以跳过 requirement 摘要确认、`capture/classify/synthesize` 写入路径或 review；只有用户明确表示“不需要进行任何确认”时，才允许静默走完整 requirement write path。', '“请帮我实现/继续实现”表示执行意图；requirement、capture/classify/synthesize 和 review 由 Agent 在后台维护，不追加 OpenPrd 确认门禁。')
+      .replace('`review.html` 是稳定评审 artifact，不再默认等于唯一的人类停顿点；默认按 decision-points approval policy 执行，只有当前 lane 仍要求人类决策时才在 final answer 主体里停下请求确认；当 review 已确认且 tasks 已就绪但还需要执行授权时，先给执行确认清单再请用户确认。', '`review.html` 是稳定评审 artifact，不是授权门禁；Agent 自行记录并继续，OpenPrd 不要求用户批准评审稿或执行清单。')
+      .replace('Agent 要主动确认是否符合预期、是否纳入后续效果图/实现截图对比、以及是否按此继续实现；只有确认后，才把选定方向、整张图或其中子图整理成 reference-set 并进入实现。', 'Agent 应展示候选方向并说明采用的可逆默认方向；OpenPrd 不强制等待确认，用户明确选择时再覆盖默认方向并更新 reference-set。')
+      .replace('用户选定前不写入项目文件。用户选定后再定位源图或 contact sheet', 'Agent 可先保留候选源图并选择可逆默认方向；用户明确选定时优先采用。进入资产工程化后再定位源图或 contact sheet');
+  }).join('\n');
 }
 
 function parseSkillSourceMarkdown(text) {

package/src/codex-hook-runner-template.mjs

@@ -1924,6 +1924,8 @@ function analyzePromptIntent(prompt) {
   const canvasCollaborationRequest = /(画布|canvas|excalidraw)/i.test(text)
     && /(标注|批注|协同|改图|回填|贴到画布|放到画布|插入画布|插到画布|画布评审|画布反馈|一起看|openprd\s*canvas|annotation)/i.test(text);
   const visualReview = /效果图|实现截图|视觉对比|视觉评审|对标效果图|复刻|不一致|好丑|没对齐|对不上|不像/i.test(text);
+  const largeUiVisualDirectionRequest = visualMockupRequest
+    && /(界面改动比较大|大界面|大改|改版|重做|重新设计|三种设计方向|3\s*种设计方向|多个设计方向|信息架构|核心布局|首屏|关键路径)/i.test(text);
   const directBugfixExecution = explicitExecution && bugfixOrDiagnostic;
   const newFeatureVerbMatched = /(新增|增加|新建)/.test(text);
   const capabilityCreationMatched = capabilityCreationPatterns.some((pattern) => pattern.test(text));
@@ -2017,6 +2019,7 @@ function analyzePromptIntent(prompt) {
     readOnly,
     simpleConcrete,
     visualMockupRequest,
+    largeUiVisualDirectionRequest,
     continuationRequest,
     continuationSessionId,
     continuationTaskHandle,
@@ -2705,11 +2708,10 @@ function detectHighRiskAutonomyMutation(root, payload, intent, risk) {
 
 function formatHighRiskAutonomyBlock(detection) {
   return [
-    `OpenPrd blocked a high-risk autonomy action: ${detection.title}.`,
-    '当前用户消息只授权了本轮实现范围，不等于授权 Agent 私自做云端热修复、生产远端写入、业务兜底、写死逻辑或缓存补行。',
+    `OpenPrd detected an autonomy risk: ${detection.title}.`,
     detection.details ? `Matched action: ${detection.details}` : null,
-    '默认路径：先改本地源码、配置、迁移或数据修复脚本，让本地与云端保持同一事实源；完成后再按正常发布/部署路径验证。',
-    '如果这次确实必须临时处理，请先让用户明确说“允许这次云端热修复”或“允许这次临时兜底/写死”，并说明影响范围、回滚方式和如何同步回本地源码/配置/迁移。',
+    'Agent 责任：优先改成配置、迁移、标准状态机、幂等脚本或可回滚发布路径并继续。OpenPrd 只提供风险提醒，不承担授权审批。',
+    'OpenPrd 不阻断工具调用，也不要求用户确认或复述固定授权口令；是否需要确认由当前 Agent 依据宿主安全规则和真实上下文自行判断。',
   ].filter(Boolean).join('\n');
 }
 
@@ -3043,7 +3045,7 @@ function skillVisualizationGateMessage(gate) {
   return [
     'OpenPrd skill/AGENTS 可视化确认门禁: active。',
     '当前请求涉及 skill、SKILL.md、AGENTS.md 或相关 workflow 规则变更。编辑前必须先读取现状，输出彩色 Mermaid 方案图，再用简短文字说明新增、修改、保持不变和删除/阻断项。',
-    'Mermaid 必须包含 `unchanged`、`added`、`changed`、`removed` 四种 classDef，并等待用户明确确认后才能修改相关文件。',
+    'Mermaid 应包含 `unchanged`、`added`、`changed`、`removed` 四种 classDef，用于解释变更；它不是 OpenPrd 授权门禁，用户已提出修改时可继续执行。',
   ].join('\n');
 }
 
@@ -3104,7 +3106,6 @@ function composeHookContext(root, intent = null, gate = null, progress = null, s
     weappGateMessage(readNamedGate(root, 'weapp', sessionId)),
     browserSafetyMessage(intent),
     productCopyMessage(intent),
-    largeUiVisualDirectionMessage(intent),
   ].filter(Boolean).join('\n');
 }
 
@@ -3357,7 +3358,6 @@ function recordRunHook(cwd, baseEvent, outcome) {
 
 function requirementGateMessage(intent, gate) {
   const gateBlocksImplementation = isBlockingRequirementGate(gate);
-  const approvalPolicy = requirementApprovalPolicy(gate);
   if (!intent?.requiresIntake && !gateBlocksImplementation) {
     return null;
   }
@@ -3372,21 +3372,13 @@ function requirementGateMessage(intent, gate) {
       'Before generation, do a quick anti-slop check: without brand or reference support, avoid default purple/blue-purple gradients, generic font taste, white card piles, and context-free decoration.',
     ].join('\n');
   }
-  const status = gateBlocksImplementation ? 'active' : 'opened';
   return [
-    'OpenPrd requirement intake gate: ' + status + '.',
-    'This prompt looks like a likely 新功能/新流程方案 (L2), so the heavy requirement-intake lane is active. Do not decide from fixed keywords; first use $openprd-requirement-intake to classify the user-visible requirement type by impact, unknowns, decision cost, and validation cost.',
+    'OpenPrd requirement intake runs in background and does not create a user approval stop.',
+    'This prompt looks like a likely 新功能/新流程方案 (L2). Use $openprd-requirement-intake to classify it by impact, unknowns, decision cost, and validation cost while continuing the work the user requested.',
     'Keep this mapping visible for internal review: 直接处理=L0, 现有功能优化=L1, 新功能/新流程方案=L2.',
     'L0 and L1 stay on lightweight paths and should not be forced through formal PRD/review/change/tasks unless the scope expands.',
-    'If the requirement type is 新功能/新流程方案 (L2), do not edit implementation files yet and proceed through PRD/review/change/tasks with the appropriate PRD scene lens: 通用场景、面向个人消费者场景、面向企业服务场景，或以 Agent 为主要使用场景。 Keep raw enum values such as base / consumer / b2b / agent for internal commands or records only; do not surface them to the user unless truly necessary.',
-    reviewPolicyAllowsSilentRecord(approvalPolicy)
-      ? 'Decision-point policy: because the user explicitly said there is no need for any confirmation stop, you may skip the requirement-summary confirmation stop, write back the requirement facts, synthesize the PRD, record the exact current stable review artifact, generate the OpenPrd change, prepare the task breakdown, then implement within the confirmed scope.'
-      : 'Decision-point policy: first output a short structured requirement summary in chat with 需求判断 / 需求理解 / 功能范围 / 技术方案, where 功能范围 and 技术方案 should prefer Markdown tables; if this is still a 0-to-1 or worth-doing discussion, also surface the validation/startup loop with 第一批最容易触达的社区或种子用户、你为什么算这个社区里的自己人、当前替代方案和痛点证据、先怎么手工交付、手工作战卡怎么写、能不能先用 spreadsheet / 表单 / no-code 跑起来、什么承诺才算真需求、有没有 10 个样本和更强付费信号、最低成本先验证什么、达到什么条件才允许产品化、增长阶段守什么纪律、以及验证阶段怎样先活下来; wait for the user to confirm that summary, then write back confirmed facts, synthesize the PRD, wait for a human decision on the stable review artifact, generate the OpenPrd change, prepare the task breakdown, then implement within the confirmed scope.',
-    reviewPolicyAllowsSilentRecord(approvalPolicy)
-      ? 'This lane is in silent-record mode only because the user explicitly said there is no need for any further review or confirmation stop. Plain "请帮我实现" is not enough; you may record only the exact current version, digest, and work unit.'
-      : 'Requirement-summary confirmation, review-artifact confirmation, and implementation authorization are different gates: do not treat "可以开做", "继续实现", plain "请帮我实现", or "不需要评审" as permission to skip them.',
-    'If the original request already asked to implement, execution can continue once the active approval policy and tasks are ready; otherwise wait for a clear execution request.',
-    'Recommended next action: write a short 需求类型判断 in chat, and by default merge the route into the label as 需求类型：新功能/新流程方案（L2）; only add a separate 内部路由码 when internal debugging truly benefits. Then run openprd clarify ., summarize the requirement in chat using 需求判断 / 需求理解 / 功能范围 / 技术方案, prefer Markdown tables for 功能范围 and 技术方案, and if the ask still looks like 0-to-1 validation also add 第一批最容易触达的社区或种子用户、你为什么算这个社区里的自己人、当前替代方案和痛点证据、先怎么手工交付、手工作战卡怎么写、能不能先用 spreadsheet / 表单 / no-code 跑起来、什么承诺才算真需求、有没有 10 个样本和更强付费信号、最低成本先验证什么、达到什么条件才允许产品化、增长阶段守什么纪律、以及验证阶段怎样先活下来; ask for confirmation, and only after that write back confirmed facts. Do not open a clarification HTML page; the formal HTML review happens after synthesize/review.',
+    'For L2, maintain PRD/review/change/tasks and the appropriate scene lens in the background. Do not block implementation files, do not ask the user to approve OpenPrd artifacts, and do not expose internal enum values unless necessary.',
+    'Write back the best-supported facts with explicit source labels, synthesize the PRD, record the stable review artifact, generate the change, and prepare tasks as Agent-owned maintenance. If information is uncertain, choose a reversible default and state the assumption instead of turning OpenPrd into a confirmation gate.',
   ].join('\n');
 }
 
@@ -3488,7 +3480,10 @@ function learningReviewMessage(intent = null) {
   return lines.join('\n');
 }
 
-function largeUiVisualDirectionMessage() {
+function largeUiVisualDirectionMessage(intent = null) {
+  if (!intent?.largeUiVisualDirectionRequest) {
+    return null;
+  }
   return [
     'OpenPrd 大界面改动视觉方案评审:',
     '位置: 需求分流之后、PRD 定稿或实现开工之前；它不同于 review.html，也不同于实现后的 visual-compare。',
@@ -3496,7 +3491,7 @@ function largeUiVisualDirectionMessage() {
     '自动性: 用户不需要额外提出“请生图”。只要语义判断命中大界面改动或视觉决策成本高，就主动完成 3 方向生成；卡片宽度、间距、对齐、颜色、圆角、字号等轻量微调不触发。',
     '步骤: 已有界面时，Codex 原生 App 用 Computer Use，Codex 网页环境用 Chrome 插件的任务专用窗口，Cursor 用当前可用的浏览器或项目预览能力，进入对应功能并截当前真实界面。三个方向必须把同一张截图作为 image-to-image 参考；除非用户明确要求换风格，否则锁定现有字体角色、色彩系统、明暗模式、表面语言、圆角/边框/阴影、图标语言、平台框架和信息密度，只探索布局、信息层级、导航、关键路径和空间构图。冷启动没有现有界面时，基于已确认 PRD、用户画像、第一版切片和视觉目标写 design brief，不伪造修改前截图。brief 必须写清用途、受众、气质端点、约束和记忆点，3 个方向要分别说明审美主张和主动避开的模板味。然后按生图路由调用内置生图工具（Codex=`imagegen`/Image 2，Cursor=`GenerateImage`；都不可用时按 `.openprd/harness/image-generation-preference.json` 的用户已确认偏好，没有偏好先问用户）生成至少 3 个不同设计思想方向；把效果图横向拼成一张带 1/2/3 序号的大图，先作为候选效果图给用户评审，不要默认写入 `.openprd/harness/visual-reviews/` 当验收参考。',
     '质量: 每个方向都要从用途、用户、业务约束、核心动作和唯一记忆点出发，同时检查字体角色、色彩、空间构图、信息层级、表面/图标语言和动效含义；拒绝无依据蓝紫渐变、默认字体、等权白卡堆叠、过量大圆角、无语境装饰和只换颜色的伪方向。',
-    '交互: 主动追问三件事：是否符合预期、是否纳入后续效果图/实现截图对比、是否按此继续后续实现。只有用户确认纳入后续对比或继续实现后，才把选定方向、整张图或其中子图整理成 reference-set 并写入 `.openprd/harness/visual-reviews/`；用户确认前，不进入大 UI 实现，也不要声称界面方案已定。',
+    '交互: 把三个方向直接给用户看，并说明 Agent 采用的可逆默认方向及原因；OpenPrd 不强制等待确认，也不阻断大 UI 实现。用户明确选择时再覆盖默认方向并更新 reference-set。',
     '多对象参考处理: 如果候选效果图是一张图里包含多个子图、网格、多对象或多方向，不要拿整板直接硬比；先运行 `openprd visual-prepare . --reference <效果图> --grid <列>x<行>` 或 `--boxes <plan.json>`，检查 contact sheet，确认 reference-set 后再逐项进入实现和验收。',
   ].join('\n');
 }
@@ -3513,69 +3508,30 @@ function visualLocalAdjustmentMessage() {
 }
 
 function codexConfirmationReplyRule() {
-  return 'Codex 回复规则: 只有当前真的还缺人来拍板时，才在 final answer 里停下来请求确认。停下请求确认时执行“一次确认合同”：把本条需求后续本来会出现的全部确认点合并成一段话一次性说清，并告诉用户只要回一句“确认，继续执行”，剩余环节会自动连续推进；同一条需求不允许出现第二个人工确认停顿。绝对不要让用户粘贴 digest、work unit、版本号或任何 openprd 命令——这些值 hook 会自动绑定，需要时由你自己填进命令。只要用户已经明确说了“认可并继续”，或已经确认了 mini-plan、范围边界、正式产品边界，就直接沿着已确认路径继续，不要再写“如果你认可”“确认的话我就继续”这类二次索取确认的话。面向用户时，不要直接抛 lane、change、tasks、review artifact、work unit、digest、worker shard、write-scope、worktree、内部版本号、命令或文件路径这些内部词；统一改说“需求确认稿”“本次调整”“后续任务”“继续落地”“完成后检查”。如果后面真的还需要额外授权，再用人话把会做什么、不会做什么、完成后怎么检查说清楚。如果当前仍在 L2 的首轮澄清或需求摘要确认阶段，不要写成“你回我一句我就开始实现”；只能承诺“我先整理需求摘要给你确认，确认后再继续”。如果当前 lane 已进入 silent-record 策略，只能说明用户已经明确说了“不需要进行任何确认”；单纯的“请帮我实现/继续实现”不能把 lane 切到 silent-record。';
+  return 'Codex 回复规则: OpenPrd 不创建用户确认停顿，不要求用户批准需求摘要、评审稿、change、tasks、设计合同、测试证据或风险分类，也不要求粘贴 digest、work unit、版本号或命令。Agent 在后台维护这些材料并继续用户要求的工作；是否因真实上下文需要向用户提问，只由当前 Agent 依据宿主安全规则和任务信息自行判断，不由 OpenPrd 强制。';
 }
 
 function confirmationGateMessage(gate) {
   if (!gate || gate.active) {
     return null;
   }
-  const intro = gate.status === 'execution-authorized'
-    ? 'OpenPrd requirement intake gate auto-authorized execution after review confirmation and task preparation because the original user request already asked to implement.'
-    : 'OpenPrd requirement intake gate was explicitly confirmed by the user.';
   return [
-    intro,
-    'Implementation may proceed only within the confirmed scope, with docs/basic, file manuals, folder README docs, standards verification, and OpenPrd run verification kept up to date. For backend, script, agent, tooling, service, or data-processing changes, keep CLI and API surface review current in docs/basic/backend-structure.md.',
+    'OpenPrd requirement materials are Agent-maintained background records and do not create a user approval stop.',
+    'Continue the user-requested work while keeping docs, review records, tasks, and verification evidence accurate.',
     'For UI or visual work with an existing reference image, first confirm the user has accepted that image as a later comparison reference; if one image contains multiple sub-images, grid cells, or objects, run openprd visual-prepare . --reference <effect-image> --grid <columns>x<rows> or --boxes <plan.json>, inspect the contact sheet, and use the generated reference-set / compare-plan before comparing. Then capture the implemented UI and run openprd visual-compare . --reference <effect-image> --actual <implementation-screenshot>; if local detail matters more than the whole screen, add openprd visual-compare . --board <focus-board.json> --locale <zh-CN|en> so the agent can review numbered zoom regions. When there is no reference image, capture the before screenshot first, implement, capture the after screenshot from the same entry, viewport, account, and data state, then run openprd visual-compare . --before <before-screenshot> --after <after-screenshot>; if the agent explored multiple optimization directions, add openprd visual-compare . --board <parallel-board.json> --locale <zh-CN|en>. If ordinary screenshots or Computer/Browser/Playwright checks are used as evidence, assemble them with the checked path and checkpoints through openprd visual-compare . --board <verification-board.json> --locale <zh-CN|en> before claiming visual completion. If the UI contains repeated homogeneous cards, lists, grids, or tables, or the user reports misalignment, capture the real screen, overlay guide lines, measure both container-track and internal content-slot x/y/size/baseline spread, and assemble an alignment-board through openprd visual-compare . --board <alignment-board.json> --locale <zh-CN|en>. If a single logo, icon, avatar, badge, button graphic, or image crop needs internal-centering or visual-centroid judgment, crop the target and assemble a centering-board through openprd visual-compare . --board <centering-board.json> --locale <zh-CN|en> before claiming it is centered.',
     'If the user later says the implementation does not match the effect image, looks wrong, or asks for replication, do not rely on subjective narration alone; produce at least one visual evidence artifact before claiming completion.',
   ].join('\n');
 }
 
 function currentRequirementStatusLine(gate, progress) {
-  if (gate?.status === 'review-confirmation-authorized') {
-    return gate?.reviewActionAuthorization?.continueAfterReview
-      ? '用户刚刚已经确认这版需求，并且明确表示继续。先记录这次确认结果，然后直接接着整理本次调整和后续任务；只有后面真的还缺额外授权时，再用人话说明影响和下一步。'
-      : '用户刚刚已经确认这版需求；本回合只允许记录这次确认结果，不能把它直接扩展成开工授权。';
-  }
-  if (gate?.status === 'review-recording-authorized') {
-    return '这版需求确认稿已经按免再次确认的规则授权记录；只记录这一次确认结果，然后继续整理本次调整和后续任务。';
-  }
-  switch (progress?.nextStep) {
-    case 'clarification-confirmation-required':
-      return '当前卡点: 先让用户确认当前需求摘要；在此之前不要把核心需求写成既定事实，也不要直接往后推进。请求确认时按“一次确认合同”表达：明确告诉用户这是本条需求默认唯一的一次人工确认，只要回复“确认，继续执行”，后面的需求稿整理、调整范围、任务拆解和实现都会自动连续推进，不会再逐环节找他确认。';
-    case 'clarification-writeback-required':
-      return '当前卡点: 用户已经确认这轮需求摘要或默认方案，但 current.json 里还没有把确认后的事实稳定写回。先按 canonical 字段路径用 user-confirmed 回写，再继续 synthesize；不要再回退成泛化 clarify，也不要继续写 agent-inferred。';
-    case 'product-type-classification-required':
-      return '当前卡点: 用户已经确认这轮需求摘要，但产品场景还没锁定。先完成 classify 并让当前 lane 的产品场景与写回事实一致，再继续 synthesize。';
-    case 'requirement-interview-required':
-      return '当前卡点: 用户已经确认这轮需求摘要，但 current.json 里还缺这轮 requirement 的关键事实。先补齐 canonical 字段，必要时再用 openprd interview 收敛剩余问题，然后继续 synthesize。';
-    case 'prd-synthesis-required':
-      return reviewPolicyAllowsSilentRecord(requirementApprovalPolicy(gate))
-        ? '当前卡点: 用户已明确表示不需要再停下来确认，可以直接整理已确认内容，并生成这版需求确认稿。'
-        : '当前卡点: 当前需求摘要已确认，下一步把已确认内容整理成这版需求确认稿。';
-    case 'prd-review-required':
-      return progress?.review?.versionId
-        ? '当前卡点: 先等用户确认这版需求确认稿；不要把“继续做”“开落地吧”或单纯的“请帮我实现/继续实现”当成已经认可这版内容。请求确认时只需要用户回一句自然语言，例如“确认这版，继续执行”；版本、digest、work unit 由 hook 自动绑定，绝对不要让用户粘贴 digest、work unit 或任何 openprd 命令。同时说明这一句确认之后整条链会自动执行到实现，不会再停。'
-        : '当前卡点: 先整理出这版需求确认稿，再等待用户确认。';
-    case 'review-recording-required':
-      return '当前卡点: 这版需求确认稿已经生成，而且用户已明确表示不需要再停下来确认；可以先记录这次确认结果，再继续后面的整理。';
-    case 'change-generation-required':
-      return '当前卡点: 这版需求已经确认，下一步先整理本次调整范围；这是当前流程的直接延续，不需要再重复索取同一轮确认。';
-    case 'task-breakdown-required':
-      return '当前卡点: 本次调整范围已经立起来了，下一步把它拆成可直接执行的后续任务。';
-    case 'implementation-ready':
-      return '当前卡点: 这版需求和后续任务都准备好了。如果用户一开始就明确要继续做，就直接进入实现；否则再用人话说明这次会做什么、不会做什么、完成后怎么检查。若用户刚刚确认的是 L1 范围边界或 mini-plan，承接话术要写成“已确认，我按这个继续”，不要再写成像二次索取确认的句子。';
-    default:
-      return '当前卡点: 继续按“澄清需求 -> 确认需求 -> 整理本次调整 -> 拆分后续任务 -> 开始实现”的顺序推进。';
-  }
+  const next = progress?.nextStep || gate?.status || 'continue';
+  return `后台维护状态: ${next}。这是 Agent 的记录任务，不是用户卡点；继续用户要求的工作并自行补齐。`;
 }
 
 function currentRequirementMessage(intent, gate, progress) {
   const prompt = stripMarkdown(gate?.promptPreview || '');
   const approvalPolicy = requirementApprovalPolicy(gate);
-  const gateStatus = isImplementationAdvanceIntent(intent)
-    ? 'OpenPrd requirement intake gate was explicitly confirmed by the user.'
-    : 'OpenPrd requirement intake gate: active.';
+  const gateStatus = 'OpenPrd requirement intake runs in background and does not block the user-requested implementation.';
   const lines = [
     'OpenPrd 当前需求入口',
     gateStatus,
@@ -3588,21 +3544,17 @@ function currentRequirementMessage(intent, gate, progress) {
     gate?.intakeMode === 'deep-reflection'
       ? '需求入口: 先运行需求自省，再输出对话内澄清摘要或简短清单。'
       : '需求入口: 先做轻量项目映射，再确认影响点和验收方式。',
-    reviewPolicyAllowsSilentRecord(approvalPolicy)
-      ? '当前 approval policy: decision-points / silent-record。之所以进入 silent-record，是因为用户已经明确表示不需要进行任何确认；单纯的“请帮我实现/继续实现”或“不要评审”都不够，仍然只能记录版本、digest、work unit 精确匹配的 artifact。'
-      : '当前 approval policy: decision-points / human-review。当前 lane 仍需要一次 requirement 摘要确认和一次稳定 review artifact 的明确人类决策；单纯的“请帮我实现/继续实现”不算这两次决策。',
+    '当前 approval policy: agent-maintained。需求摘要、稳定评审记录、change 和 tasks 由 Agent 在后台维护；用户要求实现或继续时，不再要求额外确认口令、digest、work-unit id 或命令。',
     intent?.reviewContinuationRequested
       ? '这条消息同时表达了“确认当前稳定评审稿并继续当前 OpenPrd 下一步”的意图：先记录精确 review artifact，再继续当前 lane；如果 review 后 tasks 已就绪但还需要执行授权，立刻展示执行确认清单，不要停在“如果你要我继续”。'
       : '',
     currentRequirementStatusLine(gate, progress),
-    reviewPolicyAllowsSilentRecord(approvalPolicy)
-      ? 'Decision-point order: because the user explicitly waived any confirmation stop, you may skip requirement-summary confirmation, write back requirement facts, synthesize the PRD, record the exact stable review artifact, generate the OpenPrd change, prepare the task breakdown, then implement within the confirmed scope.'
-      : 'Decision-point order: clarify the requirement, summarize it in chat using 需求判断 / 需求理解 / 功能范围 / 技术方案, prefer Markdown tables for 功能范围 and 技术方案, and if the ask still looks like 0-to-1 validation also surface 第一批最容易触达的社区或种子用户、你为什么算这个社区里的自己人、当前替代方案和痛点证据、先怎么手工交付、手工作战卡怎么写、能不能先用 spreadsheet / 表单 / no-code 跑起来、什么承诺才算真需求、有没有 10 个样本和更强付费信号、最低成本先验证什么、达到什么条件才允许产品化、增长阶段守什么纪律、以及验证阶段怎样先活下来; wait for the user to confirm that requirement summary, write back only confirmed facts, synthesize the PRD, wait for a human review decision on the stable artifact, generate the OpenPrd change, prepare the task breakdown, then implement within the confirmed scope.',
-    'Recommended next action: 先在 chat 输出“需求类型判断”，默认把路由码并进“需求类型：新功能/新流程方案（L2）”这类标签里；只有内部排障确实需要时，才额外写“内部路由码”。若为新功能/新流程方案（L2），再运行 openprd clarify .，并按“需求判断 / 需求理解 / 功能范围 / 技术方案”给出结构化摘要，其中“功能范围”和“技术方案”优先用 Markdown 表格；`需求判断` 和 `需求理解` 先用轻量主句说清这次是什么、核心问题和第一版目标，再把边界、风险、异常例子和技术细项下沉到后续分项或表格，不要把某条示例文案写成固定模板。如果这轮本质上还在判断值不值得做，还要主动补上：第一批最容易触达的社区或种子用户、当前替代方案、先怎么手工交付、什么承诺才算真需求、最低成本先验证什么，以及验证阶段怎样先活下来。请求确认后再写回 requirement 事实并继续 classify/synthesize，不要把这一步表述成“确认后直接开始实现”。Do not open clarification HTML; use review.html only after synthesize/review.',
+    'Decision-point order: Agent 先吸收用户原始意图并继续当前安全范围内的工作，同时在后台补写需求事实、PRD、评审记录、change 和 tasks；材料不完整时记录缺口，不中断用户任务。',
+    'Recommended next action: 用户要求实现、继续、修复、部署或发布时直接推进；需要的需求类型判断和结构化摘要由 Agent 自行整理，只有真实产品方向存在多个会明显改变结果的选择时才向用户提一个必要问题。',
   ];
   if (isImplementationAdvanceIntent(intent)) {
     lines.splice(2, 1, gate?.active
-      ? '用户表达了继续实现的意图；但在 review 评审、change 和任务拆解走完之前，仍然阻断实现写入。'
+      ? '用户表达了继续实现的意图；直接进入安全范围内的实现，review、change 和任务拆解由 Agent 在后台补齐。'
       : '用户已确认当前需求可以进入执行范围；仍需保持实现范围与已确认的需求入口一致。');
   }
   lines.push(codexConfirmationReplyRule());
@@ -3610,7 +3562,7 @@ function currentRequirementMessage(intent, gate, progress) {
 }
 
 function requirementRoutingSummary() {
-  return '需求类型由 $openprd-requirement-intake 按影响面、未知数、决策成本和验证成本判断：直接处理(L0)可直接处理并事后说明，不打开正式 PRD/review/change/tasks；现有功能优化(L1)先给对话内 mini-plan，默认不生成正式 PRD/change/tasks；新功能/新流程方案(L2)才进入 requirement intake 与 PRD/review/change/tasks，并选择通用场景 / 面向个人消费者场景 / 面向企业服务场景 / 以 Agent 为主要使用场景的 PRD 视角。对用户复述时不要直接把 consumer / b2b / agent 当展示词；这些枚举值只用于内部记录和命令。单纯的“请帮我实现/继续实现”只表示有执行意图，不表示跳过 requirement 摘要确认或 review；只有用户明确表示不需要进行任何确认时，才允许静默走完整 requirement write path。';
+  return '需求类型由 $openprd-requirement-intake 按影响面、未知数、决策成本和验证成本判断：直接处理(L0)直接完成；现有功能优化(L1)用轻量 mini-plan；新功能/新流程方案(L2)由 Agent 在后台维护 requirement、PRD、review、change 和 tasks。用户说“实现、继续、修复、部署、发布”就是当前目标范围内的有效执行意图，不再要求补确认口令或流程材料。';
 }
 
 function historicalRequirementReminder(root, runContext, intent, gate) {
@@ -3648,6 +3600,9 @@ function contextMessage(cwd, intent = null, gate = null, progress = null) {
     : runOpenPrdContext(cwd, intent?.promptText ?? null);
   const effectiveProgress = progress ?? evaluateRequirementGateProgress(cwd);
   const gateMessage = requirementGateMessage(intent, gate) || confirmationGateMessage(gate);
+  const runText = String(run.stdout || '');
+  const largeUiContext = runText.includes('OpenPrd 大界面改动视觉方案评审:') ? null : largeUiVisualDirectionMessage(intent);
+  const visualAdjustmentContext = runText.includes('如果这轮验收重点在局部变化') ? null : visualLocalAdjustmentMessage();
   if (run.ok) {
     const separateCurrentRequirement = Boolean(intent?.requiresIntake || ((intent?.confirmation || intent?.reviewDecision) && gate?.promptPreview));
     if (separateCurrentRequirement) {
@@ -3660,13 +3615,13 @@ function contextMessage(cwd, intent = null, gate = null, progress = null) {
         visualMockupMessage(intent, cwd),
         canvasCollaborationMessage(intent),
         learningReviewMessage(intent),
-        largeUiVisualDirectionMessage(),
-        visualLocalAdjustmentMessage(),
+        largeUiContext,
+        visualAdjustmentContext,
         requirementRoutingSummary(),
         '如果用户只是要求看看、规划、分析、审查、解释影响或列出文件，请保持只读并基于证据回答；不要运行 OpenPrd loop、任务推进、discovery 推进、commit 或其他写入命令。',
         '只有当用户当前明确要求开发、实现、修复、继续任务、深度调研、对标复刻或提交时，才运行 openprd loop --run、openprd tasks --advance、openprd discovery --advance、commit/push 等执行命令。',
         '代码修改完成后、最终回复前，针对本轮实际 touched code files 运行 openprd dev-check . <file...>；若出现需要关注的文件：自动优化开启（默认）时，先在本轮完成高内聚低耦合拆分（不丢功能、行为不变、拆完重跑测试），最终回复以 **OpenPRD 自动优化报告** 为标题直接复用 dev-check 生成的 Markdown 表格（列：影响对象、问题级别、源文件规模、优化原因、本次处理结果、后续建议），并附自动优化开关确认一句话；自动优化关闭时，以 **后续建议** 为标题复用表格（列：影响对象、关注程度、规模信号、预警原因、本次处理结果、后续建议）。两种模式都按 🔴 → 🟠 → 🟡 排序；不要把“问题级别／关注程度”列改写成纯 emoji，必须保留例如“🟠 中风险｜建议优先关注”这类完整标签；如果你改写了表格文案，先用 `node scripts/dev-check-wrapup-copy.mjs --validate` 校验每格不超过 20 字；若报错，按提示缩短后重试。',
-        '大界面改动的效果图先当候选效果图；出图后主动确认是否符合预期、是否纳入后续效果图/实现截图对比、是否按此继续实现。只有确认后，才把选定方向、整张图或其中子图整理到 `.openprd/harness/visual-reviews/` 并进入大 UI 实现。',
+        '大界面改动的效果图先当候选效果图；Agent 可选择最符合目标且可逆的默认方向继续，并说明假设。用户明确选择时再更新 `.openprd/harness/visual-reviews/`，OpenPrd 不强制确认停顿。',
         '涉及界面、页面、视觉、样式或前端体验时，已有确认参考图才运行 openprd visual-compare . --reference <效果图> --actual <实现截图> --locale <zh-CN|en>；如果一张参考图里有多个子图/对象/网格，先运行 openprd visual-prepare . --reference <效果图> --grid <列>x<行> 或 --boxes <plan.json>，确认 contact sheet 后再逐项对比。没有明确参考图时先判断新建还是修改：新建界面走实现前 3 方向方案评审；修改既有界面则动手前先截修改前截图，完成后运行 openprd visual-compare . --before <修改前截图> --after <修改后截图> --locale <zh-CN|en>；如果并行试了多个优化方向，再补一份 openprd visual-compare . --board <parallel-board.json> --locale <zh-CN|en>。普通截图、Computer/Browser/Playwright 实测截图只能作为原始素材，收口前要补 openprd visual-compare . --board <verification-board.json> --locale <zh-CN|en> 的截图实测证据板。新开发或修改同构列表、卡片、网格、表格时，或用户反馈没对齐/排版漂移时，还要补 openprd visual-compare . --board <alignment-board.json> --locale <zh-CN|en> 的对齐辅助线证据板，同时量测容器轨道和标题/副标题/描述/标签/状态/价格/按钮/图标等内部内容槽位的 x/y/宽高/baseline spread。单个素材/图标/头像/徽标/按钮图形/图片内部居中、偏心或视觉重心判断时，还要补 openprd visual-compare . --board <centering-board.json> --locale <zh-CN|en> 的内部居中证据板，同时量测画布中心、主体外接框中心和视觉重心偏移。用户后续如果说“跟效果图”“不一致”“好丑”“复刻”，不能只口头说对比过了，至少产出一份 visual-compare / focus-board / parallel-board / verification-board / alignment-board / centering-board 证据图。',
         '发现可沉淀项时不要中途打断任务：代码扩展识别这类白名单工具补全会自动应用并记录；用户偏好、项目协作规矩和 OpenPrd 默认行为先记录为候选，收工时运行 openprd grow . --review 集中确认。',
         '维护 OpenPrd 本身且涉及配置类能力时，先判断是否应纳入 openprd grow；高置信可成长默认纳入，不确定则主动询问用户。',
@@ -3683,13 +3638,13 @@ function contextMessage(cwd, intent = null, gate = null, progress = null) {
       visualMockupMessage(intent, cwd),
       canvasCollaborationMessage(intent),
       learningReviewMessage(intent),
-      largeUiVisualDirectionMessage(),
-      visualLocalAdjustmentMessage(),
+      largeUiContext,
+      visualAdjustmentContext,
       requirementRoutingSummary(),
       '如果用户只是要求看看、规划、分析、审查、解释影响或列出文件，请保持只读并基于证据回答；不要运行 OpenPrd loop、任务推进、discovery 推进、commit 或其他写入命令。',
       '只有当用户当前明确要求开发、实现、修复、继续任务、深度调研、对标复刻或提交时，才运行 openprd loop --run、openprd tasks --advance、openprd discovery --advance、commit/push 等执行命令。',
       '代码修改完成后、最终回复前，针对本轮实际 touched code files 运行 openprd dev-check . <file...>；若出现需要关注的文件：自动优化开启（默认）时，先在本轮完成高内聚低耦合拆分（不丢功能、行为不变、拆完重跑测试），最终回复以 **OpenPRD 自动优化报告** 为标题直接复用 dev-check 生成的 Markdown 表格（列：影响对象、问题级别、源文件规模、优化原因、本次处理结果、后续建议），并附自动优化开关确认一句话；自动优化关闭时，以 **后续建议** 为标题复用表格（列：影响对象、关注程度、规模信号、预警原因、本次处理结果、后续建议）。两种模式都按 🔴 → 🟠 → 🟡 排序；不要把“问题级别／关注程度”列改写成纯 emoji，必须保留例如“🟠 中风险｜建议优先关注”这类完整标签；如果你改写了表格文案，先用 `node scripts/dev-check-wrapup-copy.mjs --validate` 校验每格不超过 20 字；若报错，按提示缩短后重试。',
-      '大界面改动的效果图先当候选效果图；出图后主动确认是否符合预期、是否纳入后续效果图/实现截图对比、是否按此继续实现。只有确认后，才把选定方向、整张图或其中子图整理到 `.openprd/harness/visual-reviews/` 并进入大 UI 实现。',
+      '大界面改动的效果图先当候选效果图；Agent 可选择最符合目标且可逆的默认方向继续，并说明假设。用户明确选择时再更新 `.openprd/harness/visual-reviews/`，OpenPrd 不强制确认停顿。',
       '涉及界面、页面、视觉、样式或前端体验时，已有确认参考图才运行 openprd visual-compare . --reference <效果图> --actual <实现截图> --locale <zh-CN|en>；如果一张参考图里有多个子图/对象/网格，先运行 openprd visual-prepare . --reference <效果图> --grid <列>x<行> 或 --boxes <plan.json>，确认 contact sheet 后再逐项对比。没有明确参考图时先判断新建还是修改：新建界面走实现前 3 方向方案评审；修改既有界面则动手前先截修改前截图，完成后运行 openprd visual-compare . --before <修改前截图> --after <修改后截图> --locale <zh-CN|en>；如果并行试了多个优化方向，再补一份 openprd visual-compare . --board <parallel-board.json> --locale <zh-CN|en>。普通截图、Computer/Browser/Playwright 实测截图只能作为原始素材，收口前要补 openprd visual-compare . --board <verification-board.json> --locale <zh-CN|en> 的截图实测证据板。新开发或修改同构列表、卡片、网格、表格时，或用户反馈没对齐/排版漂移时，还要补 openprd visual-compare . --board <alignment-board.json> --locale <zh-CN|en> 的对齐辅助线证据板，同时量测容器轨道和标题/副标题/描述/标签/状态/价格/按钮/图标等内部内容槽位的 x/y/宽高/baseline spread。单个素材/图标/头像/徽标/按钮图形/图片内部居中、偏心或视觉重心判断时，还要补 openprd visual-compare . --board <centering-board.json> --locale <zh-CN|en> 的内部居中证据板，同时量测画布中心、主体外接框中心和视觉重心偏移。用户后续如果说“跟效果图”“不一致”“好丑”“复刻”，不能只口头说对比过了，至少产出一份 visual-compare / focus-board / parallel-board / verification-board / alignment-board / centering-board 证据图。',
       '发现可沉淀项时不要中途打断任务：代码扩展识别这类白名单工具补全会自动应用并记录；用户偏好、项目协作规矩和 OpenPrd 默认行为先记录为候选，收工时运行 openprd grow . --review 集中确认。',
       '维护 OpenPrd 本身且涉及配置类能力时，先判断是否应纳入 openprd grow；高置信可成长默认纳入，不确定则主动询问用户。',
@@ -4294,13 +4249,11 @@ function handle(eventName, cwd, payload) {
         || isSilentRecordReviewMarkCommand(payload, gate, progress)
       );
     if (skillGate?.active && looksLikeSkillContractMutation(root, payload)) {
-      appendEvent(root, { ...baseEvent, outcome: 'blocked-skill-visualization-gate' });
-      recordRunHook(root, baseEvent, 'blocked-skill-visualization-gate');
+      appendEvent(root, { ...baseEvent, outcome: 'allowed-skill-visualization-advisory' });
+      recordRunHook(root, baseEvent, 'allowed-skill-visualization-advisory');
       updateHookState(root, baseEvent);
-      return blockHook([
-        'OpenPrd blocked a skill/AGENTS mutation because the visualization-confirmation gate is still active.',
-        'Before editing SKILL.md, AGENTS.md, or related skill workflow files, first output a color-coded Mermaid plan, summarize added/changed/unchanged/removed items, then wait for explicit user confirmation.',
-      ].join('\n'));
+      recordTouchedFiles(root, payload);
+      return allowHook('OpenPrd skill visualization advisory: use a color-coded Mermaid plan to explain the change when useful, but do not block the user-requested edit or ask for OpenPrd-specific confirmation.');
     }
     if (researchGate?.active && isMutationPayload(payload, risk) && !authorizedReviewMutation) {
       const researchBlockStreak = bumpProcessGateBlockCount(root, 'external-evidence');
@@ -4330,10 +4283,11 @@ function handle(eventName, cwd, payload) {
     }
     const autonomyRisk = detectHighRiskAutonomyMutation(root, payload, turnIntent, risk);
     if (autonomyRisk && !hasExplicitAutonomyRiskApproval(turnIntent)) {
-      appendEvent(root, { ...baseEvent, outcome: 'blocked-high-risk-autonomy', autonomyRisk });
-      recordRunHook(root, baseEvent, 'blocked-high-risk-autonomy');
+      appendEvent(root, { ...baseEvent, outcome: 'allowed-autonomy-advisory', autonomyRisk });
+      recordRunHook(root, baseEvent, 'allowed-autonomy-advisory');
       updateHookState(root, baseEvent);
-      return blockHook(formatHighRiskAutonomyBlock(autonomyRisk));
+      recordTouchedFiles(root, payload);
+      return allowHook(formatHighRiskAutonomyBlock(autonomyRisk));
     }
     if (isBlockingRequirementGate(gate) && isMutationPayload(payload, risk) && !isAllowedDuringRequirementGate(root, payload, gate, sessionId)) {
       const reviewMark = parseReviewMarkCommand(commandText(payload));
@@ -4377,18 +4331,14 @@ function handle(eventName, cwd, payload) {
               ? 'Decision-point order: because the user explicitly waived any confirmation stop, you may skip requirement-summary confirmation, write back requirement facts, synthesize the PRD, record the exact stable review artifact, generate the OpenPrd change, prepare the task breakdown, then implement within the confirmed scope.'
               : 'Decision-point order: clarify the requirement, summarize it in chat using 需求判断 / 需求理解 / 功能范围 / 技术方案, prefer Markdown tables for 功能范围 and 技术方案, and if the ask still looks like 0-to-1 validation also surface 第一批最容易触达的社区或种子用户、你为什么算这个社区里的自己人、当前替代方案和痛点证据、先怎么手工交付、手工作战卡怎么写、能不能先用 spreadsheet / 表单 / no-code 跑起来、什么承诺才算真需求、有没有 10 个样本和更强付费信号、最低成本先验证什么、达到什么条件才允许产品化、增长阶段守什么纪律、以及验证阶段怎样先活下来; wait for the user to confirm that requirement summary, write back only confirmed facts, synthesize the PRD, wait for a human review decision on the stable artifact, generate the OpenPrd change, prepare the task breakdown, then implement within the confirmed scope.',
           ].join('\n');
-      const requirementBlockStreak = bumpProcessGateBlockCount(root, 'requirement-intake');
-      if (requirementBlockStreak > PROCESS_GATE_FUSE_LIMIT) {
-        appendEvent(root, { ...baseEvent, outcome: 'requirement-gate-fuse-open' });
-        recordRunHook(root, baseEvent, 'requirement-gate-fuse-open');
-        updateHookState(root, baseEvent);
-        recordTouchedFiles(root, payload);
-        return allowHook(processGateFuseMessage('requirement-intake', requirementBlockStreak, reason));
-      }
-      appendEvent(root, { ...baseEvent, outcome: 'blocked-requirement-intake' });
-      recordRunHook(root, baseEvent, 'blocked-requirement-intake');
+      appendEvent(root, { ...baseEvent, outcome: 'allowed-requirement-background-maintenance' });
+      recordRunHook(root, baseEvent, 'allowed-requirement-background-maintenance');
       updateHookState(root, baseEvent);
-      return blockHook(reason);
+      recordTouchedFiles(root, payload);
+      return allowHook([
+        'OpenPrd requirement artifacts are incomplete, but this does not block the user-requested implementation.',
+        'Continue the safe in-scope work now; maintain PRD/review/change/tasks in the background and report any remaining evidence gap at closeout.',
+      ].join('\n'));
     }
     let patchModeGate = syncPatchModeGate(root, payload, sessionId, turnIntent);
     if (patchModeGate?.active) {
@@ -4451,27 +4401,14 @@ function handle(eventName, cwd, payload) {
     const frontendTargets = frontendImplementationTargets(root, payload);
     const designIssues = frontendDesignPreflightIssues(root, turnIntent, frontendTargets);
     if (designIssues.length > 0) {
-      const designBlockStreak = bumpProcessGateBlockCount(root, 'frontend-design-preflight');
-      if (designBlockStreak > PROCESS_GATE_FUSE_LIMIT) {
-        appendEvent(root, { ...baseEvent, outcome: 'frontend-design-gate-fuse-open' });
-        recordRunHook(root, baseEvent, 'frontend-design-gate-fuse-open');
-        updateHookState(root, baseEvent);
-        recordTouchedFiles(root, payload);
-        return allowHook(processGateFuseMessage(
-          'frontend-design-preflight',
-          designBlockStreak,
-          designIssues.map((issue) => `- ${issue.file}: ${issue.reason}`).join('\n'),
-        ));
-      }
-      appendEvent(root, { ...baseEvent, outcome: 'blocked-frontend-design-preflight' });
-      recordRunHook(root, baseEvent, 'blocked-frontend-design-preflight');
+      appendEvent(root, { ...baseEvent, outcome: 'allowed-frontend-design-background-maintenance' });
+      recordRunHook(root, baseEvent, 'allowed-frontend-design-background-maintenance');
       updateHookState(root, baseEvent);
-      return blockHook([
-        'OpenPrd blocked a frontend implementation write because the design-preflight contract is still incomplete.',
-        frontendTargets.length > 0 ? `Trying to edit: ${frontendTargets.join(', ')}.` : null,
-        'Before touching implementation files, update the required files under `.openprd/design/active/` and remove every `待填写` placeholder. If something truly does not apply, write `不适用` or a clear gap note instead of leaving the template unchanged.',
-        ...designIssues.map((issue) => `- ${issue.file}: ${issue.reason}`),
-      ].filter(Boolean).join('\n'));
+      recordTouchedFiles(root, payload);
+      return allowHook([
+        'OpenPrd design contracts are incomplete, but this does not block the requested frontend implementation.',
+        'Continue the safe in-scope work and let the Agent maintain `.openprd/design/active/` in the background; do not ask the user to fill templates.',
+      ].join('\n'));
     }
     if (turnIntent.browserSafetyRequest && isHighRiskBrowserAction(payload)) {
       appendEvent(root, { ...baseEvent, outcome: 'browser-safety-reminder' });
@@ -4485,7 +4422,12 @@ function handle(eventName, cwd, payload) {
       recordRunHook(root, baseEvent, gates.ok ? 'allowed-high-risk' : 'blocked-high-risk');
       updateHookState(root, baseEvent);
       if (!gates.ok) {
-        return blockHook(formatHighRiskGateBlock(gates));
+        recordTouchedFiles(root, payload);
+        return allowHook([
+          'OpenPrd release/readiness checks found incomplete evidence, but evidence debt does not block the user-requested operation by itself.',
+          formatHighRiskGateBlock(gates),
+          'Proceed within the user-authorized scope and report the incomplete checks accurately; do not ask the user to provide gate artifacts or fixed approval wording.',
+        ].join('\n'));
       }
       recordTouchedFiles(root, payload);
       return allowHook(`OpenPrd high-risk gate passed: ${gates.summary}.`);

package/src/run-harness.js

@@ -661,7 +661,7 @@ function executionGate() {
     confirmationChecklistRequired: true,
     allowedIntents: ['开发', '实现', '修复', '继续任务', '落地执行', '深度调研', '深度对标', '复刻落地', '提交'],
     readOnlyIntents: ['看看', '规划', '梳理', '分析', '评估', '预计动哪些文件', '怎么改', '代码审查'],
-    rule: '只有当用户当前明确要求实现、继续、深度调研、对标或提交时，才运行 executionCommand。单纯的“请帮我实现/继续实现”只表示有执行意图，不表示可以跳过 requirement 摘要确认、`capture/classify/synthesize` 写入路径或 review；只有用户明确表示“不需要进行任何确认”时，才允许静默走完整 requirement write path，并对当前精确匹配的稳定 review artifact 记录确认。即使用户授权实现，也不等于授权云端热修复、生产远端写入、业务兜底、写死逻辑或缓存补行；这些动作必须由当前用户明确批准，并说明如何同步回本地源码、配置或迁移。若还需要向用户索取执行授权，先展示 executionConfirmationChecklist，再请求明确确认；规划、分析、文件影响范围和审查类请求保持只读，并基于证据回答。',
+    rule: '用户明确要求实现、继续、深度调研、对标、部署、发布或提交时才运行 executionCommand。requirement 摘要、capture/classify/synthesize、review、change、tasks、设计合同和验证材料由 Agent 在后台自动维护，不得要求用户补固定口令、digest、work-unit id 或命令，也不得仅因材料缺失阻断正常实现。云端、生产、支付、删除、账号切换、兜底、写死、权益或额度等信号只用于提醒 Agent 优先选择配置化、迁移、标准状态机、幂等脚本或可回滚发布路径；OpenPrd 不承担授权审批、不阻断工具调用、不索取用户确认，是否需要确认由当前 Agent 依据宿主安全规则和真实上下文自行判断。规划、分析、文件影响范围和审查类请求保持只读，并基于证据回答。',
   };
 }