@openprd/cli 0.1.10 → 0.1.18

package/skills/openprd-requirement-intake/SKILL.md

@@ -27,7 +27,7 @@ description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品
 脑暴模式是独立 lane，不等于普通 clarify：
 
 - 目的不是只补字段，而是先判断值不值得做、给谁做、为什么现在做、有哪些方向、当前工作区能复用什么。
-- 每轮至少要把这几类关键点补齐：第一批最容易触达的社区或人群、现在怎么解决、为什么现在想换、如果先不做完整产品怎么手工交付、什么真实承诺最能证明不是口头兴趣、先怎么低成本验证、验证阶段怎样先活下来、什么情况下先停。
+- 每轮至少要把这几类关键点补齐：第一批最容易触达的社区或人群、你为什么算这个社区里的自己人、现在怎么解决、当前 workaround 到底有多痛、如果先不做完整产品怎么手工交付、能否先用 spreadsheet 或 no-code 跑起来、什么真实承诺最能证明不是口头兴趣、有没有 10 个样本和更强付费信号、达到什么条件才允许产品化、先怎么低成本验证、验证阶段怎样先活下来，以及什么情况下先停。
 - 资料来源默认同时包含 benchmark、knowledge、当前工作区文档/代码和开放问题。
 - 如果用户能提供更大的工作区或历史项目目录，优先一起扫描可复用能力、旧流程和已有产品做法。
 - 用户没有明确要求时，Agent 只能“建议进入脑暴模式”，不能静默切换。
@@ -57,6 +57,7 @@ description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品
    - 只有内部排障真的受益时，才额外补一行“内部路由码”
    - 需求理解：主要服务对象 / 使用场景 / 第一版先做什么 / 这轮先不做什么 / 必须守住什么
    - `需求判断` 和 `需求理解` 先用 1 到 2 句轻量主句说清“这次是什么 / 核心问题是什么 / 第一版先做到什么”；能一句话说清就不要写两句话。范围边界、风险边界、异常例子和技术细节下沉到后面的分项或表格，不要全塞进同一整段长话里。
+   - 如果需求理解里同时出现多个角色、路径、状态、前后对比、风险传播或取舍关系，优先补一张解释型 SVG 图来承载结构；图后只保留必要结论、开放问题和下一步。
    - 这里沉淀的是表达风格，不是固定示例文案；要根据本次内容自适应生成，不要机械套同一句模板。
    - 功能范围：优先用 Markdown 表格写 `功能模块 | 这次先做什么 | 这次先不做什么`
    - 技术方案：优先用 Markdown 表格写 `技术部分 | 初步方案 | 主要负责什么`；涉及前端、后端、Agent、数据或集成时，按用户能看懂的功能视角拆开
@@ -83,13 +84,14 @@ description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品
 ### L2
 
 - 如果用户明确要梳理、先想清楚、进入脑暴模式，或这句话明显还需要先收敛业务方向，先运行或建议 `openprd brainstorm . --topic <当前主题> --open`，不要只在对话里先给一版 requirement 摘要代替脑暴模式。
-- 进入脑暴模式后，Agent 默认先用“创业验证透镜”追问和收口：第一批可触达社区/种子用户、当前替代方案、手工交付路径、承诺信号、最低成本验证、default alive 约束，再补核心诉求、推荐方向、关键角色和复用基础。
+- 进入脑暴模式后，Agent 默认先用“创业验证透镜”追问和收口：第一批可触达社区/种子用户、你为什么算这个社区里的自己人、当前替代方案和痛点强度、手工交付路径、手工作战卡、一件事 MVP、周末级验证、能否先用 spreadsheet / 表单 / no-code 跑起来、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、第一批客户路径、初始收费假设、客户 1 盈利路径、10 个样本和付费验证信号、达到什么条件才允许产品化、default alive 约束、增长纪律、可逆性、客户真问题判断和价值观一致性（是不是你愿意长期住进去的业务形态），再补核心诉求、推荐方向、关键角色和复用基础。
 - 进入脑暴模式后，至少要形成 `brainstorm.html` 这类可继续评审和推进的产物，再基于产物追问或收口。
 - 其他 L2 默认先运行或建议 `openprd clarify .`。
 - 先建立首轮项目画像：用户群体、产品形态、第一版切片、暂不处理、不能破坏和风险探针。
-- 对话内 requirement 摘要除了常规的用户、范围、风险，还要主动抬出“第一批最容易先找谁验证、用户现在怎么解决、先怎么手工交付、什么承诺才算真需求、最低成本先验证什么、验证阶段怎样先活下来”。
+- 对话内 requirement 摘要除了常规的用户、范围、风险，还要主动抬出“第一批最容易先找谁验证、你为什么算这个社区里的自己人、用户现在怎么解决、这个 workaround 到底有多痛、先怎么手工交付、手工作战卡怎么写、第一版只做哪一件事、能不能压成周末级 MVP、能不能先用 spreadsheet / 表单 / no-code 跑起来、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、第一批客户路径、从第一个客户开始怎么收费、客户 1 如何打平成本、有没有 10 个样本和更强付费信号、达到什么条件才允许产品化、增长阶段守什么纪律、验证阶段怎样先活下来，以及这条路是否可逆、是否真在解决客户问题、是否符合团队价值观、是不是你愿意长期住进去的业务形态”。
 - 再用对话内结构化摘要确认需求，默认按“需求判断 / 需求理解 / 功能范围 / 技术方案”的顺序来写，其中“功能范围”和“技术方案”优先用 Markdown 表格。
 - `需求判断` 和 `需求理解` 先轻后重：先用轻量主句给用户一个一眼能懂的结论，再把边界、风险和技术细项下沉到后续表格或分项里；不要把它们揉成一大段说明。
+- 如果 L2 摘要正在解释新流程、新角色关系、状态机、前后方案差异、依赖边界或失败恢复路径，先用解释型 SVG 图降低理解成本，再用表格承接范围和技术分工。
 - 优先由 Agent 先归纳，再请用户确认；默认先问 1 个最高价值问题，必要时再给 2 到 3 个方向和取舍供用户选，不要一次砸一整墙问题。
 - 当前还是 L2 的首轮澄清或 requirement 摘要确认阶段时，只能承诺“我先整理需求摘要给你确认”；不要写成“你回我一句我就开始实现”，也不要把 requirement 摘要确认、review 和实现压成一句话。
 - 单纯的“请帮我实现/继续实现”只表示用户希望最终落地，不表示可以跳过 requirement 摘要确认、`capture/classify/synthesize` 写入路径或 review；只有用户明确表示“不需要进行任何确认”时，才允许静默走完整 requirement write path。

