ln-73-system-design-proposal-builder

システム設計提案ビルダー

目標： 要件を明確な境界、契約、データフロー、障害時の動作、運用、トレードオフに落とし込み、適切な規模で根拠に裏付けられた目標システム設計を作成します。承認済みの設計ドキュメントのみを変更し、実装、監査、納品物の承認は行いません。

実行契約： 順序付きチェックボックスが完了の定義です。各項目を内部で PENDING、具体的な証拠がある PROVEN、条件が存在しないことを示す証拠がある CLEARED、または不足がある UNPROVEN として追跡します。読み取り、委任、ツールの失敗は証拠になりません。各セクションの後に項目を照合してください。返答前にすべての PENDING を解消し、PROVEN と CLEARED のみを数えます。すべての不足に対し、このスキルの判定ルールと承認ルールを適用してください。 ユーザーの意図、スコープ、既存の権限を維持します。承認された作業を続行し、結果に重大な影響を及ぼす未解決の選択肢や必要な外部承認についてのみ質問してください。重大なリスクに応じて深さを調整し、チェックを暗黙に省略しないでください。依存関係と安全性に関する順序を守り、それ以外については各義務に適した検証方法を選択してください。

ツールの使い分け

必要事項	優先する手段	フォールバック
要件と制約	承認済みの要件、ベースライン、決定事項、ステークホルダーからの直接の情報	重大な不足を明記し、必要最小限の確認質問をする
現在の実装と規約	リポジトリの検索、マニフェスト、エントリーポイント、アーキテクチャ成果物	ユーザーまたはリポジトリによって事実と確認できる場合のみグリーンフィールドとして扱います。それ以外の場合は現在の状態を UNKNOWN とし、その不足が境界、互換性、移行に影響する可能性があれば REVISE または BLOCKED を返します
外部の機能と制限	最新の公式ドキュメントと仕様	主張を UNVERIFIED として記載し、ベンダー依存の確約を避けます
見積もり	出典のあるワークロードの前提に基づく再現可能な計算	範囲と感度を示し、見積もりを実測値として提示しないでください
ドキュメントの変更	承認済みの目標設計成果物への最小限のパッチ	スコープまたはパスが安全でない場合は BLOCKED を返します

パターンは候補となる解決策として扱い、目標として扱わないでください。要件、障害モード、所有権の境界、または測定可能な期間によってライフサイクルコストが正当化される場合に限り、インフラストラクチャを導入してください。

成果物のルール

• 明確な目標設計ドキュメントがあれば再利用し、なければ docs/architecture/target-design.md を使用します。
• 利用可能なベースライン、現状、決定事項、インターフェース、図、移行に関する成果物をパスで確認します。必須の成果物はありません。
• 事実、前提、見積もり、提案する決定事項、未解決の選択肢を分けて明記します。
• 重要な決定については、実現可能な最もシンプルな選択肢を含め、妥当な代替案を比較します。制約上選択肢が一つしかない場合は、別の選択肢を作り上げるのではなく、その理由を記載します。
• 可逆的な選択と、システムに適合する最もシンプルなトポロジーを優先します。新規アプリケーションでは、独立したサービスより先にモジュラーモノリスを検討します。ただし、ライブラリ、プラグイン、または確立済みのトポロジーにその形を無理に当てはめないでください。
• 承認済みの決定を暗黙に変更しないでください。矛盾と必要なガバナンス上の対応を記録します。

チェックリスト

1. 設計の枠組みを定める

• 編集前に、ビジネス上の成果、関係者、利用者の一連の行動、スコープ、対象外事項、期間、読者、言語、承認済みの正式な保存先を確定します。
• リポジトリの指示を読み、関連するアーキテクチャ成果物と現在の実装を調査します。
• 機能要件と測定可能な品質要因を抽出し、その出典と状態を維持します。
• アーキテクチャにとって重要な不明点を特定し、目標の形を変える回答が必要な質問のみをします。
• 必須のビジネス上の境界または安全制約を責任を持って前提とできない場合は、BLOCKED を返します。

2. コンポーネントを選ぶ前に見積もる

• 平均およびピーク時のリクエスト数またはイベント数、同時実行数、ペイロードと帯域幅、ストレージの増加量、保持期間、必要に応じて復旧対象の量を見積もります。
• 数式、範囲、成長期間、前提条件を示し、選択を覆し得る変数を特定します。
• 最初に発生する可能性が高いボトルネックと、後回しにするスケーリングの仕組みを導入する明確な基準を特定します。
• 可用性、レイテンシ、耐久性、一貫性、セキュリティ、コスト、運用性に関する要件を、実装上の好みから切り分けます。
• 投機的なスケールを退け、意図的に後回しにする複雑な仕組みを列挙します。

