depa-codument 0.4.1

package/src/templates/codument/std/operations/gap-loop.md

@@ -0,0 +1,301 @@
+# skill: codument-gap-loop（Gap Loop 命令 · 双角色协议）
+
+**本提示词同时供父层编排代理与 fresh 子代理阅读。** 读完后**必须先判断自己当前所处的角色**，再只执行对应章节允许的动作。
+
+> 本文是完整协议（口径已对齐当前标准）。**程序化的执行流程**（串行/并行/条件/循环/spawn/返回/退出）用流程标记块（` ```text ` + `@delimiter: --`，构造词汇见 `_operation-spec.md`）表达；**说明、规则、背景、示例**用 Markdown。
+>
+> 口径映射：`codument:gap-loop`→`codument-gap-loop`；`plan.xml`→`track.xml`；`validation_mode=yield-gap-loop`/`validation_granularity`→该 scope 挂 `<cdt:GapLoop>`、挂在终态 phase（final）或每个 phase（every）；`<confirm>`→`<cdt:GapLoop>`/`<cdt:HumanConfirm>` 节点；`<gap_loop_round>`→track.xml `<Metadata>` 的 `gap-round`；`spec_deltas/`→`behavior_deltas/`；`reports/`→`codument/tracks/<id>/reports/`。
+
+---
+
+## 0.0 总纲
+
+`<cdt:GapLoop>` 的目标**不是**让"当前拿到命令的代理顺手做一次 review"，而是把工作拆成两个角色：
+
+1. **父层编排代理**：负责轮次控制、fresh-spawn 新一轮、根据 XML 结果决定继续/复检/阻塞。
+2. **fresh 子代理**：只负责当前这一轮的目标对比、gap 报告、必要修正与 XML 返回。
+
+读完本文件后没有先判断角色就直接审查代码、diff 或写报告，属于**违反协议**。
+
+## 0.1 角色判定
+
+读完本文件后的第一判断必须是：
+
+```text
+@delimiter: --
+-- #switch ?role on="我是不是'专门为这一轮 gap-loop freshly created 的 round executor'？"
+---- #case ?yes when=是
+按「§2 Fresh 子代理章节」执行
+---- /?yes
+---- #case ?no when=否
+按「§1 父层编排代理章节」执行
+---- /?no
+-- /?role
+```
+
+特别注意：
+
+- 同一个文件给两个角色共用，**不代表两个角色都执行全部步骤**。
+- 父层代理不得越权去做子代理的一轮实质工作。
+- 子代理不得越权去决定下一轮是否继续。
+
+## 0.2 公共规则
+
+### 0.2.1 上层封装运行环境优先级
+
+如果当前运行在一个更上层的封装编排环境中，而该环境本身已经实现了 gap-loop 协议，则**以上层环境的编排实现为准**。
+
+如果当前 scope 已由上层 `operation-hooks.xml` 或 track.xml 的 `<cdt:AttractorCheck>`/`<cdt:GapLoop>` 拥有校验，**不要**在 gap-loop 子代理内启动 competing nested check。可以读取已有 hook 结果作为背景，但是否重跑由父层决定。
+
+这类环境包括但不限于：
+
+- 多 agent / agent teams 编排应用
+- 自定义制度化 workflow 应用
+- 显式指定由某个上层 orchestrator 统一主持 gap-loop 的运行环境
+
+此时：当前 agent 必须先判断自己是上层 orchestrator 还是其下游 worker；若上层已声明"由它主持 fresh-round orchestration"，下游 worker **不得**再在本层私造竞争性 nested gap-loop。Codument 的 gap-loop 约束仍有效，但"谁来承担 parent orchestrator"由上层环境定义。
+
+### 0.2.2 手动触发时的模式补齐
+
+如果用户显式执行 `codument-gap-loop <track-id>`，而当前 track 的该 scope 原本不是 gap-loop 模式（挂的是 `<cdt:HumanConfirm>`，或没挂校验节点），则父层在启动第 1 轮**之前**，必须先把 track.xml 补齐并切到 gap-loop 模式：
+
+```text
+@delimiter: --
+-- #sequence ?patch
+---- #step ?d1
+把该 scope 的校验节点切为 <cdt:GapLoop>（带 max-rounds / on-exhausted 属性）
+---- /?d1
+---- #step ?d2
+定 granularity：多个 phase 已配 phase 级校验 → every_phase；否则 final_phase
+---- /?d2
+---- #step ?d3
+轮次初始化为 0（写 track.xml <Metadata> 的 gap-round）
+---- /?d3
+---- #if ?p1 cond="命令带 --phase <id>"
+该 phase 至少必须具备可执行的 <cdt:GapLoop>
+---- /?p1
+---- #else ?p2
+整个 track 的 phase 级校验布局必须与最终 granularity 一致
+---- /?p2
+-- /?patch
+```
+
+### 0.2.3 轮次元数据
+
+该 scope 处于 gap-loop 模式时，track.xml `<Metadata>` 记录当前轮次（字段 `gap-round`，或由 `reports/` 报告序号承载）：创建/切入时为 `0`；父层**每次启动新一轮前先更新为当前 round 编号**；旧 track 缺该字段按 `0`。
+
+### 0.2.4 历史报告与首轮怀疑规则（verify-round 配置）
+
+父层决定是否收口时必须区分：
+
+1. **已有历史 gap-loop**：`reports/` 已有报告，或 `gap-round > 1`。
+2. **从未跑过 gap-loop**：`reports/` 为空或不存在，且当前是第 1 轮。
+
+对第 2 类场景（首轮 + 无历史 + `NO_GAP`），是否再 fresh-spawn 一轮「验证轮」做首轮怀疑，由 **`verify-round` 配置**决定，**不再写死强制**：
+
+- **节点属性优先**：读该 scope 所挂 `<cdt:GapLoop>` 节点的 `verify-round` 属性（取值 `true|false`）。
+- **缺省取全局默认**：节点未写 `verify-round` 时，取全局默认。**全局默认为 `false`（关）**——约定如此；如 `config/operation-hooks.xml` 的 `<Operation name="gap-loop">` 显式声明了全局开关，则以该声明覆盖此约定默认。
+- **判定**：
+  - `verify-round="true"` → 首轮 `NO_GAP` 父层**仍保持怀疑**，再 fresh-spawn 一轮（**轻量**，见 §2.5）验证轮；该验证轮再 `NO_GAP` 才收口。
+  - `verify-round="false"`（默认）→ 首轮 `NO_GAP` + 无历史**直接收口**，不跑额外验证轮。
+
+注意：本规则只控制「首轮 `NO_GAP` 后是否再追一轮验证轮」。`FIX_APPLIED` 复检**始终强制**、独立于 `verify-round`（见 §1.3 / §2.5）。
+
+### 0.2.5 统一禁止事项
+
+无论你是哪种角色，都禁止：
+
+- 复用上一轮 gap-loop 子代理上下文。
+- 把当前代理的预检查结果伪装成正式 round 结果。
+- 让子代理在本轮结束后自己继续下一轮。
+- 在上层 orchestrator 已声明接管时，再在下层节点内部私造一层 nested gap-loop。
+
+---
+
+## 1.0 父层编排代理章节
+
+### 1.1 你是父层编排代理时，只允许做什么
+
+只允许：解析参数、确认 scope、补齐 gap-loop 模式与轮次元数据、查 `reports/` 历史、fresh-spawn 子代理、传输入/输出契约、等 XML、据 XML 决策。
+
+在 fresh-spawn 子代理之前，父层**禁止**：自己读审代码实现细节、分析未提交 diff、生成 gap 结论、写 gap 报告、修正实现。
+
+**fresh-spawn 注入（按 agent 类型）**：父层 spawn 子代理时按当前运行的 agent 类型注入模型/档位与必要指令——例如 **codex → 模型 `gpt-5.5`、`effort=high`**；其他 agent 按其高能力档。落盘 skill 时由对应 agent 生成器补充该注入；本协议在此声明意图，确保自包含 skill 不丢"用高能力档跑 fresh 复检"这一要求。
+
+### 1.2 父层主循环（每轮顺序 + 收到 XML 的处理）
+
+父层的整个职责就是这段**循环程序**——每轮 spawn 一个 fresh 子代理，据其返回 status 决定续轮 / 收口 / 阻塞：
+
+```text
+@delimiter: --
+-- #loop ?rounds max="cdt:GapLoop 的 max-rounds"
+---- #step ?s1
+解析参数 <track-id> / --phase / --background，确认本轮 scope（track 或 phase）
+---- /?s1
+---- #if ?s2 cond="该 scope 已被更上层 orchestrator 接管且你未被授权"
+------ #exit ?x0
+停止本地 loop，把控制权交回上层协议（见 0.2.1）
+------ /?x0
+---- /?s2
+---- #step ?s3
+读 track.xml；若该 scope 非 gap-loop 模式，先按 0.2.2 补齐
+---- /?s3
+---- #step ?s4
+读当前 gap-round（缺失按 0）；查 codument/tracks/<id>/reports/ 历史报告；读该 scope <cdt:GapLoop> 的 verify-round（缺省取全局默认 false，见 0.2.4）
+---- /?s4
+---- #step ?s5
+gap-round = gap-round + 1，写回 track.xml <Metadata>
+---- /?s5
+---- #spawn ?run as=fresh-subagent inject="按 agent 类型注入模型/档位，如 codex→gpt-5.5、effort=high；若本轮为验证轮或 FIX 复检轮则切轻量模式（更低 effort，见 §2.5）并标注'增量复检'"
+只传最小上下文（track-id、phase、background、固定输入范围、输出 XML 契约）；验证轮 / FIX 复检轮额外注入「上轮 gap 报告路径 + 本轮关注的 diff/FIX 改动范围 + 轻量模式」；等它返回结构化 XML
+---- /?run
+---- #switch ?dispatch on="子代理返回的 status"
+------ #case ?c_blocked when=BLOCKED
+把该 scope 的 <cdt:GapLoop>/<cdt:HumanConfirm> 标 BLOCKED
+-------- #exit ?x1
+停下请求用户输入
+-------- /?x1
+------ /?c_blocked
+------ #case ?c_fix when=FIX_APPLIED
+-------- #continue ?cont1
+不得停、不得收口：本轮已修复，下一轮 spawn 时标注「增量复检」（聚焦 FIX 改动范围、轻量模式），续轮复检
+-------- /?cont1
+------ /?c_fix
+------ #case ?c_nogap1 when="NO_GAP 且 首轮+无历史+从未跑过 且 verify-round=true"
+-------- #continue ?cont2
+首轮怀疑（已配 verify-round=true）：不得收口，再跑一轮（轻量）验证轮
+-------- /?cont2
+------ /?c_nogap1
+------ #case ?c_nogap2 when="NO_GAP 且（非首轮怀疑 或 verify-round=false/默认收口）"
+把该 scope 校验节点标 DONE
+-------- #return ?ok value=收口
+-------- /?ok
+------ /?c_nogap2
+---- /?dispatch
+-- /?rounds
+-- #step ?exhausted
+循环达 max-rounds 仍未 NO_GAP 收口 → 按 on-exhausted（block = 标 BLOCKED 等用户）
+-- /?exhausted
+```
+
+### 1.3 强制循环规则（即 §1.2 `#switch ?dispatch` 的语义）
+
+为强调，上面 `#switch` 的四条规则用文字复述——父层**不得**偏离：
+
+- `BLOCKED` → 标 BLOCKED，停下请求用户输入。
+- `FIX_APPLIED` → **不得停、不得视为完成**，必须 `#continue` 续轮复检；续轮 spawn 时标注「增量复检」——聚焦 FIX 改动范围、走轻量模式（§2.5）。此复检**始终强制**，与 `verify-round` 无关。
+- `NO_GAP`（首轮 + 无历史 + 从未跑过 + `verify-round=true`）→ **不得收口**，`#continue` 再跑一轮**轻量**验证轮（首轮怀疑）。
+- `NO_GAP`（非首轮怀疑，或首轮但 `verify-round=false`/默认）→ 才可 `#return` 收口（标该 scope 校验节点 DONE）。`verify-round` 缺省取全局默认 `false`（见 0.2.4）。
+
+### 1.4 父层对外输出限制
+
+父层代理对用户最终**只应转交子代理返回的结构化 XML**。不应输出自己的 gap 推理过程，不应把自己的中间判断冒充为本轮 gap-loop 结果。
+
+---
+
+## 2.0 Fresh 子代理章节
+
+### 2.1 继续执行的前提
+
+你只有在满足以下前提时才允许继续：
+
+- 你已经是本轮 freshly created 的专用执行者。
+- 当前 track 的该 scope 已由父层确认/补齐为 gap-loop 模式。
+- 当前 round 已由父层决定并写入 track.xml `<Metadata>`。
+- 你不是某上层 workflow 下游节点内部私造出来的竞争性 nested loop。
+
+前提不成立则**立即返回 `BLOCKED`**，并说明环境无法满足 fresh-round 执行要求。
+
+### 2.2 你必须读取的输入
+
+必须读取：
+
+- `codument/tracks/<track-id>/proposal.md`
+- `codument/tracks/<track-id>/behavior_deltas/**/*.xml`
+- `codument/tracks/<track-id>/design.md`（如存在）
+- `codument/tracks/<track-id>/track.xml`
+- `codument/tracks/<track-id>/reports/` 下已有的历史报告（如存在）
+
+命令提供 `--background <path>` 时继续读取背景文件。还必须检查：当前代码实现、当前未提交改动；若指定 `--phase <phase-id>`，聚焦该 phase 的目标、任务、`<cdt:Acceptance>` 验收与对应实现。
+
+### 2.3 你这一轮必须按什么顺序执行
+
+```text
+@delimiter: --
+-- #sequence ?round
+---- #if ?chk cond="你不是本轮专用 fresh 子代理"
+------ #return ?rb value=BLOCKED
+------ /?rb
+---- /?chk
+---- #step ?a2
+读取目标文档（proposal.md、behavior_deltas/**/*.xml、design.md、track.xml）
+---- /?a2
+---- #step ?a3
+读取 codument/tracks/<id>/reports/ 历史 gap 报告；读 --background 背景文件
+---- /?a3
+---- #step ?a5
+review 当前实现与未提交改动（带 --phase 则聚焦该 phase）
+---- /?a5
+---- #step ?a6
+生成新 gap 报告 → codument/tracks/<id>/reports/track-impl-gap-report-<round>.md
+---- /?a6
+---- #switch ?verdict on="本轮结论"
+------ #case ?v1 when="没有 gap"
+不做不必要修改
+-------- #return ?rn value=NO_GAP
+-------- /?rn
+------ /?v1
+------ #case ?v2 when="存在 gap"
+先更新 track.xml，必要时 design.md / behavior_deltas/**/*.xml → 再修正实现
+-------- #return ?rf value=FIX_APPLIED
+-------- /?rf
+------ /?v2
+------ #case ?v3 when="依赖用户决策 / 外部输入 / 无法继续自动修正"
+记录 gap 报告，必要时更新 track.xml / behavior_deltas / design.md
+-------- #return ?rbl value=BLOCKED
+-------- /?rbl
+------ /?v3
+---- /?verdict
+-- /?round
+```
+
+### 2.4 这一轮结束时你不能做什么
+
+返回本轮 XML 后：不得自己继续下一轮；不得假设 `FIX_APPLIED` 就代表收口；不得自行判定"首轮 `NO_GAP` 已经足够"。下一轮是否继续，**由父层编排代理决定**。
+
+### 2.5 轻量模式（验证轮 / FIX 复检轮）
+
+当父层在 spawn 你时标注本轮是**验证轮**（首轮 `NO_GAP` 后的 `verify-round` 验证）或 **FIX 复检轮**（上轮 `FIX_APPLIED` 后的强制复检），你走**轻量模式**，**不重做全量目标对比**：
+
+- **输入收窄**：只读「上轮 gap 报告（`reports/` 最新一份）的结论」+「当轮未提交 diff」。FIX 复检时**聚焦上轮 FIX 的改动范围**（哪些文件/需求被改），只确认该范围是否真正闭合、未引入新偏差；验证轮则确认「首轮 `NO_GAP` 结论在当前 diff 下仍成立」。
+- **不做的事**：不重新逐条比对 proposal / behavior_deltas / design 的全部目标，不重写完整 gap 报告（只在 `reports/` 追加一份**轻量增量复检**报告，标明本轮为验证轮 / FIX 复检轮及其聚焦范围）。
+- **更低 effort**：本轮**可用更低 reasoning effort**（父层注入档位已下调），与全量首轮区分。
+- **结论与 XML 不变**：仍按 §3.0 输出 `NO_GAP` / `FIX_APPLIED` / `BLOCKED`。轻量模式只缩输入与工作量，**不放宽** FIX 必须复检、不偷过真实偏差。
+
+非轻量模式（首轮、或全量对比轮）仍按 §2.2/§2.3 做完整目标对比，质量底线不变。
+
+---
+
+## 3.0 输出协议
+
+子代理本轮**最终只允许输出**以下结构化 XML：
+
+```xml
+<codument-gap-loop-result version="1">
+  <protocol>cdt:GapLoop</protocol>
+  <track_id>add-user-auth</track_id>
+  <scope kind="track">add-user-auth</scope>
+  <status>NO_GAP</status>
+  <report_path>codument/tracks/add-user-auth/reports/track-impl-gap-report-4.md</report_path>
+  <track_updated>false</track_updated>
+  <behavior_updated>false</behavior_updated>
+  <design_updated>false</design_updated>
+  <summary>未发现相对于当前目标的新增 gap。</summary>
+</codument-gap-loop-result>
+```
+
+`scope` 规则：未指定 `--phase` → `<scope kind="track">...</scope>`；指定 `--phase P2` → `<scope kind="phase">P2</scope>`。
+
+`status` 只允许：`NO_GAP`（本轮无新增 gap）/ `FIX_APPLIED`（本轮发现并已修复，**须复检**）/ `BLOCKED`（需用户决策 / 外部输入）。
+
+**禁止输出**：Markdown 说明、自然语言前言或总结、额外代码块、多段 XML。