package/skills/openprd-requirement-intake/references/prd-template-lenses.md

@@ -9,7 +9,7 @@
 3. 做到什么程度：目标、成功指标、验收标准
 4. 做什么和不做什么：范围、非目标、边界情况
 5. 用户怎么走：主流程、失败路径、恢复路径
-6. 值不值得继续做：第一批可触达社区、种子用户、当前替代方案、手工交付路径、承诺信号、最低成本验证、default alive 约束
+6. 值不值得继续做：第一批可触达社区、种子用户、社区契合依据、当前替代方案、痛点证据、手工交付路径、手工作战卡、手工/表单/no-code 桥接、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、一件事 MVP、周末级验证、第一批客户路径、初始收费假设、客户 1 盈利路径、承诺信号、10 个样本与付费验证、最低成本验证、产品化门槛、增长纪律、default alive 约束、可逆性、客户真问题校验和价值观一致性（是不是你愿意长期住进去的业务形态）
 7. 需求怎么验收：需求矩阵、优先级、验收标准、测试/验证
 8. 有什么风险：依赖、约束、成本、滥用、开放问题
 9. 如何交接：review、change、tasks、负责人、下一步
@@ -103,6 +103,6 @@
 
 - 不输出大段空字段或 TBD 墙；缺事实时进入开放问题。
 - 不把类型专项字段堆在末尾；把它们融进用户、流程、需求矩阵、验收和风险。
-- 如果当前需求仍然像 0 到 1 验证，不要只写“做什么功能”；还要写清第一批先找谁、现在怎么替代、如何先手工交付、什么承诺才算真需求，以及验证阶段怎样先活下来。
+- 如果当前需求仍然像 0 到 1 验证，不要只写“做什么功能”；还要写清第一批先找谁、为什么你算这个社区里的自己人、现在怎么替代、到底痛在哪里、如何先手工交付、手工作战卡、能不能先用表单 / spreadsheet / no-code 跑、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、一件事 MVP、周末级验证、第一批客户路径、从第一个客户开始怎么收费、客户 1 如何打平成本、什么承诺才算真需求、有没有 10 个样本和更强付费信号、达到什么条件才允许产品化、增长阶段守什么纪律，以及验证阶段怎样先活下来、是否可逆、是否真在解决客户问题、是否符合团队价值观、是不是你愿意长期住进去的业务形态。
 - PRD 写产品判断，`design.md` 写技术方案，`tasks.md` 写执行步骤。
 - 每条 requirement 都应能追踪到验收标准和后续 task。

package/skills/openprd-requirement-intake/references/startup-validation-lens.md

@@ -1,23 +1,108 @@
 # 创业验证透镜
 
-当 L2 需求、脑暴模式或 0 到 1 方向讨论还停留在“做什么功能”时，用这组问题把它收回到更真实的验证闭环。
+当 L2 需求、脑暴模式或 0 到 1 方向讨论还停留在“做什么功能”时，用这组问题把它收回到更真实的创业验证闭环。重点不是多补几个字段，而是把“怎么保持小、什么时候不要继续做大”变成默认判断链。
 
-## 六个关键问题
+## 保持小的六道门
 
