audit: independent audit role, auto-pushback, rebuild branch, three tightenings, QA full-chain

Independent audit (no code, independent re-run, separate signature;
CONDITIONAL never passes; deviation needs due todo) and automatic
pushback (fail -> derived fix subtask, merge/release blocked,
package with per-item evidence, full re-audit, 3-round limit with
a separate CI auto-fix counter, ledger hash-chain interface for
track 4, gate-block interface for track 1). Over 3 failures per
module per contract version: rebuild only that module from the
frozen contract (old implementation archived, avoidance list),
contract/design root cause -> G2 re-freeze escalation instead.
Tightenings: 3rd-failure triage (structural early rebuild /
early refreeze, near-complete one targeted round), rebuild keeps
tests and passed assets with an old-test first gate, audit-of-
audit sampling/correction and G6 user-only acceptance plus
acceptance-rebuild user confirmation. QA full chain: self-test
three parts, PRD coverage, agent six, cross-client matrix with
honest uncompiled verdicts, G5 gates, impact-scoped regression,
dual QA/audit signatures, failed-link re-runs in re-audit.
Skill text is purely additive (+459/-0) against main v0.2 text;
port this section into v0.3/v0.4/v0.5 texts on merge, never
overwrite them with this file.

cloud/skills/software-engineering/CHANGELOG.md

@@ -65,3 +65,21 @@ v0.1 → v0.2 的 5 个 P0 缺口明细无法从本文件追溯，本文件不
   01/02/03/05/06/09 章后有 `---`。
 - 校验脚本与两份附录测试的 EXPECTED_IDS 同步扩为 11 章；#214 的
   “仅复制 SKILL.md”结论不受影响（播种行为未改）。
+
+## #244 审计段落向 v0.5 的移植（集成时做，移植准备轨 #258 的 §1–§3 为准）
+
+- A 矩阵行：插入 QA 行之后、验收行之前（v0.5 矩阵行本身不动）。
+- B 主节：插在“失败、续跑与成本”节末、“诚实边界”节首之前；
+  引言移植警告按 R1 改写为移植注；“与已有回路的关系”按 v0.5
+  实际回路对齐（G7、全自动在本文件已有定义，注意句相应改写，
+  全自动下执行人字段口径见集成摘要：full-auto-executor +
+  installation id，签字人与执行人仍须不同）；B2、B3 全并，
+  唯收紧三末段“验收失败导致的推倒要先通知用户”整段停下
+  （全自动四类回头问用户未含此情形，须用户拍板 (a)/(b)，移植轨
+  不擅自选）；B4 QA 全链路整段停下（跨端版与 v0.5 跨视口口径正面
+  冲突，须视口版重写后再移植）；C 只插审计项，QA 项随 B4 停下。
+- D 附录章：落为 11-auditor（v0.5 已有 09-ops / 10-iteration，
+  编号顺延），标题用严格格式，源文件为
+  `templates/roles/11-auditor.md`（正文与 #258 的 09-auditor 同源）；
+  校验表同步扩为 12 章。§4 的 templates/artifacts 删引用决策
+  未在集成基底执行（仍待用户拍板），SKILL.md 内 6 处引用原样保留。

cloud/skills/software-engineering/SKILL.md

@@ -357,6 +357,7 @@ G0 的六问缺一问，G0 就不算过。用户没回复时，协调员等，
 | 共享核心 | 1 | `packages/shared/`（G3） | 共享类型、SDK、mock 服务、契约测试 |
 | 客户端开发 | 每客户端 1 | `apps/web`、`apps/macos`、`apps/windows`、`apps/ios`、`apps/android` 之一 | 该客户端可运行产物 + 自测证据；v0.5 默认只开 web，iOS / Android 原生后置占位，不在 MVP 内 |
 | QA / 测试 | 1（跨视口 E2E 可再分 1 个） | `tests/` | 测试用例、跨端一致性矩阵（v0.5 行是跨视口）、缺陷清单 |
+| 独立审计 | 1，与 QA、协调员、执行人分开 | 只写审计记录与推回包，不写业务代码 | 独立重跑证据 + 单独签字的审计结论（见“独立审计与自动推回”） |
 | 验收 / 发布 | 协调员兼任，用户拍板 | `docs/release/` | 验收清单结果、web 单端发布说明、已知问题清单 |
 | 运维 | 1（G7） | `docs/ops/` | 运维手册、问题清单、热修复记录、回滚触发结论 |
 | 迭代 | 1（G8） | `docs/` | v1.1 交接清单终版、下一轮 G0-G6 输入冻结清单 |
