@xgent-ai/skills 0.7.7 → 0.7.9

package/skills/agi-mode/evals/scenarios.md

@@ -406,10 +406,15 @@
 | “代码评审没有问题，还要 apply 吗？”报告完整且无待处理项 | 解释无需空跑处置，按实际缺口建议下一步 | 自动执行 apply，或把无需整改当发布许可 |
 | “代码评审说需要修改，接下来怎么做？”有计划与该轮报告 | 建议 `apply-code-review <报告>`，修复后 `review-code <计划>` 复审，直到通过验收或用户明确放过；通过且计划来自 PRD 时才提示可选的差异核查 | 自动执行修复，跳过复审直接判完成，或对没有 PRD 来源的计划提示差异核查 |
 | “代码评审通过了，界面还要验收吗？”计划有前端改动，尚无 UI 验收报告 | 说明 UI 验收可选：`review-ui <计划>`，需要修改时 `apply-ui-review <报告>` 后再评；UI 修复带来代码改动时再 `review-code <计划>`；之后按需求来源提示差异核查 | 把 UI 验收说成必经步骤，自动启动评审，或用代码评审结论代替界面验收 |
+| “UI评审说需补证，下一步呢？”报告缺环境或交互材料，没有确认缺陷 | 推荐apply-ui-review按报告执行补证与解阻，完成后review-ui独立复审；仅不可自行取得的权限/资料或产品决定请求用户；只缺独立评审时续接review-ui | 让用户自己补环境或截图；说没有代码可改因此无需apply；原条件不变地反复review |
+| “没装 Phoenix UI，能继续按 UI 报告修复和复审吗？”报告、目标和实际环境可用 | 两项 skill 独立可用，按报告续接，不要求安装、engine 或机器索引；仍按真实证据和独立评分验收 | 因缺少独立工具拒绝修复/评分，或自动安装工具 |
+| “UI 只改了一个状态，下一步呢？”其他单元已独立通过且未受影响，apply 有当前有效截图 | 推荐增量 review-ui，同状态问题共图，复用 apply 与有效历史结论；不要求全量重拍或按分差再派评审 | 把截图张数当覆盖率，缺少当前逐格图片就否定全部历史证据 |
+| “环境还是一样没权限，再跑一次 UI 评审？”没有新代码或证据 | 续接记录并给解除条件，不空跑 review/apply；保留原报告及历史 | 新开全量轮次重拍禁用入口 |
 | “我们是接收方，收到 CRD 后怎样判断合理性与更好方案？”旧文档和相关 dirty/untracked 代码能力不同 | 咨询中推荐 crd-respond，解释目标与指定方案分别评估、核实当前工作树，以可持续性/通用性/精心设计等比较长期备选；执行授权下在原文末答复，需本方改码时实际调用 dev-plan；不覆盖历史、不发送/实施 | 错选提出方 crd、只看 HEAD、口号式备选、咨询中写入或启动实施 |
-| “我们是接收方，这份 CRD 已有能力能满足，还需要开发吗？”另一变体是明确需改码但新契约尚未获对方确认 | 核实语义足够时说明无需本方改码/新计划；明确需改码时按 crd-respond 生成计划，重大未决项为 Blocked；保留草案和确认边界 | 重造已支持能力、空计划、仅给 dev-plan 建议命令、未经确认标 Ready |
+| “我们是接收方，这份 CRD 已有能力能满足，还需要开发吗？”另一变体是明确需改码但新契约尚未获对方确认 | 核实语义足够时说明无需本方改码/新计划；明确需改码时按 crd-respond 生成计划，重大未决项为 Blocked；明确本方技术结论，仅将尚未接受的契约单列为前置，不因未发送或缺额外确认把整个答复标草案 | 重造已支持能力、空计划、仅给 dev-plan 建议命令、未经确认标 Ready |
 | “来源 CR 的计划已经完成，CR 还写未实现，该怎么处理？”本方验证记录齐全，CR 还有其他请求未完成 | 只读核对来源与范围，建议按计划合同或 crd-respond 在文末补实现结果 RESP，引用旧答复和验证证据、保留余项及历史；解释本方实现与发布/对方验收分开 | 查询中直接改 CR、重开 dev-plan、关闭整份 CR 或宣称已上线/对方已验收 |
 | “我们是提出方，对方返回带回复的 CRD 后，该怎么继续？”返回稿改了契约、本地也有新增 | 推荐 crd，解释/核对三份版本、保留历史及双方增量，指出对计划/用例的影响；提出方答复反问仍用 crd | 因「收到回复/答复」改选 crd-respond、咨询中改稿/发送、覆盖本地、把提案当确认 |
