principle-encode-lessons-in-structure

構造で教訓を定着させる

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

テキストの指示は見落とされがちです。構造的な仕組みなら、協力を求めなくてもルールを徹底できます。

パターン： 同じ指示を2回目に書いていることに気づいたら：

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

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

補足： 修正が構造的なものなら、構造的な修正だけを使います。指示は症状です。

人が介入したときやテストが失敗したときは、一度限りの問題か、パターンなのかを判断します。適切な仕組みに振り分けます。一度限りの問題なら brain note、繰り返し発生する修正なら skill または lint ルール、システム全体の問題なら原則にします。フィードバックループを閉じます。記録するだけでなく、すぐに適用するか、具体的な todo を作成します。

アンチパターン：

• 記録せずに了承する（「覚えておきます」では定着しません）
• 振り分けずに記録する（実装すべき lint ルールについて brain note を残しても、lint ルールを実装しなければ無駄になります）
• 一般化せずに修正する（1つの事例を修正するだけで、繰り返し発生するパターンを放置する）