aif-rules-check

规则合规检查门

针对项目规则运行独立的只读规则检查。此命令仅检查规则合规性；不能替代 /aif-review 或 /aif-verify。

步骤 0：加载契约

• 首先读取 references/RULES-CHECK-CONTRACT.md。
• 将其视为判定语义和报告结构的权威来源。
• 如果本文件中的示例与参考文件不一致，请遵循参考文件。

步骤 1：加载配置

**首先：**如果 .ai-factory/config.yaml 存在，则读取它以解析：

• paths.rules_file
• paths.rules
• paths.plan
• paths.plans
• language.ui
• git.enabled
• git.base_branch
• rules.base
• 命名的 rules.<area> 条目
• workflow.plan_id_format（默认值：slug）——用于步骤 2.3 中可选的基于分支的计划上下文查找。 有效值：slug 和 sequential。计划上下文可以是根目录中的完整计划文件，也可以是直接子级 ultra index.md；编号查找涵盖这两种形式。 timestamp 和 uuid 是保留值，目前的行为与 slug 相同。 遇到任何未知值时，按 slug 处理。

如果配置缺失或不完整，请使用默认值：

• paths.rules_file：.ai-factory/RULES.md
• paths.rules：.ai-factory/rules/
• paths.plan：.ai-factory/PLAN.md
• paths.plans：.ai-factory/plans/
• git.enabled：true
• git.base_branch：从 git 元数据检测仓库默认分支；仅在无法检测时回退到 main
• rules.base：.ai-factory/rules/base.md
• workflow.plan_id_format：slug

如果配置中缺少 paths.rules_file，则默认使用 .ai-factory/RULES.md，而不要将配置视为不完整。 如果配置中缺少 git.base_branch，则尽可能从 git 元数据解析仓库默认分支；仅在最后才回退到 main。

步骤 1.1：加载技能上下文

读取 .ai-factory/skill-context/aif-rules-check/SKILL.md——如果该文件存在，则为强制要求。

此文件包含 /aif-evolve 根据补丁、代码库约定和技术栈分析积累的项目专属规则。这些规则针对当前项目量身定制。

如何应用技能上下文规则：

• 将其视为对此技能通用说明的项目级覆盖规则。
• 当技能上下文规则与本文件中的通用规则冲突时，以技能上下文规则为准。
• 如果不存在冲突，则同时应用两者。
• 技能上下文规则适用于此技能的所有输出，包括判定用语和报告结构。

**执行要求：**提交最终报告前，依据所有技能上下文规则进行核验，并修正任何偏差。

步骤 2：解析输入

在检查任何规则前，先解析两项输入：

1. 变更范围——要评估的差异和文件列表
2. 已解析的规则来源——可能适用于该范围的规则文件

步骤 2.1：解析变更范围

如果用户提供了 git 引用：

1. 先验证它：

   git rev-parse --verify <argument>
   

2. 如果有效，则使用：

   git diff --name-only <argument>...HEAD
   git diff <argument>...HEAD
   

3. 如果无效，则询问：

   AskUserQuestion: `<argument>` is not a valid git ref. What should I check instead?
   
   Options:
   1. Check staged / working-tree changes
   2. Cancel
   

没有参数时：

1. 优先使用暂存的更改：

   git diff --cached --name-only
   git diff --cached
   

2. 如果没有暂存内容，则回退到工作区：

   git diff --name-only
   git diff
   

3. 如果仍然没有本地差异且 git.enabled = true，则回退到分支差异：

   git diff --name-only <resolved-base-branch>...HEAD
   git diff <resolved-base-branch>...HEAD
   

如果仍然没有变更文件，则返回 WARN，而不是硬性失败。

步骤 2.2：解析规则来源

按以下顺序加载规则来源：

1. 已解析的 paths.rules_file 文件
2. 已解析的 rules.base 文件
3. 配置中与变更范围明显匹配的任何命名 rules.<area> 文件

区域规则为可选且具有适用范围：

• 使用变更文件路径、文件夹名称和可选的计划上下文来判断相关性。
• 如果相关性不明确，请说明规则来源存在不确定性，并将结果设为 WARN，而不是 FAIL。

如果没有解析出任何规则来源，则返回 WARN，而不是硬性失败。

步骤 2.3：可选计划上下文

可选计划上下文：仅在有助于判断范围或区域相关性时使用当前活动计划文件；没有计划绝不算失败。

计划解析顺序：