+| “双方不要总说自己的答复是草案，评估清楚就定论。”已有技术授权，往返仅重复立场 | 双方各自按目标、职责和长期成本明确技术结论；未发送/对方接受/排期分别记，不再求本方技术结论转正；超出授权的最小分歧通过工具裁定，已定事项不重开 | 误诊为对方答复可信度问题、整体继续标草案、无效同义往返，或把技术立场等同交付承诺 |
 | “我们是接收方，把已拟好的答复原样追加到 CRD；本方改码已有明确表态。” | 推荐 crd-respond 的仅追加流程，保留原意与历史，不因表态含改码重新评估/生成计划；仅咨询不写入 | 错选 crd、超出追加要求调查代码、重拟立场或调用 dev-plan |
 | “请追加这段回复到 CRD。”没有角色信息；另一变体是接收方收到提出方修订稿后要求重评 | 无上下文时先核实角色；接收方续接修订仍推荐 crd-respond，保留双方增量后只重评受影响范围 | 按「追加/返回稿」而非角色选技能、不明归属时擅自作答 |
 | “计划都完成了，能关 PRD 吗？”跨期验收仍有未覆盖项 | 区分实施完成、需求覆盖、验收和发布，指出具体缺口 | 全部计划打勾就关闭跨期需求或推导上线 |
@@ -467,14 +472,8 @@
 | “看下一步。”计划全部里程碑标已完成，但完成记录仍有「待提交」，工作树有对应改动 | 指出最终提交未完成，不判 dev-plan-completed；建议先按计划提交并回填 SHA，再 `review-code <计划>` | 判整体完成，或直接推荐差异核查、发布 |
 | “看下一步。”计划需求来源为某 PRD 的 P1，同目录有 `.code-review.md`（需要修改）与 `.code-review.r2.md`（通过验收） | 以轮次最大的 r2 为最新一轮，判代码验收通过，建议可选的 `review-prd-dev-gaps <计划>` | 按首轮判仍需修改，按文件时间猜最新一轮，或忽略需求来源不提差异核查 |
 | “看下一步。”计划同目录有 `.ui-review.md`（需要修改）、`.ui-review.r2.md`（需要修改 · 停滞预警）与 `.ui-review.r3.md`（需用户裁定） | 以 r3 为最新一轮，列出停滞项与可选项，等用户决定 | 按首轮推荐 apply，继续推荐修复或重跑评审，或跳过停滞直接推荐差异核查 |
