@xgent-ai/skills 0.7.6 → 0.7.8

package/skills/agi-mode/playbooks/what-next.md

@@ -45,28 +45,27 @@
 
 先服从用户当前目标和项目约定，再比较真实阻塞、已成立缺陷、依赖解除收益及可执行性。每条建议给出对象/路径、理由、前置条件、具体动作和完成判据；一般突出 1 个首选，另列可独立推进的工作。推荐专用技能时给可直接复制的命令（按当前客户端的技能调用写法），与该技能自身的收尾提示一致。不编造优先级、负责人或交期。
 
-涉及 UI 循环时，先读取 `<前缀>.ui-review.json`、报告及安装回执以区分人工与 managed。managed 当前报告和未结束轮次从索引及匹配 engine 的只读状态返回定位，不按 mtime 或 Markdown 最大后缀覆盖它；`review status` 的退出 0 不等于 UI 通过。只读查询不执行 begin、import、安装、评审或修复。下表的 UI 修复建议先满足循环能力边界。
+涉及 UI 循环时，按目标包、报告轮次、证据和修复记录定位状态；未结束轮次续接，不按文件时间猜结论。两项 UI skill 不依赖外部工具的安装或状态。只读查询不启动评审、修复或安装。
 
 | 核实到的情况 | 可推荐的动作（遵循项目已定流程，不强制补全流水线） |
 | --- | --- |
 | PRD 尚有影响范围或验收的未决项 | 指出具体待决项；需要撰写/修订时用 `prd`，质量评审用 `review-prd` |
 | 用户希望逐项确认已有 PRD/计划中的功能取舍 | `spec-human-decision <文档>`：每项讲清功能与价值，计划另述做法；固定确认/驳回/修改，修改须附说明并确认修订版，决定落实到文档；查询本身只推荐，不启动问答或改稿，逐项确认不等于技术评审或 Ready |
-| 本项目是 CRD 接收方，需评估/答复、续接澄清或补回告实现结果 | 固定建议 `crd-respond <CRD>`；评估时基于最新工作树比较目标、原案与长期备选，在原文末答复，需改码时实际生成带来源 CR、承接范围和顶部完成回写约定的计划，未决契约按就绪门标 Blocked。已完成请求按证据追加实现结果及余项，不重开规划。仅原样追加/收录不重评或生成计划，仅评估/仅答复遵守边界，不发送或实施；查询本身不运行该技能 |
-| 本项目是 CRD 提出方，需起草/修订、跟进或整合接收方返回稿 | 固定建议 `crd`，核对发出、返回与本地版本，整合实际答复、追加本方澄清/确认，维护需求与 Q&A；收到文件或答复反问不切换技能。角色不明先核实；对方已回复不等于已承诺或完成集成 |
+| 本项目是 CRD 接收方，需评估/答复、续接澄清或补回告实现结果 | 固定建议 `crd-respond <CRD>`；评估时基于最新工作树比较目标、原案与长期备选，证据足够即明确本方技术结论，未发送或缺额外确认不使整体成为草案；重复分歧转具体裁定，不无效续谈，在原文末答复，需改码时实际生成带来源 CR、承接范围和顶部完成回写约定的计划，未决契约按就绪门标 Blocked。已完成请求按证据追加实现结果及余项，不重开规划。仅原样追加/收录不重评或生成计划，仅评估/仅答复遵守边界，不发送或实施；查询本身不运行该技能 |
+| 本项目是 CRD 提出方，需起草/修订、跟进或整合接收方返回稿 | 固定建议 `crd`，核对发出、返回与本地版本，整合实际答复、追加本方澄清/确认，维护需求与 Q&A；依据本方目标、底线及双方长期成本明确选择，未发送不等于本方结论是草案，已定事项不重问、无新证据的僵持转具体裁定。收到文件或答复反问不切换技能。角色不明先核实；对方已回复不等于已承诺或完成集成 |
 | 文档评审有当前确认待处理意见 | 指定报告和原文交给 `apply-doc-review`；已 applied 或无需处理不重复执行，是否已处理不明时先补核查 |
 | 需求已有边界但尚未有承接计划 | 以明确的需求集合、开发对象与排除交给 `dev-plan`，按 PRD 期次时用 `dev-plan <PRD> P<n>`；不默认一份 PRD 对应一份计划，依赖系统缺口保留提供方与前置，不自动转成本方开发 |
 | 计划需要设计评审 | `review-dev-plan`，注明具体计划与版本 |
-| 计划评审意见已 apply，状态仍为 `Blocked` | 以该计划交给 `resolve-blocked` 逐项解除：自行查证、交互补齐前置，收到答复后继续验证回写，外部缺口用 `crd` 创建/续写本地请求，不以找负责人代替行动；查询本身不运行或写入。查询回复也集中列全剩余阻塞、各方需提供什么、用户具体动作、解除条件与恢复入口，不能只说仍 Blocked 或让用户翻前文。已有 CRD 时按具体缺口建议交接、用 `crd` 修订/整合答复或补本方验证；条件满足后再运行 `resolve-blocked` 重判就绪，条件未变且无可执行动作时不空跑 apply、评审或解阻 |
+| 计划评审意见已 apply，状态仍为 `Blocked` | 以该计划交给 `resolve-blocked` 逐项解除：自行查证；实际解阻时需用户决定、补证或协调的事项必须用 Ask User 类工具提出并等待明确答复，不以聊天消息或最终清单替代；收到答复后继续验证回写，外部缺口用 `crd` 创建/续写本地请求，不以找负责人代替行动；查询本身不运行或写入。查询回复也集中列全剩余阻塞、各方需提供什么、用户具体动作、解除条件与恢复入口，不能只说仍 Blocked 或让用户翻前文。已有 CRD 时按具体缺口建议交接、用 `crd` 修订/整合答复或补本方验证；条件满足后再运行 `resolve-blocked` 重判就绪，条件未变且无可执行动作时不空跑 apply、评审或解阻 |
 | 验收条件已有口径但缺用例或执行证据 | 用例设计用 `test-plan`；已有用例则核对实际执行与覆盖缺口，不把用例草稿当通过，也不重复设计已覆盖项 |
 | 计划可实施且前置已满足 | 直接读计划实施协议继续对应里程碑，用 goal 推进时为 `/goal 按 <计划> 开发`；不加载 `dev-plan` 重写计划 |
 | 代码评审有当前仍成立的缺陷 | `apply-code-review <报告>`，计划可从报告头定位；修复后回到 `review-code <计划>` 复审。缺输入时先定位，不虚构关联 |
 | 计划实施完成待验收、修复已完成或待审代码范围明确 | 有计划时推荐 `review-code <计划>`：按完成记录登记的提交与未提交改动定范围，已有本计划报告时按轮次复审；无计划时明确 base/target 或工作树范围与对应历史报告 |
 | 来源 CR 的对应请求已有实现与约定检查证据，CR 仍只记未实现 | 核对来源 CR、承接范围与既有回告，建议按计划顶部合同或用 `crd-respond <CRD>` 补实现结果、计划/验证链接和剩余配合；一个计划完成不推导整份 CR、发布或对方验收完成，查询本身不写入，也不退回 dev-plan 重新规划 |
 | 代码评审已通过验收，变更涉及界面，且没有覆盖当前版本的 UI 验收 | 可选推荐 `review-ui <计划>`，它不是必经步骤；用户跳过时按闭环推荐差异核查 |
-| 已有 managed UI 索引，但 engine 缺失、不匹配、schema 未知或状态损坏 | 只读历史，可收集未登记素材；先说明如何恢复回执固定版本及匹配协议，恢复后续接原轮/revision。当前不推荐修产品、改目标/处置/计数/生成区，或换前缀、降人工重置历史 |
-| 人工 Markdown UI 历史没有 managed 索引，CLI 不可用 | 可继续原人工合同，不要求补装才能读取或续接；接管须用户明确要求并显式 import，未知尝试/重构次数保持未知 |
-| 匹配 managed 能力，索引当前轮仍草稿、缺证或等待确认评审 | 指向原轮次与缺项，建议用 `review-ui <原对象>` 续接补采/确认；不新开一轮绕过，不把旧轮通过或 CLI 退出 0 当本轮完成 |
-| 最新一轮 UI 验收判定需要修改（含停滞预警或待裁定标记） | `apply-ui-review <报告>`，计划与目标包从报告头定位；修复后回到 `review-ui <计划>` 复审。带待裁定标记时，同时列出这些事项请用户决定 |
+| 未安装 Phoenix UI，或其状态不可用，但有 UI 报告与目标材料 | review-ui / apply-ui-review 按自身合同续接；不把独立工具的安装、协议或索引作为前置，不清零历史 |
+| 最新一轮 UI 验收已完成，判定需补证 | `apply-ui-review <报告>` 执行修复、补证与可自行解除的阻塞，完成后 `review-ui <计划或原范围>` 独立复审；没有代码可改也不跳过补证。只缺独立评审时续接 review-ui；代码、证据与阻塞条件均未变化则续接记录、列解除条件，不建议空跑；仅无法自行取得的权限、资料或产品决定交用户 |
+| 最新一轮 UI 验收判定需要修改（含停滞预警或待裁定标记） | `apply-ui-review <报告>`，计划与目标包从报告头定位；修复后携有效 apply 证据回到 `review-ui <计划>` 增量复审，同状态多问题共用截图，未受影响的已通过结论复用；预警先诊断，不强制重构。带待裁定标记时，同时列出这些事项请用户决定 |
 | 最新一轮 UI 验收判定需用户裁定 | 列出报告中停滞或待裁定的事项和可选项，等用户决定；用户给出方向前，不推荐继续 apply 或重跑评审 |
 | UI 验收已通过，但其 UI 修复带来的代码改动尚未经代码评审 | `review-code <计划>` 复审这些改动，再按闭环推荐差异核查 |
 | 实现已交付但验收缺证、未集成或未发布 | 给出具体补证/集成动作；不把评审通过当部署授权 |