3. ドメイン、データ、コントラクトを定義する

• ビジネスケイパビリティ、ドメインまたはモジュール、所有者、不変条件、許可される依存関係の方向をマッピングします。
• 信頼できる唯一の情報源となるシステム、アーキテクチャレベルでのデータモデル、ライフサイクル、保持期間、一貫性、トランザクション境界を定義します。
• 公開 API、イベント、コマンド、スキーマ、エラー、冪等性、順序、バージョニング、互換性への期待事項を定義します。
• リスクに応じて、信頼境界、ID、認可、機密データ、シークレット、不正利用対策、監査要件を定義します。
• 真の制約でない限り、フレームワークやベンダーの詳細はコアモデルの外に置きます。

4. HLD と重要な LLD を作成する

• システムコンテキスト、デプロイ可能な単位、ストア、キュー、外部システム、責務、ラベル付きのデータフローを記述します。
• 重要なユーザージャーニーについて、正常終了、過負荷、依存先の障害、部分障害、再試行、タイムアウト、縮退、復旧、キャンセルを追跡します。
• 正確性、スケール、セキュリティ、または可逆性のリスクにより実装レベルの詳細が必要なコンポーネントのみ、詳細に検討します。
• オブザーバビリティ、SLI の測定ポイント、ヘルスチェック、デプロイ戦略、ロールバック、バックアップ、運用担当者の作業を定義します。
• 提案するトポロジーについて、所有権、チームへの影響、コスト要因、運用負荷を定義します。

5. 決定して検証する

• 要件、見積もり、障害時の挙動、複雑さ、コスト、移行、将来の発動条件に照らして、現実的な代替案を比較します。
• 選択した案と退けた案、それぞれの影響、感度の高い点、判断を再検討することになる前提条件を明記します。
• 独立した簡潔な意思決定記録に値する重要な決定を特定します。ただし、別のワークフローを必須にはしません。
• 重要な各要因に適したアーキテクチャの受け入れを示す証拠を定義します。例として、コントラクトチェック、負荷・障害実験、セキュリティ検証、復旧の実証、オブザーバビリティのシグナルがあります。前提条件と合格基準を指定し、設計中には実行しません。
• 完全な実装計画に踏み込まずに、現状から目標状態への影響と互換性要件の概要を示します。

6. 文書を作成して報告する

• コンテキスト、要因、見積もり、ドメイン、コントラクト、HLD、重要な LLD、障害と運用のモデル、セキュリティ、代替案、決定、検証、未解決の質問、進化の発動条件を記述します。
• 承認された範囲外の既存コンテンツを維持し、共有成果物へのリンクはドキュメントのパスまたはタイトルのみで示します。
• 提案を読み直し、裏付けのない事実、隠れた決定、抽象度の混在、正当化されていない仕組みがないか確認します。
• 実装計画の立案に進めるだけの決定事項がそろっている場合のみ READY を使用します。重要だが解決可能な不足がある場合は REVISE、必要な意図、証拠、権限、または提出先が得られない場合は BLOCKED を使用します。

セルフチェック

• 返却前に整合性を確認します。 項目ごとの証拠、要件の網羅性、矛盾、スコープ、判定、該当するクリーンアップを確認します。報告書または承認された成果物を修正します。有効な証拠を再利用し、リポジトリを自動的に再スキャンしたり、成功済みのコマンドを再実行したりしません。関連する変更、失敗、または未解決の証拠がある場合に限り、確認を繰り返します。残る不足を明示します。

出力契約

ユーザーの言語で、以下の順に報告してください。5つすべての項目を残し、各事実は一度だけ記載してください。少量の結果は各項目を1行にまとめてもかまいません。空の表は省略し、リンク先の成果物をコピーしないでください。

1. 結果： スキル固有の判定と、裏付けのある成果。
2. 対象範囲： レビュー／変更した範囲、対象外、ベースライン、重要な前提。
3. 根拠： 以下のスキル固有の項目。事実、推論、未検証の主張を区別してください。成果物にリンクし、必要に応じて表を使用してください。
4. 検証： チェックと結果、入手できない根拠、該当するクリーンアップ／外部状態。
5. 完了状況： Checklist: X/Y complete。Incomplete: None、または各 UNPROVEN 項目について、その理由、成果への影響、具体的な次のアクションを記載してください。残存リスクと必要な判断も記載してください。

スキル固有の根拠： 成果物のパス、要件、見積もり、境界、契約、HLD／重要なLLD、選択した判断、代替案、根拠、再検討のトリガー。検証／移行の必要事項、互換性、ロールアウト、ロールバック、可観測性、実装計画に影響する未解決の選択肢のみを要約してください。