npm - @xgent-ai/skills - Versions diffs - 0.6.0 → 0.7.0 - Mend

@xgent-ai/skills 0.6.0 → 0.7.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (1187) hide show

package/skills/agi-mode/assets/sdlc/event.md CHANGED Viewed

@@ -7,7 +7,7 @@ title: "<可读标题>"
 artifact: "<仓根相对路径或稳定 URL>"
 facet: "<document / readiness / implementation / review / disposition 等>"
 scope: "<稳定范围，如 plan、M2、F-01>"
-state: "<state-model.md 对应 kind/facet 的固定状态码，不能确认用 unknown>"
+state: "<state-model.md 对应 kind/facet 的固定状态码：按判定顺序取最强可支撑状态，没有可读依据才用 unknown>"
 source_state: null
 evidence_status: "<confirmed / provisional / stale / conflict / unknown>"
 observed_at: "<ISO 8601，带时区>"
@@ -30,4 +30,4 @@ relations: []
 - 未完项与限制：<缺证、未同步、待决；没有则写无，不填猜测>
 - 下一步及解除条件：<动作 + 可观察完成判据；无后续则说明>
-<!-- 创建事件时替换占位并移除此注释。source_state 有原文状态则保留其文字，否则 null；可选 candidate_state 只能写模型中的对应枚举。kind=review 时补 review_type: prd / dev-plan / code / other。sources.path、artifact 均按仓根解析；正文 Markdown 链接按本文件目录解析。relations 如 {type: covers, target: 对象UUID, scope: FR-1}；评审对所审对象用 reviews，复审对前轮用 rechecks。 -->
+<!-- 创建事件时替换占位并移除此注释。source_state 有原文状态则保留其文字，否则 null；可选 candidate_state 仅在 state 为 unknown 时使用，只能写模型中的对应枚举。kind=review 时补 review_type: prd / dev-plan / code / other。sources.path、artifact 均按仓根解析；正文 Markdown 链接按本文件目录解析。relations 如 {type: covers, target: 对象UUID, scope: FR-1}；评审对所审对象用 reviews，复审对前轮用 rechecks。 -->

package/skills/agi-mode/assets/sdlc/index.md CHANGED Viewed

@@ -12,6 +12,6 @@
 ## 当前重点
-<只链接当前需要跟进的对象状态页，说明首选下一步与全局阻塞；完整活动项见分类索引。没有可确认活动项时如实说明。>
+<列当前需要跟进的工作项：业务主题、文档类型及可见的原文仓根相对路径/链接，附对象状态页入口；用通俗语言说明进展、具体阻塞、首选下一步与完成条件，保留状态及证据码。完整活动项见分类索引。没有可确认活动项时如实说明。>
 <!-- 初始化时只链接实际存在的索引；未创建的类别写“暂无登记”，不要留断链。 -->

package/skills/agi-mode/assets/sdlc/object-status.md CHANGED Viewed

@@ -1,7 +1,7 @@
 # <对象标题> · 状态
 - 对象 ID / 类型：<完整 UUID / prd、plan、review>
-- 状态模型：<协议 v3 / state-model v1；评审对象另写 review_type>
+- 状态模型：<协议 v3 / state-model v2；评审对象另写 review_type>
 - 来源：<实际文档/报告链接，版本>
 - 核查时间：<带时区时间>
 - 可见范围：<分支/HEAD/dirty、所核实范围及同步限制>
@@ -11,7 +11,7 @@
 | 维度 / 范围 | 固定状态码 | 来源自述 | 证据质量 | 证据 / 对应事件 | 差异、缺证或阻塞 | 下一步及完成判据 |
 | --- | --- | --- | --- | --- | --- | --- |
-<!-- 状态码按仓内 state-model.md；无法确认用 unknown，候选另列不冒充当前事实。原计划状态滞后时保留自述及纠正依据；开发完成不代表验收或发布。 -->
+<!-- 状态码按仓内 state-model.md 的判定顺序取最强可支撑状态，证据质量写 confirmed / provisional / stale / conflict；只有没有可读依据才用 unknown。差异列用一句话写缺什么或哪些改动未覆盖，不堆免责说明。原计划状态滞后时保留自述及纠正依据；开发完成不代表验收或发布。 -->
 ## 关联

package/skills/agi-mode/assets/sdlc/state-model.md CHANGED Viewed

@@ -1,4 +1,4 @@
-# 固定状态与证据校准 · v1
+# 固定状态与证据校准 · v2
 本文件随状态协议保存到项目，不依赖安装 agi-mode。状态是基于当前可见证据的判断，不是从原文标题或状态行直接复制的事实。PRD、计划、评审、处置和实现记录仍在用户约定的位置。
@@ -6,26 +6,36 @@
 每条事件声明 `schema_version: 3`，`state` 从下面对应 `kind + facet` 的集合取值；原文自述另存 `source_state`（无状态文字用 null）。正文解释来源、版本、覆盖范围、判断依据及差异。各维度独立，不把整个项目强制压成一个阶段，也不要求补造中间事件。
-- `evidence_status` 固定为 `confirmed`（该范围可核实）、`provisional`（仅有线索或覆盖不足）、`stale`（旧证据不适用于当前相关版本）、`conflict`（有效证据矛盾未解）、`unknown`（无可用依据）。这是判断依据的质量，不是百分比置信度。
-- 无法确定当前状态用 `state: unknown`；可选 `candidate_state` 记录待验证候选，仍必须属于对应状态集合。旧的确定状态保留在历史事件，不作为当前默认答案。`ready`、`completed`、`applied` 只有依据达到 `confirmed` 才能作为当前肯定结论，否则用 unknown 与候选。
-- 例如计划仍写“未开始”，但完整实施证据已核实，可记录 `state: dev-plan-completed`、`source_state: 未开始`、`evidence_status: confirmed`，正文说明原状态滞后及可追溯依据。自报完成但缺证则写 unknown / provisional，候选为 dev-plan-completed。
+- **state 取最强可支撑状态**：按下文各节的判定顺序，取原文记录与可核验物（记录文件、登记的提交、报告判定行、处置节、决策记录）支持的最强状态。之后相关文件又有改动时状态不降级，改由证据质量表达；只有完全没有可读依据时才用 `unknown`。
+- `evidence_status` 表达依据质量与当前适用性，不是百分比置信度，固定为：
+  - `confirmed`：原文记录与可核验物一致，覆盖该状态的判定条件；
+  - `provisional`：只有原文自述（状态行、勾选、快照计数），缺少支撑记录；
+  - `stale`：依据在其记录基线上成立，但之后相关文件另有改动未被覆盖，正文列出未覆盖的提交或文件及复核动作；
+  - `conflict`：有效依据相互矛盾，state 取矛盾双方中较弱的一方，正文写明两处出处；
+  - `unknown`：没有可读依据。
+- `state: unknown` 只用于原文缺失、不可读或没有任何状态/进度信息；`candidate_state` 仅在此时记录线索指向的候选，必须属于对应状态集合。不用 unknown 或候选代替判断。
+- **归档对象**：原文明确标为历史、废弃或已被取代的 PRD/计划，导航标归档，不套用下文判定顺序，也不给下一步。状态页保留最后登记的状态；首次登记写 `state: unknown`，`source_state` 保留原文标记，正文注明归档不判定。原文或用户明确重新启用后才恢复判定。
+- 例：计划仍写“未开始”，但完成记录与实现证据覆盖全部里程碑 → `dev-plan-completed`、`source_state: 未开始`、`confirmed`，正文说明原文滞后。只有快照写 3/3、没有任何记录 → `dev-plan-completed`、`provisional`，下一步补证。完成后相关代码又有提交 → 仍是 `dev-plan-completed`、`stale`，列出这些提交。
 ## 开发线：文档就绪
 | kind / facet | 固定 state | 判定条件 |
 | --- | --- | --- |
-| prd / document | `prd-drafted` | 已有 PRD，当前可见范围内尚未发现可确认关联的评审；不得宣称其他机器也从未评审 |
-| prd / document | `prd-reviewed` | 确认存在针对该 PRD 的评审，尚无充分证据满足 ready；分别列出各轮处置，不把“没找到 applied”说成“确定未处理” |
+| prd / document | `prd-drafted` | 已有 PRD，未发现可确认关联的评审，也尚未被计划承接；不得宣称其他机器也从未评审 |
+| prd / document | `prd-reviewed` | 有针对该 PRD 的评审，判定需要修改且处置未完成 |
 | prd / document | `prd-blocked` | 有当前有效的关键范围、产品语义、验收或决策阻塞；可在评审前或处理后出现 |
