Audit Common

Audit Common Skill

职责

所有 audit 工作流必须先执行 G0 体量评估 + Profile Freshness Check + G1~G5 公共维度，再叠加子类型专属维度（TD/RQ/PE/RA/DA/RL）。

G0 体量评估（前置，G1 之前执行）

G0 必须先调用 skill-gap-analysis 的 ProjectArtifactScaleRoutingGate：识别唯一项目/root，使用 bounded inventory 统计文件数、可解析字节、最大文件、目录集中度、派生产物比例和消费者扩散面，形成 ScaleDecisionRecord 后才允许 CRS 或内容审查。用户提示目录很大时不得降为 single-pass；项目/root 不明确时必须 blocked。

审查开始前统计待审查文件/目录总数，决定执行策略：

分批策略详见 audit-execution-guide/SKILL.md §体量分批策略。

ReReviewRuntimeFirstGate / ClosureEvidenceGate

当用户要求「再审 / 已调整 / 复审修订稿」或审查宣称 finding closed / 可确认下一 CP / 可实施 / scheme-pass 时：

1. ReReviewRuntimeFirstGate：先绑定当前正文 hash；先问「按实施计划开工，Hook/MCP/descriptor 会不会假绿？」并抽样 runtime/writer/reader；禁止只对照方案段落是否出现旧 finding 文案后关闭。
2. ClosureEvidenceGate：每条 P0/阻断关闭须双列 designEvidence + runtimeOwners(writer|reader|schema|probe) + negativeProbe；仅 design → 最高 partial，禁止写可进 CP3。
3. 外部/前序审查报告（含其他 Agent）一律 AuditReportIsSignalNotEvidence，须回源码/当前正文复证。
4. 探针锚点：V100。

ReviewCoverageClaimIntegrityGate

审查报告、清单和最终回复必须区分 inventory-covered / machine-scanned / manually-read / sampled-deep-read / executed-verified。目录枚举、grep 命中、抽样深读和运行探针不得相互冒充。

• 声明“逐文件 / 逐服务 / 全量深读”时必须提供 FileEvidenceLedger，逐项记录 path、coverageLevel、evidence、status 和 unread reason。
• sampled 路线必须记录 sampleMethod / sampledSet / unreadSet / inferenceBoundary，不得把样本结论无条件外推到未读集合。
• executed-verified 只证明对应命令或路径，不自动证明人工阅读或全部消费者覆盖。
• 无法取得逐文件证据时必须降级声明，禁止用更强措辞包装较弱证据。
• coverageClaims 必须记录 claim type、evidence mode、FileEvidenceLedger 或 sampled/unread/inference boundary，供 review checklist、TestRoute、report 与 V94 复证。

Profile Freshness Check（PFresh）

🔴 audit 不得默认 Profile 永远可信；在使用 Profile 做 G3 外部一致性之前，必须先反向核对 Profile 是否仍匹配当前项目事实。 audit 统一使用 load-profile 的 ProfileTruthReconciliationGate full 模式；PFresh-1~PFresh-6 是 full 模式的强制检查集合，不得被 targeted 或 N/A 路径削弱。

full 模式还必须执行 repo-shape 反查：当仓库已具备 SDK/CLI、文档站、public API、CI、发布、多模块或规范控制面特征时，核对 Profile 自报档位与 04~07 活文档是否完整。审查报告必须输出 profileTrustState 和 ProfileTruthMatrix(profileClaim / actualSources / status / conclusionAuthority / correctionRoute)。

若任一 PFresh 项无法验证，profileTrustState=partially-unverifiable 且审查结论必须标注 ⚠️ Profile freshness 待验证；若确认过期，profileTrustState=drift-detected，先记录审查 finding / 治理台账并以当前事实矫正本轮结论，再继续后续 G1~G5。audit 不得直接修改 Profile，也不得基于过期 Profile 宣告收敛。

公共维度（G1~G5）

统一联查矩阵映射（audit = L3）

