Unit of Work Plan — continuum

Project: continuum Phase: INCEPTION — Units Generation (Part 1: Planning) Date: 2026-05-08

目的

Application Design で定義された 18 コンポーネント / 6 サービスを、Construction フェーズで並列開発可能な独立した Unit of Work に分解する。MVP（Phase 2 / 5/30 予選）と決勝（Phase 3 / 6/26）のスコープを明確に区別し、AI フル実装下での並列処理を最大化する。

Mandatory Unit Artifacts（必須生成物）

• aidlc-docs/inception/application-design/unit-of-work.md — Unit 定義 + 責務 + 含むコンポーネント・ストーリー
• aidlc-docs/inception/application-design/unit-of-work-dependency.md — 依存マトリクス + 並列化機会 + 開発順序
• aidlc-docs/inception/application-design/unit-of-work-story-map.md — ストーリー × Unit マッピング
• Greenfield 必須: コード組織化戦略（ディレクトリ構造、Monorepo 構成、デプロイ単位）を unit-of-work.md に明記（Layer-based: frontend/backend/infrastructure/shared）
• Unit 境界と依存関係の検証
• 全 38 ストーリーが Unit に割当済みであることを保証

暫定 Unit 候補（Application Design §11 由来）

参考までに、Application Design で暫定提案した Unit 構成は以下：

これは出発点で、本プランの質問への回答により最終確定します。

Step-by-Step Execution Plan（Part 2 で実行）

• Step 1: 質問への回答に基づく Unit 構成の確定（10 Unit）
• Step 2: 各 Unit の責務・含むコンポーネント・含むストーリーを明文化（unit-of-work.md）
• Step 3: コード組織化戦略（Monorepo 内部構造 = Layer-based）を unit-of-work.md に追加
• Step 4: Unit 間依存関係マトリクス + 並列化機会の特定（unit-of-work-dependency.md）
• Step 5: 開発順序の確定（Phase 2 並列最大化 → Phase 3 決勝）
• Step 6: 38 ストーリー × Unit のフルマッピング（unit-of-work-story-map.md）
• Step 7: 全ストーリーが Unit に割当済みかの検証

質問（Embedded Questions）

以下の質問にお答えください。各 [Answer]: タグの後に該当する選択肢の文字を記入してください。

Question 1: Unit 粒度

Unit の粒度はどの程度がよいですか？（並列開発 + 管理コストのバランス）

A) 粗粒度（5〜6 Unit） — 機能領域単位で大きく分割。並列開発機会少ないが管理シンプル B) 中粒度（10 Unit） — 暫定提案通り。Frontend/Backend 統合 Unit + 専用 Unit の混在（推奨） C) 細粒度（15 Unit以上） — Frontend と Backend を別 Unit に分離。独立性最大だが管理オーバーヘッド大 D) AI 委任 — 暫定提案を基準に AI が判断 E) Other (please describe after Answer: tag below)

Question 2: Frontend と Backend の Unit 統合方針

Frontend View と関連 Backend Lambda は同一 Unit に含めますか？

A) 統合（Frontend + Backend を同一 Unit） — 1 Unit が垂直スライス（UI から DB まで）。MVP デモ単位で完結（推奨） B) 分離（Frontend Unit / Backend Unit を別個） — 専門性で分離。Frontend 専門・Backend 専門の並列開発に有利だがコンポーネント横断の調整コスト増 C) ハイブリッド — コア機能は統合 / 横断的機能（認証、Realtime）は分離 D) AI 委任 E) Other (please describe after Answer: tag below)

Question 3: MACP の Unit 分割方針

MACP 機能は Phase 2 簡易版 と Phase 3 Federated 本実装で実装方法が異なります。Unit としては？

A) 2 Unit に分離 — U-7 (Phase 2 Simulator) と U-8 (Phase 3 Federated) を独立 Unit に。スコープ明確 B) 1 Unit に統合 + Phase ラベル — U-MACP に統合し、Phase 2 / Phase 3 のスコープラベルで区別 C) AI 委任 D) Other (please describe after Answer: tag below)

Question 4: WebSocket 基盤の Unit 分割

WebSocket（Realtime）は専用 Unit にしますか？