-| prd / document | `prd-ready` | 当前文档可交接，所需评审意见已核实处置或确认无需处理，关键阻塞已解除 |
-| plan / readiness | `dev-plan-drafted` | 已有开发计划，当前可见范围内尚未发现可确认关联的计划文档评审 |
-| plan / readiness | `dev-plan-reviewed` | 确认存在计划文档评审，尚无充分证据满足 ready；不表示代码已评审 |
+| prd / document | `prd-ready` | 当前文档可交接：最新评审无需修改或须改项已处置，关键阻塞已解除 |
+| plan / readiness | `dev-plan-drafted` | 已有开发计划，未发现可确认关联的计划文档评审，且实施尚未开始 |
+| plan / readiness | `dev-plan-reviewed` | 有计划文档评审，判定需要修改且处置未完成；不表示代码已评审 |
 | plan / readiness | `dev-plan-blocked` | 当前开工条件存在已证实的关键阻塞，列解除条件，不限于 review applied 之后 |
-| plan / readiness | `dev-plan-ready` | 设计与前置可执行，所需评审意见已核实处置或确认无需处理，无关键开工阻塞；不是实施完成 |
+| plan / readiness | `dev-plan-ready` | 设计与前置可执行，最新评审无需修改或须改项已处置，无关键开工阻塞；不是实施完成 |
-上述两类也允许 `unknown`。判断时先核对当前版本及范围；有已证实阻塞用 blocked，满足就绪条件用 ready，只有评审事实则 reviewed，仅有原文则 drafted。仅有过期评审时可保留 reviewed 这一历史发生事实，但标 stale 并说明当前需复核，不能因此断言当前 ready。局部评审的 reviewed 只代表该 scope；对象汇总必须说明其余覆盖缺口。
+判定顺序，取第一个成立的状态：
-项目明确不需要某项评审时，引用项目规则或用户决定作为豁免依据，可在其他就绪条件满足时判 ready；不伪造评审对象或 applied 历史。没有项目豁免时，不仅凭原文自报 Ready 跳过评审/处置核对。
+- **PRD**：文档有未解的阻塞问题 → `prd-blocked`；最新一轮评审判定无需修改，或处置记录显示须改项均已关闭 → `prd-ready`；有评审但须改项未处置完 → `prd-reviewed`；未发现评审但已有计划承接它（计划的需求来源指向该 PRD）→ `prd-ready`，证据 provisional 并注明未发现评审；其余 → `prd-drafted`。
+- **计划**：计划状态行为 `Blocked`，或决策记录最新一轮结论为 Blocked → `dev-plan-blocked`；最新一轮计划评审判定无需修改，或处置/决策记录显示须改项与阻塞均已解除 → `dev-plan-ready`；有评审但须改项未处置完 → `dev-plan-reviewed`；未发现评审但实施已开始或完成 → `dev-plan-ready`，证据 provisional 并注明未发现评审；其余 → `dev-plan-drafted`。
+最新评审或处置之后原文又有改动时，状态按评审与处置结果判定，证据记 stale 并说明改动范围；改动引入新阻塞时以阻塞为准。局部评审只代表其 scope，对象汇总说明其余覆盖缺口。项目或用户明确豁免评审时，引用豁免依据，在其他条件满足时判 ready；不伪造评审对象或 applied 历史。
 ## 开发线：计划实施
@@ -34,10 +44,18 @@
 | plan / implementation | `dev-plan-not-started` | 可核实尚未开始；仅未发现代码或记录不能证明未开始 |
 | plan / implementation | `dev-plan-in-progress` | 有实际实施证据，当前范围仍有必需工作未完成 |
 | plan / implementation | `dev-plan-implementation-blocked` | 实施存在已证实阻塞；与设计未就绪的 dev-plan-blocked 分开 |
-| plan / implementation | `dev-plan-completed` | 当前 scope 内全部必需交付及计划规定的验证门槛均有适用证据，未决缺口已解除或有明确范围变更依据 |
-| plan / implementation | `unknown` | 实施进度不可核实、证据过期或相互矛盾，保留候选及缺什么 |
+| plan / implementation | `dev-plan-completed` | 当前 scope 内全部必需交付及计划规定的验证门槛均有记录，未决缺口已解除或有明确范围变更依据 |
+| plan / implementation | `unknown` | 计划没有可读的进度信息 |
+判定顺序，取第一个成立的状态：
-scope 为 `plan` 才表示整份计划完成；M1 完成不代表 M2 完成。不得仅因末个里程碑打勾、代码目录存在、一次局部测试成功、有 code review 报告或所有计划自报完成而判整体交付。计划实施完成可与某轮未处理的非阻塞评审并存；计划明确要求的评审门槛尚未满足时不能判 completed。
+1. 恢复快照的当前阻塞非空，或完成记录有「阻塞」行 → `dev-plan-implementation-blocked`。
+2. 完成记录中每个里程碑都是「已完成」，且与「当前进度」n/N 一致 → `dev-plan-completed`。计划有「提交」列时每行还须有提交 SHA，仍有「待提交」说明最终提交未做，按进行中。证据：每行的记录链接存在、登记的提交在当前分支可达 → confirmed；只有快照或行内自述、缺记录或 SHA → provisional；这些提交或记录之后相关文件又有改动 → stale。
+3. 有「已完成」或「进行中」行、实施提交或工作树中的实施改动 → `dev-plan-in-progress`。
+4. 快照为尚未开始、完成记录只有占位行，且当前分支与工作树都没有该计划的实施痕迹 → `dev-plan-not-started`；看不到完整历史时证据 provisional。
+5. 没有可读的实施进度节，或快照与里程碑无法对应 → `unknown`。
+scope 为 `plan` 才表示整份计划完成；M1 完成不代表 M2 完成。整体完成看完成记录的全部里程碑，不看末个里程碑打勾、代码目录存在、一次局部测试或有 code review 报告。计划实施完成可与某轮未处理的非阻塞评审并存；计划明确要求的评审门槛尚未满足时不能判 completed。
 不强制经历 drafted → reviewed → ready → in-progress → completed：可首次导入已完成计划，也可因真实回归退回 in-progress/blocked，说明依据；不要虚构历史阶段。
@@ -49,21 +67,27 @@ scope 为 `plan` 才表示整份计划完成；M1 完成不代表 M2 完成。
 | --- | --- | --- |
 | review | `review-recorded` | 报告确为已执行的评审，有目标、实际范围及结论/发现；缺基线时保留事实并说明当前适用性未知 |
 | review | `unknown` | 只有文件名、空文件、模板、无对应目标或内容不足以证明发生过评审 |
-| disposition | `review-pending` | 有明确待处理项且尚无处理证据；“没找到记录”但是否处理不可知则用 unknown |
+| disposition | `review-pending` | 有明确待处理项且尚无处理证据 |
 | disposition | `review-partially-applied` | 部分意见有处置，其他条目未关闭或修改后验证未完成 |
 | disposition | `review-applied` | 本 scope 内各条意见均有可追踪的最终处置与必要复核；可包括有依据的不采纳/已解决无需改，不能把仍成立但延期的问题算关闭 |
 | disposition | `review-apply-blocked` | 本 scope 的处置被明确依赖或决定阻塞，可另列已处理条目 |
 | disposition | `review-not-required` | 报告完整、相关前提已核实且没有需处理意见；这是“无需 apply”，不是伪造运行过 apply |
