| name | milestone-composite-check |
| description | 当 Milestone Gate 需要消费 composite acceptance lanes（code-review / feature-completeness / related-influence / intent-completeness / operator-simulation / professional-review），聚合并审查现有的 per-WT lane 报告以产出 milestone 级复合验收结论时，使用这个技能。它聚合已有 lane 报告，不生成新的代码检查。与其他三轴（blackbox / whitebox / anticheat）不同，本轴不主动检查代码。 |
Milestone 复合验收轴检查技能
概览
本技能实现 Milestone Gate 四轴检查中的 composite acceptance 轴。它是 Layer 1 四个独立 SubAgent skill 中的一个，与其他三轴（milestone-blackbox-check、milestone-whitebox-check、milestone-anticheat-check）并行运行、轴间不可见、各自产出独立的 composite_verdict。
与其他三轴不同，本轴不生成新的代码检查。它消费每个已闭环 worktrack 上已经产出的 composite_lane_record refs/statuses，聚合并审查其完整性和可信度，最终形成 milestone 级的复合验收结论。
本技能在隔离的 SubAgent 上运行，接收限定范围输入包，不得读取其他轴的 verdict。架构位置定义见 milestone-gate-aggregation.md Layer 1 / composite_lane_rules。
target_type / target_scenario 只能参与 review-depth 和 mandatory lane 分类。Composite 轴不能用 lane prose 后验补造 blackbox、whitebox 或 anticheat evidence；也不能把自己的 pass 当成其他轴的替代 pass，除非对应轴显式记录 substituted 且替代证据合同满足。
何时使用
当 Milestone Gate 到达 composite acceptance 轴检查阶段时，使用这个技能：
- milestone 的所有 worktrack 已关闭
- per-WT 的 composite acceptance lane records 已经存在（至少部分存在）或 closeout bundle 已显式标记缺失/历史缺口
- 需要从六条复合验收 lane 的角度判断 milestone 是否可接受
- 需要检测 lane 覆盖完整性、fallback 是否充分、mandatory lane 是否缺失
- 需要综合六条 lane 的 verdict 形成 composite axis 的整体判定
- 系统必须保留每条 lane 的 record ref、status、carrier、fallback、evidence 追溯链、absorbed issue refs 和 residual risks，不能把六条 lane 压缩成一段模糊总结
工作流
- 确认角色边界：确认这是一轮 composite axis 检查，不是 blackbox / whitebox / anticheat 检查，也不是 milestone-status-skill 内的 aggregator 聚合。
- 验证输入隔离：检查输入包是否仅包含本轴所需数据（per-WT lane 报告、milestone composite_acceptance 配置、purpose、acceptance_criteria）。如果输入包中包含其他轴的 verdict 或未经本轴授权的外部判断，必须标记
isolation_guarantee: false 并记录泄漏来源。
- 载入输入：
- 所有已闭环 WT 的 composite acceptance lane records（如存在）以及 closeout bundle 中每条 lane 的 ref/status
- milestone 的
composite_acceptance 配置（来自 milestone artifact 的 composite_acceptance 字段或聚合合同中的 composite_lane_rules）
- milestone 的
purpose 和 acceptance_criteria
- 判定 review depth：读取 milestone 的 composite_acceptance 配置中的
review_depth（standard / deep），并结合 mandatory trigger table 判定当前深度。若配置缺失，先根据 milestone target_type、target_scenario、operator situation、purpose、node_types、changed paths、risk boundary 与 acceptance criteria 做目标/风险分类；分类命中 deep trigger 才进入 deep，分类明确为普通低风险则进入 standard，分类无法完成时返回 blocked / questions_required，不得无依据盲目默认 deep。
- 逐 lane 检查：对六条 composite acceptance lane 分别执行检查：
- C1 (code-review)：消费
code-review lane record，检查其独立代码审查覆盖（非 self-review）结论、证据 refs 与状态。它回答 review coverage 是否存在且覆盖关键 WT，不判定 evidence credibility bias；carrier/provenance 偏倚由 anticheat A6 判定。
- C2 (feature-completeness)：消费
feature-completeness lane record，检查 completion_signal→evidence 映射是否由 record refs 支撑。
- C3 (related-influence)：消费
related-influence lane record，检查相邻模块影响分析是否由 record refs 支撑。
- C4 (intent-completeness)：消费
intent-completeness lane record，检查 deliverables 与 milestone purpose 对齐证据是否由 record refs 支撑。
- C5 (operator-simulation)：审计已有
operator-simulation lane record、runbook/workflow/CLI/config evidence refs 与操作路径记录，判断 operator path 是否完整。C5 不生成新的 blackbox 行为场景、不运行 CLI/API、不替代 blackbox 轴的用户可观察行为测试。
- C6 (professional-review)：消费
professional-review lane record，检查独立 professional review 信号是否由 record refs 支撑。
- 判定 mandatory lanes：根据 mandatory/deep trigger table 判定当前 milestone 场景下哪些 lane 为 mandatory：
- 若命中 deep trigger（release / installer/deploy / migration / authority changes / destructive operation / path governance / security/privacy / cross-WT integration / release-prep）：所有 6 条 lane 均为 mandatory
- 否则：C1 (code-review) + C2 (feature-completeness) 为 mandatory，C3-C6 为 optional
- lane fallback 审查：对每条 lane，检查其 carrier 状态：
carrier: subagent 且 delegation_attempted: true：正常carrier: current-carrier 且 fallback_reason 有合法记录：可接受，但标记 fallback: truecarrier: human 且 fallback_reason 有合法记录：可接受，但标记 fallback: true- lane record 缺失且无 fallback 记录：该 lane 标记为
blocked
- lane record 存在但
carrier / delegation_attempted / fallback_reason 任一项缺失：该 lane 标记为 blocked
- lane status 为
missing / incomplete / historical_gap / contaminated：该 lane 不能 pass，且必须保留原 status、record ref、缺失字段或污染原因
- lane status 为
not_applicable：仅当 not_applicable_reason 明确且该 lane 非 mandatory 时可作为不适用记录；不得贡献 positive evidence
- 综合判定：对每条 lane 给出独立 verdict，再形成 composite axis 的整体判定：
- 任一 mandatory lane 为
blocked → 整体 verdict = blocked
- 任一 lane 为
hard_fail 且 mandatory → 整体 verdict = hard_fail
- 任一 lane 为
soft_fail 且 mandatory → 整体 verdict ≥ soft_fail
- 所有 mandatory lane 为
pass，optional lane 均为 pass 或不存在 → 整体 verdict = pass
- 生成 composite_verdict 报告：按照输出格式生成完整的结构化 verdict，包含每条 lane 的详细判定、证据引用和发现。
- 停止并返回：在产出 composite_verdict 后停止，不进入 aggregator 或其他轴的判定流程。
检查约定
Composite 轴任务简报
axis: composite触发条件: milestone 所有 worktrack 已关闭，进入 Milestone Gate 四轴检查阶段目标: 聚合 per-WT composite acceptance lane 报告，产出 milestone 级 composite acceptance verdictmilestone_id: 当前 milestone 标识review_depth: standard | deep范围内:
- 所有已闭环 WT 的 composite acceptance lane 报告
- milestone composite_acceptance 配置
- milestone purpose 和 acceptance_criteria
范围外:
- 代码实现细节（除非 lane 报告已引用）
- 其他三轴（blackbox / whitebox / anticheat）的 verdict
- per-WT gate evidence 的重新审查
- 生成新的代码检查或测试
约束: 只读、轴间不可见、不生成新代码检查完成信号: 所有 6 条 lane 已完成检查并给出 verdict，composite_verdict 已生成
Composite 轴信息包
milestone_idtarget_typetarget_scenariotarget_scenario_sourcetarget_scenario_confidenceoperator_situationreview_depthdeep_review_triggered: true | falsedeep_review_reason: 触发 deep review 的具体场景（如 "release + cross-WT integration"）mandatory_lanes: 根据 deep trigger table 判定的 mandatory lane 列表closed_wt_list: 已闭环 WT 的 ID 列表及各自状态lane_reports_available: 每个 WT 是否提供了 composite acceptance lane 报告的摘要composite_lane_records_by_worktrack: 每个 WT 的六条 lane record refs/statusesmilestone_purpose_summary: milestone purpose 的摘要acceptance_criteria: milestone 的 acceptance_criteriacomposite_acceptance_config: milestone 的 composite_acceptance 配置（如有）missing_inputs: 缺失的 lane 报告或配置项known_risks: 已知风险
Lane 检查细则
每条 lane 检查时需记录以下结构：
lane_check:
check_id: C1..C6
lane_name: code-review | feature-completeness | related-influence | intent-completeness | operator-simulation | professional-review
mandatory: true | false
per_wt_assessment:
- worktrack_id: "WT-xxx"
has_lane_report: true | false
lane_record_ref: string | N/A
lane_status: captured | linked | incomplete | missing | historical_gap | contaminated | not_applicable
carrier: subagent | current-carrier | human | missing
delegation_attempted: true | false | unknown
fallback: true | false
fallback_reason: "..." | N/A
lane_verdict: pass | soft_fail | hard_fail | blocked | missing
severity: none | low | medium | high
evidence_refs: [...]
absorbed_issue_refs: [...]
residual_risks: [...]
producer_ref: string | N/A
validation_ref: string | N/A
missing_required_fields: [...]
contaminated_reason: string | N/A
findings: "..."
gap_notes: "..."
aggregate_verdict: pass | soft_fail | hard_fail | blocked
aggregate_severity: low | medium | high
aggregate_finding: "..."
预期输出
使用这个技能时，产出一份至少包含以下章节的 composite_verdict 报告：
轴判定摘要deep review 触发分析逐 lane 详细检查mandatory lane 强制检查lane fallback 审计整体 composite verdictcarrier 隔离声明
结果必须包含以下字段的 composite_verdict：
composite_verdict:
axis: composite
verdict: pass | soft_fail | hard_fail | blocked
severity: low | medium | high
mandatory_lanes_applied: true | false
deep_review_triggered: true | false
deep_review_reason: "..." | N/A
checklist_results:
- check_id: C1
lane_name: code-review
verdict: pass | soft_fail | hard_fail | blocked
mandatory: true | false
severity: low | medium | high
lane_status: captured | linked | incomplete | missing | historical_gap | contaminated | not_applicable
lane_record_refs: [...]
carrier: subagent | human | current-carrier
fallback: true | false
fallback_reason: "..." | N/A
evidence_refs: [...]
absorbed_issue_refs: [...]
residual_risks: [...]
finding: "..."
- check_id: C2
lane_name: feature-completeness
verdict: pass | soft_fail | hard_fail | blocked
mandatory: true | false
severity: low | medium | high
carrier: subagent | human | current-carrier
fallback: true | false
fallback_reason: "..." | N/A
evidence_refs: [...]
finding: "..."
- check_id: C3
lane_name: related-influence
verdict: pass | soft_fail | hard_fail | blocked
mandatory: true | false
severity: low | medium | high
carrier: subagent | human | current-carrier
fallback: true | false
fallback_reason: "..." | N/A
evidence_refs: [...]
finding: "..."
- check_id: C4
lane_name: intent-completeness
verdict: pass | soft_fail | hard_fail | blocked
mandatory: true | false
severity: low | medium | high
carrier: subagent | human | current-carrier
fallback: true | false
fallback_reason: "..." | N/A
evidence_refs: [...]
finding: "..."
- check_id: C5
lane_name: operator-simulation
verdict: pass | soft_fail | hard_fail | blocked
mandatory: true | false
severity: low | medium | high
carrier: subagent | human | current-carrier
fallback: true | false
fallback_reason: "..." | N/A
evidence_refs: [...]
finding: "..."
- check_id: C6
lane_name: professional-review
verdict: pass | soft_fail | hard_fail | blocked
mandatory: true | false
severity: low | medium | high
carrier: subagent | human | current-carrier
fallback: true | false
fallback_reason: "..." | N/A
evidence_refs: [...]
finding: "..."
carrier: subagent | current-carrier
isolation_guarantee: true | false
isolation_leak_detail: "..." | N/A
carrier_isolation_broken: true | false
carrier_isolation_broken_reason: "..." | N/A
六条 Lane 检查清单
C1: code-review
| 维度 | 内容 |
|---|
| 判据 | 每项已闭环 WT 是否有独立代码审查覆盖（非 self-review），且 critical WT 是否被覆盖？ |
| 检查方法 | 读取每个 WT 的 code-review composite_lane_record；检查其 evidence refs 是否指向独立 reviewer、programmer review、peer review 或等效复核记录。若 lane record 缺失、状态为 non-pass，或只有 self-review 标记（implementer == reviewer）且无独立 review 记录，则为 coverage 缺失。不得从 closeout prose summary 补造 review coverage。 |
| pass 条件 | 所有已闭环 WT 均有独立 reviewer 记录，或 self-review 记录中声明了独立复核（如 programmer review）。 |
| soft_fail 条件 | 部分低权重 WT（weight ≤ 2）缺失独立 review，但所有 critical WT（weight ≥ 3）均有独立 review。 |
| hard_fail 条件 | 任一 critical WT 缺失独立 review 且无合理解释。 |
| blocked 条件 | lane 数据完全缺失，无法判断。 |
边界说明：C1 只回答“是否存在独立 review 覆盖”，不把 carrier identity 重叠本身当成反作弊结论。若发现 reviewer / implementer / gate_judge / evidence producer 的身份重叠，应在 C1 中记录 coverage 影响，并把 evidence credibility bias 留给 anticheat A6。C1 的 hard_fail 来源是 critical WT 缺少独立 review 覆盖，而不是 provenance 风险本身。
C2: feature-completeness
| 维度 | 内容 |
|---|
| 判据 | 所有 completion_signals 是否都有对应的证据？每个 signal 是否有至少一个 WT 的 evidence 支持？ |
| 检查方法 | 提取 milestone 的 completion_signals 列表；对每个 signal，读取已闭环 WT 的 feature-completeness composite_lane_record 和其 evidence refs，构建 signal→evidence 映射。不得从 closeout prose summary 搜索并合成 lane evidence。 |
| pass 条件 | 每条 completion_signal 至少有一条来自 WT 的可信证据。 |
| soft_fail 条件 | 部分非关键 signal 缺少直接证据但有间接证据（如相关 WT 的产出隐含覆盖了该 signal）。 |
| hard_fail 条件 | 关键 signal 完全无证据支撑，或 signal→evidence 映射中存在明显断裂。 |
| blocked 条件 | completion_signals 定义缺失或 lane 报告全部缺失。 |
C3: related-influence
| 维度 | 内容 |
|---|
| 判据 | 每项 WT 是否检查了对相邻系统的影响？每个 WT 是否考虑了变更对相邻模块、文档、部署流程、测试系统的影响？ |
| 检查方法 | 读取每个 WT 的 related-influence composite_lane_record 和其 evidence refs；必要时只用 WT contract 的 impacted_modules 作为 expected coverage 对照，不得把 contract prose 当作 lane record。 |
| pass 条件 | 所有已闭环 WT 均有相邻影响分析记录，且分析覆盖了实际变更涉及的相邻模块。 |
| soft_fail 条件 | 部分 WT 的相邻影响分析不完整，但未发现遗漏对 critical 模块的影响。 |
| hard_fail 条件 | 任一 WT 的变更明显触及相邻模块（如 shared interface、common config），但未做影响分析。 |
| blocked 条件 | lane 报告全部缺失且无法从 WT contract 推断。 |
C4: intent-completeness
| 维度 | 内容 |
|---|
| 判据 | 实现是否忠实于原始 purpose？每项 WT 的 deliverables 是否与 milestone purpose 在语义上对齐？ |
| 检查方法 | 读取每个 WT 的 intent-completeness composite_lane_record，用其 evidence refs 对齐 milestone purpose、acceptance_criteria 与每个 WT 的 scope / deliverables；检查是否存在 scope drift、偏移或过度实现。 |
| pass 条件 | 所有 WT 的 deliverables 与 milestone purpose 一致，无偏离。 |
| soft_fail 条件 | 存在可接受的轻微偏离（如 scope 内未计划但有益的小改进），但核心 purpose 未受影响。 |
| hard_fail 条件 | 任一 WT 的 deliverables 与 milestone purpose 存在实质性偏离，或遗漏了关键意图。 |
| blocked 条件 | purpose 定义缺失或 lane 报告全部缺失。 |
C5: operator-simulation
| 维度 | 内容 |
|---|
| 判据 | 已有 operator-simulation 证据是否覆盖真实 operator path，是否暴露或遗漏可用性断裂？ |
| 检查方法 | 读取已有 per-WT operator-simulation composite_lane_record、runbook、workflow、CLI/config evidence refs 和操作路径记录；审计这些记录是否覆盖关键步骤、恢复路径和边界条件。不得新建 blackbox 行为场景或实际运行 CLI/API。 |
| pass 条件 | operator 操作路径完整、可执行，所有关键步骤有明确的操作指南或自动化支持。 |
| soft_fail 条件 | 操作路径可用但有低严重度的可用性瑕疵（如某些边缘情况的文档不完整）。 |
| hard_fail 条件 | 操作路径存在断裂（如某步骤缺乏必要的前置配置说明、错误恢复路径缺失导致不可恢复状态）。 |
| blocked 条件 | 无法构建 operator 操作路径（产出物不足以支撑模拟）。 |
边界说明：C5 的“operator-simulation”是对已有 operator-path 证据的复合验收审计，不是新的 blackbox execution lane。需要从外部用户视角构建场景、运行 CLI/API、检查用户可观察行为或回归路径时，应由 milestone-blackbox-check 承担；C5 只能把缺失或不充分的 operator evidence 记录为 blocked / soft_fail / hard_fail。
C6: professional-review
| 维度 | 内容 |
|---|
| 判据 | 是否有领域专家或同行复核？检查是否存在外部/独立 review 信号。 |
| 检查方法 | 读取每个 WT 的 professional-review composite_lane_record；检查其 evidence refs 是否指向 programmer review、外部 reviewer 签名、peer review 记录、或等效的独立复核信号。不得从 closeout prose summary 合成 professional review。 |
| pass 条件 | milestone 级存在至少一个独立的 professional review 信号（如 programmer 对整体 milestone 的 review、或有记录的 peer review）。 |
| soft_fail 条件 | professional review 存在但覆盖不完整（如仅覆盖部分 WT），或 review 来自同一团队且独立性有限。 |
| hard_fail 条件 | 完全无 professional review 证据且 milestone 涉及 deep review 触发场景。 |
| blocked 条件 | lane 报告缺失且无法判断。 |
Mandatory / Deep Trigger 表
以下场景触发 deep review，使所有 6 条 lane 均为 mandatory：
| 场景 | Mandatory | 所有 6 条 lane 均为 mandatory | 说明 |
|---|
| release | yes | yes | 发布场景，所有 lane 必须覆盖 |
| installer/deploy | yes | yes | 安装/部署场景，operator-simulation 和 related-influence 尤为关键 |
| migration | yes | yes | 迁移场景，intent-completeness 和 related-influence 必须覆盖 |
| authority changes | yes | yes | 权限变更场景，professional-review 和 code-review 必须覆盖 |
| destructive operation | yes | yes | 破坏性操作场景，operator-simulation 和 code-review 必须覆盖 |
| path governance | yes | yes | 路径治理变更场景，related-influence 和 code-review 必须覆盖 |
| security/privacy | yes | yes | 安全/隐私场景，code-review 和 professional-review 必须覆盖 |
| cross-WT integration | yes | yes | 跨 WT 集成场景，feature-completeness 和 related-influence 必须覆盖 |
| release-prep | yes | yes | 发布准备场景，所有 lane 必须覆盖 |
| 其他场景 | — | C1 + C2 mandatory，C3-C6 optional | 标准场景，仅核心 lane 为 mandatory |
判定优先级：
- 先检查 milestone artifact 的
composite_acceptance.review_depth 是否显式声明为 deep 或 standard。若显式声明为 deep，所有 6 条 lane 为 mandatory；若显式声明为 standard，仍需检查是否命中不可降级 deep trigger。
- 若
composite_acceptance 配置缺失，不得直接默认 deep。必须先基于 target_type、target_scenario、operator situation、purpose、node_types、changed paths、risk boundary、acceptance criteria 与 known risks 分类当前 milestone。
- 若分类命中上述 trigger table 中任一 deep trigger 场景，所有 6 条 lane 为 mandatory，并记录
deep_review_reason。
- 若分类明确不命中 deep trigger，按 standard：C1 (code-review) + C2 (feature-completeness) 为 mandatory，C3-C6 为 optional。
- 若配置缺失且目标/风险分类无法完成，返回
blocked 并记录 questions_required、missing_inputs 与 composite_acceptance_config_missing: true；不得为了保守而无证据扩大为 deep，也不得静默降级为 standard。
判定记录：无论是否命中 deep trigger，都必须在输出中记录 deep_review_triggered（true/false）和 deep_review_reason（命中场景或 N/A）。
硬约束
本技能特有约束：
-
权限边界：只读操作。消费现有的 per-WT lane 报告。禁止修改任何代码、禁止生成新的 review 内容、禁止重新执行代码检查。本轴聚合已有报告，不产生新的代码级发现。
-
轴间隔离：禁止接收或读取其他三轴（blackbox / whitebox / anticheat）的 verdict。如果输入包中注入了其他轴的 verdict 或判断，必须标记 isolation_guarantee: false，记录泄漏详情到 isolation_leak_detail，并在该约束被打破的条件下继续完成本轴检查（标记但不阻断——阻断交由 orchestrator 判定）。
-
SubAgent 要求：本技能设计为在隔离 SubAgent 上运行。当 SubAgent 不可用时，降级为 current-carrier 执行，但必须在输出中标记 carrier_isolation_broken: true 并记录 carrier_isolation_broken_reason。标记 carrier: current-carrier 的同时不得声称 isolation_guarantee: true。若声称已 spawned SubAgent，必须记录 parent_runtime_dispatch_record_ref、spawned_subagent_record_ref、carrier_instance_id 和 isolation_boundary。缺少这些 linkage 的 spawned-axis claim 必须标记为 ambiguous/non-pass；current-carrier 不得 masquerade 为 SubAgent，除非同时记录具体 runtime boundary violation。
-
Lane fallback 记录：如果某条 lane 无法由 SubAgent 执行而 fallback 到 current-carrier 或 human，必须记录该 lane 名称、fallback 类型和 fallback 原因。缺失 lane 且无 fallback 记录 → 该 lane 的 verdict 必须为 blocked。不得在无证据的情况下将缺失 lane 标记为 pass。
-
Mandatory lane 强制：如果 mandatory trigger table 判定某条 lane 为 mandatory，且该 lane 的 verdict 为 blocked 或缺失，则整体 composite_verdict.verdict 必须为 blocked，无论其他 lane 是否 pass。mandatory lane 的缺失不可被 optional lane 的 pass 补偿。
-
不生成新检查：本轴不执行代码审查、不运行测试、不扫描漏洞、不分析依赖。所有判断必须基于已有的 per-WT composite_lane_record 内容。如果某 lane record 不存在、状态为 missing / incomplete / historical_gap / contaminated，唯一合法行为是保留该状态并记录缺失——不得自行补充分析。本约束是本轴与其他三轴的本质区分：blackbox / whitebox / anticheat 可以生成新发现，composite 只能聚合已有 records。
-
缺失配置不得盲目 deep：当 composite_acceptance 配置缺失时，必须先做 target/risk classification。分类依据不足时返回 blocked / questions_required，而不是无条件 deep review。只有存在可引用 deep trigger 证据时，才允许将缺失配置场景升级为 deep。
-
边界不重复：C1 负责 independent review coverage，A6 负责 evidence credibility bias；C5 负责审计已有 operator path 证据，blackbox 负责生成和执行用户可观察行为/场景测试。Composite 不得用 C1/C5 复制 anticheat 或 blackbox 的主动检查职责。
-
Lane verdict 审计链：每条 lane 的 verdict 必须有明确的 record_ref、lane_status 和证据引用（evidence_refs）。不得给出无证据引用的 verdict。如果证据指向的文件路径与 WT 的 closeout record 不一致，必须标记并记录差异。
-
Lane record 状态保真：captured / linked 可作为候选 evidence；missing / incomplete / historical_gap / contaminated 必须作为 non-pass evidence 保留；not_applicable 必须保留 reason，且不能贡献 positive evidence。禁止从 prose closeout summary、旧 composite paragraph 或 milestone summary 后验合成 composite_lane_record。
-
输出协议：先生成完整的 checklist_results（6 条 lane 各自完整的 per-WT 评估），再提取 composite_verdict。空字段使用 N/A 或省略。重复上下文使用 artifact 引用，不得内联全文复制。
资源
- Milestone Gate 证据聚合合同 — §五 composite_lane_rules：composite acceptance lanes 在 milestone 级的消费规则和 veto power 定义。
- Composite Milestone Acceptance — composite acceptance 的 lane 定义、verdict model 和 fallback 规则。
- Composite Lane Evidence Records — 随包字段说明定义 per-WT lane record schema、status 语义和 closeout bundle link shape；运行时不得依赖源码仓库文档路径。
- milestone-gate-aggregation.md — Milestone Gate 聚合合同，定义 composite_lane_rules 和 Layer 2 聚合逻辑。本技能（composite lane check）是 Layer 2 的输入之一。
- milestone.md — Milestone artifact 合同，定义 aggregation_rules 字段和 composite_acceptance 配置。
- Skill 公共约束已内联于 §硬约束
- Single-Acceptance Verdict — per-WT 单体验收结果，定义 single-acceptance verdict 的结构化格式与判定规则。C2 (feature-completeness) lane 应消费其中的
completion_signals_passed / completion_signals_failed 字段作为预聚合证据。
