principle-encode-lessons-in-structure

仕組みに教訓を組み込む

繰り返し発生する修正は、文章による指示ではなく、仕組み（ツール、コード、メタデータ、自動化）に組み込みます。すべてのエラー、人による修正、予想外の結果は学習のシグナルです。それを記録し、適切な場所に振り分け、フィードバックループを完結させましょう。

理由： 文章による指示は見落とされがちです。読み手が気づき、覚え、従う必要があります。仕組み（Lint ルール、メタデータフラグ、実行時チェック、自動化スクリプト）なら、協力を求めずにルールを適用できます。

パターン： 同じ指示を2回目に書いていると気づいたら、次のようにします。

1. これは Lint ルール、メタデータフラグ、実行時チェック、スクリプトにできないか考えます。
2. できる場合は、仕組みに組み込みます。指示は削除します。
3. できない場合（判断が必要な場合）は、指示をより目立たせ、失敗例を追加します。

最も強力な仕組みを選びます。 複数の仕組みが使える場合は、その状況で可能な限り最も強力なものを選びます（コンパイルできない状態を表現できないようにする仕組み、CI を失敗させる Lint ルールまたは禁止 API、標準ヘルパー、実行時チェックの順）。エージェントは周囲のコードにある手法を模倣するため、より弱いガードが次のテンプレートになってしまうからです。

系： 修正が構造的なものなら、構造的な修正だけを使います。指示は症状にすぎません。

フィードバックループ：

• すべての修正を記録します。 人が介入したときやテストが失敗したとき、それが一度限りの問題か、パターンなのかを判断します。
• 適切なレイヤーに振り分けます。 一度限りの問題 → ブレインノート。繰り返し発生する修正 → スキルまたは Lint ルール。システム上の問題 → 原則。
• フィードバックループを完結させます。 記録するだけではいけません。今すぐ適用するか、具体的な ToDo を作成します。

アンチパターン：

• 認識しただけで記録しない（「覚えておきます」では定着しません）
• 振り分けずに記録する（実装すべき Lint ルールについてブレインノートに記録しても、Lint ルールが実装されなければ無駄です）
• 一般化せずに修正する（1つの事例だけを修正し、繰り返し発生するパターンをそのままにする）