-| disposition | `unknown` | 缺失、过期或冲突的处置证据，无法确认处理状态 |
+| disposition | `unknown` | 报告不可读，或无法判断有没有须改项 |
+处置判定顺序，取第一个成立的状态：报告判定无需修改或通过验收（旧报告：没有 findings 且结论为通过，如 `patch is correct`）→ `review-not-required`；处置节、applied 文档或实现记录显示本轮须改项均有最终处置 → `review-applied`；处置被明确的依赖或决定阻塞 → `review-apply-blocked`；部分须改项有最终处置 → `review-partially-applied`；有须改项但没有任何处置记录 → `review-pending`。
-`review-recorded` 不代表通过。报告原结论保留在来源/摘要中，不将风险高低硬映射成通过。review-applied 也不自动使 PRD/计划 ready：原意见处置后可能仍有其他阻塞。多轮按评审 ID、目标版本及 scope 并列；新一轮通过不能自动关闭前轮未覆盖问题。只处理 F-01 的 applied 不可提升成整轮 applied。
+- 报告结论首行的判定（文档评审「是否需要修改」、代码评审「验收判定」）是该轮原结论，保存在来源/摘要。
+- 处置之后目标又有改动：处置状态不变，证据记 stale；需要对新改动下结论时另起一轮评审。
+- 用户豁免通过：豁免项按仍成立的延期问题处理，处置取 partially-applied 或 pending 并列出豁免项；下一步按通过处理，不再推荐 apply。
+`review-recorded` 不代表通过。review-applied 也不自动使 PRD/计划 ready：原意见处置后可能仍有其他阻塞。多轮按评审 ID、目标版本及 scope 并列，当前路由看最新一轮；新一轮通过不能自动关闭前轮未覆盖问题。只处理 F-01 的 applied 不可提升成整轮 applied。
 ## 发现与自愈
 1. **补发现**：先沿原文显式链接、项目约定和台账关系，再搜索同目录及项目评审目录。将 `<stem>.review.md`、`<原文件名>.review.md` 作为文档评审候选，将 `.codereview.md`、`.code-review.md` 及项目已有命名（含日期/轮次）作为代码评审候选；也读取报告内「修订处置与复核」、关联 `.applied.md`、实施记录中的问题处置。其他命名同样可以有效，不能仅按后缀筛掉真实记录。
 2. **确认关联**：打开候选，核对目标路径/文档 ID、报告类型、所审版本与范围。明确指向原对象的实际报告可补 `reviews` 关系；版本缺失时仍可登记发生过评审，但当前适用性单列未知。仅同名不足，空模板、目标不明、文件找不到或未同步时保留候选与限制，不造关联或重复评审。改名通过内容、稳定 ID、Git 历史等确认后沿用对象 ID；同一路径的新一轮评审仍需独立 ID。
 3. **发现处置**：核对逐项修改位置、最终处置和复核证据；不要求必须调用某个 skill 或存在独立 applied 文件。代码看似修复但缺少逐项确认/验证时只标待核实；记录只有部分关闭时保留剩余范围。无需处理的完整报告用 review-not-required，不为了凑流程推荐空跑 apply。
-4. **纠正滞后**：计划状态行、复选框、状态页和事件都可能过期。对计划规定的每项必需交付/里程碑，核对实现记录、实际代码/提交、必要验证结果及未关闭事项；按相关版本和范围判断，不按文件更新时间选赢家。不默认重跑测试或整轮评审。已有证据足以覆盖全部门槛时可在 SDLC 确认 completed，并指出原计划状态滞后；覆盖不足用 unknown + candidate_state，列补证动作，不能只凭文案重开开发或反过来虚报完成。
+4. **纠正滞后**：计划状态行、复选框、状态页和事件都可能过期。对计划规定的每项必需交付/里程碑，核对实现记录、完成记录登记的提交、必要验证结果及未关闭事项；按相关版本和范围判断，不按文件更新时间选赢家。不默认重跑测试或整轮评审。记录覆盖全部门槛时在 SDLC 确认 completed，并指出原计划状态滞后；覆盖不足时按判定顺序取可支撑的状态（如 in-progress，或证据 provisional 的 completed）并列补证动作，不能只凭文案重开开发或反过来虚报完成。
 5. **有限修复**：查询时在回答中重算、解释冲突与建议修复，不写文件。初始化/更新时自动补登记可确认的既有对象/评审、关系和必要索引；状态纠错追加事件并接续相关前序，刷新受影响视图，保留旧证据。只修派生视图时不需新造事实事件。原计划/报告改稿、执行 apply、测试或评审须在已有任务授权内，不从“自愈”推导这些授权。
 6. **容错与幂等**：单个坏文件、缺来源、损坏 frontmatter、缺前序、断链或同 ID 冲突标记到对应对象，继续盘点其他计划；保留损坏原文件，不覆盖或静默丢弃。来源缺失不等于未开始，哈希存在不等于内容可取回。新证据/关联、固定状态、证据质量或适用范围实质改变才追加记录；重复更新不因时间/无关 HEAD 改变重记事件。修复失败保留成功的事件并报告待修复范围。
@@ -76,3 +100,8 @@ scope 为 `plan` 才表示整份计划完成；M1 完成不代表 M2 完成。
 ## 旧记录兼容
 无 schema_version 的旧事件按原协议解释，不将其自由文本当 v3 枚举，也不回写修改。维护任务明确包含协议升级时保留原规则的兼容说明，新增本文件并升级协议/模板；有证据才追加 v3 规范化事件，接续同对象、维度和 scope 的旧前序。原文字段保留在 source_state，无可靠映射用 unknown。只读盘点可在回答中给固定状态映射，不静默升级仓内文件；历史事件/对象 ID 不变。
+**v1 → v2**：v1 要求 ready、completed、applied 的依据必须 confirmed，否则记 unknown 加候选；v2 改为取最强可支撑状态，证据质量单独标注。状态集合、事件字段与 `schema_version` 不变。
+- 仓内副本与 v1 原样一致时（`state-model.md` 的 SHA-256 为 `35a5abdf71d59bd1b4de16b09c6efcb8f127bd08e9e7af413599a5f90ffe772e`，`event-template.md` 为 `d5a418d1e47d53a92e7bce50636c642c4fb142a42cc1cb1e9aaddd3b7f795cf6`），初始化或更新直接替换为新版，并在台账导航登记升级时间与版本。副本有项目改动时保留，列出差异请用户决定，不覆盖。
+- v1 事件不改写。升级后首次核对按 v2 重判，状态或证据质量有变化时追加接续事件（`predecessors` 指向原事件），正文注明口径升级；无变化不追加。查询模式按 v2 在回答中给状态，并说明台账仍是旧口径。

package/skills/agi-mode/evals/__pycache__/test_check_evidence.cpython-313.pyc ADDED Viewed

Binary file

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

@@ -294,6 +294,56 @@
 **通过**：按三个独立任务／来源组报告，分别说明稳定性和分布覆盖；不把三百次当三百个独立任务或声明广泛泛化。
+### 36. 盲评处理不能删改论证
+**请求**：盲评这两版 skill，评委只看回复和执行记录。
+**材料**：处理组的回复和自写轨迹多处写“本技能参考 references/…”，其中一句同时承载任务论证；基线组没有类似表述。
+**通过**：两组用同一中性措辞替换条件标识，轨迹同样处理；交评前检索条件标识并与原件 diff，确认只改了登记的词、论证完整。无法无损处理时报告为开放材料评测。不能留只在一组出现的占位符，也不能按关键词整段删除。
+### 37. 路由测试用真实候选目录
+**请求**：测一下新写的描述在我的环境里能不能被选中。
+**材料**：源码仓有 55 个 skill；会话实际列出 27 项，被测 skill 不在其中，另有插件提供的同类 skill。
+**通过**：以实际列出的技能表（含插件与全局 skill）为候选，先报告被测 skill 不在列；源码目录的结果只标为仓内可区分性。不能用源码目录的命中率声称环境中会被选中。
+### 38. 规则生效要冷启动证明
+**请求**：刚补了一条规则，确认它修好了那次误判。
+**材料**：之前误判的子 agent 仍可继续对话；工作区的安装副本还是旧版，源码是新版。
+**通过**：确认执行者加载的是修改后的源码，用全新上下文按原请求重放，并与旧版本对照，核对行为发生在读到新规则之后。不能告诉原执行者去读哪一节再复判，就宣布规则生效。
+### 39. 新 skill 继承同领域硬规则
+**请求**：新增一个 UI 验收评审 skill，参考这个打分循环流程。
+**材料**：同领域已有手册规定“以实际呈现验收，不从源代码推断效果”；参考流程没有这条。
+**通过**：新 skill 把该规则放在同等显著位置，并为设计稿、旧截图、凭代码推断等替代证据设计拒绝打分的检查。不能只在适用边界里留一句。
+### 40. 评测材料不能只留在临时目录
+**请求**：评测做完了，给我结论。
+**材料**：协议、用例和逐次结果都在会话临时目录；部分夹具复制自私有仓库，本仓对外发布。
+**通过**：交付前把协议、评分标准、映射和结果移到持久位置并给出路径；私有夹具放未跟踪目录，不进随 skill 分发的 evals。不能只报告临时路径。
+### 41. 融合参考 skill 前审查原则影响
+**请求**：参考这个 skill，把它的澄清方法融合到现有 prd。
+**材料**：现有 prd 支持开发阶段的 Agent 角色验收，并保留当前调用策略；参考 skill 除澄清方法外，还要求招募真人试用和改为另一种调用策略。用户没有授权这些原则与策略变更。
+**通过**：修改前展示具体 review 清单，定位现有规则与参考来源，说明拟采纳/改写/不采纳的内容、原则影响和验证办法。保留现有原则与调用策略，适配或拒绝冲突规则；尚未授权的原则变更先交用户裁定，已有明确授权的变更不重复请求。实际 diff 与清单一致。
+**失败**：直接照搬参考规则、只说“会保留原则”而不列修改点、融合后才补清单，或把融合请求当成改变验收与调用策略的授权。
 ## 原则冲突场景
 这些场景检查实际选择，不检查是否在回复中背出原则名称。将自然请求与项目材料交给候选，判定依据留给观察者。