-1. 第一批最容易触达的社区、渠道或人群是谁？
-2. 他们现在主要靠什么替代方案、流程或人工方式在解决？
-3. 如果先不做完整产品，怎么靠手工服务、半自动流程或轻量交付先把价值跑出来？
-4. 什么真实承诺最能证明这不是口头兴趣？
-5. 最低成本先验证哪一步最关键？
-6. 在验证阶段，怎样控制成本、时间和交付方式，确保这件事先活下来？
+### 1. 社区门
+
+先问是不是这个社区里的自己人，而不是先问功能点子够不够酷。
+
+- 第一批最容易触达的社区、渠道或人群是谁？
+- 你为什么算这个社区里的自己人？你理解他们的语言、价值观和工作方式吗？
+- 你现在是否已经在这个社区里真实参与、贡献或交付，而不是只把它当作潜在市场？
+- 他们主要在哪里聚集？你现在就能接触到他们吗？
+- 你能不能说出至少 10 个具体的人、团队或试点对象？
+- 这个切口是不是足够小、足够聚焦，能先在一个小圈层里做深？
+
+如果连 10 个具体对象都说不出来，或你其实不属于这个社区，先不要急着进入方案设计。
+
+### 2. 痛点门
+
+先看现在怎么解决，再看值不值得替换。
+
+- 他们现在主要靠什么替代方案、流程、人工 workaround 或更差的付费方案在解决？
+- 这个问题到底有多痛？只是轻微不爽，还是高频、卡业务、卡收入、卡交付？
+- 他们已经在为这个问题花什么时间、精力或金钱？
+- 能不能用一句话说清“谁在什么场景下，被什么问题反复卡住”？
+- 如果需要先教育用户“你其实有这个问题”，这通常是红旗。
+
+当前 workaround 就是你的真实竞争对手；如果没有 workaround，往往说明痛点还不够真。
+
+### 3. 最小执行门
+
+先 processize，再 productize。
+
+- 如果今天禁止你写复杂代码，只能用自己、电话、表单、spreadsheet、Zapier、Notion、Airtable 这类现成工具，你会怎么把价值跑出来？
+- 先不做完整产品时，怎么靠手工服务、半自动流程或轻量交付把结果交出去？
+- 这份手工作战卡怎么写：触发条件、关键步骤、工具、单客耗时和交接点分别是什么？
+- 第一天到底只做哪一件事？一句话讲不清，就说明范围还没收够。
+- 能不能压成周末级 MVP、顾问式试跑或更轻验证？
+- 如果已经不得不开始做产品，能不能只自动化最重复的一步，并把第一版压成 forms / lists / CRUD 这种最轻骨架？
+- 这一步是在服务今天已经存在的客户和重复需求，还是在为假想中的未来规模、未来角色和未来复杂度提前造壳？
+
+这里的“手工作战卡”就是 `Magic Piece of Paper`。重点不是格式漂亮，而是让别人拿到也能继续交付。
+
+### 4. 付费验证门
+
+兴趣不算验证，交易或更强承诺才算。
+
+- 你是否至少和 10 个潜在对象聊过，或已经能明确列出这 10 个样本？
+- 这 10 个样本里，是否至少有大约 3 个愿意付费、预付、安排试点，或给出更强的真实承诺？
+- 什么真实承诺最能证明这不是口头兴趣？例如愿意预约、导入真实数据、提交真实素材、拉同事一起试、接受明确上线窗口。
+- 从第一个客户开始准备怎么收费？什么价格既是 no-brainer，又不会因为免费而失真？
+- 第一个客户如何覆盖时间和交付成本，让这条路更接近 default alive？
+
+“早收费”不是为了立刻赚钱，而是避免 zero price effect。免费可以短时例外，但不能长期拿免费当真需求证明。
+
+### 5. 产品化门
+
+不是“有点反馈了就继续加功能”，而是“达到门槛才允许产品化”。
+
+- 在继续产品化前，要不要先满足这些条件：已经服务过 10+ 付费客户、需求开始重复、手工作战卡几周没大改、你花在交付上的时间开始明显高于找客户？
+- 如果这些条件还不满足，当前最合理的动作是不是继续手工、继续 no-code、继续顾问式试跑，而不是扩成功能列表？
+- 现在明确先不 build 的东西有哪些？
+- 哪一步最值得先自动化？为什么是它，而不是整个系统一起上？
+- 就算开始做产品，第一版是否也只自动化这一小步，而不是马上做成平台、工作台或全流程系统？
+- 如果现在继续做大会产生哪些不可逆决策？例如重招聘、长期绑定、复杂权限、重平台化或高维护承诺。
+
+默认先自动化最费时、最稳定、最重复的那一步，而不是把整套系统一次性做完。
+
+### 6. 增长门
+
+先卖，再 launch；先花时间，再花钱。
+
+- 第一批客户最现实的触达顺序是什么？先熟人、现有客户、社区，还是陌生线索？
+- 在有足够付费基础前，是否应该把 launch 当成庆祝而不是获客策略？
+- 在没有自然增长和明确客户画像前，是否应该先花时间做内容、访谈、私聊和手动销售，而不是先投广告或招人？
+- 什么情况下才允许进入更主动的营销、付费增长或团队扩张？
+- 这条路怎样才能先活下来，而不是先把成本、复杂度和维护负担做爆？
+
+`slavingia/skills` 的强约束是：没有真实付费基础前，不要把 marketing、launch、ads 和规模化错当成解决验证问题的手段。
+
+## 常见红旗
+
+- 目标用户太泛，像“所有创业者”“所有做内容的人”“所有用 AI 的团队”。
+- 你并不在这个社区里，只是觉得这个市场可能很大。
+- 需要先教育别人“你有这个问题”，而不是顺着现有抱怨或现有 workaround 切入。
+- 第一反应是做完整产品，而不是先做手工服务、表单、spreadsheet 或 no-code。
+- 明明还没付费验证，就开始讨论规模化架构、复杂权限、自动化编排或营销投放。
+- 还没拿到稳定重复需求，就先往“多功能平台”“一站式工作台”“全流程闭环”扩。
+- 现在服务的还是假想中的未来客户，而不是今天已经能找到、已经在痛的那批人。
+- 还没跑顺最小成交链，就先做重招聘、长期绑定或其他难回头的决策。
 
 ## 使用方式
 
-- 不要机械逐条盘问；优先把它融进 requirement 摘要、脑暴卡片和追问顺序里。
+- 不要机械逐条盘问；优先把这六道门融进 requirement 摘要、脑暴卡片和追问顺序里。
 - 如果用户已经明确提供其中几项，就直接吸收，不要重复确认。
 - 对内部工具、团队流程或 Agent 项目，也照样适用。
   这里的“社区 / 种子用户”可以是维护者、运营、交付、内部试点团队或最先受影响的一线角色。
-- “承诺信号”不等于一定要收费。
-  也可以是愿意预约、提交真实素材、导入数据、拉同事参与、接受试点、给出明确上线窗口等更强承诺。
-- “default alive”不是财务口号，而是提醒 Agent 先问清楚：
-  这件事在验证阶段怎样不把成本、复杂度和维护负担一下子做爆。
+- requirement 摘要和 brainstorm 默认至少要覆盖：
+  - `communityFit`：为什么算自己人、在哪里触达、为什么是小而可达的切口
+  - `painEvidence`：当前 workaround、痛点强度、已付出的时间或金钱
+  - `paymentProof`：10 个样本、3/10 付费意愿或更强承诺
+  - `smallestExecution`：spreadsheet / 表单 / no-code / 手工桥接，以及明确不 build 的部分
+  - `productizeGate`：达到什么条件才继续产品化
+  - `growthDiscipline`：熟人到陌生线索的顺序、何时不该 launch、先花时间别先花钱
+- “default alive”不是财务口号，而是提醒 Agent 先问清楚：这件事在验证阶段怎样不把成本、复杂度和维护负担一下子做爆。
+- “minimalist review” 不只看市场大不大，还要看这条路是不是更简单、更可逆、更贴近客户真问题，并且不违背团队想坚持的价值观；更进一步，还要问这是不是你愿意长期住进去、不会反过来绑住自己的业务形态。

package/skills/openprd-router/SKILL.md

@@ -34,7 +34,7 @@ description: OpenPrd 入口路由 skill。先判断当前任务该读哪个 repo
 - 最佳实践、benchmark、公开 GitHub 仓库、第三方技术事实、prompt/context engineering：`skills/openprd-benchmark-router/SKILL.md`
 - `docs/basic/`、文件说明书、文件夹 README、文档标准：`skills/openprd-standards/SKILL.md`
 - 就绪验证、EVO 门禁、HTML 质量评估报告、项目经验沉淀：`skills/openprd-quality/SKILL.md`
-- 架构图、产品流程图、可视评审、大界面改动效果图方案评审：`skills/openprd-diagram-review/SKILL.md` 与 `skills/openprd-harness/SKILL.md`
+- 架构图、产品流程图、解释型 SVG、可视评审、大界面改动效果图方案评审：`skills/openprd-diagram-review/SKILL.md` 与 `skills/openprd-harness/SKILL.md`
 - 长时间只读挖掘、参考项目持续调研、requirements/specs/tasks 补全：`skills/openprd-discovery-loop/SKILL.md`
 - 学习包、归档阅读器、知识整理：`skills/openprd-learning-review/SKILL.md`
 
