doc-prd-audit

doc-prd-audit

用途

一次执行统一的 PRD 审核——将声明式结构检查与内容质量审查结合起来，生成一份供 ../doc-prd-fixer/SKILL.md 使用的综合报告。该框架不包含运行时代码，因此 此技能就是验证器：Claude 会依据规范契约，直接对 PRD 执行每项检查。

层级：2（PRD 质量门禁）。上游：PRD 文件。下游： .aidoc/audit/02_PRD-audit.md 和可选的修复周期触发器。

适用场景

在 PRD 存在之后、生成 EARS 之前使用，或在自动驾驶的审核↔修复周期中使用。 不要用于创建 PRD（请使用 ../doc-prd/SKILL.md 或 ../doc-prd-autopilot/SKILL.md）。

**全新审核策略：**始终从头开始审核——不得复用先前的评分或缓存结果；每次运行都要独立计算 EARS 就绪度评分。

**报告清理：**审核报告是一个单独的文件 （.aidoc/audit/02_PRD-audit.md），每次运行都会原位覆盖——无需清理版本文件。 保留 PRD-NN.F_fix_report_v*.md 和 .drift_cache.json。

执行约定

**输入：**PRD 路径（docs/02_PRD/PRD-NN_*/...）；可选评分阈值 （默认值为 90）。

**顺序：**1）运行结构检查 → 2）记录发现项 → 3）运行内容审查 → 4）合并并规范化发现项 → 5）写入 .aidoc/audit/02_PRD-audit.md → 6）若存在可自动修复的发现项，则移交给 doc-prd-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 §“评分、 冲突与门禁”所规定的门禁底线。

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

内容质量审查由针对每个视角的 Task 子 Agent 并行执行，并使用针对每项工件的黑板，具体参见 ${CLAUDE_PLUGIN_ROOT}/framework/governance/REVIEW_TEAM.md §Operations §Review。

1. 准备黑板。 mkdir -p .aidoc/review/02_PRD/<PRD-id>/ 其中 <PRD-id> 是 PRD 的短制品 ID（例如 PRD-01），而不是 嵌套文件夹名称。这样即使 slug 发生变化，黑板路径也能保持稳定。
2. 读取 PRD 评审组，路径为 ${CLAUDE_PLUGIN_ROOT}/framework/governance/REVIEW_CREWS.yaml — {product_owner: 30, architect: 25, tech_lead: 20, chaos_engineer: 8, security_engineer: 7, auditor: 10}。权重合计为 100。理由：chaos / security 按 8 / 7 拆分——PRD 同时包含可靠性和安全 NFR；两者都不占主导； 参见 REVIEW_TEAM.md §“权重分配规则”。
3. 通过下表将每个视角映射到对应的插件 Agent，该表位于 ../review-team/SKILL.md：
   • product_owner → aidoc-flow:requirements-analyst
   • architect → aidoc-flow:solutions-architect
   • tech_lead → aidoc-flow:solutions-architect
   • chaos_engineer → aidoc-flow:chaos-engineer
   • security_engineer → aidoc-flow:security-engineer
   • auditor → aidoc-flow:traceability-auditor 3a. 加载层级与视角手册。 对评审组中的每个视角， 解析并读取路径 ${CLAUDE_PLUGIN_ROOT}/framework/playbooks/02_PRD/<lens>.md 中的手册内容。 如果手册文件缺失，将 branches[<lens>].status = "BRANCH_FAILED" 标记为失败，原因设为 "playbook missing: <path>"，并跳过 此视角——不得降级为不带手册的提示词。其他视角继续执行。是否仍能 达到法定覆盖数由覆盖法定数逻辑决定。
