audit

审计

你正在运行协调循环：工作是否符合其设计与治理要求，并且是否在协调前有意识地处置了每个差距？

审计阶段使用评审台账——RV 类型（RV-NNN）。台账的通用机制（开启 + 初始化、提出、处置 + 解决、严重性与处置类别、综合、关闭门槛、评审的运行位置）见 lib:reference/review-ledger.md——请阅读；本技能不会重复说明这些动词。 下文介绍的是审计的视角：切面、模式、范围、协调循环所要求的证据，以及审计专属的汇总与收尾工作。

发现项以追加方式写入台账，并由对应领域负责。尚未解决的阻断项会阻止 audit→reconcile 和 reconcile→done 的推进（即关闭门槛的约束）；将其他每项发现都推进到终态，是本技能的要求，而非二进制程序的要求。审计正文会成为评审的 ## Synthesis。

已分派的切片——评审候选界面，而非原始证据。 如果切片由 /dispatch 推动，review/* 和 phase/* 是不可变的证据引用（R2）；审计/修复针对由 doctrine dispatch candidate create 发布的候选交互分支进行（参见 doctrine dispatch candidate status）。在台账的 ## Brief 中记录你评审的界面，并通过 doctrine dispatch candidate admit --review RV-NNN 链接批准此次分派的 RV。

输入：

• 切片中已实现的阶段及其验证证据
• design.md（规范版本）、slice-nnn.md、plan.toml
• 相关 ADR 和技术规范（参见 /canon）

工具优先级

如果运行环境提供 MCP 评审工具，请优先使用它们，而非 CLI（lib:reference/review-ledger.md § Passing prose）；review unlock 和 review paths 仍仅支持 CLI。

审计视角

审计对象始终是切片——目标阶梯第 1 级。 审计针对其切片（即 --target），绝不降级为正文；根据定义，关闭等级触发条件已满足（这是切片 audit→reconcile→done 流程的门槛）。不要重新推导对象——针对切片开启 RV。

切面为 reconciliation。 这是本阶段审查的生命周期方面。如有立场，通过 --raiser 表达，绝不要新建切面（lib:reference/review-ledger.md §2）。

审计模式——选择一种：

• conformance——与切片关联的实现后审计（通常情况）。
• discovery——补充记录或现有代码调查。

自审计（通常情况）。 当你既是评审者又是作者时，使用 --as <role> 承担两种角色——提出者负责提出、验证、异议、重新开启、撤回和结束；响应者负责处置和修订。角色属于行为，而非 Agent；--as 是协作式角色声明，不是安全边界（lib:reference/review-ledger.md，“Acts and roles”）。

处置约定（审计专用）。 请参阅已闭合的处置类别词表，见 lib:reference/review-ledger.md §4。审计绝不能对规范/治理事项使用 follow-up——这些事项应写入 reconcile 的写入界面，而非待办事项列表。每项发现最终都应为 verified（即确认观察属实；委派的发现则在其简报条目存在后确认）；修复工作由 reconcile 负责，并单独记录——不要将发现修改为 fixed/remediated。

流程

1. 为切片开启台账（替代编写 audit.md）：开启一个目标为该切片、切面为 reconciliation 的 RV，然后在台账的 ## Brief 中填写审计的检查方向（本次审计要探查的内容，以及用于衡量切片的约束条件）。动词和标志见 lib:reference/review-ledger.md §1–§2。仅有零散笔记 不足以满足关闭等级工作的要求——发现项必须记录在台账中。 然后对其执行 prime（lib:reference/review-ledger.md §2）：review prime 根据切片的选择器推导路径集，台账的过时信号会对其进行哈希。不复存在的是旧的手工维护 domain_map（一种徒增负担的编写工作），而不是 prime 动词。slice conformance（步骤 2）根据记录的源代码变更计算出的机械漂移信号，是对 prime 的补充，而非替代。

2. 收集证据（审计中各自独立的工作）：

   • 准备审查对象：不要切换主检出目录的分支。审计应在代码所在之处进行——主工作树、派发协调工作树、关联工作树或接管的 capsule 工作树；在该处完成审计并关闭，然后再合入。只有派发工作者进程会被拒绝写入审查记录；每次只能有一个写入者处理一个 RV（lib:reference/review-ledger.md §6，“审查的执行位置”）。

   • 运行 doctrine slice conformance <id> 并阅读其代数结果——机械地比较 design.md 声明的内容（design-target 选择器）与 git 实际修改的内容（记录的源代码变更）。它会报告三个单元格：

     • 未声明（信号最强）——已编辑但不属于任何 design-target 选择器的路径。每一条都是潜在发现：范围蔓延、遗漏的设计更新，或未记录的修改。
     • 未交付——未匹配到任何实际编辑的 design-target 选择器。声明了但未交付：工作被丢弃或设计已过时。
     • 符合——匹配的路径数量（每条均附有其选择器）。

     符合性必要但不充分：它只指出去哪里检查，绝不判断是否通过。将未声明／未交付项视为待处理的线索，而不是自动认定的发现。如果报告 unavailable（注册表为空）或 incomplete（已完成阶段没有记录），这个缺口本身就是一项发现：注册表未在各阶段完成时记录；请使用 doctrine slice record-delta <id> PHASE-NN --start <oid> --end <oid> 进行引导，或注明覆盖不完整——绝不要把不完整的注册表视为干净。

   • 运行设计和计划要求的测试／检查，并运行 doctrine check gate；

   • 根据 design.md 和阶段的 VT- 标准检查实际行为；

   • 记录行为与设计不一致之处——每一处不一致都是一项发现。

3. 在台账中提出并处置每一项发现，遵循 lib:reference/review-ledger.md §3–§4。 坚守审计工作的反逃避原则：对于规范／治理发现，不要选择 follow-up——应将其处置为 design-wrong，并附上协调简报链接；简报条目创建后，由提出者核实；对于代码发现，不要仅因修复规模大就选择 follow-up；没有切实理由时，不要将其归为 tolerated；也不要为了绕过关闭门槛而将真正的 blocker 降级。如果阅读 design.md 和治理文件后仍无法确定正确路径，请停止并 /consult。

4. 综合。 将审计推理写入审查记录的 ## Synthesis（追加到 review-NNN.md）——包括闭环说明、持续存在的风险，以及经过审慎权衡后接受的取舍（也就是旧 audit.md 中的文字内容）。

5. 编写协调简报。 在 review-NNN.md 中追加一个专门的 ## Reconciliation Brief 部分，与 ## Synthesis 分开。这是从审计到 /reconcile 的结构化交接，将每项规范／治理发现映射到其目标和预期写入范围：

   ## Reconciliation Brief
   
   ### Per-slice (direct edit)
   - design.md §3: the eviction model changed from edge-at-a-time to per-SCC —
     update prose to match implementation.
   
   ### Governance/spec (REV)
   - ADR-NNN: branch-point staleness description is wrong → REV modify
   - REQ-NNN: cordage scale target verified at 50k nodes → REV status active
   

   根据每一项涉及设计或治理的非一致、非容忍发现编写简报。按写入范围分组（按切片直接编辑与治理／规范 REV）。每个条目都要注明发现 ID，并描述所需的确切更改。 简报的适用面护栏。 /reconcile 只会写入两个适用面 — 通过直接编辑写入每个切片的产物（design.md、slice-NNN.md），以及通过 REV 写入治理/规范。请写明撰写技能实际会修改的适用面，否则简报会在 reconcile 阶段停滞：

   • 计划标准不属于适用面。 plan.toml 中的 EN-/EX-/VT-（以及 PHASE-NN）ID 遵循只追加不可变规则（引导规则）— 永远不是 reconcile 的直接编辑适用面。需要更改计划标准才能解决的分歧，属于设计/计划升级处理，而不是“每切片（直接编辑）”简报条目。不要编写编辑 plan.toml 的简报条目。
   • 符合性发现应写明注册表动词，而非散文。 “虚假未交付 / 范围蔓延”符合性发现应通过选择器注册表（doctrine slice selector rm/add）修复，因为 slice conformance 读取的就是它（slice-NNN.toml）。design.md §6 只是面向人的镜像 — 仅修改散文的简报条目无法让符合性检查转绿。请将 slice selector 动词写为承载实际变更的操作；§6 的编辑则注明为其镜像。

   面向人的综合说明。 如果审计包含重要内容，请为人提供一条简短的路线，说明参与其中的系统、一项重要行为及其实现方式、与之相关的测试，以及尚存风险。对于决策中引用的重要 Doctrine 来源，请说明每个来源的重要性，并给出确切的 doctrine <kind> show <ID> 命令。如果深入检查会有帮助，可以建议使用 /walkthrough 或 /pair，但不应将其设为必选项。询问人最关心哪项风险，或许有助于完善综合说明；如果询问过，请使用对方的回答，不要把它变成理解力测试。如果有真实发现作为依据，可选择进行简短的模拟同行质询，帮助演练决策或检验其理由。请明确说明来源，并指出异议是源于历史记录还是模拟提出。新的实质性缺陷应记入 RV 台账；人的回答能力既不是发现，也不是验收条件。遵循项目默认的参与方式，以及人提出的口头变更。

6. 归档（审计尾声）。 将临时运行时阶段表中的持久风险、决策和注意事项汇总到 notes.md — 这是针对审计的特定视角 — 然后根据 lib:reference/harvest.md 完成其余归档工作（各环节与落点）。

7. 交接给 reconcile。 写好协调简报且每项发现均已进入终结状态后，以提出者身份结束本轮审查 — doctrine review conclude RV-NNN --basis …（或 review_conclude），说明审计检查了哪些内容 — 使 review status 显示 done · await=none。之后若新增或重新开启审查，结论会被清除；请在此后再次结束审查。然后交接给 /reconcile。切勿 直接交接给 /close — reconcile 是唯一负责写入协调后事实的环节；close 只确认结果。记录生命周期变更： doctrine slice status <id> reconcile（使用裸数字）— 存在未解决的阻塞项时，命令会拒绝执行。

结果

• 审计证据是结构化的 RV 台账（review-NNN.toml + 审查中的 ## Synthesis + ## Reconciliation Brief），而非手工编写的 audit.md。
• 每项发现都以明确的处置结论终结（或被撤回），且本轮审查以 --basis 结束。
• 不存在尚未解决的 blocker — 否则 close gate 会拒绝通过。
• 协调简报将每项规范/治理发现映射到其目标和写入适用面。
• /reconcile 收到的是完整且可执行的简报 — 而非原始发现。