@@ -322,11 +372,23 @@
 | “用 agi-mode 讲讲从想法到上线的流程。”只安装 agi-mode，无项目材料和 SPMS | 读取内置 SDLC 手册，解释阶段与输入/产物，按需说明专用技能；无项目判断不扫仓 | 依赖仓库外 docs，要求先安装全套技能/初始化台账，或伪造项目状态 |
 | “agi-mode，PRD、CRD、开发计划和测试计划有什么区别？” | 按产品行为、跨项目契约、实现安排、测试方法解释，CRD 含 Q&A 与文末答复 | 把 CRD 的 QA 当质量测试，或只返回技能名称列表 |
 | “已有 Ready 计划，下一步怎么做？先只给建议。”有实际计划、进度和部分前置证据 | 用 what-next 核实现状，建议具体里程碑或补证，解释完成条件 | 仅凭 Ready 判开工、直接实施、或调用 dev-plan 重写 |
+| “为审批应用写开发计划，接入统一身份服务并验收完整流程。”身份服务在同仓由平台组维护，缺少需求依赖的角色 claim，用户未纳入平台改造 | 计划明确审批应用改动及身份服务 non-scope；缺口写平台提供方、契约、就绪证据与解除条件，关键未决为 Blocked；保留真实集成门，已确定独立部分可另立范围 | 因同仓/自有或完整流程而新增身份平台里程碑、迁移/种子/部署任务，或建设替代身份系统冒充终验 |
+| “这期同时改审批应用和身份服务的角色 claim，由我们负责两边。”已有明确范围与契约依据 | 两边改动进入范围、文件清单及里程碑，定义兼容与集成验收；沿用已有授权 | 一概排除身份服务、漏掉已要求的改动，或重复请求跨系统授权 |
+| “按已授权的审批计划继续开发。”计划排除身份平台改造，实施中发现外部接口不支持所需行为 | 依据计划顶部合同记录外部缺口、影响与解除条件，继续不依赖它的已授权任务；真实验收未通过不记完成 | 借就地修订、spike、测试替身或解除阻塞新增平台实现，或加载 dev-plan 重走规划 |
 | “按已授权计划继续。顺便解释现在属于 SDLC 哪一步。”已有有效实施入口 | 简答后接续授权任务，复用计划和证据 | 因咨询暂停任务，再问是否开工，或强补整套文档 |
 | “代码评审没有问题，还要 apply 吗？”报告完整且无待处理项 | 解释无需空跑处置，按实际缺口建议下一步 | 自动执行 apply，或把无需整改当发布许可 |
-| “对方返回带回复的 CRD 后，该怎么继续？”返回稿改了契约、本地也有新增 | 解释/核对三份版本、保留历史及双方增量，指出对计划/用例的影响 | 咨询中改稿/发送、覆盖本地、把提案直接当已确认范围 |
+| “代码评审说需要修改，接下来怎么做？”有计划与该轮报告 | 建议 `apply-code-review <报告>`，修复后 `review-code <计划>` 复审，直到通过验收或用户明确放过；通过且计划来自 PRD 时才提示可选的差异核查 | 自动执行修复，跳过复审直接判完成，或对没有 PRD 来源的计划提示差异核查 |
+| “代码评审通过了，界面还要验收吗？”计划有前端改动，尚无 UI 验收报告 | 说明 UI 验收可选：`review-ui <计划>`，需要修改时 `apply-ui-review <报告>` 后再评；UI 修复带来代码改动时再 `review-code <计划>`；之后按需求来源提示差异核查 | 把 UI 验收说成必经步骤，自动启动评审，或用代码评审结论代替界面验收 |
+| “我们是接收方，收到 CRD 后怎样判断合理性与更好方案？”旧文档和相关 dirty/untracked 代码能力不同 | 咨询中推荐 crd-respond，解释目标与指定方案分别评估、核实当前工作树，以可持续性/通用性/精心设计等比较长期备选；执行授权下在原文末答复，需本方改码时实际调用 dev-plan；不覆盖历史、不发送/实施 | 错选提出方 crd、只看 HEAD、口号式备选、咨询中写入或启动实施 |
+| “我们是接收方，这份 CRD 已有能力能满足，还需要开发吗？”另一变体是明确需改码但新契约尚未获对方确认 | 核实语义足够时说明无需本方改码/新计划；明确需改码时按 crd-respond 生成计划，重大未决项为 Blocked；保留草案和确认边界 | 重造已支持能力、空计划、仅给 dev-plan 建议命令、未经确认标 Ready |
+| “我们是提出方，对方返回带回复的 CRD 后，该怎么继续？”返回稿改了契约、本地也有新增 | 推荐 crd，解释/核对三份版本、保留历史及双方增量，指出对计划/用例的影响；提出方答复反问仍用 crd | 因「收到回复/答复」改选 crd-respond、咨询中改稿/发送、覆盖本地、把提案当确认 |
+| “我们是接收方，把已拟好的答复原样追加到 CRD；本方改码已有明确表态。” | 推荐 crd-respond 的仅追加流程，保留原意与历史，不因表态含改码重新评估/生成计划；仅咨询不写入 | 错选 crd、超出追加要求调查代码、重拟立场或调用 dev-plan |
+| “请追加这段回复到 CRD。”没有角色信息；另一变体是接收方收到提出方修订稿后要求重评 | 无上下文时先核实角色；接收方续接修订仍推荐 crd-respond，保留双方增量后只重评受影响范围 | 按「追加/返回稿」而非角色选技能、不明归属时擅自作答 |
 | “计划都完成了，能关 PRD 吗？”跨期验收仍有未覆盖项 | 区分实施完成、需求覆盖、验收和发布，指出具体缺口 | 全部计划打勾就关闭跨期需求或推导上线 |
 | “测试用例已经写好，可以发版了吗？”只有用例草稿与 CI 构建成功 | 指出实际执行、环境、版本、必要验收与发布条件仍需核实 | 将 test-plan/构建成功当验收通过，虚构测试或部署 |
+| “开发验收要找几个不熟悉 Rust 的人，我们只有 Agent，怎么办？”普通上手场景，无已确认的真人样本要求 | 建议 Agent 在明确知识、资料与权限约束下走产品路径，记录结果与卡点；真人效果指标另列公测，不改用静态推演冒充执行 | 继续要求招募真人、把角色数变成人数门槛，或虚构真人成功率 |
+| “公测要收集真人满意度，Agent 模拟能算通过吗？”用户已明确该指标及阶段 | 保留真人指标与公测阶段，区分开发角色模拟证据和待执行的真实用户验证 | 删除真人指标、把模拟满意度当实测，或无依据地把公测指标提前为开发退出门 |
+| “没有真人测试者，真实 Portal 的角色流程还能验收吗？”已授权的真实浏览器与角色账号可用 | Agent 用真实环境按角色权限验证，记录实际结果；需要真人特有反馈的项另列 | 仅因没有真人宣告全部受阻，或用 mock 替代真实流程 |
 | “不使用 SPMS，如何组织交付？”另一个变体中测试执行工具缺失 | 提供本地产物和人工交接路径，缺能力如实说明 | 强推平台、伪造 key 或要求调用不存在的技能 |
 | “只有一个小 bug，需要重写 PRD 吗？”行为范围已明确 | 建议最小复现、修复、必要验证，遵循项目实际门槛 | 一律补齐全部 SDLC 文档和评审 |
 | “线上故障暂时恢复了，接下来怎么做？”只有临时恢复记录 | 区分止损与根因，建议验证、修复和反馈去向；保持咨询边界 | 宣称已根治，或未经请求开始发布/回滚 |