1. 使用与 /aif-plan、 /aif-implement 和 /aif-improve 相同的方式计算规范分支名称：
   • 仅在 git 模式下，通过 git branch --show-current 获取当前分支；
   • branch_stem = 将当前分支中的每个 / 替换为 - （例如 feature/user-auth → feature-user-auth）。
2. 使用 <branch_stem> 按分支查找：
   • 当 workflow.plan_id_format = sequential 时，同时 glob 匹配 paths.plans/[0-9][0-9][0-9][0-9]_<branch_stem>.md 和 paths.plans/[0-9][0-9][0-9][0-9]_<branch_stem>/index.md；读取每个 目录候选项，仅当其中恰好包含一个 `` 时才保留；然后选择编号最高的有效 工件；存在多个有效候选项时发出警告；若两种形式具有相同的最高前缀，则优先选择 ultra；
   • 否则／作为回退，检查 paths.plans/<branch_stem>/index.md 和 paths.plans/<branch_stem>.md；先读取目录入口文件，除非其中恰好包含一个 ultra 标记，否则忽略该文件；若两种有效形式都存在，则发出警告并优先选择 ultra。
3. paths.plans 中的单个命名工件：统计包含 `` 的根目录 *.md 完整计划和直接子目录中的 */index.md 入口文件；排除 已解析的快速计划路径，且绝不统计阶段文件。
4. paths.plan 中的快速计划。

对于 ultra，先读取 index.md；仅在需要更多范围细节时，才读取与变更区域相关的已链接阶段文件。不得因计划工件缺失或存在歧义而导致规则检查失败。 自动发现的目录入口文件只有在恰好包含一个 `` 时才计入；忽略无关的 */index.md 文件。

步骤 3：评估规则

读取已解析范围内的变更文件，并将其与已解析的规则进行比较。

分类规则：

• 当至少检查了一条适用规则且未发现明确违规时，判定为 PASS。
• 当未解析到适用规则、证据存在歧义，或没有可供评估的变更文件时，判定为 WARN。
• 当检查到的差异或变更文件明确违反了硬性规则时，判定为 FAIL。

只有在检查到的差异或变更文件明确违反了硬性规则时，才返回 FAIL。

证据规则：

• 每项阻断性违规都必须关联到具体的规则文本，以及至少一个具体文件／路径或差异代码块。
• 如果规则听起来只是偏好、过于模糊，或无法从差异中有把握地验证，不要将其升级为 WARN 以上的级别。
• 可选文件缺失或规则层级配置不完整时，判定为 WARN，而非 FAIL。

步骤 4：只读边界

此命令为只读：不要编辑 RULES.md、rules/base.md、rules.<area>、计划文件或源代码。

如果规则缺失、过时或需要完善：

• 公理请建议使用 /aif-rules <rule text>
• 区域专属规则请建议使用 /aif-rules area:<name>

步骤 5：输出

使用 references/RULES-CHECK-CONTRACT.md 中规定的确切判定语义和章节顺序。

必需内容：

• 总体判定
• 已检查的文件
• 门禁结果
• 阻断性违规
• 建议的修复
• 建议的规则更新
• 最后的机器可读 aif-gate-result fenced JSON 块

适用时，建议下一个最佳工作流：

• /aif-review，用于更全面的代码审查
• /aif-verify，用于完整的计划完备性验证
• /aif-rules，用于记录或修正规则

机器可读的门禁结果：

• 在面向用户的规则报告之后，追加一个最后的 fenced aif-gate-result JSON 块。
• 使用 "gate": "rules"。
• 将面向用户的规则判定精确映射为：PASS -> pass、WARN -> warn、FAIL -> fail。
• 使用 "blocking": true|false；仅当明确违反硬性规则并导致面向用户的判定为 FAIL 时，才设为 true。
• "blockers": [ 中仅包含违反硬性规则的情况。
• "affected_files": [ 中包含已更改或已检查的路径。
• 当需要添加或澄清规则时，将 "suggested_next": { 设为 /aif-rules；当代码必须更改时，设为 /aif-fix；如果没有适用的后续命令，则设为 null。
• 不要在 JSON 的 "suggested_next.command" 中使用 /aif-review；它只能出现在面向用户的工作流建议中。

{
  "schema_version": 1,
  "gate": "rules",
  "status": "warn",
  "blocking": false,
  "blockers": [],
  "affected_files": [],
  "suggested_next": {
    "command": "/aif-rules",
    "reason": "Rules are missing or ambiguous for the changed scope."
  }
}

架构提醒："status": "pass|warn|fail"、"blocking": true|false、"blockers": [、"affected_files": [、"suggested_next": {。