Memory Bank MCP Server

{ "schema": "memory_document_v2", "metadata": { "id": "template-ts-schema-integration-plan", "title": "スキーマパッケージとの統合を考慮したテンプレートTS化計画", "documentType": "design_document", "path": "template-ts-schema-integration-plan.json", "tags": [], "createdAt": "2025-04-11T14:00:00.000Z", "lastModified": "2025-04-11T11:58:33.336Z" }, "content": { "sections": [ { "title": "パッケージ間の依存関係", "content": "現状の分析：\n\n1. **パッケージ構造**\n - `@memory-bank/schemas`: スキーマ定義パッケージ\n - `@memory-bank/mcp`: MCPサーバー本体（テンプレート実装を含む）\n\n2. **依存関係**\n - `@memory-bank/mcp` は `@memory-bank/schemas` に依存している\n - `@memory-bank/schemas` には現在テンプレート関連の型定義は含まれていない\n\nこの構造を活用し、二重管理のリスクを最小化する方針を採用します。" }, { "title": "統合アプローチ", "content": "### 選択した方針：スキーマパッケージでの型定義、MCPでの実装\n\n1. **型定義の移動**\n - `@memory-bank/mcp/src/templates/types.ts` の型定義を `@memory-bank/schemas` パッケージに移動\n - テンプレート関連の型を `@memory-bank/schemas/src/templates` ディレクトリに新設し管理\n\n2. **テンプレート実装**\n - 具体的なテンプレートインスタンスは引き続き `@memory-bank/mcp` パッケージで管理\n - ただし、型情報は `@memory-bank/schemas` からインポート\n\n3. **段階的アプローチ**\n - まず型定義のみを移動し、既存コードへの影響を最小化\n - その後、テンプレートをJSONからTypeScriptに移行\n - 最後に参照を更新して整合性を確保\n\nこのアプローチにより、型の一元管理とコードの分離を実現します。" }, { "title": "実装ステップの更新", "content": "### ステップ1: スキーマパッケージにテンプレート型定義モジュールを追加\n\n1. `@memory-bank/schemas/src/templates` ディレクトリを作成\n2. `@memory-bank/schemas/src/templates/index.ts` を作成して型定義をエクスポート\n3. `@memory-bank/schemas/src/index.ts` を更新してtemplatesモジュールをエクスポート\n\n```typescript\n// @memory-bank/schemas/src/templates/index.ts\n\n/**\n * テンプレート関連の型定義\n */\n\n// テンプレートのメタデータ\nexport interface TemplateMetadata {\n id: string;\n titleKey: string;\n descriptionKey: string;\n type: 'system' | 'user' | 'project';\n lastModified: string;\n}\n\n// テンプレートのセクション\nexport interface TemplateSection {\n id: string;\n titleKey: string;\n contentKey: string;\n isOptional: boolean;\n}\n\n// テンプレートの内容\nexport interface TemplateContent {\n sections: TemplateSection[];\n placeholders: Record<string, unknown>;\n}\n\n// テンプレートのスキーマ\nexport interface Template {\n schema: 'template_v1';\n metadata: TemplateMetadata;\n content: TemplateContent;\n}\n```\n\n### ステップ2: package.json の更新\n\n```json\n// @memory-bank/schemas/package.json の「exports」セクションに追加\n\"./templates\": {\n \"import\": \"./dist/templates/index.js\",\n \"types\": \"./dist/templates/index.d.ts\"\n}\n```\n\n### ステップ3: MCPパッケージでの型定義の参照更新\n\n```typescript\n// @memory-bank/mcp/src/templates/types.ts を更新\n\n/**\n * テンプレート関連の型定義\n * @deprecated この型定義は @memory-bank/schemas パッケージに移動しました\n */\nexport * from '@memory-bank/schemas/templates';\n\n// 言語タイプ（まだschemas側に移動していないため残す）\nexport type Language = 'en' | 'ja' | 'zh';\n```\n\n### ステップ4: テンプレート定義ディレクトリの作成（既存計画通り）\n\n```typescript\n// @memory-bank/mcp/src/templates/definitions/rules.ts\n\nimport { Template } from '@memory-bank/schemas/templates';\n\nexport const rulesTemplate: Template = {\n schema: \"template_v1\",\n metadata: {\n id: \"rules\",\n titleKey: \"template.title.rules\",\n descriptionKey: \"template.description.rules\",\n type: \"system\",\n lastModified: \"2025-04-11T12:45:00.000Z\"\n },\n content: {\n // ...\n }\n};\n```\n\n### ステップ5: JsonTemplateLoaderの更新（既存計画通り）\n\n```typescript\nimport { Template } from '@memory-bank/schemas/templates';\nimport * as templateDefinitions from '../../templates/definitions/index.js';\n\n// 型エイリアスの更新\ntype JsonTemplate = Template;\n```" }, { "title": "移行戦略の更新", "content": "### フェーズ1: 型定義のスキーマパッケージへの移行\n\n1. `@memory-bank/schemas/src/templates` ディレクトリと型定義ファイルの作成\n2. パッケージのエクスポート設定の更新\n3. スキーマパッケージのビルドと動作確認\n\n### フェーズ2: MCPパッケージでの型参照の更新\n\n1. `@memory-bank/mcp/src/templates/types.ts` の更新（リダイレクト）\n2. 既存のインポートパスが正常に機能することを確認\n3. 既存のテストが通ることを確認\n\n### フェーズ3〜5: 既存計画通りのテンプレートTS化\n\n1. テンプレート定義ディレクトリの作成\n2. rulesテンプレートのTS実装\n3. JsonTemplateLoaderの拡張\n4. テスト環境の整備\n5. 残りのテンプレートの移行\n\nこの分割アプローチにより、各フェーズでの変更を最小限に抑え、リスクを軽減します。" }, { "title": "テスト戦略の更新", "content": "### パッケージ間統合テスト\n\n新たに必要となるテスト：\n\n1. **スキーマパッケージのテスト**\n - 新しいテンプレート型定義のテスト\n - エクスポートの正常性確認\n\n2. **パッケージ間参照テスト**\n - `@memory-bank/mcp` から `@memory-bank/schemas/templates` へのインポートが正常に機能するか\n - 型定義に基づいたテンプレートの検証が機能するか\n\n3. **既存テストの修正**\n - インポートパスの変更に伴うテストコードの修正\n - モックオブジェクトの型定義更新\n\n### テスト順序\n\n1. まずスキーマパッケージの変更をテスト\n2. 次にMCPパッケージでの型参照更新をテスト\n3. 最後にテンプレートTS化に関するテストを実施" }, { "title": "リスクと対策", "content": "### 追加リスク\n\n| リスク | 対策 |\n|-------|------|\n| パッケージ間の循環参照 | 明確な依存方向を維持（schemas ← mcp の一方向のみ） |\n| 旧型定義への依存 | 段階的な移行と非推奨警告の追加 |\n| バージョン不整合 | monorepoでのバージョン管理と明示的な依存指定 |\n| ビルド順序の問題 | schemas→mcpの順でビルドするよう依存順序を明確化 |\n\n### 対策詳細\n\n1. **型定義の一時的な重複**\n - 移行期間中は両方のパッケージに型定義が存在する状態になるが、MCPパッケージではリダイレクトとして実装\n - 非推奨（deprecated）警告を追加して明示的に示す\n\n2. **既存コードへの影響最小化**\n - リダイレクトアプローチで、インポートパスを維持しつつ実装を移行\n - 全ての変更がテストでカバーされていることを確認\n\n3. **将来的な型定義の変更に備える**\n - スキーマバージョニングを考慮した設計\n - スキーマバージョンと型定義バージョンの整合性維持の仕組み検討" }, { "title": "調整が必要な点", "content": "### t3taさんに確認すべき項目\n\n1. **スキーマパッケージへの型定義移動の承認**\n - テンプレート型定義をスキーマパッケージに移動する方針の承認\n - 移行タイミングと優先度の確認\n\n2. **Language型の扱い**\n - 現在MCPパッケージで定義されている`Language`型も移動すべきか\n - それともドメイン固有の型として残すべきか\n\n3. **テストカバレッジ要件**\n - パッケージ間の統合に関するテスト要件\n - 特に注意すべきエッジケース\n\n4. **メンテナンス計画**\n - スキーマとテンプレートの整合性を長期的に維持する方法\n - 将来的な拡張に対するアプローチ" }, { "title": "実装スケジュール", "content": "### 修正版スケジュール\n\n| フェーズ | 作業内容 | 見積り時間 |\n|---------|----------|--------|\n| 1 | スキーマパッケージへの型定義追加 | 2時間 |\n| 2 | MCPパッケージでの型参照更新 | 1時間 |\n| 3 | テンプレート定義ディレクトリとテンプレート実装 | 4時間 |\n| 4 | JsonTemplateLoaderの拡張実装 | 2時間 |\n| 5 | テスト環境の整備と修正 | 3時間 |\n| 6 | 残りのテンプレートの移行 | 4時間 |\n| 7 | 最終テストとコードレビュー | 2時間 |\n\n**合計見積り時間**: 約18時間\n\n### 優先順位\n\n1. スキーマパッケージへの型定義追加（基盤整備）\n2. rulesテンプレートの実装（POC）\n3. JsonTemplateLoaderの拡張（動作確認）\n4. テスト環境の整備（品質保証）\n5. 残りのテンプレートの移行（完成）" }, { "title": "まとめ", "content": "スキーマパッケージとの連携を考慮したテンプレートTS化計画の更新により、以下の利点が得られます：\n\n1. **型定義の一元管理**\n - スキーマとテンプレートの型定義がschemasパッケージで一元管理される\n - 型の不整合リスクが低減される\n\n2. **関心の分離**\n - 型定義はスキーマパッケージで（宣言的な部分）\n - 実装はMCPパッケージで（実装的な部分）\n\n3. **移行の容易さ**\n - 段階的なアプローチにより、既存コードへの影響を最小限に抑制\n - 各ステップでのテストが容易\n\n4. **将来的な拡張性**\n - スキーマの進化に合わせてテンプレート型も進化させやすい\n - バージョニングの管理がしやすい\n\nこの計画に従って実装を進めることで、より保守性の高い、型安全なテンプレート管理システムを実現できます。" } ] } }