設計してから構築 は何をしますか？
概要
作業は5つの段階を順に進めます: Brainstorm（ブレインストーミング）→ Spec（仕様）→ Plan（計画）→ Execute（実行）→ Record（記録）。設計が明確に記述され承認されるまでは、実装を開始しません。最もシンプルなタスクこそ、検証されていない前提が最もコストを生む場です。
このルールの文言に違反することは、その精神に違反することです。 「コードを書きながら設計する」は設計ではありません。
5つの段階
- Brainstorm（ブレインストーミング）。意図、制約、成功基準を探ります。一度に1つの質問をしましょう。トレードオフと推奨事項を含む2～3のアプローチを提案します。設計に収束し、明示的な承認を得ます。ここではコードは書きません。
- Spec（仕様）。承認された設計を、日付入りのドキュメントに書き起こします。仕様書は、構築されるものの契約書です。
- Plan（計画）。コードに触れる前に、仕様を順序立てられたレビュー可能な実装計画に分解します。
- Execute（実行）。計画に沿って実装し、レビューのチェックポイントを設けます。
- Record（記録）。何が構築されたか、そしてなぜかを、決定記録にまとめます（
recording-decisionsを参照）。
大規模な作業は分解してください。 リクエストが複数の独立したサブシステムにまたがる場合は、詳細を詰める前に停止して分解します。各サブプロジェクトは独自のサイクルを実行し、依存関係の順序に従って構築します。
使用すべきでない場合
真に些細で元に戻せる編集（タイプミス、ログ行、設定値）は、Execute（実行）段階に直接進みます。判断基準: ここで間違った推測をした場合、設計ステップよりもコストがかかるか？ もし「はい」なら、最初に設計を行います。
よくある正当化
| 言い訳 | 現実 |
|---|---|
| 「これは設計が必要ないほどシンプルだ」 | シンプルなタスクには前提が隠れています。数行の設計は安価ですが、書き直しはそうではありません。 |
| 「進めながら設計する」 | 設計が確定する前に書かれたコードは、書き直されるコードです。設計は独立した行為です。 |
| 「ユーザーが何を作るか教えてくれた、それが設計だ」 | リクエストは何を示すもので、どのようにを示すものではありません。どのようにが設計です。 |
| 「まずコードベースを調べればアプローチがわかる」 | 調査は設計に情報を与えますが、設計の承認に代わるものではありません。 |
| 「急いでいる」 | 急いでいる時こそ、設計を省略すると無駄な作業が発生します。 |
レッドフラグ — 停止
- 承認された設計がないままエディタを開く
- 「とりあえずプロトタイプを作ってみよう」（仕様のないプロトタイプは、レビューされていないスコープです）
- 計画なしで複数ファイルの変更を開始する
- ユーザーの1行のリクエストを完成した仕様として扱う
これらはすべて、停止し、設計し、承認を得てから構築することを意味します。
完全な根拠: 憲法第1条、engineering-constitution/references/engineering-constitution.md にバンドルされています。