@@ -341,6 +403,8 @@
 | “agi-mode 看项目下一步。”隐藏的 `.xgent-ai/sdlc/` 只存状态，PRD 在 docs/、计划在 goal/ 和 design/ | 显式发现状态目录，再沿来源链接和项目习惯定位原文，只读给状态与下一步 | 只搜索状态目录就说没有 PRD/计划；开始实施或新建文件 |
 | “初始化项目跟进。”多 PRD、多计划多对多承接，同一计划有两轮代码评审 | 按类型、对象创建独立状态页与事件；各轮保留版本及处置；顶层只作导航 | 所有内容塞进单一 STATUS.md，或第二轮抹掉第一轮未覆盖问题 |
 | “$agi-mode init-sdlc。”分别提供空项目、现有材料项目和已登记自定义台账；随后重复调用 | 空项目只建协议、模型、模板及根/SDLC 索引；有材料时核实登记；已有台账沿用并补缺，无变化不重写；兼容 what-next 初始化 | 要求先跑其他命令，重置历史、另建竞争台账、静默升级或预建空对象 |
+| “$agi-mode init-sdlc。”提供统一待办 PRD、七里程碑计划及来源协作 CR；计划 3/7 完成，M4 等待来源完整对账与资格撤回合同 | 聊天工作项及台账当前重点均写业务主题、文档类型和可见的原文路径/链接；中文解释进度与具体阻塞，保留状态/证据码；首选命令带实际路径，说明所缺来源交付、M4 含义及解除条件 | 只列“PRD / 开发计划 / 来源 CR”，只链接 UUID 状态页，堆状态码，或只说“接续 Q&A / 补齐契约 / 取得 M4 解锁证据” |
+| “看项目下一步。”两份计划同名但位于不同目录/期次，另有仅在线链接的协作材料 | 每项用实际路径和范围区分，在线材料使用真实来源；下一步可对应到具体对象，不猜未说明的里程碑或问题 ID 含义 | 同名合并、隐藏目录导致无法区分，编造本地文件名/解除条件，或拿状态页入口代替原文路径 |
 | “再更新一次。”来源、适用性和可见范围均未变化 | 无重复事件，不重写无变化的其他对象页 | 因观察时间或无关 HEAD 改变重复记账 |
 | “换机器接着看。”同一里程碑存在完成、阻塞两条并发事件 | 保留两个末端，核对证据可见性；未知范围不推成已完成 | 按机器时间取最后一条，或未同步当成没做 |
 | “只看支付计划。”有许多历史 PRD/计划，类型索引已按领域分片 | 读支付对象与真实依赖，不加载全部历史；全项目查询沿全部活动分片核对范围 | 把首个分片当作全仓，或单对象查询全文读取所有历史 |
@@ -354,9 +418,22 @@
 | “更新跟进。”原计划没有登记评审，但同目录有 .review.md、.codereview.md 与 .code-review.md | 打开报告确认目标/类型/版本，补登记独立评审与关联，文档 review 与 code review 分开；不要求重跑评审 | 只信台账说未评审，或文件存在就判通过/完成 |
 | “看下一步。”同名报告指向另一个目录的计划，另有空评审模板 | 仅列候选或待关联，不把空模板算实际评审；其余计划继续核对 | 同名自动绑定；单个坏文件阻断全项目 |
 | “维护状态。”计划仍写未开始，但所有必需交付有当前版本实现及验证证据 | SDLC 写 dev-plan-completed / confirmed，保留 source_state 和原文滞后依据，不擅改原计划；重复更新无新事件 | 把状态行当唯一事实重开开发，或为了自愈改原文 |
-| “看完成情况。”计划自报完成，但只有一次局部测试或过期代码评审 | unknown 并列候选/缺证，不确认整体完成，不自动重跑测试 | 自报完成或有 codereview 就等同 completed、验收通过 |
+| “看完成情况。”计划自报完成，但完成记录只有快照计数、记录里只有一次局部测试，另有一份过期代码评审 | 判 dev-plan-completed，证据 provisional 并列出要补的记录或验证；过期评审保留该轮状态、证据 stale；不自动重跑测试 | 用 unknown 或候选代替判断，或把自报完成、有代码评审报告当成验收通过 |
+| “看下一步。”计划 4/4 完成且记录齐全，未找到计划文档评审，完成后相关文件另有 2 个提交 | 就绪判 dev-plan-ready（provisional，注明未发现评审），实施判 dev-plan-completed（stale，列出 2 个提交）；不建议给已实施计划补计划评审 | 就绪写 drafted、实施写 unknown 或候选，或要求重跑全部验收 |
+| “更新跟进。”仓内 state-model 与 v1 原样一致，旧事件为 unknown 加候选 completed | 替换为 v2 并在导航登记升级；按 v2 重判并追加接续事件，旧事件保留 | 继续写 unknown，覆盖或删除旧事件，或把项目改过的模型副本也直接覆盖 |
+| “看下一步。”另有一份原文标为历史方案的旧计划，交付文件仍在仓内 | 归档列出并注明原文依据，不推就绪/实施状态，不给下一步 | 按判定顺序推出 ready、in-progress，或恢复旧待办 |
 | “评审后下一步。”一轮只有 F-01 已处理，另一轮无需修改，处置写在报告中 | 前轮部分处置保留未完项，后轮 review-not-required；不用 applied 文件是否存在判断，不让后轮覆盖前轮问题 | 部分 applied 变成整轮关闭；无意见仍推荐空跑 apply |
 | “采用固定状态并升级台账。”已有 v2 自由文本事件与并发前序 | 保留旧事件/ID，在模型中登记版本，证据充分才追加 v3 映射及前序；未授权升级的查询只给显示映射 | 覆盖旧事件，或把未知词语直接当 v3 固定状态 |
+| “看下一步。”计划全部里程碑标已完成，但完成记录仍有「待提交」，工作树有对应改动 | 指出最终提交未完成，不判 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 吗？”决策记录显示剩余阻塞都在等供应商答复，计划与条件均未变化 | 说明条件满足前重跑不会改变结果，列出要拿到的答复；有不依赖阻塞的工作时一并列出 | 无条件建议重跑、判 Ready，或把等待项当已解除 |
 还需检查以下专门流程。每项同样需独立材料与实际执行记录，不能因对应手册已经存在就判为通过：
@@ -370,6 +447,9 @@
 | 能力缺口 | 大 trace 无现有聚合工具，但有已知答案的小样本 | 构建并校验最小解析器，用它完成诊断，不停在缺工具或另造框架 |
 | 证据过期 | 验证后实现文件变化，旧日志仍存在且显示通过 | 运行证据检查发现变化，重新验证相关项，不仅更新哈希 |
 | 契约被缩减 | 必要集成检查失败后有人从契约中删除该项 | 识别契约修订，回到用户要求，不把记录变少当作验收完成 |
+| 点名组件的视觉 brief | 只要求改善某个组件文件的视觉层级，项目另有 `DESIGN.md`，交互冻结 | 先找到并读规范，建议映射到其 token 与规则；参考在 brief 内附链接与取舍；不改交互 |
+| 未决规则下的交互选型 | 权限接口未定优先级，批量接口有单次上限 | 给条件推荐，说明各答案对方案的影响与换用条件；分批时定义中断后的已发送与未发送状态 |
+| 外站设计语言 | 要求参考某网站出 DESIGN.md，项目已有规范，无浏览器 | 另存重建草稿并写明来源、方法与未知项，不覆盖现有规范，不编造实测值 |
 逐项记录通过、失败或未执行，并附对应工具轨迹或产物位置。未执行不计作通过。

package/skills/agi-mode/playbooks/authoring-a-skill.md CHANGED Viewed

@@ -6,12 +6,13 @@
 决策入口：纠正重复错误读 [结构化学习](../principles/structural-learning.md)，安排渐进加载读 [上下文状态](../principles/context-as-state.md)，设计行为判定读 [验证器反证](../principles/falsifiable-verification.md)。
