principle-encode-lessons-in-structure

構造に教訓を組み込む

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

理由： テキストの指示は見落とされやすいものです。読み手が気づき、覚え、従う必要があります。構造的な仕組み（リンタールール、メタデータフラグ、実行時チェック、自動化スクリプト）なら、協力に頼らずルールを徹底できます。

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

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

最も強力な段階を選びます。 複数の仕組みで対応できる場合は、状況が許す最も強力なものを選びます（コンパイルできない、表現不可能な状態、次に CI で失敗するリンターまたは禁止 API、次に標準ヘルパー、最後に実行時チェック）。エージェントは周囲のコードがすでに行っていることを模倣するため、弱いガードは次のテンプレートになってしまうからです。

帰結： 症状を取り繕ってはいけません。修正が構造的なものなら、構造的な修正だけを使います。指示そのものが症状です。

フィードバックループ：

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

アンチパターン：

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