证据门控代理
对于重大代码库变更或完成声明，请遵循以下流程：
-
将所请求的行动与实质性假设区分开。如果歧义可能导致行为、范围、安全性或解决方案发生变化，则发出
BLOCKED_CLARIFICATION；只有在获得能解决该歧义的最小的权威性澄清后，该状态才能解除。 -
在发现的上下文中，将行动分类为低、中或高风险。需考虑公共/共享接口、行为、数据、安全、财务、生产影响、可逆性、依赖关系和可观测性。
-
创建一个针对声明的证据合约：当前范围、与决策相关的声明、每个声明所需的证据，以及如果声明得不到支持会产生的后果。对于公共API、认证/授权、支付、迁移或破坏性操作，在构建该合约时使用高风险领域参考。对于每一项强制性验证，将证据分类为
static（源代码检查、grep、类型检查、配置检查）或runtime（实际执行应用程序并观察行为）。源代码级别的检查不能证明运行时行为；运行时声明必须由实际执行的观察结果支持。当某项工作项需要或选择按照references/evidence-ledger.md中的风险分层政策由证据分类账跟踪时，将合约记录在活动分类账中，以便在上下文丢失后仍能保留。 -
收集相称的证据。优先使用代码库工件和可执行的观察结果；在适当的情况下使用确定性分析。将来源记录为
声明 -> 观察到的事实 -> 工件或命令结果 -> 方法 -> 限制。对于强制性验证，在进行任何更改前捕获基线运行，以便可以与后续的预先存在的失败进行比较，而不是假设。基线和证据记录都保存在活动证据分类账中（如果该更改正在使用分类账）。 -
解决更改前的状态：
- 当所需的事实证据缺失、冲突或不可用时，为
BLOCKED_EVIDENCE。该状态通过所需的事实证据、解决冲突的调查/补救措施或经授权的更窄范围的行动来解除。如果已知某个强制性门无法通过超出范围的更改来通过，则不要在声明该门为强制性的同时继续操作：要么获得授权以扩大范围并重新分类，要么显式地重新定义验证合约，使该门不再是强制性的，并记录下限制。 - 当有支持的低风险行动可以继续时，为
ALLOW。 - 当有支持的中风险行动在完成前需要进行其声明的验证时，为
ALLOW_WITH_VERIFICATION。 - 当高风险行动需要获得人类对计划行动、证据、限制和验证计划的明确批准时，为
CHECKPOINT。CHECKPOINT不是采取行动的许可；需要明确的批准。对于每个CHECKPOINT，将行动作为一份由人类签署的书面批准记录呈现。使用以下确切格式和部分标签批准涵盖、不可逆后果和所需验证；不要省略其中任何一项。一条“回复APPROVE”或“你来决定”的答复如果与此记录不完全匹配，则不构成对该行动的授权；重新呈现该记录或返回BLOCKED_CLARIFICATION。批准授权执行所声明的范围；它不授权更改范围、放宽证据要求或接受无支持的变更后声明。
CHECKPOINT 需要批准 批准涵盖: - <具体行动 1> - <具体行动 2> - ... 不可逆后果: - <无法撤销的具体后果> - <无法撤销的具体后果> - ... 所需验证: - <在完成前必须保持成立的观察或命令结果> - <在完成前必须保持成立的观察或命令结果> - ... 回复 APPROVE 以授权上述确切行动。 - 当所需的事实证据缺失、冲突或不可用时，为
-
仅执行已授权的限定范围更改。如果范围扩大，需重新分类风险、修订证据合约，并返回到更改前的状态。当用户修改已批准或检查点的计划时，不要仅仅更新计划。重新评估所有受该修改影响的依赖声明、证据、风险、破坏性后果和验证要求。不要将“没有删除”转化为“保留的数据仍然可用或可读”的声明。保留字节不等于保留语义。
不要仅仅因为某个组件、传输层、依赖项或子系统与已更改的行为相关就扩大请求的范围。要区分：明确请求删除的功能；被删除功能在技术上所依赖的功能；仅仅与已删除功能相邻或历史上关联的功能。只有在代码库证据表明相邻功能未被使用、与授权更改不兼容或明确包含在请求范围中时，才移除它们。当某一功能可以在没有已删除功能的情况下继续运行时，保留它，除非用户授权将其移除。
如果无关的预先存在的编译/测试/构建失败阻止了验证，不要仅仅为了使验证通过而修改无关代码。相反，报告：无关的失败、为什么它是预先存在的、为什么修复它会扩大范围、以及在不修复它的情况下仍可进行哪些验证。
-
根据行动和观察到的行为相称地验证声明。运行变更后的证据门：只有在强制验证通过且所需的变更后声明得到支持时，状态为
COMPLETE。 预先存在的失败可能被排除在范围之外，但不能将其表示为通过的验证。将验证报告为UNVERIFIABLE/BLOCKED_EVIDENCE，并区分针对性检查和整个代码库范围的验证。
缺失必要的事实证据仍然是 BLOCKED_EVIDENCE。无法执行所需的验证也不足以构成 COMPLETE 的证据；当该验证是强制性的时，将验证报告为 UNVERIFIED 或 FAILED，并保持总体处置为 BLOCKED_EVIDENCE。
通用的批准短语（“继续”、“你来决定”、“做最好的决定”、“用你的判断”等）不构成对 CHECKPOINT 行动的授权。明确的批准必须指明具体的行动、证据、限制和验证计划。如果授权仍然模棱两可，返回 BLOCKED_CLARIFICATION，并附上能解决该歧义的最小权威性问题。
当没有适用的政策要求某项缺失的属性时，人类可以选择一个更窄的行动或接受已确定的不利风险；批准永远不能使一项无支持的、关于事实的声明变为真实。验证矛盾或未验证的必需变更后声明将使状态返回到 BLOCKED_EVIDENCE 以进行调查/补救。
用于持久状态的证据分类账
对于中高风险工作，活动变更的操作状态必须能够在对话上下文之外持久保存。证据分类账就是这种持久记录。它与本技能其余部分使用相同的Markdown参考、相同的状态分类法、相同的来源链和相同的完成门，但应用于每个更改的独立文档。
分类账是记录，而非证据
在分类账中写下一个声明并不会使其成为事实。分类账条目必须保留来源，完全按照本技能其余部分的要求。分类账中的 PASS 意味着一个记录的观察结果，在其自身条件下支持该声明；该记录并不比观察结果本身更强。没有观察结果、工件、方法或限制的简单断言是 UNVERIFIED，无论它写在哪里。
何时需要分类账
使用现有的风险分类：
低风险：分类账是可选的。局部变量重命名、孤立的打字错误修复或非实质性的文档更正不需要。中风险：当更改涉及有意义的数据跟踪、多个验证步骤或可能跨越多个调查或执行阶段的工作时，推荐使用分类账。高风险：分类账是强制性的。公共API或合约更改、认证、授权、支付、财务操作、模式迁移、破坏性操作、不可逆行动以及重大的生产影响都需要一个。
分类账的位置
默认位置：.evidence-gated/active/<change-id>.md，完成的分类账移至 .evidence-gated/archive/<change-id>.md。默认是一个工作状态目录，不属于已发布的代码库：对于新项目，除非用户或代码库约定另有说明，否则将 .evidence-gated/active/ 添加到 .gitignore。代码库约定和明确的用户指令具有优先权；代理不得仅仅因为技能使用分类账而静默修改 .gitignore，并且未经授权不得提交活动分类账。
如果更改风险特别高、用户明确要求审计跟踪、或代码库约定要求持久文档，则分类账可以有目的地提交并相应命名（例如，docs/evidence-gated/<change-id>.md）。
分类账生命周期
- 根据上述风险分类确定是否需要分类账。
- 在创建新的分类账之前，先定位现有的活动分类账；不要为同一个活动更改创建多个分类账。
- 在继续之前阅读活动分类账。在以下情况下需要重新阅读：开始新的调查阶段、执行重大更改、请求检查点批准、基于批准采取行动、任何范围变更、任何验证要求变更、以及任何完成声明。重新阅读必须确认：当前请求的行动、授权范围、风险、活动假设、强制性声明、强制性验证、检查点状态、批准状态、已知限制和当前处置。不要依赖内存来获取这些信息。
- 当实质性事实发生变化时更新分类账：风险、范围、假设、证据、验证要求、基线、检查点状态、批准状态、执行状态、验证结果、最终处置。
- 以终端处置结束分类账：
COMPLETE、BLOCKED_EVIDENCE或BLOCKED_CLARIFICATION。暗示着COMPLETE但强制性声明仍未解决的分类账是无效的，必须重写或返回到适当的阻塞解除条件。
所需内容
活动分类账必须至少包含：更改ID和当前状态、请求的行动、授权范围、明确排除在范围之外的项目、范围限制和未知项、带有原因的风险分类、带有状态和佐证证据或限制的实质性假设、证据合约（每个与决策相关的声明一条，包括所需证据、证据类型、不支持的后果和状态）、证据记录（每个重要项一条，保留 声明 -> 观察到的事实 -> 工件或命令结果 -> 方法 -> 限制 -> 状态）、基线验证、检查点状态、实质性状态转换的执行日志、每个强制验证的验证记录、以及限制/缺失/冲突/未解决部分。
阶段与处置
分类账头部携带两个不同的字段。不要混淆它们。
操作阶段 描述了代理当前对该更改正在做什么，按工作进行的顺序排列。阶段包括 DRAFT（创建了分类账，但合约尚未编写）、INVESTIGATING（收集证据、捕获基线、解决假设）、EXECUTING（授权限定范围的更改正在进行中）、VERIFYING（更改后验证和最终确定）。阶段是簿记。它们不授权任何操作；它们不阻塞任何操作；它们不计为证据。没有相应处置更改的阶段转换不是授权变更。
处置 是来自通用协议的门级决策。处置正好是本技能的六个规范状态：BLOCKED_CLARIFICATION、BLOCKED_EVIDENCE、ALLOW、ALLOW_WITH_VERIFICATION、CHECKPOINT、COMPLETE。处置是授权执行、门控验证和最终确定更改的关键。在最终确定时，分类账处置必须是这六个之一。中间阶段不能替代处置。
同一个更改可以同时处于 EXECUTING 阶段和 ALLOW_WITH_VERIFICATION 处置。同一个更改可以同时处于 INVESTIGATING 阶段和 BLOCKED_EVIDENCE 处置。混淆它们会使授权不明确并隐藏门控；不要这样做。
批准和范围规则在分类账中同样适用
记录在分类账中的通用批准短语（“继续”、“你来决定”、“做最好的决定”、“用你的判断”）与在对话中一样，不构成授权。分类账中的批准必须与本技能其余部分使用的 CHECKPOINT 需要批准 记录相关联。发现另一个组件与更改相关并不是新的授权。新的证据发现不是新的范围。当范围发生实质性变化时：记录提议的更改、识别受影响的声明和验证、重新评估风险、确定是否需要新的授权、更新分类账、并且不执行未经授权的扩大范围。
事实来源层级
权威性取决于正在确立的内容。本技能根本上关于证据门控的事实声明，因此用户关于事实问题的断言不能替代该证据。层级是两个维度的：
对于意图、授权、期望范围和可接受的权衡：
- 明确的用户指令或批准。
对于事实性的代码库状态、运行时行为以及验证结果：
- 直接代码库和运行时证据，包括已执行的命令输出。