対象は、Issueで管理する工程（ユースケース → 設計 → 実装範囲の決定 → 詳細設計 → 実装）の成果物である、docs/runtime-management-*.md と、今後同じ工程で作る設計文書である。更新する主体（Claude、CODEX、人間）を問わず、同じルールに従う。
目的は、「なぜ今の内容になったのか」を、後から（別のセッション、別の担当者が）追えるようにすることである。
- 決定を伴う変更は、変更と同じ作業の中で、経緯を残す。 後回しにしない。
- 設計書の「決定の経緯」節に1行追加する（日付、決めたこと、理由、却下・置き換えた案、根拠のIssueコメント）
- Issueにコメントする（変更箇所ごとに「何を・なぜ」）
- 作業記録（
work_record）のメッセージに、理由を書く
- 過去の記述を置き換えたときは、置き換えたと明記する。 新しいコメントと「決定の経緯」節に、どの記述を置き換えるかを書く。
- 確定済みの文書（ユースケース等）を改訂するときは、運用者に確認する。 冒頭の「改訂」行に、日付と根拠のIssueコメントへのリンクを残す。ユースケースの追加も同じ。
- レビュー指摘への対応は、反映したものと反映しなかったものに分け、反映しなかったものには理由を書く。
- 節目で、Issue本文を現在の状態に書き直す。 本文は「現在地」、コメントは「経緯」と役割を分ける。本文に、廃止した方針を残さない。
設計書末尾の「決定の経緯」節の表に、次の列で1行ずつ追加する。
| 列 |
内容 |
| 日付 |
決めた日 |
| 決めたこと |
設計として何を決めたか |
| 理由 |
なぜそう決めたか |
| 却下・置き換えた案 |
採らなかった案、置き換えた過去の記述 |
| 根拠 |
Issueコメントへのリンク |