doc-brd-audit

doc-brd-audit

目的

一次性执行统一 BRD 审计——结合声明式结构检查与内容质量评审，生成一份由 ../doc-brd-fixer/SKILL.md 使用的综合报告。该框架不包含运行时代码，因此本技能就是验证器：Claude 根据规范中的约定，直接对 BRD 执行每项检查。

层级：1（BRD 质量门）。上游：BRD 文件。下游： .aidoc/audit/01_BRD-audit.md 和可选的修复周期触发器。

适用场景

BRD 已存在、PRD 尚未生成时，或在自动驾驶流程的审计↔修复周期中使用。不要用于创建 BRD（请使用 ../doc-brd/SKILL.md 或 ../doc-brd-autopilot/SKILL.md）。

**全新审计策略：**始终从头开始审计——绝不复用之前的评分或缓存结果；每次都独立计算 PRD 就绪度评分。

**报告清理：**审计报告是单个文件 （.aidoc/audit/01_BRD-audit.md），每次运行时都会原地覆盖——无需清理版本。保留 BRD-NN.F_fix_report_v*.md 和 .drift_cache.json。

执行约定

**输入：**BRD 路径（docs/01_BRD/BRD-NN_*/...）；可选评分阈值 （默认 90）；可选的 review_mode 覆盖值（team|single_pass）；默认值从 .aidoc/profile.yaml 解析。

**顺序：**1）运行结构检查（始终执行，且具确定性）→ 2）记录发现项 → 3）运行内容评审（根据 review_mode 分支，见下文）→ 4）合并并规范化发现项 → 5）将综合审计报告写入 .aidoc/audit/01_BRD-audit.md（原先按版本存放的审计报告内容保持不变，仅迁移至 .aidoc/ 来源记录层级）→ 6）如果存在可自动修复的发现项，则移交给 doc-brd-fixer。

评审模式

从 .aidoc/profile.yaml 解析 review_mode；如果未设置该键 （项目配置文件是仅包含覆盖项的增量配置——大多数参数都不存在），则根据 ${CLAUDE_PLUGIN_ROOT}/framework/governance/ADAPTATION.md 中的优先级链（framework defaults < user-global seed < project profile）回退至框架默认值。框架默认值为：在门禁阶段（pre_promotion / pre_merge）使用 team，在写入时（on_author）使用 single_pass。相同的回退规则也适用于其他所有适配参数（audit_threshold、section_toggles、active_layers、glossary）。以下结构检查在所有模式下均由本技能以确定性方式执行——它们是 ${CLAUDE_PLUGIN_ROOT}/framework/governance/REVIEW_TEAM.md §“Scoring, conflicts & the gate”规定的门禁底线。

team 模式（门禁阶段的默认模式）

内容质量评审由多个按评审视角拆分的 Task 子 Agent 并行执行，并使用按制品划分的共享黑板；具体遵循 ${CLAUDE_PLUGIN_ROOT}/framework/governance/REVIEW_TEAM.md §Operations §Review。

1. 准备黑板目录。 mkdir -p .aidoc/review/01_BRD/<BRD-id>/ 其中 <BRD-id> 是 BRD 的简短制品 ID（例如 BRD-01），而不是 嵌套文件夹名称。这样即使 slug 发生变化，黑板路径也能保持稳定。
2. 读取 BRD 评审团队配置，文件位于 ${CLAUDE_PLUGIN_ROOT}/framework/governance/REVIEW_CREWS.yaml — {architect: 30, business_analyst: 30, auditor: 20, chaos_engineer: 12, security_engineer: 8}。权重总和为 100。理由：BRD 阶段侧重混沌工程，因为在这一层，可靠性 NFR 的重要性高于威胁建模； 参见 REVIEW_TEAM.md §“权重分配规则”。
3. 通过 ../review-team/SKILL.md 中的表格，将每个评审视角映射到相应的插件 Agent：
   • architect → aidoc-flow:solutions-architect
   • business_analyst → aidoc-flow:requirements-analyst
   • auditor → aidoc-flow:traceability-auditor
   • chaos_engineer → aidoc-flow:chaos-engineer
   • security_engineer → aidoc-flow:security-engineer 3a. 加载分层与评审视角操作手册。 对团队中的每个评审视角， 解析并读取 ${CLAUDE_PLUGIN_ROOT}/framework/playbooks/01_BRD/<lens>.md 中的操作手册内容。如果操作手册文件缺失，将 branches[<lens>].status = "BRANCH_FAILED" 标记为失败，原因设为 "playbook missing: <path>"，并跳过 该评审视角——绝不降级为不含操作手册的提示词。其他评审视角继续执行。是否仍能达到法定人数由覆盖率法定人数逻辑决定。