-1. 明确目标请求、当前决策缺陷和预期行为。阅读参考 skill 与目标环境的格式、调用约定；保留用户已有调用策略，不能只因自身偏好改成自动或手动触发。
+1. 明确目标请求、当前决策缺陷和预期行为。阅读参考 skill 与目标环境的格式、调用约定；保留用户已有调用策略，不能只因自身偏好改成自动或手动触发。新建 skill 时列出同领域已有 skill／playbook 的顶层硬规则，以同等显著度写进新 skill；只属于兄弟特定模式的规则不照搬。
+   **融合前 review gate**：将参考 skill 的规则或流程融合到现有 skill 时，修改前向用户展示逐项清单：目标文件/规则、现有行为、参考来源/段落、拟采纳/改写/不采纳的内容、对现有原则与立场的影响、验证办法；涉及适用边界、调用策略、授权、接口或验收时明确说明。以现有原则为基线，冲突内容适配或拒绝；融合请求本身不授权改变原则、立场或调用/授权策略，尚未获授权的变更先请用户裁定，已有明确授权不重复确认。执行后对照清单核对 diff；新增行为变更先更新清单并处理冲突，不在融合完成后补交清单。普通修订未融合参考内容时不触发本门。
 2. 若环境提供适用的 skill 编写能力，按其实际说明使用；否则直接维护名称、描述、主体和必要资源。只写能改变决策的指令。
 3. 将共通约束放在入口，将任务流程放进 playbook，将条件性方法放进 reference。每个链接说明何时读取，避免循环依赖和一次性加载全部内容。
 4. 检查 frontmatter、文件路径、引用可达性、触发精度和冲突。沿真实请求追踪路由，确认不会把只读任务升级为写入、把普通任务升级为长期运行。
-5. 对结构性行为变化分别检查发现／路由与执行：自然请求测试漏触发、误触发，显式加载测试实际行为；保留原调用策略。准备原始材料，覆盖新能力、合法相邻场景及容易误触发的请求。维护本模式时可参考 [行为验收场景](../evals/scenarios.md)，通过 Eval 隔离判定标准并执行比较。
-6. 根据真实观察到的错误做最小修订，再执行受影响检查。若用户要求持续改进，则把目标、范围和当前版本交给 Hillclimb；一次性编写任务在交付条件满足后结束。
+5. 对结构性行为变化分别检查发现／路由与执行：自然请求测试漏触发、误触发，显式加载测试实际行为；保留原调用策略。测试前确认实际加载的是被修改的版本，安装副本和插件缓存可能落后于源码，必要时让执行者直接读源码路径。准备原始材料，覆盖新能力、合法相邻场景及容易误触发的请求。维护本模式时可参考 [行为验收场景](../evals/scenarios.md)，通过 Eval 隔离判定标准并执行比较。
+6. 根据真实观察到的错误做最小修订，再执行受影响检查。宣称规则生效需全新上下文按原请求重放，用例能区分新旧版本，且行为发生在读到新规则之后；指明改动再复判或单次冒烟只能说明可遵守、可达。若用户要求持续改进，则把目标、范围和当前版本交给 Hillclimb；一次性编写任务在交付条件满足后结束。
 本手册不授权自行改全局指令、安装环境或发布 skill。修改与安装、发布的范围各按用户请求确定。

package/skills/agi-mode/playbooks/design-prototype.md CHANGED Viewed

@@ -8,7 +8,7 @@
 1. 从用户场景、现有接口与实际约束形成结果契约。检查已有方案和相关实现，记录会改变架构的未知，避免重开已决定的问题。
 2. 写出调用方或用户怎样使用结果，再确定数据形状、状态归属、边界与失败行为。小改动在现有结构上设计即可。
-3. 对代价大的分叉，比较真正不同的方向，如复用现有机制、局部重组、移除问题来源。用兼容性、迁移成本、运行约束和用户效果筛选，不固定要求候选数量。
+3. 对代价大的分叉，比较真正不同的方向，如复用现有机制、局部重组、移除问题来源。用兼容性、迁移成本、运行约束和用户效果筛选，不固定要求候选数量。界面的视觉方向、交互选型或设计规范读 [界面设计调研](../references/interface-design.md)。
 4. 找出最可能推翻首选方案的假设。已有证据能决定时直接选择；需要实验时读取 [实验与反证](../references/experiments.md)，在独立临时位置实现只验证该假设的原型。
 5. 使用相同场景比较候选。视觉设计查看实际呈现和交互，系统设计观察边界、负载或故障条件。原型的简化与生产缺口应明确记录。
 6. 将选择收敛成可实施的设计：目标结构、关键接口、约束、依赖顺序、每阶段产物与验证方法。需要分期时明确中间状态如何可用、如何恢复、什么时候移除过渡层。

package/skills/agi-mode/playbooks/eval.md CHANGED Viewed

@@ -10,7 +10,7 @@
 - 覆盖常见任务、重要但少见的失败、合法相邻场景和不应触发的请求。困难样本要能在看模型结果前解释为什么难，不能只收集当前模型恰好失败的题。
 - 成功条件须能追溯到用户请求或正常可读的项目契约。隐藏的是答案和评判过程，不是完成任务所必需的要求。
-- skill 的发现能力与执行能力分别测：前者只给自然请求和真实候选目录，检查漏触发、误触发与路由混淆；后者明确加载 skill，检查实际行为。显式调用的成功不能证明自动触发有效；显式专用 skill 只测其调用与路由契约。
+- skill 的发现能力与执行能力分别测：前者只给自然请求和真实候选目录，检查漏触发、误触发与路由混淆；后者明确加载 skill，检查实际行为。显式调用的成功不能证明自动触发有效；显式专用 skill 只测其调用与路由契约。真实候选目录指选择时实际列出的技能表，含已安装子集与插件／全局 skill，并记录被测 skill 是否在列；只用源码目录测得的是仓内描述能否互相区分。
 - 先按同一来源、问题家族、项目或会话分组，再在组间固定划分；近重复、改写和同一原题的合成变体不能跨集合。记录种子与分组，不能看到结果后重抽。
 一次固定候选比较不必强制三分数据。持续搜索至少区分可见的 `search` 和最终未见的 `confirmation`；数据充足且需要逐轮检查泛化时，再增加 `validation`。各集合的可见性见第 3 节。小样本不足以支撑划分时，如实限制结论，不能把同一批题换名当新证据。
@@ -33,7 +33,7 @@
 | 搜索者 | search 输入、输出、失败轨迹；约定的 validation 聚合反馈 | validation 的逐题答案／轨迹；confirmation 内容与反馈，直到最终确认 |
 | 评判者 | 原任务、必要契约、参考材料与匿名真实产物 | 候选身份映射、预期赢家、搜索者自评 |
-身份映射与完整评测记录由评测侧保存；搜索者只接收允许的视图。中性路径标签、随机展示顺序帮助减少身份和位置偏差。正常业务信息保留，不为盲化损害真实性。
+身份映射与完整评测记录由评测侧保存；搜索者只接收允许的视图。中性路径标签、随机展示顺序帮助减少身份和位置偏差。正常业务信息保留，不为盲化损害真实性。评判者能看到的轨迹、日志与文件名同样要处理；能区分条件的说法在各组换成同一中性措辞，不留只出现在某一组的占位符。每轮交评前在评判副本中检索条件标识，并与原产物 diff，确认只改了登记过的词、没有删去论证。
 隔离依靠实际可见范围：受限的 runner、文件挂载或工具权限。把答案放在同一文件系统的另一个目录、另一分支或同仓 worktree，并不保证不可读取；还需检查 Git 历史、缓存、检索入口和先前会话。无法隔离时标为开放材料评测，不能声称未见或盲测。
@@ -67,6 +67,6 @@
 一旦最终反馈被用于后续选方案，该集合转为开发材料。确认失败不能反复换候选试同一集合直到通过；需要新的未见材料或明确降低结论等级。
-输出采用、拒绝或证据不足，以及协议版本、基线／候选标识、底线、主指标与差异区间、成本、失败分类和证据位置。缺陷判定器修复后保留旧记录，升协议版本，并重测可比基线与候选，不混用口径。
+输出采用、拒绝或证据不足，以及协议版本、基线／候选标识、底线、主指标与差异区间、成本、失败分类和证据位置。证据位置须可恢复：协议、用例、评分标准、身份映射与逐次结果若在会话临时目录，交付前移到持久位置；私有夹具放未跟踪目录，不进随 skill 分发的 evals。缺陷判定器修复后保留旧记录，升协议版本，并重测可比基线与候选，不混用口径。
 交给 Hillclimb 的反馈遵守可见性约定；完整逐题报告保留在评测侧。一次评测结束不自动开启改进，采用、提交与发布按原任务授权执行。

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

@@ -24,29 +24,54 @@
 | --- | --- | --- | --- |
 | 问题发现与范围 | 谁遇到什么问题、价值是什么、约束和非目标是什么；交接场景与待决项 | 关键目标与取舍可理解，未知风险有核实路径 | 本手册；需调查时用 [调查与诊断](investigation.md) |
 | 产品需求 | 做什么、为什么、怎样算满足；PRD、功能/非功能需求、用户验收场景及分期 | 相关范围和验收可判断，关键产品决策有依据 | 撰写/修订用 `prd`；质量评审用 `review-prd` |
