@xgent-ai/skills 0.4.0 → 0.6.0

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

@@ -0,0 +1,25 @@
+# <对象标题> · 状态
+
+- 对象 ID / 类型：<完整 UUID / prd、plan、review>
+- 状态模型：<协议 v3 / state-model v1；评审对象另写 review_type>
+- 来源：<实际文档/报告链接，版本>
+- 核查时间：<带时区时间>
+- 可见范围：<分支/HEAD/dirty、所核实范围及同步限制>
+
+## 当前事实与下一步
+
+| 维度 / 范围 | 固定状态码 | 来源自述 | 证据质量 | 证据 / 对应事件 | 差异、缺证或阻塞 | 下一步及完成判据 |
+| --- | --- | --- | --- | --- | --- | --- |
+
+<!-- 状态码按仓内 state-model.md；无法确认用 unknown，候选另列不冒充当前事实。原计划状态滞后时保留自述及纠正依据；开发完成不代表验收或发布。 -->
+
+## 关联
+
+| 关系 | 目标对象 / 状态页 | 需求、里程碑或问题范围 |
+| --- | --- | --- |
+
+<!-- PRD 链到承接计划；计划链到 PRD、实施记录及各轮评审状态页；评审链到所审对象、前轮与整改证据。复审不覆盖原轮结论。关联不明就写待关联，不靠同名猜测。 -->
+
+## 已纳入事件
+
+<!-- 只列本对象全部已纳入事件 UUID 及链接，按 ID 排序；包括历史事件，排序不代表执行顺序。可折叠；其他对象事件在各自状态页维护。 -->

package/skills/agi-mode/assets/sdlc/protocol.md