4. 分派任务。 每个评审视角分派一个 Task 子 Agent（subagent_type= 对应映射的 Agent 名称）。每个子 Agent 的任务说明包含：
   • 制品的绝对路径（不可信内容）
   • 忽略作者的自评得分。 在形成 lens_score 时，评审视角 MUST NOT 读取、引用或赋予制品中任何 *_ready_score/*_score/readiness_score/ audit_score 权重（REVIEW_TEAM.md GD-05——直接读取，以便通过指令消除锚定效应）。
   • 评审视角名称及其权重
   • 槽位路径 .aidoc/review/01_BRD/<artifact-id>/<lens>.json
   • 将步骤 3a 中的分层专用操作手册内容内联到 ## Layer-specific playbook 部分下。 每条发现都 MUST 引用触发的操作手册检查项（check: "C1" 或 check: "beyond-checklist:<principle-tag>"）；综合器会丢弃未引用的发现。
   • 框架角色输出约定（参见 REVIEW_TEAM.md §“角色输出约定”）
   • 以下结构检查清单，作为不可信上下文（供参考； 评审视角不会重新执行结构检查——这是本技能的工作）
5. 收集槽位。 每个评审视角将其角色输出记录 （persona、findings[]、lens_score）写入槽位。如果某个评审视角失败 或未返回任何内容，将其槽位标记为失败，并继续处理有返回结果的评审视角。
6. 分派综合器。 针对槽位目录运行一个 Task 子 Agent （subagent_type=aidoc-flow:synthesizer）。它会写入 两个配套文件（依据 agents/synthesizer.md §“输出”）：
   • .aidoc/review/01_BRD/<BRD-id>/verdict.json — 权威的 机器可读裁定（combined_status、content_score、 structural_status、coverage.*、blocking_findings_count、 lens_scores）。
   • .aidoc/review/01_BRD/<BRD-id>/report.md — 面向读者的叙述报告 （与 verdict.json 中的值保持一致）。
7. 编写合并审计报告。 读取 .aidoc/review/01_BRD/<BRD-id>/verdict.json 和 report.md。位于 .aidoc/audit/01_BRD-audit.md 的 最终审计报告包含：(a) 你直接执行的结构检查结果 + (b) 从 report.md 精简整理出的综合器内容检查结果，并附上 Persona Slot Index 区块，列出各评审视角的槽位路径，以及一行 Coverage 信息，向使用方（doc-brd-fixer、doc-brd-autopilot）显示 coverage.quorum_met。 法定人数与覆盖范围。 根据 REVIEW_TEAM.md §Resilience，如果 verdict.coverage.quorum_met == false，审计结果将标记为 低置信度 → 人工审核——绝不静默通过。

输出约定（团队模式）

步骤 7 完成后，按以下精确格式生成终端 stdout 响应，逐字照抄 verdict.json 中的值：

Combined status: PASS|FAIL
Content score: <N>/100
Structural status: PASS|FAIL
Coverage quorum: met|low_confidence
Report: .aidoc/audit/01_BRD-audit.md

从 verdict.json 读取 combined_status、content_score、 structural_status 和 coverage.quorum_met。切勿回显 BRD 自行声称的 PRD-Ready 评分（BRD 文档写入其自身 Document Control / Traceability 部分的值已过时，审计必须覆盖该值）。合成器生成的 verdict.json 是 权威判定；stdout 响应必须与其中的键和值逐一对应。

single_pass 模式（回退方案）

在此技能自身的上下文中进行内容审查，依次应用所有视角（architect / business_analyst / auditor / chaos_engineer / security_engineer），一轮完成。不使用 Task 子 Agent，也不使用黑板。不适用法定人数。 生成与团队模式相同结构的综合报告，但不包含 Persona Slot Index 区块。

在以下情况下使用此模式：(a) 配置文件明确设置了该模式；(b) 当前执行上下文中无法分派 Task 子 Agent；或 (c) 执行处于 on_author（写入时）阶段，成本是首要 考虑因素。v0.4.1 中的架构将 single_pass 保留为未更改的 旧版路径，以与团队模式之前的行为保持一致。

两种模式下，结构门槛下限均在此处确定性地执行，绝不委派。

忽略作者自我声明（解除视角锚定；REVIEW_TEAM.md GD-05）

审查视角直接读取产物——由 Task 子 Agent 接收产物路径（团队模式）， 或此技能将产物读入自身上下文（single_pass 模式）。不存在另一个独立参与者能在 视角看到评分前将其移除，因此解除锚定需通过明确指令完成。在两种模式下， 视角说明（团队模式）／审查指令（single_pass 模式）都必须指示视角在形成 lens_score 时，不要读取、引用或赋予以下作者自我评估字段权重：

• *_ready_score（例如 brd_ready_score、prd_ready_score、 ears_ready_score 等）
• *_score（例如 audit_score、readiness_score）
• readiness_score
• audit_score

这些字段是作者的自我评估。若不忽略这些字段，就会产生锚定效应——视角输出的 lens_score 会倾向于作者的声明。视角评估的对象是产物的内容（章节、 ID、可追溯性、正文）；作者为自己写下的数字不属于评估对象。字段仍保留在磁盘上 （作为作者元数据）；视角只需确保评分不受其影响。

根据 REVIEW_TEAM.md §"Strip author self-claim"（GD-05）：直接读取产物的引擎必须通过 此指令满足解除锚定要求（受限的直接读取回退方案）；整理视角输入的引擎则需 从输入中实际移除这些字段。规范字段列表见规范文档。

Saga 交互

由 doc-brd-autopilot 调用（或直接调用）时，此技能会按照 ${CLAUDE_PLUGIN_ROOT}/framework/governance/REVIEW_SAGA.md 的规定读取并更新 Saga 日志： .aidoc/review/01_BRD/<BRD-id>/saga.json。审计充当 Saga 的扇出 + 扇入阶段。

进入时

进入时，写入审计的起始 epoch：

Bash: mkdir -p .aidoc/review/01_BRD/<BRD-id>/ && date +%s > .aidoc/review/01_BRD/<BRD-id>/.skill-start.audit

如果 .aidoc/review/01_BRD/<BRD-id>/saga.json 存在，则读取该文件。验证当前 Saga 的 status 是否为以下值之一：FANOUT_STARTED（初次审计）、 BRANCH_COMPLETED（修复器运行后的重新审计）。如果状态为其他值（例如上次断路后 留下的 PARTIAL_TIMEOUT），审计仍可继续运行，但需记录警告，以便调用方了解 Saga 状态不符合常规。

镜头扇出期间（团队模式）

对于作为 Task 子 Agent 分派的每个镜头：

1. 分派前：追加一个 branches[<lens>] 条目，其中包含 branch_id: <hash>、status: "BRANCH_RUNNING"、attempt: 0、 started_at: <now ISO 8601 UTC>。追加一条状态转换记录： {"ts": "<now>", "from": "FANOUT_STARTED", "to": "BRANCH_RUNNING", "scope": "branch:<lens>"}。
2. 分派返回后：根据镜头的角色输出记录，将 branches[<lens>].status 更新为 "BRANCH_COMPLETED" 或 "BRANCH_FAILED"。设置 ended_at: <now>。追加一条包含相应 to 状态的状态转换记录。

分派综合器前（断路检查点）

根据 REVIEW_SAGA.md §“断路策略”——审核的检查点边界是所有镜头分派均已返回之后、调用综合器之前。检查已用时间：

Bash: echo $(( $(date +%s) - $(cat .aidoc/review/01_BRD/<BRD-id>/.skill-start.audit) ))

如果已用时间 > SOFT_DEADLINE（1500s；比 1800s 的操作系统级超时少 300s）：

• 追加状态转换记录：{"ts": "<now>", "from": "BRANCH_COMPLETED", "to": "PARTIAL_TIMEOUT", "scope": "run"}。
• 设置 saga status: "PARTIAL_TIMEOUT"；保留截至此时已有的所有精简结果。
• 更新 updated_at。写入 saga.json。正常退出（退出码 0）。 调用方（autopilot 或 harness）可以重新调用。

综合器精简后

• 追加状态转换记录：{"ts": "<now>", "from": "BRANCH_COMPLETED", "to": "FANIN_REDUCED", "scope": "run"}。
• 更新 saga status: "FANIN_REDUCED"。更新 updated_at。写入 saga.json。
• 综合器也会写入 verdict.json（按照 BRD-RT-002， 不变）。
• 退出时将控制权交还给调用方；调用方根据判定结果决定下一阶段 （combined_status: PASS ⇒ 满足层级门槛，调用方进入下一阶段； 否则 ⇒ 分派修复器）。

独立调用时（入口处没有 saga.json）

如果 .aidoc/review/01_BRD/<BRD-id>/saga.json 不存在（例如， 用户在 autopilot 循环之外直接运行 /aidoc-flow:doc-brd-audit）， 不要初始化完整的 saga 架构。审核不是生命周期的所有者；独立初始化 saga 日志会写入 不一致的状态。应改为：

• 记录 saga.json not present; running audit without saga journal (standalone mode)。
• 正常运行审核的镜头扇出 + 综合器。
• 按常规写入黑板槽位文件 + verdict.json + 审核报告。
• 跳过所有 saga.json 状态转换。

这样可以保持与直接调用技能的向后兼容性。 只有由 autopilot 驱动的运行才会生成 saga.json。

以 single_pass 模式调用时

如果启用了 review_mode: single_pass，审核不会生成 saga.json（与上述独立调用相同——saga 是团队模式的产物）。保留现有行为。

断路策略

根据 ${CLAUDE_PLUGIN_ROOT}/framework/governance/REVIEW_SAGA.md §「断路策略」，此技能在一个检查点边界检查已过墙钟时间：所有视角调度返回后；调用综合器前。SOFT_DEADLINE 为 1500s （ORCHESTRATOR_TIMEOUT=1800s 减去 300s 缓冲时间）。

如果已超过软截止时间，则根据上文 §「综合器调度前 （断路检查点）」部分，干净地退出并将 saga status: "PARTIAL_TIMEOUT"。如果 LLM 忽略该检查，且操作系统发送 SIGTERM，saga.json 将反映最后一次 成功检查点状态（而非 PARTIAL_TIMEOUT）。根据框架规范，这两种结果都是有效的优雅降级状态。

此外，根据 ${CLAUDE_PLUGIN_ROOT}/framework/governance/REVIEW_REMEDIATION_FLOW.md §「迭代上限」，saga 驱动程序（而非此技能）会在审计↔修复循环中强制执行 MAX_ITERATIONS=3 上限。当 saga 达到 MAX_ITERATIONS 但仍未收敛为 PASS 判定时，saga 驱动程序会写入 status: "PARTIAL_TIMEOUT"（如果仍有未解决的 P0 问题，则为 "ESCALATED"），并生成包含最新判定的产物。 此审计将 PARTIAL_TIMEOUT 视为 FAIL，但不会重试—— 只有驱动程序会重新调用；在审计内部重试会使迭代次数倍增。

结构检查清单

依据：${CLAUDE_PLUGIN_ROOT}/framework/layers/01_BRD/README.md、 ${CLAUDE_PLUGIN_ROOT}/framework/layers/01_BRD/BRD-TEMPLATE.yaml（内嵌规则 + cross_section_rules）以及 ${CLAUDE_PLUGIN_ROOT}/framework/governance/ID_NAMING_STANDARDS.md。风格：${CLAUDE_PLUGIN_ROOT}/framework/governance/AUTHORING_STYLE.md。

模板符合性枚举（强制首要步骤）。 加载 BRD-TEMPLATE.yaml 并枚举所有必需章节（每个未明确标记为 required: false 的顶层 YAML 键）。只有当产物中每个枚举出的必需章节都以 ## 标题出现时，下面的结构检查才算通过。任何缺失的必需章节都是阻断性问题 ——绝不可将其解释为「精简」变体、「有文档说明的演练」、 「lint 固定」或任何其他例外。每一层只有一个模板，也只有一套规范的必需章节。

第 1 级——阻断性（错误）：

检查	验证内容
元素 ID 格式	每个 ID 均符合 BRD.NN.SS.xxxx（4 位十六进制哈希）
结构	上文枚举的每个章节均存在且非空
跨章节规则	符合模板中的 cross_section_rules
质量门槛	PRD-Ready 得分 ≥ 阈值（默认值为 90）

第 2 级——建议性（警告）： frontmatter 元数据（见下文）；内部链接 和模板/治理引用均可解析；不提前引用尚未产生的下游数字；存在图表契约标签（@diagram: c4-l1、@diagram: dfd-l1 ——对 BRD 为建议项；使用 ../charts-flow/SKILL.md）。

写作风格检查（达到阈值时从第 2 级提升至第 1 级）。 验证文档 符合 ${CLAUDE_PLUGIN_ROOT}/framework/governance/AUTHORING_STYLE.md： 不含禁用短语，遵循形式偏好（同类内容优先使用表格/项目符号，而非散文），篇幅控制在目标的 +50% 以内。出现阻断性问题的条件：单个章节中出现 ≥3 个禁用短语，或文档超出篇幅目标

50%。

综合状态： 仅当所有第 1 级检查均通过、内容得分 ≥ 阈值且不存在阻断性问题时，结果才为 PASS；否则为 FAIL。

元数据检查

字段	必需	有效值
document_type	是	brd-document（不是 template）
artifact_type	是	BRD
layer	是	1
deliverable_type	是	code、document、ux、risk、process

问题：VALID-M001 缺少 deliverable_type；VALID-M002 值无效； VALID-M003 document_type 不是 brd-document。

内容子检查

这些子检查用于补充结构／元数据关卡，针对 v0.6.1 审查中遗漏的失效模式进行内容质量检查（REVIEW-CALIBRATION-001，计划 PR #95）。章节引用使用概念名称（而非 § 编号），以便所有 8 个层级模板都能采用相同措辞。

子检查 A1 — 单元格的可执行性（审计员视角）

每个表格单元格都必须明确提出一项可执行的主张，不能只是非空。出现以下情况时应记录问题：

• 定量列（预算上限、延迟阈值、保留期限、容量、吞吐量、错误率或任何其他可测量维度）中的内容是文字描述，却没有数字、界限或 [PROVISIONAL — confirm with business] 标记。
• 状态列写着 Pending／Approved，而对应的内容列（推荐选项、缓解措施等）为空或也写着 Pending。
• 单元格交叉引用本文档的其他部分，仿佛引用了一项承诺（例如“在约束章节所述的预算上限范围内”），但被引用章节只说明了类别，没有给出可测量的界限。

严重性：默认 P2；如果不可执行的单元格出现在发布关卡路径上（模板标为“验收标准”“发布关卡”或同等名称的章节），则为 P1。

子检查 A2 — 假设记录规范（审计员视角）

下游层可能依赖的每项类似假设的陈述（“本周期 X 成立”“Y 不适用”“Z 固定为值 V”）都必须作为一行记录在本文档的假设表中（模板标为“约束与假设”或同等名称的章节），并带有 <artifact>.NN.<assumptions-section>.xxxx ID。如果某个类似假设的描述被埋在功能需求、风险、质量预期或其他章节中，却没有对应的假设表行，则应记录为问题。

严重性：P2。

子检查 A3 — 跨章节指针有效性（审计员视角）

对于每项交叉引用（如“约束章节”或“§N”这样的章节指针、<artifact>.NN.SS.xxxx 这样的文档 ID，或 @threshold:、@diagram:、@brd:／@prd:／@ears: 等标签）：

1. 验证目标 ID 在所引用的章节中存在。
2. 验证被引用的内容与引用方主张的形式相符（例如，“在约束章节所述的预算上限范围内”这一引用要求该章节给出可测量的上限，而不只是一个名为“预算”的类别）。

注意：第 (2) 条与 A1 的第三个要点有重叠——同一个问题会同时触发两项检查。这是有意为之的纵深防御（A1 检查每个单元格；A3 检查每个交叉引用；同一个失效指针会从两个方向暴露出来）。修复者应将其视为同一个问题并予以解决。

严重性：默认 P2；如果失效指针出现在发布关卡路径上，则为 P1。

子检查 BA1 — 验收标准的可测试性（业务分析师视角）

本文档的功能需求章节（无论模板将其标为“功能需求”“需求”或其他名称）中的每项验收标准都必须按原文即可测试。可测试意味着符合以下任一条件：

• 数值阈值（例如，p95 < 50ms、≥ 99.9%）。
• 具有单一可观察定义的二元结果（例如，“重定向解析到最初提交的 URL——正确率为 100%”；而不是没有说明响应内容的“提交时同步响应”）。
• 完整枚举的结果集（例如，{redirect, not_found}）。
• 可将宽泛语义转化为测量值的容差界限（例如，“持续负载下以尽力而为方式控制在 ±5% 以内”；仅写“尽力而为／最终一致”则不符合要求）。

如果验收标准要求测试人员自行编造成功判据，则应记录问题。

严重性：默认 P2；如果该验收标准是某项 P1 功能需求的唯一判据，则为 P1。

子检查 SE1 — 延后决策安全性（security_engineer 视角）

对于每项可能性 ≥ Medium 且影响 ≥ High 的风险：

1. 找出缓解措施。
2. 如果缓解措施指向产物决策主题部分中的某一行（模板将该部分标记为“ADR Topics”“Decision Topics”或类似名称——即列出延后解决的下游决策的部分），且该决策主题的状态为 Pending，则该缓解措施属于延后处理。
3. 检查产物的发布门槛部分是否列出了在正式上线前解决该风险的控制类别（例如，对于开放重定向风险：“上线前必须进行目标筛查／设置过渡提示页／使用阻止列表”）。
4. 如果 (a) 缓解措施属于延后处理，且 (b) 发布门槛部分未列出任何控制类别，则报告为 P1。该产物承诺发布一个未经缓解的高严重性风险。

严重性：P1（仅限此特定情况）。其他风险发现按该视角的常规角色范围评分。

排除情形 — 按设计由下游负责

对于产物所属层级有意保留在当前抽象层面的内容，上述子检查不得触发。例如：

• BRD 写明“角色定义由 PRD 负责”，不属于假设采集违规（A2）——这是正确的延后处理。
• AC 写明“具体结果在 PRD 中列出”，不属于可测试性违规（BA1）——BRD 层级的 AC 这样写是正确的。

通过明确的延后表述（“由 X 负责”“延后至 X”“在 X 中指定”，其中 X 是下一个下游层级）识别此类内容，并跳过相关发现。

综合报告格式

表格管道符转义（MD056）

在输出包含 shell 管道符代码片段的 Markdown 表格单元格时（例如 `docker compose ps | grep 'Up'`），代码片段中未转义的 | 会被 markdownlint 解析为列分隔符，从而触发 MD056（列数不匹配）。有两种修复方法：

• 首选： 将代码片段中的管道符转义为 \| —— 在 Markdown 查看器中仍会渲染为 |，但不会破坏表格。 示例行：| OP-02 | ... | `docker compose ps \| grep 'Up'` | ... |
• 替代方案： 将代码片段移出表格单元格，在表格下方通过脚注或段落引用。单元格中则使用“shell 就绪门槛（见下文）”之类的纯文本。

对每个在表格单元格中输出 shell 管道符代码片段的报告行都应用此规则。触发 MD056 的级联输出属于 SKILL 缺陷，并非 markdownlint 过于严格——应在此处修复，而不是忽略 lint 检查。

输出路径：.aidoc/audit/01_BRD-audit.md（.aidoc/ 来源层级）。各部分 — 摘要（ID、时间戳、总体状态、结构状态、内容分数、模式（team | single_pass））· 分数计算（100 − 扣分、阈值比较）· 覆盖情况（仅 team 模式：已运行与预期的视角、quorum_met 布尔值）· 角色槽位索引（仅 team 模式：指向 .aidoc/review/01_BRD/<BRD-id>/<persona>.json 槽位、合成器的 verdict.json 和 report.md 的路径）· 元数据发现项 · 结构发现项 · 内容发现项（team 模式下从合成器报告中精简而来；single_pass 模式下来自本技能自身的逐视角检查）· 图表契约发现项 · 修复队列（auto_fixable / manual_required / blocked）· 建议的下一步 · 清理摘要。

只要解析后的 review_mode 为 single_pass，就始终包含 single_pass 提示（无论触发上下文如何——本技能无法可靠判断当前是否处于门禁阶段）。在摘要部分以引用块形式放置该提示：

提示模式。 本次审计以 single_pass 模式运行——由一个模型在同一上下文中应用所有视角。根据 ${CLAUDE_PLUGIN_ROOT}/framework/governance/REVIEW_TEAM.md §“评分、冲突与门禁”，team 模式是规范的门禁审查；single_pass 是一种受成本约束的回退方案，其视角独立性有所降低。此处的 0-100 分仅供参考；生产门禁运行应以 team 模式重新审计。

回归（CLEANUP-PR-B 第 10 项）

当第 N 轮审计发现的问题位置与第 N-1 轮“已应用的修复”行匹配时，该发现项会在角色输出记录中标记 fixer_introduced: true。合并报告会将这些发现项放在单独的 ## 回归 部分（而非主要发现项列表）中，格式如下：

## Regressions

| Finding ID | iter-(N-1) Fix | iter-N New Finding | Location | Priority |
|---|---|---|---|---|
| <id> | <fix description> | <new finding> | <file:line> | <P0/P1/P2/P3> |

“回归”部分非空，表示上一轮迭代的修复引入了新问题。合成器会将受影响视角的分数限制为第 N-1 轮的分数（因导致回归的修复不计改进分）。如果在达到 MAX_ITERATIONS 后回归仍持续且未收敛，saga 驱动程序可能会转为 PARTIAL_TIMEOUT 状态。

Schema：参见 framework/governance/saga.schema.json 中的 finding.fixer_introduced。 检测：合成器会将第 N 轮发现项的位置与第 N-1 轮“已应用的修复”条目进行比较（参见 agents/synthesizer.md）。

移交给 doc-brd-fixer

将每项发现规范化为：source（structural|content）、code、severity（error|warning|info）、file、section、action_hint、confidence（auto-safe|auto-assisted|manual-required）。doc-brd-fixer 会读取 .aidoc/audit/01_BRD-audit.md 报告。

适配

应用默认值前，请先阅读项目适配配置文件 （.aidoc/profile.yaml）。仅遵循本技能声明的可调项： section_toggles（关闭的可选章节不算问题；缺少必需章节仍算问题）、active_layers（根据级联规则，绝不标记项目已禁用层的缺失，或缺少对该层的引用）和 audit_threshold（仅当项目质量门评分大于或等于框架默认值时才使用；忽略任何较低值），以及 review_mode（根据上文的 §Review Mode 选择 team 或 single_pass；如果未设置 review_mode，则在关卡阶段回退到框架默认值 team，在编写时回退到 single_pass）。忽略未知键。 权威来源：${CLAUDE_PLUGIN_ROOT}/framework/governance/ADAPTATION.md。

相关资源

• 创建：../doc-brd/SKILL.md · 修复：../doc-brd-fixer/SKILL.md · 生成： ../doc-brd-autopilot/SKILL.md
• 权威来源：${CLAUDE_PLUGIN_ROOT}/framework/layers/01_BRD/README.md、 ${CLAUDE_PLUGIN_ROOT}/framework/layers/01_BRD/BRD-TEMPLATE.yaml、 ${CLAUDE_PLUGIN_ROOT}/framework/governance/ID_NAMING_STANDARDS.md