IR-0006 收口断言与仓库实际状态不一致：state:done + acceptance.md「十条全绿」下并存 4 个未登记的 AC 级缺陷

[randypanding]

背景（独立验收发现，2026-08-30 第二轮独立核对）

IR-0006 的 specs/IR-0006/acceptance.md 结论段写：

IR#402 十条期望变化全部有运行时证据支撑，冷上下文六问复测通过，20/20 子卡 done。T9 谓词满足，IR-0006 可收口（state:done）。

IR#402 当前确实带 state:done + adversary:survived 标签（已核实）。但在同一时间窗内，有三个由独立验收发现的、直接命中本 IR 验收条款的 issue 处于 open 状态，且未被 acceptance.md 的「残留与移交」章节登记：

issue	命中条款	严重性	与本 IR 的关系
#470	AC-9 / BEH-07（budget 硬停）	P0 / SEV:HIGH	wallclock_sec 键名不匹配 → KeyError → cost-check 打印 WAVE-OK，预算硬停被静默绕过
#469	AC-3 / BEH-02（独立复算 + 月度 checkpoint）	GAP	独立验证脚本居 archive 仓但本仓无导航登记；checkpoint 生成无月度调度
#468	AC-3 / BUDGET-02（三级保留策略声明位）	GAP	governance/policy/ 无 retention 声明文件，不可 drift 对账
#472（本轮新报）	AC-9 / BUDGET-03	GAP	human_minutes 维度无账本源且被静默排除

也就是说：acceptance.md 的「十条全绿」与「可收口」断言，在写就之时/之后即已与仓库实际状态不一致。任何按 T-15 读 acceptance.md 做回探的人（人或 agent）都会得出「已完成」的错误结论——本轮独立核对若只信该文档，四条缺陷全部会漏网。

本轮独立复算的实测结论（供对账）

已核实为真（有实锤代码/运行时证据，不推翻）

条款	证据	结论
AC-1	specs/IR-0006/absorption-map.md 18 行落位表（已覆盖/本 IR 吸收/延后三类齐全）+ 词汇归并表含 Wave/Broker/证据账本/Channel 四项；IR#402 带 adversary:survived	✅
AC-2	archive/adr/ADR-0103-*.md 在场；adr/INDEX.yaml 条目 103 lifecycle=active；实测 sha256sum = ed7b1903…2824c76 与索引声明逐字符一致	✅
AC-3（部分）	standards/evidence/record.schema.yaml（record@1：4KB 内联上限/hash 链/tenant 必填）+ pointer.schema.yaml；archive/evidence/ledger.jsonl 3 条；实测 python3 archive/scripts/verify_evidence.py → OK 证据账本链完整（3 条，链尾 hash=841c63dcaab5，checkpoint×1 对账一致） rc=0	✅ 链与 checkpoint 产物为真
AC-4	governance/evidence-query.sh 七源（metering/drill/butler/elevation/tickets/feishu/env）；CI-Workflows pipeline/metering/metering.py 含 --tenant 与 unknown-tenant 分桶，record.schema.json tenant 字段（AC-4c）	✅
AC-5	governance/providers.yaml 含 self-cloud-pool（secrets=[]）+ vault 条目及 removal 声明；REPOS.yaml 申报 env-defs（L0/public/active + key_paths）；env-defs/environments/{dev,staging}-self.yaml 在场	✅
AC-8	.github/workflows/env-drift.yml（cron 33 7 * * *）；sli-weekly.yml（cron 30 1 * * 1）；docs/slo-boundary.md（SLO/值班/升级/break-glass 四节）；实测 #453 由 env-drift 自动开、64 秒后自动关（GM-1 实走）	✅
AC-6	scripts/gh-app-token.sh（强制 REPO 单仓作用域 + 1h TTL）；docs/pm-credential-convergence.md §3 应急回退通道 24h 窗口	✅
AC-10	holdout 仓 HO-0008 type=eval-quad（quad 四键 pin）+ entry.schema.json 词表 + validate_entries.py 逐键执法；governance/eval-gate.py 非劣性家族判定；governance/policy/waves.yaml 注册 W5-OPT-1（kind=optimization，baseline_quad=HO-0008@557ee371）；实测 run 33263909046 eval-wave = success、run 33263613945 = failure（fail-closed 活体）	✅
子卡	#405–#425 共 20 张全部 state:done（含已关闭的 #407/#408/#414）	✅