@@ -626,6 +627,311 @@ tests/                 # QA 线程专属，含跨端一致性用例
   较经济的模型，具体以项目实际可用模型和配额为准；
   配额将满时先停新线程，不先透支再解释。
 
+## 独立审计与自动推回
+
+本节是审计加固第 3 步的技能机制，与代码 `cloud/audit_pushback.py`
+（推回决策纯函数）双轨落地，只写文档不算落地。只补审计机制，
+不改上面已有规则的语义：G5 缺陷回路、合并拆分、G6 用户验收
+的原意都不变。移植注：本节源自审计加固轨，移植时已按本文件对应章节的回路口径对齐。
+
+### 独立审计角色：不写代码，只独立重跑、抽查证据、单独签字
+
+- 审计线程不写业务代码、不改待办、不给合并决定、不执行合并。
+  它只做三件事：独立重跑测试（不只复读 QA 报告）、抽查证据、
+  出一份单独签字的审计结论。谁写、谁测、谁审、谁执行、谁签字
+  五职分开：写是开发线程，测是 QA 线程，审是审计线程，
+  执行合并/发布是人或宿主操作，签字是审计签字人。
+- 同一人不兼两职，可核查：审计记录的签字人字段必须与任务执行人
+  字段、协调员批准人字段、QA 测试人字段都不同，有一项相同，
+  审计结论本身无效，按审计 fail 处理。代码里这就是
+  `validate_signer_separation`，缺字段也按无效处理，不补猜。
+- 安全签字只有两种结果：无条件通过，或拦住。CONDITIONAL 通过
+  不算通过，仍触发推回。安全签字是 CONDITIONAL 时，哪怕审计
+  结论正文写了“通过”，也按 fail 处理。
+- 已知偏差必须有到期与跟进 todo，不能永久接受：偏差清单里
+  每一项都要有跟进 todo 和到期日；无到期跟进 todo 的偏差、
+  或到期未跟进的偏差，都触发推回。“已知偏差已接受”只有在
+  偏差有到期跟进 todo 且未到期时才不触发。
+- 证据标准升级三条，缺一即 fail：
+  1. 回归必须跑确切产物，复用跨任务产物传递的三方哈希核对模式
+     （核心报告 hash、产物清单 hash、协调员重算 hash 三方一致
+     才算数，清单 hash 不一致即停）；不用 fixture 替身跑回归，
+     fixture 模拟的项必须单独列为“未实测”，绝不写成通过。
+  2. 演示必须可运行验证：要跑应用自己的入口、跑出真实流程；
+     不能用通用 `http.server` 冒充演示（只起文件服务器、不跑
+     应用入口的，一律算演示未通过）。
+  3. 缺失的门禁检查按 fail 处理，不按通过补猜：CI、目录隔离、
+     合同版本、协调员批准、未解决评审意见，缺一项证据即 fail。
+
+### 自动推回：审计不过关，系统自动推回，不等人工点头
+
+触发条件表（任一成立即触发，CONDITIONAL 不算通过）：
+
+| 触发项 | 含义 |
+|--------|------|
+| 独立审计签字为 fail | 审计结论本身不通过 |
+| CI 未绿 | 含 CI 账单故障秒级失败的情形：没绿就是没绿，不假装账单已恢复、不拿旧 CI 顶替当前头 |
+| 目录隔离违规 | 分支改了非拥有目录且未经批准的契约变更 |
+| 合同版本不符 | 不是冻结版合同 |
+| 协调员批准缺失 | 无协调员合并决定 |
+| 未解决评审意见 | PR 里有未处理/未回复的评审意见 |
+| 安全签字非无条件通过 | CONDITIONAL 或 fail |
+| 回归未跑确切产物 | hash 不一致、或用了 fixture 替身 |
+| 演示未可运行验证 | 演示跑不起来、或用通用文件服务器冒充 |
+| 已知偏差无到期跟进 todo | 无 todo、无到期日、或到期未跟进 |
+| 审计签字人不独立 | 签字人等于执行人、协调员批准人或 QA 测试人任一 |
+
+- 推回动作是自动的：审计 fail 后系统自动把任务推回重新优化/
+  修复，不停在“等用户/协调员手动重开”上。推回形式二选一，
+  本技能选第 ② 种，并写清取舍：
+  - 选 ②：原任务保持 completed，但自动派生一个修复/优化子任务，
+    并阻塞合并与发布，直到重新审计通过。
+  - 否 ①：原任务状态回退到可重跑状态并附审计结论重跑。否的原因：
+    回退会抹掉 completed 记录、可能重跑有副作用的步骤、还可能
+    让修复悄悄丢弃或覆盖上一轮已通过的产物；② 保留 completed
+    记录与已通过产物原样可查，修复是可追踪的新任务，时间线不断。
+  - 无论哪种，合并与发布在审计重新通过前一律阻塞，绝不能出现
+    “审计 fail 但照样合并/发布”的路径。与第 1 轨硬门禁的接口约定：
+    硬门禁读推回决策的阻塞字段（`merge_blocked` /
+    `release_blocked`、`blocked_by="audit_pushback"`、轮次、
+    失败检查清单），硬门禁自己的检查与推回阻塞是“与”关系：
+    审计通过不解硬门禁的锁，硬门禁通过也不解推回的锁，两边都
+    通过才能合并/发布。代码侧该接口目前是提案（第 1 轨落地时
+    确认接线，在此之前本模块本身不拦任何服务端点，这一点要
+    如实写进 PR 摘要，不冒充已接线）。
+- 推回包必须可执行，缺一项就不算推回完成：审计结论原文；
+  失败项逐条（含测试名、文件路径、行号、合同条款、diff 范围）；
+  复现步骤；修复验收标准（即重新审计时要过的同一批检查，
+  见下“完整重审”）；上一轮产物清单与哈希（复用三方哈希模式，
+  修复不得悄悄丢弃或覆盖上一轮已通过的产物，改动处要可 diff，
+  改动不在修复 diff 里的已通过产物 hash 变了即违规）。
+- 推回上限与升级：推回修复最多三轮（与全自动 CI 自动修复限
+  3 次同口径，但计数不共用：CI 修复轮次发生在审计前，审计推回
+  轮次发生在审计后，一方不得消耗另一方的预算，代码里
+  `ci_auto_fix_rounds` 只作参考输入、不计入推回上限）。
+  超过三轮不再自动推回修复，改走下一节“推倒重做”升级分支；
+  但第 3 次失败先按再下一节“三条收紧”的根因分流判定，
+  结构性错误可提前推倒、接近完成可 targeted 续轮，分流不改变
+  “超过 3 次才推倒”的阈值口径（见收紧一的计数说明）；
+  推倒本身也超限后，才升级给协调员人工复核（G6 验收仍只能
+  用户勾，升级绝不能替用户勾验收）。升级时附带全部轮次的
+  审计结论、改动 diff、成本与 token 消耗，不得只报最后一轮。
+- 完整重审：修复后重新跑全部硬门禁与独立审计（CI、目录、
+  合同、回归确切产物、演示可运行、安全），上一轮通过项在修复后
+  也要复核是否被改坏；只复核失败项的重审不算通过。
+- 成本与配额：修复任务本身计成本与配额，超配额即按配额规则中断，
+  不因“是修复”就绕过配额。
+- 状态与账本：每轮推回、修复、重审都要写审计记录（轮次、触发项、
+  推回包、修复 diff、重审结果），账本走第 4 轨的防篡改机制；
+  本轨先按“审计记录字段 + 校验接口”定义（代码里
+  `build_ledger_entry` / `validate_ledger_chain` 的
+  `prev_hash` / `entry_hash` 链式格式是提案，第 4 轨落地后接线，
+  接口不一致处在 PR 摘要写清）。任务时间线要能看到
+  “审计 fail → 自动推回 → 修复 → 重审”的完整链路，不能只有
+  最终通过一条记录把失败轮次抹掉。
+- 与已有回路的关系，不重复造轮子：G5 缺陷回路（缺陷回 G4、
+  修完回 G5 回归）复用为修复执行通道，推回派生的修复子任务
+  就按 G5 方式执行，只补“自动触发 + 合并发布阻塞”这两块缺失；
+  G7 热修复回路并行（推回是合入前，热修复是发布后应急，
+  推回不能替代热修复、热修复也不能抵推回）；全自动 CI 自动
+  修复并行且计数独立（见上限一段）。注意：G7 与全自动 CI 回路在本文件 v0.5 文本里已有定义
+  （G7 发布后运维、全自动模式），本段按本文件的实际回路定义对齐；
+  推回是合入前、热修复是发布后应急，计数独立。
+
+## 推倒重做：超过三次后的升级分支（不是并行回路）
+
+本节是用户追加的升级分支，与上一节自动推回是同一条链路的两段：
+自动推回是第 1–3 轮的修复回路，推倒重做是超过 3 次后的升级分支，
+不是并行两套回路。不要把“推回修复”和“推倒重做”混成一回事：
+前者是修补同一实现，后者是废弃同一实现、从冻结合同重新实现。
+
+### 计数口径：按模块、按合同版本，审核与验收合计
+
+- 按模块计数：每个模块（例如 web 客户端、iOS 客户端各算一个模块）
+  各自计数，一个模块超限只推倒该模块，不连坐其他模块。
+- 审核 fail 与验收 fail 合并计入同一模块的失败计数：审核指独立审计
+  与硬门禁，验收指 G6 用户验收与 QA 验收；计数时来源分别记录
+  （`audit_fail_count` / `acceptance_fail_count` 各记各的），
+  但触发阈值看合计（`total_fail_count`）。
+- 一次通过即清零该模块的失败计数，下一轮重新计；但同一合同版本
+  下的推倒次数不清零（否则“通过—失败”循环可以无限推倒，
+  见“重做上限”一段）。
+- 按合同版本计：合同版本变了（重新冻结）计数重新起算——失败计数
+  与推倒次数都清零，因为模块改按另一份合同评判，旧计数不能带过去。
+  版本变化时的处理写死：先按新版本把计数清零，再把触发这次
+  重新计数的失败（如有）记为新版本下的第 1 次。
+
+### 阈值语义：恰好 3 次仍推回修复，第 4 次才推倒
+
+- 推回修复最多三轮：第 1 到第 3 次没通过走自动推回修复。
+- 累计失败超过 3 次（即第 4 次仍没通过，或同一模块在同一合同版本下
+  累计 fail 次数 > 3）不再修补，直接触发推倒重做。
+- “超过三次”在代码和本文档里一律是 `> 3`，不是 `>= 3`：
+  恰好 3 次仍是推回修复，第 4 次才是推倒。代码与测试用
+  `round_no` 0、1、2 对应第 1–3 次失败、`round_no >= 3`
+  对应第 4 次失败同一口径钉住边界，两处不一致就是不合格。
+
+### 推倒重做的含义：只推倒该模块，旧实现归档、新实现带避坑清单
+
+- 只推倒该模块：不动其他模块、不动已冻结合同与设计、不动其他
+  已通过模块的产物；目录隔离不变，新实现仍只写该模块的拥有目录。
+  只推倒实现代码：测试、已通过验收项、合同、设计、审计结论、
+  避坑清单一律保留（细则见再下一节“三条收紧”之收紧二，
+  新实现第一道门就是旧测试全过）。
+- 该模块的工作代码从冻结合同出发重新实现。旧代码不直接删除历史：
+  旧实现以提交 / tag / 归档形式保留在 git 历史与审计记录里供复盘，
+  工作区以新实现替换旧实现；审计记录里必须写清新旧实现的对应关系
+  （旧实现 ref、新实现分支、替换点），删历史、改写历史冒充
+  “从来没失败过”的一律不合格。
+- 上一轮的审计结论、失败原因、已通过项清单要作为新一轮的
+  “避坑清单”带进新实现任务包：新实现任务包里逐条列出此前
+  失败项与此前已通过项，绝不能让新实现把同一错误再犯一遍后
+  还声称是全新开始；重审时避坑清单上的项要逐项复核。
+
+### 先判根因再决定是重做还是重新冻结
+
+- 连续失败先判根因，再决定是重做代码还是重新冻结，不要一超限
+  就无脑重做代码。
+- 根因判定标准（代码 `classify_root_cause` 的可测试版）：
+  合同/设计根因成立当且仅当以下任一成立：① 至少两轮审计结论
+  指向同一合同/设计条款且根因为合同/设计；② 修复方至少两轮
+  证明按合同无法实现（`proved_unimplementable`）。只一轮指向
+  合同/设计、或指向条款各不相同，都算根因未定，不触发重新冻结。
+- 如果根因在合同或设计本身（例如合同自相矛盾、设计不可实现、
+  技术栈选错），推倒代码重做是治标不治本：此时不自动重做代码，
+  改为触发 G2 重新冻结流程，并升级给协调员人工复核（协调员须把
+  新冻结方案交用户定，升级本身不替用户冻结合同、更不替用户勾 G6）。
+- 根因未定（无两轮以上的合同/设计证据）时默认走推倒重做分支：
+  重新冻结需要肯定证据，不能凭猜测冻结；推倒重做是可逆的第一步，
+  且新实现包里有避坑清单，不会盲目重来。
+- 测试/检查要能区分“代码实现问题”与“合同/设计问题”：
+  两轮同条款合同根因 → 重新冻结；两轮实现根因 → 推倒重做；
+  一轮合同指向 → 根因未定 → 推倒重做（见代码测试）。
+
+### 重做也有上限，绝不无限重开
+
+- 同一模块在同一合同版本下最多推倒 1 次（不是 2 次）：取舍写清——
+  推倒是全量重做、成本最高，1 次已是真正的第二次机会；若新实现
+  再累计失败超过 3 次，问题几乎不在可修补代码里，而在合同/设计
+  或能力本身，第二自动次推倒只会烧成本、掩盖根因，所以不再自动重开。
+- 重做后的新实现重新计失败次数（从第 1 次起算），再累计失败超过
+  3 次即升级，不再自动重开。升级去向：升级给协调员人工复核，
+  附带全部轮次审计结论、历次推倒记录、改动 diff、成本与 token
+  消耗；G6 验收仍只能用户勾，升级不能替用户勾验收。
+- 推倒次数与失败计数、推回轮次一样写审计记录（见下）。
+
+### 成本与配额：重做是全量重做，成本最高，照常计
+
+- 推倒重做仍计成本与配额，超配额即按配额规则中断；超配额的推倒
+  不消耗推倒次数（根本没开始重做，不能算用掉一次机会）。
+- 如预估重做成本超过用户定的成本超阈值 escalation 线，先升级给用户，
+  而不是悄悄烧掉：升级时附预估成本与阈值，待用户决定是否重做、
+  缩范围还是停掉；用户没点头前不启动重做。
+- 预估与实际的记录方式：重做任务包里先写预估成本（启动前），
+  完成后补实际成本与 token 消耗，未定价的项绝不记 0（沿用成本
+  双列口径：预估一列、实际一列）。
+- 重做任务包里要写清“这是推倒重做第 N 次、上一轮失败原因”，
+  任务标题与任务包 kind 都标明 rebuild，不能伪装成普通新任务。
+
+### 状态与账本：计数、推回、推倒、根因都要留痕
+
+- 模块失败计数（审核/验收分来源、合计）、推回轮次、推倒次数、
+  重做新旧实现对应关系、根因判定结果都要写审计记录，走第 4 轨
+  的防篡改机制（本轨先按字段 + 校验接口定义：账本条目含
+  `module_id`、`contract_version`、`fail_counts`、`rebuild_no`、
+  `root_cause`、`old_implementation_ref`，链式校验见代码
+  `build_ledger_entry` / `validate_ledger_chain`，第 4 轨落地后接线）。
+- 任务时间线要能看到完整链路：“审计 fail → 自动推回修复
+  （1–3 轮）→ 超过 3 次 → 推倒重做 → 重新审计”，不能只有最终
+  通过一条记录；推倒记录、重新冻结升级记录同样留痕，不得抹掉。
+- 与上一节自动推回的关系再写一遍以免混淆：自动推回（1–3 轮修补）
+  在前、推倒重做（超过 3 次）在后，是同一链路的前后两段；
+  与 G5 缺陷回路的关系是复用修复执行通道（重做任务本身仍按
+  阶段派生、仍走 G5 回归复核），与 G7 热修复回路并行（已发布
+  模块的应急修复走 G7，不走推倒），与全自动 CI 自动修复并行
+  且计数独立（CI 修复轮次不计入模块失败计数、也不计入推倒次数）。
+
+## 三条收紧：分流、保留资产、审计的审计
+
+本节与自动推回、推倒重做并列，不覆盖已有计数与推倒规则：
+阈值仍是 `> 3` 才推倒、推倒每模块每合同版本最多 1 次、G6 验收
+仍只能用户勾。下面三条只把原来可能留主观口子的地方写成
+可测试机制。代码在 `cloud/audit_pushback.py`，判定函数、
+阈值与输入输出见该文件 docstring 与测试。
+
+### 收紧一：阈值不能死板，第三次失败先判根因
+
+- 固定 3 次只当默认值，不能当真理。第三次失败（累计 fail = 3、
+  尚未触发推倒的那一刻）必须先做一次根因判定，再决定下一条路；
+  判定结果与判定依据要写进审计记录，事后可抽查。
+- 判定分两类，标准写死，不留“协调员觉得差不多”这种主观句：
+  ① 结构性错误 → 提前推倒重做，不必等到第 4 次。结构性指：
+  架构边界错、模块职责错、技术栈或数据模型根本性错误——代码里
+  是失败项带 `structural_kind`（四类之一）或触及核心结构；
+  但连续多轮指向同一设计/合同条款属于合同/设计结构性，
+  按原根因规则转 G2 重新冻结升级，不直接推倒代码（合同优先于
+  代码推倒，因为合同修了架构可能跟着变；两者信号同时出现时
+  也先走重新冻结）。提前推倒计入推倒次数（每模块每合同版本
+  最多 1 次的预算照扣），不是免费的一次。
+  ② 接近完成、只差收尾 → 再给一轮 targeted 修复。接近完成的
+  判定条件四条全满足才算：失败项 ≤ 2 项；失败项与核心结构无关
+  （无结构性种类、无核心触及、无合同/设计根因）；上一轮已通过项
+  未被破坏（破坏清单为空，且须实测提供、不能缺省当作空）；
+  已通过项数量多于失败项数量。targeted 修复范围只限失败项与
+  直接相关代码，不得借机重构无关部分；续轮最多 1 次
+  （每模块每合同版本 1 次，代码 `targeted_fix_used`）。
+- 计数方式（两处一致，不得出现两套计数）：续轮算入累计失败计数，
+  不单独计数——targeted 轮本身就是第 3 轮推回；该轮再 fail 即
+  累计第 4 次失败，按原规则触发推倒（不得以“接近完成”为由
+  再续一轮）；targeted 预算不计入推倒预算，推倒也不补回
+  targeted 预算；推倒后新实现失败计数清零，但 targeted 预算
+  与推倒次数在同一合同版本下都不清零（合同版本变了才全清零）。
+- 判定本身可审计：判定依据（审计结论原文、失败项清单、diff 范围、
+  已通过项清单、已破坏项清单）附在记录里；判定为“接近完成”
+  却在续轮后仍 fail 的案例，事后抽查时能从记录里复核当初四条
+  条件是否真的全满足，条件不满足却给了续轮的，记为判定错误
+  并走收紧三的纠错路径。
+
+### 收紧二：推倒只推倒实现代码，测试与已通过资产全部保留
+
+- 推倒重做的范围写死：只替换该模块的实现代码；测试用例、
+  已通过的验收项、合同、设计、审计结论、避坑清单一律保留，
+  不得随实现代码一起清零；新实现任务包里必须包含旧测试集
+  与已通过验收项清单（代码里是重做包的 `retained_assets`，
+  没给旧测试集的包标 `retained_tests_missing`，不算合格包）。
+- 新实现的第一道门就是旧测试全过：重做后的实现先跑旧测试集
+  与已通过验收项复核，全过才进入新一轮完整审计；过不了旧测试
+  就不算重做成功，直接记为重做失败并计入失败计数（新实现
+   episode 的审核失败计数），不得以“新实现有新功能”为由
+  跳过旧测试；旧测试缺结果按 fail 处理，不按通过补猜。
+- 旧测试本身如因合同变更而失效，须走合同重新冻结流程改测试，
+  不得在重做时悄悄删测试或改断言：删测试或改断言必须同时满足
+  两项——合同已走 G2 重新冻结、且该改动有单独审计记录；缺一项
+  即违规（代码 `validate_test_changes`）。新增测试不需要重新冻结，
+  但新增不能冒充删除（把旧测试删了再以新名加回来，仍按删除算）。
+- 旧实现归档与新实现对应关系不变：旧实现以提交 / tag / 归档保留，
+  新旧实现 diff、测试通过情况、已通过项保留情况都要写进审计记录。
+
+### 收紧三：审计本身要被审计，G6 人工验收不能被自动化绕过去
+
+- 审计兜底三件套，缺一不可，全部可测试或可核查：
+  ① 独立重跑的确切产物测试，不是只看报告：复用三方哈希模式
+     （核心报告、产物清单、重算 hash 三方一致），产物不一致即停。
+  ② 金任务集与关键路径的人工审定样本，定期抽查审计结论本身：
+     金任务集必须人工审定（每项有 `human_approved_by`），示例文件
+     不算金任务；抽查比例写死：金任务与推倒/重新冻结/升级记录
+     100% 抽查，普通记录每 10 条确定性抽 1 条（按序号、可复现，
+     不是随机抽）；抽查结果处理：抽查发现判错即走纠错路径。
+  ③ G6 用户验收这个最后人工关口不能被自动化绕过去：审计升级、
+     推回、推倒、抽查纠错都不能替用户勾验收，验收清单最后只能用户勾。
+- 审计判错的纠错路径：事后抽查发现审计结论判错（该拦没拦、或
+  不该拦拦了），要能纠正该轮审计结论、恢复或重新触发相应流程，
+  并把判错记入审计的审计记录，不得只改当轮结果不留痕。实现方式：
+  原记录不动，追加一条纠错记录（引用原记录 hash、写清原结论、
+  纠正后结论、纠错人与原因）；该拦没拦的纠正 → 重新触发推回并
+  恢复阻塞；不该拦拦了的纠正 → 安排重新审计（不是直接放行合并，
+  因为纠错本身只是复核、不是完整审计）；纠错人必须与原签字人不同。
+
 ## 诚实边界：原生客户端（v0.5 后置占位版）
 
 - 在只有 Linux 主机的环境里，PWA、“添加到主屏幕”、WebView 壳是能做能测的；