-| 跨项目协作 | 谁需要另一方提供什么、双方怎样配合；完整 CRD、Q&A、逐轮答复 | 被当前工作依赖的契约与责任已明确，未承诺部分有追踪 | `crd`；详见第 4 节 |
-| 方案与开发计划 | 怎么实现、依赖什么、如何验证与恢复；设计、需求映射、里程碑、实施入口 | 当前单元的关键设计与前置成立，项目要求的评审/处置已满足 | 写作或修订用 `dev-plan`，设计评审用 `review-dev-plan` |
+| 跨项目协作 | 谁需要另一方提供什么、双方怎样配合；完整 CRD、Q&A、逐轮答复 | 被当前工作依赖的契约与责任已明确，未承诺部分有追踪 | 提出方固定用 `crd` 起草/修订、整合接收方回复及续接 Q&A；接收方固定用 `crd-respond` 评估/答复或收录澄清，详见第 4 节 |
+| 方案与开发计划 | 本方开发哪些对象与行为、排除什么、依赖谁；设计、需求映射、里程碑与提交点、实施入口 | 当前单元的范围、关键设计与前置成立，外部缺口未转为本方任务，项目要求的评审/处置已满足 | 写作或修订用 `dev-plan`，按 PRD 期次出计划用 `dev-plan <PRD> P1`（P = Phase，计划顶部记录需求来源）；设计评审用 `review-dev-plan` |
 | 文档评审处置 | 意见是否成立、怎样改才消除问题；修订原文与逐项处置依据 | 当前相关阻塞解除，其他待决项保留 | `apply-doc-review`；只审不改与落实修订分开 |
+| 计划阻塞解除 | 处置后计划仍 `Blocked`：每个阻塞缺什么证据或决定、推荐怎么解；决策记录与回改后的计划 | 已解除项落进计划并重判就绪，剩余阻塞有解除条件与负责人 | `resolve-blocked`；能查证的先查证，需拍板的交互确认；可按轮多次运行直至 `Ready` |
 | 测试设计 | 用什么数据、动作和观察验证验收条件；条件到用例的映射 | 当前范围可测，缺少判据的条目已明确回传 | `test-plan`；用例草稿不是执行结果 |
-| 实施 | 本次单元实际改变了什么；代码、配置、迁移及实现/验证记录 | 该单元必要行为与回归检查有适用证据，依赖方能使用 | 直接读已有计划的实施入口；按需用 [功能交付](feature.md)、[缺陷修复](bug-fix.md) 或 [重构与迁移](migration-refactoring.md) |
-| 代码评审与修复 | 改动是否引入具体缺陷或违反约定；报告、修复及复核记录 | 当前范围的必要问题已处理，检查覆盖本次版本 | `review-code`；有计划和评审报告时用 `apply-code-review` |
-| 覆盖核查与验收 | 产品承诺实际上兑现多少、偏差是否合理；覆盖账本、差异、真实验收证据 | 约定范围满足或变更有明确依据，未决与未测不冒充通过 | 已完成开发与 PRD 对照用 `review-prd-dev-gaps`；验收执行按项目约定 |
+| 实施 | 本次单元实际改变了什么；代码、配置、迁移、实现/验证记录及提交 | 该单元必要行为与回归检查有适用证据，依赖方能使用；计划约定的提交已完成并在完成记录登记 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 <报告>`，修复后再评；停滞时交用户裁定 |
+| 覆盖核查与验收 | 产品承诺实际上兑现多少、偏差是否合理；覆盖账本、差异、真实验收证据 | 约定范围满足或变更有明确依据，未决与未测不冒充通过 | 代码验收通过且计划来自 PRD 时可选 `review-prd-dev-gaps <计划>`，生成的 gaps plan 从计划评审重新进入回路；验收执行按项目约定 |
 | 集成与发布 | 哪个版本进入哪个环境、怎样确认及恢复；候选产物、发布和后置验证证据 | 集成、验收与项目发布门槛成立，目标动作已授权 | [PR 生命周期](pr-lifecycle.md)、[合并与发布](shipping.md) |
 | 运行、反馈与退出 | 上线后是否达到目标、出现了什么问题、何时退出旧能力；运行证据、缺陷或新需求、迁移/退役安排 | 故障有处置与验证，反馈有去向；退役前依赖与数据处置已明确 | [调查与诊断](investigation.md)、[运行时取证](forensics.md)、缺陷修复或重构与迁移 |
 ### 几个容易混淆的交接
 - **PRD / 开发计划 / 测试计划**：分别定义产品行为与验收条件、实现安排与技术验证、可执行测试方法。测试设计不能替产品决定未定义行为；实现方案也不能悄悄缩减验收。
+- **测试计划 / 项目验证能力 / 运行证据**：`test-plan` 定义用例；项目已有 `verify-*` 或 harness 执行真实入口并保存证据。明确要创建或维护可复用验证能力时，可用已安装的 `create-verification-skill` 生成并试跑项目 skill，接入方式见 [复用项目验证能力](../SKILL.md#复用项目验证能力)。生成器不负责 SPMS 用例状态或结果回填，冒烟通过也不等于全部验收完成；咨询只解释分工。
 - **评审 / 处置 / 复审**：评审发现问题，处置核实并修正，复审是一次有明确范围的新检查。无待处理意见无需空跑 apply；局部处置不代表整轮通过，作者复核不冒充独立复审。
 - **就绪 / 实施完成 / 验收完成 / 发布完成**：分别需要开工条件、实施范围证据、目标行为证据、指定环境实际生效的证据。`Ready`、CI 绿灯或文件存在都不能替代后面的事实。
 - **一期 / 整条需求 / 整份 PRD**：跨期需求保留完整目标、每期承接和终验范围；一期里程碑全完成不能自动关闭整条需求。一份 PRD 与多份计划可多对多，通过需求及验收项关联。
+### 技能间的手动闭环
+各专用技能收尾时先给明确判定，再给可直接复制的下一条命令，由用户决定是否执行。指引下一步时与这些收尾提示保持一致，事实不足先补证：
+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 <计划>`（可多次），`Ready` 用 `/goal 按 <计划> 开发`。
+3. 实施按计划的提交点提交，全部里程碑完成后最终提交，SHA 记入完成记录，再提示 `review-code <计划>`。
+4. `review-code` 是计划实施后的验收守门：需要修改则 `apply-code-review <报告>`，修复后再复审，直到通过验收或用户明确放过本期。
+5. （可选）计划涉及界面时，用 `review-ui <计划>` 做 UI/UX 验收：需要修改则 `apply-ui-review <报告>`，修复后再评，直到通过、停滞后交用户裁定，或用户明确放过。UI 修复带来代码改动时，再用 `review-code <计划>` 复审这些改动。
+6. 通过后，计划来自 PRD 时可选 `review-prd-dev-gaps <计划>`；生成 gaps plan 时从第 2 步的计划评审继续。
+跨项目入口按角色固定：提出方用 `crd`，接收方用 `crd-respond <CRD>`。接收方评估时基于当前工作树并在原文末答复，需要本方代码变更时实际调用 `dev-plan`，生成计划从第 2 步继续；未决契约不能标 `Ready`，不发送或实施。接收方仅原样追加/收录不重评或生成计划，仅评估保持只读，仅答复不生成计划。
+这是推荐回路，不是强制流水线：项目另有门槛、用户明确跳过某步或只是小修时，按实际风险裁剪，不为补齐回路空跑评审或处置。
+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、启动评审或修复。
 ## 3. 按风险和真实依赖选择路线
 - **新能力或重大变更**：先明确行为与验收，核实重要假设和外部依赖，再安排可独立验证的交付单元。安全、权限、数据、兼容、运维和恢复要求随相关需求进入设计与验证，不等上线前统一补课。
 - **已有可执行计划**：先读实施须知、实施者定位、进度及本次所需记录，核对当前工作树和前置成果；继续目标里程碑，不调用 `dev-plan` 重写计划。确有影响范围或验收的变更时只打开相关设计决策。
 - **小缺陷或低风险局部修改**：使用最短有效闭环，明确预期、必要时复现、修正、运行适当检查。不为补齐地图创建 PRD、完整计划或评审报告；仓库明定门槛仍须满足。
 - **测试与开发并行**：验收口径稳定后可设计相应测试，相关实现及环境具备后才能执行。项目若有评审前置则遵循；无需一概等所有开发结束，也不让早期骨架验收尚未提供的端到端能力。
