Review Roughcut

---
name: review-roughcut
description: Use when timeline.json exists and the user asks to review the rough cut, critique the edit, or generate review_report.yaml and review_patch.json.
metadata:
  filePattern:
    - '**/06_review/review_report.yaml'
    - '**/06_review/review_patch.json'
  bashPattern: []
---
# review-roughcut

## いつ使うか（必ず発火する条件）

- ユーザーが「レビューして」「粗編集を評価して」「review_report.yaml を作って」と言ったとき
- `full-pipeline` の Step 7 として呼ばれたとき
- `compile-timeline` が `05_timeline/timeline.json` を新規作成または更新した直後
- `scripts/compile-timeline.ts --patch ...` で patch apply 後の `timeline.json` が更新された直後
- `timeline.json`、`06_review/human_notes.yaml`、`STYLE.md` のいずれかが変わり、既存 review artifact が stale になったとき

**compile の直後に review を省略してはいけない。** `timeline_version` が変わったら前回の
`review_report.yaml` / `review_patch.json` は再評価対象とみなす。

## 前提条件

- `schemas/review-report.schema.json` と `schemas/review-patch.schema.json` を守ること
- `runtime/commands/review.ts` の preflight / promote / state transition と整合すること
- `/review` preflight は deterministic に以下を行う
  1. compile
  2. placeholder `05_timeline/review.mp4` の生成
  3. `05_timeline/review-qc-summary.json` の生成
  4. roughcut critique
  5. patch safety guard
- `06_review/human_notes.yaml` がある場合は `schemas/human-notes.schema.json` に合わせて読むこと
- current repo の `review.mp4` は実レンダではなく JSON stub。直接視聴ベースの断定は避け、timeline / QC からの推論であることを明示すること
- compile gate / planning gate / timeline schema validation が preflight で落ちた場合、これは critic の `FATAL` 判定ではなく command failure (`GATE_CHECK_FAILED`) として止まる

## 評価の優先順

### 1. evidence の優先順

- `human_notes.yaml`
- brief / blueprint との factual mismatch
- `timeline.json` / `review-qc-summary.json` / markers / quality flags
- AI-only craft / style inference

### 2. critique baseline の順序

- brief mismatch
- blueprint mismatch
- technical deliverability
- craft / style

taste-level のコメントで factual mismatch を覆い隠さない。

### 3. craft 判断の優先順位

craft 上のトレードオフは Walter Murch の Rule of Six で並べる。

- `emotion > story > rhythm > eye_trace > plane_2d > space_3d`

2D / 3D continuity が改善しても、emotion や story を弱めるなら減点する。

**`references/review-rubric.md` を必ず参照すること。**

## やること（ステップ）

### Step 1: deterministic metrics を生成して確認する

- まず `npx tsx scripts/review-metrics.ts <project-dir>` を実行し、`06_review/review_metrics.json` を生成する
- `/review` コマンド経由では preflight 後、critic agent の前に `review_metrics.json` が自動生成される
- `review_metrics.json` の `checks[].status` が `fail` / `warn` の項目は、`review_report.yaml` の `fatal_issues` / `warnings` / `mismatches_to_blueprint` に機械的に転記する
- LLM は metrics が測れない主観的判断に集中する:
  - カットの気持ちよさ
  - 物語の説得力
  - 感情の立ち上がり / 余韻
  - 2D / 3D continuity を犠牲にしてでも emotion / story を優先すべき箇所
- 定量チェックを LLM の注意力に依存させない。Rule of Six のうち、決定論的に測れる違反は `review_metrics.json` を正とする

### Step 2: preflight の成否と artifact を確認する

- 現在の `05_timeline/timeline.json` を正とする
- `05_timeline/review.mp4` と `05_timeline/review-qc-summary.json` を確認する
- `review.mp4` が placeholder の場合は、`summary_judgment.rationale` や `details` で inference ベースの評価であることを曖昧にしない

### Step 3: factual mismatch を先に切る