package/src/templates/codument/std/operations/impl-mission.md

@@ -0,0 +1,167 @@
+# skill: codument-impl-mission（执行长周期 mission）
+
+按 `mission.xml` 的 desired DAG 执行 mission，并通过 `MissionPlanner` / `MissionObserver` / `MissionReconciler` / `MissionApplier` 四个控制论 + DEPA actor 做反馈收敛。
+
+> mission 执行不是一次性按 DAG 跑完。它是 level-triggered 的控制循环：每轮读取当前 actual state，比较 desired state，只执行一个 bounded convergence action。格式规范见 `codument/std/spec/mission-xml-spec.md`；flow notation 见 `codument/std/spec/flow-notation.md`。
+
+## 0. 前置
+
+- mission 必须位于 `codument/missions/pending/<id>/` 或 `codument/missions/active/<id>/`。
+- `mission.xml` 是状态真源。
+- `analysis/` 和 `reports/` 是执行期外部记忆，默认不进 git。
+- 不依赖 chat history 作为状态。
+
+## 1. Actor 边界
+
+| Actor | 输入 | 输出 | 禁止 |
+|---|---|---|---|
+| `MissionObserver` | mission id | actual state projection | 不修改文件 |
+| `MissionReconciler` | desired state + actual state | next action / drift / blocked / done | 不直接写文件 |
+| `MissionPlanner` | drift / user decision / evidence | revised desired graph proposal | 不执行 track |
+| `MissionApplier` | approved bounded action | file changes / track action / report | 不做无限自动化 |
+
+## 2. 主循环
+
+```text
+@delimiter: --
+@node: #
+@marker: ?
+-- #loop ?mission until="mission completed/cancelled/superseded or blocked"
+---- #step ?load
+定位 mission：优先读取 active/<id>/；若只存在 pending/<id>/，本轮唯一允许的 bounded action 是 start-mission（见 §3），不得执行任何 ready node。
+---- /?load
+---- #if ?pending_start cond="mission 位于 pending/<id>/"
+------ #call ?start target="start-mission(pending/<id>)"
+------ /?start
+------ #exit ?reload_active
+启动完成后停手或从 active/<id>/ 重新加载；不要沿用 pending 路径缓存继续执行 DAG。
+------ /?reload_active
+---- /?pending_start
+---- #step ?observe
+MissionObserver 读取 actual state：mission.xml 当前状态、`cdt:TrackLink` 绑定的真实 tracks、archive、测试结果、用户新约束、reports。
+---- /?observe
+---- #step ?reconcile
+MissionReconciler 比较 desired vs actual，判定：ready-node / drift / blocked / completed。
+---- /?reconcile
+---- #switch ?decision on="reconcile result"
+------ #case ?ready when="存在 ready mission node"
+-------- #step ?apply_ready
+MissionApplier 执行一个 bounded action：分析一个 plan 节点、创建一个 track、续跑一个 track、归档一个 track，或写一个报告。
+-------- /?apply_ready
+-------- #exit ?wait_after_action
+动作完成后停手或进入下一轮；不要无界连续执行多个 track。
+-------- /?wait_after_action
+------ /?ready
+------ #case ?drift when="actual state 使当前 DAG/节点不再成立"
+-------- #step ?plan_revision
+MissionPlanner 基于 evidence 或 human decision 产出重规划建议。
+-------- /?plan_revision
+-------- #step ?apply_replan
+MissionApplier 写 reports/replan-XXX.md，更新 mission.xml，递增 Revision。
+-------- /?apply_replan
+-------- #exit ?wait_replan
+重规划后停手，等待下一轮观察。
+-------- /?wait_replan
+------ /?drift
+------ #case ?blocked when="缺少 evidence、用户决策、外部状态或 track 失败"
+-------- #return ?blocked_out value="报告阻塞和所需输入"
+-------- /?blocked_out
+------ /?blocked
+------ #case ?done when="全部节点 DONE 或 SUPERSEDED，成功判据满足"
+-------- #return ?complete value="更新 mission.xml Status=completed；提示可 archive-mission"
+-------- /?complete
+------ /?done
+---- /?decision
+-- /?mission
+```
+
+## 3. 启动 pending mission
+
+当 mission 位于 `pending/<id>/`：
+
+`start-mission` 是一个门禁动作，不是普通 ready node。完成前不得执行 mission DAG 中的任何节点。
+
+1. 读取 `proposal.md`、`design.md` 和 `mission.xml`。
+2. 确认用户要启动；如果用户未明确启动，返回 blocked。
+3. 检查 `active/<id>/` 不存在；若已存在，返回 blocked，要求人工处理，禁止覆盖。
+4. 移动目录到 `active/<id>/`。
+5. 更新 `active/<id>/mission.xml`：
+   - `Metadata.Status=active`
+   - `Metadata.UpdatedAt=<now>`
+6. 写 `reports/mission-run-001.md` 记录启动路径、启动时间和用户确认。
+7. 启动动作完成后停手，或从 `active/<id>/` 重新加载再进入下一轮观察；禁止继续使用旧的 `pending/<id>/` 路径引用。
+
+## 4. ready node 处理
+
+ready node 来自 `mission.xml` 顶层 `TaskGroup` DAG：所有 `<After>` 前驱已 DONE / SUPERSEDED，且节点自身未完成。进入某个 ready `TaskGroup` 后，按其内部叶子 `Task` 的 `order` 顺序执行第一个未完成 Task；除非未来显式扩展 nested DAG，否则组内 Task 不并行、不写进顶层 DAG。
+
+常见节点类型：
+
+- 普通 leaf `Task`：做证据盘点 / 设计收敛 / track 切片；产物写 `analysis/`，稳定结论写 `design.md` 或 decisions。
+- 带 `cdt:TrackLink` 的 leaf `Task`：创建、续跑、验证或归档一个 codument track；真实实现交 `codument-plan-track` / `codument-impl-track` / `codument-archive-track`。
+- 验证 leaf `Task`：独立验证 mission 成功判据。
+
+### 4.1 TrackLink 绑定写回
+
+`cdt:TrackLink` 只挂在叶子 `Task` 上：
+
+```xml
+<Task id="G3-T1" name="创建并执行 runtime contracts track" status="NOT_STARTED" order="0">
+  <cdt:TrackLink state="candidate" id="add-runtime-contracts"/>
+</Task>
+```
+
+当 `MissionApplier` 创建真实 track 后，必须立即更新 `mission.xml`：
+
+1. 将同一个 `cdt:TrackLink` 的 `state` 从 `candidate` 改为 `bound`。
+2. 将 `id` 写成真实 track id；如果真实 id 与 candidate id 不同，用真实 id 覆盖。
+3. 不写 `path`、`archive-path` 或 track 状态；active/archive 位置后续通过 id 解析。
+4. 更新该 leaf `Task.status`，并更新 `Metadata.Revision` / `UpdatedAt`。
+5. 写 `reports/track-bind-XXX.md`，至少包含 mission task id、candidate id、real track id、创建证据和时间。
+
+如果 `cdt:TrackLink state="candidate"` 指向的 track 已经存在，也按同样规则绑定为 `bound` 并写 report；不得重复创建 track。
+
+## 5. 受控重规划
+
+允许变更：
+
+- 增加 mission 节点。
+- 删除 / supersede mission 节点。
+- 修改节点描述、验收、状态。
+- 修改 DAG 依赖。
+- 改变某 `cdt:TrackLink state="candidate"` 的边界、id 或顺序。
+
+硬要求：
+
+- 必须有 evidence 或 human decision。
+- 必须写 `reports/replan-XXX.md` 或 `reports/human-intervention-XXX.md`。
+- 必须递增 `Metadata.Revision`。
+- 必须更新 `Metadata.UpdatedAt`。
+
+## 6. reports 模板
+
+```markdown
+# Mission Replan Report
+
+## Trigger
+
+## Desired State
+
+## Actual State
+
+## Diff
+
+## Decision
+
+## Applied Change
+
+## Next Observation
+```
+
+## 7. 完成
+
+当所有必要节点 DONE 或 SUPERSEDED，且 proposal 的成功判据满足：
+
+- 更新 `mission.xml` status 为 `completed`。
+- 写 `reports/mission-complete.md`。
+- 提示用户使用 `codument-archive-mission` 归档。