@@ -771,6 +1077,11 @@ tests/                 # QA 线程专属，含跨端一致性用例
   回归提示词里产物清单与文件原文双通道齐了吗？回归结尾有
   ARTIFACT-VERIFY 一节与 ARTIFACT-VERIFY-OK 吗？回归是跑同一份
   核心代码，还是自己写 fixture 猜契约？
+- 审计与推回走了吗？审计签字人是否独立于执行人、协调员批准人、
+  QA 测试人？安全签字是不是无条件通过？审计 fail 后有没有自动推回
+  并阻塞合并/发布？模块失败超过 3 次后有没有按推倒重做分支处理
+  （先判根因、只推倒该模块、旧实现归档、避坑清单带进新包），
+  而不是无限修补或悄悄放行？
 有一项为否，就停在当前门禁，不进入下一阶段。
 
 ## 附录：角色模板（播种随附版）
@@ -1477,3 +1788,44 @@ iOS / Android 原生后置占位不进 QA 通过表，标注“未编译 / 未
   Vitest、OpenAPI 或共享类型），G2 冻结后不准中途换，只有
   用户特别要求时才换语言；codex-app-server 本身保持 Python，
   不为统一语言重写。
+
+## 附录角色：11-auditor（来源 templates/roles/11-auditor.md）
+
+# 角色模板：独立审计（1 个线程，与 QA、协调员、执行人分开）
+
+你是本项目的独立审计线程。你不写业务代码、不改待办、不给合并决定、
+不执行合并。你只做：独立重跑测试、抽查证据、单独签字。
+
+## 你必须先做的事
+
+1. 拿到交付物后自己重跑测试，不要只复读 QA 的报告；QA 说通过
+   不等于你通过，你的重跑命令和结果要写进审计记录。
+2. 按技能主文档“独立审计与自动推回”一节逐项核对：CI、目录隔离、
+   合同版本、协调员批准、未解决评审意见、安全签字、回归确切产物、
+   演示可运行、已知偏差到期跟进 todo。缺一项证据即 fail，不补猜。
+3. 签字人就是你，且必须与任务执行人、协调员批准人、QA 测试人
+   都不同；相同即审计结论无效，按 fail 处理。
+
+## 你的签字规则
+
+- 只有无条件通过，或拦住。CONDITIONAL 不算通过；安全签字
+  CONDITIONAL 时结论就是 fail，并触发自动推回。
+- 已知偏差无到期跟进 todo、或到期未跟进时，结论就是 fail。
+- 回归用了 fixture 替身、或 hash 对不上时，结论就是 fail，
+  fixture 项单独列“未实测”，不写成通过。
+- 演示没跑应用入口（例如只起了通用文件服务器）时，结论就是 fail。
+
+## 你的交付物
+
+- 审计结论原文、失败项逐条（测试名、文件路径、行号、合同条款、
+  diff 范围）、复现步骤、上一轮产物清单与哈希。
+- 审计 fail 时你不等人点头：系统按“自动推回”一节自动派生修复
+  子任务并阻塞合并/发布；你只负责把推回包写完整。
+- 模块失败超过 3 次时，你先判根因（见“推倒重做”一节的两轮标准），
+  再决定是推倒重做还是转 G2 重新冻结升级；根因判定结果写进审计记录。
+
+## 禁止
+
+- 不替开发线程改代码“顺手修掉”，修了就审不出原缺陷。
+- 不把“没测”写成“通过”，不把 CONDITIONAL 写成通过。
+- 不替用户勾 G6 验收，不替协调员给合并决定。