@@ -46,3 +46,4 @@ description: OpenPrd 入口路由 skill。先判断当前任务该读哪个 repo
 - 如果用户只是要规划、分析、评审或解释影响范围，保持只读，不要因为命令存在就直接执行写入
 - 用户原话里已经明确要求“先梳理/脑暴”时，用户意图优先于不带 message 的默认 run context；先把原话带进 `openprd run . --context --message ...`，或直接进入脑暴模式
 - 不要用固定关键词决定是否写 PRD，也不要用词表决定工具；先让 `openprd-requirement-intake` 按影响面、未知数、决策成本和验证成本做语义分流，再按用户目标、期望产物、交付阶段和证据缺口选择学习器、视觉评审或质量收口工具
+- 当用户需要理解状态跳转、因果链、方案差异、边界分工或风险传播时，先读 `skills/openprd-diagram-review/SKILL.md`，优先用轻量解释型 SVG 辅助说明；不要把它误升级成正式评审图或视觉验收图

package/skills/openprd-shared/SKILL.md

@@ -20,6 +20,9 @@ description: OpenPrd 工作区与产物的共用守则。凡是需要查看、
 - 涉及第三方 API、模型、云服务、付费工具或外部供应商时，优先比较多家可行方案，用表格列出效果、价格、接入成本、限制、风险和推荐理由，并给出性价比最好的默认选择。
 - 当用户的问题包含多个对象、方案、文件、场景、风险、验证项、素材或任务，并且需要同时呈现状态、证据、影响、动作或推荐时，Agent 应主动使用 Markdown 表格，不等用户要求。先用一句话给结论，再给表格。
 - 表格优先用于方案对比、状态盘点、问题排查、风险审查、多对象 QA、文件/命令清单、需求场景覆盖和内容/素材规划；单一结论、单一动作、代码示例、命令示例和叙事型说明不要强行表格化。
+- 当用户需要理解复杂关系、状态跳转、因果链、边界分工、路径差异、风险传播或方案取舍时，优先用“结论 + 解释型 SVG 图 + 少量补充”的图解优先表达；能被一张图讲清的内容，不要先输出长段落文字。
+- 解释型 SVG 是对话辅助，不是正式评审或验收产物；它用于让用户快速看懂，不替代 `review.html`、`openprd diagram`、`visual-compare`、测试证据、调研证据或实现截图。
+- 图解优先不等于所有问题都画图：单一事实、短命令输出、简单 yes/no、精确错误文本、合规/安全必须逐字说明的内容，仍用简短文字或表格。
 - 如果用户明确说质量优先、稳定性优先或体验优先，就降低价格权重，优先保证效果、可靠性和长期可维护性。
 
 ## 共用运行规则
@@ -30,10 +33,11 @@ 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，必须有当前用户明确执行意图。
+   - 实现授权不包含云端热修复、生产远端写入、业务兜底、写死逻辑、客户端/服务端补业务数据或缓存补行；这些动作需要当前用户单独明确批准，并给出本地源码/配置/迁移同步与回滚计划。
 3. 不要虚构 OpenPrd 命令或产物类型。
    - 不确定时先对照 `openprd --help`。
 4. 共用规则放在这里，领域规则放到对应 skill。
-5. 默认用简体中文生成用户可见文档、报告，以及 Agent 产出的 spec 和 tasks；必要专有名词、品牌名、命令名、路径、字段名和 API 术语可以保留原文。
+5. 用户可见文档、报告，以及 Agent 产出的 spec 和 tasks 跟随用户当前主语言；无法判断时用简体中文兜底。必要专有名词、品牌名、命令名、路径、字段名和 API 术语可以保留原文。
    - OpenPrd 自身及随包 workspace / template / skill README 默认把简体中文放在 `README.md`，英文放在 `README_EN.md`；如需兼容旧链接，可保留 `README_CN.md` 作为跳转入口。
    - 如果 README、概览图或发布说明存在双语版本，带文字的图片资产也要与 `README.md` / `README_EN.md` 成对维护并同步更新，避免一边改了文案、另一边还停留在旧说法。
    - 入口路由优先看 `skills/openprd-router/SKILL.md`
@@ -61,36 +65,41 @@ description: OpenPrd 工作区与产物的共用守则。凡是需要查看、
    - 用户给出会话 ID 并要求继续时，按工具无关的历史会话精确续接；不要要求工具专属 ID，也不要用当前 active change、相似历史或 requirement gate 替代指定会话。
    - 用户没有给 ID、但明确描述了某个已有需求、change、task 或 work unit 时，先按描述解析对应对象；只有解析不出来时，才把当前工作区状态当作背景继续看。
    - 使用 `.openprd/harness/install-manifest.json`、`hook-state.json`、`events.jsonl` 和 `drift-report.json` 判断生成引导是否健康。
+   - 使用 `.openprd/harness/runtime-environment.json` 判断最近 hook/session 观察到的当前对话环境；协议和能力清单看 `.openprd/harness/install-manifest.json` 的 `runtimeDetection` / `platformCapabilityPacks`。
+   - 判断当前用户正在和 Codex、Claude Code 还是 Cursor 对话时，按 hook/session payload > 显式 launcher > SDK/headless session > 子进程 env > config/CLI probe > agent 自述的优先级处理。Codex 原生 Image 2、Computer Use、Codex-owned browser window、对话协同画布和当前线程文本桥接属于 surface-dependent 能力，只有当前工具面或 hook/session 证据明确支持时才使用；当前线程桥接只在 Codex App 明确提供线程发送工具时使用，画布图片仍以导出路径或 Markdown 图片引用作为证据；不要仅凭 Codex CLI、`.codex/config.toml` 或 `CODEX_HOME` 推断可用。
    - 前端体验任务进入实现前，优先读取 `skills/openprd-frontend-design/SKILL.md` 与 `.openprd/design/`，先锁定 lens、theme、layout 和组件，再决定是否实现。
