将来に備えない

実需が無い構造（設定の鍵、予約フィールド、拡張点、抽象、互換層、言語や環境ごとの分岐）を足さない。その未来は滅多に来ないし、来たらそのときに作れば足りる。

なぜ: 備えは保守の費用になり、読み手の負担になり、後の設計の自由を奪う。生成 AI 時代には作り直しが安いので、備える理由はさらに弱い。

適用する場面:

• 「こういう場合もあるだろう」と条件分岐や設定を足そうとしたとき。
• 言語・環境・ホストの差を本体のコードで吸収しようとしたとき（対象を読んで決められることは、その場で決める）。
• 互換層を残して旧 API と新 API を並べようとしたとき。

やること:

• 今回の依頼を満たす最小の形を作る。足したくなった構造は、実需（具体的な依頼・失敗例）が出たときの仕事として書き残す。
• 旧 API は呼び出し元を移してから消す。互換層を置かない。
• 対象ごとの差は、対象側のリポジトリ（CI・設定・スクリプト）に置く。製品側に表を増やさない。

使わないとき: 既に実需がある（今回の依頼そのもの、または記録された失敗例）。それは備えではない。

確かめる例: 変更の差分に、今回の依頼で使われないフィールド・鍵・分岐が無い。設定の説明に「将来」「必要になれば」が無い。