/audit-common

name: audit-common
description: 审查公共维度 G0~G5 + Profile Freshness Check — 所有 audit 子类型必先执行的基础维度层

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。

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

| 文件总数 | 策略 | 说明 | |:--------:|------|------| | 1~30 | 默认 single-pass 候选 | 仍需同时满足字节、最大文件、派生比例和 fan-out 预算 | | 31~60 | 默认 batched | 输出 batch budget/checkpoint 后执行 | | > 60 | 强制 batched 或 sampled+deep-read | 全量 inventory，不等于逐字全读 |

> 分批策略详见 [`audit-execution-guide/SKILL.md`](../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 路径削弱。

| 编号 | 检查项 | 说明 | |------|--------|------| | PFresh-1 | 版本与包身份 | 对照 `package.json`、`plugin.json`、根 `CHANGELOG.md` 与 `changelogs/`，检查 Profile 当前版本、阶段摘要、发布状态是否过期 | | PFresh-2 | 资产数量与目录事实 | 对照 `instructions/`、`skills/`、`prompts/`、`scripts/`、`data/templates/`、主要源码目录，检查 Profile 资产数量和目录边界是否漂移 | | PFresh-3 | 脚本与验证路线 | 对照 `package.json scripts`、CI/发布脚本和当前 TestRoute，检查 Profile 中的测试、构建、发布命令是否仍真实可用 | | PFresh-4 | 宿主与部署能力 | 对照 `.github/`、`.claude/`、`.codex/`、`AGENTS.md`、MCP/Hook 配置，检查 Profile 的宿主能力说明是否滞后 | | PFresh-5 | 当前任务现实 | 对照 active-root 下当前 `requirements/`、`bugs/`、报告、SUMMARY 与 open ledger，检查 Profile 是否漏记新增边界、风险或治理能力 | | PFresh-6 | 发布关键 Profile 字段 | 对自动发包、npm package、CLI/plugin 或 release-heavy 项目，检查 Profile 是否覆盖 CI workflow/job 矩阵、tag/publish 触发链、失败恢复路径、外部消费者验证矩阵、dist 产物边界、registry/tag 验收与常见故障诊断 |

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）

| 维度 | 内容 | 优先级 | |------|------|:------:| | G1 文件完整性 | 必需章节/字段齐全，无空白占位 | 🔴 | | G2 内部一致性 | 文档内部无矛盾（定义 vs 使用，目录 vs 正文） | 🔴 | | G3 外部一致性 | 与引用文件/规范/代码实现不矛盾 | 🔴 | | G4 格式规范性 | 标题层级正确，代码块有语言标记，表格对齐 | 🟡 | | G5 链接有效性 | 内部/外部链接可访问，锚点存在 | 🟡 |

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

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

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

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

执行时机

| 时机 | 说明 | |------|------| | **R1 范围确认前** | 建立初始文件集合时 | | **宣告收敛前** | 作为收敛门禁的最后一步 |

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
→ 这两个文件不在审查范围 → 加入范围 → 执行