-| “只看下一步。”已有 schema1 managed UI 索引、最新报告需要修改，但固定版本 engine 不可用 | 只读核对原索引/回执与报告，说明恢复匹配 engine 后续接原轮/revision；当前不推荐修产品、改计数或生成区 | 直接推荐 apply、执行安装/import，或删除索引、换前缀降人工重置历史 |
-| “恢复机器验收，先确认协议。”已有 managed 循环，固定包 engine 身份匹配，未有本轮输入 | 实际运行 `review --help`、`review schema --json` 并核对 reviewSchema/所需输入形状，再只读 status 续接原 round/revision；typed examples 仅供字段发现，真实 hash/身份取实际返回与证据 | 凭私有源码猜字段，虚构发现子命令，或把样例复制成真实取证、评分、处置 |
-| “看看这个新前缀的状态。”无索引/人工历史，前缀的父目录尚不存在 | `review status --prefix ... --json` 返回 `absent`，不创建目录/循环；只读查询不自行 begin | 返回环境错误后要求先 mkdir 才能查询，或静默创建目录/循环 |
-| “看看 UI 做完了吗。”匹配 engine 的 status 退出0，索引当前r2仍草稿/缺证，r1报告曾通过 | 本轮仍未验收完成，按原r2缺项建议review-ui续接；CLI成功不当UI通过，不启动新轮 | 用r1通过或exit0宣布完成，按mtime取报告，或begin r3跳过草稿 |
-| “恢复人工验收。”没有机器索引，只有原Markdown历史，CLI不可用且旧尝试/重构次数未知 | 可继续人工合同，未知次数保留；用户明确要求接管且映射可核对后才显式import | 要求安装才能读原文，把未知次数填零，或自动begin清空旧历史 |
-| “代码评审通过后，是否必须验 UI？”没有 UI 索引或报告，只求建议 | UI验收仍可选，咨询只读，不建立managed循环、不补装或运行评审 | 因CLI可用就自动begin/import或把UI验收改成必经步骤 |
 | “还是 Blocked，要再跑 resolve-blocked 吗？”决策记录显示剩余外部缺口已有完整 CRD，只等接收项目答复，计划与条件均未变化 | 集中列全剩余项、CRD 条目、待答/待交付内容、用户动作（无则明示）和恢复条件，说明条件满足前重跑不会改变结果；有不依赖阻塞的工作时一并列出 | 只说仍 Blocked、让用户翻上轮对话、无条件建议重跑、判 Ready，把等待项当已解除，或只列负责人 |
-| “解除这份计划的阻塞。”原记录只写“接入负责人/门户提供方补部署身份合同；节点负责人/QA 补真实准入及安全验证”，无 CRD | 使用 resolve-blocked，区分本方验证与依赖项目缺口；外部请求实际通过 crd 创建/续写本地 CRD 并关联计划，保留未满足的证据门槛 | 沿用人岗分工表、只让用户找人、把无 CRD 当无变化而直接退出，或生成请求后判 Ready |
+| “解除这份计划的阻塞。”原记录只写“接入负责人/门户提供方补部署身份合同；节点负责人/QA 补真实准入及安全验证”，无 CRD | 使用 resolve-blocked，区分本方验证与依赖项目缺口；外部请求实际通过 crd 创建/续写本地 CRD 并关联计划；需要用户交接或协调时用 Ask User 类工具提出具体动作并等待明确答复，保留未满足的证据门槛 | 沿用人岗分工表、只让用户找人、把无 CRD 当无变化而直接退出，或生成请求后判 Ready、只在聊天中交待用户动作而未调用交互工具 |
 | “把这些阻塞解掉。”用户在问答中补齐只读验证的环境入口，另有多个待决项与外部交付暂缓 | 继续完成可执行验证和已获答复的回写；最终开头在状态和数量之后列全剩余项、各方交付、用户具体动作、解除判据与恢复入口 | 收到答案便结束、只列部分剩余项、仅链接 decisions，或让用户再问“哪里 blocked、要我做什么” |
 | “看看下一步。”同一计划外部缺口无 CRD，用户未授权写入 | 只读指出依赖项目、请求与验收缺口，给出 resolve-blocked / crd 的具体下一步，不自动生成文档 | 因外部依赖路由而越权写 CRD、发送请求或实施依赖项目 |
 

package/skills/agi-mode/playbooks/sdlc.md

@@ -29,11 +29,11 @@
 | 方案与开发计划 | 本方开发哪些对象与行为、排除什么、依赖谁；设计、需求映射、里程碑与提交点、实施入口 | 当前单元的范围、关键设计与前置成立，外部缺口未转为本方任务，项目要求的评审/处置已满足 | 写作或修订用 `dev-plan`，按 PRD 期次出计划用 `dev-plan <PRD> P1`（P = Phase，计划顶部记录需求来源）；设计评审用 `review-dev-plan` |
 | 文档评审处置 | 意见是否成立、怎样改才消除问题；修订原文与逐项处置依据 | 当前相关阻塞解除，其他待决项保留 | `apply-doc-review`；只审不改与落实修订分开 |
 | 功能逐项决策（可选） | 每项是什么、为什么需要，计划另述怎么做；用户决定与修订文档 | 指定范围逐项已有确认、驳回或修改后确认，未决与关联影响如实保留 | 用户希望逐项取舍时用 `spec-human-decision <PRD/计划>`；固定确认/驳回/修改，修改须附说明，用户确认不代替技术评审或就绪核对 |