- `must_have`, `must_avoid`, `message.primary`, `audience.primary`, `emotion_curve` を確認する
- `edit_blueprint.yaml` の beat purpose, required role coverage, pacing intent と `timeline.json` の実際を照合する
- factual mismatch を見落としたまま taste の話に進まない

### Step 4: rubric に沿って評価する

- `references/review-rubric.md` の構成 / 感情 / リズム / 技術チェックを順番に見る
- 重要な指摘にはできるだけ `evidence`, `affected_beat_ids`, `affected_clip_ids` を付ける
- 直接観測と推論を混ぜない
- 短尺SNSでは `social_hook_treatment_valid`, `social_visual_refresh_valid`, `social_title_copy_fit_valid`, `social_cta_treatment_valid`, `social_audio_policy_valid` を確認する。brief がCTAを要求する場合、登録済み `cta-card` が終盤35%に2秒以上あることを完成条件にする

### Step 5: `review_report.yaml` を作る

必須 section:

- `summary_judgment`
- `strengths`
- `weaknesses`
- `fatal_issues`
- `warnings`
- `mismatches_to_brief`
- `mismatches_to_blueprint`
- `recommended_next_pass`

### Step 6: 判定を決める

#### `PASS`

- 意味:
  technical deliverability に blocker がなく、構成 / 感情 / リズムにも重大な再編集要求がない
- report への書き方:
  - `summary_judgment.status: approved`
  - `fatal_issues: []`
- runtime 上の意味:
  critic judgment が通っただけで、project state は operator accept まで自動で `approved` にならない

#### `needs_revision`

- 意味:
  technical blocker はないが、hook / pacing / beat order / clip choice / audio policy などに改善余地がある
- report への書き方:
  - `summary_judgment.status: needs_revision`
  - `fatal_issues: []`
- 次アクション:
  localized fix が safe op に落ちるなら patch を出す

#### `FATAL`

- 意味:
  preflight 通過後なお、意図した message / coherence / technical deliverability を壊す blocker が残る
- report への書き方:
  - `summary_judgment.status: blocked`
  - `fatal_issues` を必ず埋める
  - `recommended_next_pass.goal` で compile 再実行や blueprint 見直しの要否を明示する
- 次アクション:
  unsafe patch でごまかさず、root cause を report に残す

## `review_patch.json` の生成ルール

- `/review` では `06_review/review_patch.json` を artifact として常に作る
- safe op がない場合も空 patch を作る

基本 shape:

```json
{
  "timeline_version": "<timeline.json version>",
  "operations": []
}
```

`operations` を入れてよい条件:

- 問題が局所的で、safe / deterministic / machine-executable な修正に落ちる
- `reason` が 1 op ごとに明確
- `evidence` が report の指摘と結び付いている

safe rule:

- `replace_segment`
  - `target_clip_id` の `fallback_segment_ids` に含まれる segment
  - または `human_notes.yaml` の `approved_segment_ids` に含まれる segment
- `insert_segment`
  - `human_notes.yaml` に `directive_type: insert_segment` と machine-readable anchor がある場合のみ
- `trim_segment`, `move_segment`, `remove_segment`, `change_audio_policy`, `add_marker`, `add_note`
  - target が一意で、意図と副作用を説明できる場合のみ

safe に直せない場合:

- issue は report に残す
- patch は `operations: []` にする
- 無理に unsafe な `replace_segment` / `insert_segment` を作らない

**`references/patch-patterns.md` を参照し、自然言語の改善提案を schema-valid な op に落とすこと。**

## 出力 artifact

- `06_review/review_metrics.json`
- `06_review/review_report.yaml`
- `06_review/review_patch.json`
- `05_timeline/review.mp4`
- `05_timeline/review-qc-summary.json`

## 注意事項

- `human_notes.yaml` が AI 判断と衝突した場合は human note を優先し、AI 側は `alternative_directions` に退避する
- `PASS` でも warning はありうる。warning だけで `fatal_issues` に昇格させない
- `FATAL` でも、原因が preflight hard failure なら review artifact ではなく command failure になる
- `replace_segment` / `insert_segment` は patch safety guard で filtering される。reject される前提の op に依存した report を書かない