plangate-working-discipline

PlanGate Working Discipline

AI 駆動開発の品質ゲート。計画を固定し、リスクを先に見て、承認要否を判定し、 観測可能な証拠で検証し、判断を記録するための作業規律。

v2（2026-07-07）: ai-loop 実運用 Run-001〜003 から得た規律を還元。 出典の内訳 — 摩擦記録（F-10〜F-13、docs/working/ai-loop-runs/run-001-frictions.md） から: 原則 11（監査記録不変・F-10/Run-002 事後注記方式）・原則 12 と anti-pattern 16 （検証コマンド事前検証・F-12）・レビューのラウンド規律（F-13）。 Run-003 の C-4 追対応での実践（摩擦記録外・委譲プロトコル docs/ai/subagent-delegation/ の追指示テンプレートの運用実証）から: 原則 9 の SendMessage 追指示パターン。

高度なモデルの能力を再現するものではなく、どのモデルでも継承できる 「判断基準・検証ループ・停止条件」の集合である。

When to use / When not to use

• Use: 実装・修正・リファクタ・バグ修正・設計/差分レビュー・長期タスク・ 複数セッション跨ぎ・サブエージェント委託を伴う作業のすべて。
• Do not use: 読み取りのみの単発調査・会話的な質問応答 （ただし報告時の「観測事実と推測の区別」は常時適用）。

Core Principles（中核原則）

1. 完了条件を先に固定する — 着手前に「何が観測できたら完了か」を書く。 書けないなら作業を始めない。
2. 検証方法を書けない作業は、まだ理解できていないと見なす — 「どう確かめるか」が 言えない時点で、対象の理解が不足している。調査に戻る。
3. 実装前にリスクが高い箇所を特定する — 不可逆操作・共有状態・承認境界・ 外部影響を先に列挙する。次の一手は常に「いま最もリスクが高い場所」から。
4. 「動くはず」ではなく、観測された証拠を信じる — 完了・修正・マージなどの 完了系の主張は、一次証跡（コマンド出力・SHA・CI 結果・grep 件数）で実測してから報告する。 番号や名前の一致ではなく、SHA・内容の紐付けで同一性を判定する。
5. 宣言と実態を突合する — ドキュメントの「DONE」「適用済み」を信じず、 実ファイル・実コミットで確認する。宣言と実態の乖離（偽の完了）は最優先で是正する。
6. 着手前に並行作業を確認する — 同じ issue・同じ領域を別の PR / セッションが 既に実装していないかを確認してから着手する（重複実装は棄却コストが高い）。
7. 差分を小さく保つ — 要求に紐づかない変更を混ぜない。stage は明示パス指定で行い、 コミット前に staged 内容を必ず確認する。
8. 破壊的変更は承認ゲートを必須にする — 削除・上書き・force 系・本番影響は approval-gate-template.md を通す。迷ったら承認側に倒す。
9. サブエージェント利用を目的化しない — 委託は「複雑さ・独立性・並列性」の判断が先。 委託しても統合責任者として自ら検証する。委託結果を無検証で採用しない。 レビュー指摘の追対応など同一文脈の続きは、新規 spawn せず同一エージェントへの 追指示（SendMessage）で行う（文脈再構築のコストと齟齬を避ける）。
10. 作業後は memory に判断・却下理由・未解決事項を残す — 未来のセッションが 同じ調査・同じ失敗を繰り返さないために。確定していない事項は PENDING を明記する。
11. 監査記録は遡及編集しない — 時点記録（計画の各ラウンド・decision record・run ログ） への事後修正は、レビュー指摘対応であっても改竄になる（「レビュアーが何を見て 判定したか」が消える）。修正は事後注記の追記で行い、本文は不変に保つ。
12. 検証コマンドは計画時に実機で通す — 「機械検証」と書いたコマンドが動かなければ、 検証設計ごと偽物になる。計画段階で実機実行し、PASS する入力と FAIL する入力の 両方向で挙動を確認する（環境差 — BSD/GNU sed 等 — でサイレントに空を返す穴に注意）。