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）：
   • 当前部署权威：GlobalOnlyHostConfigModeV1 使用 GlobalHostTargetV1 / GlobalHostConfigReceiptV1 的用户级指令、G_RUNTIME、config 和 runtime generation；不从源仓 cwd 或父目录名称推断宿主已安装。空 .agents/、.codex/ 或只有 CI 的 .github/ 不证明存在 DevCodex 部署。
   • 历史检测条件：父链有实际旧 adapter 入口或 managed manifest 证据，且本轮明确核对 legacy/迁移范围时，才扫描旧 workspace 部署；retired fixture、用户原生文件与当前受管文件分别归类。
   • 触发动作： a. 当前部署按 receipt 的实际落点纳入 G3；明确历史核对时，另列旧 .claude/{instructions,skills,prompts,agents,hooks}/、.github/{instructions,skills,prompts,agents,hooks}/、AGENTS.md、.agents/、.codex/ 的证据和适用版本。 b. 对当前受管内容核 source/compiled digest、generation、配置、进程实际加载路径；旧副本只按当时契约或迁移计划核对，不要求与当前发布包逐字一致。 c. 当前用户级 adapter 滞后时，列出源码仓 devcodex global-adapters apply、pack+全局安装或已发布环境 npm update -g devcodex 的适用方案；既有授权已覆盖部署时按该 scope 执行，审计/Auto/Profile 本身不扩权。不要用 bare devcodex update 或 update --claude/--codex 冒充刷全局，也不能声称全局 apply 会重写旧父链副本；授权刷新后核 receipt、devcodex doctor 和新 CLI/MCP 的实际行为。
   • 目的：避免只读源码就推断部署已生效，同时保留 GAP-019 的历史核对能力。
   • 未发现受管部署证据时：记录部署状态 UNVERIFIED/N/A，不把空目录升级为待补齐副本，也不宣称宿主原生通过。

• ⚠️ V8 与 CRS 职责不可互替（PI-006，v1.9.5+）：V8 在 source scope（authoring package 未指定范围时自动识别）核源码边界，并保留显式 workspace 范围的 legacy checkPairs；它不签发当前用户级安装或原生加载资格。CRS、当前 receipt/内容摘要和真实宿主证据分别留存——V8 ✅ ≠ 全量部署同步。

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

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

CRS 示例

textCopy code
修改了：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。

交接循环流程

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

关键规则

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

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

textCopy code
---
🔄 审查发现交接状态
- 当前轮次：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}/R（达到 Owner 所需轮数，再通过 CRS/PCV 才收敛）

🛡️ 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。

审查收敛规则

• 🔴 CRS 是收敛门禁：必须先完成 CRS（§关联文件发现），扩展范围内的文件 G3 全通过，才允许进入收敛倒计时
• 🔴 连续 3 轮有效零发现为默认：无论之前已运行多少轮，必须连续 3 轮均无新发现，且每轮覆盖增量和维度增量都合格，方可声明收敛
• CRS 发现新文件时，零发现计数重置为 0
• 禁止提前收敛：CRS 未完成、未达到所需零发现轮次，或 ReviewCoverageDelta / ReviewDimensionDeltaGate 不合格时不得输出"已收敛"结论

窄范围 audit 收敛降档（SK-FIX-15b / medium）

当且仅当用户明确 窄范围 / 单文件 / 单模块 audit，且 ScaleDecision 为 single-pass、无控制面跨宿主扩散、不属于 full/security/release 审查时，可将「连续有效零发现」从 3 轮降为 2 轮，但必须：

1. 报告写明 convergenceMode=narrow-2 与范围边界；audit-state 同时保存该模式及完整 reviewExecutionPlan（Owner 生成、摘要有效且候选绑定的 ReviewExecutionPlanV1，exit.auditConvergence.mode=narrow-2）；audit-session 与 V15 使用同一 Owner 的 requiredAuditZeroFindingRounds(state)，缺失或篡改不得降档；
2. 仍满足 CRS ✅ 与 ReviewCoverageDelta / ReviewDimensionDeltaGate；
3. 一旦发现控制面、多消费者或范围扩大，立即恢复默认 3 轮。

ReviewCoverageDelta（复审覆盖增量）

R2 及以后轮次必须维护复审覆盖增量，防止连续零发现退化为重复阅读同一批已通过内容。