4. 分派任务。 为每个视角分派一个 Task 子 Agent（subagent_type= 对应的映射 Agent 名称）。每个子 Agent 的任务说明包含：
   • 制品的绝对路径（不可信内容）
   • 忽略作者的自评得分。 在形成 lens_score 时，该视角不得 读取、引用或加权制品中的任何 *_ready_score/*_score/readiness_score/ audit_score（REVIEW_TEAM.md GD-05——直接读取，因此通过指令解除锚定）。
   • 视角名称及其权重
   • 槽位路径 .aidoc/review/02_PRD/<artifact-id>/<lens>.json
   • 步骤 3a 中的层级专用手册内容，内嵌在 ## Layer-specific playbook 小节下。 在每条发现中，视角必须注明 触发了哪项手册检查（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/02_PRD/<PRD-id>/verdict.json — 权威的 机器可读判定结果（combined_status、content_score、 structural_status、coverage.*、blocking_findings_count、 lens_scores）。
   • .aidoc/review/02_PRD/<PRD-id>/report.md — 面向读者的叙述 （与 verdict.json 中的值一致）。
7. 撰写综合审计报告。 读取 .aidoc/review/02_PRD/<PRD-id>/verdict.json 和 report.md。最终审计 报告 .aidoc/audit/02_PRD-audit.md 包含：(a) 你直接运行的结构检查发现 + (b) 从 report.md 精简整理的综合器内容发现， 并附上一个 Persona Slot Index 区块，列出各视角的槽位路径，以及一行 Coverage，显示供使用方（doc-prd-fixer、 doc-prd-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/02_PRD-audit.md

从 verdict.json 读取 combined_status、content_score、structural_status 和 coverage.quorum_met。切勿回显 PRD 自行声明的 PRD-Ready 分数（PRD 文档写入其自身 Document Control / Traceability 部分的值是过时数据，审计必须覆盖它）。synthesizer 的 verdict.json 是权威判定；你的 stdout 响应必须逐项对应其中的键和值。

single_pass 模式（回退）

在此技能自身的上下文中执行内容审查，依次应用每个视角（product_owner / architect / tech_lead / chaos_engineer / security_engineer / auditor），一次完成。不使用 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-prd-autopilot 调用时（或直接调用时），此技能会根据 ${CLAUDE_PLUGIN_ROOT}/framework/governance/REVIEW_SAGA.md 读取并更新 saga 日志 .aidoc/review/02_PRD/<PRD-id>/saga.json。审计充当 saga 的扇出 + 扇入阶段。

进入时

进入时，写入审计的起始纪元时间：

Bash: mkdir -p .aidoc/review/02_PRD/<PRD-id>/ && date +%s > .aidoc/review/02_PRD/<PRD-id>/.skill-start.audit

如果 .aidoc/review/02_PRD/<PRD-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/02_PRD/<PRD-id>/.skill-start.audit) ))

如果已用时间 > SOFT_DEADLINE（1500s；比 1800s 的 OS 级超时提前 300s）：

• 追加状态转换：{"ts": "<now>", "from": "BRANCH_COMPLETED", "to": "PARTIAL_TIMEOUT", "scope": "run"}。
• 将 saga 的 status 设为 "PARTIAL_TIMEOUT"；保留截至此时已生成的 精简结果。
• 更新 updated_at。写入 saga.json。正常退出（exit 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， 不作更改）。
• 退出时将控制权交还调用方；调用方根据 verdict 决定下一阶段 （combined_status: PASS ⇒ 满足该层门槛，调用方推进；否则 ⇒ 分派修复器）。

独立调用时（进入时不存在 saga.json）

如果 .aidoc/review/02_PRD/<PRD-id>/saga.json 不存在（例如，用户在 autopilot 循环之外直接运行 /aidoc-flow:doc-prd-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 驱动程序（而非此技能）会在 audit↔fix 循环中强制执行 MAX_ITERATIONS=3 上限。当 saga 达到 MAX_ITERATIONS，但仍未收敛到 PASS 判定时，saga 驱动程序会写入 status: "PARTIAL_TIMEOUT"（如果仍有未解决的 P0 问题，则写入 "ESCALATED"），并生成包含最新判定的产物。本次审计将 PARTIAL_TIMEOUT 视为 FAIL，但不会重试——只有驱动程序可以再次调用；在审计内部重试会导致迭代次数倍增。

结构检查清单

权威依据：${CLAUDE_PLUGIN_ROOT}/framework/layers/02_PRD/README.md、 ${CLAUDE_PLUGIN_ROOT}/framework/layers/02_PRD/PRD-TEMPLATE.yaml（内嵌规则），以及 ${CLAUDE_PLUGIN_ROOT}/framework/governance/ID_NAMING_STANDARDS.md。风格指南： ${CLAUDE_PLUGIN_ROOT}/framework/governance/AUTHORING_STYLE.md。

模板符合性枚举（必须作为第一步执行）。 加载 PRD-TEMPLATE.yaml，枚举每个必需章节（每个未明确标记为 required: false 的顶层 YAML 键）。只有当产物中每个已枚举的必需章节都以 ## 标题的形式出现时，下方的 Structure 检查才算通过。任何缺失的必需章节都是阻断性问题 ——绝不能将其合理化为“精简”变体、“文档化演练”、 “lint 固定”或任何其他例外。每个层级只有一个模板，也只有一套规范的必需章节集合。

Tier 1——阻断性（错误）：

检查项	验证内容
元素 ID 格式	每个 ID 都符合 PRD.NN.SS.xxxx 格式（4 位十六进制哈希）；SS = 所属章节
结构	上方枚举的每个章节都存在且内容非空
累积标签	存在 @brd: 标签，且标签指向现有 BRD 元素
面向客户的内容	§10 在 ≥3 个类别中包含实质内容（不是占位符）
质量门槛	EARS-Ready 分数 ≥ 阈值（默认 90）

Tier 2——建议性（警告）： frontmatter 元数据（见下文）；§8 包含 PRD 级摘要及层级分离说明；内部链接和模板／治理引用有效；未引用尚不存在的 ADR 编号； 各章节之间以及与 BRD 来源中的阈值保持一致；存在图表契约标签（@diagram: c4-l2、@diagram: dfd-l2、@diagram: sequence-sync 并带有 alt/else——使用 ../charts-flow/SKILL.md）。

写作风格检查（达到阈值时由 Tier 2 升为 Tier 1）。 验证文档是否符合 ${CLAUDE_PLUGIN_ROOT}/framework/governance/AUTHORING_STYLE.md： 不含禁用短语，遵循格式偏好（内容同质时优先使用表格／项目符号，而非散文），篇幅符合目标，超出幅度不超过 50%。当某一章节出现 ≥3 个禁用短语，或文档超过篇幅目标 >50% 时，将其升级为阻断性问题。

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

元数据检查

字段	必填	有效值
document_type	是	prd-document（不是 template）
artifact_type	是	PRD
layer	是	2
deliverable_type	是	code、document、ux、risk、process

发现：VALID-M001 缺少 deliverable_type；VALID-M002 值无效； VALID-M003 document_type 不是 prd-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”、制品 ID，如 <artifact>.NN.SS.xxxx，或 @threshold:、@diagram:、 @brd: / @prd: / @ears: 等标签）：

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

注意：第 (2) 条与 A1 的第三个要点重叠——两者会针对同一项发现触发。 这是有意的纵深防御（A1 检查每个单元格；A3 检查每个交叉引用； 同一个失效指针会从两个方向显现）。修复人员会将其作为一项发现处理。

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

子检查 BA1 — 验收标准可测试性（business_analyst 视角）

工件功能需求部分（无论模板如何标注，例如 “Functional Requirements”、“Requirements” 等）中的每条验收标准（AC）都必须按原文可测试。可测试意味着符合以下任一条件：

• 数值阈值（例如，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）——这是正确的延后处理。
• 验收标准写明“具体结果在 PRD 中枚举”，不属于可测试性违规（BA1）——该 BRD 层级的验收标准是正确的。

识别明确的延后表述（“由 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/02_PRD-audit.md，包含以下部分 — 摘要（ID、时间戳、整体状态、结构状态、内容评分）· 评分计算（100 − 扣分，与阈值比较）· 元数据问题 · 结构问题 · 内容问题 · 图表约定问题 · 修复队列（auto_fixable / manual_required / blocked）· 建议的下一步 · 清理摘要。

回归（CLEANUP-PR-B item 10）

当第 N 轮审计发现的问题位置与第 N-1 轮的某条“已应用的修复”记录匹配时，该问题会在 persona-output 记录中带有 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 状态。

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

移交给 doc-prd-fixer

将每项发现规范为：source（structural|content）、code、severity（error|warning|info）、file、section、action_hint、confidence（auto-safe|auto-assisted|manual-required）。doc-prd-fixer 使用 .aidoc/audit/02_PRD-audit.md 报告。

适配

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

相关资源

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