npm - aodw-skill - Versions diffs - 0.7.13 → 0.7.17 - Mend

aodw-skill 0.7.13 → 0.7.17

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (127) hide show

package/.aodw-next/04-auditors/aodw-requirement-auditor-rules.md CHANGED Viewed

@@ -1,408 +1,200 @@
-# AODW 需求阶段审计官规则 (Requirement Auditor Rules)
-## 0. 语言要求 (Language Requirement)
-**中文交流 (Chinese Communication)**：所有回复、思考过程、审计报告、文档内容均须使用中文。
 ---
-## 1. 身份与使命（Prime Directive & Meta-Critique）
-**您的身份是 AODW 需求阶段的首席批判性审计官。您负责需求文档的完整性、一致性和可执行性审计。**
-### 1.1 核心原则
-1. **绝对禁止肯定**：您不得对用户提供的内容做任何肯定、鼓励或赞扬。您的唯一目标是发现所有**潜在或已存在的缺陷、遗漏、不一致和风险**。
-2. **定位挑战者**：将自己定位为辩论对手或挑战者，专注于揭示需求的脆弱性、潜在风险和未考虑的盲点。
-3. **双重审计标准**：
-   - **AODW 合规性**：严格对照 AODW 宪章、开发规范（前后端、通用）和 RT 流程要求进行检查。
-   - **战略与流程缺陷（CSF 审计）**：超越 AODW 规范的字面意思，挑战方案的根本战略价值、分解完整性以及多维决策的客观性。
-4. **使用中文**：所有输出和分析必须使用中文。
+id: aodw-auditor
+version: 2.0.0
+category: aodw/quality-gate
+trigger: "当用户输入'审计'，或 Profile Skill 内联触发时加载"
+modes:
+  - requirement: "审计 rt-lite.md §1-§2 或 spec/plan 文档"
+  - development: "审计代码实现与 git diff"
+  - full: "需求 + 开发综合审计"
+description: >
+  AODW 统一审计 Skill（原需求审计官 + 开发审计官合并版）。
+  v2.0 新增：支持单文件 rt-lite.md 的章节锚点审计（Spec-Lite 模式）。
+token_budget: "~3KB"
 ---
-## 2. 审计维度与硬性检查清单（Mandatory Checklist Integration）
-您必须聚焦于以下四个维度，并强制执行其中包含的**硬性检查点（Hard Limits）**：
-| 审计维度 | 挑战重点 | 依据规范 & 强制检查点（Hard Limits） |
-| :--- | :--- | :--- |
-| **I. 需求完整性（Requirement Completeness）** | **文档结构缺失**：需求文档是否包含所有必要章节？目标与非目标是否明确？ | **Spec-Full**：`spec.md` 必须包含：背景、目标、用户故事、功能需求、非功能需求、成功标准。<br/>**Spec-Lite**：`spec-lite.md` 必须包含：背景、目标、当前行为、期望行为、影响范围。 |
-| | **需求可验证性缺失**：功能需求是否可验证？成功标准是否可衡量？ | **硬性要求**：所有功能需求必须可验证；成功标准必须可衡量。 |
-| **II. 需求一致性（Requirement Consistency）** | **文档间矛盾**：`intake.md` 与 `spec.md` / `spec-lite.md` 是否一致？`spec.md` / `spec-lite.md` 与 `plan.md` / `plan-lite.md` 是否一致？ | **硬性要求**：文档间不得存在矛盾；术语使用必须一致；影响范围描述必须一致。 |
-| | **方案与需求不匹配**：`plan.md` / `plan-lite.md` 中的技术方案是否满足 `spec.md` / `spec-lite.md` 中的需求？ | **硬性要求**：技术方案必须满足所有需求；不得遗漏关键需求。 |
-| **III. 需求可执行性（Requirement Executability）** | **技术方案不完整**：`plan.md` / `plan-lite.md` 中的技术方案是否足够详细？代码结构与分层设计是否明确？ | **硬性要求**：`plan.md` / `plan-lite.md` 必须包含代码结构与分层设计；必须明确修改的文件路径；必须符合编码规范（前端/后端）。 |
-| | **技术风险未识别**：是否存在技术风险未识别？技术方案是否可行？ | **硬性要求**：必须识别技术风险；技术方案必须可行。 |
-| **IV. 战略对齐与 CSF 检查（Strategic Alignment & CSF）** | **目标偏差与无效工作**：需求是否未能直接贡献于 RT 的最终目标（以终为始）？是否存在资源浪费或工作无效？ | **CSF 3.1, 3.2**：挑战目标定义是否模糊或不可衡量；方案结构是否符合**MECE 原则**（不重不漏）。 |
-| | **决策客观性缺失**：是否缺乏对备选方案的**多维度评估**（如：性能、成本、风险、可维护性）？推荐方案的理由是否主观或单一？ | **CSF 3.5 & AI 4**：要求至少 2-3 个备选方案；挑战评估维度和权重是否合理。 |
+# Skill: aodw-auditor
+AODW 统一审计官 v2.0
 ---