-   - 使用 `.openprd/harness/visual-reviews/` 承接用户已经确认纳入后续对比的 reference-set、选中方向、实现后视觉对比证据、局部焦点证据板和并行实验证据板；候选效果图默认不要直接登记进去。
+   - 使用 `.openprd/harness/visual-reviews/` 承接用户已经确认纳入后续对比的 reference-set、选中方向、实现后视觉对比证据、局部焦点证据板、并行实验证据板、截图实测证据板和对齐辅助线证据板；候选效果图默认不要直接登记进去。
    - 使用 `.openprd/quality/config.json`、`.openprd/quality/reports/` 和 `.openprd/knowledge/` 判断实现就绪、当前场景必需 EVO 证据和可复用经验。
    - 使用 `.openprd/growth/` 承接收工阶段的自我成长复盘；工具识别补全和减少重复打扰这类高置信低风险项可自动补齐，用户偏好、项目协作规矩和 OpenPrd 默认行为留到收工时集中确认。
-10. 生成图片内容时默认使用 `imagegen`，也就是 Codex 原生 Image 2。
+10. 生成图片内容时默认使用 `imagegen`，也就是 Codex 原生 Image 2；Image 2 是工具路径，不是审美豁免。
    - 当用户要求生成图片、封面图、配图、海报、插画、图标、贴纸、头像、banner、主视觉/KV、运营图、效果图、视觉稿、mockup、先看样子或先确认设计方向时，默认直接调用 `imagegen` 产出图片。
+   - 生成前先写清用途、受众、气质、约束和记忆点，并把这些写进 prompt；没有品牌或参考图依据时，用 `.openprd/design/anti-slop.md` 排除默认紫白/蓝紫渐变、通用字体、白底卡片堆叠和无语境装饰。
    - 对 logo、icon、avatar、badge 等开发素材，如果用户没有明确要求 mockup、场景图、设备框、卡片承载、名片/包装展示或参考界面复刻，默认按 `独立素材输出（standalone asset）` 处理：使用全画布单主体，不额外添加 UI frame、卡片、设备壳、名片、桌面陈列、手持实拍或其他展示容器。
    - 只有当用户明确要求 mockup、场景化效果图、容器化呈现，或参考图本身就包含这些承载结构时，才生成对应的容器或场景。
    - 除非用户明确指定 HTML、SVG、CSS、Canvas、代码稿或可编辑矢量/source artifact，不要改用临时 HTML/SVG/CSS 再截图。
    - 只有实际发生 `imagegen` 调用后，才能汇报生图结果、失败或限流；未调用 `imagegen` 前，不要声称“生图限流”或“生图失败”。
-   - 生图结果先当候选效果图，不要默认登记到 `.openprd/harness/visual-reviews/`。如果用户还要继续做实现，主动确认是否符合预期、是否纳入后续效果图/实现截图对比、以及是否按此继续实现；只有确认后才把选定方向、整张图或其中子图整理成 reference-set。
-   - OpenPrd 的 `review.html` 只用于需求评审，不能替代图片或效果图生成；`visual-compare` 只用于实现阶段视觉证据：已有确认参考图时做“效果图 / 实现截图”对比；没有参考图时先判断新建界面还是修改既有界面，新建界面回到实现前 3 方向方案评审，修改既有界面做“修改前 / 修改后”自检；当局部细节更重要时，优先改用 `--board` 生成“局部焦点证据板”；当并行跑了多个优化方向时，优先改用 `--board` 生成“并行实验证据板”。
+   - 生图结果先当候选效果图，不要默认登记到 `.openprd/harness/visual-reviews/`。看图时不仅判断是否生成成功，还要判断气质、层级、字体/色彩/表面角色和记忆点是否成立。如果用户还要继续做实现，主动确认是否符合预期、是否纳入后续效果图/实现截图对比、以及是否按此继续实现；只有确认后才把选定方向、整张图或其中子图整理成 reference-set。
+   - OpenPrd 的 `review.html` 只用于需求评审，不能替代图片或效果图生成；`visual-compare` 只用于实现阶段视觉证据：已有确认参考图时做“效果图 / 实现截图”对比；没有参考图时先判断新建界面还是修改既有界面，新建界面回到实现前 3 方向方案评审，修改既有界面做“修改前 / 修改后”自检；当局部细节更重要时，优先改用 `--board` 生成“局部焦点证据板”；当并行跑了多个优化方向时，优先改用 `--board` 生成“并行实验证据板”；普通截图、Computer/Browser/Playwright 实测截图要作为视觉证据时，优先改用 `--board` 生成“截图实测证据板”；新功能或改动包含同构列表、卡片、网格或表格，或用户反馈没有对齐/排版漂移时，优先改用 `--board` 生成“对齐辅助线证据板”，叠辅助线并量相同槽位的 x/y/宽高 spread。visual evidence 同时检查气质、层级、字体/色彩/动效/表面角色和记忆点，不只检查截图是否存在。
 11. 界面视觉实现有参考图时，必须留下左右对比图。
    - 只要任务涉及界面、页面、视觉、样式或前端体验，并且已经有效果图、设计稿、截图或用户给图且进入实现阶段，阶段性完成后先截取实现截图。
-   - 运行 `openprd visual-compare . --reference <效果图> --actual <实现截图>`，默认输出 JPG 到 `.openprd/harness/visual-reviews/`。
+   - 运行 `openprd visual-compare . --reference <效果图> --actual <实现截图> --locale <zh-CN|en>`，默认输出 JPG 到 `.openprd/harness/visual-reviews/`。
    - 如果一张参考图里有多个子图、网格或对象，先运行 `openprd visual-prepare . --reference <效果图> --grid <列>x<行>` 或 `--boxes <plan.json>`，检查 contact sheet 后再逐项对比。