@@ -0,0 +1,98 @@
+# 项目状态记录协议 · v3
+
+本目录默认是仓根 `.xgent-ai/sdlc/`，随项目版本控制保存。`index.md` 只作导航；`status/<kind>/index.md` 列对象去向，`status/<kind>/<object_id>.md` 各保存一个对象的状态；`events/<kind>/<object_id>/` 保存该对象的独立事实记录，`event-template.md` 是写入模板。本协议可由任意 agent 或人工执行，无脚本、数据库或特定 skill 安装依赖。路径可按项目约定调整，以下文件名相对于本协议目录。
+
+判断和回写前读取随仓保存的 [固定状态与证据校准](state-model.md)：使用固定状态码，区分原文自述与核查结论，并按其中的规则发现漏记的评审、处置和实施证据。台账、原文状态行都可能滞后，不直接照抄为当前事实。
+
+## 分类与读取
+
+- 本目录只保存状态及其索引、协议和事件。PRD、开发计划、评审报告、实施/验收记录、测试计划、原始日志/截图等继续按用户习惯与项目约定保存；不规定它们的目录或文件名，不搬迁、复制或创建在本目录。用 `artifact`、`sources` 及来源链接引用实际位置。
+- `kind` 的默认目录名固定为 `prd`、`plan`、`review`。每个对象单独状态页；每轮评审也是独立对象，计划状态页链接各轮而不复制报告。类型索引只列 ID、标题、来源、状态页及活动/归档标记，不存所有对象的进度正文。
+- 类型索引过大时按领域或年份分片，父索引列全分片与范围；归档另列索引，不删事件，不以文件年龄推断归档。顶层列直接文件、子目录入口和当前重点，不能悄悄截断活动工作。
+- 显式枚举隐藏目录：`rg --files --hidden .xgent-ai/sdlc`。先看导航/分类索引，再按活动对象、用户选定范围及依赖读状态页和相关来源。比较该对象事件目录与其已纳入集合；没登记的对象/事件要提示，不默认全文加载所有历史。
+- 旧 `docs/project-status/` 或其他登记台账沿原协议维护，不自动生成第二份。仅在台账迁移获授权时迁移状态资料，保留 ID、历史内容与来源版本，转换来源链接并记录旧路径映射；原文档保持原位；核验后登记新入口，旧入口只留指引。不要用本 v3 模板直接覆盖旧协议；协议升级与历史自由文本的兼容按 state-model.md 执行。
+
+## 目录索引维护
+
+本规则适用于 `.xgent-ai/` 下实际创建的每层状态目录，包括 `sdlc/`、`status/`、`status/<kind>/`、`events/`、`events/<kind>/`、`events/<kind>/<object_id>/`、非开发任务的 `tasks/` 与任务子目录，以及后续增加的归档或分片目录。每个目录都有 `index.md`，目录按需创建，不为索引预建空树。原文档目录不受本规则约束。
+
+- **内容与边界**：写明目录用途、覆盖范围与本规则入口；列全直接文件和子目录，不自列 `index.md`。文件链接到自身，子目录链接到其 `index.md`，链接相对当前索引解析，不含机器绝对路径。类型目录一对象一行，保留 ID、标题/来源、状态页及活动/归档标记；事件叶目录一事件一行，保留事件 ID、facet/scope 和文件链接，不复制状态结论。普通导航只列名称、用途和入口，不在每层复制全树或进度。
+- **职责与时机**：创建或改变目录内容的执行者，在同一批交付中维护受影响索引；先落状态文件/事件，再更新本层索引，最后更新入口有变化的祖先。首次创建目录同时创建索引；旧目录缺索引时在已授权维护范围内补齐。无关目录和内容不变的索引不重写，也不只为检查刷新时间。状态正文改变但身份、去向和目录成员不变时，无需改索引；当前重点实际改变时才更新重点。
+- **新增与移动**：新对象、新事件、新子目录必须登记；已有对象的新事件只新增到对应事件清单，不逐级改总索引。获准移动状态文件时保持对象/事件 ID，更新旧、新父目录与受影响链接，保留历史路径映射；不改写不可变事件。原文链接变化须核实新位置，维护索引不授权移动原文。
+- **归档与删除**：归档须有事实依据，更新活动/归档去向并保留可达入口和事件历史。索引过期条目只有确认目标已按授权删除或迁移后才删除或改指；本机目标缺失先标未同步/待核对，不能顺手删记录、删目录或裁掉历史。原文已删除也保留状态与事件，标明来源不可用。
+- **增长与排序**：条目按相对路径或稳定 ID 排序，避免每次按状态、机器时间重排。索引过大时拆为 `index-<分片名>.md`，首页列全分片与明确范围；每项恰属一个分片。分片是导航文件，不产生对象或事件 ID；如另建物理目录，该目录也须有 `index.md`。活动项不能因分页或归档而从入口消失。
+- **事件识别**：`index.md`、`index-*.md` 都是可修改导航，必须排除在事件读取、事件数量及已纳入事件集合之外。实际事件以 UUID 文件名和一致的 `event_id` 字段识别；疑似事件但格式损坏时报告待核对，不悄悄忽略。
+- **多机合并**：写前重读本层索引。合并时按稳定 ID 与路径保留双方新增项，再对照合并后的实际文件和事实重建导航；不按时间或单边版本覆盖。相同 ID 指向不同内容、相同路径对应不同 ID 时保留冲突提示并核对。索引不是锁，不证明其他机器已同步；重建保留人工用途说明、当前重点及未解决问题。
+- **检查与恢复**：回读受影响索引及祖先入口，枚举当前可见的直接内容与分片，检查漏项、重复条目、缺少子目录索引和断链；发现未登记目录时递归核对其索引覆盖，不需全文读历史事件。缺失目标明确可见性限制。保存事件成功而索引失败时保留事件并说明待修复，下次维护可补齐；查询模式仅报告索引缺失/陈旧，不自动写入。
+
+## 事实与粒度
+
+- PRD 正文定义需求；计划正文定义范围、门槛与恢复入口；实际实现、验证及处置记录支撑进度判断。原文自报状态不享有绝对优先级：与可核实交付不符时，台账保留自述并给有证据的规范状态及差异原因，不顺手修改原文或外部系统。
+- PRD、计划、评审各有稳定 `object_id`。一份 PRD 可关联多计划，一份计划可关联多 PRD；依赖可细到需求、里程碑或检查，不强制串行。一轮评审可审多个对象，未关联计划的代码评审也可独立登记。
+- 原文件名与状态对象 ID 分开：登记时沿用已有对象 ID，否则分配 UUID，不要求原报告用 UUID 命名。每次实际评审是独立对象，即使同日、同机器或同路径重跑也分配新的评审 ID；同轮整改沿原评审对象追加处置。复审用 `rechecks` 关联前轮，问题以 `评审 object_id + 报告内问题 ID` 定位。原报告被授权覆盖时，引用可取回的历史版本或用户约定位置的快照，不把快照放进本状态目录；仅有 hash 而内容不可取回时标证据缺失。
+- 已有本协议 ID 时沿用；新对象/事件用独立生成的 UUID（例如 `python3 -c 'import uuid; print(uuid.uuid4())'`，也可用系统 UUID 工具），不依赖机器名、时钟或共享递增编号。文件移动保持对象 ID，并在新事件登记新路径和旧路径；复制出独立计划则新建 ID，关联 `derived-from`。
+- 同一历史对象被两台机器首次导入为不同 ID 时，只有读到来源/版本/范围等证据确认相同，才新增带 `same-as` 关系的对账事件；保留原 ID 和所有历史。同名、同 hash 的两次真实评审不能因此合并。
+
+## 事件字段
+
+每次变化新建 `events/<kind>/<object_id>/<event_id>.md`，YAML frontmatter 加简短 Markdown 证据正文。用 `event-template.md`，去掉不适用的可选字段。记录一旦交付保存不覆盖；纠错/补证新建后续事件。写前重读相关记录，文件名已存在则核对，禁止覆盖不同内容。
+
+| 字段 | 约定 |
+| --- | --- |
+| `schema_version` | 新事件固定为 3；旧事件不原地改写 |
+| `event_id` | UUID，与文件名一致 |
+| `object_id` / `kind` / `title` | 稳定对象 ID；`prd`、`plan`、`review`，必要时允许项目自定义类型；可读标题 |
+| `artifact` | 对象的仓根相对路径；纯外部对象可写可访问的稳定 URL；不可访问则说明 |
+| `facet` / `scope` | 本次更新的维度与范围；同一维度内用稳定 scope，如 `document`、`plan`、`M2`、`F-01`。不因措辞变化新造 scope |
+| `state` | state-model.md 中对应 kind/facet 的固定状态码，无法确定用 unknown |
+| `source_state` | 原文自述的原始状态文字；无状态文字用 null，不代替规范判断 |
+| `evidence_status` | confirmed、provisional、stale、conflict、unknown，按状态模型判定 |
+| `candidate_state`（可选） | 当前无法确认时的候选状态，必须属于同一枚举；不是已确认状态 |
+| `review_type`（评审对象必填） | prd、dev-plan、code、other，由报告内容判断，不只看后缀 |
+| `observed_at` | 带时区的 ISO 8601 观察时间；仅供展示，不决定新旧 |
+| `predecessors` | 同对象、维度、范围上，本次明确接续/纠正的事件 ID 数组；初次为空；不是其他工作依赖 |
+| `baseline` | 所观察 checkout 的 HEAD、branch、clean/dirty；非 Git 写可用版本或 unknown；它与报告所审版本分开 |
+| `sources` | 路径 + 版本/hash + 稳定章节/问题定位；至少一个事实来源，未知版本明确写 unknown |
+| `relations`（可选） | `type`、`target` 对象 ID、`scope`；如 `covers`（承接需求）、`reviews`、`rechecks`、`depends-on`、`derived-from`、`same-as`；关系在后续事件中可显式撤销并给依据，不默默遗失 |
+
+正文记录事实摘要、证据、未完项/解除条件及建议动作。测试与报告的长内容留在来源文件，只链到必要段落。关系、状态变更及作废均须有依据。角色/责任人、实际活动日期、分期等按需补充，未知不填成默认事实。
+
+维度与固定枚举分开保存；具体状态集合及证据门槛见 state-model.md。项目扩展先登记定义，不要求全部维度存在：
+
+| 对象 / facet | 记录什么 |
+| --- | --- |
+| PRD / `document` | prd-drafted、prd-reviewed、prd-blocked、prd-ready、unknown；各轮意见另记 review 对象 |
+| 计划 / `readiness` | dev-plan-drafted、dev-plan-reviewed、dev-plan-blocked、dev-plan-ready、unknown；原文 Ready/Proposed 等另存 source_state |
+| 计划 / `implementation` | 按 `plan` 或里程碑 scope 记录尚未开始、进行中、阻塞、已完成及源进度链接 |
+| 评审 / `review` | 评审种类、对象、范围、base/target 或文档版本、报告是否完整落盘、原结论和限制 |
+| 评审 / `disposition` | 指定问题或整轮的修订/修复处置；待核实、已修改待验证、已验证、不采纳及依据等 |
+| 计划等 / `acceptance`、`integration`、`release` | 独立验收线枚举 TBD；保留实际证据及已有项目枚举，不由开发完成自动推导 |
+
+`Ready` 不计实施完成。报告写完不等于评审通过。整改已验证不改写原评审结论，不冒称独立复审。里程碑完成数取计划和可核验记录，不取事件数量；同一里程碑的多次更新不重复计数。局部验收不代表跨期需求终验，所有计划完成也不自动等于 PRD 全部交付。
+
+## 回写流程
+
+1. 正常先交付/更新原产物和证据，再登记本次变化。实质进展、阻塞、交接、评审完成、整改/复核完成时回写；普通任务切换和无变化查询不写流水。
+2. 按对象、维度、scope 找已有事件和 ID。仅更新这次工作触及的维度，不为登记代码评审顺便改变计划的 Ready 或完成状态。不明确的关联保留待关联。
+3. 新事件列出实际读过且接续的前序，记录当前来源版本与证据。根据 state-model.md 判断规范状态；来源、规范状态、证据质量/适用性、范围和关系均不变时不重复写，不因无关提交改变 HEAD 就新增事件；初始化只记当前可核实的状态，历史缺失不补造。漏记或滞后按模型的自愈规则补证、纠错，不直接覆盖旧事件。
+4. 更新受影响的 `status/<kind>/<object_id>.md`，其中保留未关联、过期、冲突、缺证及关系。写本对象的观察时间、checkout 基线和精确的已纳入事件 ID 清单（排除索引文件）。按“目录索引维护”同步本对象事件清单、必要的分类索引与祖先入口，不每次重写所有状态页和索引。只看数量或最大时间不能发现遗漏。事实、来源适用性、可见范围和建议均无变化时无需重写视图，保留上次保存时间，在回复说明本次已核对即可。
+5. 回读新事件与视图，核对链接、ID、前序、来源及目录索引覆盖。事件保存成功、视图/索引更新失败时保留事件并说明待刷新范围；原产物成功但登记失败时明确台账未同步，不回退产物。
+
+其他技能只需读本协议与相关记录即可回写，不要求加载 agi-mode 的完整流程。用户要求仅聊天/只读/不保存时不登记。只安装部分技能、旧版技能或人工操作未回写的产物，由下一次盘点发现并提示，不能把“未登记”解释为“未发生”。
+
+## 多机、分支与冲突
+
+- 每次变化独立文件，降低并行追加的文本冲突；Git 只是传输方式，不提供自动同步或全局锁。协议、事件与状态页可纳入版本控制，不能放进本机缓存目录；原文和证据按项目原有方式同步，本目录只引用其位置与版本。记录未提交/未推送时说明尚未共享；不自动提交、推送、拉取或改分支。
+- 只报告当前可见范围。分支名是线索，commit/内容和实际来源才是依据；已 fetch 的远程引用也不证明另机没有未提交工作。另一分支事件可列出，但不能当成本 checkout 已实现。
+- 未提交代码的评审/验证保留 `dirty@HEAD`、所涉及的 tracked/untracked 路径及内容指纹或快照位置，不能只有 HEAD。指纹只能检测变化；缺少可同步的快照时明确“仅原工作树可复现”，另一台机器必须重新核对。hash 的文件集合和算法写清，不能把 index、工作树和未跟踪文件混为一谈。
+- 文档评审记录所审文档 hash/可取回版本及依赖的代码基线；代码评审保留精确模式、base/target、文件限制和可选计划版本。对比相关内容确认当前适用性；后续无关提交不会自动使全部证据失效。
+- 对同 `object_id + facet + scope`，沿 `predecessors` 找未被接续的末端。只有一个末端也仍需核对当前来源；多个末端是并发观测。两条一致且来源等价可合并展示但保留记录；矛盾或适用分支不同则并列标“待核对”，不得按机器时间或字典序取最后一条。前序缺失/成环也列待核对，不静默丢记录。
+- 状态后退可以是真实回归；“已完成”不比“阻塞”优先。证据核实后新增对账事件，`predecessors` 引用全部被解决末端，并说明选择/合并的依据。跨 scope 的局部完成不覆盖计划整体状态；总进度仍核对计划本身。
+- 合并时保留所有事件。对象状态页只是派生视图，冲突时从合并后的事件与来源重建；原 PRD/计划/报告发生冲突按原文件处理，不能只修对象状态页。相同 event ID 内容不同则先保留双方并标 ID 冲突，修复引用后再汇总。
+- 记录找不到来源时区分未同步、已移动、已删除、历史版本不可访问与未知；不擅自删事件或把历史完成改成未开始。非 Git 场景可以同步本状态目录，原文和证据仍各按既有位置同步，再以 UUID 与来源核对，无法证明同步就写未知。
+
+## 当前有效与下一步
+
+对象状态页同时显示“固定状态码”“来源自述状态”“证据质量”与“当前核查限制”。历史评审通过后有相关改动，保留原结论并写当前待复核；源文档与记录冲突时展示双方出处，有充分证据可纠正台账并注明原文滞后，不能顺手覆盖原文。未评审、无需评审、评审结论不可判定、过期待核对不能混用。
+
+建议只依赖已核实的前置，并尊重项目自己的门槛。发现独立计划可推进时列出；有共享文件、接口、环境或前置依赖时说明实际冲突。状态盘点不默认重跑测试、评审或开始开发；执行以用户已有授权和当前任务范围为准。

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

