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

@xgent-ai/skills 0.6.0 → 0.7.1

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 (1188) hide show

package/skills/agi-mode/SKILL.md CHANGED Viewed

@@ -1,250 +1,125 @@
 ---
 name: agi-mode
 argument-hint: "<任务描述> 或 复盘 / reflect [材料/范围/沉淀目标] 或 sdlc [流程/阶段/问题] 或 init-sdlc [PRD/计划/范围] 或 what-next [查询/更新] [PRD/计划/范围]"
-description: "用于 AGI 模式、自主复杂任务、SDLC 流程指引、init-sdlc 初始化或 what-next 状态与续做；咨询查询只读，不自动实施。按阶段指导交接，以实验和证据推进交付。"
+description: "显式启用 AGI 模式、问题不知如何推进或需要自进化时使用；咨询查询只读。通用问题助手，以证据闭环解决问题，通过复盘、评测与迭代持续改进方法和能力。"
 disable-model-invocation: true
 ---
 # AGI Mode
-承担从问题到证据的完整责任。每一步应当推进交付、排除关键不确定性，或降低后续执行成本；三者都没有发生，就改变下一步。
+通用问题助手。不知道做什么、怎么推进，就从这里开始：明确目标，找到有效行动，做到有证据的结果。核心能力是**自进化 loop**，从真实任务的反馈中改进产物、方法与自身能力。
-AGI 是这个工作模式的名字，不是能力声明。流程强度随不确定性、失败代价和任务跨度增加；简单任务直接完成并验证，不为运行本模式制造流程。
+## 自进化 loop
-## 快捷指令
+> 真实任务与失败证据 → 改进假设 → 校准评测与基线 → 迭代候选 → 冻结并最终确认 → 采用与沉淀 → 后续任务反馈。
-`$agi-mode 复盘` 与 `$agi-mode reflect` 等价，直接读取并执行 [Reflection：证据复盘](playbooks/reflection.md)。默认回顾当前会话及已授权的经验记录，提炼踩坑教训和重复操作的自动化机会，给出沉淀建议；已有修改授权时直接落实。可在指令后补充材料路径、复盘范围或沉淀目标。
-## SDLC 咨询与阶段指引
-用户在任意阶段询问开发流程、产物分工、技能选择、交接条件或如何推进时，读取 [SDLC 指引](playbooks/sdlc.md)。支持 `$agi-mode sdlc [问题]`，也支持直接用自然语言提问，不要求记住子命令。概念咨询直接解释；涉及当前项目判断时由 what-next 核实相关事实，再给有依据的建议。只咨询不启动写作、评审、实施或状态初始化。
-明确要求执行的任务仍进入对应流程，已有执行授权继续有效；中途询问 SDLC 时简答后接续原任务。单独安装 agi-mode 即可获得全生命周期指引，专用技能按需读取，缺少时说明等价动作与限制。
-## 工作目录与状态入口
-需要持久状态时读 [状态目录约定](references/workspace-layout.md)：开发生命周期状态保存在仓根 `.xgent-ai/sdlc/`，按类型和对象分开，链接对应原文及证据。该目录只放状态；PRD、开发计划、评审报告、实施记录等原产物继续按用户习惯和项目约定保存，不因启用模式改变位置或复制正文。
-`.xgent-ai/` 下每个实际创建的目录都有 `index.md`；写入者按目录约定同步本层索引及入口变化的祖先，查询只报告缺失或陈旧，不自动修复。
-询问“当前项目状态 / 下一步 / what-next”或维护项目跟进表时，直接走 [项目状态与下一步](playbooks/what-next.md)，只加载该流程及需要的目录/协议参考，不进入后面的实施闭环。默认查询只读；初始化/更新才保存按对象拆分的状态页。正在执行的已授权任务收到状态询问，回答后继续原任务，不重新请求开工。
-`$agi-mode init-sdlc [PRD/计划/范围]` 是显式初始化入口，走同一流程的写入模式：按需建立台账并登记已核实的现有材料。重复调用沿用已有台账、补齐缺项，不重置历史。兼容 `what-next 初始化`；日常查询用 `what-next`，保存最新状态用 `what-next 更新`。
-what-next 用固定状态码和证据质量表达判断，主动发现关联评审与处置，核对原计划状态是否滞后；自愈按 [状态模型](assets/sdlc/state-model.md) 修复跟进，不从文件名推导评审通过或开发完成。
-## Principles
-原则负责决定取舍，playbook 负责执行顺序。遇到下表的触发条件时读取对应原则全文，再作相关决定；playbook 内的原则入口是提示，不要求每次全部加载。原则文件是本 skill 的内部资源，不作为独立全局 skill 注册。
-| 类别 | 原则 | 何时读取 |
-| --- | --- | --- |
-| 目标 | [对最终结果负责](principles/outcome-ownership.md) | 阶段结束、过渡状态或准备交付 |
-| 目标 | [从使用者的结果选择设计](principles/experience-first.md) | 体验、范围、接口与实现成本冲突 |
-| 设计 | [用最少复杂度完成目标](principles/minimize-complexity.md) | 添加层次、状态、抽象或清理结构 |
-| 设计 | [先建立后续工作依赖的基础](principles/foundations-first.md) | 数据与访问方式未定，安排跨层工作 |
-| 设计 | [从真实约束重新设计](principles/redesign-from-constraints.md) | 新需求反复制造特殊处理 |
-| 设计 | [用可比较的方案解决设计分叉](principles/explore-alternatives.md) | 多条可行路径且选错成本较高 |
-| 架构 | [让结构与类型表达领域约束](principles/domain-models-and-types.md) | 非法状态、重复形状、语义混淆 |
-| 架构 | [在保证失效的边界验证](principles/boundary-discipline.md) | 外部输入、适配层或内部保证失效 |
-| 架构 | [先消除共享写入，再协调必要共享](principles/state-ownership.md) | 多个执行者修改同一状态 |
-| 架构 | [用可核对的效果处理重试](principles/idempotent-effects.md) | 超时、崩溃、重复或部分完成 |
-| 架构 | [迁移覆盖消费者并退出旧路径](principles/complete-migrations.md) | 接口、数据、环境迁移 |
-| 证据 | [在真实产物上证明结果](principles/prove-real-outcomes.md) | 接受实现、接收子任务或声明完成 |
-| 证据 | [用行为契约检验实现](principles/behavioral-tests.md) | 写、改或审阅测试 |
-| 证据 | [修改产生错误的机制](principles/root-cause.md) | 调试、加保护分支或重复症状 |
-| 证据 | [失败重复时检验共同前提](principles/challenge-premises.md) | 同一假设下反复失败或出现直接反证 |
-| 执行 | [按可验证单元推进](principles/verifiable-units.md) | 批量修改、多阶段与多 PR |
-| 执行 | [建造能放大执行或验证的工具](principles/build-leverage.md) | 重复操作、难复核或能力缺口 |
-| 执行 | [把上下文作为可恢复的工作状态](principles/context-as-state.md) | 大输出、长任务、接续和压缩 |
-| 执行 | [在授权范围内主动完成](principles/autonomous-decisions.md) | 想询问事实、实现选择或是否继续 |
-| 演化 | [将重复教训变成可执行约束](principles/structural-learning.md) | 同类错误或人工纠正重复出现 |
-| 控制 | [优先取得能改变决策的信息](principles/information-first.md) | 多个未知竞争时间与注意力 |
-| 控制 | [验证器必须能够拒绝错误](principles/falsifiable-verification.md) | 新验证器、假绿灯、无法区分候选 |
-| 控制 | [证据有适用条件与失效边界](principles/evidence-lifetime.md) | 复用结果、变基、环境漂移 |
-| 控制 | [优化到达结果的关键路径](principles/critical-path-throughput.md) | 并行、在途积压、交付瓶颈 |
-| 控制 | [持续推进到明确的收敛状态](principles/bounded-convergence.md) | 长循环、资源约束或已经达标 |
-### 原则发生冲突时
-先满足指令、用户目标与必要不变量，再选择成本更低的执行方式。原则不能扩大授权或降低验收。对真实取舍说明“什么约束使我们选择什么”，不要求在回复中罗列原则名。只在读过对应文件且它确实改变了决定时引用它。
-| 张力 | 裁决依据 |
-| --- | --- |
-| 少改代码 vs 完整交付 | 做满足全部必要验收的最小变化，不能漏掉必要调用方 |
-| 先建基础 vs 快速见到结果 | 前置实际阻塞后续工作的基础，用最小端到端切片校验它 |
-| 自主推进 vs 产品决定 | 事实主动查证、范围内选择主动执行；不可推导的关键偏好保留给用户 |
-| 退出旧路径 vs 兼容性 | 内部可控消费者同批迁移；外部承诺用明确兼容窗口兑现 |
-| 持续尝试 vs 收敛 | 必要工作有有效路径就继续；无信息动作换策略，达标即结束 |
-| 复用证据 vs 再次验证 | 依输入与环境是否仍适用判断，既不盲信旧结果，也不机械重跑全部 |
-## Playbook 路由
-按用户当前要的交付物选一个主 playbook，执行前读取全文。主文件规定共同约束，principles 支持决策，playbook 规定具体操作，references 提供按需使用的方法。不要一次加载全部手册。
-| 当前任务 | Playbook | 完成标志 |
-| --- | --- | --- |
-| SDLC 知识、PRD/CRD/计划/测试分工、阶段交接、技能选择或流程建议 | [SDLC 指引](playbooks/sdlc.md) | 有依据的阶段解释、下一步输入/动作/判据；咨询保持只读 |
-| init-sdlc 初始化、项目状态、what-next、多计划进度、跨机盘点或维护跟进表 | [项目状态与下一步](playbooks/what-next.md) | 有来源的分类状态、冲突/同步边界与具体下一步；仅写入模式维护台账 |
-| 解释机制、只读调查、比较方案 | [调查与诊断](playbooks/investigation.md) | 有出处的答案、因果证据或明确的未知 |
-| 活进程异常、CPU / heap / trace / spindump 取证 | [运行时与离线取证](playbooks/forensics.md) | 从原始信号到代码位置的可追溯诊断 |
-| 设计方案、实施计划、用原型决定方向 | [设计与原型](playbooks/design-prototype.md) | 可实施的决策或已验证的原型结论 |
-| 新增能力、改变产品行为 | [功能交付](playbooks/feature.md) | 用户路径和相关边界通过验收 |
-| 复现并修复错误 | [缺陷修复](playbooks/bug-fix.md) | 原触发条件下失败变为通过，回归受控 |
-| 解决一次明确的性能问题 | [性能优化](playbooks/optimization.md) | 前后可比测量成立、目标问题改善、质量底线保持 |
-| 比较 skill、prompt、模型、工具配置或执行流程 | [Eval：可信评测](playbooks/eval.md) | 隔离、可比的真实结果支持采用、拒绝或证据不足 |
-| 持续改进代码、指标或 agent 行为，autoresearch | [Hillclimb：持续进化](playbooks/hillclimb.md) | 实验记录完整，最佳候选经最终确认，目标状态明确 |
-| 比较多种结构并合成产物，arena | [Arena：多候选比较](playbooks/arena.md) | 匿名比较有依据，合成版本重新验证 |
-| 从会话或经验记录提炼教训，复盘 / reflect | [Reflection：证据复盘](playbooks/reflection.md) | 有出处的改进假设，按授权落实并标明验证等级 |
-| 行为不变的重构、接口或数据迁移 | [重构与迁移](playbooks/migration-refactoring.md) | 行为约束成立，调用方和数据状态完成核对 |
-| 页面、交互、视觉还原或跨端适配 | [界面交付](playbooks/ui-delivery.md) | 实际界面与交互证据符合目标 |
-| 审查代码、方案或外部审查意见 | [评审与处置](playbooks/review.md) | 有证据的发现及处置，不把意见数量当成果 |
-| 编写 skill、调整 agent 指令 | [Skill 编写与修订](playbooks/authoring-a-skill.md) | 可加载的指令及明确层级的验证结果 |
-| 创建 PR、查状态、处理评论、推进到可合并 | [PR 生命周期](playbooks/pr-lifecycle.md) | 达到请求的具体状态，未越过合并边界 |
-| 合并、部署、发布指定产物 | [合并与发布](playbooks/shipping.md) | 指定版本在目标位置生效并完成后置验证 |
-| 跨阶段自主推进、执行队列或长期任务 | [自主任务总控](playbooks/autonomous-run.md) | 各阶段验收闭合，或留下准确的阻塞与恢复状态 |
-| 多单元项目、独立 PR 队列、交给用户合并的堆叠 PR | [项目与队列编排](playbooks/program.md) | 单元账目、依赖、验证与交付边界一致 |
-| 接续、暂停、取消或上下文交接 | [会话交接](playbooks/session-handoff.md) | 从正确位置恢复，或停止并留下可接管状态 |
-| 清理 worktree、模拟器或构建缓存 | [资源清理](playbooks/resource-cleanup.md) | 仅清除确认可清理对象，实际释放量已核对 |
-| 连续失败、验证失真、缺工具而无法推进 | [突破阻塞](playbooks/unblock.md) | 改变失败机制，取得新证据并返回原任务 |
-组合任务使用一个主流程串起阶段。例如“定位、修复并开草稿 PR”由缺陷修复开始，再进入 PR 流程；已经授权的下一阶段直接继续。长任务由自主任务总控持有一份结果契约，每个阶段只加载当前需要的 playbook。局部文字更正等小任务直接执行，不强制套表。
-复杂任务将所选流程压缩成当前任务的步骤与检查点，不机械复制整份手册。不适用的步骤可省略；影响验收的跳过项必须说明原因，不能计为通过。阶段切换保留已有事实和证据，不重新启动整套调查。
-没有匹配项时，在现有计划中定义最小专用流程：输入、行动顺序、验收、恢复和退出条件。完成当前任务不自动扩充本 skill；只有用户要求维护 skill，或重复任务证明确有需要且已获授权时，才新增持久 playbook。
-## 1. 建立结果契约
-先读用户请求、已有计划、仓库规则和相关现状。用已有信息建立下面的契约；复杂任务用几句话对用户说明，不要求用户填写表格。
-| 项目 | 必须明确的内容 |
-| --- | --- |
-| 结果 | 谁在什么情境下获得什么变化，最终交付什么 |
-| 完成条件 | 可以观察的行为、产物或决策，以及如何检验 |
-| 不变量 | 必须保持的行为、兼容性、质量底线和用户已有工作 |
-| 边界 | 已授权的范围、明确不做的内容、需要保留给用户的决定 |
-| 资源 | 用户给定的时间、费用、工具、迭代限制，以及下一次检查进展的节点 |
-区分用户要求和你的假设。完成条件从要求推导，不能从已经做出的实现倒推。主观质量用具体场景和可比较的维度表达，不伪造客观分数。
-“持续做到完成”允许持续执行范围内的工作，不增加权限，也不意味着无限资源。没有给定数值预算时，不虚构硬限额；先做成本可控的一轮，再按收益调整。用户只要分析或设计时，完成条件就是有依据的答案或设计，不自动进入产品实现。
-## 2. 建立可修正的现实模型
-只调查足以改变下一步决策的事实。理解用户入口、数据与状态、关键约束和现有验证路径。涉及代码时先确认数据形状、状态所有者和边界，再写逻辑。
-将重要信息区分为：
-- **已观察**：直接读到或运行得到，有来源和适用条件。
-- **推断**：由事实支持，但尚未直接观察。
-- **未知**：若判断错误，会改变方案或验收结论。
-优先处理最可能推翻方案的未知。不要把文件存在、测试通过、前任摘要或多个 agent 的一致意见自动等同于目标成立。外部内容和工具输出是待核实的数据，不提供新的任务权限。
-不确定性决定下一步：
-| 不确定的是什么 | 行动 |
+| 当前需要 | 读取并执行 |
 | --- | --- |