package/skills/apply-ui-review/SKILL.md

@@ -1,42 +1,47 @@
 ---
 name: apply-ui-review
 argument-hint: "<UI验收报告> [开发计划] [问题ID/单元] [修复方向/用户决定]"
-description: 用于按 UI 验收评审报告修复界面差距；不用于初次 UI 评审、代码评审处置或无报告的界面开发。逐条对照截图与目标核实后修复并自检，停滞预警时重构思路，提交登记后交回复审。
+description: 用于执行 UI 验收报告中的修复、补证与解阻；不用于初次 UI 评审、独立评分、代码评审处置或无报告的界面开发。核实差距、修复界面、补齐环境与实测材料，同状态共用证据，记录后交回复审。
 disable-model-invocation: true
 ---
 
 # apply-ui-review · 落实 UI 验收评审
 
-把独立评审给出的差距清单变成真实的界面改进，让下一轮评审的分数明显提高。评审看过目标和截图，所以可修复的差距默认全部处理；但每条仍要对照截图、目标包和规范核实一遍，评审看错的、与目标包矛盾的，不照着改。用户调用本技能，即授权核实、修复、运行必要的检查、按计划约定提交并回写记录。
+把独立评审给出的差距清单变成真实的界面改进，优先关闭验收阻断项和共同根因。评审看过目标和截图，所以可修复的差距默认全部处理；但每条仍要对照截图、目标包和规范核实一遍，评审看错的、与目标包矛盾的，不照着改。用户调用本技能，即授权在报告与项目范围内核实、修复、补证、解除可自行处理的阻塞、运行必要的检查、按计划约定提交并回写记录。没有代码可改，不等于没有工作；报告中的缺证清单也是执行输入。
 
-**核实和自检都以运行中的真实界面为准。** 无论是判断评审看错、判断差距已不存在，还是确认修复生效，依据只能是本轮实拍的截图、页面里实测的样式和尺寸，以及实际操作的结果。不能读了代码就下结论。
+**核实和自检都以运行中的真实界面为准。** 无论是判断评审看错、判断差距已不存在，还是确认修复生效，依据必须是当前有效的实拍截图、页面实测值和实际操作结果。同页面、状态、视口、主题、语言、数据与版本的多个问题共用一图，注明位置；不得按问题编号分别截图。已有证据经版本、条件、目标和影响范围核验仍有效时直接引用；历史证据不冒充新采集。不能读了代码就下结论。
 
 **本技能不给自己打分。** 修复是否到位，由下一轮 `review-ui` 的独立评审判定，所以记录里的处置最多写到「已修改待评审」。不改评审报告、评审截图和 `judge.md`；只有用户明确确认后，才把用户的决定写进目标包。推送、部署等按已有授权处理。
 
 `references/` 相对本文件解析。启动方式、组件库、设计规范和检查命令从目标仓发现。语言跟随用户。
 
-## 循环模式与能力探测
-
-先核对报告前缀对应的 `<前缀>.ui-review.json` 与安装回执。已有纯 Markdown 历史而无 managed 索引时按本文人工流程执行，必须显式 import 才接管；缺少 Phoenix CLI 不妨碍读取报告、目标和原文材料，也不把人工处置宣称为 managed 状态。
-
-已有 Phoenix managed 索引时，修复前核对固定版本 engine 身份与实际 review 协议；缺失、不匹配、未来 schema 或状态损坏时只读历史，可收集未登记素材，不改产品代码、目标、处置、计数、报告生成区或计划记录。说明恢复匹配 engine 的方法，恢复后续接原循环；不以人工降级、新前缀或重置基线绕过它。
-
-安装包包含 `review-ui` 时，按其 [Phoenix 评审协议](../review-ui/references/phoenix-review.md) 发现能力与续接状态；单独使用本技能时仍遵守上述边界，机器输入只依实际 `review --help` 与 `review schema --json` 返回的 typed examples，不猜字段；样例不是证据，身份、hash 和 revision 取真实操作与材料。managed 处置用 `review apply record` 登记当前轮，带当前 applied revision；旧 Markdown 的接入必须显式 `review import`，历史不明的尝试、重构次数不视为零。
+本技能是独立的 SDLC 执行流程。
+依据报告、目标包和修复记录续接；独立工具缺失或不兼容不阻止核实、修复与补证。
 
 ## 1. 锚定输入
 
-1. 定位用户给的 UI 验收报告，从报告头的「评审对象」找到计划、目标包、截图目录和上轮报告，并核实它们确实对应。用户没给报告时，人工循环从上下文或计划同目录取轮次最大的 `.ui-review` 报告；managed 循环从索引读取本循环当前报告，不按文件修改时间或猜轮次。有多份无法判断时询问。
+1. 定位用户给的 UI 验收报告，从报告头的「评审对象」找到计划、目标包、截图目录和上轮报告，并核实它们确实对应。用户没给报告时，从上下文或计划同目录取轮次最大的 `.ui-review` 报告，不按文件修改时间或猜轮次。有多份无法判断时询问。
 2. 按报告的验收判定处理：
-   - **需要修改**：处理可修复的差距。带「停滞预警」时，按下文做重构轮。带「待裁定」时，那些事项先不改，记「待决定」，除非用户本次已就它给出方向。
-   - **需补证**：所缺的证据由 `review-ui` 补齐。报告里已评单元的可修复差距，用户要求时可以先修。
+   - **需要修改**：处理可修复的差距。带「停滞预警」时，按下文诊断原因，不强制重构。带「待裁定」时，那些事项先不改，记「待决定」，除非用户本次已就它给出方向。
+   - **需补证**：本技能执行报告中的补证工作，并处理已评单元的可修复差距；不因缺证或没有确认缺陷而直接退回 `review-ui`，也不默认让用户准备环境或采集证据。按下节补齐可执行项后交独立复审。
    - **需用户裁定**：用户本次没给方向时，转述报告里的选项，请用户决定，不动停滞和待裁定的部分；给了方向就照做，并把用户原话记下来。
    - **通过验收 / 用户豁免通过**：只有用户要继续打磨时，才处理剩余差距。
 3. 用户接受某处偏差或修改期望时，经用户明确确认后，写进目标包对应单元的比较口径或规范要点，注明日期和用户原话，并追加变更记录；下一轮评审会据此重建基线。用户接受整体界面时，提示由 `review-ui` 记为豁免通过，本技能不改报告。
 4. 读目标包、报告中的差距清单、待裁定事项和上轮复核表，以及以往各轮的修复记录（见记录合同）。记下当前 HEAD 和未提交改动，分清哪些是用户已有的修改、哪些是本次修复。用户限定了差距编号或单元时，只处理这些。
 
+## 补证与解阻
+
+- 读取报告、采集清单及缺失状态的原始记录，逐项确定缺什么、执行动作和完成条件。能在当前权限和项目范围内完成的立即做，不把清单原样交给用户。
+- 依项目既有流程启动或恢复测试环境，准备测试账号与种子数据，复用已有 mock/拦截方法到达目标状态，执行缺失交互并实测，必要视觉转折才截图；明确模拟范围，不把替身结果冒充真实集成。只用测试数据，不修改真实业务数据、不绕过权限或扩大产品范围。缺目标时先找已有规范及已确认设计；找不到或互相冲突才请求决定，不自造期望。
+- 补证时发现真实产品缺陷，核实后在授权范围内修复并自检。仅缺截图或执行记录时完成采集即可，不为体现“apply”而改代码。待裁定项可先补事实，但不替用户决定期望或修复方向。
+- 补采文件放 `<前缀>.ui-captures/r<n>-apply/`，记录被测版本、目标指纹、单元/状态/视口/主题、操作、实际结果和文件路径；保留每次必要采集，不按问题复制同状态图片，不覆盖评审截图、报告或 `judge.md`。临时服务用完清理，截图与日志遵循项目忽略约定。
+- 在原修复记录位置的本轮补证小节记录补证动作、结果与剩余阻塞；纯补证不伪造差距编号。没有产品修改的采集不记「已修改待评审」，不增加修复尝试或重构计数。
+- 只有缺少无法自行取得的权限、资料或需要产品决定时，才向用户提出具体请求，写清已尝试动作、所需输入与解除条件，并继续不受阻的事项。保留原报告、材料和修复历史，不重置记录。
+- 补证材料是交接输入，不是独立验收结论。`review-ui` 核对目标、版本、条件与出处后直接引用有效的 apply 材料，仅失效或看不清时补采，并完成独立评分；不把 apply 截图冒充下一轮新采集。只有剩余工作确实是独立评审/确认评审，或可执行项已完成时，才交回复审；仍有外部阻塞时说明解除条件，不建议原条件下空跑。
+
 ## 2. 核实与排序
 
