# Launch Harness の設計

## 目的

ローンチの計画から制作、確認、告知、振り返りまでを一つのワークスペースで進める。運用中の社内版を変更せず、他の組織が自分の環境へ導入できる独立製品として再構成する。

## 製品の境界

- 1導入 = 1組織。組織間のデータは別のD1とWorkerへ分離する。
- ホーム、ローンチ一覧、詳細（概要・準備・告知・リンク・成果）、タスク、カレンダー、原稿、成果、設定、AI連携、操作履歴。
- ローンチ作成はテンプレートと開催日から逆算したタスクを同一トランザクションで登録する。
- 書き込みはこの製品専用のDBだけ。既存のBloomやLINE、メール、XのDBへの接続を含まない。
- 告知は下書き・確認待ち・承認済み・実施済みを分ける。承認後に原稿・日時・対象を変更すると承認が解除される。送信は各配信サービスで実行する。
- チャネルの実績は手動記録または権限付きAPIで取り込む。未入力と0を区別し、最終更新と出典を表示する。
- 管理者・確認者・編集者・閲覧者。APIトークンの権限は発行者の現在の権限以下。UIとAPIで同じ認可を適用する。

## 構造

画面（HTML/CSS/JavaScript）→ Worker の認証・入力検査 → ドメインAPI → 専用D1。

データはローンチ、タスク、告知原稿、リンク、日次成果、メンバー、セッション、トークン、監査履歴。表示データの取得と更新を分け、更新競合はリビジョン比較で409を返す。失敗時は入力を残し、再送を自動で行わない。アーカイブは復元可能にする。

## 検証方針

権限、CSRF、初期管理者、招待、セッション失効、入力検査、競合、原稿の承認解除、カレンダー日付、実績の未入力、エクスポート、導入再開を自動試験する。独立したローカルDBで操作を検証し、全画面を8幅で監査する。390px/1440pxは画像を目視する。配布物を新しいディレクトリから再インストールして検証し、GitHubのCIと配布アーカイブを照合する。

## 参考仕様

- [Cloudflare Workerと静的アセットのルーティング](https://developers.cloudflare.com/workers/static-assets/routing/worker-script/)
- [Cloudflare HTML handling](https://developers.cloudflare.com/workers/static-assets/routing/advanced/html-handling/)
- [MCP TypeScript SDK v1](https://ts.sdk.modelcontextprotocol.io/server)

画面は認証後に配信。`run_worker_first: true` と `html_handling: none` を使用する。MCPはローカルstdioブリッジから同じREST APIへ接続する。