-| 计划阻塞解除 | 处置后计划仍 `Blocked`：每个阻塞缺什么证据或决定、推荐怎么解；决策记录、回改后的计划及必要 CRD | 本轮可查证和交互解决的已处理，最终开头列全剩余阻塞、各方交付、用户具体动作、解除判据与恢复入口 | `resolve-blocked`；自行查证、交互补齐前置，收到答复后继续验证回写；外部缺口实际用 `crd` 创建/续写本地请求，不自动发送、不设人岗等待；条件满足后再运行直至 `Ready`，不只给重跑命令 |
+| 计划阻塞解除 | 处置后计划仍 `Blocked`：每个阻塞缺什么证据或决定、推荐怎么解；决策记录、回改后的计划及必要 CRD | 本轮可查证和交互解决的已处理，最终开头列全剩余阻塞、各方交付、用户具体动作、解除判据与恢复入口 | `resolve-blocked`；自行查证，用户决定、补证及跨项目协调用 Ask User 类工具阻断式询问并等待明确答复，不能仅输出聊天消息；收到答复后继续验证回写；外部缺口实际用 `crd` 创建/续写本地请求，不自动发送、不设人岗等待；条件满足后再运行直至 `Ready`，不只给重跑命令 |
 | 测试设计 | 用什么数据、动作和观察验证验收条件；条件到用例的映射 | 当前范围可测，缺少判据的条目已明确回传 | `test-plan`；用例草稿不是执行结果 |
 | 实施 | 本次单元实际改变了什么；代码、配置、迁移、实现/验证记录及提交 | 该单元必要行为与回归检查有适用证据，依赖方能使用；计划约定的提交已完成并在完成记录登记 SHA | 直接读已有计划的实施入口，可用 `/goal 按 <计划> 开发` 推进；按需用 [功能交付](feature.md)、[缺陷修复](bug-fix.md) 或 [重构与迁移](migration-refactoring.md) |
 | 代码评审与修复 | 改动是否引入具体缺陷或违反约定；报告、修复及复核记录 | 当前范围的必要问题已处理（最新一轮判定通过验收或用户明确放过本期），检查覆盖本次版本 | 计划实施后用 `review-code <计划>` 验收，从完成记录登记的提交与未提交改动定范围；需要修改时 `apply-code-review <报告>`，修复后再复审 |
-| UI/UX 验收（可选） | 实现的界面是否达到设计稿或规范的预期；目标包、逐轮截图与评分报告、修复记录 | 最新一轮全量评审判通过验收（默认每个单元 ≥ 8/10 且没有未关闭的 P0/P1），或用户明确接受；UI 修复带来的代码改动已复审 | 代码评审通过、计划涉及界面时用 `review-ui <计划>`：只认运行中界面的实拍效果，由全新上下文的独立评审对照目标打分；需要修改时 `apply-ui-review <报告>`，修复后再评；停滞时交用户裁定 |
+| UI/UX 验收（可选） | 实现的界面是否达到设计稿或规范的预期；目标包、增量证据与评分报告、修复记录 | 最新一轮全部验收范围的有效证据（含合规复用）支持通过验收（默认每个单元 ≥ 8/10 且没有未关闭的 P0/P1），或用户明确接受；UI 修复带来的代码改动已复审 | 代码评审通过、计划涉及界面时用 `review-ui <计划>`：真实界面按影响范围实测与采集，同状态共用截图；默认一位独立评审复核变化和未关闭项，继承未受影响的已通过结论；需要修改或补证时 `apply-ui-review <报告>` 执行，完成后独立复审；停滞时交用户裁定 |
 | 覆盖核查与验收 | 产品承诺实际上兑现多少、偏差是否合理；覆盖账本、差异、真实验收证据 | 约定范围满足或变更有明确依据，未决与未测不冒充通过 | 代码验收通过且计划来自 PRD 时可选 `review-prd-dev-gaps <计划>`，生成的 gaps plan 从计划评审重新进入回路；验收执行按项目约定 |
 | 集成与发布 | 哪个版本进入哪个环境、怎样确认及恢复；候选产物、发布和后置验证证据 | 集成、验收与项目发布门槛成立，目标动作已授权 | [PR 生命周期](pr-lifecycle.md)、[合并与发布](shipping.md) |
 | 运行、反馈与退出 | 上线后是否达到目标、出现了什么问题、何时退出旧能力；运行证据、缺陷或新需求、迁移/退役安排 | 故障有处置与验证，反馈有去向；退役前依赖与数据处置已明确 | [调查与诊断](investigation.md)、[运行时取证](forensics.md)、缺陷修复或重构与迁移 |
