🛡️C-A-Rプロトコル · AIと一緒にバグのないソフトウェアを構築する方法（Claude Code, Codex, NeuralOS）

今後、すべての些細でない作業（新しいフィーチャー、リファクタリング、複数ファイルにまたがる変更）で、構築-監査-振り返り（C-A-R）プロトコルを適用してください。1行の些細な修正のとき、または明示的に頼まれたときだけスキップしてください。

=== フェーズ1 · 構築 ===
創造的なエネルギーで構築してください。コードを書く前に競合の標準をリサーチしてください。クリーンな境界のアーキテクチャで。進めながら自己テストしてください。
終わったら、手を止めて報告書をください：
- 作成/変更したファイルと主要な決定
- 標準に対してどんな改善を加えたか
- テスト結果（type-check、build、tests）
- 何をしなかったか、そしてその理由（スコープの境界）
それから待ってください。このターンでは監査しないでください。監査を構築と混ぜないでください。

=== フェーズ2 · 監査（別ターン · 私の承認が必要）===
私が「監査を進めて」と言うまで待ってください。それから：
1. 各ファイルを監査者の頭で（冴えた、悲観的な状態で）読み返す
2. 発見をカタログ化する：
   - クリティカル：本物のバグ（メモリリーク、競合状態、セキュリティの欠陥、壊れたアクセシビリティ、間違ったセマンティクス、データ破損）
   - 改善：堅牢性、パフォーマンス、UXの磨き上げ
3. 各発見を、それを固定する回帰テストとともに修正する — テストがなければ修正は完了していない
4. エッジケースの積極的なテストを走らせる：unicode、境界値、イベントのスパム、並行操作、キャンセルパス
5. 四重に検証する：type-check + build + 既存のテスト + 新しいテスト、閉じる前にすべて緑に

=== フェーズ3 · 振り返り（監査とともに）===
教訓の文書を書いてください：各発見をその根本原因とともに（ビルダーモードで何を見落としたか？）、メタ教訓、そして次の構築のための更新されたチェックリスト。この文書はサイクルごとに成長し、プロジェクトのメモリになります。

ルール：
- 構築と同じターンで監査しない。
- 新しいコードに対して本物の監査パスを走らせずに「バグなし」と断言しない。
- 監査の修正の回帰テストをスキップしない。
- 根本原因を、決してパッチではなく。値が空で届いたら、なぜかを見つける；デフォルト値で塞がない。

=== ループの締めくくり · GITHUB ===
監査が緑になった後（type-check + build + スモークテストすべてパス）、仕事を完了とみなす前に：
1. まだやっていなければ、スモークテストを走らせるよう私に思い出させる。
2. 達成したことを説明する明確なメッセージでコミットする。
3. 良いポイントをクラウドに保存するためGitHubにプッシュする。
進捗をバックアップして残さずにサイクルを閉じないでください。

=== 監査のための深いコンテキスト ===
監査する前に、プロジェクトの知識グラフ（Graphify）またはRAGを参照し、私が触れたものが残りとどうつながっているかを理解してください。私が変更したファイルだけでなく、システム全体への影響を理解した上で監査してください。自問してください：他のどの部分がこれに依存しているか？連鎖的に何が壊れた可能性があるか？

=== ループの締めくくり · フルスタック ===
監査が緑になったら、完全なサイクルをこの順序で閉じてください：
1. スモークテスト → すべて緑に。
2. コミット + GitHubにプッシュ（良いポイントを保存）。
3. 新しい変更を反映するよう知識グラフ（Graphify）を再構築 / 更新する。そうすれば次の監査は冴えたコンテキストを持つ。
4. 監査の教訓をプロジェクトのメモリ文書に保存する。
5. C-A-Rプロトコルが忘れられないよう、CLAUDE.mdに書かれたままであることを確認する。
このループは各スプリントまたは重要な開発パスの後に適用します。