IR: 卡绑定测试与红队守门制度（LLM-as-a-Verifier 验证 + 意图兜底道闸）

job（要完成的待办）

建立"卡绑定测试 + 红队守门"制度，并把验证（Verify）方式一次性说清：

LLM-as-a-Verifier 立为组织默认 verifier 范式：凡 LLM 参与判定的环节（红队攻击是否成立、实现是否满足 AC、任何未来的 LLM 判定），一律采用开源 LLM-as-a-Verifier 实践——绝对细粒度 reward（score token logprob 分布取期望）+ criteria 分解 + K 次重复评估 + 阈值构成 gate；PPT 锦标赛仅作 best-of-N 选择层，不进判定链；判定输出为结构化连续分，不接受散文结论。不自研打分轮子。
红队按此范式从建立第一天做起：红队 pipeline 的判定环节不使用任何临时 prompt 解析，直接以 llm-verifier 连续分 + 阈值产出 verdict；报告中的每条证据引用由代码对运行时刻真实工件做字符串级机械核对（硬谓词），核对基准版本写入报告。
卡绑定测试：开卡必须挂钩验收测试（无测试不开卡）；实现 PR 绑定卡后自动走卡对应测试集与已注册 holdout 测试（合并阻断）。
红队守门：红队审计覆盖意图→spec→测试设计路径——该路径（specs/** 的 spec/suite 设计与变更）每个 PR 都必须经红队审计并作为合并阻断项，因为测试设计错了，下游开发 gate 全部失效；开发实现路径的 PR 不走红队（实现 PR 只跑确定性测试）。语义审计（spec vs suite 缝隙，ADR-0067 S1–S5）verdict=insufficient 时机器阻断（Veto），survived 才放行。此频率决策是对 ADR-0067"spec+波次收口"频率的修订，随本 IR 以 ADR 落实。
意图探索（非 Verify，是兜底道闸）：红队顺带做意图层探索（S6 重复已有功能 / S7 违反治理约束 / S8 越出 blastRadius），不产生阻断性判定，命中带证据报人裁决。
红队住在沙箱里：红队 AI 以 GitHub Actions job 形态存在，沙箱内直接完成代码库探索；人类唯一配置 = 一个 org secret（LLM API key）+ 一个 org variable（endpoint + 模型名）。

触发场景

每次开 IR 卡进入 spec 阶段：当前 spec PR 合并后即可被认领，无任何"测试是否充分"的机器审查。
每次实现 PR 绑定卡：当前无任何关卡强制"该卡存在对应测试"，卡可以裸奔到合并；Verify 判定逻辑也无可复用框架，各处自己糊 prompt 解析、输出散文结论。
实现 agent 在开发中发现验收测试本身写错：当前无制度化上报回路，要么硬着头皮实现错误测试，要么私自改测试绕过。
卡意图本身有问题（重复建设/违反治理/越界）时：当前没有任何一道闸能兜住，问题要到 review 甚至更晚才暴露。
一旦某个 IR 形成波次与工作卡后，规划 agent 同步设计的测试并没有成为 PR 的阻断项；也没有强制规划 agent 设立 holdout 测试并放在 holdout 仓库、使之成为开发 agent 不可改的合并阻断项。

当前痛点的证据

governance/transitions.yaml:15 状态全集已列 redteam、wave-planned，但转移表仅有 T1–T4——红队在状态机里是死状态。
adversary 红队管线整体不存在：无 adversary workflow、无判定脚本、无 attack-strategies.yaml；S1–S5 攻击面目前仅是 adr/ADR-0067 的散文描述。红队 Veto 无任何机器载体。
governance/policy/testing.yaml 政策止于 T-13，无"卡存在但无测试"的检测条款——开卡不带测试在当前政策下不违规。
main-protection.json required checks 仅 gate + org-gate，红队结果不在合并阻断面内。
template-service 的卡绑定测试体系（card-test、run-gates、g060-test-tamper、g050-fail-before）目前只存在于 adr/ADR-0061 与 W2 任务卡设计中，代码未落地；治理仓更无等价机制。
已有 spec 目录佐证测试缺位：specs/IR-0001、IR-0002、IR-0003 均无任何 suite/ 验收测试目录。
Verify 方式从未成文：现有制度只说"gate 聚合 + PR review"，LLM 参与判定时用什么方法、什么框架、什么阈值，无任何声明。
2026-08-22 手动红队 dogfood（IR IR: 卡绑定测试与红队守门制度（LLM-as-a-Verifier 验证 + 意图兜底道闸） #263 评论链）实证：无范式约束时，LLM 判定会出现"裁判凭记忆核对证据"的事故——两份红队报告错误指控候选幻觉，后发 erratum 撤回。证据核对不代码化、不锚定真实工件，判定链就不可信。

期望的可观察变化（验收时能在线上看到的事实）

Verify 默认范式

LLM-as-a-Verifier 写入 GOVERNANCE.yaml / testing.yaml 为组织默认 verifier 范式（绝对细粒度 reward + criteria 分解 + K 重复 + 阈值 gate；PPT 仅选择层；连续分输出，禁散文结论）。运行时证据：一次真实判定的 CI 日志含 llm-verifier 实际调用记录、逐 criterion 连续分 JSON 与 token 消耗——不接受"声明已写入"作为证据。
阈值成 gate：阈值随 criteria 文件版本化，标定使用含已知不合格样本的 golden set，标定记录留档。运行时证据：故意构造的低分样本触发 gate 失败的反向测试日志（证明判定脚本真的做了数值比较，而非恒绿）。
证据核对硬谓词代码化：红队/verifier 报告的每条引用由代码对运行时刻的真实工件（issue body / spec 原文）做字符串级机械匹配；核对所用基准的版本（SHA/抓取时间）写入报告；核对不通过的命中作废并记录。运行时证据：机械核对脚本的实测——对一份含已知捏造引用的样本报告，作废记录全部命中（本 IR 的 dogfood erratum 为反面教材，见 IR: 卡绑定测试与红队守门制度（LLM-as-a-Verifier 验证 + 意图兜底道闸） #263 评论链）。
endpoint 三探测校验制度化：logprobs 有无、top_logprobs 上限、prefill/structured_outputs 支持；探测结果决定打分抽取路径与精度预期并写入报告；不满足最低要求的 endpoint 配置即失败。运行时证据：LongCat 无 logprobs 校验失败记录、aliyun top_logprobs=5 截断走降级路径记录（dogfood 已有，pipeline 内重放即可）。
verifier token 成本随 run 持久化，纳入 automation-limits.yaml 预算口径；K 与 pivots 为暴露的成本旋钮。运行时证据：一次真实 run 的 token 账落盘文件（dogfood 已发生"成本无法回溯"事故，此条为其修复）。

红队守门

状态机 T5（spec→redteam，前置=spec PR 合并+suite 就绪）/ T6（redteam→wave-planned，前置=红队 survived）生效，conductor 路由真实卡；adversary 经 repository_dispatch 自动触发，check run 以 App 令牌写回。运行时证据：conductor 按 T5/T6 转移的状态变更记录 + 证明无绕过转移（needs-human 不可直跳 wave-planned）的自动化测试。
红队沙箱：Actions job 内 checkout 完整代码库 + sparse-checkout 治理规范，红队 AI 沙箱内只读探索；配置面 = 1 org secret + 1 org variable。运行时证据：Action run 日志含 LLM API 真实请求与代码库探索操作日志——空壳 job（echo survived）不满足本条款。
Veto 强制力：insufficient → state:needs-human 且无法进入 wave-planned；adversary check 纳入 specs/ 路径（spec/测试设计路径）全部 PR 的 required checks——该路径每 PR 必走红队审计；开发实现路径 PR 不要求红队 check（EXPECTED_SKIP 模式条件化豁免）。运行时证据：用故意极差 spec 触发真实 insufficient 的端到端记录——Veto 理由由红队 AI 真实产出，且修复针对该理由后 survived；开发路径 PR 无 adversary check 仍正常合并的对照记录。
红队 run 为唯一证据，挂了自动兜底：红队是否跑过只认指定 Action 历史 run；run 失败（含 no-attempts 白卷，有界重试≤2 次后）自动开特定标签 issue、停止规划 agent 相关产出并提醒人类。运行时证据：Action failure → 自动开 issue 的实测记录；Action success 但产物为空报告 → 同样按失败处理的实测记录。
意图兜底道闸 S6–S8 落地：入 attack-strategies.yaml（标 requires_explore），只报人不阻断；S8（blastRadius 集合比对）为确定性脚本；命中必须带 file:line 且经条款 3 的机械核对。运行时证据（正向）：对一张已知含 S6 重复问题的卡，道闸在卡下产出含 file:line 的评论。IR: 卡绑定测试与红队守门制度（LLM-as-a-Verifier 验证 + 意图兜底道闸） #263 dogfood 的三条有效命中（专用 APP vs AG-1、每 PR 审计 vs ADR-0067 频率、holdout 强制 vs DECISION-02 隔离）作为本道闸的首批实跑记录存档。

卡绑定测试

T-14（card_bound_test_required）：spec PR 必须含 suite/ 且卡可解析到测试集；实现 PR 带卡必须跑卡对应测试 + 已注册 holdout 测试且通过（合并阻断）。holdout 测试注册由验证者 APP 执行（owner 裁决：验证者 APP 可挂载 holdout 仓，ADR-0056 DECISION-02 对该身份的限制随本 IR 以 ADR 修订）；机器校验 PR 引用的 holdout hash 与已注册记录一致，holdout 内容对开发 agent 不可改。运行时证据：缺测试 PR 被阻断的真实 CI 红记录；holdout hash 不匹配被阻断的真实 CI 红记录；开发 agent 身份尝试改 holdout 测试被拒的 403 记录。
验证者 APP 设立：新设验证者专用 GitHub App（测试/验证身份，与开发身份 cloudbrid-agent 分离），测试相关内容（suite/、holdout、卡测试）的 CODEOWNER = 验证者 APP + 人类，防止开发 agent 经既有 APP 修改测试；AG-1（身份唯一性）随本 IR 以 ADR 修订为"开发身份唯一 + 验证者身份独立"。T-15（intent_backstop）、AR-10（red_team_veto）入册；g060 等价关卡落地治理仓（specs/*/suite/** 按 IR 分片锁定），非验证者 APP/owner 改测试 exit 2 且自动开 issue 路由 owner 裁决。运行时证据：验证者 APP 安装与权限范围查询记录；开发 APP 令牌改测试被拒的 403 日志；真实 exit 2 阻断日志 + 阻断后自动开 issue 的记录。
端到端实跑：一张真实卡走通 ir-signed→spec→redteam→（真实 Veto 一次→修复→survived）→wave-planned→认领→PR 绑定卡测试→合并全程。运行时证据：全程 issue 时间线 + 各 check run 链接链。

非目标（NONGOAL）

不自研 LLM 验证/打分框架——默认范式指定 LLM-as-a-Verifier，本 IR 只做接入与制度化
不把 PPT 锦标赛排名分当作判定信号——它是选择层；判定只认绝对 reward 对阈值
不把意图探索（S6–S8）做成 Verify 工作或阻断关卡——它是兜底道闸，只报人不拦路
不再另设第三个 App 身份（验证者 APP 之外的扩展另起 ADR）；AG-1 修订（开发身份唯一 + 验证者身份独立）与 DECISION-02 修订（验证者 APP 可挂载 holdout 仓）随本 IR 以 ADR 完成，先补票后实施
开发实现路径 PR 不强制红队审计（红队聚焦意图→spec→测试设计路径；实现 PR 只跑确定性测试与 holdout 测试）
不做运维安全红队（registry 的 red-adversary 是另一物）
不改 verifier-exam 入职考试机制（ADR-0072 已冻结）
不替换现有 gate / org-gate 结构，红队作为新增 check 并入
不赋予红队任何写权限（沙箱内只读探索 + LLM 判定，产物即焚）
不在本 IR 内重建 template-service 全套 quality 体系（ADR-0061/W2 卡已覆盖，本 IR 只做治理仓侧制度与 T-14/T-15 条款）
不要求红队/verifier 与实现 agent 使用同一模型（org variable 可独立指定，支持分角色配模型）

约束 / 不可违反项

遵守 GOVERNANCE.yaml 全部铁律；transitions.yaml / testing.yaml / GOVERNANCE.yaml / conductor / workflows 均为 C1 路径：PR + ADR + owner-merge
默认范式铁律：任何 LLM 判定环节的输出必须是 llm-verifier 结构化连续分（逐 criterion、K 次重复）；散文结论、单次离散打分、锦标赛胜率均不得作为 gate 输入
证据核对铁律：核对由代码执行、基准为运行时刻真实工件、基准版本写入报告；裁判（人或 LLM）凭记忆/转述比对一律无效（IR: 卡绑定测试与红队守门制度（LLM-as-a-Verifier 验证 + 意图兜底道闸） #263 erratum 为鉴）
AG-1（身份唯一性）与 ADR-0056 DECISION-02（holdout 隔离）的修订必须随本 IR 的 C1 路径 PR 以 ADR 先行完成，不允许先实施后补票
INV-02 不破：跨仓触发与 check 写回一律经 App 令牌（单仓作用域、1h 过期），GITHUB_TOKEN 不持有状态写权；验证者 APP 令牌同样单仓作用域、仅测试/验证路径写权
沙箱边界：harden-runner 出向白名单（github.com / api.github.com / objects.githubusercontent.com / LLM endpoint，egress-policy: block）；job 内凭据仅 org secret 注入的 LLM_API_KEY（无 repo 写权）；一次性 runner，产物判定后即焚
endpoint 准入：三探测（logprobs / top_logprobs 上限 / prefill 支持）结果决定抽取路径；top_logprobs 截断造成的精度折损必须在 run 报告中声明
llm-verifier 依赖版本钉点（pip 版本 + lock），org-required-workflows 钉点一并改 commit SHA
语义审计维度不放宽 ADR-0067 判定语义：insufficient=blocking、survived=放行、no-attempts=infra 失败（有界重试≤2 次后转 needs-human + dead-man + 自动开 issue）
意图探索道闸的任何输出不构成机器阻断条件；只有 owner 裁决后可转化为状态操作

人类愿意接受的验收证据

13 条期望变化各自的运行时证据（见各条加粗段）：真实 CI 日志、连续分 JSON、反向触发记录、真实阻断红记录、自动开 issue 记录、端到端链接链
一份真实卡的 criteria 文件及其从 AC 派生的对照、golden set 标定记录
配置面证据：org secret / org variable 各一项的查询结果（key 本身不可见），证明此外无人类配置
endpoint 三探测报告（含一个被拒 endpoint 的失败记录）
机械核对脚本对含已知捏造引用样本的作废记录
llm-verifier 版本钉点 diff

可逆性偏好

逐步回滚：红队 check 可从 required checks 摘除（回到 report-only）；T5/T6 可停用（卡按原 T1–T4 流转）；意图道闸可整体关停（本就不阻断）；llm-verifier 实现可替换，但替换物必须仍满足默认范式四件套（绝对细粒度 reward + criteria 分解 + K 重复 + 阈值 gate）。任何单步回退不破坏已合并的卡历史。

质量-速度旋钮

质量优先：红队 Veto、卡绑定测试、机械证据核对不接受降级；K 与 pivots 默认取保守高值。可接受的降级面：意图道闸允许因 LLM 不可用而跳过（跳过须留痕）；成本超预算时先降 K/pivots，不动判定语义与阈值；endpoint 仅支持截断 logprobs 时接受精度折损但必须在报告中声明。

红队 Dogfood 报告 — IR #263

人工触发的手动红队（pipeline 不存在前的 dogfood）。harness = kimi code，红队 AI = LongCat-2.0（api.longcat.chat），判定 = harness 对照 IR 原文逐条核证据。
成本：语义审计 12,013 tokens（prompt 3,474 / completion 8,539）；意图兜底 23,128 tokens（prompt 17,956 / completion 5,172）。合计 ≈ 35k tokens。

一、语义审计（spec vs AC 可验证性，ADR-0067 S1–S5 适配）

verdict: insufficient（Veto）——AC 存在系统性"声明式合规"病。

红队有效利用的缝隙（经 harness 核对 IR 原文确认成立）：

IR 条目	缝隙	摆拍手法
1 Verify 制度化	只要求"声明写进文件"	贴了声明文本但 CI 从不调 llm-verifier；criteria 文件是空壳
2 阈值成 gate	阈值无标定约束	设 0.01 阈值全放行，或 gate 硬编码 pass
3 红队沙箱形态	Action 存在≠真实执行	job 内不调 LLM，直接 echo survived
4 Veto 强制力	隐藏转移可绕过	conductor 留 T4 变体从 needs-human 直跳 wave-planned；EXPECTED_SKIP 豁免面过宽
5（S6–S8 道闸）	策略入表≠探索真实发生	S8 用过时/空集合比对，探索脚本恒返回无命中
7（T5/T6）	转移入表≠路由生效	conductor 硬编码旧路径；T5 前置"suite 就绪"恒为真
8（T-14/T-15）	条款入册≠执行层读取	执行层从不读取新条款
10（端到端实跑）	实跑可导演	Veto 是人工先置 insufficient 再"修复"的剧本

修补方向（红队建议，harness 认可）：每条 AC 必须从"存在性检查"升级为"运行时证据"——CI 日志含 llm-verifier 实际调用与 token 消耗、gate 输出逐 criterion 连续分而非布尔值、Action run 必须由 conductor 自动触发且产出结构化评分 JSON、S8 用实时集合比对、端到端 Veto 必须由红队 AI 真实产出理由且修复针对该理由。

红队幻觉剔除（harness 判定）：红队声称"IR 说 10 条实际 13 条"并攻击了"条目5 规划agent测试落地+holdout""条目6 规划agent专用APP+CODEOWNER""条目7 红队Action run作为唯一证据"——IR 原文不存在这些内容，系红队捏造，三条攻击作废。IR 条目数实为 10，编号无误。

二、意图兜底道闸（S6–S8）

verdict: 本次运行无效（证据全数捏造），按 ADR-0067 语义视同 no-attempts → infra 失败处理，不产生任何结论。

S6：判"无命中"。harness 复核：结论方向正确（ADR-0061/0067/0072 均为"已决策未实现"，IR 是承接而非重复），予以采信，但因同批输出存在捏造，采信度降级。
S7 三条命中（违反 AG-1 身份唯一性 / 篡改 ADR-0067 判定语义与频率）：全部基于捏造证据。IR 原文无"新设规划 agent 专用 APP"、无"每 PR 红队审计"、Veto 语义与 ADR-0067 的 insufficient=blocking 一致并未篡改。三条全数驳回。
S8 一条命中（越界访问 holdout 仓）：捏造。IR 原文不涉及 holdout 仓。驳回。

三、Dogfood 元结论（比单卡结果更重要）

弱模型当红队会产生"引用型幻觉"：捏造不存在的条款再据此前后一致地"命中"。本次 4 条 S7/S8 命中 100% 是幻觉，若无人核证据，道闸会变成狼来了发生器。
这恰好验证了 IR 的设计选择：(a) 命中必须附机器可复核证据（file:line/原文引用）且 harness 机械核对——本次 harness 靠对照原文就剔除了全部幻觉；(b) 意图道闸只报人不阻断——幻觉没有造成任何阻断后果；(c) llm-verifier 的 K 次重复评估 + 连续分正是压制单次幻觉的统计手段。
语义审计维度弱模型够用：S1–S5 摆拍攻击有效命中率 8/10（剔除幻觉后），说明"找 AC 的可摆拍性"对模型能力要求低于"意图合规判定"。两个维度对模型等级的需求不同，org variable 应支持分维度配模型。
** pipeline 落地时的硬性设计**：judge 环节必须机械核对每条命中的引用是否在原文中存在（纯字符串匹配即可剔除本次全部幻觉），核对不过的命中直接作废并计入红队自身的失信记录。

四、处置

语义审计 insufficient → 按制度 IR 回炉：AC 需按"运行时证据"方向补强后重打 state:redteam。
意图兜底：无有效命中，无需 owner 裁决项。

红队 Dogfood 报告 v2（llm-as-a-Verifier 范式）— IR #263

手动红队第二轮，严格采用 LLM-as-a-Verifier 范式：criteria 分解 + logprob 分布期望的细粒度连续分 + K=4 重复评估 + Probabilistic Pivot Tournament（pivots=2）best-of-N。
角色分工：红队（候选生成）= LongCat-2.0；Verifier = qwen3.8-max（aliyun 兼容端点，配置中唯一通过 logprobs 校验的 endpoint）；harness/机械核证据 = kimi code。
框架：llm-verifier 0.2.0（隔离 venv，打 aliyun 兼容补丁三处）。
已知成本：候选生成 126,909 tokens（A 组 42,248 / B 组 84,661）；verifier 成本未能回溯（见元结论 5）。

一、Verifier 锦标赛结果（连续分，非散文）

A 组·语义审计（5 候选，criteria=证据真实/可利用性/修补可执行）：

候选	连续分	排名
cand-A-3（主攻 S3 no-op 桩）	0.5319	1
cand-A-1（主攻 S1 硬编码）	0.5167	2
cand-A-5（主攻 S5 错误路径）	0.4906	3
cand-A-4（主攻 S4 缓存）	0.4853	4
cand-A-2（主攻 S2 特例短路）	0.4514	5

B 组·意图兜底（4 候选，criteria=证据真实/维度守纪/判定克制）：

候选	连续分	排名
cand-B-1（主攻 S6 重复）	0.5828	1
cand-B-3（主攻 S8 越界）	0.5519	2
cand-B-4（全维度均衡）	0.4174	3
cand-B-2（主攻 S7 违反治理）	0.4143	4

二、机械核证据（harness 对 winner 逐条字符串匹配 IR 原文）

A winner（cand-A-3）：10 条攻击中 7 条有效、3 条幻影。

有效：对真实 AC1（Verify 制度化）、AC2（阈值成 gate）、AC3（沙箱形态）、AC4（Veto 强制力）、AC8（S6–S8 道闸）、AC9（双 check 独立）、AC10（状态机/防篡改）的 no-op 摆拍攻击，全部成立且修补建议可执行。
幻影（作废）：其"AC5 规划/开发 agent 测试与 holdout 强制检查""AC6 规划 APP 专用 CODEOWNER""AC7 红队 run 为唯一证据并停止规划 agent"——IR 原文均不存在，系 LongCat 系统性幻觉（与 v1 的幻影主题完全一致）。

B winner（cand-B-1）：主结论成立，2 处幻影引用作废。

有效：S6 无命中的论证（承接 ADR-0061/0067/0072 属"已决策未实现"，非重复；意图道闸是全新维度）经核对成立。
幻影（作废）："6. holdout 测试检查→细化 ADR-0056"（IR 无 holdout 要求）与结尾"IR 要求新设规划 agent 专用 APP（job 第 6 点）与 AG-1 张力"（IR 的 job 只有 5 点，无此内容）——两处引用均系捏造，基于其上的 S7 警示随之作废。

三、Verdict

语义审计：insufficient（Veto）。两轮独立运行（v1 散文判定 / v2 verifier 锦标赛）结论一致：IR 的 AC 患"声明式合规"病，多数可被"yaml 写字 + CI echo success"的 no-op 桩摆拍。回炉方向不变：每条 AC 升级为运行时证据（verifier 调用日志+原始 logprob 输出、反向触发测试、真实 403/exit 2 记录）。
意图兜底：无有效命中。S6 无命中成立；S7/S8 无有效证据。无 owner 裁决项。

四、范式层面的元结论（v2 新增，比单卡结论重要）

LLM verifier 排名 ≠ 证据有效。verifier 把"证据真实"放第一 criterion，选出的 winner 仍带 3 条幻影 AC——因为全部候选共享同一系统性幻觉，criterion 无可区分。pipeline 必须是双层：verifier 连续分做质量排名 + 机械引用核对做硬谓词，缺一不可。
单一弱模型生成候选，best-of-N 治不了系统性偏差。5 份 A 候选全部幻觉出"holdout/规划 APP"主题，锦标赛只能在同病候选里选"病最轻"的。候选生成需要跨模型多样性或"逐字引用 AC 原文"的强约束 prompt。
连续分聚集在 0.5 附近的两个成因：候选同病（criterion 拉不开）+ top_logprobs=5 截断（20 档分布只剩头部 5 档，期望估计变粗）。后者是 aliyun 端点的硬限制，换 DeepSeek/vLLM（top_logprobs=20）可解。
endpoint 校验要从一项扩成三项探测：logprobs 有无（LongCat ✗）→ top_logprobs 上限（aliyun=5）→ prefill/structured_outputs 支持（aliyun ✗，决定走"模型自输出 score tag"降级路径）。三探测结果决定抽取路径与精度预期，应在配置时写入报告。
verifier 成本必须随 run 持久化。框架有 token_usage() 但只在进程内；本次 select 两轮的真实 token 消耗无法回溯。pipeline 落地时每次 run 必须落盘 token 账（这正是 IR 要求的"CI 日志含 token 消耗"的第一次正面教训）。
降级路径打分精度冒烟验证通过：错误答案 1.07e-7 vs 正确答案 0.99999，20 档 logprob 期望打分在 aliyun 补丁后真实生效（精度有 top-5 截断折损，已在结论 3 注明）。

五、处置

IR IR: 卡绑定测试与红队守门制度（LLM-as-a-Verifier 验证 + 意图兜底道闸） #263 AC 回炉（同 v1 结论，现有两轮独立证据）：重点补强 AC1/2/3/4/5/7（真实条目编号）的运行时证据要求。
意图道闸：无需动作。
pipeline 设计输入：元结论 1/2/4/5 直接进入 build 阶段的需求（双层判定、候选多样性、三探测校验、token 账落盘）。

ERRATUM：撤回前两份红队报告中的"幻觉"指控（harness 判定错误）

本 erratum 针对上两条评论（v1 报告与 v2 报告）。结论先行：LongCat 红队没有产生引用型幻觉；是 harness（kimi code）的"机械核证据"核对错了基准——拿候选输出与自己记忆中的 strawman 草稿比对，而非与磁盘/线上的真实 IR 正文比对。所有"幻影 AC""捏造引用"的指控全部撤回。

一、事实

IR 正文在挂出前经 owner 编辑，新增了痛点第 8 条与期望变化第 5/6/7 条（规划 agent 测试落地+holdout 强制注册、新设规划 agent 专用 APP 及测试 CODEOWNER、红队 action run 唯一证据+挂了开 issue 停规划 agent），且新增条目与原有 5/6/7 编号重复（全节实为 13 条）。
v1 红队报告称"声称 10 条实际 13 条且编号重复"——正确，harness 误判为幻觉。
v1/v2 候选中所有涉及"holdout/规划 agent 专用 APP"的攻击与引用，均有 IR 原文对应，全部为有效引用。
v3.1 verifier 对真实 AC 块（含新增 5/6/7）打 1.0、对编号错配块（"AC8"实为第 5 条、合并多条的"AC10"）打低分——判定基本正确，harness 此前将其列为"误报"亦属错误。

二、因此恢复有效的意图兜底命中（v1 B 组，当时被错误作废）

S7 命中（有效）：期望变化第 6 条"新设立给规划 agent 专用的 APP"与 GOVERNANCE.yaml AG-1（agent 写仓库唯一身份 = App cloudbrid-agent）存在张力——需 owner 裁决：修订 AG-1、走既有例外通道、或改用既有 App 的权限分组实现。
S7 命中（有效）：期望变化第 5 条"测试必须全部经过红队审计，这是 PR 阻断项"将红队审计频率扩到每 PR，与 ADR-0067 的频率与成本预算决策存在张力——需 owner 确认修订范围或调整该条。
S7/S8 命中（有效）：期望变化第 5 条强制 holdout 测试注册到 holdout 仓且为合并阻断项，与 ADR-0056 DECISION-02 隔离不变量（App 不挂载 holdout 仓）存在张力——写入路径需要 owner 裁决（例如由谁的身份注册、CI 如何验证不可挂载之仓的内容）。
附带发现（有效）：期望变化节编号 5/6/7 重复，spec-author 落地前需重排。

三、仍然成立的结论

语义审计 verdict=insufficient（AC"声明式合规"病，需运行时证据化）不受影响，两轮独立证据仍然有效。
v3/v3.1 的机制结论成立：绝对 reward + 阈值 gate 可运行；aliyun 端点三探测（logprobs/top_logprobs 上限/prefill）必要；token 账须随 run 落盘。

四、修正后的元结论（替换前两份报告的第四节）

证据核对必须是由代码执行的、针对运行时刻真实工件的机械匹配，不能是裁判（人或 LLM）凭记忆比对。本次全部错误源于 harness 用"我记得的 strawman"当基准；pipeline 中该步骤必须读当时的 issue body / spec 文件原文做字符串级匹配，并把"核对所用的基准版本（SHA/抓取时间）"写进报告。
弱模型红队 + 强模型 verifier 的组合在本场景表现合格：LongCat 的引用全部真实，qwen 的局部判定基本准确。前两份报告对两者的能力评估（"引用型幻觉""排名≠证据有效"）基于错误基准，予以撤回。
意图兜底道闸的价值得到实跑证明：三条有效命中全部是 owner 编辑引入的意图层张力，正是道闸设计要抓的问题类型。
仍保留的警示：单模型候选生成可能存在系统性偏差（本次未观察到，但不构成反证）；候选多样性与机械核对仍应保留在 pipeline 中。

IR v3 修订说明（按红队有效反馈回炉）

正文已按两轮红队 dogfood 的有效反馈重写。变更明细：

一、按语义审计反馈（AC 声明式合规病）的修订

期望变化全部重写为 13 条，每条自带"运行时证据"子句——不再接受"声明/配置存在"作为验收依据：

AC1（Verify 制度化）→ 要求 CI 日志含 llm-verifier 实际调用 + 连续分 JSON + token 消耗
AC2（阈值 gate）→ 新增 golden set 标定 + 故意低分样本的反向触发测试
AC3（新增）→ 证据核对硬谓词代码化：运行时刻真实工件 + 基准版本入报告 + 捏造引用样本的作废实测（本卡 erratum 为反面教材）
AC4（新增）→ endpoint 三探测制度化（logprobs / top_logprobs 上限 / prefill 支持）
AC5（新增）→ token 成本随 run 落盘（修复 dogfood 的"成本无法回溯"事故）
AC6/7/8 → 沙箱/Veto/状态机条款全部改为要求真实执行证据（空壳 job、echo survived、人为导演 Veto 均不满足）
AC9（保留 owner 新增条款）→ 红队 run 唯一证据 + 挂了自动开 issue 停规划 agent，补"success 但产物为空同样按失败处理"
AC11（卡绑定测试）→ 补"缺测试 PR 被阻断的真实红记录""holdout hash 不匹配被阻断的红记录"

二、按意图兜底三条有效命中的修订

专用 APP vs AG-1 → NONGOAL 新增"不新设规划 agent 专用 APP"，测试写入保护改用既有 cloudbrid-agent 身份 + CODEOWNERS + 分支保护；确需独立身份则另起 ADR 修订 AG-1
每 PR 红队审计 vs ADR-0067 频率成本 → 频率回归 ADR-0067（spec + 波次收口）；每 PR 跑的是确定性测试而非 LLM 审计；NONGOAL 明示"红队审计不扩到每 PR"
holdout 强制 vs DECISION-02 隔离 → AC11 改为：注册走 owner/人类通道，机器只校验 PR 引用的 holdout hash 与已注册记录一致；NONGOAL 明示"不要求 App 写入 holdout 仓"

三、LLM-as-a-Verifier 立为组织默认 verifier 范式

job 第 1 条 + AC1/AC2 + 约束段"默认范式铁律"：凡 LLM 判定环节必须输出 llm-verifier 结构化连续分（绝对细粒度 reward + criteria 分解 + K 重复 + 阈值 gate）；散文结论、单次离散打分、锦标赛胜率均不得作为 gate 输入（PPT 仅选择层——dogfood v2 曾误用胜率当判定信号，已纠正）
红队 pipeline 从建立第一天起按此范式实现（job 第 2 条），不留"先散文后补框架"的过渡态

四、其他

期望变化编号重排为 1–13（修复上一版 5/6/7 编号重复——红队 v1 的有效发现）
约束新增"endpoint 精度折损必须声明""机械核对裁判凭记忆比对一律无效"
dogfood 三条意图命中作为道闸首批实跑记录存档（AC10）

状态：待 owner 签署（state:ir-signed）。签署前请重点裁决：NONGOAL 的三条合规化改法（专用 APP / 每 PR 审计 / holdout 注册通道）是否符合你的本意。

IR v4 修订说明（owner 三条裁决落实）

正文已按 owner 裁决重写。变更明细：

一、owner 裁决的三条（覆盖 v3 的合规化保守改法）

新设验证者 APP（AC12 新增）：验证者专用 GitHub App，与开发身份 cloudbrid-agent 分离；测试相关内容（suite/、holdout、卡测试）CODEOWNER = 验证者 APP + 人类。AG-1 以 ADR 修订为"开发身份唯一 + 验证者身份独立"（约束段：ADR 先行，不许先实施后补票）。
红队审计范围 = 意图→spec→测试设计路径每 PR（job 第 4 条 + AC8）：specs/** 路径全部 PR 必走红队审计且为合并阻断——测试设计错了，下游开发 gate 全部失效。开发实现路径 PR 不走红队，只跑确定性测试 + holdout 测试（NONGOAL 明示）。此为对 ADR-0067 频率决策的修订，随本 IR 以 ADR 落实。
holdout 强制，验证者 APP 可挂 holdout 仓（AC11）：holdout 注册由验证者 APP 执行，DECISION-02 对该身份的限制以 ADR 修订；机器校验 PR 引用的 holdout hash；开发 agent 不可改 holdout 内容（运行时证据含 403 记录）。

二、签署失败根因（供存档）

09:42 签署时 type:intent 与 state:ir-signed 同时操作导致前者被移除，T1 守卫（transitions.yaml:26：要求 type:intent in label_set）为假，conductor 按 AC-11 静默丢弃（回退标签、不评论、不启动），审计行 verdict=DENIED-silent-drop。系统按设计工作；教训：签署时两个标签必须同时在场。"静默丢弃无反馈"的 UX 缺陷建议后续改进（守卫拒绝时至少回贴一条原因评论）。

三、重新签署

v4 正文更新后重新打 type:intent + state:ir-signed 触发 T1 → spec-author。

spec-author 完成（BEH-01）：spec PR → #266
计量：model=glm-4.5-air tokens=7092 latency=34673ms
状态转移由 conductor 跟进（state:spec）。

spec(ISSUE-263): 条款级规格（auto，ISSUE-263 #263，ADR-0050） (#266)

红队报告：spec(ISSUE-263) — verdict: insufficient（Veto）

手动红队（pipeline 未建前的第三次 dogfood，对象是已合并的 specs/ISSUE-263/spec.md @ dc7ee31）。
角色：红队候选生成 = LongCat-2.0（5 份语义 + 3 份意图，共 151,035 tokens）；机械核对 = 代码（AC 编号存在性）；verifier = qwen3.8-max / llm-verifier 0.2.0（绝对 reward，K=4，θ=0.7）；终裁 = kimi code 对照 spec 原文逐条核。
gate 机判：5/5 A 候选过阈值且机械干净 → insufficient。注意 verifier 分数再次饱和（4×1.0000），本报告的 verdict 以逐条内容终裁为准，分数仅作存档——这再次证明 spec 自身 AC-8（golden set 标定）的必要性。

一、语义审计：有效命中（经终裁确认）

A. IR 保真度丢失（spec 把 IR 的"运行时证据"条款弄丢了）

T-15 / AR-10 / g060 整组掉落（cand-A-5 IR-12，有效）：IR 期望变化 12 要求 T-15（intent_backstop）、AR-10（red_team_veto）入册、g060 等价关卡落地治理仓；spec 全部 19 条 AC 无任何对应条款。这是漏项，不是细节。
AC-9 缺反向测试义务（cand-A-2，有效）：IR 要求"对含已知捏造引用的样本，作废记录全部命中"；spec AC-9 只要求"由代码执行"——verify_evidence() { return True; } 即满足字面。AC-2 同病。
AC-18 缺 403/exit 2 留档（cand-A-2 漏项 5，有效）：IR 明确要求"开发 APP 令牌改测试被拒的 403 日志 + exit 2 阻断日志"作为验收证据；spec AC-18 只有 CODEOWNER 配置描述。
AC-8 缺 golden set 独立性（cand-A-2，有效且刁钻）："低分样本"可由与判定脚本串通的桩构造——IR 未防、spec 未防；需补"不合格样本构造方法独立于判定脚本"。
AC-11 缺 usage 交叉核对（cand-A-2，有效）：写 {"tokens": 0} 即满足"持久化"字面；需与 LLM 响应 usage 字段交叉核对。
AC-12 缺无绕过转移测试（cand-A-5 IR-6，有效）：IR 要求"证明 needs-human 不可直跳 wave-planned 的自动化测试"；spec AC-12 未覆盖。
AC-14 缺开发路径 EXPECTED_SKIP 豁免机制（cand-A-5 IR-8，有效）：spec 只写"specs/** 必须含 adversary check"，豁免机制（DECISION-02 的机器实现）未落 AC。
其余细节丢失（次要，一并回炉）：AC-1 未点名 GOVERNANCE.yaml/testing.yaml；AC-8 缺阈值版本化与标定留档；AC-9 缺"核对不通过作废并记录"闭环；AC-15 缺有界重试≤2 次；AC-17 缺 holdout 注册主体（验证者 APP）与 hash 校验机制。

B. spec 文本阶段的攻击面需要重定义（cand-B-2 违反 3，部分有效）

ADR-0067 的 S1–S5 攻击面针对代码实现（硬编码/no-op 桩/忽略错误路径）；红队审计扩展到 spec/测试设计路径后，攻击面需面向文本工件重定义（本次 dogfood 实际使用的"AC 可摆拍性 + IR 保真度"即雏形）。随本 IR 修订 ADR-0067 时应把"spec 阶段攻击面"写进去，否则红队在 spec 阶段无判定依据。

二、意图兜底：有效命中

S8 命中（有效）：blastRadius 结构失真（cand-B-3 基础上终裁加深）：
- 声明的 repo 名不是真实仓：repo: governance、repo: adr、repo: main-protection 均为 .github 仓内目录/文件，不是仓；真实仓名应为 .github。
- 漏 automation-limits.yaml（cand-B-2 违反 6，有效）：AC-11 要求修改该文件（C1 政策文件），blastRadius 未含。
- 漏 CI-Workflows 仓（终裁补充）：adversary workflow、attack-strategies.yaml、llm-verifier 接入全部落在 CI-Workflows，blastRadius 完全未声明。
- template-service path: '**' 与 NONGOAL"不重建 template-service 全套 quality 体系"张力：应收窄为具体路径（如 .github/workflows/ci.yml、AGENTS.md）或注明由独立 IR 处理。
S7 部分有效：AG-1/IFACE-01 的时序（cand-B-2 违反 4/5）：修订 ADR 未出编号前不设新 App——IR 约束段已写"ADR 先行不许后补票"，但 spec 未把该时序写进 DECISION-01/IFACE-01，回炉时补一句即可。

已驳回的命中（终裁判定不成立）

"AC-12 引用不存在的 T5/T6 违反 GM-1"——驳回：本 IR 的交付物就是创建 T5/T6，spec 引用待建资产属正常。
"AC-14 状态写权令牌越权/无权双杀"——驳回：conductor 现有 App 令牌机制（INV-02）已覆盖状态标签写，spec 无需重复声明。

三、处置建议（回炉清单）

spec 修订（建议由 spec-author 走一轮修订 PR，diff 可机器核对覆盖性）：

补 T-15/AR-10/g060 对应 AC（IR 期望变化 12 的完整映射）。
19 条 AC 逐条对齐 IR 的"运行时证据"子句：反向测试（捏造引用样本、极差 spec、故意低分）、403/exit 2 留档、usage 交叉核对、无绕过转移断言、EXPECTED_SKIP 豁免、有界重试。
blastRadius 重写：repo 名用真实仓（.github / CI-Workflows / template-service），补 automation-limits.yaml 与 CI-Workflows，收窄 template-service 路径。
DECISION-01/IFACE-01 补时序：AG-1/DECISION-02 修订 ADR 合并前，验证者 APP 不得实施。
ADR-0067 修订案中补"spec 阶段攻击面"定义。

四、本次 run 元数据

机械核对：5/5 A 候选引用 AC 编号全部真实（无幻影）——LongCat 三轮 dogfood 均未再出现引用型幻觉
verifier 分数（存档）：A 组 0.9515–1.0000（饱和）；B 组 0.8365–1.0000
成本：候选生成 151,035 tokens；verifier 成本未落盘（又一次印证 AC-11 的必要性）

spec(ISSUE-263): rev3 红队 R2/R3 回炉（#263 CNB 轮报告）——S5 负向守卫（缺 check 必须红/…

红队报告 R3：spec rev2 — verdict: insufficient（CNB 轮，已回炉为 rev3）

红队管线首次 CNB 实跑：候选生成 = CNB CodeBuddy NPC（8 窗口并行，全部回复，质量显著高于 LongCat 轮）；机械核对 = 代码（AC 编号存在性，8/8 干净无幻影）；verifier = qwen3.8-max / llm-verifier（绝对 reward，K=4，θ=0.7，分数仍饱和存档）；终裁 = kimi code 对照 rev2 原文逐条核。
本轮处置：有效命中已全部落进 spec rev3（PR #267，specVersion: 3）。

一、有效命中与 rev3 对应修订（26 处）

S5 错误路径缺失（cand-A-4 主攻，本轮最有价值维度）

AC-4：spec 路径 PR 缺 adversary check（漏配/摘除/跳过）→ CI 必须红【rev3 AC-4 负向断言+红记录】
AC-2/AC-9：引用被作废后 verdict 不受影响 → 作废强制转 insufficient【rev3 AC-2】；基准获取失败判不通过【AC-9】；工件快照随报告归档防"验过即焚"【AC-9】
AC-15：no-attempts/空报告后卡的状态后果 → 锁定 needs-human、不得进 wave-planned【rev3 AC-15】
AC-19：死条款（写入但无消费方）→ 判失败【rev3 AC-19】
AC-11：偏差超阈值仅告警 → run 作废转人工【rev3 AC-11】
AC-17：缺 suite/ 无显式阻断 → 负向断言+红记录【rev3 AC-17】
AC-20：只证 happy path → Veto 理由与修复 diff 闭环核对 + 每卡独立不作资历【rev3 AC-20】

S3 no-op / 一次性验收（cand-A-2）
8. 反摆拍证据多为"一次真实 run/一次抽查"→ 新增 INV-04：golden 回归、无绕过断言、机械核对、配置面校验逐 run 常驻 CI【rev3 INV-04 + AC-2/AC-8】
9. AC-5/AC-16 道闸"只报人不阻断"可被空转桩恒绿 → 每卡实跑留痕（无命中也落盘，区别于未运行）【rev3 AC-5/AC-16】

S2/S4 短路与放行（cand-A-3）
10. AC-12：repository_dispatch 宽松匹配可伪造旁路 → event_type 白名单精确匹配 + 前置条件 conductor 侧重新断言（不信载荷）【rev3 AC-12】
11. AC-15：重试计数落在可写状态可无限重试 → 以不可篡改 run ID 序列为准【rev3 AC-15】
12. AC-8：golden set 一次标定后永久绿 → 每次 run 全量重放+回归断言+非 golden 随机样本反特判【rev3 AC-8】

IR 保真度（cand-A-5，质量最高的一份）
13. M-1 PPT 仅选择层未落 AC → AC-1 负向断言"胜率不得入 gate"
14. M-2 AG-1 ADR 先行时序闸未落 AC → AC-18 + DECISION-01（含 ADR-0061 验证者 APP 豁免通道同步修订）
15. M-4 精度折损声明未落 AC → AC-10
16. M-5 降 K/pivots 不动阈值/语义 → AC-11
17. R-1 T5"suite 就绪"前置谓词未定义 → AC-12 确定性谓词（存在+非空+可解析）
18. R-2 required/豁免互补未锁定 → AC-14 豁免谓词确定性派生（禁人工打标）+ 伪装豁免反向红记录
19. R-3 owner 裁决闭环截断 → AC-18 补 TTL + dead-man

意图兜底（B 组）
20. B-3 S8 硬命中 ×2：specs/** 与 CI-Workflows/pipeline/** 未在 REPOS.yaml key_paths 申报（GM-4 drift）→ AC-19 补申报 + blastRadius 补 REPOS.yaml 与 org-required-workflows.json
21. B-2 S7 命中：验证者 APP 写 suite 的豁免通道在 ADR-0061 中未定义（"只人类可解"）→ DECISION-01 把 ADR-0061 修订纳入 ADR 批次
22. B-2 提示：AG-1 修订目标文本未落 spec → DECISION-01 补目标文本全句

S1 元攻击的处置（cand-A-1）：二阶摆拍（伪造运行时证据本身）成立但属无限回溯——rev3 新增 DECISION-05：证据链终止于"独立采集 + usage 交叉核对 + 人类签收抽检"三层，不做无限回溯。

二、驳回的命中

B-1 全部 S6 命中（AC-14/AC-3/AC-2 重复 ADR-0067/0061/0054）：前提错误——那些 ADR 是"已决策未实现"，本 spec 是承接落地而非重复在跑机制。有效内核（spec 引注 ADR 防双源）已吸收进 AC-18/AC-14。
B-2 命中 2（EXPECTED_SKIP vs ADR-0032 硬冲突）：误读——EXPECTED_SKIP 本就是 ADR-0032 的登记豁免制实现模式，rev3 AC-14 已注明一致性。
B-2 命中 3（AC-15 与 ASSUMPTION-02 互斥）：措辞已统一（no-attempts=infra 失败=锁 needs-human+开 issue），非互斥。
AC-5 裁决 SLA、AC-18 双因素审批：与道闸不阻断设计冲突/过度工程，驳回。

三、run 元数据

CNB 窗口：82/35/34/93/94/70/68/51（8/8 回复，1–3 分钟/个）；冒烟 + 10 路并发探测 10/10（0–20s）——CNB 通道今日 19 次 NPC 执行零失败
verifier 分数（存档）：A 组全 1.0000（饱和）；B 组 0.8468–1.0000
CNB 通道已知约束：评论不可删（API 404）、窗口池多用户共享（抢占需容忍他人在用）

红队报告 R4：spec rev3 — verdict: insufficient（CNB 第二轮，已回炉为 rev4 + 待落 rev5 批）

管线同 R3（CNB NPC 8 窗口候选 + 机械核对 + llm-verifier 绝对 reward + 人工终裁）。机械核对 8/8 干净（无幻影引用）；verifier 分数存档（仍趋饱和，verdict 以终裁为准）。
处置：主体命中已落 rev4（PR #267，specVersion: 4）；另有 5 处承接/结构修订待随 R5 结果一并落 rev5。

一、已落 rev4 的修订（R4 有效命中）

正向上报回路补齐（cand-A-5 LEAK-3，本轮最有价值命中）：实现 agent 发现验收测试/AC 语义有误时，经结构化上报 issue（引用 test/AC 编号）路由 owner，TTL 内裁决、裁决前暂停该卡合并——"发现错误的合法通道"与"防篡改阻断"互补【AC-18】。这是 IR 原始意图第 5 条在 spec 层的真正落地。
T5/T6 未列入入册（cand-B-2 S7-2，强命中）：transitions.yaml 无 T5/T6 且 AC-19 未登记 → 运行期必 no-op【AC-19 补 T5/T6 登记 + guard 含 survived 记录】。
意图道闸"无命中"被误挂失败语义（cand-A-5 DISTORT-1）：rev3 把"无产出"与"无命中"混同——无命中=正常留痕，只有白卷才走失败分支【AC-5】。
锁卡语义收窄（DISTORT-4）：锁 needs-human 仅 no-attempts/空报告；普通 run 失败只重试+开 issue 不锁卡【AC-15】。
道闸跳过留痕（A-3 漏项 4）：LLM 不可用跳过时显式留痕，与未运行可区分【AC-16】。
时序判红：AG-1 修订 ADR 合并前出现验证者 APP 实施证据即判红【AC-18】；holdout 条款同受 ADR-0056 修订时序约束【AC-17】。
规划 agent holdout 义务补回（LEAK-1）：开卡时规划 agent 必须设计并登记 holdout，缺失即阻断【AC-17】。
S8 正向证据（LEAK-2）：一次真实 S8 集合比对命中落盘记录【AC-16】；S8 结果不一致 → 判定作废（blocking）【AC-16】。
人类签收抽检落 AC（LEAK-5）：DECISION-05 第三层有了载体【AC-20】。
杂项：混合 PR 豁免限定"实质 spec 变更"【AC-14】；erratum 事件纳入 golden 样本构造来源【AC-9】；第三 App 负向断言 + llm-verifier 钉点 + org-required-workflows SHA 钉点 + drift-check §18 同步【AC-19】；模型接入注明 ADR-0048 直连现状【AC-6】；nonGoals"第三个 App"措辞矛盾修正。

二、待落 rev5 的修订（R4 尾批，随 R5 一并落）

fail-closed 总原则（cand-A-4 S5 系统主题）：判定工具链任何环节异常（LLM 不可用、核对脚本崩溃、golden 加载失败、配置面枚举失败、无 verdict）一律判红/转 needs-human，不存在"未定义默认绿"分支 → INV-04 扩写。
ADR-0072 承接引用（cand-B-1 S6-1 的有效内核）：llm-verifier 范式与 ADR-0072 引用同一外部范式，spec 应显式声明承接/泛化关系（非重复在跑机制——ADR-0072 是 verifier 入职考试，判定对象不同），引注入 AC-1/INV-01。
AC-11 挂接 ADR-0062：token 持久化复用既有 metering wrapper 与 llm_tokens 预算口径，spec 只新增 usage 交叉核对约束，不重述已有机制。
AC-17 复用 ADR-0068：holdout hash 校验/揭封机制承接 ADR-0068，spec 仅新增验证者 APP 身份面。
blastRadius 补 holdout 仓（cand-B-3 命中一）：AC-17/AC-18 要求对 holdout 仓实施（注册/校验/跨仓 403），blastRadius 未申报该仓。

三、驳回项（选录）

B-1 的 S6-1/S6-2"重复在跑机制"定性：前提过宽——ADR-0072 是 verifier 入职考试（判定对象是 verifier 本身），ADR-0062 是计量基建，本 spec 是承接/消费方而非重复；但其"显式引注避免双源"的建议已吸收（见 rev5 批 2/3/4）。
B-2 S7-3（直连 LLM 违反 ADR-0002 Gateway）：ADR-0048 已明确 phase1 直连 provider，驳回；引注已补。
B-3 命中三（main-protection.json 过度声明）：保留——红队 check 的 required 化是否落在仓级 ruleset 取决于实施形态（org-required-workflows 集中钉点 vs 仓级），列为实施期确认项，不构成失实。
A-1/A-2 的凭据内嵌 variable、采集组件进程隔离边界等：属实现层细节或二阶回溯，DECISION-05 覆盖。

四、run 元数据

CNB 窗口 8/8 回复（70/37/57/69/84/3/50/52）；CNB 通道累计 27 次 NPC 执行零失败
本轮 CNB 候选质量评估：B-3 明确指出其无法访问线上仓（token 仅见 talk 仓），路径真实性判定基于随附治理上下文——方法诚实，结论可用

红队报告 R5：spec rev4 — verdict: insufficient（已回炉为 rev5），并建议宣布循环收敛

管线同 R3/R4（CNB NPC 8 窗口，7/8 有效回复——cand-B-2 交白卷 135 字符，按 no-attempts 处理并记录，其余 7 份质量在线）。机械核对 8/8 无幻影。终裁 = kimi code 对照 rev4 原文。
处置：全部有效命中已落 rev5（PR #267，specVersion: 5）。

一、R5 有效命中与 rev5 修订

IR 保真度（cand-A-5）

AC-20 缺"Veto 真实发生"硬谓词 → 运行时证据须含一条真实 verdict=insufficient 阻断记录，无 Veto 的全程不算
criteria 从卡 AC 派生的溯源链丢失（IR 有、spec 无）→ AC-1 补"一卡一文件且机器可追溯到对应卡 AC 列表"
AC-19 钉点缺运行时证据 → 补 lock diff + SHA 变更记录
AC-5 把意图道闸白卷挂进 AC-15 失败分支（违反"道闸输出永不阻断"）→ 白卷仅留痕+报人；AC-15 失败分支仅红队 run

S8 blastRadius（cand-B-3，两条阻断级）
5. archive/adr/** 与 archive 的 append-only 性质冲突，且 ADR 真源是 agent-registry/decisions/（ADR-0053）→ blastRadius 改申报 agent-registry/decisions/** 为修订/新增真源，archive 仅归档追加
6. holdout 仓漏报（AC-17/AC-18 明确要求对其写入与跨仓拒写取证）→ blastRadius 补 holdout: entries/**

S2/S4（cand-A-3，全部采纳为硬化）
7. golden 样本身份短路 → 盲化注入（剥来源元数据同批混排）；criteria 每次变更须重新标定（SHA 强一致）
8. T6 前置"存在 survived 记录"可被跨卡记录短路 → 卡 ID+specVersion+审计 run ID 三元组
9. 白卷填坑报告绕过锁卡 → 白卷判定锚定结构（缺逐 criterion 连续分/核对记录即白卷）
10. 凭据口径只数 org 层 → 全来源（org+repo+env+硬编码）唯一 + env 凭据形状扫描
11. 快照只归档不重放 → 保留 TTL + 定期重放 job
12. fail-before 仅首次 → 逐变更常驻

S5 fail-open（cand-A-4 主题，R4 尾批并入）
13. 判定工具链异常分支默认绿 → INV-04 扩 fail-closed 总原则：任何环节异常一律判红/转 needs-human，无"未定义默认绿"

承接引用（cand-B-1/B-2 有效内核，R4 尾批并入）
14. ADR-0072（同外部范式泛化承接）入 AC-1；AC-11 挂接 ADR-0062 metering 与既有 llm_tokens 口径；AC-17 复用 ADR-0068 揭封 hash 校验；g060 注明引用 ADR-0061 非新设

二、驳回项

cand-B-1 全部 S6 命中（AC 重复 INV/BEH）：spec 的 AC 是 INV/BEH 的可执行化载体，层内重述不构成"重复建设"；其"g060 引用而非新实现"内核已吸收。
cand-A-5 曲解 3（"死条款判失败"自创）：有 IR 出处（期望变化 12"执行层恒绿不算"），驳回。
cand-B-2 白卷：135 字符无实质内容，按 no-attempts 记录（本轮唯一的 infra 噪声，不影响判定）。
main-protection.json 存疑项：保留于 blastRadius，实施期按 check 接入形态（org-required-workflows 集中钉点 vs 仓级 ruleset）确认。

三、收敛声明（建议）

五轮红队的边际发现轨迹：R1 结构性缺陷（条款整组缺失）→ R2/R3 负向守卫缺失 → R4/R5 措辞级硬化与承接引用。R5 已无任何"不修就会被摆拍击穿"的新结构性缝隙；剩余可攻击面为二阶回溯（证据的证据），已由 DECISION-05 封顶。建议以 rev5 定稿合并，后续严格性由实施期的机器断言（INV-04 常驻 CI）承接，而不是继续堆 spec 文本。

四、run 元数据

CNB 通道累计 35 次 NPC 执行，34 成功 1 白卷；窗口管理零冲突
五轮 dogfood 总成本：CNB 侧 0（免费池）；自有 API 侧 verifier 调用约 200 次（qwen3.8-max）

spec(ISSUE-263): rev2 红队回炉修订（#263 红队报告 insufficient） (#267)

波次规划落地：W1–W5 共 21 张工作卡已开出（#268–#288）

spec rev5 已合并（PR #267）。按 spec 的 blastRadius 与 AC 映射拆为 5 波 21 卡，全部带 type:card 标签与卡元数据（父意图/Spec 版本/依赖/AC/blastRadius）：

波次	卡	内容
W1 治理前置（ADR 批次）	#268–#272	AG-1 修订、ADR-0056 DECISION-02 修订+drift-check §18、ADR-0061 验证者 APP 通道、ADR-0067 spec 阶段攻击面、条款入册（T5/T6、T-14/T-15、AR-10、REPOS 补登、钉点 SHA）
W2 验证者 APP 与测试防线	#273–#276	验证者 APP 创建安装（时序闸）、g060 治理仓落地、T-14 机器化、holdout 注册/校验+正向上报回路
W3 红队 pipeline	#277–#281	adversary workflow、attack-strategies.yaml、llm-verifier 接入、CNB dispatch 通道+canary+fallback、机械核对脚本
W4 状态机与守门接线	#282–#285	conductor T5/T6 路由、dispatch 白名单+check 写回、required checks 接入、意图道闸落地
W5 端到端与收口	#286–#288	golden set 标定、真实卡 E2E（含一次真实 Veto）、红队守门 ADR 收口

依赖关系已写入各卡头部（W2 全部依赖 W1 的 ADR 批次——时序铁律：ADR 合并前验证者 APP 不得实施）。

状态说明：本卡（IR #263）当前停于 state:spec。spec 已合并、红队五轮已实跑（survived after rev5）、波次已规划——实际状态等价于 wave-planned，但 T5/T6 转移尚不存在（正是 #272/#282 的交付物），conductor 目前无路可走。请 owner 决定：手动打 state:wave-planned 标签闭环，或等 W4 落地后按机器流程走。

dogfood 全链存档：IR 签署（含一次守卫拒绝教训）→ spec-author 自动产 spec → 五轮红队（R1 结构缺陷 → R5 收敛）→ rev1–rev5 回炉 → 合并 → 波次开卡，全部证据在本 issue 评论链。

独立验证 + 端到端修复实录（2026-08-24）

一、独立验证结论（修复前）

W1-W5 未全部真实完成：18/21 卡关闭但 3 张零评论未验收（#275/#278/#281）；Veto 无线上强制力（ruleset 落盘带非法 integration_id:0，apply 恒 422）；required workflow 钉点指向不存在文件；expected_skip/writeback 接口漂移 12 断言红且未接 CI；e2e 仅本地模拟；治理 CI 多处 INFRA。

二、修复清单（全部已合入 main）

修复	载体
expected_skip/check_run_writeback 接口统一 + 三套自测入 CI	CI-Workflows #91
e2e 靶场 + kimi k2.7 接入（参数兼容/超时旋钮/16k 预算）	CI-Workflows #92
adversary-gate：merge_group 支持 + 去 App 令牌单点	CI-Workflows #94 + #336
ADR-0083（T-14 第一面/ruleset 修正/drift fail-closed）双仓登记	agent-registry #95 + archive #15
llm-connectivity 接 kimi（KEY1）+ allowlist 折叠假绿修复	CI-Workflows #93
T-14 门 + ISSUE-263 自有 suite + ruleset/drift/cost/g060 修复 + 中继 workflow	.github #336/#339/#341/#342
线上：main-protection 加 adversary、required workflows 重钉、merge_queue 摘除（与 required checks 结构性冲突）、GOVERNANCE_TOKEN 值+visibility=all	org API

三、运行时证据（#263 验收要求的真实链）

真实 Veto：run 32680426207——kimi 真调用，弱套件（占位断言）5 攻击（S1'-S5'）全得手 → verdict=insufficient，exit 1（CI 红）
真实 survived + check run 写回：run 32683661862 → check run #97306729778 success 挂 PR#92 head
红队套件军备实录（三轮加固均有 run 记录）：①逐表硬编码（S3' 得手）→ 多表参数化；②复用测试内 reference（S1' 得手）→ 源级硬谓词；③运行时随机税表（S3' 再得手）→ 语义反硬编码——最终 5 攻全败
required check 合并闭环：PR [自动合并 P2-7] merge queue 接入 #92 在 main-protection 含 adversary required check 下合并（8f69aa3）
跨仓中继：feat(governance): T-14 机器化第一面 + 红队 required check 落地修正（W2-C3 .github#275，ADR-0083） #336 审计（run 32686938796 survived，字节完整性套件）→ 机械核证中继 → check run 挂 .github PR#336 head → 合并（5dbc0aa）
治理 CI：cost-check 绿（32688936502 后续验证 success）；butler-ledger 绿；governance-drift 恢复真实检测（残留 §10 旧 PR 实体性误判 → drift §10 残留：AI_Web_School/template-service 旧 PR 的 ADR 实体性恒判 unreadable（双通道本地均通） #343）

四、遗留（已立单）

drift §10 残留：AI_Web_School/template-service 旧 PR 的 ADR 实体性恒判 unreadable（双通道本地均通） #343：drift §10 旧 PR ADR 实体性恒 unreadable（双通道本地通，需 per-number 诊断）
T-14 第二面（fail-before/卡测试解析/holdout hash）按 ADR-0083 后续波次
harden-runner egress block 在本 org 拦 git fetch（audit 模式过渡，见 adversary.yml 偏离记录）
AGENT_APP_SECRET 疑似轮换未同步（spec-author 铸令牌连红三日）——需 owner 在 App 设置页重下私钥并更新 secret

系统清洁巡检状态（2026-08-25）

IR 实质工作已全部交付：全部子卡（W1–W5 波次，#218–#288 系）早已 state:done 并关闭；卡绑定测试（g060 锁定 specs suite）、红队守门（ADR-0082）、llm-verifier、意图道闸均在当前流水线实际运转（近期 spec PR 均走 adversary-gate/org-gate）。

未关单原因（fail-closed）：T9 机械谓词缺一——specs/ISSUE-263/acceptance.md 尚不存在。需按验收流程产出验收报告（逐 AC 证据）后方可置 done 关单。建议 owner 安排一次验收 run（或授权 PM 会话起草验收报告走 C1 PR）。

IR: 卡绑定测试与红队守门制度（LLM-as-a-Verifier 验证 + 意图兜底道闸） #263

Description

job（要完成的待办）

触发场景

当前痛点的证据

期望的可观察变化（验收时能在线上看到的事实）

非目标（NONGOAL）

约束 / 不可违反项

人类愿意接受的验收证据

可逆性偏好

质量-速度旋钮

Activity

randypanding commented on Aug 22, 2026

红队 Dogfood 报告 — IR #263

一、语义审计（spec vs AC 可验证性，ADR-0067 S1–S5 适配）

二、意图兜底道闸（S6–S8）

三、Dogfood 元结论（比单卡结果更重要）

四、处置

randypanding commented on Aug 22, 2026

红队 Dogfood 报告 v2（llm-as-a-Verifier 范式）— IR #263

一、Verifier 锦标赛结果（连续分，非散文）

二、机械核证据（harness 对 winner 逐条字符串匹配 IR 原文）

三、Verdict

四、范式层面的元结论（v2 新增，比单卡结论重要）

五、处置

randypanding commented on Aug 22, 2026

ERRATUM：撤回前两份红队报告中的"幻觉"指控（harness 判定错误）

一、事实

二、因此恢复有效的意图兜底命中（v1 B 组，当时被错误作废）

三、仍然成立的结论

四、修正后的元结论（替换前两份报告的第四节）

randypanding commented on Aug 22, 2026

IR v3 修订说明（按红队有效反馈回炉）

一、按语义审计反馈（AC 声明式合规病）的修订

二、按意图兜底三条有效命中的修订

三、LLM-as-a-Verifier 立为组织默认 verifier 范式

四、其他

randypanding commented on Aug 22, 2026

IR v4 修订说明（owner 三条裁决落实）

一、owner 裁决的三条（覆盖 v3 的合规化保守改法）

二、签署失败根因（供存档）

三、重新签署

cloudbrid-agent commented on Aug 22, 2026

randypanding commented on Aug 22, 2026

红队报告：spec(ISSUE-263) — verdict: insufficient（Veto）

一、语义审计：有效命中（经终裁确认）

A. IR 保真度丢失（spec 把 IR 的"运行时证据"条款弄丢了）

B. spec 文本阶段的攻击面需要重定义（cand-B-2 违反 3，部分有效）

二、意图兜底：有效命中

已驳回的命中（终裁判定不成立）

三、处置建议（回炉清单）

四、本次 run 元数据

randypanding commented on Aug 22, 2026

红队报告 R3：spec rev2 — verdict: insufficient（CNB 轮，已回炉为 rev3）

一、有效命中与 rev3 对应修订（26 处）

二、驳回的命中

三、run 元数据

randypanding commented on Aug 22, 2026

红队报告 R4：spec rev3 — verdict: insufficient（CNB 第二轮，已回炉为 rev4 + 待落 rev5 批）

一、已落 rev4 的修订（R4 有效命中）

二、待落 rev5 的修订（R4 尾批，随 R5 一并落）

三、驳回项（选录）

四、run 元数据

randypanding commented on Aug 22, 2026

红队报告 R5：spec rev4 — verdict: insufficient（已回炉为 rev5），并建议宣布循环收敛

一、R5 有效命中与 rev5 修订

二、驳回项

三、收敛声明（建议）

四、run 元数据

randypanding commented on Aug 22, 2026

波次规划落地：W1–W5 共 21 张工作卡已开出（#268–#288）

randypanding commented on Aug 24, 2026

独立验证 + 端到端修复实录（2026-08-24）

一、独立验证结论（修复前）

二、修复清单（全部已合入 main）

三、运行时证据（#263 验收要求的真实链）

四、遗留（已立单）

randypanding commented on Aug 25, 2026

系统清洁巡检状态（2026-08-25）

Metadata