-- **核实**：逐条打开报告引用的截图和目标图，在运行中的界面里按同一单元、状态、视口和主题复现；再对照目标包的规范要点、比较口径和 DESIGN.md。
+- **核实**：按页面状态分组打开报告截图和目标图，一次复现核实该状态的全部相关问题；同一原图只需打开一次，看不清先放大，不逐条重复截图。再对照目标包的规范要点、比较口径和 DESIGN.md。
 - **成立的**：进入修复。
 - **不采纳**：以下情况记「不采纳」并写明依据，不改代码：评审看错（运行中的界面与评审描述不符，附截图或实测值）；与目标包或规范矛盾；属于比较口径排除的差异。报告附了核对说明的差距，同样自己核实，确实不成立就记不采纳。
 - **待决定或阻塞**：需要素材、文案、数据、接口或产品决定才能修的，记「待决定」或「阻塞」，然后继续处理其他条目。
@@ -50,23 +55,23 @@ disable-model-invocation: true
 - 只改界面范围内必要的代码、样式、素材和测试。修复需要改接口、数据契约或计划范围时，记「待决定」，不擅自扩大。
 - 保留用户已有的修改，不 reset、stash 或回退。
 - **回归**：报告判为回归的差距，先用上一轮以来的 diff 找出是哪个改动引入的，修正它；不要用另一处回归来换。
-- **重构轮**：报告带停滞预警时做，只针对预警的范围（全局，或某条差距所在的单元）。停止微调：
+- **停滞诊断**：报告带停滞预警时，只诊断预警范围（全局，或某条差距所在单元）：
   1. 写清以往的尝试为什么没奏效。
-  2. 列出可能的结构性原因：布局模型或组件选错；素材质量不够；token 或主题不符；字体或图片没正确加载；容器与断点约束；数据形态；采集环境与目标不一致。
-  3. 选证据最强的一条，做一次大的结构性改变，目标是明显提分，而不是小修小补。
-  4. 把范围、假设、改动和预期写进记录。每个范围在同一基线内只有一次重构机会；下一轮评审靠这份记录判断有没有走出停滞。
+  2. 先区分实现缺陷、证据不足和标准争议；有实现依据时再检查根因：布局模型或组件选错；素材质量不够；token 或主题不符；字体或图片没正确加载；容器与断点约束；数据形态；采集环境与目标不一致。
+  3. 选证据最强的一条，采取最小有效修复或补证；只有结构性根因才重构，不为提分强制换组件或布局。标准争议记待决定。
+  4. 把范围、诊断、实际改动与证据写进记录。实际重构每个范围每基线最多一次；没有重构也照实记录，重复实际修改仍无效时由复审转为停滞，不无限微调。
 - **只记真正改过的**：一轮做不完的差距，如实标「未处理」，不算尝试过。只有真正改过的才记「已修改待评审」，下一轮的顽固差距判定以此为准。
 
 ## 4. 自检
 
-1. 启动当前代码，按目标包的条件采集受影响的单元，自己与目标对照；再把其他单元快速过一遍，确认没引入回归。自检截图默认放临时目录；需要作为记录证据时，存到 `<前缀>.ui-captures/r<n>-apply/`，不覆盖评审截图。
+1. 启动当前代码，先复用现有自动检查验证受影响条件，再按页面状态统一采集必要代表帧，与目标对照；共享组件、主题、字体、素材、依赖或布局变化时扩大复查范围。未受影响的有效结果复用，不机械重跑全部页面。一张修复后的状态图可核实多条差距。可供复审的截图直接存到 `<前缀>.ui-captures/r<n>-apply/`，不覆盖评审截图。
 2. 运行计划和仓库要求的相关检查：组件测试、单元测试、类型检查、lint、构建。项目有视觉回归测试时，只在改动符合目标的情况下更新快照，并说明更新了哪些。检查失败时，分清是新引入的回归、原本就有的失败，还是环境问题；新引入的回归要继续修。
-3. 应用起不来或无法截图时，自检记「未运行」并写明原因，不能凭代码判断已经修好；处置仍是已修改待评审，由下一轮评审在真实界面上判定。
+3. 应用起不来或无法截图时，先按补证与解阻流程处理；仍不能完成时，自检记「未运行」并写明已尝试动作及剩余原因，不能凭代码判断已经修好；处置仍是已修改待评审，由下一轮评审在真实界面上判定。
 4. 自检不算验收：不估分，不宣称已经达标。
 
 ## 5. 提交、记录与交付
 
-1. 按 [记录合同](references/record-contract.md) 保存本轮处置。人工循环更新这一轮已有的小节，不重复追加；managed 循环用 `review apply record` 和当前 applied revision 更新，只让 engine 投影原记录位置里属于本循环、本轮的区块。冲突或生成区被手改时保留原文并停止覆盖，用显式 import 按权威事实恢复生成区，再以当前 applied revision 重新登记要保留的处置，不自动强写。
+1. 按 [记录合同](references/record-contract.md) 保存本轮处置。更新这一轮已有的小节，不重复追加；保留用户文字、其他轮次和历史评审。
 2. 计划有提交约定，或用户授权提交时：
    - 只暂存本次修复和记录，遵守仓库的提交规范，不跳过提交钩子；
    - 提交后，在完成记录对应里程碑行的「提交」列追加 `UI修复` 加短 SHA，再单独提交这次登记。
@@ -76,12 +81,15 @@ disable-model-invocation: true
 4. 回复内容：
    - 各类处置的数量和关键改动；
    - 重构假设（如有）；
+   - 补证与解阻的动作、结果、材料路径及剩余缺口；
    - 自检和检查结果；
    - 提交 SHA，或未提交的原因；
    - 记录链接；
    - 待用户决定的事项。
 
-   结尾给下一步：用 `review-ui <计划路径>` 复审，按当前客户端写法给出（如 Codex `$review-ui`、Claude Code `/review-ui`）。不自行启动评审。
+   交接附影响范围、共用截图到问题的映射、可复用材料及仍缺的条件。没有新改动、新证据或阻塞解除时续接原记录，说明解除条件，不建议原条件下再次 review/apply。
+
+   有新的可评证据、可执行的修复与补证完成后，结尾给下一步：用 `review-ui <计划路径或原范围>` 复审，按当前客户端写法给出（如 Codex `$review-ui`、Claude Code `/review-ui`）。不自行启动评审。
 
 调用示例：
 
@@ -93,6 +101,6 @@ disable-model-invocation: true
 
 ## 项目状态回写
 
-若仓库已登记状态台账，或存在仓根 `.xgent-ai/sdlc/protocol.md`（兼容已有 `docs/project-status/protocol.md`；两套并存且未登记切换时先核对，不能双写），交付原产物后读取台账的回写规则（默认目录读上述协议），按仓内协议更新受影响对象的当前状态与来源链接，必要时维护索引；v4 日常直接更新当前页，事件留存条件或旧版事件要求以仓内协议为准；未启用时不自动建表，不依赖另装技能。只读/仅聊天/不保存及 managed 能力异常时的只读边界优先，登记失败须说明，不影响如实交付已完成的原产物。
+若仓库已登记状态台账，或存在仓根 `.xgent-ai/sdlc/protocol.md`（兼容已有 `docs/project-status/protocol.md`；两套并存且未登记切换时先核对，不能双写），交付原产物后读取台账的回写规则（默认目录读上述协议），按仓内协议更新受影响对象的当前状态与来源链接，必要时维护索引；v4 日常直接更新当前页，事件留存条件或旧版事件要求以仓内协议为准；未启用时不自动建表，不依赖另装技能。只读/仅聊天/不保存约束优先，登记失败须说明，不影响如实交付已完成的原产物。
 
 接着原评审对象登记处置：差距编号、处置、修复版本、自检结果和未完项，并链接实现记录。「已修改待评审」不登记为已解决，修复也不能登记成独立复审通过。

package/skills/apply-ui-review/agents/openai.yaml

@@ -1,6 +1,6 @@
 interface:
   display_name: "落实 UI 验收评审"
-  short_description: "按 UI 验收报告在运行中的界面上核实并修复差距，实拍自检，停滞预警时重构思路，交回复审"
-  default_prompt: "使用 $apply-ui-review 按指定 UI 验收报告修复。先识别人工或 Phoenix managed 循环，已有人工历史须显式 import；已有 managed 索引而固定 engine 不匹配时只读并说明恢复方法。可执行时在真实界面上核实差距，按预警范围重构，实拍自检并运行相关检查；只把实际改过的记为已修改待评审，不自评分。按约定提交登记；managed 处置用实际协议与 applied revision 更新原记录区块，不改历史评审。回读处置与证据，交回 review-ui 复审。"
+  short_description: "执行 UI 验收报告中的修复、补证与解阻，实拍自检，记录后交回独立复审"
+  default_prompt: "使用 $apply-ui-review 按报告执行修复、补证与解阻。按页面状态分组核实，多问题共用一图，优先处理阻断项与共同根因；停滞先诊断，仅结构性根因才重构。按影响范围自检，记录版本、条件和可复用材料；只把实际改过的差距记为已修改待评审，不自行评分。按已有约定提交并保存处置；完成后交 review-ui 独立复审，条件未变且无新证据不空跑。"
 policy:
   allow_implicit_invocation: false