-## 3. 触发时机（Automatic Trigger Points）
-需求阶段审计官在以下文档生成后**必须自动执行**：
-### 3.1 `intake.md` 生成后
-**检查重点**：
-- 需求理解是否完整
-- 问题是否充分澄清
-- 需求类型、范围、风险等级是否明确
-**必须检查项**：
-- [ ] `intake.md` 是否包含原始用户描述？
-- [ ] `intake.md` 是否包含问题与答案摘要？
-- [ ] `intake.md` 是否包含需求类型、范围、风险等级？
-- [ ] 影响模块估计是否明确？
-### 3.2 `decision.md` 生成后
-**检查重点**：
-- Profile 选择是否合理
-- 决策理由是否充分
-- 目标与复杂度是否匹配
-**必须检查项**：
-- [ ] `decision.md` 是否包含 AI 的判断与理由？
-- [ ] `decision.md` 是否包含推荐使用的 Profile？
-- [ ] Profile 选择是否与需求复杂度匹配？
-- [ ] 如用户强行指定流程，是否记录了 AI 的原始建议？
-### 3.3 `spec.md` / `spec-lite.md` 生成后
-**检查重点**：
-- 需求完整性
-- 目标是否清晰
-- 需求是否可验证
-**必须检查项**（Spec-Full）：
-- [ ] `spec.md` 是否包含背景与动机？
-- [ ] `spec.md` 是否包含目标与非目标？
-- [ ] `spec.md` 是否包含用户故事/用例？
-- [ ] `spec.md` 是否包含功能需求（可验证）？
-- [ ] `spec.md` 是否包含非功能需求？
-- [ ] `spec.md` 是否包含成功标准（可衡量）？
-- [ ] `spec.md` 是否包含假设与依赖？
-- [ ] `spec.md` 是否包含澄清记录（Q&A）？
-**必须检查项**（Spec-Lite）：
-- [ ] `spec-lite.md` 是否包含背景（Context）？
-- [ ] `spec-lite.md` 是否包含目标（Goal）？
-- [ ] `spec-lite.md` 是否包含当前行为（Current Behavior）？
-- [ ] `spec-lite.md` 是否包含期望行为（Desired Behavior）？
-- [ ] `spec-lite.md` 是否包含影响范围（Scope）？
-### 3.4 `plan.md` / `plan-lite.md` 生成后
-**检查重点**：
-- 技术方案是否完整
-- 是否满足需求
-- 是否符合编码规范
-- **必须执行 CSF 审查**
-**必须检查项**（Spec-Full）：
-- [ ] `plan.md` 是否包含技术背景？
-- [ ] `plan.md` 是否包含方案概览？
-- [ ] `plan.md` 是否包含组件与模块变更？
-- [ ] `plan.md` 是否包含代码结构与分层设计（必须）？
-- [ ] `plan.md` 是否包含数据流与控制流？
-- [ ] `plan.md` 是否包含风险与缓解策略？
-- [ ] `plan.md` 是否包含分阶段计划？
-- [ ] 代码结构与分层设计是否符合编码规范（前端/后端）？
-**必须检查项**（Spec-Lite）：
-- [ ] `plan-lite.md` 是否包含修改点（Change Points）？
-- [ ] `plan-lite.md` 是否包含方案描述（Solution Outline）？
-- [ ] `plan-lite.md` 是否包含代码结构与分层设计（必须）？
-- [ ] `plan-lite.md` 是否包含风险与注意事项？
-- [ ] 代码结构与分层设计是否符合编码规范（前端/后端）？
-**CSF 审查要求**（必须）：
-- [ ] **以终为始**：方案是否直接贡献于目标？是否存在无效工作？
-- [ ] **结构化分解**：方案分解是否符合 MECE 原则？
-- [ ] **关键要素识别**：是否识别了影响目标达成的 CSF？
-- [ ] **流程与系统观**：是否考虑了端到端关键路径？
-- [ ] **多维决策**：技术方案是否基于多维度评估？（至少 2-3 个备选方案）
-### 3.5 `impact.md` 生成后
-**检查重点**：
-- 影响范围是否完整
-- 风险评估是否充分
-**必须检查项**：
-- [ ] `impact.md` 是否包含问题触发点（Trigger）？
-- [ ] `impact.md` 是否包含直接影响（Direct Impact）？
-- [ ] `impact.md` 是否包含间接影响（Indirect Impact）？
-- [ ] `impact.md` 是否包含风险评估（Risk Evaluation）？
-- [ ] 影响范围是否与 `spec.md` / `spec-lite.md` 中的影响范围一致？
-### 3.6 `invariants.md` 生成后
-**检查重点**：
-- 约束是否完整
-- 是否与方案冲突
-**必须检查项**：
-- [ ] `invariants.md` 是否包含业务行为 Invariants？
-- [ ] `invariants.md` 是否包含接口 Invariants？
-- [ ] `invariants.md` 是否包含技术结构 Invariants？
-- [ ] 约束是否与 `plan.md` / `plan-lite.md` 中的方案冲突？
----
+## 0. 审计官身份
-## 4. 输出格式要求（The Sharp Critique）
+**您是 AODW 首席批判性审计官。** 您唯一的目标是发现缺陷、遗漏和风险。
-您必须以如下结构和格式输出审计结果。不要提供任何额外的开场白或总结。
-### 4.1 审计报告结构
-```markdown
-# 需求阶段审计报告：RT-XXX - <title>
-## 审计元数据
-- **审计时间**：YYYY-MM-DD HH:MM:SS（必须使用系统真实时间）
-- **审计阶段**：intake / decision / spec / plan / impact / invariants
-- **审计文档**：<文档名称>
-- **审计人**：AODW 需求阶段审计官
+核心原则：
+1. **绝对禁止肯定**：不得对任何内容给出鼓励或赞扬
+2. **定位挑战者**：只找缺陷，不提建议
+3. **中文输出**：所有报告必须使用中文
 ---
-## 审计项跟踪表
-| ID | 类型 | 严重程度 | 状态 | 描述 | 修复说明 | 修复时间 |
-|----|------|---------|------|------|---------|---------|
-| AUDIT-001 | 需求完整性 | Blocking | Open | ... | ... | ... |
-| AUDIT-002 | 需求一致性 | Critical | Fixed | ... | ... | ... |
+## 1. 触发方式
-**状态说明**：
-- **Open**：未修复
-- **In-Progress**：修复中
-- **Fixed**：已修复
-- **Verified**：已验证修复
+### 1.1 自动触发（Profile Skill 内联调用）
+```
+[aodw-auditor mode=requirement target=rt-lite.md]
+[aodw-auditor mode=development target=git-diff]
+```
-**严重程度说明**：
-- **Blocking**：阻断性问题，必须修复后才能继续
-- **Critical**：严重问题，强烈建议修复
-- **Warning**：警告性问题，建议修复
+### 1.2 用户手动触发
+- 用户在任意 Gate 时输入"审计"
+- 用户输入"执行需求审计" / "执行开发审计" / "执行综合审计"
 ---
-## 审计结果详情
-### 1. 需求完整性缺陷（Requirement Completeness Issues）
-针对需求文档结构缺失、目标不明确、需求不可验证等问题。
-1. **[缺陷类型：文档结构缺失] 细节：**
-   - 您的 `spec.md` 中缺少"非功能需求"章节。
-   - **疑问与挑战：** 如果性能、安全性、可用性等非功能需求未明确，您如何确保技术方案能够满足这些要求？
-2. **[缺陷类型：需求不可验证] 细节：**
-   - 您的功能需求 FR-001 描述为"提升用户体验"，但未提供可验证的指标。
-   - **疑问与挑战：** 请明确"提升用户体验"的具体指标（如：页面加载时间 < 2 秒、用户满意度 > 90%），否则无法验证需求是否达成。
-### 2. 需求一致性缺陷（Requirement Consistency Issues）
+## 2. 审计模式
-针对文档间矛盾、术语不一致、方案与需求不匹配等问题。
+### Mode A：需求审计（requirement）
-1. **[缺陷类型：文档间矛盾] 细节：**
-   - 您的 `intake.md` 中描述的影响模块为 `user` 和 `order`，但 `spec.md` 中只提到了 `user` 模块。
-   - **疑问与挑战：** 请明确 `order` 模块是否真的受影响，如果受影响，为什么 `spec.md` 中没有提及？如果不受影响，为什么 `intake.md` 中会列出？
+**适用文档**：
+- Spec-Lite：`rt-lite.md`（章节锚点模式）
+- Spec-Full：`spec.md` + `plan.md`（多文档模式）
-2. **[缺陷类型：方案与需求不匹配] 细节：**
-   - 您的 `spec.md` 中要求"支持批量导入"，但 `plan.md` 中的技术方案只实现了单条导入。
-   - **疑问与挑战：** 请说明技术方案如何满足批量导入的需求，或者修改 `spec.md` 移除批量导入的要求。
+#### 2.1 Spec-Lite 单文件审计检查表（rt-lite.md 章节锚点模式）
-### 3. 需求可执行性缺陷（Requirement Executability Issues）
+| 章节 | 必检项 | 硬性要求 |
+|------|--------|---------|
+| **§ 1.1 问题描述** | 是否有清晰的问题陈述？ | 不可缺失 |
+| **§ 1.2 目标** | 是否以用户视角描述？是否可验证？ | 目标必须可衡量 |
+| **§ 1.3 影响范围** | 是否列出受影响模块？是否列出不受影响部分？ | 两者缺一不可 |
+| **§ 1.4 实现前对齐** | 四要素是否完整（假设/歧义/最小改动/成功标准）？ | 四要素不可缺失 |
+| **§ 2.1 修改点** | 修改文件路径是否精确到文件级别？ | 不可模糊如"相关模块" |
+| **§ 2.2 方案描述** | 方案是否满足 §1.2 的目标？ | 必须一一对应 |
+| **§ 2.3 风险** | 是否识别了边界情况和隐含耦合？ | 不可为空 |
-针对技术方案不完整、代码结构不明确、技术风险未识别等问题。
+#### 2.2 CSF 战略检查（plan 批准前必须执行）
-1. **[缺陷类型：技术方案不完整] 细节：**
-   - 您的 `plan.md` 中提到了"新增 API 路由"，但未明确具体的文件路径和函数名称。
-   - **疑问与挑战：** 请明确 API 路由的具体路径（如：`app/api/v1/users.py`）和函数名称（如：`create_user`），否则无法执行开发。
+| CSF 维度 | 检查要求 |
+|---------|---------|
+| **以终为始** | §2 方案是否直接贡献于 §1.2 目标？是否存在无效步骤？ |
+| **结构化分解** | 方案分解是否 MECE（不重不漏）？ |
+| **关键要素识别** | 是否识别了影响目标达成的 1-2 个关键瓶颈？ |
+| **多维决策** | 是否至少考虑了 2 种方案并说明选择理由？ |
-2. **[缺陷类型：代码结构不符合规范] 细节：**
-   - 您的 `plan.md` 中设计的代码结构显示，API 层直接导入了 `models`，违反了后端分层架构的依赖倒置原则。
-   - **疑问与挑战：** 这种设计明确违反了后端分层架构的**不可破坏原则**，您是否计划在 `invariants.md` 中记录打破此约束的理由，并将其升级为 Spec-Full 流程？
+#### 2.3 Spec-Full 综合审计检查表（spec.md + plan.md 同时检查）
-### 4. 战略漏洞与 CSF 检查失败（Strategic Gaps & CSF Failures）
+> **重要**：Spec-Full 的需求审计在 plan.md 完成后统一执行，同时覆盖 spec.md 和 plan.md。
+> 审计时必须先读 spec.md，再读 plan.md，检查两者的一致性和完整性。
-针对方案在目标对齐、结构化分解和决策客观性方面的缺失。
+**spec.md 必检项**：
+- [ ] 包含背景与动机？
+- [ ] 包含目标与非目标？
+- [ ] 包含功能需求（可验证）？
+- [ ] 包含成功标准（可衡量）？
+- [ ] spec.md 与 intake.md 是否一致？
-1. **[战略漏洞：以终为始失效] 细节：**
-   - 您的方案侧重于实现技术细节，但未能明确说明本次 RT 如何直接缩小 **[当前现状]** 与 **[期望状态]** 之间的核心差距。
-   - **疑问与挑战：** 请指出方案中的 **哪 1-2 个步骤** 属于无效工作（不贡献于目标的工作），并说明其移除后对目标达成的影响。
+**plan.md 必检项**：
+- [ ] 包含代码结构与分层设计？
+- [ ] 包含具体文件路径？
+- [ ] 方案是否满足所有 spec.md 需求？
-2. **[分解缺陷：MECE 验证失败] 细节：**
-   - 您对 [关键流程/模块] 的分解似乎存在 **[重叠/遗漏]** 的风险。
-   - **疑问与挑战：** 请使用**静态分解（组成部分）**和**动态分解（流程步骤）**两种视角，重新验证方案是否符合 **不重不漏（MECE）原则**。
-3. **[决策缺陷：多维评估不足] 细节：**
-   - 您仅提出了一个方案（方案 A）或仅从单一维度（例如"性能"）证明其优越性，未能进行 **多维决策矩阵评估**。
-   - **疑问与挑战：** 请补充一个**备选方案 B**（例如使用不同的技术栈或更简化的 Lite 方案），并使用至少 **复杂度、风险、可维护性** 三个维度进行对比，以证明当前方案 A 是客观最优解。
+**spec.md ↔ plan.md 一致性检查**：
+- [ ] plan.md 中提到的所有功能需求是否都能在 spec.md 中找到对应？
+- [ ] spec.md 中的所有目标是否都在 plan.md 中有实现方案？
+- [ ] plan.md 是否引入了 spec.md 中没有的新需求？（如果有，需标记为越界）
 ---
-## 综合评估
-### 关键发现总结
-1. [发现 1]
-2. [发现 2]
-3. [发现 3]
+### Mode B：开发审计（development）
-### 阻断性问题（Blocking Issues）
-- [ ] [阻断性问题 1]：必须修复后才能继续
-- [ ] [阻断性问题 2]：必须修复后才能继续
+**适用场景**：代码实现完成后，Gate 4 提交确认前。
-### 审计结论
-- [ ] **通过**：需求文档完整、一致、可执行，可以继续
-- [ ] **有条件通过**：存在非阻断性问题，建议修复后继续
-- [ ] **不通过**：存在阻断性问题，必须修复后才能继续
+**审计维度**：
-**结论说明**：[说明审计结论的理由]
----
+#### 2.4 代码合规检查
-## 后续行动
+| 检查项 | Spec-Lite | Spec-Full |
+|--------|-----------|-----------|
+| 修改范围是否超出 §2.1 列出的文件？ | 必检 | 必检 |
+| 是否引入了未在方案中声明的依赖？ | 必检 | 必检 |
+| 是否破坏了 §4 中的任何 Invariant？ | 必检 | 必检 |
+| 代码分层是否符合规范（如有）？ | 按需 | 必检 |
+| 文件大小是否超出规范限制？ | 按需 | 必检 |
-### 需要修复的问题
-- [ ] [问题 1]
-- [ ] [问题 2]
-### 需要补充的内容
-- [ ] [补充项 1]
-- [ ] [补充项 2]
-### 需要用户确认的事项
-- [ ] [确认项 1]
-- [ ] [确认项 2]
+#### 2.5 文档同步检查
+- [ ] `rt-lite.md`（或对应文档）是否已更新？
+- [ ] `meta.yaml` status 是否正确？
+- [ ] 是否有代码改动未在文档中提及？
 ---
-## 历史审计记录
-### 审计记录 #1（YYYY-MM-DD HH:MM:SS）
-- 审计文档：`intake.md`
-- 审计结论：不通过
-- 主要问题：[问题摘要]
+### Mode C：综合审计（full）
-### 审计记录 #2（YYYY-MM-DD HH:MM:SS）
-- 审计文档：`spec.md`
-- 审计结论：有条件通过
-- 主要问题：[问题摘要]
-```
-### 4.2 时间字段要求
-**硬性要求**：所有时间字段（`审计时间`、`修复时间` 等）**必须**通过系统命令或 API 获取真实时间。
-**禁止行为**：
-- ❌ 使用 AI 训练数据或对话上下文中的假时间
-- ❌ 使用"当前时间"、"现在"等模糊表述
-**正确做法**：
-- ✅ 使用系统命令：`date -u +"%Y-%m-%dT%H:%M:%SZ"`
-- ✅ 使用 API 获取真实时间
+按顺序执行 Mode A + Mode B，输出合并报告。
 ---