计数规则：

• NewlyReadThisRound 非空，且本轮无新增问题 → 可计入 1 次有效零发现。
• NewlyReadThisRound 为空，但 NoNewSurfaceReason 有证据支撑，且本轮无新增问题 → 可计入 1 次有效零发现。
• NewlyReadThisRound 为空且缺少 NoNewSurfaceReason → 本轮即使零发现，也不得增加收敛计数。
• 重复阅读已审查范围不能替代覆盖增量；只能作为高风险回归、修复点回归、抽样或新证据复核的补充。
• PCV 必须按 audit-session/Owner 的完整有效计划核验最近 R 次有效零发现（默认3，完整有效 narrow-2 为2；full/security/release为3）的 ReviewCoverageDelta，确认不是用同一轮或同一批文件的机械重复凑数。

ReviewDimensionDeltaGate（复审维度增量）

R2 及以后轮次必须维护维度增量，防止复审每次机械重复同一组维度。

计数规则：

• CurrentDimensionFocus 与上一轮不同，且本轮无新增问题 → 可与覆盖增量一起计入有效零发现。
• 维度完全重复但有有效 RepeatedDimensionReason，且本轮无新增问题 → 可计入有效零发现。
• 维度完全重复且缺少有效理由 → 本轮即使零发现，也不得增加收敛计数。
• 维度增量不要求每轮增加维度数量；它要求本轮说明“为什么这个审查视角仍然必要”。

OmissionOnlyReviewGate（遗漏专审）

当用户要求只审查遗漏、只列未吸纳清单或排除已吸纳/没必要项时，R1 起必须切换为 omission-only：

