design-doc

設計ドキュメント

1. ブリーフと、リンクされているドキュメント、コード、計画を読みます。不足している情報によって設計が変わる場合に限り、推奨する回答を添えて、一度に1つずつ質問します。
2. 以下のテンプレートを使って、1〜3ページの docs/<design-slug>/design.md を作成します。該当しないセクションは省略します。
3. 作成したら停止します。人間の確認が済むまで、仕様書、計画、実装には進みません。

ルール

• 設計上の選択とそのトレードオフを、レビューしやすい形で示します。
• 後からコードを見ても分からない判断に焦点を当てます。
• 正確な形式が設計の核心でない限り、スキーマ、API、コード全体をコピーしません。
• ステータスは「Draft」のままにし、「Decision」は空欄にします。どちらもレビュー時に記入します。

テンプレート

# <タイトル>

**ステータス：** Draft | In review | Approved
**作成者：** <名前>  **日付：** <日付>

## 概要
課題、提案する解決策、その理由を1段落で記述します。

## 目標
この設計で達成すべきこと。

## 対象外
この設計では意図的に解決しないこと。

## 制約
技術、製品、移行、互換性、運用、コスト、時間に関する制限。

## 提案する設計
仕組み、構成、データフロー、主要なインターフェースを記述します。図は、明確化に役立つ場合にのみ使用します。

## 代替案とトレードオフ
検討した各選択肢と、採用しなかった理由を記述します。レビュアーが判断するセクションです。

## リスク
起こりうる問題と、その緩和策。

## 展開
移行、フラグ、ロールバックを含むリリース方法。

## 未解決の質問
まだ決定が必要な事項と、決定者。

## 決定
レビュー後に記入：決定内容、決定者、決定日。