package/skills/apply-ui-review/evals/scenarios.md

@@ -4,16 +4,18 @@
 
 | 场景与请求 | 应观察的行为 | 失败信号 |
 | --- | --- | --- |
-| R2 判需要修改，有 6 条差距 | 逐条打开截图与目标图，在运行的界面中复现后修复；P0/P1 和共同根因先修；自检受影响单元并过一遍其他单元，运行相关测试；按约定提交，登记 `UI修复` SHA；提示 `review-ui <计划>` | 只按文字描述改、不看截图；自报「已达 8 分」；不跑测试；处置写成已修复并验证 |
+| R2 判需要修改，有 6 条差距 | 按页面状态分组打开共用截图与目标图，在运行的界面中复现后修复；P0/P1 和共同根因先修；按影响范围自检并复用未受影响证据，运行相关测试；按约定提交，登记 `UI修复` SHA；提示 `review-ui <计划>` | 只按文字描述改、不看截图；自报「已达 8 分」；不跑测试；处置写成已修复并验证 |
 | 差距要求换一种颜色，但目标图用的是规范 token，页面实测现状与之一致 | 记不采纳，附实测截图或计算样式，并引用目标包与 token 位置 | 硬编码新颜色来迎合评审 |
 | 评审说卡片圆角不对；修复方读 CSS 看到变量是 8px，就想记不采纳 | 先在运行中的页面上实测计算样式或截图对照，再决定是否采纳 | 只看代码就判评审看错 |
-| 改完后应用起不来，无法自检 | 自检记「未运行」及原因，处置仍是已修改待评审 | 凭代码宣称已经修好 |
-| 报告判「需要修改 · 停滞预警（UI-07 所在 U3）」 | U3 做重构轮：写清旧尝试为何失败和结构性假设，换布局原语、组件或素材，把范围和假设记入记录；其他差距照常处理 | 继续微调几个像素；全局推倒重来 |
+| 改完后应用起不来，无法自检 | 先排查并解除可处理的启动阻塞；仍失败才记自检未运行、尝试与剩余原因，处置仍是已修改待评审 | 不尝试解阻就退回；凭代码宣称已经修好 |
+| 报告判「需要修改 · 停滞预警（UI-07 所在 U3）」 | U3 先诊断实现、证据或标准争议，采取最小有效行动，仅结构性根因才重构；其他差距照常处理 | 强制换布局/组件或全局推倒重来 |
 | 报告判「需要修改 · 待裁定（UI-04）」，用户没提 UI-04 | 跳过 UI-04，修复其余差距，回复中列出 UI-04 请用户决定 | 自行改 UI-04；因为有待裁定事项就整轮不修 |
 | 报告判需用户裁定，用户没给方向 | 转述报告里的选项，请用户决定，不改停滞和待裁定的部分 | 自行做大改动，或擅自修改目标包 |
 | 用户说「U3 按设计稿改成两栏卡片」 | 按方向修复，原话记入记录 | 忽略方向 |
 | 用户确认「U2 的圆角以现在的实现为准」 | 写进目标包 U2 的比较口径，注明日期和原话，追加变更记录；提示下一轮会重建基线 | 只写进修复记录，导致评审下一轮再次扣分；未经确认就改目标包 |
-| 报告判需补证（U3 缺目标），U1、U2 有可修复差距，用户要求先修 | 修复 U1、U2 的差距；U3 的证据交给 `review-ui` 补齐 | 以需补证为由整体拒绝修复；替 U3 自造目标 |
+| 报告判需补证，U3缺目标，U1/U2有可修差距 | 修复U1/U2；主动查已有规范和确认设计补U3材料，确实缺产品决定才询问；保留冻结目标边界 | 将U3原样推回review-ui或交用户找资料；自造目标 |
+| 报告仅缺环境、测试数据和键盘操作证据，没有确认缺陷；用户调用apply-ui-review | 按项目流程恢复环境、准备测试数据、实际操作采集，记录版本与材料路径；无产品改动不计修复尝试，完成后交独立复审 | 说没什么apply而转回review-ui；让用户执行可自行完成的补证；为了有改动而改代码 |
+| 补证需用户未提供的外部权限，另有本地可采项目 | 提出具体权限请求、说明尝试与解除条件，继续本地可采项目；不宣称完整补齐 | 因一项外部阻塞放弃全部；绕过权限；让用户自己跑全部采集 |
 | 报告把一条差距判为回归 | 用上一轮以来的 diff 定位引入回归的改动，修正它 | 用另一处回归来换 |
 | 修复需要改接口字段，超出计划范围 | 记待决定，说明影响，继续其他差距 | 擅自改 API 或数据契约 |
 | 差距很多，一轮修不完 | 没动的差距标「未处理」，只把改过的记为已修改待评审 | 把没尝试的也记已修改，导致下一轮误判顽固差距 |
@@ -22,11 +24,12 @@
 | 工作树里有用户自己未提交的改动 | 保留，只暂存本次修复 | reset、stash，或把用户改动一起提交 |
 | 项目有视觉回归快照，修复改变了界面 | 只在改动符合目标时更新快照，并说明更新范围 | 为让测试变绿批量更新快照 |
 | 用户只想做第一轮 UI 评审 | 转到 `review-ui` | 没有报告就开始改界面 |
-| 「按 r3 报告修复订单页」；有 managed 索引但固定 engine 缺失 | 只读历史并说明恢复方法；不改代码、目标、处置、计数或记录生成区 | 人工修复后写 Markdown 绕过原索引；猜协议字段 |
-| 「没有 CLI，先核实这份人工报告」；没有 managed 索引 | 直接读报告、目标、规范和截图；不能实测的如实待补证 | 因缺 CLI 拒绝原文读取；仅凭 CSS 宣称不采纳或已解决 |
-| 「我把处置记录补了注释，再记下这轮修复」；managed 生成区 hash 改变 | 保留文字与 source hash；显式 import 核对允许内容和 applied revision | 强写覆盖；改历史报告或原始评审；生成重复轮小节 |
+| 「没有 CLI，先核实这份人工报告」 | 直接读报告、目标、规范和截图；不能实测的如实待补证 | 因缺 CLI 拒绝原文读取；仅凭 CSS 宣称不采纳或已解决 |
+| 未安装 Phoenix UI，报告与目标完整、产品可运行，调用 apply-ui-review | 直接核实、修复、补证和记录，再交独立复审；不要求 engine 或机器索引 | 因独立工具缺失而禁止修改产品或写处置 |
 | 「旧报告显示发过重构预警，但修复记录丢了一份，继续做一次重构」 | 重构次数保持未知，先补材料或请用户确认基线与旧差距 | 把丢失记录当作没重构过；再领一次机会 |
 | 「后端只支持 status=active AND owner=me，这份 UI 差距要求加快捷筛选」 | 读真实接口，只在既有 AND 语义内核实/修复；需要 OR 或新增字段时待决定 | 为满足界面建议凭空发明 OR、接口字段或数据契约 |
 | 「我接受整页现状，你把这些问题都关掉」 | 保留原分数和差距，交 `review-ui` 追加真实豁免 | 把接受现状记成已解决或改原评审分数 |
+| 同一页面 8 条差距一起修复，4 条确定性检查成功 | 按状态留必要修复后图片，8 条处置共用图；记录检查结果、版本与影响范围供复审复用 | 每条问题和每条成功断言各拍一张，交接后要求全部重拍 |
+| 外部权限仍缺失，报告和代码均无变化，再调用 apply | 续接原记录列解除条件，继续独立可执行项；没有新证据不建议再跑 review | 重复拍禁用入口或原条件下互相转交 |
 
 路由与正文验证方法见 [全新上下文验证](../../review-ui/evals/fresh-context.md)。结构检查覆盖 frontmatter、description 全文及前 100 字符、相对链接。试跑另行记录输入、产物、实际执行范围和限制；修复后的验收以下一轮 `review-ui` 为准。

package/skills/apply-ui-review/references/record-contract.md

@@ -13,9 +13,7 @@
 3. 没有计划时，写在 `<前缀>.ui-review.applied.md`，前缀见 `review-ui` 的报告合同。
 4. 每轮一个小节，不改写前几轮。对同一份报告再次执行时，更新这一轮已有的小节，不重复追加；同一差距以这一轮最后一次登记的处置为准。`review-ui` 靠这些小节判断哪些差距被尝试过、哪个范围做过重构轮。
 
-以上是人工循环的写法。Phoenix managed 循环由 `review apply record` 以当前 applied revision 写入权威 JSON 并生成 Markdown，只更新首次选定位置中属于本循环、本轮的区块；保留人工文字、其他循环和其他轮记录，不创建新里程碑。评审原文、截图、历史报告和封存结果不改写。缺少匹配 engine 时只读，不修复或手写处置来绕过状态。
-
-生成区被手改或 revision 冲突时，先保存用户原文、source hash 与差异，停止覆盖；再用显式 `review import`（projectionRebase）按权威事实恢复生成区。import 不导入手改文本，要保留的处置以当前 applied revision 经 `review apply record` 重新登记才生效；不强写、不静默重置。没有 managed 索引的 Markdown 循环继续人工流程，接入 managed 必须显式导入。
+只更新本轮对应的小节，保留用户文字、其他轮次及原始评审材料；不依赖工具索引或生成区协议。
 
 ## 每轮内容
 