cloud/skills/software-engineering/templates/roles/11-auditor.md

@@ -0,0 +1,38 @@
+# 角色模板：独立审计（1 个线程，与 QA、协调员、执行人分开）
+
+你是本项目的独立审计线程。你不写业务代码、不改待办、不给合并决定、
+不执行合并。你只做：独立重跑测试、抽查证据、单独签字。
+
+## 你必须先做的事
+
+1. 拿到交付物后自己重跑测试，不要只复读 QA 的报告；QA 说通过
+   不等于你通过，你的重跑命令和结果要写进审计记录。
+2. 按技能主文档“独立审计与自动推回”一节逐项核对：CI、目录隔离、
+   合同版本、协调员批准、未解决评审意见、安全签字、回归确切产物、
+   演示可运行、已知偏差到期跟进 todo。缺一项证据即 fail，不补猜。
+3. 签字人就是你，且必须与任务执行人、协调员批准人、QA 测试人
+   都不同；相同即审计结论无效，按 fail 处理。
+
+## 你的签字规则
+
+- 只有无条件通过，或拦住。CONDITIONAL 不算通过；安全签字
+  CONDITIONAL 时结论就是 fail，并触发自动推回。
+- 已知偏差无到期跟进 todo、或到期未跟进时，结论就是 fail。
+- 回归用了 fixture 替身、或 hash 对不上时，结论就是 fail，
+  fixture 项单独列“未实测”，不写成通过。
+- 演示没跑应用入口（例如只起了通用文件服务器）时，结论就是 fail。
+
+## 你的交付物
+
+- 审计结论原文、失败项逐条（测试名、文件路径、行号、合同条款、
+  diff 范围）、复现步骤、上一轮产物清单与哈希。
+- 审计 fail 时你不等人点头：系统按“自动推回”一节自动派生修复
+  子任务并阻塞合并/发布；你只负责把推回包写完整。
+- 模块失败超过 3 次时，你先判根因（见“推倒重做”一节的两轮标准），
+  再决定是推倒重做还是转 G2 重新冻结升级；根因判定结果写进审计记录。
+
+## 禁止
+
+- 不替开发线程改代码“顺手修掉”，修了就审不出原缺陷。
+- 不把“没测”写成“通过”，不把 CONDITIONAL 写成通过。
+- 不替用户勾 G6 验收，不替协调员给合并决定。