• audit 天生对应统一联查矩阵的 L3 强联查
• CRS / G3 / PCV 继续作为 audit 的主路径，不降级、不被其他轻量联查规则替代
• 其他工作流升级为 L3 时，应向 audit 的“关联文件全覆盖 + 收敛门禁”靠拢，而不是反过来弱化 audit
• 正式复审、ECR、发布前复审、多轮收敛、外部 finding 批次或用户要求“复审直至收敛”时，必须触发 review-checklist，先创建或复用复审清单文件，冻结范围和维度，再逐项执行证据核验，并通过 ChecklistStateFreshnessGate 确认清单状态、最新证据和收敛结论一致。

关联文件发现（CRS — 收敛前必须执行）

🔴 CRS 是收敛的前置门禁：宣告收敛前，必须完成关联文件发现扫描，确认审查范围已覆盖所有引用相同概念的文件。

执行时机

CRS 执行步骤

1. 提取关键词：从本次修改（或被审查）的文件中提取核心概念词（规则名、文件路径、配置项名等）
2. 全库 grep：在以下范围内 grep 这些关键词：
   • instructions/（Instruction 层）
   • skills/（Skill 层）
   • prompts/（Prompt 模板）
   • agents/（Agent 定义）

• data/（数据文件：gap-registry.md / pending-fixes.md / pending-issues.md 等）
  • 根目录 *.md（RULES.md / README.md / CHANGELOG.md）

3. 【v1.11.0+ 父链部署体扫描】（关联 GAP-019）：
   • 检测条件：当 cwd 是 plugin 源仓库（含 package.json 且 name 含 devcodex），且 cwd 父链上存在 .github/、.claude/、AGENTS.md、.agents/ 或 .codex/ 部署体
   • 触发动作： a. 将工作区根的 .claude/{instructions,skills,prompts,agents,hooks}/、.github/{instructions,skills,prompts,agents,hooks}/、AGENTS.md、.agents/、.codex/ 也纳入 grep 范围 b. 对每个命中文件做 G3 外部一致性检查（与源仓库对应文件是否一致） c. 若发现部署体 / 用户级 adapter 与源仓库不一致 → 标注 ⚠️ 部署滞后，列出源码仓 devcodex global-adapters apply、pack+全局安装或已发布环境 npm update -g devcodex 的适用方案；这些命令必须取得当前明确的全局环境修改授权后才可执行，审计/Auto/Profile 不补权。不要用 bare devcodex update 或 update --claude/--codex 冒充刷全局；授权执行后再运行 node scripts/validate.js V8 / devcodex doctor
   • 目的：避免源仓库与工作区根部署体并存时 CRS 仅扫源仓库导致误判（GAP-019 案例：F-03/F-04 因未扫父级 e:\Worker\.claude/ 而误判为"hooks 不生效"）
   • 跳过条件：当 cwd 即工作区根（无父链部署体）→ 跳过本步骤

• ⚠️ V8 与 CRS 职责不可互替（PI-006，v1.9.5+）：scripts/validate.js 的 V8 checkPairs 已覆盖 instructions/skills/hooks/CLAUDE.md/prompts/agents 等关键部署面，但仍只是 CI 快速门禁；CRS 手动 grep 仍是收敛前全量同步的必要补充——V8 ✅ ≠ 全量部署同步

4. 发现关联文件：将 grep 命中且不在当前审查范围内的文件列入扩展范围
5. 补充 G3 审查：对每个新发现文件执行 G3 外部一致性检查
6. 确认覆盖完整：所有命中文件均已审查后，CRS ✅

ℹ️ CRS 发现的文件只需做 G3（外部一致性），不需要完整重跑全部维度。

CRS 示例

修改了：02-output-paths §02-技术方案.md（改为条件触发）
grep "02-技术方案" instructions/ skills/
→ 命中：10-dev.instructions.md L56、cp-gate/SKILL.md L52
→ 这两个文件不在审查范围 → 加入范围 → 执行 G3 → 发现冲突 → 🔴 问题

审查发现交接循环（阻断暂停 / 非阻断入池）

🔴 触发条件：任何 audit finding 都进入交接循环，与审查对象类型无关。audit 只允许写审计报告、audit-state、记忆和 RecordRouter 台账；禁止修改或暂存被审查源码、规范、配置、测试、文档和部署副本。

🔴 核心原则：先分流，再交接，最后由用户决定是否启动独立修复：

