implementation-approach

# 実装戦略選択フレームワーク（メタ認知的アプローチ） ## メタ認知的戦略選択プロセス ### Phase 1: 現状の包括的分析 **核心質問**: 「既存の実装はどうなっているのか？」 #### 分析フレームワーク ```yaml アーキテクチャ分析: 責務分離、データフロー、依存関係、技術的負債 実装品質評価: コード品質、テストカバレッジ、パフォーマンス、セキュリティ 歴史的文脈理解: 現在の形の理由、過去判断の妥当性、制約���変化、要求の進化 ``` #### メタ認知質問リスト - この実装の真の責務は何か？ - どの部分がビジネス本質で、どの部分が技術的制約由来か？ - コードから明確でない依存関係や暗黙の前提条件は何か？ - 現在の設計がもたらしている利点と制約は？ **完了証跡**: 確認したパス、観測したアーキテクチャ・データフローの事実、既知の制約、推測と明記した歴史的背景、不明点のうち戦略選択を変え得るもの。 **移行条件**: 戦略に関係するすべての主張が、観測済み、根拠付きの推測、または不明として明記されている場合に次へ進む。 ### Phase 2: Design Convergence **核心質問**: 「現行の必要な成果を届ける最小の設計は何か。そこから先の追加は、どの根拠が要求しているのか？」 実装戦略の探索に入る前に、以下を順に完了させる： 1. **Direct MVP**: 既存のシステム機能を使って現行の必要な成果を届ける、最も単純なエンドツーエンドの設計を記述する。明示されたユーザー要件と確定済みの判断は拘束力を持つ。提案や選択肢として示された技術手段は、必須と確定されるまでは候補にとどまる。 2. **失敗チェック**: Direct MVP を、現行要件、検証済みの制約、確定済みスコープまたは成果に必要な依存の範囲内で観測された問題、根拠のある重大リスクに照らして検証する。満たせない項目だけを根拠とともに `Failed Items` として記録し、すべて満たす場合は `None` と記録する。その範囲外の問題は、スコープ判断のために別途報告する。 3. **的を絞った拡張**: `Failed Items` ごとに、まず既存の設計サーフェス内での解決を検証する — 再利用、既存データからの導出、オンデマンド計算、現在の呼び出し側または境界での責務保持。これらで解決できない場合に、十分な最小の追加を選択する。`Adopted Additions` として、追加 → 対応する Failed Item → より小さいサーフェスでの解決が成立しない根拠、の形で記録する。追加には対応する Failed Item が必要である。 4. **減算チェック**: `Adopted Additions` を1つずつ一時的に取り除き、対応する Failed Item を再検証する。項目が再び満たせなくなる場合にその追加を残す。ステップ3で検討したが採用しなかった選択肢を、簡潔な理由とともに `Rejected Additions` として記録する。ステップ3で不採用の候補がなかった場合は `None` と記録する。 **Design Docへの出力**: `Direct MVP`、`Failed Items`、`Adopted Additions`、`Rejected Additions`。 **完了証跡**: 4つの出力すべてが記録されていること。`Failed Items` ごと...