package/src/templates/codument/std/operations/impl-quick.md

@@ -0,0 +1,79 @@
+# skill: codument-impl-quick（基于 Codument 上下文快速实现小改动）
+
+用于小范围变更：bug 修复、测试补齐、局部重构、非破坏性配置修正。它读取 Codument 知识上下文和项目工程文件后直接实现，不创建 track、mission、proposal 或 behavior delta。
+
+## 0. 边界
+
+适合 quick：
+
+- 恢复既有预期行为的 bug fix。
+- 小范围测试补齐。
+- 局部重构且不改变对外行为。
+- 非破坏性配置/脚本修正。
+
+不适合 quick：
+
+- 新能力或对外行为变化。
+- 需要 behavior/modeling/engineering delta 才能表达清楚的变更。
+- 架构/模式调整。
+- 多阶段或跨模块高风险工作。
+- 长期自动化目标。
+
+遇到不适合 quick 的工作，停止并建议 `codument-plan-track` 或 `codument-plan-mission`。
+
+## 1. 上下文加载
+
+1. 执行命令级前置 hook：若 `operation-hooks.xml` 为 `impl-quick:before` 配了 `<cdt:AttractorCheck use="coding"/>`，读取 `coding` profile 和其引用的 attractors。
+2. 读取与请求相关的：
+   - `codument/attractors/`、`codument/std/attractors/`。
+   - `codument/behaviors/`。
+   - `codument/modeling/`、`codument/engineering/`（如果存在）。
+   - `codument/decisions/` 与相关 archive/track 历史。
+   - 源码、测试、配置、脚本。
+
+## 2. 实现流程
+
+```text
+@delimiter: --
+-- #sequence ?quick
+---- #step ?scope
+判断请求是否适合 quick；不适合则 #exit 并建议 plan-track / plan-mission
+---- /?scope
+---- #step ?context
+读取 Codument owner 知识和相关工程文件，形成最小上下文
+---- /?context
+---- #step ?edit
+按项目既有模式做最小代码/测试/配置修改
+---- /?edit
+---- #step ?verify
+运行最小必要验证；能跑测试就跑，不能跑则说明原因
+---- /?verify
+---- #step ?durable
+判断是否发现稳定结构知识或工程知识；如有，只提示是否写入 codument/modeling 或 codument/engineering，不静默沉淀
+---- /?durable
+---- #return ?done value="quick implementation complete"
+---- /?done
+-- /?quick
+```
+
+## 3. 知识沉淀
+
+默认不创建 track、不写 proposal、不写 behavior delta。
+
+若实现过程中发现稳定长期知识：
+
+- 领域结构、对象、状态机、policy、workflow → 提示是否写入 `codument/modeling`。
+- 工程规则、howto、troubleshooting、code-map、runbook → 提示是否写入 `codument/engineering`。
+- 对外行为变化 → quick 不再合适，建议创建 track。
+
+未经用户明确同意，不要把 quick 中发现的知识直接沉淀为 durable owner registry。
+
+## 4. 输出
+
+最终回复包含：
+
+- 修改摘要。
+- 验证结果。
+- 是否仍属于 quick。
+- 是否发现建议沉淀到 `codument/modeling` / `codument/engineering` 的长期知识。
+- 若未能验证，说明原因和剩余风险。