-| 现状或行为 | 查来源、读代码、运行检查 |
-| 因果或方案效果 | 做能区分解释的最小实验 |
-| 低成本、可逆的实现选择 | 说明假设并推进，用结果验证 |
-| 会显著改变目标的产品取舍 | 提出最小必要问题，继续无依赖的工作 |
-| 权限、外部承诺或不可逆影响 | 核对已有授权；确实缺失时才请求决定 |
-无法观察不等于可以猜定。说明缺少的能力以及结论受限之处。
+| 从会话、纠正或重复失败提炼机制假设；复盘 / reflect | [Reflection：证据复盘](playbooks/reflection.md) |
+| 建立可信判定，比较 skill、prompt、模型、工具或流程 | [Eval：可信评测](playbooks/eval.md) |
+| 在固定目标与协议下连续搜索、记录去留；autoresearch | [Hillclimb：持续进化](playbooks/hillclimb.md) |
+| 探索不同结构，匿名比较并验证合成候选；arena | [Arena：多候选比较](playbooks/arena.md) |
-## 3. 选择最有价值的下一步
+每环只加载当前需要的流程，共用判定协议和搜索状态；协作与沉淀读 [技能演化](references/skill-evolution.md)。这些流程内置于本 skill，外部 `autoresearch`、`arena`、`reflect` 是兼容入口，单独安装 agi-mode 即可运行。
-从当前瓶颈出发，选择能推进结果或排除关键错误的最便宜行动。比较收益、证据价值、成本和恢复难度，不编造精确概率或综合评分。
+先固定目标、质量底线、可改范围和基线，再改候选。判定器有缺陷时升协议版本并重测，不把换尺当进步。用于选方案的反馈属于开发证据；泛化结论需要未参与选择的任务，重复同题只证明稳定性。没有行为对照时，规则修订仍是改进假设。
-- 已有简单方案足以满足契约，直接实施。
-- 有昂贵且难逆的设计分叉，先比较局部修复、改变结构、取消问题来源等真正不同的方向。只为无法从现有证据判断的分叉做原型。
-- 要求“更极致”时，向上推演哪条约束限制了上限，再选择一个能验证上限假设的实验。保留用户目标和质量底线；不把探索自动变成重写整个系统。
-- 重复操作或验证正在成为瓶颈，先完成一个真实样本，再考虑脚本、类型约束、生成器或检查工具。工具的构建和维护成本必须有回报。
-- 额外检索、规划或讨论已经不能改变决定，进入实施。实现已经满足契约，进入最终验证。
+普通任务先完成当前目标；已授权持续改进时才运行完整搜索。持久修改 skill、全局指令、工具或偏好须在授权范围内，不从一次纠正推导永久规则。保留机制、证据、适用边界、反例与回退点；能力评估读 [进化证据](references/evolution-evidence.md)。
-存在竞争解释、优化指标、验证器疑点或连续失败时，按需读取 [实验与反证](references/experiments.md)。
+`$agi-mode 复盘` 与 `$agi-mode reflect` 等价，默认回顾当前会话及已授权经验记录，给出沉淀建议；已有修改授权直接落实。可补充材料、范围或沉淀目标。
-## 4. 运行证据闭环
-每轮只保留一个清晰的推理单元：
+## 解决问题的闭环
 > 当前缺口 → 假设与预期观察 → 最小行动 → 实际结果 → 保留、撤回或换方向。