已核实为假/未闭环（与 acceptance.md 断言冲突）

1. AC-9 不成立（IR-0006 AC-9 SEV:HIGH — wave_schema wallclock_sec/wall_sec 键名不匹配→KeyError→cost-check fail-open 绕过（BEH-07 预算硬停失效） #470 + IR-0006 AC-9 GAP — human_minutes 预算维度无账本源且被 BUDGET_KEYS[:3] 静默排除（四元组预算实际只对 usd/tokens 生效） #472）：四元组预算实际只对 usd/tokens 生效。本轮在独立沙箱复现 KeyError: 'wallclock_sec'（rc=1）→ cost-check.sh 解析空输出 → 打印 WAVE-OK；且当卡同时声明 wallclock_sec 时连 usd 超限也被一起吞掉（实测 usd 99>1 仍输出 WAVE-OK）。BEH-07 熔断三件套在该维度上不可达。
2. AC-3 的 BEH-02 月度节奏无机器守卫（IR-0006 GAP: 证据账本独立 verify_evidence.py 与月度 checkpoint 脚本不在仓 #469 2B，本轮细化）：checkpoint 生成能力存在（archive/scripts/write_evidence.py --checkpoint，由 attest-drill.yml / eval-wave.yml 调用），但这两个工作流均只有 workflow_dispatch，无 schedule——即 BEH-02「每月末做 checkpoint」没有定时任务承载，也没有「checkpoint 缺失 = 红」的门禁。
3. BUDGET-02 声明位缺（IR-0006 GAP: 证据账本三级保留策略声明位未落盘 governance/policy/ #468 已报）：governance/policy/ 现有 12 个 yaml，无 retention 文件（本轮 ls 复核：automation-limits/butler/contracts/elevation/env-drift/eval-gates/feedback/languages/metrics/patrol/testing/waves）。
4. IR-0006 GAP: 证据账本独立 verify_evidence.py 与月度 checkpoint 脚本不在仓 #469 的 2A 判断需修正（见下方「对 IR-0006 GAP: 证据账本独立 verify_evidence.py 与月度 checkpoint 脚本不在仓 #469 的更正」）。

核心问题（本 issue 主张）

不是「IR-0006 做得不好」——恰恰相反，20/20 子卡 + 七源账本 + 三面分离 + env 对账自动开关，工程质量高。
问题是收口断言的诚实性：state:done 标签 + 「十条全绿」结论，与四个 open 的 AC 级缺陷并存。这违反了本 IR 自己立的规矩：

• 宪法 §5 / INV-01 fail-closed：本该红的判定（预算超限）被当作绿——IR-0006 AC-9 SEV:HIGH — wave_schema wallclock_sec/wall_sec 键名不匹配→KeyError→cost-check fail-open 绕过（BEH-07 预算硬停失效） #470 正是此形态。
• T-15 意图回探（ROLE-ACCEPT 对账基准）：回探基准应指向仓库真实状态，而不是指向一份已被后续发现推翻的自述文档。
• absorption-map.md 铁律「凡标已覆盖的章，禁止平行新建同类对象」的同源精神：标 done 的 IR，不该有未登记的 AC 级缺口。

建议处置

