mece-plan-reviewlisted

`## 受け入れ条件` を BB (仕様) / WB (コード) で検証し、tier または Critical 候補に応じて Fresh Red Team を加える。PoC では通常使わない。 ## Inputs and tier 1. `$ARGUMENTS` のプラン、なければセッションの Plan File Info を読む。 2. `<plan>.analysis.md` の `## 受け入れ条件` がないか本文が空なら `不足入力: 受け入れ条件 (<絶対 analysis path>) — /define-acceptance-criteria を先に実行` と報告して終了する。 3. [references/init-common.md](references/init-common.md) と [references/ac-enumerate.md](references/ac-enumerate.md) に従い、AC を `AC-N` へ正規化する。列挙結果が0件でも同じ不足入力を報告し、Analyst起動・合成・書き込みをせず終了する。`${CODE_ROOT}` は plan の対象 repo、実装ファイルの共通 Git root、現在の Git root の順で解決する。辿れなければ `(対象コード不在)`。 4. tier は domain 名や「表示のみ」という自己申告ではな���、実際に変更する振る舞いで決める。auth / billing / payment / migration は **deep**、それ以外は **standard**。分析ファイルの `### Tier` が deep でも deep とし、lite は standard と読む。表示だけの変更は、値や認証状態を算出・生成しない場合に限り非リスクとする。 ## Evidence boundary [references/analyst-contract.md](references/analyst-contract.md) の閾値と JSONL 契約を適用する。 - BB は AC、プラン、仕様、公式資料、一般知識だけを使い、コードを読まない。 - WB の finding と判定根拠はコードだけから得る。AC とプランは照合対象と探索位置の特定だけに使い、仕様根拠にはしない。コード不在時は契約の既定に従う。 - Red Team には plan / AC 本文を渡さず、取得済み BB / WB の findings・AC 判定 JSONL と欠落ロール名だけを渡す。 - Critical は欠陥単独で害が成立する契約上の4類型だけ。件数を埋めない。Critical 0 なら MECE OK、1以上なら要修正。不十分 AC は別に改善する。 - 分析ファイルを書くのは main agent だけ。 ## Execute ### Standard main agent が BB と WB を情報源を混ぜず inline 実行する。 - Critical 候補 0: Red Team を省略し、`Critical: 0` と `Red Team skip のため未検出` を記録する。4分類は [references/red-team-checklist.md](references/red-team-checklist.md) を main agent が付与する。 - Critical 候補あり: 取得済み BB / WB の