cloud/skills/software-engineering/tools/check_appendix.py

@@ -10,10 +10,10 @@ source, then re-issue the appendix through the skill's own track),
 never a silent rewrite by this script.
 
 What it checks, in order:
-  1. SKILL.md contains the appendix intro and exactly the eleven
-     chapters 00..10, in order, each with a source note naming its own
+  1. SKILL.md contains the appendix intro and exactly the twelve
+     chapters 00..11, in order, each with a source note naming its own
      templates/roles/<id>.md file.
-  2. templates/roles/ contains exactly those eleven source files:
+  2. templates/roles/ contains exactly those twelve source files:
      a missing source fails, an unexpected extra file fails.
   3. Each source, in canonical form, equals the matching appendix
      chapter in canonical form (see canonical() below).
@@ -29,7 +29,7 @@ and its appendix chapter -- anything else is a failure):
   b. One inter-chapter separator line "---": in the current SKILL.md
      it appears after chapters 01/02/03/05/06/09 only. Chapters
      00/04/07 end with their GitHub subsection and run straight into
-     the next heading with no separator, and 10-iteration is the end
+     the next heading with no separator, and 11-auditor is the end
      of file.
      The check strips at most one trailing separator; it does NOT
      normalise SKILL.md to a uniform separator, so the current
@@ -64,7 +64,8 @@ from pathlib import Path
 EXPECTED_IDS = ["00-coordinator", "01-product-manager", "02-architect",
                 "03-designer", "04-client-developer", "05-backend",
                 "06-qa", "07-acceptance", "08-shared-core",
-                "09-ops", "10-iteration"]
+                "09-ops", "10-iteration",
+                "11-auditor"]
 
 CHAPTER_RE = re.compile(
     r"^## 附录角色：(\d{2}-[a-z0-9-]+)"