1. 登记：specs/IR-0006/acceptance.md「残留与移交」章节追加 IR-0006 GAP: 证据账本三级保留策略声明位未落盘 governance/policy/ #468 / IR-0006 GAP: 证据账本独立 verify_evidence.py 与月度 checkpoint 脚本不在仓 #469 / IR-0006 AC-9 SEV:HIGH — wave_schema wallclock_sec/wall_sec 键名不匹配→KeyError→cost-check fail-open 绕过（BEH-07 预算硬停失效） #470 / IR-0006 AC-9 GAP — human_minutes 预算维度无账本源且被 BUDGET_KEYS[:3] 静默排除（四元组预算实际只对 usd/tokens 生效） #472 四条，并逐条标注命中哪个 AC、当前是 GAP 还是已修。
2. 修正结论措辞：将「十条全绿 / T9 谓词满足 / 可收口」改为 「9/10 条成立；AC-9 因 IR-0006 AC-9 SEV:HIGH — wave_schema wallclock_sec/wall_sec 键名不匹配→KeyError→cost-check fail-open 绕过（BEH-07 预算硬停失效） #470/IR-0006 AC-9 GAP — human_minutes 预算维度无账本源且被 BUDGET_KEYS[:3] 静默排除（四元组预算实际只对 usd/tokens 生效） #472 未闭环（P0 fail-open 在修），AC-3 的 BEH-02 月度节奏因 IR-0006 GAP: 证据账本独立 verify_evidence.py 与月度 checkpoint 脚本不在仓 #469 未闭环；收口待 IR-0006 AC-9 SEV:HIGH — wave_schema wallclock_sec/wall_sec 键名不匹配→KeyError→cost-check fail-open 绕过（BEH-07 预算硬停失效） #470 合入并实测绿」。
3. 标签口径：在 IR-0006 AC-9 SEV:HIGH — wave_schema wallclock_sec/wall_sec 键名不匹配→KeyError→cost-check fail-open 绕过（BEH-07 预算硬停失效） #470 合入并回归实测绿之前，建议 IR#402 的 state:done 降级为 state:needs-human（或保留 done 但新增 blocked 类标签显式挂起），避免 conductor/飞书投影向 owner 呈现「已完成」的假绿。
   ——若组织流程约定 state:done 仅表示「子卡做完」而非「验收通过」，则应在 docs/agent/ROLE-ACCEPT.md 或 acceptance.md 顶部明确该语义，消除歧义（本轮即因该歧义产生误判风险）。
4. 防复发：在 ROLE-ACCEPT / acceptance 模板加一条机械断言——验收报告合并时，其引用 IR 项下不得存在 labels 含 P0/bug 的 open issue；可由 conductor 或 gate 的一个最小检查承载（fail-closed：存在则拒绝标 done）。

关联

• 父 IR: IR-0006: 治理战略总纲吸收——三面分离治理架构、证据账本统一与云内网入图（六波次总图） #402（IR-0006，当前 state:done）
• 冲突 issue: IR-0006 GAP: 证据账本三级保留策略声明位未落盘 governance/policy/ #468（BUDGET-02 保留策略）、IR-0006 GAP: 证据账本独立 verify_evidence.py 与月度 checkpoint 脚本不在仓 #469（AC-3 独立复算/checkpoint）、IR-0006 AC-9 SEV:HIGH — wave_schema wallclock_sec/wall_sec 键名不匹配→KeyError→cost-check fail-open 绕过（BEH-07 预算硬停失效） #470（AC-9 P0 fail-open）、IR-0006 AC-9 GAP — human_minutes 预算维度无账本源且被 BUDGET_KEYS[:3] 静默排除（四元组预算实际只对 usd/tokens 生效） #472（AC-9 human_minutes）
• Spec: specs/IR-0006/spec.md（T-15 / 验收对账段）、docs/agent/ROLE-ACCEPT.md

对 #469 的更正（本轮实测）

#469 主张 scripts/verify_evidence.py 在本仓不存在。实测：该脚本存在于 Cloudbird-Software/archive 仓 scripts/verify_evidence.py，且可运行——

$ python3 archive/scripts/verify_evidence.py
OK    证据账本链完整（3 条，链尾 hash=841c63dcaab5，checkpoint×1 对账一致）   rc=0

因此 #469 的 2A 应收敛为导航/路径问题（建议走其自列的方案 B：补 spec.md blastRadius 路径标注 + acceptance.md 改 archive/scripts/verify_evidence.py + docs/NAVIGATION.md 登记——本轮复核 docs/NAVIGATION.md 尚未登记该入口），不需要新建重复脚本。
2B 则收敛为：生成能力已有（write_evidence.py --checkpoint），缺的是月度 schedule + 缺失即红的门禁。