A) 独立 Unit (U-9 Realtime) — Frontend WSClient + Backend WSBroker を独立 Unit に。MACP Demo・Recommendation 通知・バッジ通知を統一基盤として整備 B) U-7/U-8 MACP Unit に統合 — MACP デモ専用と捉えて MACP Unit に含める C) U-10 DemoSetPiece Unit に統合 — 決勝デモ目的のため演出 Unit に統合 D) AI 委任 E) Other (please describe after Answer: tag below)

Question 5: Demo Set Piece の Unit 化

Demo Set Piece（DS-1〜DS-4 = MACP 決勝演出）は専用 Unit にしますか？

A) 独立 Unit (U-10 DemoSetPiece) — 決勝向け演出 UI + 統合シナリオを独立 Unit に。Phase 3 専用 B) U-8 MACP-Federated に含める — MACP 機能群の一部として扱う C) AI 委任 D) Other (please describe after Answer: tag below)

Question 6: コード組織化（Monorepo の内部構造）

Monorepo（Q10=A 確定）の内部ディレクトリ構造はどうしますか？

A) Service-based — services/ 配下に各 Unit ディレクトリ（services/inbound/, services/outbound/ 等）。各 Service ディレクトリ内に frontend/backend/iac サブディレクトリ B) Layer-based — frontend/ backend/ infrastructure/ shared/ のレイヤー分離。各レイヤー内に Unit 別サブディレクトリ C) Hybrid (Recommended) — apps/ (frontend と backend を含むデプロイ単位) + packages/ (共有ライブラリ・型) + infrastructure/ (CDK)。pnpm workspace で管理 D) AI 委任 E) Other (please describe after Answer: tag below)

Question 7: デプロイ単位

CDK デプロイの単位（Stack 構成）は？

A) Single Stack — 全リソース 1 Stack。シンプルだが影響範囲大 B) Per-Unit Stacks — Unit ごとに Stack 分離。並列デプロイ可能、影響範囲限定 C) Layered Stacks — Foundation Stack（VPC/IAM/Cognito）+ Application Stack（Lambdas/API Gateway）+ Data Stack（DynamoDB）（推奨：本格的構成） D) AI 委任 E) Other (please describe after Answer: tag below)

Question 8: 並列開発の優先順位

Phase 2 MVP（5/16-5/30 約2週間）で並列開発する際、優先順位は？

A) Critical Path 重視 — Foundation → Inbound（コア）→ Maturity → 残り、を順次。並列度低いが堅実 B) 並列最大化 — 並列着手可能な Unit を同時開始。Foundation 完了後に他 Unit を並列 C) MACP 早期着手 — 簡易 MACP を早期に動作させて演出を確認、他 Unit と並走 D) AI 委任 E) Other (please describe after Answer: tag below)

Question 9: 共有コード（型定義・ユーティリティ）の取扱い

Frontend / Backend 間で共有される型定義（例: InboxMessage, Contact, MACPSession）は？

A) 専用パッケージ (packages/shared-types) — TypeScript 型定義を独立パッケージで管理（推奨、Q6=Cと整合） B) Backend に集約 + Frontend が import — 型定義を Backend 側に置き Frontend が参照 C) 重複定義 — Frontend / Backend で個別に定義（同期コスト発生） D) AI 委任 E) Other (please describe after Answer: tag below)

Question 10: AgentCore 連携層の独立 Unit 化

AgentCore（Runtime/Memory/Identity/Gateway）への抽象化レイヤーは？

A) 共有パッケージ (packages/agentcore-client) — 各 Backend Unit から共通利用される薄いラッパー。一元化で API 変更耐性 B) 各 Unit 内で個別実装 — 各 Unit が必要な AgentCore SDK を直接呼び出し C) 専用 Unit (U-AgentCore) — AgentCore 統合層を専用 Unit として切り出し D) AI 委任 E) Other (please describe after Answer: tag below)

Approval Required

すべての質問に回答後、「完了」または「done」 とお知らせください。回答内容を分析し、矛盾・曖昧さなしの場合は本プランの承認をお願いします。承認後、Part 2（unit-of-work.md, unit-of-work-dependency.md, unit-of-work-story-map.md の生成）に進みます。