akari-video 0.1.0

package/vendor/skills/analyze-footage/test/fixtures/scribe-punctuation-inflation.json

@@ -0,0 +1,17 @@
+{
+  "_note": "v4.1 実測を模した Scribe raw 応答。文末の無音が句読点トークン（type spacing）の end へ吸われ、末尾語の end が実発話より膨張するケースを固定する。数値は内部 dogfood-v4-1-repair 実走（2026-07-24）の実測（「ね。」2822.84→2826.84 = 4.0s / 「です。」相当 3728.939→3731.399 = 2.46s）に対応。",
+  "language_code": "jpn",
+  "words": [
+    { "text": "はい", "start": 2820.34, "end": 2821.10, "type": "word" },
+    { "text": "もう", "start": 2821.10, "end": 2821.62, "type": "word" },
+    { "text": "、", "start": 2821.62, "end": 2821.62, "type": "spacing" },
+    { "text": "書き出し", "start": 2821.62, "end": 2822.40, "type": "word" },
+    { "text": "終わりました", "start": 2822.40, "end": 2822.84, "type": "word" },
+    { "text": "ね", "start": 2822.84, "end": 2823.12, "type": "word" },
+    { "text": "。", "start": 2823.12, "end": 2826.84, "type": "spacing" },
+    { "text": "これ", "start": 3728.20, "end": 3728.60, "type": "word" },
+    { "text": "無料", "start": 3728.60, "end": 3728.939, "type": "word" },
+    { "text": "です", "start": 3728.939, "end": 3729.20, "type": "word" },
+    { "text": "。", "start": 3729.20, "end": 3731.399, "type": "spacing" }
+  ]
+}

package/vendor/skills/analyze-footage/test/normalize-scribe.test.mjs

@@ -0,0 +1,76 @@
+import { test } from "node:test";
+import assert from "node:assert/strict";
+import fs from "node:fs";
+import { fileURLToPath } from "node:url";
+import path from "node:path";
+
+import { normalizeScribe } from "../bin/transcribe-cloud.mjs";
+
+const here = path.dirname(fileURLToPath(import.meta.url));
+const fixture = JSON.parse(
+  fs.readFileSync(path.join(here, "fixtures", "scribe-punctuation-inflation.json"), "utf8"),
+);
+
+test("句読点トークンの無音を末尾語の end へ膨張させない（隙間の原則）", () => {
+  const segments = normalizeScribe(fixture);
+
+  // 文末の「。」で 2 文にセグメント化される。
+  assert.equal(segments.length, 2);
+
+  const [first, second] = segments;
+
+  // 第 1 文: 末尾語は「ね。」で、end は実発話の end（2823.12）を維持する。
+  // 句読点トークン「。」の膨張 end（2826.84）を吸わない。
+  assert.equal(first.text, "はいもう、書き出し終わりましたね。");
+  assert.equal(first.words.at(-1).text, "ね。");
+  assert.equal(first.words.at(-1).end, 2823.12);
+  assert.equal(first.end, 2823.12);
+  assert.notEqual(first.end, 2826.84);
+
+  // 第 2 文: 末尾語は「です。」で、end は実発話の end（3729.20）を維持する。
+  // 句読点トークン「。」の膨張 end（3731.399）を吸わない。
+  assert.equal(second.text, "これ無料です。");
+  assert.equal(second.words.at(-1).text, "です。");
+  assert.equal(second.words.at(-1).end, 3729.20);
+  assert.equal(second.end, 3729.20);
+  assert.notEqual(second.end, 3731.399);
+});
+
+test("句読点のみのトークンは独立 word として残さない", () => {
+  const segments = normalizeScribe(fixture);
+  for (const segment of segments) {
+    for (const word of segment.words) {
+      assert.ok(
+        !/^[。、！？!?,.]+$/.test(word.text),
+        `句読点のみの word が残っている: ${JSON.stringify(word)}`,
+      );
+    }
+  }
+});
+
+test("ゼロ幅の読点も直前語へ結合する（既存挙動の非退行）", () => {
+  const segments = normalizeScribe(fixture);
+  // 「もう」+ ゼロ幅「、」→「もう、」。end は「もう」の end（2821.62）のまま。
+  const mou = segments[0].words.find((word) => word.text.startsWith("もう"));
+  assert.equal(mou.text, "もう、");
+  assert.equal(mou.end, 2821.62);
+});
+
+test("words が無い応答は空配列を返す（非退行）", () => {
+  assert.deepEqual(normalizeScribe({}), []);
+  assert.deepEqual(normalizeScribe(null), []);
+  assert.deepEqual(normalizeScribe({ words: [] }), []);
+});
+
+test("句読点なし・2 秒以上の無音で文分割する（非退行）", () => {
+  const segments = normalizeScribe({
+    words: [
+      { text: "こんにちは", start: 1.0, end: 1.8 },
+      { text: "今日", start: 5.0, end: 5.4 },
+    ],
+  });
+  assert.equal(segments.length, 2);
+  assert.equal(segments[0].text, "こんにちは");
+  assert.equal(segments[0].end, 1.8);
+  assert.equal(segments[1].text, "今日");
+});

package/vendor/skills/analyze-footage/workflow.md

