あなたは Next.js アプリを実装するエンジニアです。
作業対象は、現在の作業ディレクトリ（本プロジェクトのルートフォルダ）です。

# 前提
- まずルートの requirements.md を読み、§6（機能要件）/§7（非機能）/§8（技術スタック）を満たす実装を行う。
- requirements.md を正典とし、本プロンプトはその実装方針を具体化したもの。矛盾があれば実装前に質問する。
- output/ には Cowork 生成済みの会議データがある想定。無い場合は §5 のスキーマに沿ったダミーを1〜2件作って動作確認してよい。

# 作るもの
プロジェクトルートの app/ に Next.js（App Router）+ TypeScript のローカル Web アプリを実装する。

# データの読み書き（最重要・契約。requirements.md §5）
- データルートはプロジェクトルート（app/ の1つ上）。環境変数 DATA_ROOT で上書き可、デフォルトは app/ の親ディレクトリ。
- 会議：output/<meetingId>/ を走査。各フォルダの
  - minutes.md … gray-matter で frontmatter(id, title, date, attendees, source) と本文に分離
  - tasks.json … { meetingId, tasks:[{ id, title, description, assignee, due }] }
- ステータス：state/task-status.json … { "<taskId>": { status, updatedAt } }
  - 値は todo | in_progress | done。未登録のタスクは todo 扱い。
  - 更新は Route Handler 経由で、一時ファイル→rename の原子的書き込み。state/ や task-status.json が無ければ作成する。
- output/ 配下（minutes.md, tasks.json）は読み取り専用。絶対に書き換えない。書き込みは state/task-status.json のみ。

# 画面（3つ）
1. 会議一覧 /
   - output/ の会議を日付降順で一覧。タイトル / 日付 / タスク総数 / 未完了数 を表示。
   - タイトルで簡易絞り込み。行クリックで議事録詳細へ。
2. 議事録詳細 /meetings/[id]
   - minutes.md を Markdown レンダリング（react-markdown + remark-gfm）。frontmatter のメタを上部に表示。
   - 当該会議のタスクをステータス付きで表示。ここでもステータス変更可。
3. タスクボード /tasks（全会議横断）
   - 全タスクを集約。フィルタ：ステータス / 担当者 / 期限（期日超過・今週）/ 会議。
   - 検索：タイトル・説明のフリーワード。ソート：期限・会議日。
   - 各行でステータスをインライン変更（todo→in_progress→done）。出典会議へのリンクを付ける。

# ステータス変更 UX
- セグメント or ドロップダウンで3状態を切替。変更時に PATCH /api/tasks/[taskId]/status を呼び state を更新。楽観的更新で可。

# 技術・方針（§7/§8）
- Markdown: react-markdown + remark-gfm、frontmatter: gray-matter
- スタイリング: Tailwind CSS（簡潔に。過度な装飾は不要）
- 認証なし、localhost 前提、DB 不要（プレーンファイルのみ）
- ファイル欠損・JSON 不正は握りつぶさず、画面に分かる形で警告（アプリをクラッシュさせない）
- 期日超過・今週などの日付判定はローカルタイム基準
- 文字コード UTF-8 / 日本語

# 受け入れ基準（§12）
- output/ に会議フォルダを置くと会議一覧に出る
- 議事録詳細で minutes.md が整形表示される
- タスクボードで全会議のタスクが集約され、フィルタ・検索・ソートが効く
- ステータス変更後にリロードしても保持される（state/task-status.json に永続化）
- output/ のファイルは一切変更されない

# 成果物
- app/ 配下に動くアプリ一式
- 起動手順を app/README.md に記載（npm install → npm run dev → http://localhost:3000）

# 進め方
- 最初に実装計画を簡潔に提示してから着手。大きな設計判断（データルートの解決方法、ステータスUI 等）は必要なら質問する。