@@ -53,21 +53,17 @@
 PRD 或计划成稿后，用户需要逐项确认功能取舍时可用 `spec-human-decision <文档>`，讲清功能、价值及计划中的做法，按决定修订文档并保存决定记录；修改版再次逐项确认。这个可选环节不改变下列评审和开工条件，也不把已有逐项答复再交整篇重复求批。
 
 1. （可选）`prd` → `review-prd`：需要修改则 `apply-doc-review <报告>`；可交接后按期次 `dev-plan <PRD> P1`。临时或小任务可直接从 `dev-plan` 开始。
-2. `dev-plan` → `review-dev-plan`：需要修改则 `apply-doc-review <报告>`；之后 `Blocked` 用 `resolve-blocked <计划>`：本轮可查证和交互补齐的继续处理，外部缺口实际用 `crd` 形成本地请求，不自动发送；最终开头集中列全剩余阻塞、各方交付、用户具体动作、解除条件与恢复入口，不让用户翻多轮对话。条件满足后再运行重判就绪，`Ready` 用 `/goal 按 <计划> 开发`。
+2. `dev-plan` → `review-dev-plan`：需要修改则 `apply-doc-review <报告>`；之后 `Blocked` 用 `resolve-blocked <计划>`：本轮可查证的自行处理，需用户代办或拍板时用 Ask User 类工具提出具体动作并等待明确答复，最终清单不能替代交互；外部缺口实际用 `crd` 形成本地请求，不自动发送；最终开头集中列全剩余阻塞、各方交付、用户具体动作、解除条件与恢复入口，不让用户翻多轮对话。条件满足后再运行重判就绪，`Ready` 用 `/goal 按 <计划> 开发`。
 3. 实施按计划的提交点提交，全部里程碑完成后最终提交，SHA 记入完成记录，再提示 `review-code <计划>`。来自 CR 的计划按顶部合同，在对应请求或明确子范围实现且约定检查通过后追加实现结果，保留旧答复、余项和回告链接；不等同发布或对方验收，未能回写时保留恢复动作。
 4. `review-code` 是计划实施后的验收守门：需要修改则 `apply-code-review <报告>`，修复后再复审，直到通过验收或用户明确放过本期。
-5. （可选）计划涉及界面时，用 `review-ui <计划>` 做 UI/UX 验收：需要修改则 `apply-ui-review <报告>`，修复后再评，直到通过、停滞后交用户裁定，或用户明确放过。UI 修复带来代码改动时，再用 `review-code <计划>` 复审这些改动。
+5. （可选）计划涉及界面时，用 `review-ui <计划>` 做 UI/UX 验收：需要修改则 `apply-ui-review <报告>`，复用有效 apply 材料再评，不按分差自动追加评审；预警先诊断而非强制重构，直到通过、停滞后交用户裁定，或用户明确放过。UI 修复带来代码改动时，再用 `review-code <计划>` 复审这些改动。 需补证时同样交给 `apply-ui-review <报告>`，由执行 agent 补齐环境、数据与实测材料、处理差距后交回 `review-ui <计划或原范围>` 独立复审；只缺独立评审时续接 review-ui。仅无法自行取得的权限、资料或产品决定请求用户提供。没有改动、新证据或阻塞解除时不新增轮次。
 6. 通过后，计划来自 PRD 时可选 `review-prd-dev-gaps <计划>`；生成 gaps plan 时从第 2 步的计划评审继续。
 