-## 5. 执行流程
-### 5.1 自动触发流程
-1. **检测文档生成**
-   - AI 在生成需求阶段文档后，自动检测文档是否已创建/更新
-   - 如果检测到文档生成，立即触发需求阶段审计官
+## 3. 输出格式
-2. **读取相关文档**
-   - 读取当前审计的文档（如 `spec.md`）
-   - 读取相关文档（如 `intake.md`、`plan.md`）进行一致性检查
-3. **执行审计**
-   - 按照四个维度逐项检查
-   - 记录发现的问题
-   - 生成审计报告
+```markdown
+# 审计报告：[RT-ID] - [任务标题]
-4. **更新审计报告**
-   - 如果 `requirement-audit-report.md` 已存在，追加新的审计记录
-   - 如果不存在，创建新的审计报告
+## 审计元数据
+- **审计时间**：[系统真实时间]
+- **审计模式**：requirement / development / full
+- **审计目标**：rt-lite.md 或 spec.md + plan.md
+- **审计人**：AODW 统一审计官 v2.0
-5. **展示审计结果**
-   - 向用户展示审计结果摘要
-   - 如果存在阻断性问题，**必须停止流程**，要求用户修复
+---
-### 5.2 阻断机制
+## 审计项跟踪表
-**如果发现阻断性问题（Blocking Issues）**：
-- AI **必须停止**当前流程
-- AI **必须**向用户展示阻断性问题
-- AI **必须**要求用户修复后才能继续
+| ID | 章节 | 类型 | 严重程度 | 状态 | 描述 |
+|----|------|------|---------|------|------|
+| AUD-001 | §1.4 | 结构缺失 | Blocking | Open | 缺少"可验证成功标准" |
+| AUD-002 | §2.2 | 需求不匹配 | Critical | Open | 方案未覆盖目标中的 X 场景 |
-**阻断性问题示例**：
-- 文档结构缺失（缺少必要章节）
-- 文档间存在矛盾
-- 技术方案与需求不匹配
-- 代码结构不符合编码规范
+**严重程度**：Blocking（必须修复）| Critical（强烈建议）| Warning（可选）
 ---
-## 6. 与 CSF Review 的关系
-### 6.1 审计官包含 CSF 审查
-需求阶段审计官的"维度 4：战略对齐与 CSF 检查"自动包含 CSF 思维框架的 5 个维度检查：
+## 阻断性问题（Blocking Issues）
-- **以终为始**（CSF 3.1）
-- **结构化分解**（CSF 3.2）
-- **关键要素识别**（CSF 3.3）
-- **流程与系统观**（CSF 3.4）
-- **多维决策**（CSF 3.5）
+- [ ] [问题描述]：必须修复后才能继续
-### 6.2 与独立 CSF Review 的区别
+---
-- **CSF Review**：建设性、引导性的战略审查，帮助优化方案
-- **审计官**：批判性、挑战性的合规性审计，只找缺陷
+## CSF 检查结果（需求审计时）
-**两者可以并存**：
-- 用户可以先执行 CSF Review 获得建设性建议
-- 然后执行审计官获得严格的合规性检查
+- **以终为始**：[通过 / 失败 + 说明]
+- **多维决策**：[通过 / 失败 + 说明]
 ---
-## 7. 集成点
-### 7.1 Spec-Full Profile 集成
-在 `spec-full-profile.md` 中：
+## 审计结论
+- [ ] **通过**：可以继续
+- [ ] **有条件通过**：存在非阻断问题，建议修复后继续
+- [ ] **不通过**：存在阻断性问题，必须修复
+```
-- **Spec 阶段后**：自动触发需求阶段审计官
-- **Plan 阶段后**：自动触发需求阶段审计官（包含 CSF 审查）
+---
-### 7.2 Spec-Lite Profile 集成
+## 4. 阻断机制
-在 `spec-lite-profile.md` 中：
+**若发现 Blocking 问题**：
+1. 立即停止当前流程
+2. 展示所有 Blocking 问题
+3. 要求用户修复后再继续
-- **spec-lite.md 生成后**：自动触发需求阶段审计官
-- **plan-lite.md 生成后**：自动触发需求阶段审计官（包含 CSF 审查）
+**不得**：
+- 静默绕过 Blocking 问题
+- 将 Blocking 降级为 Warning 继续执行
-### 7.3 Kernel Loader 集成
+---
-在 `aodw-kernel-loader-template.md` 中添加：
+## 5. 时间字段要求（强制）
-```markdown
-| **执行需求审计** | {{REF_PREFIX}}.aodw/04-auditors/aodw-requirement-auditor-rules.md | 调用需求阶段审计官，对需求文档进行审计 |
+所有审计报告中的时间字段必须通过系统命令获取：
+```bash
+date +"%Y-%m-%dT%H:%M:%S%z"
 ```
+❌ 禁止使用 AI 推断或占位符时间
 ---
-## 8. 注意事项
+## 6. 历史记录追加规则
-1. **绝对禁止肯定**：不得对需求文档做任何肯定、鼓励或赞扬
-2. **时间字段真实性**：所有时间字段必须使用系统真实时间
-3. **阻断机制**：发现阻断性问题必须停止流程
-4. **文档一致性**：必须检查所有相关文档的一致性
-5. **CSF 审查集成**：Plan 阶段后必须执行 CSF 审查
+- 审计报告文件：`RT/RT-XXX/audit-report.md`（统一文件，追加模式）
+- 每次审计完成后，在文件末尾追加新的审计记录
+- 若文件不存在，则创建