• ReviewedSet 需区分“此前已覆盖 / 本轮新增覆盖 / 已吸纳或排除”。
• UnreviewedRelatedSet 优先纳入此前未扫的 data 台账、消费者链、部署副本、报告和记忆索引。
• 最终发现只保留此前未覆盖且仍有处理价值的遗漏项；重复项、已关闭项和无必要项只写排除理由。
• 来源为 data 吸纳时，同步执行 WorkspaceDataAbsorptionScopeGate，覆盖 .devcodex/*/data/ 全命名空间。
• 同步执行 ReviewDimensionDeltaGate，优先补此前未覆盖的维度；若仍复用同一维度，必须给出高风险回归、新证据或抽样理由。

ReviewFindingIntakeGate（审查发现 intake 分流）

当审查对象或输入材料包含外部审查报告、AI review finding、audit issue 或代码评审发现时，R1 起必须执行审查发现 intake 分流：

• AuditReportIsSignalNotEvidence：报告只是线索；每条 finding 必须有本地代码、文档、测试或运行复现证据，无法复现标 not-reproduced / needs-evidence。
• IntentionalDesignClassification：判断是否为 intentional design、兼容设计、性能取舍或产品策略，并记录依据、消费者影响和文档/测试承托。
• UserDecisionBeforeMutation：公共契约、兼容风险、设计取舍或文档/实现二选一，必须输出用户确认点，不得直接推进源码修改。
• DocsImplementationDriftAttribution：文档与实现不一致时，先判断文档是否合理、是否代表产品目标或历史承诺，再归因到代码、文档、示例或测试。
• TestCoverageGapOnly：仅测试浅、回归缺失或证据不足时，审查结论优先指向补测试/复现/验证证据，不直接要求 runtime mutation。

自我审视机制（Meta-Audit）

🔴 触发条件：R2 及以后轮次发现新问题时，必须在输出问题清单前先执行自我审视，分析上一轮为何漏掉该问题。

四轴盲点分析（每轮新发现后逐轴检查）

执行流程

textCopy code
R2+ 发现新问题
  ↓
步骤一：实证定位（必须）
  - 读取对应文件/代码，确认问题确实存在（不得依赖记忆、推断或会话上下文中的注入内容——上下文可能是旧版）
  - ⚠️ 修复前必须从磁盘重新读取目标文件；会话开始时注入的 Instructions 内容可能早于本次修改，以磁盘文件为准
  - 记录：文件路径 + 行号/章节 + 问题原文
  ↓
步骤二：三列验证（必须）
  - 合理性：为什么这是问题？依据是哪条规范？
  - 可实施性：修复是否有明确方案？前置条件满足？
  - 收益：修复后带来什么改善？
  ↓
步骤三：对话输出感知（必须）
  - 在对话中输出上述验证结果，让用户可见
  - ⚠️ 禁止跳过此步骤直接修复
  ↓
步骤四：决定交接状态
  - 所有文件类型先判定是否阻断当前审查结论
    - 阻断项 → 保持 open/pending，停止受影响结论并提出显式用户确认
    - 非阻断项 → 写入适当台账/问题池，标记 recorded/transferred
  - 用户显式授权后才可启动独立 fix/self-fix；独立工作流必须自行执行 CP/ExecutionContract
  - audit 内禁止 source mutation、`git add`、commit 或把修复建议直接标为 fixed
  ↓
步骤五：M1~M4 盲点分析
  - 对每个新问题逐轴过一遍 M1~M4，确定盲点类型（可多轴）
  - 先归一为 `record.audit-gap`，输出规范化意图、置信度、依据和目标台账，再追加到 data/gap-registry.md（格式：GAP-NNN，含盲点轴编号）
  ↓
下一轮带着已知盲点类型定向补查

🔴 禁止"未分流即修"：步骤一（实证定位）、步骤三（对话感知）和步骤四（阻断/非阻断分流）不可跳过。未经实证的问题不得执行修复；未在对话输出的验证结果，用户无法感知和纠错。

自我审视输出格式

textCopy code
---
🔍 自我审视（R{N}）
- 新发现 N 个问题
- 【实证定位】[文件路径:行号] — 问题原文
- 【三列验证】
  - 合理性：[依据规范/条目]
  - 可实施性：[修复方案简述，前置条件]
  - 收益：[改善效果]
- 【盲点分析】M{X} [盲点类型]：[上一轮漏掉的原因] → 已记录 GAP-NNN
- 【交接决定】阻断项等待用户授权 / 非阻断项入池 / 已转独立 fix/self-fix（原因：[影响范围/歧义说明]）
- 下一轮定向补查：[文件/层次/关键词]
---

ℹ️ 自我审视输出在问题清单之后立即输出；任何文件类型的修复都必须等待显式用户授权并进入独立 fix/self-fix，audit 不继承写入权限。

收敛后汇总验证（PCV）

🔴 强制步骤：收敛后必须执行 PCV，方可输出最终报告。

DF 数据文件轻量检查（审查 DevCodex plugin 时执行）

⚠️ 触发条件：仅当审查目标为 DevCodex plugin 文件（instructions/ · skills/ · prompts/ · agents/ · RULES.md）时，在 CRS 步骤中顺带对 data/ 文件执行 DF 检查。

ℹ️ 不适用 D1~D25：data/*.md 是运营数据文件（violations/pending-fixes/gap-registry/process-improvements），不是规范定义文件，使用轻量 DF 3项检查（不走全维度审查）。

DF 检查项

修复方式

• DF 检查发现问题 → Pending 级：记录 PF，不自动修复（运营数据人工决定关闭/合并策略）
• 不触发 self-fix 元循环（data/ 不在 plugin scope 内）

Token 预算管理

• 单次审查 Token 不足时，启用分会话模式
• 分会话模式：每轮只审查指定维度批次，结果通过 memory/SKILL.md 写入 .devcodex/.memory/
• 下次会话通过 memory/SKILL.md 恢复进度

Git 边界（audit 不暂存、不提交）

🔴 audit 不执行 git add、commit、push，也不管理修复变更的暂存区。用户授权后的独立 fix/self-fix 按自身 ExecutionContract 和提交授权管理 Git。

流程

textCopy code
audit finding → 记录/交接 → 用户显式授权独立 fix/self-fix
                              ↓
                    修复工作流自行管理 diff/Git
                              ↓
                    audit 只读取新证据并复审

即使用户在 audit 中要求提交，也必须先重新识别为 fix/self-fix/release 类显式动作并执行对应授权门禁；不能把 audit 的只读权限静默升级为 Git 写权限。

输出规范

审查报告：reports/audit/ 目录，含问题清单表格（级别/维度/位置/描述/PCV验证状态/状态）。

PCV验证状态列取值：✅已验证 / ⚠️待验证 / ❌排除（排除项需注明原因）