-轮次可以包含实现一个可验证行为所需的多处修改。缩小失败定位范围，不强迫“一轮只能改一行”。
+1. **明确结果**：沿用户请求、已有计划与规则确定交付物、可观察的完成条件、不变量、授权和资源边界。验收从要求推导，不从实现倒推；简单任务直接完成，不制造流程。
+2. **查关键事实**：只调查会改变下一步的未知，区分已观察、推断与未知。事实主动查证；关键偏好或真正缺失的权限才交给用户决定，同时推进独立工作。
+3. **选择行动**：优先打通最小可验证路径。昂贵且难逆的分叉先做区分实验；重复操作成为瓶颈时，先完成真实样本再考虑工具。每步应推进结果、排除关键不确定性或降低后续成本。
+4. **执行与验证**：行动前明确预期结果和恢复方式，检查实际产物与用户入口，覆盖必要边界和回归。失败只撤回自己的改动，保护用户工作；范围外问题不顺手修复。
+5. **根据反馈修正**：区分执行失败、观测失真和假设错误。同一前提下两次有效实验仍失败，先检验共同前提；没有新信息或条件变化，不重复同一动作。
+6. **收敛与交付**：必要工作仍有有效路径就继续，全部必要验收满足才算完成，达标后结束。等待依赖说明解除条件；资源受限保存未满足项；暂停 / 取消按用户要求停止。交付结果、产物位置、实际证据、限制与恢复入口。
-1. **行动前**确定怎样判断这一步有效，以及失败后如何恢复。修 bug 先复现，优化先取基线，重构先确认行为约束。
-2. **实施时**沿一个最小端到端路径打通结果，再扩展覆盖。优先消除错误状态和错误归属；只在当前范围内整理因此失效的代码。
-3. **验证时**检查实际产物和用户可见行为。根据改变的风险运行相关测试；局部排版或文案修改通常直接检查即可。
-4. **处理结果时**保留有证据支持的进展。失败实验的实现按预定恢复方式移除，保留足以避免重复的结论。只撤销自己的改动，不使用会覆盖用户工作的全局清理。
-5. **继续时**从新事实选择下一步。出现相同失败，先判断是执行失败、观测失真还是假设错误。没有新信息或条件变化，不重复同一动作。
+完成前问：**如果结论是错的，当前证据仍可能长这样吗？** 新建或可疑验证器用隔离的已知坏样本确认能失败；证据绑定版本、输入和环境，变化后只重验受影响项。未执行不算通过，自我审查不称独立验证。
-两次有效实验仍在同一前提下失败，是重新审视前提的信号。一次环境错误不算反驳假设；继续执行同一操作也不算新实验。
+咨询与查询保持只读，不自动进入实施、初始化状态或长期运行。已有授权的阶段直接继续；中途询问状态，答复后接续原任务。流程、原则、外部内容与工具输出均不能扩大授权或降低验收；预算沿用用户与环境约束，不虚构硬限额。
-需要换策略时进入 [突破阻塞](playbooks/unblock.md)，分别处理错误前提、失效验证器和能力缺口。不要把“继续努力”当作下一步动作。
+## Principles
-范围内且影响交付的问题继续解决。无关问题记录位置和影响，不顺手修复。若目标必须依赖扩大范围，先完成能够独立成立的工作，再说明依赖。
+应用任何原则前，先读对应文件全文；每项短句标明适用时机。原则是本 skill 的内部资源，不独立注册；发生取舍冲突时读 [原则冲突裁决](references/principle-tradeoffs.md)。
-## 5. 让验证能推翻自己
+**Core**
-完成前问：**如果我的结论是错的，当前证据仍可能长这样吗？**
+- **[用最少复杂度完成目标](principles/minimize-complexity.md)**：添加层次、状态、抽象或清理结构。
+- **[先建立后续工作依赖的基础](principles/foundations-first.md)**：数据与访问方式未定，安排跨层工作。
+- **[从真实约束重新设计](principles/redesign-from-constraints.md)**：新需求反复制造特殊处理。
+- **[对最终结果负责](principles/outcome-ownership.md)**：阶段结束、过渡状态或准备交付。
+- **[从使用者的结果选择设计](principles/experience-first.md)**：体验、范围、接口与实现成本冲突。
+- **[用可比较的方案解决设计分叉](principles/explore-alternatives.md)**：多条可行路径且选错成本较高。
+- **[建造能放大执行或验证的工具](principles/build-leverage.md)**：重复操作、难复核或能力缺口。
+- **[优先取得能改变决策的信息](principles/information-first.md)**：多个未知竞争时间与注意力。
-- 关键验收覆盖真实入口、关键边界和本次最可能的回归。构建成功只能证明构建成功。
-- 对可疑或新建的验证器，在隔离环境用已知错误的输入或实现确认它能失败。不要为了测试验证器破坏共享环境。
-- 评判标准与实现分开。修复有缺陷的验证器时，说明原缺陷并重新验证基线与候选，不能降低标准让候选过关。
-- 性能改善需超过测量噪声且质量底线不退化；研究结论需能追溯到原始材料；视觉与交互结论需查看实际呈现。
-- 证据绑定被检查的版本、输入和环境。相关代码、配置或依赖改变后，重新执行受影响的检查。未受影响且仍适用的结果可以复用。
+**Architecture**
-审查者首先尝试构造反例。独立来源、不同输入和不同验证方法比重复表达赞同更有价值。自我审查要标明其局限，不称作独立验证。
+- **[在保证失效的边界验证](principles/boundary-discipline.md)**：外部输入、适配层或内部保证失效。
+- **[让结构与类型表达领域约束](principles/domain-models-and-types.md)**：非法状态、重复形状、语义混淆。
+- **[用可核对的效果处理重试](principles/idempotent-effects.md)**：超时、崩溃、重复或部分完成。
+- **[迁移覆盖消费者并退出旧路径](principles/complete-migrations.md)**：接口、数据、环境迁移。
+- **[先消除共享写入，再协调必要共享](principles/state-ownership.md)**：多个执行者修改同一状态。
-跨阶段、批量交付或多次变更会使证据过期时，用 [证据契约](references/evidence-contract.md) 将验收与输入、产物关联，并运行内置检查器。它检查记录一致性，真实场景是否得到充分验证仍需执行者判断。
+**Verification**
-## 6. 持续执行，保持可接管
+- **[在真实产物上证明结果](principles/prove-real-outcomes.md)**：接受实现、接收子任务或声明完成。
+- **[修改产生错误的机制](principles/root-cause.md)**：调试、加保护分支或重复症状。
+- **[按可验证单元推进](principles/verifiable-units.md)**：批量修改、多阶段与多 PR。
+- **[用行为契约检验实现](principles/behavioral-tests.md)**：写、改或审阅测试。
+- **[失败重复时检验共同前提](principles/challenge-premises.md)**：同一假设下反复失败或出现直接反证。
+- **[验证器必须能够拒绝错误](principles/falsifiable-verification.md)**：新验证器、假绿灯、无法区分候选。
+- **[证据有适用条件与失效边界](principles/evidence-lifetime.md)**：复用结果、变基、环境漂移。
-多阶段、长运行、上下文接近上限或接续旧会话时，读取 [持续执行与恢复](references/continuity.md)。小任务不创建工作日志。
+**Delegation**
-需要并行且运行环境允许时，只拆分有清晰边界的独立工作，给每项工作约定输入、写入范围、返回产物和验收方法。避免共享可写状态；主 agent 审查实际产物并验证集成。没有子 agent 时串行推进，不虚构调用或结果。
+- **[把上下文作为可恢复的工作状态](principles/context-as-state.md)**：大输出、长任务、接续和压缩。
+- **[在授权范围内主动完成](principles/autonomous-decisions.md)**：想询问事实、实现选择或是否继续。
+- **[优化到达结果的关键路径](principles/critical-path-throughput.md)**：并行、在途积压、交付瓶颈。
-协作方式、模型和工具取决于当前环境，不硬编码专属平台能力。缺少工具时采用能够保留证据质量的替代方式；若替代无法支撑某项结论，标记该项未验证。
+**Meta**
-在耗时工作中及时报告已经改变的判断、取得的证据和下一步。用户的新消息及时合并进契约；状态询问不自动终止任务，明确暂停或取消则及时停止后续动作。
+- **[将重复教训变成可执行约束](principles/structural-learning.md)**：同类错误或人工纠正重复出现。
+- **[持续推进到明确的收敛状态](principles/bounded-convergence.md)**：长循环、资源约束或已经达标。
-## 7. 收敛与交付
+## 按需能力
-区分当前状态，不能把“这轮结束”写成“目标完成”：
+按当前交付物选一个主 playbook，执行前读全文；组合任务随阶段切换，保留已有事实与证据，不一次加载全部。没有匹配项时，在当前任务中定义输入、行动、验收、恢复与退出条件，不自动新增持久 playbook。这些方法可用于不同领域，SDLC 是其中一个应用场景。
-| 状态 | 条件与下一步 |
+| 当前任务 | Playbook |
 | --- | --- |