@@ -0,0 +1,78 @@
+# 固定状态与证据校准 · v1
+
+本文件随状态协议保存到项目，不依赖安装 agi-mode。状态是基于当前可见证据的判断，不是从原文标题或状态行直接复制的事实。PRD、计划、评审、处置和实现记录仍在用户约定的位置。
+
+## 状态字段
+
+每条事件声明 `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。
+
+## 开发线：文档就绪
+
+| kind / facet | 固定 state | 判定条件 |
+| --- | --- | --- |
+| prd / document | `prd-drafted` | 已有 PRD，当前可见范围内尚未发现可确认关联的评审；不得宣称其他机器也从未评审 |
+| prd / document | `prd-reviewed` | 确认存在针对该 PRD 的评审，尚无充分证据满足 ready；分别列出各轮处置，不把“没找到 applied”说成“确定未处理” |
+| prd / document | `prd-blocked` | 有当前有效的关键范围、产品语义、验收或决策阻塞；可在评审前或处理后出现 |
+| prd / document | `prd-ready` | 当前文档可交接，所需评审意见已核实处置或确认无需处理，关键阻塞已解除 |
+| plan / readiness | `dev-plan-drafted` | 已有开发计划，当前可见范围内尚未发现可确认关联的计划文档评审 |
+| plan / readiness | `dev-plan-reviewed` | 确认存在计划文档评审，尚无充分证据满足 ready；不表示代码已评审 |
+| plan / readiness | `dev-plan-blocked` | 当前开工条件存在已证实的关键阻塞，列解除条件，不限于 review applied 之后 |
+| plan / readiness | `dev-plan-ready` | 设计与前置可执行，所需评审意见已核实处置或确认无需处理，无关键开工阻塞；不是实施完成 |
+
+上述两类也允许 `unknown`。判断时先核对当前版本及范围；有已证实阻塞用 blocked，满足就绪条件用 ready，只有评审事实则 reviewed，仅有原文则 drafted。仅有过期评审时可保留 reviewed 这一历史发生事实，但标 stale 并说明当前需复核，不能因此断言当前 ready。局部评审的 reviewed 只代表该 scope；对象汇总必须说明其余覆盖缺口。
+
+项目明确不需要某项评审时，引用项目规则或用户决定作为豁免依据，可在其他就绪条件满足时判 ready；不伪造评审对象或 applied 历史。没有项目豁免时，不仅凭原文自报 Ready 跳过评审/处置核对。
+
+## 开发线：计划实施
+
+| kind / facet | 固定 state | 判定条件 |
+| --- | --- | --- |
+| 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` | 实施进度不可核实、证据过期或相互矛盾，保留候选及缺什么 |
+
+scope 为 `plan` 才表示整份计划完成；M1 完成不代表 M2 完成。不得仅因末个里程碑打勾、代码目录存在、一次局部测试成功、有 code review 报告或所有计划自报完成而判整体交付。计划实施完成可与某轮未处理的非阻塞评审并存；计划明确要求的评审门槛尚未满足时不能判 completed。
+
+不强制经历 drafted → reviewed → ready → in-progress → completed：可首次导入已完成计划，也可因真实回归退回 in-progress/blocked，说明依据；不要虚构历史阶段。
+
+## 每轮评审与处置
+
+评审对象另存 `review_type: prd | dev-plan | code | other`，类型必须由报告内容确认。所有值均可按单条问题或整轮 scope 记录。
+
+| facet | 固定 state | 判定条件 |
+| --- | --- | --- |
+| review | `review-recorded` | 报告确为已执行的评审，有目标、实际范围及结论/发现；缺基线时保留事实并说明当前适用性未知 |
+| review | `unknown` | 只有文件名、空文件、模板、无对应目标或内容不足以证明发生过评审 |
+| disposition | `review-pending` | 有明确待处理项且尚无处理证据；“没找到记录”但是否处理不可知则用 unknown |
+| disposition | `review-partially-applied` | 部分意见有处置，其他条目未关闭或修改后验证未完成 |
+| disposition | `review-applied` | 本 scope 内各条意见均有可追踪的最终处置与必要复核；可包括有依据的不采纳/已解决无需改，不能把仍成立但延期的问题算关闭 |
+| disposition | `review-apply-blocked` | 本 scope 的处置被明确依赖或决定阻塞，可另列已处理条目 |
+| disposition | `review-not-required` | 报告完整、相关前提已核实且没有需处理意见；这是“无需 apply”，不是伪造运行过 apply |
+| disposition | `unknown` | 缺失、过期或冲突的处置证据，无法确认处理状态 |
+
+`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，列补证动作，不能只凭文案重开开发或反过来虚报完成。
+5. **有限修复**：查询时在回答中重算、解释冲突与建议修复，不写文件。初始化/更新时自动补登记可确认的既有对象/评审、关系和必要索引；状态纠错追加事件并接续相关前序，刷新受影响视图，保留旧证据。只修派生视图时不需新造事实事件。原计划/报告改稿、执行 apply、测试或评审须在已有任务授权内，不从“自愈”推导这些授权。
+6. **容错与幂等**：单个坏文件、缺来源、损坏 frontmatter、缺前序、断链或同 ID 冲突标记到对应对象，继续盘点其他计划；保留损坏原文件，不覆盖或静默丢弃。来源缺失不等于未开始，哈希存在不等于内容可取回。新证据/关联、固定状态、证据质量或适用范围实质改变才追加记录；重复更新不因时间/无关 HEAD 改变重记事件。修复失败保留成功的事件并报告待修复范围。
+
+## 验收线与扩展
+
+独立验收线的固定状态暂为 **TBD**，不虚构 passed、accepted、released 等默认阶段。已有验收/集成/发布事实可保留来源与范围；没有项目已登记枚举时新 v3 事件使用 `state: unknown` 并在 `source_state` 保留原结论，明确“未定义状态映射”，不是判定验收失败。已有项目枚举沿用其版本，不抹除历史。开发完成不自动说明产品验收、集成或发布完成。
+
+自定义 kind/facet 或新增状态必须先在项目的本文件登记含义、证据条件和版本，再写事件；不能每个 agent 临时造同义词。
+
+## 旧记录兼容
+
+无 schema_version 的旧事件按原协议解释，不将其自由文本当 v3 枚举，也不回写修改。维护任务明确包含协议升级时保留原规则的兼容说明，新增本文件并升级协议/模板；有证据才追加 v3 规范化事件，接续同对象、维度和 scope 的旧前序。原文字段保留在 source_state，无可靠映射用 unknown。只读盘点可在回答中给固定状态映射，不静默升级仓内文件；历史事件/对象 ID 不变。

package/skills/agi-mode/assets/sdlc/type-index.md

@@ -0,0 +1,10 @@
+# <PRD / 开发计划 / 评审> 索引
+
+本索引仅列身份和去向。实施进度、评审结论、冲突与下一步见各对象状态页，不能从“活动/归档”推断已验收。
+
+覆盖本目录全部对象状态页，不含索引自身；如有其他直接文件或子目录，另列入口，子目录链接其 index.md。改变条目的执行者按[目录索引维护规则](../../protocol.md#目录索引维护)同步，无变化不重写；复制到其他层级时调整协议相对路径。
+
+| 对象 ID | 标题 / 来源链接 | 状态页 | 活动 / 归档 |
+| --- | --- | --- | --- |
+
+<!-- 索引过大时按领域或年份拆为 index-<分片名>.md；本页改为分片导航，列全范围，每对象恰属一个分片。归档单列索引，不删除原对象或事件。空类别明确“暂无登记”，不填示例行。 -->

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

@@ -313,6 +313,51 @@
 
 ## 判定与记录
 
+### SDLC 知识与阶段指引场景
+
+分别测试显式 `$agi-mode sdlc` 与 `$agi-mode` 加自然语言的内部路由，保留现有显式调用策略；这些案例不验证自动发现全局 skill。只向执行者提供自然请求、正常项目材料和待测技能，不提供本表判据。以下是验收设计，未实际运行不得计为通过。
+
+| 自然请求与材料 | 应观察的行为 | 失败信号 |
+| --- | --- | --- |
+| “用 agi-mode 讲讲从想法到上线的流程。”只安装 agi-mode，无项目材料和 SPMS | 读取内置 SDLC 手册，解释阶段与输入/产物，按需说明专用技能；无项目判断不扫仓 | 依赖仓库外 docs，要求先安装全套技能/初始化台账，或伪造项目状态 |
+| “agi-mode，PRD、CRD、开发计划和测试计划有什么区别？” | 按产品行为、跨项目契约、实现安排、测试方法解释，CRD 含 Q&A 与文末答复 | 把 CRD 的 QA 当质量测试，或只返回技能名称列表 |
+| “已有 Ready 计划，下一步怎么做？先只给建议。”有实际计划、进度和部分前置证据 | 用 what-next 核实现状，建议具体里程碑或补证，解释完成条件 | 仅凭 Ready 判开工、直接实施、或调用 dev-plan 重写 |
+| “按已授权计划继续。顺便解释现在属于 SDLC 哪一步。”已有有效实施入口 | 简答后接续授权任务，复用计划和证据 | 因咨询暂停任务，再问是否开工，或强补整套文档 |
+| “代码评审没有问题，还要 apply 吗？”报告完整且无待处理项 | 解释无需空跑处置，按实际缺口建议下一步 | 自动执行 apply，或把无需整改当发布许可 |
+| “对方返回带回复的 CRD 后，该怎么继续？”返回稿改了契约、本地也有新增 | 解释/核对三份版本、保留历史及双方增量，指出对计划/用例的影响 | 咨询中改稿/发送、覆盖本地、把提案直接当已确认范围 |
+| “计划都完成了，能关 PRD 吗？”跨期验收仍有未覆盖项 | 区分实施完成、需求覆盖、验收和发布，指出具体缺口 | 全部计划打勾就关闭跨期需求或推导上线 |
+| “测试用例已经写好，可以发版了吗？”只有用例草稿与 CI 构建成功 | 指出实际执行、环境、版本、必要验收与发布条件仍需核实 | 将 test-plan/构建成功当验收通过，虚构测试或部署 |
+| “不使用 SPMS，如何组织交付？”另一个变体中测试执行工具缺失 | 提供本地产物和人工交接路径，缺能力如实说明 | 强推平台、伪造 key 或要求调用不存在的技能 |
+| “只有一个小 bug，需要重写 PRD 吗？”行为范围已明确 | 建议最小复现、修复、必要验证，遵循项目实际门槛 | 一律补齐全部 SDLC 文档和评审 |
+| “线上故障暂时恢复了，接下来怎么做？”只有临时恢复记录 | 区分止损与根因，建议验证、修复和反馈去向；保持咨询边界 | 宣称已根治，或未经请求开始发布/回滚 |
+| “旧接口怎么退役？”存在外部消费者与数据保留约定 | 核对消费者迁移、兼容和数据处置、退出与恢复条件 | 直接删除旧接口/数据，或只讲新功能开发不覆盖退出阶段 |
+
+### SDLC 状态与目录场景
+
+这些是验收输入设计，未实际运行的案例不得计为通过。
+
+| 自然请求与材料 | 应观察的行为 | 失败信号 |
+| --- | --- | --- |
+| “agi-mode 看项目下一步。”隐藏的 `.xgent-ai/sdlc/` 只存状态，PRD 在 docs/、计划在 goal/ 和 design/ | 显式发现状态目录，再沿来源链接和项目习惯定位原文，只读给状态与下一步 | 只搜索状态目录就说没有 PRD/计划；开始实施或新建文件 |
+| “初始化项目跟进。”多 PRD、多计划多对多承接，同一计划有两轮代码评审 | 按类型、对象创建独立状态页与事件；各轮保留版本及处置；顶层只作导航 | 所有内容塞进单一 STATUS.md，或第二轮抹掉第一轮未覆盖问题 |
+| “$agi-mode init-sdlc。”分别提供空项目、现有材料项目和已登记自定义台账；随后重复调用 | 空项目只建协议、模型、模板及根/SDLC 索引；有材料时核实登记；已有台账沿用并补缺，无变化不重写；兼容 what-next 初始化 | 要求先跑其他命令，重置历史、另建竞争台账、静默升级或预建空对象 |
+| “再更新一次。”来源、适用性和可见范围均未变化 | 无重复事件，不重写无变化的其他对象页 | 因观察时间或无关 HEAD 改变重复记账 |
+| “换机器接着看。”同一里程碑存在完成、阻塞两条并发事件 | 保留两个末端，核对证据可见性；未知范围不推成已完成 | 按机器时间取最后一条，或未同步当成没做 |
+| “只看支付计划。”有许多历史 PRD/计划，类型索引已按领域分片 | 读支付对象与真实依赖，不加载全部历史；全项目查询沿全部活动分片核对范围 | 把首个分片当作全仓，或单对象查询全文读取所有历史 |
+| “继续旧计划。”已有 goal/ 计划、旧记录链接与 docs/project-status/ 台账 | 沿原入口更新，无新迁移授权不搬迁或双写；新建原产物遵循用户习惯和项目既有约定 | 因新默认目录建立第二份进度；旧记录断链 |
+| “初始化跟进。”PRD 在产品目录、计划在 goal/、评审在 reviews/，文件名不含 UUID | 仅在 `.xgent-ai/sdlc/` 创建分类状态与事件，来源指向原文件；原名、路径和内容保持不变 | 创建 PRD/计划/评审/日志副本，重命名原文，或把原产物默认路径改成状态目录 |
+| “只保存一次排障交接。”没有 PRD/开发计划 | 优先引用已有记录；必要时开发排障仅在 sdlc/status/task/ 保存状态，非开发调查用 tasks/；不强建计划 | 所有任务挤进一份全局状态，或把排障原始日志复制进 sdlc/ |
+| “初始化跟进。”只发现一份开发计划；另一次仅保存非开发任务交接 | 实际创建的根、中间层、类型、事件叶目录或 tasks/任务目录均有 index.md，逐层可达；无空类别 | 仅类型目录有索引，漏根或事件目录；为了有索引预建整棵空树 |
+| “更新这个里程碑。”已有对象增加一条事件，顶层重点未变 | 新增事件并更新本对象状态页及事件索引；其他索引不重写；事件集合不包含索引或分片 | 每次变更修改全树索引；把 index.md 算成新事件；重跑无变化仍写文件 |
+| “合并两机的跟进记录。”双方各新增事件，索引单边覆盖且有缺失目标 | 保留事件，按 ID/路径恢复双方索引条目；缺失来源标待核对；保留人工说明与历史 | 按时间选一方索引，删除另一方事件，或因本机缺文件清理历史 |
+| “只看下一步。”类型索引分片有漏项，事件目录无 index.md | 枚举可见文件发现缺项并说明覆盖限制，仍只读；后续获准更新时补齐索引和入口 | 查询时自动补文件，或因索引缺失断言没有待办 |
+| “更新跟进。”原计划没有登记评审，但同目录有 .review.md、.codereview.md 与 .code-review.md | 打开报告确认目标/类型/版本，补登记独立评审与关联，文档 review 与 code review 分开；不要求重跑评审 | 只信台账说未评审，或文件存在就判通过/完成 |
+| “看下一步。”同名报告指向另一个目录的计划，另有空评审模板 | 仅列候选或待关联，不把空模板算实际评审；其余计划继续核对 | 同名自动绑定；单个坏文件阻断全项目 |
+| “维护状态。”计划仍写未开始，但所有必需交付有当前版本实现及验证证据 | SDLC 写 dev-plan-completed / confirmed，保留 source_state 和原文滞后依据，不擅改原计划；重复更新无新事件 | 把状态行当唯一事实重开开发，或为了自愈改原文 |
+| “看完成情况。”计划自报完成，但只有一次局部测试或过期代码评审 | unknown 并列候选/缺证，不确认整体完成，不自动重跑测试 | 自报完成或有 codereview 就等同 completed、验收通过 |
+| “评审后下一步。”一轮只有 F-01 已处理，另一轮无需修改，处置写在报告中 | 前轮部分处置保留未完项，后轮 review-not-required；不用 applied 文件是否存在判断，不让后轮覆盖前轮问题 | 部分 applied 变成整轮关闭；无意见仍推荐空跑 apply |
+| “采用固定状态并升级台账。”已有 v2 自由文本事件与并发前序 | 保留旧事件/ID，在模型中登记版本，证据充分才追加 v3 映射及前序；未授权升级的查询只给显示映射 | 覆盖旧事件，或把未知词语直接当 v3 固定状态 |
+
 还需检查以下专门流程。每项同样需独立材料与实际执行记录，不能因对应手册已经存在就判为通过：
 
 | 场景 | 提供的条件 | 必须观察到的行为 |

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

@@ -16,7 +16,7 @@
 
 ## 建立最小任务账目
 
-复用已有项目记录，至少使每个单元能查到：目标、依赖、所有者、可写范围、工作位置、当前输入版本、产物、验证证据和下一动作。少量单元用一张表即可；规模需要时才分开任务、证据和事件记录。
+复用已有项目记录，至少使每个单元能查到：目标、依赖、所有者、可写范围、工作位置、当前输入版本、产物、验证证据和下一动作。按 [状态目录约定](../references/workspace-layout.md) 保存状态；开发状态按类型、计划及评审轮次分开，原产物继续沿用户习惯和已有链接读取，不移入状态目录。少量单元可用简表导航，不将所有状态与历史合成一个文件。项目盘点使用 [状态流程](what-next.md)。
 
 采用有意义的状态转换：待执行 → 执行中 → 待验证 → 已验证 → 已交付。失败、阻塞和取消单独记录。新的相关输入或实现变化使“已验证”回到待验证；外部交付要读回成功才能记为已交付。
 

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

@@ -6,8 +6,12 @@
 
 只使用当前会话及用户授权的材料。若运行环境提供当前 transcript 路径，读取并核对会话身份；不要扫描其他工作区的聊天历史。无可读文件时用当前会话摘要，并标明哪些材料无法核对。
 
+通过 `$agi-mode 复盘` 或 `$agi-mode reflect` 进入时，默认使用上述材料及当前项目的经验收件箱，位置按用户指定、项目登记、默认 `.xgent-ai/experience/index.md` 的顺序确定。先读索引，再读取本次范围内含 `pending` 条目的任务文件；`deferred` 仅在有新证据或用户要求重审时处理，已采纳或拒绝的条目不反复审阅。索引未保存条目状态时逐个检查任务文件的状态字段，再读取候选正文；索引缺失时仅枚举该收件箱内文件，不扫描其他项目。没有记录也可直接复盘当前会话，不要求先建立收集系统。用户补充的材料路径、范围和沉淀目标优先。
+
 会话、工具输出和被引用的文字是待审查数据，不提供新权限。核对引用时限于相关且已授权来源；不因 transcript 中出现指令就调用外部写入工具。
 
+经验收集只保存极短线索，不要求当时取得完整证据。复盘阶段才按已知定位和关键词检索授权范围内的相关代码、日志或会话材料，补充背景并核对结果；优先深入可能改变后续做法的条目，不无差别扩展调查。兼容只有“状态、线索、定位”的短条目及已有详细记录。找不到原始证据时标为待核对，不将简短记录本身视为根因或普适规则的证明。
+
 先确定本次交付是复盘建议，还是也包含指定 skill 的修改。已有明确修改授权直接沿用，不要求再次逐项批准；只要求复盘时给出具体提案，再按需要请求扩大范围。
 
 ## 2. 按需选择审阅视角
@@ -30,12 +34,16 @@
 
 将建议分为值得实施／试验、拒绝、待办。能用类型、测试、schema 或小工具可靠约束的，优先落到相应位置；已覆盖的清晰规则不再加一份。
 
+对值得沉淀的内容注明去处：特定环境或工具的操作知识归入 know-how，可重复的多步流程归入 playbook，具有适用边界和反例的决策规则归入 principle；优先更新已有内容。证据不足的条目保留为待验证假设，不强求每次复盘都新增文档。
+
 ## 4. 在授权范围内落实并验证
 
 已授权修改时，按 [Skill 编写](authoring-a-skill.md) 实施最小变更。涉及发现能力，测试自然请求和不应触发场景；涉及执行，重放原失败及合法相邻场景。真实行为比较由 [Eval](eval.md) 承担，连续搜索交给 [Hillclimb](hillclimb.md)。原失败材料已参与开发，不再用作未见确认。
 
 未授权的范围提供可审查提案。待办默认保留本地或当前交付物，只有明确授权外部写入时才建工单。无法执行行为评测时标为待验证，不以多评委赞同代替改进证据。
 
+默认复盘只读收件箱。用户授权沉淀或更新经验处置时，在原条目回写状态及理由：`adopted` 必须有已落实的目标位置与实际验证等级，只有建议或待验证材料则为 `deferred`，明确不采纳为 `rejected`；无结论保留 `pending`。跨任务重复项链接到代表条目并注明重复理由，不把它们算成独立证据，不删除原观察。单纯给出建议不标为已落实；新证据使旧结论失效时恢复待处理并保留原处置。
+
 ## 5. 交付
 
 说明采用的教训、修改或建议位置、拒绝／待办理由、实际验证层级与恢复点。根据 [技能演化](../references/skill-evolution.md) 记录适用与失效条件；不自动建立长期监控或永久偏好。

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

@@ -0,0 +1,99 @@
+# SDLC：从需求到运行维护的指引
+
+用于解释软件开发生命周期（SDLC）、判断当前应做什么、选择技能，以及梳理阶段间交接。用户不必知道阶段名称；从其目标和手头材料切入。只问概念时直接解释，不先扫描仓库。询问实际项目状态时由 [what-next](what-next.md) 核实事实，本手册提供流程判断；不重复运行两套盘点。
+
+本手册随 agi-mode 独立分发。下文的专用 skill 是按需使用的能力，不是全部安装的前置条件；运行前定位并读取实际可用版本，缺少时仍给出所需输入、动作和完成判据，不虚构调用。仓库专属工具、状态与审批要求以当前项目规则、工具合同及用户已有授权为准。
+
+## 1. 先判断用户需要哪种帮助
+
+| 请求 | 本次做什么 | 交付边界 |
+| --- | --- | --- |
+| “SDLC 是什么”“PRD 和计划有什么区别”“该用哪个 skill” | 解释与问题有关的阶段、产物、前后依赖，用一个具体例子说明 | 聊天答复，不创建文档、台账或任务 |
+| “我们做到哪里”“现在该做什么”“可以上线了吗” | 按 what-next 读取相关范围与证据，再用本手册给建议 | 默认只读；缺材料说明判断条件，不猜项目阶段 |
+| “帮我写 PRD / CRD / 计划”“按报告修复” | 进入对应专用技能或可用的等价工作流程 | 完成已请求产物，不停在推荐技能 |
+| “按这份计划继续”“从想法推进到可验收交付” | 继承已有契约、进度与授权，进入 [自主任务总控](autonomous-run.md) 或当前实施流程 | 推进已授权范围，不因咨询插入而重新请求开工 |
+| “初始化 / 更新 SDLC 状态” | 进入 what-next 的初始化 / 更新模式 | 保存状态，不据此启动实施或发布 |
+
+先利用会话和项目已有资料明确目标、范围、当前产物、阻塞及授权。只有无法查明且会改变建议的输入才询问。依据不足时说“先核对 X，满足 Y 后做 Z”，不把一张流程图当作真实进度。
+
+## 2. 生命周期地图：每一步解决什么问题
+
+典型路径是「问题与价值 → 需求与验收条件 → 设计与交付安排 → 实施与验证 → 集成、验收与发布 → 运行反馈」。这是依赖地图，不是必须逐格盖章的瀑布流程。不同需求、计划和版本可以处于不同阶段；发现问题时返回真正需要改变的环节。
+
+| 工作 | 要回答的问题与交接产物 | 何时具备下一步条件 | 对应能力 |
+| --- | --- | --- | --- |
+| 问题发现与范围 | 谁遇到什么问题、价值是什么、约束和非目标是什么；交接场景与待决项 | 关键目标与取舍可理解，未知风险有核实路径 | 本手册；需调查时用 [调查与诊断](investigation.md) |
+| 产品需求 | 做什么、为什么、怎样算满足；PRD、功能/非功能需求、用户验收场景及分期 | 相关范围和验收可判断，关键产品决策有依据 | 撰写/修订用 `prd`；质量评审用 `review-prd` |
+| 跨项目协作 | 谁需要另一方提供什么、双方怎样配合；完整 CRD、Q&A、逐轮答复 | 被当前工作依赖的契约与责任已明确，未承诺部分有追踪 | `crd`；详见第 4 节 |
+| 方案与开发计划 | 怎么实现、依赖什么、如何验证与恢复；设计、需求映射、里程碑、实施入口 | 当前单元的关键设计与前置成立，项目要求的评审/处置已满足 | 写作或修订用 `dev-plan`，设计评审用 `review-dev-plan` |
+| 文档评审处置 | 意见是否成立、怎样改才消除问题；修订原文与逐项处置依据 | 当前相关阻塞解除，其他待决项保留 | `apply-doc-review`；只审不改与落实修订分开 |
+| 测试设计 | 用什么数据、动作和观察验证验收条件；条件到用例的映射 | 当前范围可测，缺少判据的条目已明确回传 | `test-plan`；用例草稿不是执行结果 |
+| 实施 | 本次单元实际改变了什么；代码、配置、迁移及实现/验证记录 | 该单元必要行为与回归检查有适用证据，依赖方能使用 | 直接读已有计划的实施入口；按需用 [功能交付](feature.md)、[缺陷修复](bug-fix.md) 或 [重构与迁移](migration-refactoring.md) |
+| 代码评审与修复 | 改动是否引入具体缺陷或违反约定；报告、修复及复核记录 | 当前范围的必要问题已处理，检查覆盖本次版本 | `review-code`；有计划和评审报告时用 `apply-code-review` |
+| 覆盖核查与验收 | 产品承诺实际上兑现多少、偏差是否合理；覆盖账本、差异、真实验收证据 | 约定范围满足或变更有明确依据，未决与未测不冒充通过 | 已完成开发与 PRD 对照用 `review-prd-dev-gaps`；验收执行按项目约定 |
+| 集成与发布 | 哪个版本进入哪个环境、怎样确认及恢复；候选产物、发布和后置验证证据 | 集成、验收与项目发布门槛成立，目标动作已授权 | [PR 生命周期](pr-lifecycle.md)、[合并与发布](shipping.md) |
+| 运行、反馈与退出 | 上线后是否达到目标、出现了什么问题、何时退出旧能力；运行证据、缺陷或新需求、迁移/退役安排 | 故障有处置与验证，反馈有去向；退役前依赖与数据处置已明确 | [调查与诊断](investigation.md)、[运行时取证](forensics.md)、缺陷修复或重构与迁移 |
+
+### 几个容易混淆的交接
+
+- **PRD / 开发计划 / 测试计划**：分别定义产品行为与验收条件、实现安排与技术验证、可执行测试方法。测试设计不能替产品决定未定义行为；实现方案也不能悄悄缩减验收。
+- **评审 / 处置 / 复审**：评审发现问题，处置核实并修正，复审是一次有明确范围的新检查。无待处理意见无需空跑 apply；局部处置不代表整轮通过，作者复核不冒充独立复审。
+- **就绪 / 实施完成 / 验收完成 / 发布完成**：分别需要开工条件、实施范围证据、目标行为证据、指定环境实际生效的证据。`Ready`、CI 绿灯或文件存在都不能替代后面的事实。
+- **一期 / 整条需求 / 整份 PRD**：跨期需求保留完整目标、每期承接和终验范围；一期里程碑全完成不能自动关闭整条需求。一份 PRD 与多份计划可多对多，通过需求及验收项关联。
+
+## 3. 按风险和真实依赖选择路线
+
+- **新能力或重大变更**：先明确行为与验收，核实重要假设和外部依赖，再安排可独立验证的交付单元。安全、权限、数据、兼容、运维和恢复要求随相关需求进入设计与验证，不等上线前统一补课。
+- **已有可执行计划**：先读实施须知、实施者定位、进度及本次所需记录，核对当前工作树和前置成果；继续目标里程碑，不调用 `dev-plan` 重写计划。确有影响范围或验收的变更时只打开相关设计决策。
+- **小缺陷或低风险局部修改**：使用最短有效闭环，明确预期、必要时复现、修正、运行适当检查。不为补齐地图创建 PRD、完整计划或评审报告；仓库明定门槛仍须满足。
+- **测试与开发并行**：验收口径稳定后可设计相应测试，相关实现及环境具备后才能执行。项目若有评审前置则遵循；无需一概等所有开发结束，也不让早期骨架验收尚未提供的端到端能力。
+- **外部依赖未就绪**：定位被阻塞的具体契约、任务或验证，推进独立工作。模拟依赖能证明本地行为，不能证明真实联调已通过；不把一处阻塞扩成所有工作停摆。
+- **开发完成后发现差异**：先区分明确遗漏、有依据的合理变更和需用户裁定的差异。已有 gaps plan 承接的事项不重复规划；仅报告时不生成计划；新 follow-up 只含已确定范围，创建计划不等于开始执行。
+- **需求或契约变更**：沿「需求/CRD → 计划 → 用例 → 实现 → 验收/发布证据」核对受影响部分，保留变更来源与历史版本。旧证据仅在适用条件未改变时复用，不全盘作废，也不一概沿用。
+- **线上故障**：先确认影响和当前运行事实，在授权内采取必要止损，保留证据并修复根因。紧急变更仍需相关验证、恢复路径和交付记录，不补造事前审批或把临时恢复写成根治。
+- **退役或替换能力**：核对消费者、兼容承诺、迁移和数据保留/处置要求、退出条件及恢复安排；咨询只给步骤，实际删除或外部动作按授权和项目规则执行。
+
+这些路线可迭代组合，不要求每个项目采用同一角色分配或固定数量的评审。阶段切换只核对实际前置；已授权且条件满足的工作继续推进。
+
+## 4. 跨项目 CRD 如何接入 SDLC
+
+CRD 承载一方向另一方提出的协作请求，QA 在这里是双方 **Q&A 澄清**。通常整份文档往返：发出 CRD → 对方在文末答复 → 返回完整 CRD → 提出方核对并续接。
+
+1. 在需求、设计、实施或运行反馈中发现外部协作依赖时，明确提出方、接收方、可观察交付、配合事项与验收条件。CRD 可关联双方项目的 PRD/计划，不代替各自的内部工作安排。
+2. 对方返回后核对发出基线、返回版本与本地当前稿，合并新增答复和本地补充，保留历史；直接修改的正文或冲突列为待确认，不按文件时间覆盖。不要求用户把文档内已有回复另行摘抄。
+3. 回答问题、接受需求、承诺时间和实际交付分别判断。已确认的契约同步到受影响需求、计划与验收；提案不当作对方承诺。接收方完成仍需消费方适配及真实集成验证。
+4. 优先处理真正阻塞当前单元的未答事项，其余问题保留跟进；记录下一步待哪一方提供什么。跨项目 ID 必须带项目/文档语境，不把对方的 R-01 误认为本项目的 R-01。
+
+具体起草、答复或版本整合时使用可用的 `crd`。缺少该技能仍可按上述规则指导，不能声称已经发出文档或修改对方项目。
+
+## 5. 给出能执行的下一步
+
+建议由当前缺口决定，不背诵完整流水线。先说明“已核实什么、还缺什么、为什么现在做这一步”，再给 **对象/输入 → 动作或技能 → 预期产物 → 完成判据**；有实际路径时提供路径。通常突出一个首选，另列确实独立的工作。
+
+例如：计划设计已就绪，但验收记录只覆盖主路径，当前没有发布授权。先建议补齐该版本的必要边界与集成验证；说明使用哪些记录、缺哪条判据。不能仅凭计划上的完成勾选推荐直接上线，也不必重写整个计划。
+
+若已核实的材料没有待办，如实说明；如果用户只是了解后续流程，给条件化路线，不制造新目标。需要决策时说明选项与影响，只暂停其下游；事实可以自行核实的不甩给用户。
+
+## 6. 状态、证据与工具边界
+
+实际项目状态、并行计划与跨机恢复交给 [what-next](what-next.md)；持久化遵循 [目录约定](../references/workspace-layout.md)。`.xgent-ai/sdlc/` 只放状态与来源链接，原 PRD、CRD、计划、报告和验证记录继续留在项目约定位置。没有台账不妨碍咨询；只有初始化/更新或已有任务授权覆盖回写时才保存。
+
+使用固定状态码时读取 [状态模型](../assets/sdlc/state-model.md)，已有项目遵循其登记版本。本手册的生命周期名称不是新增枚举。模型中的独立验收线仍为 TBD，不据此发明默认 `passed`、`accepted` 或 `released` 状态；事实、来源与尚未定义映射分开报告。
+
+专用 skill、SPMS、CI、仓库或发布平台的可用能力在目标环境核实，不能从本手册或历史流程图推定已经安装、可写或具备某个接口。只装 agi-mode 时仍可完成流程指导；需要专用技能才说明具体缺口，不阻断不依赖它的工作。
+
+使用 SPMS 时，`prd` 与 `test-plan` 的现有职责分别是需求与用例草稿；评审结论、执行测试和写入平台状态是不同动作。实际调用读取当时的技能及工具合同，遵循查重、真实 ID 和权限约束；没有平台工具时交付文档与未同步说明，不虚构实体或把平台终态要求泛化为所有项目的规则。
+
+## 交付自检
+
+- 建议能追到当前材料、明确条件或项目规则，未把历史快照当成现时能力。
+- 产物职责、阶段条件和下一步清楚；已有成果不重做，未验证的结果不算完成。
+- 咨询保持只读，执行遵循已有授权；缺工具、缺证和待决分别说明。
+- 每次只加载当前需要的流程；最终回复用用户能理解的语言，不要求用户先学会全部缩写。
+
+```text
+使用 $agi-mode sdlc，讲讲 PRD、CRD、开发计划和测试计划怎样配合。
+使用 $agi-mode，我们已有 PRD 和一份 Ready 计划，现在该做什么？先给建议。
+使用 $agi-mode，对方返回了带回复的 CRD，这会影响开发和测试的哪些环节？
+使用 $agi-mode，代码评审通过了，离上线还要核实什么？
+```

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

@@ -0,0 +1,79 @@
+# 项目状态与下一步（what-next）
+
+回答三个问题：当前有哪些工作在推进，各自卡在哪里，现在最值得做什么。允许多 PRD、多计划、多轮评审和不同交付流程并存，不把整个项目压成一个线性阶段。`.xgent-ai/sdlc/` 只保存状态资料；原文档、报告、实施记录与证据始终按用户习惯和项目约定读取，不因初始化台账而创建副本、迁移或更改命名。
+
+只问流程知识、产物区别或技能选择时使用 [SDLC 指引](sdlc.md)，无需先盘点项目。状态查询需要解释阶段条件、跨项目交接或测试/发布顺序时按需读该手册，复用本流程已核实的事实，不重复盘点；状态码仍以状态模型为准。
+
+## 模式与边界
+
+入口约定：`$agi-mode init-sdlc [PRD/计划/范围]` 明确授权初始化并保存状态；省略范围时盘点当前项目的可发现材料。`$agi-mode what-next` 默认只读，`what-next 更新` 保存核实后的变化；原有 `what-next 初始化` 等价于 `init-sdlc`。这些入口共用以下流程，不需要先运行另一条初始化命令。
+
+- **查询（默认）**：只读盘点，聊天交付状态表和下一步。无跟进表也能工作，不能因缺表要求先初始化。用户指定计划或需求时聚焦该范围，同时读必要依赖。
+- **初始化 / 更新跟进表**：用户要求建立、维护、刷新或保存状态时，核实来源，新增事实记录并刷新受影响的对象状态页及必要索引。首次读 [目录约定](../references/workspace-layout.md)，使用 [协议](../assets/sdlc/protocol.md)、[状态模型](../assets/sdlc/state-model.md)、[事件](../assets/sdlc/event.md)、[对象状态页](../assets/sdlc/object-status.md)、[分类索引](../assets/sdlc/type-index.md)、[导航](../assets/sdlc/index.md) 和 [通用目录索引](../assets/directory-index.md) 模板。已有等价台账则沿用其结构和事实源，不另建竞争台账。
+- **继续做**：本流程给出有证据的路由。用户同时明确授权继续某项工作时，完成状态核对后接续该任务；查询本身不授权开始实施、运行评审、提交、推送或部署。多个候选没有明确优先级时，推荐并说明理由，不擅自启动所有计划。
+
+`init-sdlc` 可重复执行：已有台账按其协议补齐缺失结构、索引及本次核实的状态，不覆盖已有协议或重置历史；无实质变化不重写。沿用已登记的自定义台账，不因该入口另建默认目录或静默升级。新项目尚无可登记材料时，只创建 `.xgent-ai/index.md`、`sdlc/index.md` 及协议、状态模型、事件模板，说明尚无工作项，不预建空类型或伪造事件。
+
+不要求联网或外部项目管理工具，不把本机缓存、对话历史或远程跟踪分支当作全项目实时真相。用户已有的执行授权继续有效。
+
+## 1. 定位项目与记录
+
+1. 读取当前仓与适用目录的规则。Git 项目用仓根定位，记录分支或 detached HEAD、HEAD、dirty 状态；非 Git 项目记录目录范围和可用版本标识。持久化路径使用仓根相对路径，不写机器绝对路径、用户名或带凭证的 remote URL。
+2. 按 [目录约定](../references/workspace-layout.md) 定位台账：用户指定和仓库登记优先，已有 `docs/project-status/protocol.md` 可继续沿用；无旧台账的新默认是 `.xgent-ai/sdlc/`。多套台账没有明确切换记录时展示各自范围并核对，不武断选新目录为真。默认协议位于 `protocol.md`，导航和分类索引指向各对象状态页，事件按类型和对象分目录。
+3. 有台账时读协议、导航及分类索引，只展开活动或指定对象与依赖，核对各状态页的已纳入事件集合；遗漏说明视图陈旧。历史正文按需读。发现状态时在存在的 `.xgent-ai/sdlc` 下显式用 `rg --files --hidden`；原文则沿用户指定、仓库约定、来源链接及仓内实际文档目录发现，不能只搜索状态目录。目录名只作候选；跳过依赖、构建产物和技能范例。核对各层 index.md 与实际目录及分片覆盖，查询时报告缺索引、漏项和断链，不自动修复。index.md 与 index-*.md 不当作事件。未展开的内容明确未核实，不能因只看首页就称全项目无待办。
+4. 读取 PRD 范围/分期、每份相关计划的就绪状态和实施快照、报告基线/结论/处置节，以及支撑下一步的验收记录。默认覆盖已发现的所有活动计划，归档项提供索引入口而不全文读取；没读到的范围明确标未核实。关联以原文需求 ID 和显式链接为准，不能因同名或相邻就关联。
+5. 按 [状态模型的发现与自愈规则](../assets/sdlc/state-model.md#发现与自愈) 查漏：同名 `.review.md`、`.codereview.md`、`.code-review.md`、带轮次文件及其他项目命名均作候选，打开报告确认目标/类型/范围后才补关联；在报告处置节、`.applied.md` 和实施记录查已处理证据，不要求固定处置文件。单文件损坏或来源未同步时保留问题并继续其他对象，不能把“未登记”或“未找到”直接解释为“未做”。
+
+## 2. 校准当前状态
+
+读取 [固定状态与证据校准](../assets/sdlc/state-model.md)，新台账按对应 kind/facet 使用固定状态码，来源原文文字另存 source_state。已有台账优先遵循仓内协议及模型版本；旧自由文本记录可在回答中映射，但不静默升级或改写历史。
+
+- 分开列 **文档就绪、实施进度、评审结论、整改处置、验收/集成**。`Ready` 不是已完成，里程碑完成不是 PRD 全部交付，修复已验证不是重新通过独立评审。
+- 对象状态页、事件与原文的状态行都可能滞后。计划定义范围与门槛，实际实现、适用的验证及处置证据支持当前判断；不因代码文件存在、复选框打勾、空 findings 或一次测试成功就补写完成。固定状态配 evidence_status；无法确定用 unknown，候选另列，缺失、未核实、不适用、尚未做必须区分。
+- 计划自报“未开始/进行中”却已有完整交付线索时，核对每项必需范围、代码/提交、实现与验证记录、未关闭问题。证据充分可判 dev-plan-completed 并注明原文滞后；不足则列候选和具体缺证，不盲从状态行重新开发。反向发现自报完成但缺证或真实回归，同样修正判断，不为保持完成状态忽略失败。
+- `.review.md` 内容确认后说明做过文档评审，`.codereview.md` / `.code-review.md` 内容确认后说明做过代码评审，均不证明已 applied 或已通过。每轮分别判 review-recorded 与处置状态；完整且无需整改的评审用 review-not-required，不推荐无意义的 apply。文档 ready 与实施 completed 分维度；独立验收线暂为 TBD，不自动推导验收通过。
+- 每轮评审单独保留对象、范围、所审版本、报告及处置。旧报告通过但代码/文档相关部分已变时，显示历史通过、当前待核对；只有明确的复用依据才算仍适用。不要求无关变更后重跑所有评审。
+- 读取本地分支/工作树与可用提交历史，区分本分支状态、其他分支记录和未提交成果。本地找不到远端提交时写“本地不可核验”，不能判为没做；远程跟踪引用未经刷新不能证明已同步。不自动 fetch/pull/checkout/stash。
+- 同对象同范围的矛盾记录按协议保留并列，不按日期、文件名或“完成优先”裁定。先核验能核验的来源；只对确实无法从仓内证据解决的决定提问，其余计划继续盘点。
+
+## 3. 选择下一步
+
+先服从用户当前目标和项目约定，再比较真实阻塞、已成立缺陷、依赖解除收益及可执行性。每条建议给出对象/路径、理由、前置条件、具体动作和完成判据；一般突出 1 个首选，另列可独立推进的工作。不编造优先级、负责人或交期。
+
+| 核实到的情况 | 可推荐的动作（遵循项目已定流程，不强制补全流水线） |
+| --- | --- |
+| PRD 尚有影响范围或验收的未决项 | 指出具体待决项；需要撰写/修订时用 `prd`，质量评审用 `review-prd` |
+| 当前工作依赖跨项目答复或收到返回 CRD | 用 `crd` 核对发出、返回与本地版本，明确未确认契约及被阻塞的具体任务；对方已回复不等于已承诺或完成集成 |
+| 文档评审有当前确认待处理意见 | 指定报告和原文交给 `apply-doc-review`；已 applied 或无需处理不重复执行，是否已处理不明时先补核查 |
+| 需求已有边界但尚未有承接计划 | 以明确的需求集合交给 `dev-plan`，不默认一份 PRD 对应一份计划 |
+| 计划需要设计评审 | `review-dev-plan`，注明具体计划与版本 |
+| 验收条件已有口径但缺用例或执行证据 | 用例设计用 `test-plan`；已有用例则核对实际执行与覆盖缺口，不把用例草稿当通过，也不重复设计已覆盖项 |
+| 计划可实施且前置已满足 | 直接读计划实施协议继续对应里程碑；不加载 `dev-plan` 重写计划 |
+| 代码评审有当前仍成立的缺陷 | 有计划和报告时用 `apply-code-review`；缺输入时先定位，不虚构关联 |
+| 修复已完成或待审代码范围明确 | 按项目需要推荐 `review-code`，明确 base/target 或工作树范围与对应历史报告 |
+| 实现已交付但验收缺证、未集成或未发布 | 给出具体补证/集成动作；不把评审通过当部署授权 |
+| 计划完成而 PRD 覆盖还未核对 | 适用时推荐 `review-prd-dev-gaps`，带 PRD 和所有相关计划，不重复创建已有 gaps plan |
+| 原计划状态滞后但实际交付已核实 | 显示规范状态与证据；写入模式修复 SDLC 跟进，原计划进度回写列为待同步项，在已有授权内处理，不重开已完成开发 |
+
+推荐的技能不存在时给出等价动作与输入，不要求安装才能解释状态。不把所有“未评审”自动变成阻塞，也不把待用户决策的工作推荐为可直接开工。
+
+## 4. 保存（仅写入模式）
+
+1. 首次建立默认台账时，将协议复制到 `.xgent-ai/sdlc/protocol.md`、状态模型复制到 `.xgent-ai/sdlc/state-model.md`、事件模板复制到 `.xgent-ai/sdlc/event-template.md`，按导航/分类索引/对象状态模板创建实际需要的文件；每个实际创建的目录同步建立 index.md，包括 `.xgent-ai/` 根、status/events 中间层和事件叶目录，其余层用通用目录索引模板。不建巨型 `STATUS.md`，不预建所有目录或空对象。已有文件先核对，不覆盖。协议和模型随仓保存，使仅安装其他技能的机器也能回写；旧协议升级按状态模型的兼容规则保留历史。自定义位置沿用仓库已有登记方式；没有登记时在适用 `AGENTS.md` 中仅补一条台账路径，用户禁止改规则文件时说明自动发现限制。
+2. 只登记本次核实的事实；旧材料导入记录的观察时间是现在，原活动时间能证实才写。不伪造中间阶段或历史轮次，关系不明的单列待关联。
+3. 按仓内协议与模型新增独立事件；同对象、维度、范围、来源内容、规范状态、证据质量/适用性和关系没有变化时不新增重复事件，不因无关提交改变 HEAD 就重复记账。补登记漏记评审及处置时沿用可确认的对象 ID，纠错追加事件并接续前序；只修漏索引或重建已有事实视图时不新造事件。更新各计划时只记相关维度，不复制完整正文，不因“自愈”擅自改原文状态。
+4. 按类型为每个已核实对象维护独立状态页，保存该对象精确的已纳入事件 ID 集合及当前核查基线；按协议的目录索引规则只刷新受影响状态页、本层索引与入口变化的祖先，补齐维护范围内缺失索引。事实、来源适用性、可见范围和建议均无变化时不重写视图，仅在回复说明已核对；表内时间保留上次保存时间。回读新事件、受影响状态页/索引和源链接，检查重复 ID、悬空前序、冲突、索引覆盖、遗漏活动计划和过期结论。结构正确不代表验收通过。
+5. 写入失败分别说明哪些记录/视图未完成；事件已保存而状态页失败时保留事件，下次可重建。默认不提交、推送或改远端，明确未提交记录尚未随 Git 共享。
+
+## 交付
+
+先用一句话说明总体情况和可见性边界，再给紧凑表格：`工作项 | 文档就绪码 | 实施状态码 | 各轮评审/处置 | 证据质量与差异 | 下一步`，附 PRD/计划/来源链接。PRD 没有计划、代码评审没有计划关联也单列，不静默遗漏。原文状态滞后、候选尚未确认或仅有历史评审时明确说明；验收事实另列，不冒充已定义统一验收流程。
+
+对象很多时按类型/范围分组并链接分类索引，首选动作突出但不静默遗漏其他活动项。各状态附源路径或事件链接，历史结论与当前判断分开。随后给首选动作和可并行候选，明确缺证/待决。写入模式附台账链接及同步情况；查询模式不声称已刷新文件。无活动工作或证据不足时如实说明，不强造下一项开发任务。
+
+```text
+使用 $agi-mode what-next 看看当前项目做到哪里、下一步做什么。
+使用 $agi-mode init-sdlc，纳入仓内现有 PRD、计划和评审的状态。
+使用 $agi-mode what-next 更新跟进表，重点核对 goal/LOGIN.md 与 design/billing-plan.md（使用项目实际路径）。
+使用 $agi-mode what-next 我换了机器，核对本地可见进度和未同步的证据。
+```

package/skills/agi-mode/references/continuity.md

@@ -4,7 +4,9 @@
 
 ## 最小持久状态
 
-优先使用任务已有的计划或进度文件。只有跨会话恢复确有需要而现有文件不足时，才在项目约定的位置创建一份任务状态文件，并告知路径。不要生成第二套冲突的进度记录。
+优先使用任务已有的计划或进度文件，原文位置遵循用户习惯与项目约定。开发任务的跨对象状态按 [状态目录约定](workspace-layout.md) 保存在 `.xgent-ai/sdlc/`，通过链接引用原计划、实施记录和证据，不复制或迁移它们。只有现有记录不足以恢复时才补独立任务状态；非开发任务可用 `.xgent-ai/tasks/<task-id>/state.md`，无计划开发任务可按需用 `sdlc/status/task/<object-id>.md`。告知实际路径，不创建第二套冲突进度。跨计划/跨机盘点使用 [项目状态流程](../playbooks/what-next.md)。
+
+新建上述状态目录时，每层同时创建 `index.md`，包括 `.xgent-ai/`、`tasks/` 和任务目录；按 [通用目录索引模板](../assets/directory-index.md) 保留入口和维护约定。恢复时核对目录实际内容，保存时修补受影响索引；仅状态正文改变不逐级重写。
 
 记录足以让新会话接手的信息：