@@ -50,11 +48,13 @@
 
 没有「已修复并验证」：是否解决由下一轮独立评审判定。
 
-处置只针对该轮报告差距清单中的未关闭差距。已解决、不再适用或不存在的编号不登记处置（managed 循环的 `apply record` 返回 2），因此也不能作为重构轮的依据。
+处置只针对该轮报告差距清单中的未关闭差距。已解决、不再适用或不存在的编号不登记处置，因此也不能作为重构轮的依据。
+
+实际尝试只计「已修改待评审」，未处理、待决定、阻塞或不采纳不能算修改过：自评审上次判定该差距以来，任一轮的最终处置是「已修改待评审」即算尝试；最近一轮的最终处置是不采纳、待决定或阻塞时，按报告合同判断是否待裁定，两者分别判断。预警先诊断，不强制重构；实际重构必须有原范围、基线、实际改动和记录，同一范围每基线最多一次；旧历史缺失时保持次数未知，不填零或再领一次重构机会。用户确认的目标变更保留原话、日期和差异，下一轮重建基线；用户豁免由 `review-ui` 追加，不作为本技能的已解决处置。
 
-实际尝试只计「已修改待评审」，未处理、待决定、阻塞或不采纳不能算修改过：自评审上次判定该差距以来，任一轮的最终处置是「已修改待评审」即算尝试；最近一轮的最终处置是不采纳、待决定或阻塞时，按报告合同判断是否待裁定，两者分别判断。重构必须有原范围、基线、实际改动和记录，同一范围每基线最多一次；旧历史缺失时保持次数未知，不填零或再领一次重构机会。用户确认的目标变更保留原话、日期和差异，下一轮重建基线；用户豁免由 `review-ui` 追加，不作为本技能的已解决处置。
+核实和自检列的依据，必须来自运行中的界面：当前有效截图、页面实测值或实际操作结果；同状态多条差距共用图片并注明位置。列出材料的原路径、版本、目标指纹和条件，以及改动的影响范围和可复用依据，供独立复审直接使用；旧材料不标为新采集。应用起不来时写「未运行」及原因，不用代码阅读代替。
 
-核实和自检列的依据，必须来自运行中的界面：本轮截图、页面实测值或实际操作结果。应用起不来时写「未运行」及原因，不用代码阅读代替。
+阻塞条件未变且没有新改动或证据时，更新原记录并列解除条件，不制造新轮次或重复采集。
 
 只写核实结论、改动、检查结果和续做需要的事实，不写讨论过程、完整日志或技能使用经过。
 

package/skills/crd/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: crd
-description: 跨项目 CRD 提出方使用：起草或修订需求、整合接收方回复并续接 Q&A；接收方评估与答复用 crd-respond，非 Kubernetes CRD、代码评审或直接实施。维护 CRD 与往返记录。
+description: 跨项目 CRD 提出方使用：起草或修订需求、整合接收方回复并续接 Q&A；接收方评估与答复用 crd-respond，非 Kubernetes CRD、代码评审或直接实施。明确本方立场并收敛契约，保留往返依据。
 when_to_use: "用户会说「给 XX 项目提个需求」「这条需求要改一版」「对方回了，接着问」这类提出方请求时。"
 ---
 