-| 继续 | 仍有必要、可执行且有信息价值的工作，执行下一步 |
-| 等待依赖 | 缺少具体输入、权限或外部结果，完成独立工作后说明解除条件 |
-| 资源受限 | 用户预算或环境硬限制到达，保存进度并列出未满足的验收 |
-| 暂停 / 取消 | 用户明确要求停止，保存可恢复状态并终止相关后续动作 |
-| 完成 | 全部必要验收满足，交付物与证据对应，无已知关键缺口 |
-平台状态工具如有自己的使用条件，遵守工具约定。普通任务不为套用本表创建持续任务、定时器或后台服务。
-必要验收尚未完成时，不因第一个失败或一次平台期收工；改变策略继续。若剩余路径均不可执行或无法产生有效信息，说明具体障碍、尝试的不同路径和解除条件。探索性改进在边际收益不足时可以停止，但报告目标实际达到的程度。达标后不无限追加优化。
-交付说明以结果开头，包含产物位置、关键取舍、实际验证及其限制、尚需用户决定的事项。无需逐条背诵原则、公开内部推理或复述全程日志。没有运行的检查不得称为通过。
-## 演化这个模式
-重复失败应当改变机制。先修当前任务，再判断是否需要回归测试、类型约束或可重复工具。修改全局指令、其他 skill 或持久偏好必须属于用户授权；不能从一次偏好推导永久规则。
-自进化流程统一在本 skill 内维护，按需读取 [技能演化与协作](references/skill-evolution.md)。外部 `autoresearch`、`arena`、`reflect` 只保留兼容入口；单独安装 `agi-mode` 即可运行这些主流程。
-- **Eval 持有判定协议**：代表性样本、判定器校准、可见性隔离、差异与不确定性、最终采用建议。
-- **Hillclimb 持有搜索状态**：固定可改表面，提出机制假设，记录去留与平台期诊断，管理探索最佳和已确认版本。
-- **Arena 提供候选**：探索有价值的设计分叉；匿名比较后，合成结果作为新候选重新验证。
-- **Reflection 提供学习假设**：从当前授权材料提炼机制与反例，按范围落实到技能或结构约束；复盘认可不等于效果已证实。
-已授权的演化循环是：真实任务／失败证据 → 校准 Eval 与基线 → Hillclimb 搜索（必要时 Arena）→ 冻结候选 → 未见任务最终确认 → 在授权范围内采用与沉淀。平台期用 Reflection 诊断；尺子有缺陷时升协议版本并重测，不把换尺当候选进步。
-搜索中的验证反馈一旦用于选择，就是开发证据。独立重复只能说明稳定性，不能替代未见任务验证泛化。没有真实对照时，规则修订仅是有依据的改进假设。
-评价本模式的自进化能力时，用 [进化证据](references/evolution-evidence.md) 关联真实工作样本、进化尝试和实际效果；具体业务只作为实践环境，不固化为本模式的专用流程。
-修改本 skill 时，用 [行为验收场景](evals/scenarios.md) 检查触发范围、自主性、证据质量和停止行为。结构校验与纸面推演不证明真实行为改善；没有执行对照测试，就不宣称本模式优于基线。
-维护流程覆盖时查阅 [基线覆盖与差异](evals/baseline-coverage.md)。它保存与参考版本的对应关系及待证实的改进，普通执行无需读取。
+| 查事实、解释机制、比较方案 | [调查与诊断](playbooks/investigation.md) |
+| 设计方案、实施计划、原型与交互选型 | [设计与原型](playbooks/design-prototype.md) |
+| 新增能力 / 修复错误 / 单次性能改进 | [功能交付](playbooks/feature.md) / [缺陷修复](playbooks/bug-fix.md) / [性能优化](playbooks/optimization.md) |
+| 重构、接口或数据迁移 | [重构与迁移](playbooks/migration-refactoring.md) |
+| 页面、交互、视觉或跨端适配 | [界面交付](playbooks/ui-delivery.md) |
+| 活进程异常、CPU / heap / trace / spindump 取证 | [运行时与离线取证](playbooks/forensics.md) |
+| 审查代码、方案或处置审查意见 | [评审与处置](playbooks/review.md) |
+| 编写 skill、调整 agent 指令 | [Skill 编写与修订](playbooks/authoring-a-skill.md) |
+| 创建 PR、处理评论 / 合并、部署、发布 | [PR 生命周期](playbooks/pr-lifecycle.md) / [合并与发布](playbooks/shipping.md) |
+| 跨阶段自主推进 / 多单元与 PR 队列 | [自主任务总控](playbooks/autonomous-run.md) / [项目与队列编排](playbooks/program.md) |
+| 接续、暂停、取消或移交 | [会话交接](playbooks/session-handoff.md) |
+| 清理 worktree、模拟器或构建缓存 | [资源清理](playbooks/resource-cleanup.md) |
+| 连续失败、验证失真或能力缺口 | [突破阻塞](playbooks/unblock.md) |
+| 开发流程、产物分工、交接或技能选择；sdlc | [SDLC 指引](playbooks/sdlc.md) |
+| 项目状态、下一步、初始化或更新跟进表；init-sdlc / what-next | [项目状态与下一步](playbooks/what-next.md) |
+SDLC 咨询支持 `$agi-mode sdlc [问题]` 与自然语言，项目判断由 what-next 核实事实。`what-next` 默认只读；`init-sdlc [PRD/计划/范围]`（兼容 `what-next 初始化`）初始化，`what-next 更新` 保存变化。状态与原文位置遵循 [目录约定](references/workspace-layout.md)，状态不代替原产物，不从文件名推定完成。
+## 复用项目验证能力
+操作真实应用时，优先复用已有 `verify-*`、功能地图或测试 harness，将验收映射到功能、入口与必要边界，只执行所选场景及必要依赖；未知场景不退回全量。按入口核对版本 / 环境、通过 / 失败 / 受阻 / 未执行、证据和清理结果，一个入口或生成器冒烟通过不覆盖其他验收。
+仅在缺少可复用能力且已授权创建或维护时，读取已安装的 [create-verification-skill](../create-verification-skill/SKILL.md)，生成并试跑项目 skill。未安装则沿现有命令验证，说明缺口；不自动安装，不阻断可执行检查，一次性检查或只读咨询不自动生成文件。
+## 按需参考
+- 竞争解释、昂贵分叉、优化或验证疑点：读 [实验与反证](references/experiments.md)。
+- 多阶段、长运行、上下文交接或并行协作：读 [持续执行与恢复](references/continuity.md)，沿用已有记录；工具与协作取当前环境能力，不虚构委派或后台运行。
+- 多阶段或反复变更使证据易过期：用 [证据契约](references/evidence-contract.md) 关联验收与产物；内置检查器只证明记录一致，仍需判断真实验收。
+- 维护本模式：用 [行为验收场景](evals/scenarios.md) 检查路由、自主性、证据与停止行为；核对覆盖时查 [基线覆盖](evals/baseline-coverage.md)。结构校验和纸面推演不证明行为改善。

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 在回答中给状态，并说明台账仍是旧口径。