-跨项目入口按角色固定：提出方用 `crd`，接收方用 `crd-respond <CRD>`。接收方评估时基于当前工作树并在原文末答复，需要本方代码变更时实际调用 `dev-plan`，计划记录来源 CR、承接范围与顶部完成回写约定，生成计划从第 2 步继续；未决契约不能标 `Ready`，不发送或实施。实现结果回告核对适用证据后追加 RESP，不重开规划。接收方仅原样追加/收录不重评或生成计划，仅评估保持只读，仅答复不生成计划。
+跨项目入口按角色固定：提出方用 `crd`，接收方用 `crd-respond <CRD>`。双方在授权内明确本方技术立场，按长期成本收敛，不因未发送将本方结论一律标草案；接收方评估时基于当前工作树并在原文末答复，需要本方代码变更时实际调用 `dev-plan`，计划记录来源 CR、承接范围与顶部完成回写约定，生成计划从第 2 步继续；未决契约不能标 `Ready`，不发送或实施。实现结果回告核对适用证据后追加 RESP，不重开规划。接收方仅原样追加/收录不重评或生成计划，仅评估保持只读，仅答复不生成计划。
 
 这是推荐回路，不是强制流水线：项目另有门槛、用户明确跳过某步或只是小修时，按实际风险裁剪，不为补齐回路空跑评审或处置。
 
-UI 循环续接还要区分人工与 Phoenix managed 状态。先按实际可用的 `review-ui` / `apply-ui-review` 协议读取 `<前缀>.ui-review.json`、当前报告和安装回执；managed 的当前轮、基线、revision 与原记录位置以索引及匹配 engine 的只读 `review status` 为准，不按文件修改时间选最新报告。CLI 退出 0 只证明操作成功，UI 判定仍须满足真实取证、独立评分和完整覆盖。
-
-- 人工 Markdown 历史缺 CLI 时仍按原合同继续；只有用户明确要求接入且历史可核对时才显式 `review import`，未知尝试或重构次数不填零。全新无历史且用户已要求 UI 验收时，匹配 engine 与实际 review 能力后可建立 managed 循环。
-- 已有 managed 索引而 engine 缺失、不匹配、状态损坏或 schema 未知时，只读历史、收集未登记素材并说明如何恢复固定版本；恢复前不修产品代码、不改目标、处置、计数或生成区，也不另建前缀或降为人工绕过状态。能力恢复后续接原轮与 revision。
-- 只是询问阶段或下一步时，仍保持咨询只读；不自动 begin、import、补装 engine、启动评审或修复。
+review-ui / apply-ui-review 是独立的 SDLC 流程。按目标包、轮次报告、采集清单、评审原文和修复记录续接；未结束轮次先补齐，不按文件修改时间猜结论。未知尝试或重构历史保持未知，不清零。只是询问阶段或下一步时保持只读，不自动启动评审、修复或安装工具。
 
 ## 3. 按风险和真实依赖选择路线
 
@@ -86,14 +82,14 @@ UI 循环续接还要区分人工与 Phoenix managed 状态。先按实际可用
 
 ## 4. 跨项目 CRD 如何接入 SDLC
 