• 阻断项：会直接影响当前控制面正确性、造成假绿、导致规则执行失真或形成明显错误指引 → 保持 open/pending，停止受影响范围的通过结论并提出显式确认请求
• 非阻断项：属于流程优化、模板体验、治理补强、可择期处理的问题 → 写入适当台账/问题池，状态 recorded/transferred
• 修复动作：仅在用户显式授权后由独立 fix/self-fix 工作流执行；audit 不自动切换、不 source mutation、不 git add

上述边界统一称为 AuditMutationBoundaryGate；每轮 finding 分流和最终报告必须记录 auditWritableArtifacts、sourceMutationAuthorized=false、repairWorkflow 与 repairAuthorizationEvidence。

交接循环流程

开始审查
  ↓
R1：CRS + 输出发现的问题清单（只读）
  ↓
有问题？
  ├── 是 → 自我审视（实证→三列验证→对话感知→阻断/非阻断分流→盲点分析，见 §自我审视机制）
  │         ├── 阻断项 → open/pending + ConfirmationRequest → 等待用户决定是否启动独立 fix/self-fix
  │         └── 非阻断项 → 记录/转交到适当台账 → 继续可完成的审查范围
  │
  │   用户授权并完成独立修复 → audit 读取新证据 → 重启新一轮（**收敛计数归零**）
  │
  └── 否（零发现）→ 收敛计数 +1
        ├── 计数 < 3 → 继续下一轮 audit
        └── 计数 ≥ 3 → CRS 收敛门禁 → PCV → 最终报告

关键规则

交接循环状态追踪输出格式

每轮结束时输出当前状态（dev 模式下在每条回复末尾必须输出，不得因元循环工作流类型而跳过）：

---
🔄 审查发现交接状态
- 当前轮次：R{N}（本大轮审查第 N 次 audit）
- 本轮发现：🔴 X 个 / 🟡 Y 个 / 💡 Z 个
- ReviewCoverageDelta：
  - ReviewedSet：本轮已复核范围
  - UnreviewedRelatedSet：由 CRS / 调用链 / 消费链 / 配置 / 测试 / 文档 / 部署副本推导出的未读相关候选
  - NewlyReadThisRound：本轮新增阅读的未审查相关面
  - RepeatReadReason：重复阅读已审查锚点的理由（高风险锚点 / 修复回归 / 抽样 / 新证据）
  - NoNewSurfaceReason：无新增阅读面时的证据化理由
- ReviewDimensionDeltaGate：
  - PreviousDimensionSet：上一轮或已完成轮次实际覆盖维度
  - CurrentDimensionFocus：本轮新增、轮换、补强或回归维度
  - NewDimensionRationale：本轮维度焦点的证据化理由
  - RepeatedDimensionReason：重复维度的理由（阻断项回归 / 高风险锚点 / 新证据 / 抽样）
- 自我审视：[M1/M2/M3/M4 盲点类型，或"N/A（零发现）"]
- 修复交接状态：[等待用户授权 / 已转独立 fix/self-fix / 已获外部修复证据 / 零发现无需交接]
- 有效零发现计数：{n}/3（达到 3 次则收敛）

🛡️ DEV 模式 | 合规检查
FC: FC1 [✅/❌] FC2 [✅/N/A] FC3 N/A FC4 [✅/❌] FC5 [✅/❌] FC6 [✅/❌] FC7 [✅/N/A]
SC: SC4 [✅/❌] SC6 [✅/❌] ...（仅列适用项，逐项实际验证后填写）
整体：✅ 全通过 / ⚠️ <N> 项待修正

📂 本次会话产物：
- [filename (类型)](workspace相对路径/skills/xxx/SKILL.md)
- [filename (类型)](workspace相对路径/file.md)
---

ℹ️ 合规检查块是 dev 模式下的强制输出，审查发现交接循环不例外。FC2（报告文件）在 PCV 完成后输出最终报告时满足；中间轮次标注 N/A（进行中，未到输出节点）。 ⚠️ FC5 填写规则：审计产物先进入 ArtifactDeliveryManifestV1，再由 UserFacingArtifactSetV1 投影“完成交付文件/阻断证据”。用户可见项必须有语义名称、用途和动作；session/SUMMARY/raw ledger 默认 internal-only。链接按当前 surface 的 capability evidence 选择，Rich clickable 不重复绝对路径；未观察 assistant payload 时只能 unverified。