quality-gate

品質ゲート

使用する場合

• egregore の作業項目に対して品質チェックを実行する場合
• PR を作成する前にセルフレビューする場合
• PR レビューモードで別のエージェントの PR をレビューする場合

使用しない場合

• egregore のパイプライン外で手動のコードレビューを行う場合
• 単発の lint またはフォーマットチェックを行う場合（make lint を直接使用してください）

egregore のパイプラインの QUALITY ステージをオーケストレーションします。 各品質ステップでは、codex の規約チェックを実行し、 対応するスキルを呼び出します。

ルーティングテーブル

ステップ	規約	スキル	モード
code-review	C1,C2,C3,C4,C5	pensive:unified-review	self, pr
unbloat	-	conserve:unbloat	self
code-refinement	-	pensive:code-refinement	self
update-tests	-	sanctum:update-tests	self
update-docs	C5	sanctum:update-docs, scribe:slop-detector	self

入力

オーケストレーターは、次の入力でこのスキルを呼び出します。

• step：実行する品質ステップ（例：「code-review」）
• mode：「self-review」または「pr-review」
• work_item_id：マニフェストの作業項目 ID
• branch：変更を含む git ブランチ
• pr_number：（PR レビューモードのみ）PR 番号

セルフレビューワークフロー

mode が「self-review」の場合：

1. 変更されたファイルを取得します：git diff --name-only main...HEAD
2. conventions/codex.yml から規約を読み込みます
3. 現在のステップに対応する規約に絞り込みます
4. conventions.py で規約チェックを実行します
5. 変更されたファイルに対して、対応するスキルを呼び出します
6. すべての指摘事項を収集します
7. 判定を計算します

自動修正ループ

ブロッキング指摘がある場合：

1. 各指摘事項の修正を試みます（スキルによって異なります）
2. 作業項目のブランチに修正をコミットします
3. 規約チェックを再実行します
4. 3 回試行してもブロッキング指摘が残る場合、判定は 「fix-required」となります

判定の計算

if no findings:
    verdict = "pass"
elif all findings are severity "warning":
    verdict = "pass-with-warnings"
elif blocking findings remain after auto-fix:
    verdict = "fix-required"

判定をマニフェストの決定事項に記録します。

{
  "step": "code-review",
  "chose": "pass-with-warnings",
  "why": "2 warnings (C4: noqa in hooks), 0 blocking"
}

完了の完全性（オプトイン、デフォルトでは無効）

デフォルトでは、ループは無期限かつ自律的に実行されます。 fix-required の判定が記録されても、それだけで項目の 次の段階への移行が止まることはありません。これは従来どおり、 人手を介さない方針を維持するためです。

config.pipeline.completion_integrity が true の場合、 判定はエージェントが言いくるめて回避できないゲートになります。

1. fix-required の判定はオーケストレーターに ステップ失敗として報告されるため、未解決のブロッキング指摘が 残ったまま項目が出荷段階に進むことはありません。その場で再試行し、 max_attempts に達すると failed としてマークされ、 管理者に通知されます（黙って completed になることはありません）。
2. auto_merge の設定にかかわらず、マージは人間によるレビューのために 保留されます。PR は準備されますが、オープンのままになります。

これにより、「完了」はエージェント自身の自己申告ではなく、 検証（規約チェックとマッピングされたレビュー用スキル）に結び付けられます。 この原則は、リリース済みのエージェントハーネスに由来し、 KbWen/agentic-os が最もよく言い表しています。エージェントは 「手を抜くことはできるが、自分で制御できないチェックをすり抜けて この部分で手を抜くことはできない」。これらのハーネスで繰り返し見られるパターンは 次のとおりです。

パターン	機能	出典
完了判定としての検証ゲート	エージェントが偽装できないテスト、リンター、または結果ハッシュに「完了」を結び付ける	Aider、snarktank/ralph、gaasher
完了の宣言と最大反復回数の上限	「完了」という文字列の一致だけでは不十分です。反復回数の上限と手動中止を組み合わせます	anthropics ralph-wiggum
エージェントが制御できない証拠によるゲート	認証情報のスキャン、テスト実行の検証、フェーズログの解析をフックまたは CI で強制します	KbWen/agentic-os
改善なら維持／悪化なら差し戻しの台帳	変更ごとにスコアを付け、リグレッションを差し戻し、追記専用の台帳に記録してレビューできるようにします	gaasher/Agent-Loop-Skills
状態把握の手掛かり	人間がループに再参加できるよう、現在の状態またはリポジトリマップをファイルに永続化します	Aider repo map、agentic-os
人間による監視のチェックポイント	初期の反復を監視し、差分を確認して、明確に定義された問題にループを割り当てます	anthropics、ghuntley

さらに、あり得ない状態に備えて防御する前に、まずその状態を表現不可能にするべきです。 あり得ないケースを隠すフォールバックは、特定可能なクラッシュではなく、 気付かれない破損につながるためです。Armin Ronacher、「The Coming Loop」（2026）、 https://lucumr.pocoo.org/2026/6/23/the-coming-loop/。このフラグは デフォルトで無効です。有効にすることは、人間を最終判断者として 維持するための意図的な選択です。

PR レビューワークフロー

モードが「pr-review」の場合：

1. PR の差分を取得します：gh pr diff <number> --name-only
2. 規約を読み込み、コードレビューステップに絞り込みます
3. 変更されたファイルに対して規約チェックを実行します
4. 差分に対して pensive:unified-review を実行します
5. すべての指摘を収集します

レビューの投稿

指摘を GitHub のレビューに対応付けます。

• 指摘なし：イベント「APPROVE」で gh api の POST レビューを送信します
• 警告のみ：イベント「COMMENT」で POST レビューを送信し、 指摘をインラインコメントとして投稿します
• ブロッキング指摘：イベント 「REQUEST_CHANGES」で POST レビューを送信し、ブロッキング指摘を 「must fix」プレフィックス付きのインラインコメントとして投稿します

指摘ごとのコメント形式：

[egregore:{convention_id}] {message}

Convention: {convention_name}
Severity: {severity}

品質設定

作業項目には quality_config フィールドを指定できます。

{
  "skip": ["unbloat"],
  "only": ["code-review", "update-docs"]
}

• skip：スキップするステップの一覧（それ以外はすべて実行）
• only：実行するステップの一覧（それ以外はすべてスキップ）
• 両方が設定されている場合は、only が優先されます
• どちらも設定されていない場合は、すべてのステップが実行されます（デフォルト）

ステップごとの規約フィルタリング

すべてのステップで、すべての規約が実行されるわけではありません。 上記のルーティングテーブルで、どの規約がどのステップに適用されるかを定義しています。 品質ゲートはチェックの実行前に、読み込まれたコーデックスを それに応じてフィルタリングします。

終了条件

• 該当する規約チェックをすべて実行済み
• マッピングされたスキルをすべて実行済み
• 判定を計算し、マニフェストに記録済み
• PR レビューの場合：GitHub にレビューを投稿済み