-   - 合成图左侧必须标注“效果图”，右侧必须标注“实现截图”；查看合成图后继续对标，直到没有明显视觉差异。若用户后续说“跟效果图”“不一致”“好丑”“复刻”，至少先产出一份视觉证据图，不要只口头说已经对比过了。
-   - 如果整体图之外还要审局部细节，再补一份 `openprd visual-compare . --board <focus-board.json>`，把整体标框和局部放大放在同一张证据板里。
+   - 合成图左侧必须标注“效果图”，右侧必须标注“实现截图”；查看合成图后继续对标，直到结构、气质、层级、字体/色彩/表面角色和记忆点都没有明显差异。若用户后续说“跟效果图”“不一致”“好丑”“复刻”，至少先产出一份视觉证据图，不要只口头说已经对比过了。
+   - 如果整体图之外还要审局部细节，再补一份 `openprd visual-compare . --board <focus-board.json> --locale <zh-CN|en>`，把整体标框和局部放大放在同一张证据板里。
+   - 如果新开发或修改了同构列表、卡片、网格或表格，或用户反馈没对齐/排版漂移，再补一份 `openprd visual-compare . --board <alignment-board.json> --locale <zh-CN|en>`，把真实截图、对齐辅助线、标题/标签/描述/状态/操作区等相同槽位的 x/y/宽高 spread 放在同一张证据板里。
    - 未生成并查看对比图，或对比图仍有明显差异时，不要声称界面复刻或视觉实现完成。
 12. 界面视觉实现无参考图时，先区分新建界面和修改既有界面。
    - 只要任务涉及界面、页面、视觉、样式或前端体验，但没有明确效果图、设计稿、截图或用户给图，先判断这是新建界面还是修改既有界面。
    - 新建首屏、首页、控制台或核心页面时，回到实现前 3 方向方案评审；修改既有界面时，动手前先用 Computer Use、Browser、Playwright 或项目现有工具截取修改前截图。
-   - 修改既有界面完成后，用同一入口、视口、账号和数据状态截取修改后截图，再运行 `openprd visual-compare . --before <修改前截图> --after <修改后截图>`。
-   - 合成图左侧必须标注“修改前”，右侧必须标注“修改后”；查看合成图后确认预期变化出现，并检查未改区域没有明显布局、颜色、密度或状态漂移。
-   - 如果并行试了多条优化方向，再补一份 `openprd visual-compare . --board <parallel-board.json>`，把多方案截图、GIF 首帧和指标放到同一板里对比。
+   - 修改既有界面完成后，用同一入口、视口、账号和数据状态截取修改后截图，再运行 `openprd visual-compare . --before <修改前截图> --after <修改后截图> --locale <zh-CN|en>`。
+   - 合成图左侧必须标注“修改前”，右侧必须标注“修改后”；查看合成图后确认预期变化出现，并检查本轮审美意图、记忆点和未改区域没有明显布局、颜色、密度或状态漂移。
+   - 如果并行试了多条优化方向，再补一份 `openprd visual-compare . --board <parallel-board.json> --locale <zh-CN|en>`，把多方案截图、GIF 首帧和指标放到同一板里对比。
+   - 如果只是普通截图或 Computer/Browser/Playwright 实测截图作为视觉或运行态证据，再补一份 `openprd visual-compare . --board <verification-board.json> --locale <zh-CN|en>`，把检查路径、截图和 checkpoint 放到同一板里。
    - 这类自检不能替代大界面方向性改造的实现前方案评审。
 13. 大界面改动实现前必须先完成视觉方案评审。
    - 触发条件：会明显改变页面信息架构、主视觉、核心布局、关键路径、组件层级/密度，或用户需要先选择设计方向。
    - 位置：需求分流之后、PRD 定稿或实现开工之前；它不是 `review.html`，也不是实现后的 `visual-compare`。
-   - 步骤：已有界面时用 Codex Computer Use 进入产品内对应功能并截当前真实界面；冷启动没有现有界面时，基于已确认 PRD、用户群体、第一版切片和视觉目标生成设计 brief；用 `imagegen`（Codex 原生 Image 2）基于截图或设计 brief 至少生成 3 个不同设计思想方向；把效果图横向拼成一张大图，每张左上角标注 1/2/3，先作为候选效果图展示。
+   - 步骤：已有界面时用 Codex Computer Use 进入产品内对应功能并截当前真实界面；冷启动没有现有界面时，基于已确认 PRD、用户群体、第一版切片、视觉目标、气质端点和记忆点生成设计 brief；用 `imagegen`（Codex 原生 Image 2）基于截图或设计 brief 至少生成 3 个不同设计思想方向；每个方向都要有具体审美主张和 anti-slop 自检；把效果图横向拼成一张大图，每张左上角标注 1/2/3，先作为候选效果图展示。
    - 交互：主动确认是否符合预期、是否纳入后续效果图/实现截图对比、以及是否按此继续实现；只有确认后才把选定方向、整张图或其中子图整理到 `.openprd/harness/visual-reviews/`。用户确认前，不进入大 UI 实现，也不要声称界面方案已定。
 14. 界面任务进入实现前，先用 `.openprd/design/` 锁定设计框架。
    - 页面涉及具体产品事实、版本、发布时间、规格、价格、引用数据或地点事实时，先补 `.openprd/design/active/facts-sheet.md`，不要凭记忆写页面。
@@ -101,13 +110,14 @@ description: OpenPrd 工作区与产物的共用守则。凡是需要查看、
 15. 把文档与结构回顾视为实现的一部分，而不是开工前的噪声。
    - 代码修改完成后、最终回复前，针对本轮实际新增或修改的 code files 运行 `openprd dev-check . <file...>` 或 `node scripts/openprd-dev-check.mjs . <file...>`。
    - dev-check 默认是收工回顾，不是开工许可证；只有用户明确询问影响文件、拆分边界，或你已经判断需要先设计拆分范围时，才在开发前额外运行。
