mocchalera evaluate-edit
いつ使うか
- select-clips / build-blueprint / compile-timeline / review-roughcut のプロンプトやロジックを変更した直後（回帰チェック）。
- 「編集の精度を測って」「ゴールデンと比較して」と言われたとき。
- 人間編集者が編集を承認した直後（新しいゴールデンとして登録する好機）。
前提知識
- ゴールデン =
project_state.yamlにapproval_record.approved_byがある承認済みプロジェクト。approved_by: operatorが人間ティアで最も信頼できる正解。 - スコアは 0–100。selects（0.35）/ timeline（0.45）/ blueprint（0.20）の重み付き合成。
- 詳細は
docs/eval-harness.mdを読む。
やること（ステップ）
A. コンパイラ/ポリシー変更後の回帰チェック（最頻ユース）
npm run eval -- --all --min-score 80
- exit 0 なら回帰なし。exit 1 なら下がったプロジェクトの Markdown レポート（
reports/eval/）を読み、どのメトリクスが落ちたか特定する。 - スコア低下が意図した改善なら、人間に再承認を依頼してゴールデンを更新する。意図しない低下なら変更をロールバックまたは修正する。
- 字幕タイミングを変更した場合は構造スコアだけで終わらせず、次も回帰対象にする:
- 通常字幕は許容lead（既定2フレーム）を超えて音声より先に出ていない
- protected revealの本文がanchor onsetより前のcueに含まれていない
- word timingのない発話途中anchorが文字数比例で推測されず、
unresolved_reveal_anchorで止まる speech_syncのインタビュー、講義、長尺字幕は過剰先行だけが直り、音声後へ一律遅延されていない
- BGM／音声ミキサーを変更した場合は、ジャンル別の演出評価と分けて次の制作契約を回帰対象にする:
- 通常BGMがレビュー済みライブラリ／BGM Pack由来で、手続き生成は明示的な
simple_soundに限定される - BGM入力を基準 -23 LUFSへ正規化してからeditorial gainを適用する
- ducking detectorはA1 clip占有区間ではなくdialogue waveformを使う
audio-mix-report.jsonが存在し、BGMありではwaveform_sidechain_v1、なしではdialogue_only_mastering_v1を記録する- 最終実測が -17〜-15 LUFS、true peak -1.5 dBTP以下に収まる
- source trimが
adelayより前、全体尺trimがamixより後にあり、同一branchにadelay=...,atrim=start=0が生成されない - 総尺差が1フレーム未満でも
raw_dialogue.wavの信号配置がtimeline window外ならdialogue_timeline_alignment_validがfailする - VFR素材の同期補正は選択済み映像フレームを固定し、測定残差を音声側で補正する
- 通常BGMがレビュー済みライブラリ／BGM Pack由来で、手続き生成は明示的な
- short-social / content element / handoffを変更した場合は、次の横断契約も対象テストで確認する:
- hook/titleのコピー上限と日本語の折返しが一致し、座布団やsafe areaからはみ出さない
- CTA要求時は登録済みfull-frame
cta-cardが終盤35%に2秒以上ある audio_policyが納品物ごとに明示され、BGM要求時はtimelineにmusic clipがある- cold openが「両方」「双方」「どちらも」など未解決のantecedentで始まらない
- Studioのsource fallbackでtimeline字幕が見え、完成previewでは二重表示されない
- editor packetへcaption sidecarとcaption approvalが同梱される
B. LLM ステージ（select-clips / build-blueprint）の変更評価
- ゴールデンの凍結入力を candidate プロジェクトへコピーする:
mkdir -p projects/eval-rerun-<name>
cp -R projects/<golden>/01_intent projects/<golden>/03_analysis projects/eval-rerun-<name>/
- 変更後のスキルで対象ステージだけ再実行する（/triage, /blueprint, /compile）。
- 比較する:
npm run eval -- --candidate projects/eval-rerun-<name> --golden projects/<golden>
- 判断に迷う差分は LLM ジャッジを足す（
GEMINI_API_KEY必須）:
npm run eval -- --candidate projects/eval-rerun-<name> --golden projects/<golden> --judge
C. ゴールデンの追加
人間編集者が編集を確定したら、そのプロジェクトの project_state.yaml に記録する:
approval_record:
approved_by: operator
approved_at: "<ISO8601>"
status: clean
登録ファイルは不要。npm run eval -- --list で検出を確認する。
出力 artifact
reports/eval/<mode>-<candidate>-<timestamp>.md（人間向け）reports/eval/<mode>-<candidate>-<timestamp>.json（機械向け）
注意事項
- self モードはゴールデンのファイルに一切書き込まない（tmp コピーで再コンパイル）。candidate 比較も読み取り専用。
- メトリクスは「ゴールデンとの一致」を測る。一致しない = 悪い、ではない。明確に改善した逸脱は人間の再承認でゴールデン側を更新するのが正しい運用。
- ゴールデンが3件未満の間はスコアのブレが大きい。結論を断定しない。