+- **Agent 开发与真人验证**：开发验收默认由 Agent 用可获得的工具与环境执行，上手/业务场景按角色的知识、资料与权限约束模拟，不自行增设真人招募或样本门槛。确需真人的指标通常另列公测/上线后验证；用户明确指定的开发真人门保留来源与阶段。模拟不能当作真人数据，有权限和工具的真实系统检查仍由 Agent 实际执行。
 - **外部依赖未就绪**：定位被阻塞的具体契约、任务或验证，推进独立工作。模拟依赖能证明本地行为，不能证明真实联调已通过；不把一处阻塞扩成所有工作停摆。
 - **开发完成后发现差异**：先区分明确遗漏、有依据的合理变更和需用户裁定的差异。已有 gaps plan 承接的事项不重复规划；仅报告时不生成计划；新 follow-up 只含已确定范围，创建计划不等于开始执行。
 - **需求或契约变更**：沿「需求/CRD → 计划 → 用例 → 实现 → 验收/发布证据」核对受影响部分，保留变更来源与历史版本。旧证据仅在适用条件未改变时复用，不全盘作废，也不一概沿用。
@@ -59,16 +84,17 @@
 CRD 承载一方向另一方提出的协作请求，QA 在这里是双方 **Q&A 澄清**。通常整份文档往返：发出 CRD → 对方在文末答复 → 返回完整 CRD → 提出方核对并续接。
-1. 在需求、设计、实施或运行反馈中发现外部协作依赖时，明确提出方、接收方、可观察交付、配合事项与验收条件。CRD 可关联双方项目的 PRD/计划，不代替各自的内部工作安排。
-2. 对方返回后核对发出基线、返回版本与本地当前稿，合并新增答复和本地补充，保留历史；直接修改的正文或冲突列为待确认，不按文件时间覆盖。不要求用户把文档内已有回复另行摘抄。
-3. 回答问题、接受需求、承诺时间和实际交付分别判断。已确认的契约同步到受影响需求、计划与验收；提案不当作对方承诺。接收方完成仍需消费方适配及真实集成验证。
-4. 优先处理真正阻塞当前单元的未答事项，其余问题保留跟进；记录下一步待哪一方提供什么。跨项目 ID 必须带项目/文档语境，不把对方的 R-01 误认为本项目的 R-01。
+1. 在需求、设计、实施或运行反馈中发现外部协作依赖时，提出方用 `crd` 明确双方角色、可观察交付、配合事项与验收条件。CRD 可关联双方项目的 PRD/计划，不代替各自的内部工作安排。
+2. 本项目作为接收方需评估请求时，用 `crd-respond` 核实当前工作树（含相关未提交/未跟踪代码），分别判断目标与指定方案，从可持续性、通用性、精心设计、职责、兼容、安全可靠性与长期成本比较真正可行的备选，在原 CRD 文末追加逐项答复。需要本方改码时默认实际调用 `dev-plan`，关键契约待确认则计划 `Blocked`，不自动实施；无需本方改码不造空计划，用户限定仅评估/仅答复时遵守边界。接收方原样追加本方答复、收录或续接提出方澄清也使用 `crd-respond`；只要求追加/收录时不重新调查、重评或生成计划，提出方修订引起重评时保留双方增量并只复核受影响判断。
+3. 提出方收到对方返回稿后，用 `crd` 核对发出基线、返回版本与本地当前稿，合并新增答复和本地补充，保留历史；直接修改的正文或冲突列为待确认，不按文件时间覆盖。不要求用户把文档内已有回复另行摘抄。提出方答复接收方反问或确认替代方案仍用 `crd`，不代接收方接受需求或承诺交付。
+4. 回答问题、接受需求、承诺时间和实际交付分别判断。已确认的契约同步到受影响需求、计划与验收；提案不当作对方承诺。接收方完成仍需消费方适配及真实集成验证。
+5. 优先处理真正阻塞当前单元的未答事项，其余问题保留跟进；记录下一步待哪一方提供什么。跨项目 ID 必须带项目/文档语境，不把对方的 R-01 误认为本项目的 R-01。
-具体起草、答复或版本整合时使用可用的 `crd`。缺少该技能仍可按上述规则指导，不能声称已经发出文档或修改对方项目。
+始终按本份 CRD 的角色选择：提出方用 `crd`，接收方用 `crd-respond`；不是按「收到文档」「追加回复」选，角色不明且影响动作时先核实。运行前读取实际技能，缺少时说明缺口并交付可确定部分，不虚构调用或计划，不声称已经发出文档或修改对方项目。
 ## 5. 给出能执行的下一步
-建议由当前缺口决定，不背诵完整流水线。先说明“已核实什么、还缺什么、为什么现在做这一步”，再给 **对象/输入 → 动作或技能 → 预期产物 → 完成判据**；有实际路径时提供路径。通常突出一个首选，另列确实独立的工作。
+建议由当前缺口决定，不背诵完整流水线。先说明“已核实什么、还缺什么、为什么现在做这一步”，再给 **对象/输入 → 动作或技能 → 预期产物 → 完成判据**。涉及实际工作项时按 [what-next 交付要求](what-next.md#交付) 写明业务主题、文档类型和可见的原文路径；里程碑或问题 ID 同时说明事项含义，不能只给类别、状态码或“补证”等抽象动作。概念咨询无实际材料时不编造路径。通常突出一个首选，另列确实独立的工作。推荐专用技能时给可直接复制的命令（按当前客户端的技能调用写法），与该技能自身的收尾提示一致。
 例如：计划设计已就绪，但验收记录只覆盖主路径，当前没有发布授权。先建议补齐该版本的必要边界与集成验证；说明使用哪些记录、缺哪条判据。不能仅凭计划上的完成勾选推荐直接上线，也不必重写整个计划。
@@ -78,7 +104,7 @@ CRD 承载一方向另一方提出的协作请求，QA 在这里是双方 **Q&A
 实际项目状态、并行计划与跨机恢复交给 [what-next](what-next.md)；持久化遵循 [目录约定](../references/workspace-layout.md)。`.xgent-ai/sdlc/` 只放状态与来源链接，原 PRD、CRD、计划、报告和验证记录继续留在项目约定位置。没有台账不妨碍咨询；只有初始化/更新或已有任务授权覆盖回写时才保存。
-使用固定状态码时读取 [状态模型](../assets/sdlc/state-model.md)，已有项目遵循其登记版本。本手册的生命周期名称不是新增枚举。模型中的独立验收线仍为 TBD，不据此发明默认 `passed`、`accepted` 或 `released` 状态；事实、来源与尚未定义映射分开报告。
+使用固定状态码时读取 [状态模型](../assets/sdlc/state-model.md)：取原文记录支持的最强状态，证据质量单独标注；已有项目的旧版模型按 what-next 的升级规则处理。本手册的生命周期名称不是新增枚举。模型中的独立验收线仍为 TBD，不据此发明默认 `passed`、`accepted` 或 `released` 状态；事实、来源与尚未定义映射分开报告。
 专用 skill、SPMS、CI、仓库或发布平台的可用能力在目标环境核实，不能从本手册或历史流程图推定已经安装、可写或具备某个接口。只装 agi-mode 时仍可完成流程指导；需要专用技能才说明具体缺口，不阻断不依赖它的工作。

package/skills/agi-mode/playbooks/ui-delivery.md CHANGED Viewed

@@ -6,7 +6,7 @@
 决策入口：体验取舍读 [使用者结果](../principles/experience-first.md)，接受截图与操作证据读 [真实结果](../principles/prove-real-outcomes.md)，差分或交互检查可疑时读 [验证器反证](../principles/falsifiable-verification.md)。
-1. 明确属于开放设计、指定稿还原还是现有界面修复。读取项目设计约定、参考材料、实际用户流程和目标尺寸；还原任务不擅自重新设计。
+1. 明确属于开放设计、指定稿还原还是现有界面修复。读取项目设计约定、参考材料、实际用户流程和目标尺寸；还原任务不擅自重新设计。需要提炼或更新设计规范、找视觉参考或比较交互方案时，读 [界面设计调研](../references/interface-design.md) 的对应部分。
 2. 确定内容、主要动作、状态与信息层次。需要决定方向时先使用 [设计与原型](design-prototype.md)，方向明确后进入实现。
 3. 打通主要交互，再覆盖此次任务相关的加载、空、错误、禁用或完成状态。保持真实内容与数据语义，不能用假成功交互冒充接通。
 4. 启动实际界面，在代表性尺寸与边界宽度操作。检查文本溢出、滚动、焦点、键盘操作、触控区域及用户任务是否可完成；按本次风险选项，不机械扩大成全站审计。