-   - 行数状态按研发期标准解读：700 行以内正常；701-1500 行需留意；超过 1500 行说明后续改动成本较高。若出现需要关注的文件，最终回复必须以 **后续建议** 为标题，用 Markdown 表格列出影响位置、关注程度、规模信号、为什么需要关注、本次处理和后续建议，并按 🔴 → 🟠 → 🟡 排序；若只是窄 bugfix 或小修且暂不拆，要在表格里说明本次处理边界并留下后续拆分建议。
+   - 行数状态按研发期标准解读：700 行以内正常；701-1500 行需留意；超过 1500 行说明后续改动成本较高。自动优化开启（默认）时，命中需要关注的文件先在本轮直接完成高内聚低耦合拆分（不丢功能、行为不变），最终回复以 **OpenPRD 自动优化报告** 为标题复用 dev-check 表格（列：影响对象、问题级别、源文件规模、优化原因、本次处理结果、后续建议）并附开关确认；关闭后以 **后续建议** 为标题输出推荐表格（列：影响对象、关注程度、规模信号、预警原因、本次处理结果、后续建议）。两种模式都按 🔴 → 🟠 → 🟡 排序；若只是窄 bugfix 或小修且暂不拆，要在表格里说明本次处理边界并留下后续拆分建议。
    - 如果 dev-check 或执行过程发现可沉淀项，不要中途打断当前任务。高置信工具识别补全可自动固化并简短说明；用户偏好、项目协作规矩或 OpenPrd 默认行为先记录为候选，收工时运行 `openprd grow . --review` 集中确认。
    - 维护 OpenPrd 本身时，只要新增或修改配置类能力（阈值、规则、识别、豁免、命令别名、环境差异、用户偏好或策略开关），都要做 grow-aware 自检：高置信应可成长时默认纳入 `openprd grow`；不确定时主动问用户；明确一次性或固定规则时才保持静态配置。
    - 新增或修改文件时，检查 `docs/basic/`、文件说明书和文件夹 README 是否缺失或已过期。
    - 当职责、流程、结构、依赖或产品行为变化时，补齐缺失文档并更新已有文档。
    - 涉及后端、脚本、Agent、工具链、服务或数据处理变更时，把 CLI 与 API 视为同级接入面；检查命令入口、参数、输出契约、`help`/`doctor`/`dry-run`/`status` 与接口协议、返回结构、身份边界是否受影响，并同步更新 `docs/basic/backend-structure.md`；若某一面不适用也要明确写原因。
    - `.openprd/harness/install-manifest.json` 的 `optionalCapabilities` 用来记录非阻断式增强建议，例如 Context7、DeepWiki。当前任务明显受益但状态仍是 `recommended` 时，在后续建议里解释它能帮什么、附官方文档和 GitHub 链接，并可顺手提出“如果你愿意，我可以按当前客户端帮你补配置”；不要因为它未配置就阻断当前任务。
+   - `.openprd/harness/install-manifest.json` 的 `runtimeDetection` 和 `platformCapabilityPacks` 用来拆开不同 agent 平台的专属能力；Agent 应先识别当前对话客户端，再启用对应能力包，不要把 Codex、Claude Code、Cursor 的工具路径混在一套固定规则里。
 16. hook 重量要和任务风险匹配。
    - 默认 Codex hook profile 是 `lite`：`UserPromptSubmit` 注入上下文，轻量 `PreToolUse` 写入门禁阻断过早实现，`Stop` 在本轮结束前回顾是否值得沉淀项目经验。明确的 OpenPrd / 深度工作提示词，以及新的产品、模块、流程需求都会注入上下文。
    - 只有项目明确需要完整 hook 遥测或临时深度诊断时才使用 `full`。
@@ -119,7 +129,7 @@ description: OpenPrd 工作区与产物的共用守则。凡是需要查看、
    - 如果用户刚刚已经确认了现有功能优化（L1）的 mini-plan、范围边界或正式产品边界，后续承接要明确写成“已确认，我按这个继续/收口/落地”，不要只写一个“确认”，也不要写成“确认，我们就按这个……”这种像再次索取确认的句子。
 - 新功能/新流程方案包括新产品、模块、流程、权限、计费、AI/第三方集成、云服务、跨系统、数据迁移或边界不清的需求；先走 requirement intake、对话内 requirement 摘要确认、review、change 和 tasks，再实现。
 - 对话内 requirement 摘要保持原有“需求判断 / 需求理解 / 功能范围 / 技术方案”结构，但 `需求判断` 和 `需求理解` 先用轻量主句说清结论；边界、风险、异常例子和技术细节下沉到后面的分项或表格，不要把它们挤成一大段。
-- 对于 L2 或脑暴诉求，默认再补一层“创业验证闭环”：第一批最容易触达的人群/社区、当前替代方案、先不做完整产品时的手工路径、什么真实承诺才算真需求、最低成本验证动作，以及验证阶段怎样先活下来。
+- 对于 L2 或脑暴诉求，默认再补一层“创业验证闭环”：第一批最容易触达的人群/社区、你为什么算这个社区里的自己人、当前替代方案和痛点证据、先不做完整产品时的手工路径、手工作战卡、一件事 MVP、周末级验证、能否先用 spreadsheet / 表单 / no-code 跑起来、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、第一批客户路径、从第一个客户开始怎么收费、客户 1 如何打平成本、有没有 10 个样本和更强付费信号、达到什么条件才允许产品化、增长阶段守什么纪律，以及验证阶段怎样先活下来、这条路是否可逆、是否真在解决客户问题、是否符合团队价值观，以及这是不是你愿意长期住进去、不会反过来绑住团队的业务形态。
 - 历史 active change 在新 requirement intake 激活时只作为提醒，不抢当前主线。
    - 会话 ID、task handle、work unit 和用户明确描述的已有需求对象，都比全局 active change 更具体；必须先解析这些显式目标，再决定是否沿用当前工作区状态。
 18. 关键产品事实缺失时，先问用户再推进。
@@ -159,11 +169,11 @@ description: OpenPrd 工作区与产物的共用守则。凡是需要查看、
 - 只有当当前用户消息明确要求开发、实现、修复、继续任务、深度调研、对标复刻或提交时，才执行 OpenPrd loop、task 或 discovery 推进。
 - 单纯的“请帮我实现/继续实现”只表示有执行意图，不表示可以跳过 requirement 摘要确认、`capture/classify/synthesize` 写入路径或 review；只有用户明确表示“不需要进行任何确认”时，才允许静默走完整 requirement write path。
 - 声称实现就绪前，要说明文档影响检查是新增、更新，还是有意保持 `docs/basic/`、文件说明书和文件夹 README 不变。