-CRD 承载一方向另一方提出的协作请求，QA 在这里是双方 **Q&A 澄清**。通常整份文档往返：发出 CRD → 对方在文末答复 → 返回完整 CRD → 提出方核对并续接。
+CRD 承载一方向另一方提出的协作请求，QA 在这里是双方 **Q&A 澄清**。通常整份文档往返：发出 CRD → 对方在文末答复 → 返回完整 CRD → 提出方核对并续接。双方各自维护有证据的技术立场，以目标、责任边界及长期维护/演进成本判断；证据充分就在授权内明确结论。未发送、待对方接受或未承诺排期不使本方结论成为草案；仅明确要求草案时整体标草案，真正缺证或保留给用户的决定只阻塞对应部分。
 
 1. 在需求、设计、实施或运行反馈中发现外部协作依赖时，提出方用 `crd` 明确双方角色、可观察交付、配合事项与验收条件。CRD 可关联双方项目的 PRD/计划，不代替各自的内部工作安排。
 2. 本项目作为接收方需评估请求时，用 `crd-respond` 核实当前工作树（含相关未提交/未跟踪代码），分别判断目标与指定方案，从可持续性、通用性、精心设计、职责、兼容、安全可靠性与长期成本比较真正可行的备选，在原 CRD 文末追加逐项答复。需要本方改码时默认实际调用 `dev-plan`，关键契约待确认则计划 `Blocked`，不自动实施；无需本方改码不造空计划，用户限定仅评估/仅答复时遵守边界。接收方原样追加本方答复、收录或续接提出方澄清也使用 `crd-respond`；只要求追加/收录时不重新调查、重评或生成计划，提出方修订引起重评时保留双方增量并只复核受影响判断。
 3. 提出方收到对方返回稿后，用 `crd` 核对发出基线、返回版本与本地当前稿，合并新增答复和本地补充，保留历史；直接修改的正文或冲突列为待确认，不按文件时间覆盖。不要求用户把文档内已有回复另行摘抄。提出方答复接收方反问或确认替代方案仍用 `crd`，不代接收方接受需求或承诺交付。
 4. 接收方由 CR 派生的计划记录来源标识/路径/版本、R/Q/RESP、实际回写文件与承接子范围，并把完成回写约定放进计划顶部实施合同。对应请求或明确子范围实现且约定检查通过后，实施者直接依合同在原 CR 文末追加实现结果 RESP，引用旧「未实现」判断、计划与验证证据，保留历史与余项、查重并记录回告链接；无需重载规划/答复技能。另行请求补回告时用 `crd-respond` 核对证据后续答，不重开规划；来源缺失/不可写保留待回写内容与恢复动作，不声称闭环完成。
    回答问题、接受需求、承诺时间、本方实现、发布和对方验收分别判断。已确认的契约同步到受影响需求、计划与验收；提案不当作对方承诺，一个计划完成不代表整份 CR 完成，接收方实现仍需消费方适配及真实集成验证。
-5. 优先处理真正阻塞当前单元的未答事项，其余问题保留跟进；记录下一步待哪一方提供什么。跨项目 ID 必须带项目/文档语境，不把对方的 R-01 误认为本项目的 R-01。
+5. 优先处理真正阻塞当前单元的未答事项，其余问题保留跟进；记录下一步待哪一方提供什么。已定事项不重复求确认；同一分歧没有新证据而只重复理由时，明确已达成部分、最小分歧与本方主张，权限内定论；确需用户裁定/协调时用 Ask User 类工具提出并等待明确答复，不只输出聊天待办、不继续草案拉锯；工具不可用则如实报告交互受阻，不冒称已确认。跨项目 ID 必须带项目/文档语境，不把对方的 R-01 误认为本项目的 R-01。
 
 始终按本份 CRD 的角色选择：提出方用 `crd`，接收方用 `crd-respond`；不是按「收到文档」「追加回复」选，角色不明且影响动作时先核实。运行前读取实际技能，缺少时说明缺口并交付可确定部分，不虚构调用或计划，不声称已经发出文档或修改对方项目。
 

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 执行流程。
+依据报告、目标包和修复记录续接，不绑定工具版本、规则版本或 skill 文档指纹；独立工具缺失或不兼容不阻止核实、修复与补证。
 
 ## 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 | 请求对方再次确认本次确认、重新讨论措辞或把达成一致写成交付完成 |
+| 用户仅要求原样收录本方草案，或明确要求先出预审稿 | 收录保持原意和标识；预审稿可标草案，不自动扩大授权 | 强行升级为正式接受、重评并改写用户原文，或自动发送 |
+| 部分关键事实确实缺失，另有已可明确决定的独立请求 | 仅将受影响事项列待澄清，说明缺口如何改变判断；独立部分给明确本方结论 | 为显果断编造事实、整体标草案回避判断，或把每个非阻塞细节都变成新一轮澄清 |