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：入力を解決する

ルールのチェックを始める前に、次の 2 つの入力を解決します。

1. 変更範囲 — 評価対象の差分とファイル一覧
2. 解決済みのルールソース — 変更範囲に適用される可能性があるルール成果物

ステップ 2.1：変更範囲を解決する

ユーザーが git ref を指定した場合：

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> ファイル

エリアルールは任意であり、適用範囲が限定されています。

• 変更されたファイルパス、フォルダー名、任意のプランコンテキストを使って、関連性を判断します。
• 関連性が不明確な場合は、そのルールソースが不確実であることを明記し、結果は FAIL ではなく WARN とします。

ルールソースを解決できない場合は、ハードエラーではなく WARN を返します。

ステップ 2.3: オプションのプランコンテキスト

オプションのプランコンテキスト: アクティブなプランファイルは、スコープやエリアの関連性を解釈するのに役立つ場合にのみ使用してください。プランが存在しないことは決して失敗ではありません。

プラン解決の順序:

1. /aif-plan、 /aif-implement、/aif-improve と同じ方法で正規のブランチステムを計算します:
   • git branch --show-current で現在のブランチを取得します（git モードのみ）。
   • branch_stem = 現在のブランチのすべての / を - に置き換えたもの （例: feature/user-auth → feature-user-auth）。
2. <branch_stem> を使用したブランチベースの検索:
   • workflow.plan_id_format = sequential の場合、 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 の両方を glob します。すべての ディレクトリ候補を Read し、それがちょうど 1 つの `` を含む場合にのみ保持し、番号が最も大きい有効な 成果物を選択し、複数の有効な候補が存在する場合は警告します。両方の 形式が同じ最上位プレフィックスを共有する場合は ultra を優先します。
   • それ以外／フォールバックでは paths.plans/<branch_stem>/index.md と paths.plans/<branch_stem>.md を確認します。ディレクトリのエントリポイントを先に Read し、 ちょうど 1 つの ultra マーカーを含まない限り無視し、両方の 有効な形式が存在する場合は警告して ultra を優先します。
3. paths.plans 内の単一の名前付き成果物: ルートの *.md フルプランと、 `` を含む 直接の子 */index.md エントリポイントを数えます。 解決済みの fast-plan パスを除外し、フェーズファイルは決して数えません。
4. paths.plan にある fast plan。

ultra の場合、index.md を先に読み、追加のスコープ詳細が必要なときに 変更されたエリアに関連するリンクされたフェーズファイルのみを読みます。プラン成果物が 欠落している、または曖昧であることを理由にルールチェックを失敗させないでください。 自動的に検出されたディレクトリのエントリポイントは、ちょうど 1 つの `` を含む場合にのみカウントします。無関係な */index.md ファイルは無視します。

ステップ 3: ルールを評価する

解決されたスコープから変更されたファイルを読み、解決されたルールと比較します。

分類ルール:

• 少なくとも 1 つの適用可能なルールがチェックされ、明確な違反が見つからなかった場合は PASS。
• 適用可能なルールが解決されなかった場合、証拠が曖昧な場合、または評価する変更ファイルがない場合は WARN。
• 検査された diff または変更ファイルによって明示的なハードルールが明確に違反されている場合は FAIL。

検査された diff または変更ファイルによって明示的なハードルールが明確に違反されている場合にのみ FAIL を返します。

証拠ルール:

• すべてのブロッキング違反を、特定のルールテキストと、少なくとも 1 つの具体的なファイル／パスまたは diff ハンクに結び付けます。
• ルールが好みのように聞こえる場合、曖昧すぎる場合、または diff から自信を持って検証できない場合は、WARN を超えてエスカレートしないでください。
• オプションのファイルの欠落や部分的に構成されたルール階層は FAIL ではなく WARN です。

ステップ 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 のフェンス付き JSON ブロック

必要に応じて、次に最適なワークフローを提案してください：

• /aif-review：より広範なコードレビュー
• /aif-verify：計画の完全性を全面的に検証
• /aif-rules：根本にあるルールを記録または修正

機械可読なゲート結果：

• 人間向けのルールレポートの後に、最後のフェンス付き 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": {。