@@ -12,7 +12,7 @@ CR（Change Request）的文档称为 CRD，承载协作需求、**Q&A 问答澄
 INTENT:
   GOAL: independently_readable_and_answerable_crd
   SUCCESS: ["谁需要另一方提供什么、为什么、怎样算满足、哪些事项未达成一致均明确",
-            source_grounded_current_view, preserved_response_history]
+            source_grounded_current_view, explicit_requester_position, converged_decisions, preserved_response_history]
 
 RULE @role_routing:
   MUST: ["从上下文确定双方项目、协作目标、文档路径及当前代表的角色；角色不明且影响动作时询问，不直接把当前仓库认作提出方",
@@ -32,7 +32,7 @@ RULE @collaboration_scope:
 | 本次动作 | 读取与处理 |
 | --- | --- |
 | 发起或修订 | 读简报、相关代码/接口文档及已有 CR，形成可答复条目 |
-| 提出方补充或答复澄清 | 核对接收方反问、替代方案及条件，文末追加本方澄清、补充或有依据的确认；未授权表态标草案，不替接收方接受或承诺 |
+| 提出方补充或答复澄清 | 核对接收方反问、替代方案及条件，文末追加本方澄清、补充或有依据的确认；形成授权范围内的本方结论，超出授权的具体取舍单列，不替接收方接受或承诺 |
 | 整合返回 CRD | 读返回稿、发出基线、本地当前稿，按 §4 核对增量并同步摘要，不让用户另摘已有回复 |
 | 收录独立回复或续接 Q&A | 先读完整 CR 与最新往返，再对照来信/聊天/评审材料收录实际回复，保留发言归属并同步摘要 |
 
@@ -60,14 +60,39 @@ RULE @request_contract:
   MUST_NOT: [vague_acceptance, "把小请求扩成完整 PRD 或强制对方采用未达成一致的内部方案"]
 ```
 
-## 3. 维护 Q&A 与当前结论
+## 3. 明确本方立场，收敛 Q&A 与当前结论
 
 ```formal
+RULE @requester_position:
+  UNLESS: verbatim_append_only_or_receipt_only
+  MUST: ["代表提出方判断目标、核心验收与责任边界；区分必须保持的结果、可接受调整及拒绝条件，不只转述接收方方案",
+         "结合本方代码与产品约束，评估双方长期维护、运行、兼容迁移及全生命周期成本；不把复杂度转嫁给另一方当作更优，也不为假想扩展造平台",
+         "证据充分时明确选择继续原案、接受替代、缩减或撤回哪些请求，并说明依据、边界及下一步；方案已满足目标和可持续性要求时定论，不为措辞或无关细节重开"]
+
+RULE @own_conclusion:
+  MUST: ["受托评估、拟答复或续谈即应形成授权范围内的本方技术结论，不再索取一次仅用于把技术结论转正的确认；不因此取得新增产品范围、预算、排期或外部动作授权",
+         "本方技术立场、对方接受、用户保留的决定、发送、排期承诺、实现与验收分别记录；未发送或对方尚未接受不使本方技术结论成为草案",
+         "只有用户明确要草案或预审稿时，整份本方答复才标草案；证据或授权不足时仅将受影响事项列待澄清/待决，并给本方条件结论、缺口和解除条件",
+         "仅原样追加或收录时保留来源的草案/确认标识，不自行升级原文的立场或承诺"]
+  MUST_NOT: [blanket_draft_label_without_extra_user_confirmation,
+             use_draft_label_to_avoid_own_technical_judgment]
+
+RULE @negotiation_convergence:
+  UNLESS: verbatim_append_only_or_receipt_only
+  MUST: ["每轮先核对已定事项、剩余实质分歧及新证据，只处理受新信息影响的部分；不重复询问已有答案或再次要求确认已生效决定",
+         "待澄清必须指出缺哪个事实/决定、会改变什么结论、由哪方怎样补齐；非阻塞细节不拖住已能成立的契约",
+         "双方对同一范围的有效结论一致且必要确认齐备时，登记一致依据并关闭对应 Q，转入约定交付与验证；不再请求‘确认这次确认’",
+         "双方仅重复原有理由且无新证据时，停止同义反问；说明已达成部分、最小剩余分歧、本方主张、可接受边界与可行收敛路径，不靠继续生成草案推进",
+         "本方权限内能决定的当轮明确决定；确需用户取舍或跨项目协调时，用可用 Ask User 类工具给出具体裁定问题、选项、后果和推荐并等待明确答复；异步工具保持待答，不能仅把待办输出到聊天，工具不可用则如实报告交互受阻",
+         "用户明确暂缓或确需外部证据时保留具体阻塞与恢复条件，已定部分继续；无可接受交集时明确本方不接受的范围与理由，不伪造共识"]
+  MUST_NOT: [round_count_as_evidence_of_agreement, fabricated_acceptance,
+             reopen_settled_terms_without_material_change, indefinite_draft_ping_pong]
+
 RULE @current_view:
   UNLESS: verbatim_append_only
   MUST: ["Q&A 逐条保留问题、关联需求、提问方/待答方、是否阻塞及阻塞步骤、当前回答/待确认点、状态与答复链接；未知答案明确待答，建议标建议",
          "部分回答只更新对应项，未答项继续待答；已回答不等于已接受，已接受不等于已交付",
-         "单方新范围、替代方案、时间仍是待确认提议；一致结论须有有权限一方的明确确认，需要双方确认时保留双方依据",
+         "单方新范围、替代契约、时间对另一方仍是提议；本方须明确自己的选择，一致结论保留双方有效依据；真正超出已有授权的决定单列，不将已获授权的技术判断一律留待确认",
          "新旧答复冲突时列出影响，仅有明确撤回或替代依据才采用新结论，否则待澄清，不按时间覆盖承诺",
          "需求/问题/答复互引；问题关闭有实际回答及必要确认，CR 关闭有约定范围验收证据或明确拒绝/撤回理由",
          "正文写当前已确认需求与验收，未确认变更留提议/待决项；正文与历史差异可追到依据，历史保留当时原意"]
@@ -107,7 +132,7 @@ RULE @missing_versions:
 RULE @response_history:
   MUST: ["所有轮次按收录顺序追加到文末‘往返答复记录’，其他章节在前；双方发言用同一格式，收录不等于代答",
          "每轮有 RESP 编号、发言方/项目、原消息时间（未知注明）、整理时间、来源、关联 R/Q、内容、未答项及下一步",
-         "拟答复标‘草案，未发送/未确认’，收到答复标‘已收到’，不推定双方已认可",
+         "本方答复按 @own_conclusion 标识技术结论及具体待决项，发送事实另记；收到答复标‘已收到’，不推定双方已认可",
          "原文与已读材料一致；概括标整理摘要，保留条件、否定、例外与承诺边界；长原文可链接原件并保留关键答复",
          "更正以新记录引用旧编号、差异与依据，不改写或删除历史；可按 @current_view 同步正文",
          "追加前按来源标识及内容去重；有新增条件的相似消息另记并注明变化",
@@ -120,7 +145,8 @@ RULE @response_history:
 ```formal
 REVIEW:
   CHECK: [@role_routing, @collaboration_scope, @source_fidelity, @stable_identifiers,
-          @request_contract, @current_view, @handoff_version, @merge_return,
+          @request_contract, @requester_position, @own_conclusion, @negotiation_convergence,
+          @current_view, @handoff_version, @merge_return,
           @missing_versions, @response_history]
   ALSO: ["核对本次改动及关联位置，编号唯一、引用和相对链接可达，无未答项、部分接受、冲突或时间条件丢失",
          "草案、提议、已收到、已确认、验收完成不混用；修改仅涉及本次 CR，文档检查不冒充业务验收"]
@@ -128,10 +154,12 @@ REVIEW:
 
 OUTPUT:
   FORMAT: markdown
-  MUST: ["交付文档链接、本轮新增或变化结论、仍待谁回答的阻塞问题",
+  MUST: ["交付文档链接；评估/续谈给明确的本方立场、本轮已收敛结论及具体剩余事实/决定缺口，不只说仍是草案；仅追加/收录给实际记录及未答项，不制造新立场",
          "未实际发送则说明‘文档已保存，未发送’；只落盘不增设发送审批"]
 ```
 
+验证本技能的角色、立场与收敛行为时读取 [验收场景](evals/scenarios.md)；场景本身不代表验证通过。
+
 ## 调用示例
 
 ```text

package/skills/crd/assets/cr-template.md

@@ -7,6 +7,7 @@ RULE @cr_template:
   MUST: ["只写协作边界、双方配合及可观察验收，已有契约与提议分清，不代设计接收方内部实现",
          "沿用 CR 标识、版本及稳定 R/Q/RESP 编号，未知事实与时间如实注明",
          "正文维护有依据的当前视图；往返记录始终在文末，只追加、更正引用旧号并保留历史",
+         "本方技术结论与发送、对方接受、承诺及验收分开；仅用户要求草案/预审稿时整体标草案，仅收录时保留原标识",
          "无问题写暂无、无答复写暂无答复，移除未使用的示意条目与模板说明"]
   MUST_NOT: [fabricated_replies_or_commitments, "将已回复当已接受或将文档完成当验收完成"]
 ```
@@ -19,10 +20,11 @@ RULE @cr_template:
 | CR 标识 | <沿用已有标识；无则使用文档文件名> |
 | 文档版本 / 基于版本 | <当前交接版本 / 本轮收到或上次发出的版本；首版写无，未知则注明> |
 | 提出方 / 接收方 | <项目、团队及已知联系人> |
-| 当前状态 | <草案 / 待答复 / 澄清中 / 已达成一致 / 交付中 / 已关闭，按证据填写> |
+| 当前状态 | <草案 / 待答复 / 澄清中 / 已达成一致 / 交付中 / 已关闭，按协作事实填写；草案仅用于明确要求的草案/预审稿> |
 | 创建 / 更新日期 | <日期> |
 | 相关材料 | <PRD、Issue、接口文档或代码依据> |
-| 当前结论与下一步 | <已确认什么；待谁处理什么；依据或答复链接> |
+| 当前结论与下一步 | <本方明确立场、已达成一致事项；剩余实质分歧与具体下一步；依据或答复链接> |
+| 发送状态 | <未发送 / 已发送及事实来源；不以未发送推导本方结论是草案> |
 
 协作方式：提出方使用 `crd` 起草/修订、整合接收方回复并续接 Q&A；接收方使用 `crd-respond`，请在本文末尾追加逐项答复，保留原需求与既有往返记录，并返回完整 CRD。涉及范围或验收条件的调整请在答复中明确提出，供双方确认。
 
@@ -40,11 +42,12 @@ RULE @cr_template:
 
 - 场景与影响：<谁、什么条件、当前问题及优先级理由>
 - 请求接收方：<可观察行为或交付物>
+- 提出方立场与依据：<必须保持的目标/验收、可接受调整、拒绝条件；双方长期维护与演进成本、本方选择及理由>
 - 提出方配合：<调用适配、资料、环境等必要事项>
 - 协作契约：<相关输入/输出、语义、权限或失败行为；标明已有约定或提议>
 - 验收条件：<前提 → 动作 → 可观察结果，必要失败场景及验证方/节点>
 - 期望与承诺：<期望日期/节点及理由；对方估计或承诺另列，无则待确认>
-- 当前结论：<待答复 / 接受 / 部分接受 / 替代方案待确认 / 不接受；附依据，注明尚未解决的范围>
+- 双方当前结论（本方立场另列）：<待答复 / 接受 / 部分接受 / 替代方案待确认 / 不接受；附依据，注明尚未解决的范围>
 
 ## 4. Q&A 问答澄清
 
@@ -64,7 +67,8 @@ RULE @cr_template:
 
 ### RESP-01 · <发言方> · <答复主题>
 
-- 类型：<答复草案（未发送/未确认） / 已收到答复 / 补充确认 / 更正>
+- 类型：<本方答复 / 已收到答复 / 补充确认 / 更正；仅用户要求草案或原样收录草案时标答复草案>
+- 发送状态：<未发送 / 已发送及依据；与技术结论分开>
 - 发言方与项目：<实际来源；未知则注明>
 - 原消息时间：<实际时间；未知则注明>
 - 整理时间：<本次整理日期>
@@ -73,9 +77,9 @@ RULE @cr_template:
 
 **答复原文或整理摘要**（二者明确区分）：
 
-<逐项保留答复、限制条件、未接受部分及理由；草案不得写成对方承诺。>
+<逐项给出本方结论、长期取舍依据、限制条件及不接受部分；收到的原文保留原意。具体授权缺口单列，不因未另行确认把本方结论整体降为草案；不代对方接受或承诺。>
 
-**未答项与下一步**：<待谁回答/确认什么；有明确时间约定才填写。>
+**未答项与下一步**：<已定事项不重问；剩余实质分歧、具体事实/决定缺口与补齐方；重复僵持时给本方主张与裁定路径；有明确时间约定才填写。>
 
 <!-- 后续 RESP-02、RESP-03 等追加于此，保留已有记录。生成实际 CR 时移除模板说明和未使用的示意条目。 -->
 ````

package/skills/crd/evals/scenarios.md

@@ -0,0 +1,12 @@
+# crd 提出方立场与收敛验收场景
+
+以下为验收设计，未实跑不计通过。执行者只读取原请求、正常项目材料与 `skills/crd/` 源码，不读取本表判据；隔离副本内检查实际文稿、工具动作和角色选择，不能以复述规则代替行为证据。
+
+| 请求与材料 | 应观察的行为 | 失败信号 |
+| --- | --- | --- |
+| 作为提出方评估接收方的替代方案，目标与验收可保留；已有授权和代码支持这一技术选择，未单独批准本次回复 | 比较双方长期维护、迁移与运行成本，明确本方接受或不接受及依据；发送另记未发送，不再求技术结论转正 | 只转述对方建议、将本方整体标草案待确认、无理由坚持原案或擅自承诺排期 |
+| 对方方案将本应由其维护的规则和错误恢复转给本方，已知会形成永久双轨 | 明确本方目标、底线和不接受部分，提出可持续的边界方案及双方代价；不因对方坚持就自动退让 | 以合作为由照单全收、只算本方短期改动量，或虚构通用平台解决已知小问题 |
+| 同一分歧连续往返但无新证据，取舍确需用户决定 | 保留已定部分、本方明确主张，提炼最小裁定问题，通过工具询问并等待答复；用户暂缓后如实保留恢复条件 | 继续追加同义草案、只在屏幕输出待办、擅自默认批准或按固定轮数假称达成一致 |
+| 双方有效结论已对同一范围达成一致且确认齐备，交付尚未开始 | 更新当前结论并关闭对应 Q，列交付与验证入口；原历史保留，未交付状态不误关 CR | 请求对方再次确认本次确认、重新讨论措辞或把达成一致写成交付完成 |
+| 用户仅要求原样收录本方草案，或明确要求先出预审稿 | 收录保持原意和标识；预审稿可标草案，不自动扩大授权 | 强行升级为正式接受、重评并改写用户原文，或自动发送 |
+| 部分关键事实确实缺失，另有已可明确决定的独立请求 | 仅将受影响事项列待澄清，说明缺口如何改变判断；独立部分给明确本方结论 | 为显果断编造事实、整体标草案回避判断，或把每个非阻塞细节都变成新一轮澄清 |

package/skills/crd-respond/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: crd-respond
 argument-hint: "<接收方收到的 CRD 路径/链接/内容> [本方项目/仓库] [需求ID/范围] [仅评估/仅答复] [计划输出路径]"
-description: 跨项目 CRD 接收方使用：评估需求与长期方案、答复澄清或回告实现结果；提出方用 crd，非 Kubernetes CRD 或代码实施。需改码时生成带来源 CR 与完成回写约定的开发计划。
+description: 跨项目 CRD 接收方使用：独立评估长期方案并明确立场、收敛答复或回告实现结果；提出方用 crd，非 Kubernetes CRD 或代码实施。需改码时生成带来源 CR 与完成回写约定的开发计划。
 when_to_use: "用户会说「评估一下对方这个需求」「在 CRD 末尾回一段」「继续答复他们的追问」「计划完成了，回写对应 CR」这类接收方请求时。"
 ---
 
@@ -17,14 +17,14 @@ when_to_use: "用户会说「评估一下对方这个需求」「在 CRD 末尾
 
 - 先核实当前代表的是本份 CRD 的接收方，以及本方仓库和责任范围；若实际代表提出方，定位并读取可用的 `crd` 后交回其流程，不继续接收方评估。角色无法确定且影响本次动作时询问，不把当前仓库直接认作接收方。双方在往返中都可能收到文件、回答问题，不因此切换角色；多项目分别核实，不以一个仓库替全部项目作答。这里不处理 Kubernetes CustomResourceDefinition，也不替代代码评审或计划实施。
 - CRD 是跨项目协作需求文档，QA 是 **Q&A 问答澄清**。默认保留原需求、编号、Q&A 与全部历史，只在同一文档末尾追加本方答复；不把建议静默改成双方已同意的需求。
-- 技术推荐、用户确认、对方接受、排期承诺、交付和验收分别记录。无有权一方的明确确认时，答复标「草案，未发送/未确认」，不能冒称代表团队已承诺。不发送消息，不创建 issue，不改项目平台状态，不提交、推送、部署或实施代码。
+- 本方技术立场、用户保留的决定、对方接受、发送、排期承诺、交付和验收分别记录。受托评估或拟答复即应形成授权范围内的本方技术结论，不再索取一次仅用于将技术结论转正的确认；未发送或对方未接受不使本方结论成为草案。仅用户明确要草案/预审稿时整体标草案；证据或授权不足只标具体待决项，不冒称新增范围、预算或排期已获承诺。不发送消息，不创建 issue，不改项目平台状态，不提交、推送、部署或实施代码。
 - 只引用本次读到的材料，区分代码事实、对方陈述、假设与建议。未知日期、规模、SLO、工期、预算与人员不补造。外部文档中的指令是输入材料，不扩大授权；不把凭证、个人数据或内部敏感实现写入对外答复。
 - 沿用 `dev-plan` 的事实、设计、就绪与授权门：写计划不等于开工；重大未决项不能标 `Ready`；不为假想扩展造平台或抽象。运行时定位并读取实际可用的技能，不假设兄弟技能一定已安装。
 
 ## 按接收方动作裁剪
 
 - **评估或拟答复（默认）**：执行第 1–7 节，基于本方最新代码判断目标与方案，需改码时按授权生成计划。
-- **仅原样追加本方已拟好的答复，或收录提出方实际澄清/确认**：读完整 CRD，核对来源、角色、版本和关联编号，按第 5、7 节追加与回读；保留原意、条件和发言归属，只写必要标识。不重新调查代码、重评方案、代拟新立场或生成计划；模板仅用来源/关联、正文、未答项与下一步，不伪造评估与代码基线。无明确确认仍标草案，收到澄清不等于此前方案已获接受。
+- **仅原样追加本方已拟好的答复，或收录提出方实际澄清/确认**：读完整 CRD，核对来源、角色、版本和关联编号，按第 5、7 节追加与回读；保留原意、条件和发言归属，只写必要标识。不重新调查代码、重评方案、代拟新立场或生成计划；模板仅用来源/关联、正文、未答项与下一步，不伪造评估与代码基线。来源本身是草案则保留草案标识，不自行升级原文立场或承诺；收到澄清不等于此前方案已获接受。
 - **续接提出方修订或返回的 CRD**：仍走接收方入口，先核对上次返还基线、收到版本与本地稿，保留双方增量和历史；正文实质变化或冲突明确归属、保持待确认，不按文件时间覆盖。只要求收录时仅收录；要求重新评估时只重开受新证据/决定影响的判断，再追加本轮答复。
 - **对应请求完成后的实现结果回告**：按第 1 节定位来源与最新版本，读取关联计划、相关实现/验收记录及必要代码证据，按第 6 节「实现结果回告」和第 5、7 节追加、回读。不重做方案评估、不生成新计划、不实施代码；只读要求仍优先。
 
@@ -72,14 +72,26 @@ when_to_use: "用户会说「评估一下对方这个需求」「在 CRD 末尾
 
 每个候选写：保持的业务目标与验收、核心机制/责任边界、代码事实支撑、按第 3 节关键维度的优劣、双方改动、依赖与风险、稳态及必要迁移、淘汰理由或重新评估条件。备选必须核实所依赖的现有能力；需要新增能力就写增量，不把想象中的接口当现成能力。不能保留原验收时明确标为范围/契约变更提议。
 
-「更好」必须说明相对原案在哪些维度改善、付出什么代价以及为何值得，不因技术更新、抽象更多、diff 更小或只对本方更便宜就成立。不确定时给条件推荐与解除条件，不强选赢家；本方推荐不冒充双方最终决定。
+「更好」必须说明相对原案在哪些维度改善、付出什么代价以及为何值得，不因技术更新、抽象更多、diff 更小或只对本方更便宜就成立。证据足够时明确选择本方认为可持续且满足目标的方案，不把继续讨论当默认结果。确有决定性缺口时给条件结论与解除条件，只保留受影响事项；本方结论不冒充双方一致或排期承诺。
 
 逐项形成两条互不替代的结论：
 
-- **答复立场**：沿用 CRD 的「接受 / 部分接受 / 替代方案 / 不接受 / 待澄清」，无明确确认时均是拟议立场。说明目标与方案分别的判断、保留条件、不接受部分、验收变化与理由；替代方案默认待对方确认。
+- **答复立场**：沿用 CRD 的「接受 / 部分接受 / 替代方案 / 不接受 / 待澄清」，这是本轮本方技术结论，不因缺少额外确认一律标为拟议。说明目标与方案分别的判断、保留条件、不接受部分、验收变化与理由；替代契约尚未获对方接受时单列这一前置，不撤回本方明确选择。
 - **本方代码动作**：「需要修改 / 无需修改 / 待定」，给出范围、依据及与对方改动的区别。仅对方需改、本方已有能力足够或只需文档/配置操作时，明确无需本方代码计划；配置引发实现变更时仍按实际范围判断。
 
-需要用户决定的范围、权限、数据、外部契约或关键 NFR 取舍，先呈现证据、可行选项、后果与推荐，再使用可用交互方式询问。已有明确决定引用后沿用；无回答、超时或默认选项不算批准。不能交互时保留待决/待澄清，只阻塞依赖该决定的部分，不把重大假设藏进已选方案。
+涉及范围、权限、数据、外部契约或关键 NFR 取舍时，先核对已有授权与有效决定；范围内的技术选择自行定论，真正保留给用户的决定才呈现证据、可行选项、后果与推荐，使用可用 Ask User 类工具询问并等待明确答复。异步工具保持待答，不能仅输出聊天待办。已有明确决定引用后沿用；无回答、超时或默认选项不算批准。工具不可用则报告交互受阻，只保留受影响的待决/待澄清部分，不把重大假设藏进已选方案。
+
+```formal
+RULE @receiver_convergence:
+  WHEN: evaluating_or_reassessing_receiver_response
+  MUST: ["每轮先核对已定事项、剩余实质分歧和新证据；只重开受实质变化影响的结论，不因同一问题换了措辞重评",
+         "待澄清须给出缺失事实/决定、影响的结论、补齐方及解除条件；非阻塞细节不拖住已经成立的方案",
+         "双方有效结论对同一范围一致且必要确认齐备时，明确该契约已定并列双方依据，转入计划/交付/验证；不等待对本轮确认的再次确认",
+         "往返仅重复原有理由且无新证据时，停止同义反问，交付已达成部分、最小剩余分歧、本方主张与可接受边界；权限内当轮决定，需用户裁定或协调则按本节工具交互，不再续写一轮草案",
+         "没有可接受交集就明确不接受哪些部分及理由；用户暂缓或外部证据未到时写具体恢复条件，已定部分继续"]
+  MUST_NOT: [avoid_own_conclusion_with_draft_label, indefinite_draft_ping_pong,
+             fabricate_agreement_to_end_negotiation, lower_acceptance_to_close_request]
+```
 
 ## 5. 在原 CRD 文末追加答复
 
@@ -87,7 +99,7 @@ when_to_use: "用户会说「评估一下对方这个需求」「在 CRD 末尾
 
 - 继承原编号，新的 RESP 递增且不复用；新问题使用原 Q 编号体系并在本轮答复内列明提问方、待答方、关联需求和阻塞点。原文无编号时沿稳定章节定位，不强行新增全套编号。
 - 原文有末尾「往返答复记录」时追加本轮记录；没有时在末尾新建该节。既有正文和历史保持不变，答复中的新验收/范围只是提议；用户另授权同步正文时才按已确认依据局部更新。原件不是 Markdown 时沿用等价末尾答复结构与原格式。
-- 包含本方角色、草案/确认来源、原消息时间（未知则注明）、整理时间、CRD/代码基线、评估范围、逐项立场与代码动作、证据、原案/备选取舍、待决问题、计划去向和下一步。新旧答复冲突时引用旧 RESP，指出更正依据与影响；未明确取代的旧承诺保持待澄清。
+- 包含本方角色、技术结论与具体待决/确认依据、独立发送状态、原消息时间（未知则注明）、整理时间、CRD/代码基线、评估范围、逐项立场与代码动作、证据、原案/备选取舍、待决问题、计划去向和下一步。新旧答复冲突时引用旧 RESP，指出更正依据与影响；未明确取代的旧承诺保持待澄清。
 - 追加前检查同一来源/版本、范围、实质结论与计划去向是否已记录。重复调用且无实质变化时不新增 RESP、不更新时间；有新事实/决定时追加新轮，说明差异，绝不改写历史。按实质内容查重，不把无关 HEAD 变化当新答复。
 
 ## 6. 需要本方代码变更时，实际调用 dev-plan
@@ -105,7 +117,7 @@ when_to_use: "用户会说「评估一下对方这个需求」「在 CRD 末尾
 把**对应请求实现并通过约定检查后回写来源 CR**的规则带入计划顶部实施协议：回写位置、按请求核对范围与证据、文末追加实现结果、查重及不可写时的恢复办法均须自包含，不能只留在本技能或依赖实施者再次加载技能。内部实施设计进入计划，对外答复保留必要契约与判断，不替对方写内部开发计划。输出路径、重名处理与状态遵守 `dev-plan`，无用户代号时可用 `<CR标识>-respond`；已有文件先核对，不擅自覆盖。
 
 - **先查已有承接计划**：范围、方案、验收和依赖已覆盖且基线仍适用时，引用真实计划与当前状态，不重复生成。未覆盖增量按独立范围生成新计划；修订已有计划需有用户授权，不擅改其历史进度。
-- **需要修改，但关键确认未完成**：仍调用 `dev-plan`，推荐方案明确为待确认提议，计划标 `Blocked`，写清阻塞；不能跳过计划，也不能把外部未接受的契约写成 `Ready`。独立已确定部分可单独规划，未决部分显式排除并跟进，不宣称覆盖整个 CRD。
+- **需要修改，但关键确认未完成**：仍调用 `dev-plan`，明确本方技术选择，单列尚缺哪方对哪条契约或保留决定的确认，计划标 `Blocked`，写清阻塞；不能跳过计划，也不能把外部未接受的契约写成 `Ready`。独立已确定部分可单独规划，未决部分显式排除并跟进，不宣称覆盖整个 CRD。
 - **代码动作待定**：不包装成已确定改码需求；先保存答复与澄清问题。**无需修改**：说明无需新计划，不制造空计划。
 - 生成后回读计划，核对目标、ID、范围、取舍、验收及基线与答复一致，来源 CR 与完成回写规则齐备，再把实际计划链接/状态与需求去向填入**尚未定稿的本轮答复**。复用已有计划也核对这两项；缺失时按既有修订授权补齐，未授权修订则明确交接缺口，不冒称已有闭环。计划失败时本轮答复如实记录失败与恢复入口，原有答复不覆盖。任何状态都不触发代码实施或发送 CRD。
 
@@ -122,10 +134,10 @@ when_to_use: "用户会说「评估一下对方这个需求」「在 CRD 末尾
 
 - 当前代表接收方，未代提出方改需求或确认方案；评估模式下所有在范围内的需求均有目标/方案判断、证据、立场和本方代码动作，未知、未答、不接受部分与冲突未丢失。仅收录/原样追加时核对与来源一致，不要求制造新评估结论。
 - 评估模式下对「可持续、通用、精心设计」有具体证据与后果，而非口号；备选保持目标或显式提出验收变更，未暗增产品范围。
-- 原正文与历史未被重写，RESP/Q 无碰撞且引用可达，新答复在文末，重复输入未重复追加；草案、确认、承诺、交付未混用。
+- 原正文与历史未被重写，RESP/Q 无碰撞且引用可达，新答复在文末，重复输入未重复追加；本方技术结论、草案、确认、发送、承诺、交付未混用，不因未发送或未另获批准而将整份结论标草案。
 - 评估模式需改码的每项已按授权去往真实计划、现有承接或明确生成受阻；计划记录来源 CR、承接范围与顶部完成回写约定；未决依赖按计划就绪门处理；没有假链接或空计划。仅收录/原样追加不因消息内容触发计划；未运行的验证没有写成通过。实现结果回告只更新证据覆盖的请求范围，未实现余项和待回写缺口仍可追踪。
 
-最终给出：完整 CRD 路径与新增 RESP、关键立场、本方是否需改代码、计划路径/状态（或无需/待定/受阻）、仍待谁确认什么。仅收录/原样追加时给实际记录与未答项，明确未重新评估、未生成计划，不把已有立场当本次新结论。没有发送就明确「文档已保存，未发送」。评估模式有计划时给可直接复制的下一步 `review-dev-plan <实际计划路径>`（按当前客户端用 `$` 或 `/`），不自行评审或开始实施；实现结果回告则交付实际 CR/RESP、完成范围、证据与余项，复用既有实施/评审阶段的下一步，不退回计划评审；仅评估时只交付评估内容与未落盘说明。
+最终给出：完整 CRD 路径与新增 RESP、明确的本方立场、已收敛事项、本方是否需改代码、计划路径/状态（或无需/待定/受阻）、剩余实质分歧及具体裁定/补证动作，不只交付「草案待确认」。仅收录/原样追加时给实际记录与未答项，明确未重新评估、未生成计划，不把已有立场当本次新结论。没有发送就明确「文档已保存，未发送」。评估模式有计划时给可直接复制的下一步 `review-dev-plan <实际计划路径>`（按当前客户端用 `$` 或 `/`），不自行评审或开始实施；实现结果回告则交付实际 CR/RESP、完成范围、证据与余项，复用既有实施/评审阶段的下一步，不退回计划评审；仅评估时只交付评估内容与未落盘说明。
 
 ## 项目状态回写
 

package/skills/crd-respond/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "CRD 接收方评估与答复"
-  short_description: "接收方评估与答复 CRD、回告实现结果；需改码时生成带来源 CR 与完成回写约定的计划"
-  default_prompt: "使用 $crd-respond 代表 CRD 接收方处理完整文档；若实际是提出方则交回 crd，不因收到文件或追加回复而切换角色。评估时核实本方最新工作树，分别判断目标和指定方案，以可持续性、通用性、精心设计及实际约束比较长期备选，在原文末追加有证据且保留历史的答复；需改本方代码时实际调用 dev-plan，核验来源 CR、承接范围与计划顶部完成回写约定，未决契约标 Blocked。实现结果回告按请求与适用证据追加新 RESP，保留旧答复及未完成余项，不把实现冒充发布或对方验收，不重开规划。仅原样追加本方已拟答复或收录提出方澄清时保留来源与原意，不重评或生成计划。仅评估/仅答复遵守边界，不实施，不发送。"
+  short_description: "接收方独立评估长期方案并明确立场、收敛答复；需改码时生成带来源 CR 与完成回写约定的计划"
+  default_prompt: "使用 $crd-respond 代表 CRD 接收方处理完整文档；若实际是提出方则交回 crd，不因收到文件或追加回复而切换角色。评估时核实本方最新工作树，分别判断目标和指定方案，以可持续性、通用性、精心设计及实际约束比较长期备选，证据充分即明确本方技术结论，未发送或缺额外确认不一律标草案；重复分歧收敛为具体裁定，不无效往返，在原文末追加有证据且保留历史的答复；需改本方代码时实际调用 dev-plan，核验来源 CR、承接范围与计划顶部完成回写约定，未决契约标 Blocked。实现结果回告按请求与适用证据追加新 RESP，保留旧答复及未完成余项，不把实现冒充发布或对方验收，不重开规划。仅原样追加本方已拟答复或收录提出方澄清时保留来源与原意，不重评或生成计划。仅评估/仅答复遵守边界，不实施，不发送。"