Claude Code 指示書：「確定レビュー・キュー」機能の実装

openManidoc に、未確定ノードを一括で検証・確定するためのビュー「確定レビュー・キュー」を実装する。憲法第四条「信頼を確かめ合う道具」を実務に落とすことが目的で、監視ではなく確定作業の摩擦を減らすことを狙う。

実装の前提（先に確定させる方針）

• ローカル完結・MCPはローカルLLM専用という思想を崩さない範囲で実装する。ノード本文や検証状態がクラウドLLMへ送信される経路は作らない。
• 既存のワークスペース形式（{projectId}.json + {projectId}/images/、旧Manidoc互換）を壊さない。新機能はこの構造の上に追加する。

事前調査（実装前に必ず確認）

• 検証状態（draft / 未確定 / 確定）を全ノードがデータとして実際に保持できているかを確認する。保持していない場合はデータモデルへフィールドを追加し、既存ノードへの後方互換な移行（未設定は未確定扱いなど）を設計する。
• 出典ポインタ（元ファイルへの参照）が各ノードにどの形で入っているかを確認する。

機能要件

1. レビュー待ちキュー: draft / 未確定のノードをワークスペース横断で一覧化する。前回確定以降に AI が書き換えたノードも拾う。検知方式は「更新日時の比較」または「確定時に本文ハッシュを保存し差分を見る」等を比較検討し、確実な方を採用する。
2. 左に本文・右に一次ソース: 出典ポインタの元ファイルを並べて表示し、根拠を見ながら確定判断できるようにする。対応形式（Markdown / HTML / 画像 / PDF 等）の範囲は要検討。まずは Markdown を確実に対応し、他形式は段階的に。
3. 一操作確定と差し戻し: キーボードで次々に処理できるようにする（例：Enter で確定、Esc でスキップ）。既存ショートカットとの衝突を回避すること。未確定のまま保留も可能にする。
4. 確定履歴: いつ・どのノードを誰が確定したかを記録し、責任の所在を残す。保存場所は {projectId}.json 内か別ファイルかを既存データ構造との整合性を見て決める。

パフォーマンス

• ワークスペース横断でレビュー待ちを集める処理は、大量ノード時でも一覧化・検索が実用的な速度で動くこと。必要ならインデックスやキャッシュを検討する。

発展案（初期スコープ外だが設計時に考慮）

• レビューキューを「差分ハイライト表示」にし、AI が変更した箇所を色分けで見せる。
• 確定率をダッシュボード化し、ツリー全体の「確からしさ」を可視化する。

今回は扱わない（保留）

• 複数人でのロック競合・権限（第二条 統治主権）まわりは初期スコープから外す。単一使用者での確定フローを先に完成させる。

受け入れ基準

• 未確定 / AI 書き換えノードだけを集めたキュー画面から、マウスとキーボードだけで確定・保留・差し戻しが連続して行えること。
• 確定操作が履歴として理由とともに残ること。
• 既存ワークスペース・データ構造・ローカル完結の思想が保たれていること。