adr-writelisted

# 判断記録(ADR)を書く ## 何を記録するか **あとから変えにくい決定**です。技術選定、方針、原則、外部との契約に関わる設計。 日々の実装判断は対象外です。「あとで変えるとしたら何が必要か」を考えて、答えが「作り直し」に近ければ ADR にします。 ## 手順 ### 1. 番号を採る `context/decisions/` を見て次の連番を採ります。`0001-<英語のケバブケース>.md`。 ### 2. テンプレートから起こす `templates/02-adr.md` を写します。 ### 3. 埋める | 節 | 書くこと | | --- | --- | | ステータス | 採用(日付) / 廃止 / 置き換え(後継 ADR へリンク) | | コンテキスト | 何が問題で、なぜいま決めるのか | | 決定 | 何を決めたか。具体的に | | 検討した選択肢 | **採らなかった案と、採らなかった理由** | | 可逆性 | 後から変えられるか。変えるとしたら何が必要か | | 影響 | 何が変わるか。トレードオフ。仕組みの限界 | ### 4. 選択理由は人が書く **「検討した選択肢」の理由欄を AI が生成してはなりません**。どの案を選ぶかは技術判断であり、委譲の対象になりません。 エージェントができるのは次までです。 - 選択肢の**列挙**(こういう案がある) - 各案の**性質の整理**(この案はこれができて、これができない) 「したがって案Bを推奨します」と書いてはなりません。 ### 5. コミットする ``` docs: セッショ��管理の方式を決める ADR: ADR-0007 ``` ## 採用済みの ADR を書き換えない 決定を変えるときは**新しい ADR で置き換えます**。古い ADR のステータスを「置き換え」にして後継へリンクし、本文はそのまま残します。 書き換えると、当時なぜそう決めたのかが失われます。採らなかった選択肢を書き残すことは、後任者が同じ検討を繰り返さないための唯一の手段です。 ## 参照 - [第2章 2.9.4](https://takenori-kusaka.github.io/process-compass/phase4-process-design/lifecycle/) - [第4章 G-3 技術設計判断](https://takenori-kusaka.github.io/process-compass/phase4-process-design/gate-criteria/)