@@ -0,0 +1,95 @@
+# 分析ワークフロー
+
+## 原則
+
+原本を証拠、`analysis.json` を機械可読な所見として扱う。自動検出は候補生成に使い、最終判断は transcript、実フレーム、ffmpeg の客観情報を突き合わせて行う。確認できない事実を埋めない。
+
+## 1. 入力を固定する
+
+次を先に確認する。
+
+- 入力が読み取り可能な通常ファイルである。
+- `ffprobe` で映像ストリーム、duration、time base を取得できる。
+- duration が有限の正数である。
+- このスキルの `references/analysis.schema.json` を読める。
+- ソースの絶対パスと、JSON に書く相対パスを混同していない。
+
+映像ストリームがない、duration を確定できない、または ffmpeg がない場合は分析を完了扱いにしない。原因と止まった工程を報告する。
+
+## 2. 出力先を決める
+
+source がワークスペース内にあり、その祖先から `.akari/` を持つワークスペース root を特定できる場合は、source のワークスペース root からの相対パスを保った `.akari/sidecars/<source-relative-path>.analysis/` を正典の出力先とする。相対パスには `assets/` プレフィックスと source の拡張子を含める。
+
+```text
+<workspace-root>/
+├── assets/
+│   └── IMG_4606.MOV
+└── .akari/
+    └── sidecars/
+        └── assets/
+            └── IMG_4606.MOV.analysis/
+                ├── analysis.json
+                ├── proxy.mp4
+                ├── whisper-input.wav
+                ├── whisper.raw.json
+                ├── keyframes/
+                └── work/
+```
+
+`.akari/` を持つワークスペース構造を特定できない単体実行では、後方互換の出力先を使う。
+
+```text
+<source-dir>/
+├── <source-stem>.<ext>
+└── analysis/
+    └── <source-stem>/
+        ├── analysis.json
+        ├── proxy.mp4
+        ├── whisper-input.wav
+        ├── whisper.raw.json
+        ├── keyframes/
+        └── work/
+```
+
+単体実行の `<source-stem>` は最後の拡張子を除いたファイル名とする。既存の出力ディレクトリが同じ source を指す再分析なら再利用してよい。別 source を指す場合は `<source-stem>-<ext>`、それも衝突する場合は source の正規化絶対パスの SHA-256 先頭 8 桁を接尾辞にする。AKARI プロジェクト内の正典パスでも、最終セグメントの `<name>.analysis` に同じ衝突回避規則を適用し、別 source との衝突時は `<name>-<ext>.analysis`、さらに衝突する場合は SHA-256 先頭 8 桁を接尾辞にする。既存 `analysis.json` の `source` を解決して照合し、名前だけで同一素材と判断しない。
+
+JSON 内の `source`、`keyframes[].path`、`tracks.person_matte`（の `path`）の相対パスは、すべて **analysis.json のあるディレクトリ**を基準にする。上の AKARI 標準配置なら `source` は `../../../../assets/IMG_4606.MOV`、キーフレームは `keyframes/<filename>.jpg` となる。単体実行の標準配置なら `source` は `../../<source-filename>` となる。固定の `../` の個数を暗記せず、analysis.json のディレクトリと参照先の実際の階層から相対パスを機械的に算出すること。source が `assets/` 配下でネストしていれば、その深さに応じて必要な階層数も増える。絶対パスは可搬性を落とすため、同一ファイルツリー内を表せない場合に限る。
+
+## 3. 工程を順番に実行する
+
+1. ffprobe の結果を控える。
+2. 720p プロキシを生成し、映像をデコードできることを確認する。
+3. 音声があれば [media-and-transcript.md](media-and-transcript.md) の 3 層手順（Mac 既定 = SpeechAnalyzer / 共通フォールバック = whisper.cpp / クラウド = 決定カード経由オプトイン）で文字起こしする（可能なら word タイムスタンプ込み）。いずれも使えなければ明示的に劣化する。
+4. transcript から highlight 候補（重要発言）を下書きする（transcript が空ならスキップ）。
+5. プロキシから scene 候補・interval 候補・transcript 駆動候補（highlight 下書きの時刻）を系統別に抽出する。
+6. 候補の source 時刻を回収して統合し、Read で視認する。採用 keyframe に `origin` を記録する。
+7. transcript と視認所見から event を確定する（highlight 下書きは視認結果と突合して確定・棄却する）。
+8. tracks を組み立てる。人物演出を使うと決めた素材でだけ、任意工程として人物マットを生成する（[person-matte.md](person-matte.md)）。既定は `person_matte: null` のまま進む。
+9. 一時 JSON を Schema 検証・意味検証し、成功したものだけ `analysis.json` に置き換える。
+
+プロキシは時間を trim しない。プロキシと原本の時刻対応が崩れた場合は、以降の時刻を原本基準へ補正できるまで停止する。
+
+## 4. 完了報告を出す
+
+短い報告に次を含める。
+
+- source と確定した `analysis.json` のパス
+- transcript、keyframe、event 各件数（keyframe は origin 系統別、event は type 別の内訳付き）
+- `words` を省略した segment 数と理由
+- 文字起こしに使用した backend（speechanalyzer/whisper-cpp/scribe/groq）と選定理由・フォールバックした場合はその理由（[media-and-transcript.md#provenancebackendの記録](media-and-transcript.md#provenancebackend-の記録)）
+- 使用した ffmpeg、whisper.cpp 実行ファイル、モデルのパス
+- `transcript: []` へ劣化した場合の理由と探索済み場所
+- 人物マットを生成した場合はその quality・処理時間・出力サイズ、生成しなかった場合は理由（既定は「人物演出を使わないため未生成」）
+- Read できなかった画像、未実施の Schema 検証、未確認の音声・人物情報
+- 初期閾値を変更した場合の値と理由
+
+劣化理由は Schema 外のフィールドとして JSON に足さず、完了報告に書く。
+
+## よくある間違い
+
+- 複数素材を 1 個の `analysis.json` にまとめる。
+- 素材別の `<workspace-root>/.akari/sidecars/<source-relative-path>.analysis/analysis.json`（単体実行では `<source-dir>/analysis/<source-stem>/analysis.json`）を使わず、共通の `analysis.json` を素材ごとに上書きする。
+- プロキシの連番フレーム番号を秒だとみなす。
+- transcript がないのに映像だけから発話内容を創作する。
+- 一時生成物の絶対パスを JSON に固定する。
+- Schema が通っただけで `end > start` やファイル存在確認を省く。

package/vendor/skills/analyze-project/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: analyze-project
+description: プロジェクト内の素材群（analysis.json）と周辺プロジェクト文脈（intake.json・edit.json・planning/・README・過去 PJ）を読み合わせて interpretation.json（解釈層）を作り、事実 + 素材の読みに限定した読み取り専用の分析レポートを描画するスキル。複数素材プロジェクトの内容を素材横断で把握したいとき、analyze-footage が素材ごとの分析を終えたあとの統合、方向性を決める前に一次情報の欠落（取材質問）を洗い出したいときに使う。edit-plan は方針決めの前提としてこのスキルの出力を読む。
+---
+
+# プロジェクトを分析する
+
+> **Language**: Respond in the user's language — 対話・質問・承認確認・レポートはユーザーの使用言語に合わせる（例: 英語で話しかけられたら英語で応答する）。
+
+## ハードルール
+
+- **1 パス目を再実行しない**。素材ごとの事実抽出（STT・フレーム解析等の重い処理）は既存
+  [analyze-footage](../analyze-footage/SKILL.md) の analysis.json に委ね、無い素材だけ 1 素材 1 実行で
+  実行する。既存 analysis.json は無改修で使う。
+- **2 パス目は素材の再視聴をしない**。1 パス目の出力テキスト（transcript・keyframe note・events）を
+  並べて読み直すテキスト推論に限る。素材へ戻るのは、2 パス目がピンポイントで必要と判断した箇所だけ。
+- **2 パス目の入力は analysis.json 群に閉じない**。プロジェクトの周辺文脈
+  （intake.json・edit.json・`planning/`・README・過去 PJ 参照があればそれも）を読む。
+  analysis.json だけでは素材の由来判定（orphan/unclear 等）に確信を持てない実例が
+  実地検証（内部リポの multiasset-dogfood 実走・2026-07-22）で確認されている。
+- **周辺プロジェクト文脈の読み合わせに `memory` 接続を含める**。`.akari/connections.json` に
+  `memory` 宣言（[contract-2026-07-25-memory-connection-v0.md](../../docs/contract-2026-07-25-memory-connection-v0.md)）
+  があれば、`entry`（省略時 `INDEX.md`）起点で `include`/`exclude` の範囲だけを読み、
+  `interpretation.json` の `inputs.context` に参照ファイルパスを出所として記録する。全文投入は
+  禁止。宣言が無ければ何もしない（error にしない）。
+- **解釈の全主張に根拠を必須とする**（`assets[].summary`/`role`/`relations`/`flags`、`arc[]` の
+  すべて）。根拠は transcript の引用区間または keyframe note 参照に限り、捏造ゼロを守る。
+  根拠を示せない主張は書かない（穴が残るなら open_questions へ）。
+- **open_questions は取材質問のみ**。「どうしますか」（判断）を聞かない。素材にもネットにも
+  載っていない一次情報だけを聞く（例文は [interpretation.md](interpretation.md) と
+  [references/open-questions-examples.md](references/open-questions-examples.md) を見る）。
+- **停止条件（80 点ライン）= 構成案（arc）が事実の捏造なしに一本通るか**。通れば取材フェーズを
+  終える。それ以降の疑問は編集後の微調整（`edit-plan` 側）へ送る。
+- **arc（構成案）はレポートに表示しない**。schema データとしては `interpretation.json` に残す
+  （取材質問の生成源 + 対話フェーズで AI が提案する種）。表示除去は 2026-07-22 改訂で確定済み。
+- [interpretation.schema.json](../../packages/schemas/interpretation.schema.json) にない
+  補助フィールドを追加しない。`validate-interpretation.mjs` が PASS した JSON だけを確定版にする。
+- **レポートに決定 UI（選択肢・ツマミ・確定ボタン）を一切置かない**。方向性はチャットで決める。
+  「どうしますか」ではなく、根拠を示した上で AI が提案する。
+- **判断記録は既存の decision_log 慣行（edit-plan 系）に接続する**。新形式を発明しない。
+  詳細は [decision-record.md](decision-record.md)。
+- OpenMontage は構造上の参考に限り、AGPL の文章・コードを転写しない。
+
+## 実行順と目次
+
+1. [collect.md](collect.md) を読み、プロジェクト内の素材を列挙し、analysis.json の有無を
+   確認する。無い素材だけ analyze-footage を 1 素材 1 実行で走らせる。
+2. [interpretation.md](interpretation.md) を読み、全 analysis.json + 周辺プロジェクト文脈を
+   読み合わせ、根拠必須・捏造ゼロの規律で `interpretation.json` を作る。
+3. [validate-and-render.md](validate-and-render.md) を読み、`validate-interpretation.mjs` で
+   PASS を確認してから renderer（`--analysis <ref>=<path>` 形式）でレポートを生成し、開く。
+4. open_questions が残る場合だけ [interview.md](interview.md) を読み、チャットで取材する
+   （「どうしますか」禁止）。回答を得たら interview へ昇格し、interpretation とレポートを
+   再生成する（手順 2〜3 に戻る）。
+5. [decision-record.md](decision-record.md) を読み、取材の Q&A と 2 パス目の主要判断を
+   判断記録へ残す。
+
+詳細を先読みせず、現在の工程に対応するファイルだけを読む。

package/vendor/skills/analyze-project/collect.md

@@ -0,0 +1,51 @@
+# 素材収集
+
+## 原則
+
+素材ごとの事実抽出（1 パス目）と、素材横断の解釈（2 パス目）を分離する。1 パス目は
+[analyze-footage](../analyze-footage/SKILL.md) の役割のまま変えず、このスキルは「揃っているか
+確認し、無ければ埋める」だけを行う。同じ素材を 2 回分析しない。
+
+## 1. プロジェクトの素材を列挙する
+
+対象プロジェクトディレクトリ（明示された場合はそれ、無指定なら `assets/` 配下・プロジェクト
+直下の動画/静止画/音声ファイル）を列挙する。列挙対象が不明な場合は、ユーザーに対象パスを
+確認してから進む（これは判断質問ではなく、作業対象を確定するための入力確認）。
+
+## 2. 素材ごとに既存分析の有無を確認する
+
+[edit-plan/workflow.md §2](../edit-plan/workflow.md#2-素材の有無で分岐する) と同じ探索順序を使う。
+
+1. ユーザーが明示した `analysis.json`
+2. `<source-dir>/analysis/<source-stem>/analysis.json`
+3. 素材専用ディレクトリであると確認できる場合だけ `<source-dir>/analysis/analysis.json`
+
+`source` が対象素材を指すことを確認してから再利用する。素材が更新された疑いがあれば
+再分析するか、人間へ差分を示す（鮮度の推測はしない）。
+
+## 3. 無い素材だけ analyze-footage を実行する
+
+有効な分析がない素材は、1 素材 = 1 実行として [analyze-footage](../analyze-footage/SKILL.md) を
+呼ぶ。複数素材なら並列に割り当ててから全件を待つ。各依頼には source の絶対パス・リポジトリ
+ルート・analyze-footage の SKILL.md を渡し、他素材や本スキルの成果物を編集させない。
+
+## 4. 素材参照表（ref 表）を作る
+
+全素材について、プロジェクト内で一意な `ref`（例: 素材ファイル名の stem、または
+プロジェクト固有の呼称）と、対応する analysis.json への絶対または相対パスを対応付ける。
+この対応表がそのまま `interpretation.json` の `inputs.analyses[]`（`ref` / `path` / `source`）に
+なり、[validate-and-render.md](validate-and-render.md) の renderer 呼び出し
+（`--analysis <ref>=<path>`）の `ref` としてもそのまま使う。
+
+`ref` は 1 度決めたら 2 パス目・レポート生成・取材の全工程で一貫させる（`assets[].ref` /
+`arc[].refs[].asset` / `relations[].target` すべてがこの `ref` を参照するため、途中で
+書き換えると FK が壊れる）。
+
+## よくある間違い
+
+- 分析済みの素材を再度 analyze-footage にかける（1 パス目の再実行はしない）。
+- 複数素材を 1 回の analyze-footage 実行にまとめる（素材ごとの証拠境界が失われる）。
+- `ref` をファイルパスそのものにして、後で相対パスの基準が変わると参照が壊れる状態にする
+  （`ref` は場所に依存しない安定 ID にする）。
+- `analysis.json` から見た相対パス（`source` や `keyframes[].path`）を、プロジェクト直下から
+  見た相対パスとして解決し直す。

package/vendor/skills/analyze-project/decision-record.md

@@ -0,0 +1,55 @@
+# 判断記録
+
+## 原則
+
+チャットでの判断・取材の Q&A は揮発させず、必ず markdown に残す。ファイル契約が正本、
+チャットは注入経路という不変条項（intake v2）の適用であり、スタイル学習・過去 PJ 参照・
+次セッションのコンテキスト供給源になる。**形式は発明しない** —
+[edit-plan の decision_log 慣行](../edit-plan/report-guide.md#decision_log)にそのまま接続する。
+
+## 何を記録するか
+
+- **2 パス目の主要判断**: 素材の役割づけ・関係づけ・flags の判定（特に `orphan`/`unclear` の
+  使い分けなど、根拠はあるが解釈の余地が残る判断）。「根拠 = evidence フィールド」と
+  「判断そのものをなぜそう下したか」は別物であり、後者を判断記録に残す。
+- **取材の Q&A**: [interview.md](interview.md) で得た質問と回答（`interpretation.json` の
+  `inputs.context.interview[]` へも反映済みのはずだが、判断記録には「なぜその質問をしたか」
+  「回答をどう解釈に反映したか」まで残す）。
+- **停止条件の判定**: 取材フェーズを終える判断（構成案が捏造なしに一本通ると判定した理由）。
+
+## 記録先とフォーマット
+
+[edit-plan/report-guide.md](../edit-plan/report-guide.md#decision_log) が定義する `decision_log`
+の慣行（`(category, subject)` をキーとした時刻順追記・ISO 8601 日時・category・subject・決定・
+理由・決定者・関連 checkpoint）を**そのまま流用**する。analyze-project 用の category は
+`analysis`（2 パス目の判断）/ `interview`（取材の Q&A）を使う。
+
+`editing-report.html` という単一 HTML に埋め込む前提は 2026-07-22 改訂で edit-plan 側から
+退いたため（分析専用レポートへの一本化。[edit-plan/report-guide.md](../edit-plan/report-guide.md)
+冒頭の改訂注記を参照）、analyze-project と edit-plan は同一プロジェクトの決定を**共有の
+独立ファイル** `<project>/decision-log.md` に追記する（analyze-project が先に書き始めて
+よく、edit-plan の後続工程がそのまま追記を続ける。1 プロジェクト = 1 ログの単一 SSOT）。
+ファイルが無ければ新規作成し、決定行フォーマットの表（category・subject・決定・理由・
+決定者・関連 checkpoint の列）をヘッダに 1 度だけ書く。既存行は変更・削除せず、新しい行を
+末尾へ追加する。
+
+この置き場所の変更（HTML 内蔵 → 独立 markdown ファイル）は、edit-plan 側が固定レポートの
+生成を取りやめたことに伴う**最小限の新設**であり、記録の慣行・フィールド構成そのものは
+一切変えていない。
+
+## 記録例
+
+```markdown
+| 日時 | category | subject | 決定 | 理由 | 決定者 | 関連 checkpoint |
+|---|---|---|---|---|---|---|
+| 2026-07-22T10:40:00+09:00 | analysis | asset:bg-cm-prototype/flags | unclear と判定 | 由来元 edit.json・planning/production-notes.md から同一プロダクトの CM 試作と確認できたが、本編 transcript に直接言及が無く編集上の具体的根拠が無いため orphan ではなく unclear とした | AI（2 パス目） | - |
+| 2026-07-22T10:55:00+09:00 | interview | oq-01: audio/missing.wav の意図 | 取材質問として open_questions に採用 | source からは確定不能（fieldtest/planning に記録なし）。素材にもネットにも無い一次情報のため取材質問の要件を満たす | AI → オーナーへ回付 | - |
+```
+
+## よくある間違い
+
+- 判断記録の形式を新規に発明する（既存の decision_log 慣行を調べずに独自フォーマットを作る）。
+- チャットでのやり取りだけで済ませ、markdown への反映を省略する（揮発させない）。
+- `interpretation.json` の `inputs.context.interview[]` へは反映したが、判断記録（なぜ聞いたか・
+  どう解釈へ反映したか)への記載を省略する。
+- 過去の決定行を新しい判断で上書きする（追記専用の原則違反）。

package/vendor/skills/analyze-project/interpretation.md

@@ -0,0 +1,128 @@
+# 2 パス目 — interpretation.json を作る
+
+## 目次
+
+- [原則](#原則)
+- [読む文脈](#読む文脈周辺プロジェクト文脈)
+- [組み立て手順](#組み立て手順)
+- [根拠必須・捏造ゼロ](#根拠必須捏造ゼロ)
+- [flags 走査義務](#flags-走査義務)
+- [open_questions は取材質問のみ](#open_questions-は取材質問のみ判断質問の禁止)
+- [停止条件（80 点ライン）](#停止条件80-点ライン)
+- [arc は内部データ（レポート非表示）](#arc-は内部データレポート非表示)
+
+## 原則
+
+2 パス目は 1 パス目（analyze-footage）の出力テキストを**並べて読み直すテキスト推論**であり、
+新しい事実を作らない。1 パス目 = 素材ごと・文脈なしの事実抽出、2 パス目 = 全素材の分析結果 +
+周辺文脈を並べて読み直し、素材横断の解釈（役割・関係・浮き・構成案・取材質問）を作る。
+素材の再視聴は 2 パス目が必要と判断した箇所だけに限る。
+
+事実層（analysis.json）と解釈層（interpretation.json）を分離するのは、文脈が誤っていても
+事実層は無傷のまま解釈層だけ安く再生成するため。`interpretation.json` はプロジェクトあたり
+1 ファイル、[interpretation.schema.json](../../packages/schemas/interpretation.schema.json) の
+v0 に従う（未知フィールドは足さない。省略可のフィールドは値が無ければキーごと省略し、
+`null` は使わない）。
+
+## 読む文脈（周辺プロジェクト文脈）
+
+2 パス目の入力は `collect.md` で集めた analysis.json 群だけに閉じない。**プロジェクトが
+既知の AKARI プロジェクト構造（`intake.json` や `edit.json` を持つディレクトリ）の中にある
+場合は、その周辺文脈も読みに行く**:
+
+- `intake.json`（あれば要約して `inputs.context.intake` へ）
+- `edit.json`（既に編集判断が下っている場合、その判断・decision_log・章立てを文脈として読む）
+- `planning/`・`README.md`（案件の背景、企画意図、由来）
+- 過去 PJ・他社形式テンプレ参照（AKARI Video 形式に限らず、Premiere / DaVinci / CapCut 等の
+  他社プロジェクトファイルも対象。`inputs.context.past_projects[]` へ記録）
+
+これは実地検証（内部リポの multiasset-dogfood 実走・2026-07-22）で確定した重要な申し送りである:
+**orphan/unclear の判定は analysis.json（keyframes の note・events）だけでは確信を持てない
+ことがある**。素材だけを見て「これが何のための素材か」が分からない場合、その素材が置かれて
+いる由来プロジェクトの `edit.json`・`planning/`・`README.md`/`CLAUDE.md` を読みに行って初めて
+判定が確定することがある。周辺文脈が無い・読んでも埋まらない場合は、無理に確信を書かず
+`open_questions` へ回すか、flags に確信度の低さを記録する。
+
+読んだ文脈は必ず `inputs.context` に来歴として残す（後から「何を踏まえた解釈か」を追跡できる
+ようにする）。文脈が無い項目はキー自体を省略する（`past_projects`/`interview` は該当なしでも
+空配列を残し、「参照した上で無かった」ことを表す。§ 詳細は schema の description を見る）。
+
+## 組み立て手順
+
+1. `inputs.analyses[]` を `collect.md` の ref 表からそのまま作る（`ref`/`path`/`source` 必須）。
+2. 周辺文脈を読み、`inputs.context` を埋める（無ければキー省略、`past_projects`/`interview` は
+   空配列可）。
+3. 素材ごとに `assets[]` を作る: `ref` / `role`（物語上の役割タグ、自由記述）/ `summary` /
+   任意で `sections[]`（章単位の役割分析。単素材では `arc` とほぼ同型になりうるので、複数素材
+   プロジェクトでは無理に単素材と同じ粒度にしない）/ `relations[]`（他素材との関係。無関係な
+   素材なら正直に空配列にする — 捏造して関係を作らない）/ `flags[]`（[flags 走査義務](#flags-走査義務)参照）。
+4. 全 `assets[]` を並べ、構成案 `arc[]` を組む（`order`/`title`/`refs[]`/`purpose`/`evidence`）。
+   並べ替え・複数素材の統合は 2 パス目がここで初めて行う（1 パス目は時系列のまま）。
+5. `open_questions[]` を作る（[取材質問のみ](#open_questions-は取材質問のみ判断質問の禁止)）。
+6. [validate-and-render.md](validate-and-render.md) で検証する。
+
+## 根拠必須・捏造ゼロ
+
+`assets[].summary`/`role`/`relations[]`/`flags[]`、`arc[].purpose` の全主張は、根拠
+（transcript の該当区間の引用、または keyframe note 参照）を示せて初めて書く。示せない主張は
+書かない。`relations[]`/`flags[]` が実質的に空になる（本当に無関係な素材ばかりだった等）場合も、
+それが正直な結果であり、捏造して非空にしない（実地検証で確認済みの原則）。
+
+`flags[].evidence` も必須（schema で強制済み）。「なんとなく浮いている気がする」のような
+根拠なし主張は書かない。
+
+## flags 走査義務
+
+`assets[].flags[]` の走査は 2 パス目の契約義務であり、**空配列は「未走査」ではなく
+「走査した上で該当なし」を意味する**（schema の description どおり）。全素材について
+`orphan`（本編とのつながりが確認できない）/`unclear`（つながりの手がかりはあるが編集上の
+具体的根拠が無い）/`trouble_overlap`（本筋の中で発生したトラブル・脱線）の 3 種を意識的に
+検討したことを、走査した上での結論として残す。3 種で表現しきれない状態に遭遇したら、
+既存 3 値を変更・削除せず追記のみで enum を拡張してよい（要 schema 側の追記）。
+
+## open_questions は取材質問のみ（判断質問の禁止）
+
+AI は「どうしますか」（判断質問）を聞かない。聞いてよいのは「これは何ですか / なぜ
+やっているんですか」という、**素材にもネットにも載っていない一次情報**だけ。取材は伺いでは
+なく事実収集であり、方針決定ではない。判断はチャットでの対話フェーズ（`edit-plan` 側）が
+扱う。
+
+### 良い例（取材質問）
+
+- 「公園ロケの撮影日はいつですか」（`fills`: 素材のメタデータとして記録するため）
+- 「`audio/missing.wav` は編集で使う予定だった SFX ですか、それとも配置ミスですか」
+  （`fills`: 参照が壊れている理由の事実確認）
+- 「マイクノイズ（300.0-306.5s）の発生原因は屋外の環境音ですか、収録機材由来ですか」
+  （`fills`: flags の trouble_overlap を裏付ける一次情報の有無確認）
+
+### 悪い例（判断質問。書かない）
+
+- 「このトラブル区間は本編に残しますか、カットしますか」— 編集判断であり `edit-plan` の
+  チャット対話が扱う。analyze-project は事実（トラブルの内容・自己解決したか・本筋との
+  関連度）だけを `flags[]` に記録する。
+- 「章タイトルはこのままでいいですか、言い換えますか」— 構成の好みの判断。
+- 「どんな雰囲気の動画にしたいですか」— 方向性そのものであり、対話フェーズが扱う。
+
+見分け方: その質問への回答が**素材の外にある一次情報（日付・意図・経緯・固有名詞など）を
+埋めるものか**（→ 取材質問）、**複数の妥当な選択肢からどれを選ぶかを AI の代わりに人間へ
+丸投げしているか**（→ 判断質問・書かない）。
+
+## 停止条件（80 点ライン）
+
+取材の停止条件は数値ではなく、**「構成案（arc）が事実の捏造なしに一本通るか」**。`arc[]` の
+どのエントリも `purpose`+`evidence` を、素材の再視聴なしに transcript/keyframe note から直接
+引ける形で書ける状態になったら、取材フェーズを終える。それでもなお残る疑問（好みの分かれる
+判断、レポートの読者にとって重要でない些末な事実）は取材質問にせず、編集後の微調整
+（`edit-plan` 側のチャット対話）へ送る。
+
+自己完結度の高い素材（発表者が経緯・意図を全て語る等）では `open_questions` が 0 件のまま
+通ることが正常系である（実地検証で確認済み）。逆に、取材質問が 0 件だからといって
+2 パス目が手を抜いたことにはならない — 走査した上で穴が無かった、という結果を表す。
+
+## arc は内部データ（レポート非表示）
+
+`arc[]` は interpretation.json のデータとしては必須（`minItems: 1`）だが、
+[analysis-report](../../packages/analysis-report/README.md) のレポート表示からは除外される
+（2026-07-22 改訂）。arc は「対話前に出す分析」ではなく編集提案そのものであり、対話フェーズで
+AI がチャットで「こんな感じはどう」と出す種、および取材質問を発生させる材料として機能する。
+2 パス目はレポートに出ないことを理由に手を抜かず、根拠必須の規律をそのまま適用する。

package/vendor/skills/analyze-project/interview.md

@@ -0,0 +1,66 @@
+# 取材 — チャットで一次情報を埋める
+
+## 原則
+
+`interpretation.json` に `open_questions[].status: "open"` が残っている場合だけこの工程に入る。
+取材は伺いではなく事実収集である。**「どうしますか」という文言、または実質的に判断を
+丸投げする言い回しを使わない**（[interpretation.md](interpretation.md#open_questions-は取材質問のみ判断質問の禁止)
+の判断質問の禁止と同じ規律）。設計原則「伺いを立てず作り切る」とも矛盾しない
+— 取材は事実収集であって方針の伺いではない。
+
+## 1. チャットで質問する
+
+`open_questions[]` の `question` をそのままチャットで提示する。複数ある場合はまとめて提示して
+よいが、1 問 1 決定の原則（1 質問 = 1 情報ギャップ）は保つ。質問の前提（なぜ聞くか = `fills`）を
+添えると回答しやすい。
+
+良い言い回しの例:
+
+> 「`audio/missing.wav` は edit.json の SFX から参照されていますが、対象ファイルが見当たり
+> ませんでした。もともと配置予定だった SFX ですか、それとも参照ミスですか？」
+
+避ける言い回しの例（判断丸投げ・書かない）:
+
+> 「このトラブル区間、本編に残しますか？ カットしますか？ どうしますか？」
+
+後者は analyze-project の管轄ではない。事実（トラブルの内容・自己解決したか・本筋との関連度）
+を `flags[]` に記録した上で、採否の判断は `edit-plan` のチャット対話フェーズへ送る。
+
+## 2. 回答を反映する
+
+回答を得たら、該当 `open_questions[]` エントリを更新する:
+
+- `status` を `"answered"` にする
+- `answer` フィールドに回答を追記する（`open` のときは省略していたフィールド）
+
+同時に `inputs.context.interview[]` へ `{ q, a }` の対として昇格する（取材の来歴を
+`inputs.context` に残すのは、後から「何を根拠に解釈したか」を追跡できるようにするため）。
+
+回答が新しい根拠になる場合（例: flags の evidence を補強する事実が得られた）は、該当する
+`assets[].flags[]`/`relations[]`/`arc[]` の記述もその事実で更新してよい。ただし更新後も
+[根拠必須・捏造ゼロ](interpretation.md#根拠必須捏造ゼロ)の規律を守り、取材で得た事実の範囲を
+超えて解釈を広げない。
+
+## 3. 再生成する
+
+`interpretation.json` を更新したら [validate-and-render.md](validate-and-render.md) の手順
+（validate → render → 開く）を再実行し、レポートと取材台帳を最新化する。全 `open_questions`
+が `answered` になっても、それは「取材が尽きた」ことを意味しない —
+[停止条件（80 点ライン）](interpretation.md#停止条件80-点ライン)（構成案が捏造なしに一本通るか）
+を満たしていることを別途確認する。満たしていなければ、新たに生じた `open_questions` を追加して
+同じ工程を繰り返す。
+
+## 4. 取材ゼロで通るケース
+
+素材が自己完結している場合（発表者が経緯・意図を全て語る等）、`open_questions` が最初から
+0 件で [停止条件](interpretation.md#停止条件80-点ライン)を満たすことがある。これは正常系であり、
+無理に取材質問を作らない。
+
+## よくある間違い
+
+- 「どうしますか」「どちらがいいですか」等、判断を尋ねる文言を使う。
+- 取材で得た回答をそのまま `arc`/`flags` の根拠として転記せず、`inputs.context.interview` への
+  昇格を省略する（後から来歴を追跡できなくなる）。
+- 1 件も答えが返っていないのに `status: "answered"` にする。
+- 取材が尽きたと判断する基準を「open_questions が 0 件になったから」にする
+  （停止条件は「構成案が捏造なしに一本通るか」であり、`open_questions` の件数そのものではない）。

package/vendor/skills/analyze-project/references/interpretation-shape.md

@@ -0,0 +1,42 @@
+# interpretation.json の形（早見）
+
+正本は [interpretation.schema.json](../../../packages/schemas/interpretation.schema.json)。
+このファイルは複製しない（drift 防止）。実例は
+[packages/schemas/test/fixtures/interpretation/valid/interpretation.json](../../../packages/schemas/test/fixtures/interpretation/valid/interpretation.json)
+を読む（2 素材・relations あり・flags 3 種・open_questions 1 open + 1 answered の実例）。
+
+## 最小の骨格
+
+```json
+{
+  "version": 0,
+  "inputs": {
+    "analyses": [
+      { "ref": "<assets[].ref と一致>", "path": "<analysis.json への相対/絶対パス>", "source": "<由来・生成条件の要約>" }
+    ]
+  },
+  "assets": [
+    { "ref": "<一意 ID>", "role": "<自由記述タグ>", "summary": "<要約>", "relations": [], "flags": [] }
+  ],
+  "arc": [
+    { "order": 1, "title": "<構成順の名前>", "refs": [{ "asset": "<assets[].ref>" }], "purpose": "<なぜここにあるか>", "evidence": "<transcript 引用 or keyframe note 参照>" }
+  ],
+  "open_questions": []
+}
+```
+
+`inputs.context`（`past_projects`/`interview`/`intake`/`notes`）と `assets[].sections`/
+`relations`/`flags` は省略可のフィールドを含む。値が無ければキーごと省略する（`null` は
+使わない）。詳細な必須/省略の条件は schema 本体の `description`/`$comment` を読む —
+ここでの要約より schema が常に正である。
+
+## 覚えておく制約（schema 単体では表せず CLI が検証する）
+
+- `assets[].ref` と `inputs.analyses[].ref` は 1:1（過不足・重複なし）。
+- `arc[].refs[].asset` / `relations[].target` はすべて `assets[].ref` に存在する（ダングリング
+  参照禁止）。`relations[].target` は自己参照不可。
+- `sections[]` は `end > start`。`flags[]` の `start`/`end` は両方指定か両方省略。
+- `open_questions[].status` が `answered` のとき `answer` 必須、`open` のとき省略。
+
+いずれも [validate-and-render.md](../validate-and-render.md) の `validate-interpretation.mjs`
+が検証する。

package/vendor/skills/analyze-project/references/open-questions-examples.md

@@ -0,0 +1,35 @@
+# open_questions 例文集 — 取材質問 / 判断質問の見分け方
+
+[interpretation.md](../interpretation.md#open_questions-は取材質問のみ判断質問の禁止) の
+規律を、より多くの実例で補う。判断に迷ったら「この質問への回答は**一次情報**か、それとも
+**複数の妥当な選択肢からの選択**か」で判定する。前者だけを書く。
+
+## 取材質問（書いてよい）— 一次情報の欠落を埋める
+
+| 状況 | 質問 | fills（何のために聞くか） |
+|---|---|---|
+| SFX 参照先ファイルが存在しない | 「`audio/missing.wav` は配置予定だった SFX ですか、それとも参照ミスですか」 | 参照切れの原因を事実として確定するため |
+| 撮影日が transcript にも由来プロジェクトにも記録されていない | 「この B ロールの撮影日はいつですか」 | flags/relations の evidence を補強するため |
+| 登場人物の実名・公開同意が確認できない | 「画面に映っている◯◯さんは実名公開で問題ない方ですか」 | プライバシー配慮の要否を判断する材料（判断そのものは編集フェーズ） |
+| 固有名詞が言い淀みで曖昧 | 「リリース日として言及されている『7月の最終日曜日』の具体的な日付は分かりますか」 | 事実の正確性確認（構成案の成立に必須の場合のみ質問化する） |
+| トラブル区間の技術的原因が不明 | 「画面フリーズ（44:34-44:49）の原因は分かっていますか。自己解決していますか」 | flags の trouble_overlap を裏付ける事実確認 |
+
+## 判断質問（書かない）— 選択を人間へ丸投げしている
+
+| 悪い質問 | なぜ判断質問か | 代わりにすること |
+|---|---|---|
+| 「このトラブル区間は本編に残しますか、カットしますか」 | 複数の妥当な選択肢からの選択 | 事実（内容・自己解決有無・本筋との関連度）だけを `flags[]` に記録し、採否は edit-plan のチャット対話へ送る |
+| 「章タイトルはこのままでいいですか、言い換えますか」 | 好みの判断 | 1 パス目のタイトルが章全体を代表していなければ、根拠に基づく訂正として 2 パス目が直接書く（好みではなく事実の訂正なら書いてよい） |
+| 「どんな雰囲気の動画にしたいですか」 | 方向性そのもの | 対話フェーズ（edit-plan）が扱う。analyze-project は事実の提示までに留める |
+| 「サムネイルはどの案がいいですか」 | 選択肢からの選択 | analyze-project はレポートを作らない。サムネイル案は edit-plan がチャットで提示する |
+| 「BGM は何を使いますか」 | 選択肢からの選択 | 素材計画の管轄（edit-plan）。analyze-project は BGM の要否に関わる事実（既存音声トラックの有無等）だけを記録する |
+
+## 見分けにくい境界例
+
+- 「この素材はなぜここにあるのですか」— **取材質問として成立する**（由来・意図という一次情報）。
+  ただし由来プロジェクトの `edit.json`/`planning/`/`README.md` を読んで確定できるなら、
+  質問化する前にそちらを先に調べる（取材は素材にもネットにも無い情報を埋める最終手段）。
+- 「この 2 つの素材は関連していますか」— 事実（同一人物・場所・時間・内容重複）として
+  2 パス目が transcript/keyframe note から判定を試み、判定できなければ `relations[]` を
+  空のままにするか、判定に必要な一次情報（例: 撮影日・撮影場所）だけを取材質問にする。
+  「関連しているとみなして構成しますか」という聞き方は判断質問になるので避ける。