-- 用户要求生成图片、封面图、配图、海报、插画、图标、贴纸、头像、banner、主视觉/KV、运营图、效果图、视觉稿、mockup、先看样子或先确认设计方向时，最终回复应给出 `imagegen` 生成的图片结果；只有实际发生 `imagegen` 调用后，才能汇报生图结果、失败或限流。生图结果先当候选效果图，并主动确认是否符合预期、是否纳入后续效果图/实现截图对比、以及是否按此继续实现。进入实现阶段后，已有确认参考图才给出 `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 路径，并说明是否仍有差异或漂移。
+- 用户要求生成图片、封面图、配图、海报、插画、图标、贴纸、头像、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 方向横向候选效果图大图，并明确等待用户确认是否纳入后续对比和继续实现；只有确认后再进入实现。
 - 在系统形态、产品流程或外部依赖仍有实质不确定性时，需求定稿前先向用户确认。
 - 当用户还没看过最新的 synthesize 产物或图示产物时，handoff 前先确认。
-- 当用户要求可视化说明时，路由到 `$openprd-diagram-review`。
+- 当用户要求可视化说明，或当前解释明显包含复杂关系、路径、对比、边界或风险传播时，路由到 `$openprd-diagram-review`；优先判断是否适合轻量解释型 SVG，而不是默认进入正式评审图。
 
 ## 共用路由规则
 
@@ -171,7 +181,7 @@ description: OpenPrd 工作区与产物的共用守则。凡是需要查看、
 - 需要推进主工作流生命周期：使用 `$openprd-harness`
 - 需要前端审美框架、设计资产、主题/骨架/组件/任务 recipe、事实/素材/image-preflight/direction-plan：使用 `$openprd-frontend-design`
 - 需要最佳实践、benchmark、对标、参考产品、prompt engineering、Agent harness、context engineering、图标资源、CLI 或 skill 体系设计：先使用 `$openprd-benchmark-router` 选择证据源，再按 DeepWiki、Context7 或官方资料规则调研
-- 需要架构图、产品流程图、用户旅程或可视确认循环：使用 `$openprd-diagram-review`
+- 需要架构图、产品流程图、用户旅程、解释型 SVG 或可视确认循环：使用 `$openprd-diagram-review`
 - 需要更细的语言规则或命令分类说明时，阅读：
   - `references/operating-rules.md`
   - `references/language-and-review.md`

package/skills/openprd-standards/SKILL.md

@@ -15,7 +15,7 @@ OpenPrd standards 管三件事：
 - `.openprd/standards/file-manual-template.md` 定义的文件说明书规则
 - `.openprd/standards/folder-readme-template.md` 定义的文件夹 README 规则
 
-研发期还包含一个轻量标准层：`openprd dev-check <path> <file...>` 或 `node scripts/openprd-dev-check.mjs <path> <file...>`，用于 Agent 在代码修改完成后、最终回复前回顾本轮 touched code files 的行数状态和下一步动作建议。
+研发期还包含一个轻量标准层：`openprd dev-check <path> <file...>` 或 `node scripts/openprd-dev-check.mjs <path> <file...>`，用于 Agent 在代码修改完成后、最终回复前回顾本轮 touched code files 的行数状态和下一步动作建议。自动优化默认开启（`developmentStandards.autoRefactor.enabled`，`--auto-refactor on|off` 切换）：命中 attention/warning 时 Agent 在本轮直接完成高内聚低耦合拆分（不丢功能、行为不变、拆完重跑测试与 dev-check），最终回复以“OpenPRD 自动优化报告”呈现优化完成的结果（列：影响对象、问题级别、源文件规模、优化原因、本次处理结果、后续建议）并附开关确认一句话；关闭后回到“后续建议”推荐模式（列名回到关注程度、规模信号、预警原因）。dev-check 同时检测本轮是否触达界面文件：最近 24 小时没有拼图证据板时输出视觉证据提醒，附建议命令与对话流嵌入提示。
 
 自我成长标准层位于 `.openprd/growth/`：当 dev-check 高置信识别出新的代码扩展名时，可自动补齐识别规则并记录，减少后续重复提醒；执行中发现豁免路径、项目规矩、OpenPrd 默认行为或用户偏好需要增量时，先记录候选，收工时再运行 `openprd grow <path> --review` 集中确认。
 
@@ -48,7 +48,7 @@ OpenPrd standards 要求以下文档存在：
 ## 执行规则
 
 - 声称某个 change 就绪前，先运行 `openprd standards <path> --verify`
-- 代码修改完成后、最终回复前，针对本轮实际 touched code files 运行 `openprd dev-check <path> <file...>`；700 行以内正常，701-1500 行需留意，超过 1500 行说明后续改动成本较高。若出现需要关注的文件，最终回复必须以 **后续建议** 为标题，用 Markdown 表格列出影响位置、关注程度、规模信号、为什么需要关注、本次处理和后续建议，并按 🔴 → 🟠 → 🟡 排序
+- 代码修改完成后、最终回复前，针对本轮实际 touched code files 运行 `openprd dev-check <path> <file...>`；700 行以内正常，701-1500 行需留意，超过 1500 行说明后续改动成本较高。自动优化开启（默认）时，命中需要关注的文件先在本轮直接完成拆分，再以 **OpenPRD 自动优化报告** 为标题复用 dev-check 表格（列：影响对象、问题级别、源文件规模、优化原因、本次处理结果、后续建议）并附开关确认；用户要求关闭后运行 `openprd dev-check <path> --auto-refactor off`，之后以 **后续建议** 为标题输出推荐表格（列名回到关注程度、规模信号、预警原因）。两种模式都按 🔴 → 🟠 → 🟡 排序
 - dev-check 或执行过程产生自我成长项时，区分处理：高置信工具识别补全可以自动固化；用户偏好、项目协作规矩和 OpenPrd 默认行为只作为待确认候选，收工时集中 review
 - 新增配置类能力时同步评审 grow-aware 入口：候选类型、scope、review/apply 行为、拒绝后不重复提示，以及 user-local 与项目共享配置的边界
 - OpenPrd 自动生成的 change tasks 应包含 standards 维护任务
@@ -61,6 +61,8 @@ OpenPrd standards 要求以下文档存在：
 - 功能变更影响代码文件职责时，更新对应文件说明书
 - 功能变更影响文件夹职责或文件布局时，更新对应文件夹 README
 - 如果最终不需要改文档，也要说明已经做过影响检查，以及为什么现有文档依然准确
+- 更新 `docs/basic/` 时禁止 append-only 堆叠：同一事实只保留一处最新版本，过时段落直接删除或改写，不要写“更新：/补充：”式追加；单行不要超过 300 字符，长内容拆成分点或小节
+- `openprd standards <path> --verify` 会做文档质量体检：出现巨行（>300 字符）、平均行长退化（>200 字符）或 `prd.md` 落后超过 20 个 requirement 版本的警告时，先运行 `openprd docs-compact <path>` 查看按行号给出的压缩建议，压缩回填后再收口
 
 ## 文档影响检查