akari-video 0.1.0

package/vendor/skills/setup-audio-library/candidate-list.md

@@ -0,0 +1,72 @@
+# 候補リスト HTML の生成
+
+## 1. いつ実行するか
+
+- 初回セットアップ時
+- `catalog/audio/candidates.json` を更新したとき（新しい配布元・カテゴリの追記）
+- 他レーン（audio-import 等）が `catalog/audio/` に新しいエントリを登録したあと
+  （既所有のグレーアウトを最新化するため）
+
+## 2. 実行する
+
+```sh
+node packages/audio-library-setup/bin/generate-candidates-html.mjs
+```
+
+既定の出力先は `catalog/audio/candidates.html`。引数は次を上書きできる。
+
+```sh
+node packages/audio-library-setup/bin/generate-candidates-html.mjs \
+  --candidates catalog/audio/candidates.json \
+  --catalog-dir catalog/audio \
+  --out catalog/audio/candidates.html
+```
+
+生成後、ユーザーへ `open catalog/audio/candidates.html`（または生成された絶対パス）を
+案内してブラウザで開いてもらう。
+
+## 3. 何が起きるか
+
+- `catalog/audio/candidates.json` の 68 候補カード（カテゴリ 11 種、うち BGM 27 カード・
+  収録曲換算 約110曲）をカードとして並べる
+- 各カードのリンクは**ダウンロードページ URL のみ**（`target="_blank"`）。クリックすると
+  配布元の正規ページが新規タブで開くだけで、音声ファイルは一切取得しない
+- **「既所有」判定はスクリプト実行のたびに `catalog/audio/*/meta.json` を読んで動的に
+  計算する。** 完全一致する `source.url` を持つエントリがあれば「既所有」としてグレー
+  アウト、hostname だけ一致する場合は「同配布元から登録あり」と表示する。
+  他レーンの登録がハードコードなしに反映されるのはこのため
+- 各カードに confidence バッジ（本レーンで実在確認済み／リサーチ時点で確認済み／
+  自動検証不能・要手動確認）とライセンスバッジ（クレジット要否・AI学習可否）を表示する
+- **BGM（`bgm-calm` / `bgm-uplift` / `bgm-other` の3カテゴリ、計27カード）は追加で
+  `mood[]` / `tempo` バッジを表示する。** `mood` は intake の tone チップ（`真面目`・
+  `親しみ`・`高級感`・`勢い`・`かわいい`・`無機質`・`エモい`・`シネマ`）と同一語彙で、
+  各 tone に最低 2 曲を大きく上回る割り当てがある（`catalog/audio/candidates.json` の
+  `mood_vocabulary` 参照）。複数曲を束ねるカードは `songs[]` を持ち、カード内に
+  「収録曲 N 件」の折りたたみリストとして曲ごとの mood/tempo を表示する。将来 intake の
+  tone 決定結果と `mood[]` を突き合わせて BGM を自動提案するための布石であり、
+  自動選曲ロジック自体は本スキルの対象外（提示のみ）
+- 3カテゴリの構成比は「落ち着き系（bgm-calm）6割・盛り上げ系（bgm-uplift）3割・
+  補完（bgm-other）1割」を目安にしている（オーナー指示）。`songs[]` の個別曲は
+  DOVA-SYNDROME・MusMus・魔王魂・甘茶の音楽工房の一覧/ランキングページから
+  「よく使われている」ものを優先収集しており、全曲の個別ページ確認はしていない
+  （カテゴリ/ランキングページ単位の確認 + confidence マークで正直に表示）
+- `credit_template` を持つ候補（MusMus・魔王魂 等、クレジット表記必須の配布元）は、
+  規約に書かれている書式そのままの文言をカードに表示する。ユーザーが編集時に
+  そのままコピーして使える正確さを優先し、要約や言い換えをしない
+
+## 4. ユーザーへの案内文言（テンプレート）
+
+```text
+音源の候補リストを用意しました: catalog/audio/candidates.html
+「ダウンロードページを開く」を押すと配布元の正規ページが開きます。実際の保存は
+あなた自身で行ってください。保存先は ~/.akari/audio-drop/
+（無ければ作成してください）に置くと、次に登録スクリプトを実行したときに自動で
+拾われます。
+```
+
+## よくある間違い
+
+- 生成した HTML のリンクを音声ファイルの直 URL に書き換える（直リンク禁止規約への
+  抵触リスク）。
+- 「既所有」を静的にハードコードする（他レーンの登録が反映されなくなる）。
+- confidence が `blocked_unverifiable` の項目を「確認済み」であるかのように表示する。

package/vendor/skills/setup-audio-library/drop-folder.md

@@ -0,0 +1,72 @@
+# ドロップフォルダ監視・登録
+
+[candidate-list.md](candidate-list.md) でユーザーが実際にダウンロードしたあと、
+このリーフでファイル単位の照合・登録を行う。
+
+## 1. ドロップフォルダの場所
+
+既定は `~/.akari/audio-drop/`（2026-07-25 第三裁定でプロジェクト外置き場所の基底を
+`~/.akari/` に統一。`~/.config/akari-video/credentials.env` や
+`~/.config/akari-video/voice-profiles/` は認証情報の置き場として別論点のため現状維持
+— いずれも user レベル・git 管理外の置き場である点は共通）。
+ユーザーがブラウザでダウンロードしたファイルを、そのままこのフォルダへ移動・保存して
+もらう。`~/Downloads` を直接監視しない（無関係なダウンロードと混在し誤登録するリスクを
+避けるため、音源専用の場所を切る）。
+
+## 2. まず plan-only で確認する（既定・安全）
+
+```sh
+node packages/audio-library-setup/bin/register-drop-folder.mjs \
+  --drop-dir ~/.akari/audio-drop
+```
+
+`--apply` を付けない限り**ファイルは一切動かず、catalog にも一切書き込まない**。
+標準出力の JSON（`matched_candidates` / `quarantined`）をユーザーに見せ、想定通りかを
+確認する。
+
+## 3. 問題なければ `--apply` で実行する
+
+```sh
+node packages/audio-library-setup/bin/register-drop-folder.mjs \
+  --drop-dir ~/.akari/audio-drop --apply
+```
+
+- **一致したファイル**: `~/.akari/assets/audio/<candidate-id>/` （user スコープ、
+  [setup-library/fetch-and-validate.md](../setup-library/fetch-and-validate.md) と同じ
+  スコープ階層）へ実体を移動し、`meta.json`（実体あり・`remote` キーなし）を書く。
+  同時に `catalog/audio/<candidate-id>/meta.json`（`remote: true` の参照 SSOT）が
+  無ければ作る。**既にあれば上書きしない**（ハードルール 6）。
+  `ffmpeg` があれば波形 `preview.png` を生成する（無ければ生成せず理由をログに残す。
+  実物と違う mock を作らない）。
+- **一致しなかったファイル**: ドロップフォルダ内の `_quarantine/` へ移動し、
+  `_quarantine/manifest.json` に「出典不明」として記録する（audio-import レーンと同じ
+  規律）。ファイル名からの推測登録はしない。
+- **複数候補に一致してしまう場合**: 一意に決定できないため隔離する（推測しない）。
+
+再実行は idempotent（同名ファイルは二重移動しない・`manifest.json` に重複エントリを
+増やさない）。
+
+## 4. マッチングの限界（正直に伝える）
+
+ファイル名照合が機能するのは、候補データに `expected_filenames` /
+`filename_patterns` が入っている「個別ファイル名まで特定できた候補」（効果音ラボ・
+OtoLogic の一部）だけ。DOVA-SYNDROME・Pixabay・Freesound のタグ/検索ページ候補は
+ユーザーが保存時に付けるファイル名が予測できないため、自動照合できず `_quarantine/`
+に入る。この場合は audio-import レーンの前例にならい、`_quarantine/manifest.json` を
+見ながらユーザーに出典を確認し、`catalog/audio/candidates.json` の該当候補に
+`expected_filenames` を追記するか、手で `catalog/audio/<id>/meta.json` を作る。
+
+## 5. 検証
+
+```sh
+node packages/schemas/bin/validate-asset.mjs ~/.akari/assets/audio/<candidate-id>
+```
+
+失敗したら理由（大抵は `preview.png` 未生成 = ffmpeg 不在）をそのまま報告する。
+
+## よくある間違い
+
+- `--apply` を付けずに「登録した」と報告する（plan-only は何も変更しない）。
+- 複数候補に一致するファイルをどちらかに決め打ちで登録する。
+- 既存の `catalog/audio/<id>/meta.json` を上書きする。
+- `_quarantine/` の存在を無視し、出典不明ファイルを放置したまま完了報告する。

package/vendor/skills/setup-audio-library/gallery.md

@@ -0,0 +1,43 @@
+# 試聴ギャラリー（keep / drop）
+
+[drop-folder.md](drop-folder.md) で登録された音源を、実際に聴きながら keep/drop を
+決めるためのローカルギャラリー。decision-cards / intake-form と同じ流儀（`127.0.0.1`
+のみ・外部 npm 依存ゼロ・状態は JSON サイドカーへ atomic 書き込み）。
+
+## 1. 起動する
+
+```sh
+node packages/audio-library-setup/bin/gallery-helper.mjs \
+  --library-root ~/.akari/assets/audio
+```
+
+起動すると `HELPER: http://localhost:<port>/` を標準出力に出す。ユーザーへそのまま
+提示し、ブラウザで開いてもらう。
+
+## 2. 画面で分かること
+
+- `~/.akari/assets/audio/<id>/meta.json` を持つ登録済みエントリを一覧表示する
+  （`meta.json` はあるが再生可能な音声実体が無いエントリは表示しない）
+- 各エントリの音声ファイルを `<audio controls>` でその場再生できる
+  （`/media/<id>/<filename>` 経由でのみ配信。ライブラリ外のファイルは配信しない）
+- ライセンスバッジ（要クレジット／クレジット不要／AI学習禁止）に加え、`meta.json` に
+  `mood[]` / `tempo` があればそれもバッジ表示する（2026-07-22 tasks/audio-fetch-gallery で追加）
+- 画面上部の入力欄で id / タイトルを絞り込み検索できる
+- 「keep 一覧をコピー」ボタンで、現在 keep 判定済みの id を JSON 配列としてクリップボードへ
+  コピーできる（オーナーがフィードバックとして他ツールへ貼り付ける用途）
+- keep / drop ボタンで決定を記録する。決定は `~/.akari/assets/audio/_gallery-state.json`
+  へ即時保存される（ページを閉じても消えない）。もう一度同じボタンを押すと決定を解除する
+
+## 3. keep / drop の扱い
+
+このスキルは keep/drop の**記録**までを行う。`drop` にした素材の実ファイル削除や、
+`assets/audio/INDEX.md` への反映は別途人間の判断で行う（自動削除しない。取り違えた
+決定を戻せなくする操作を勝手に実行しない）。
+
+## よくある間違い
+
+- ギャラリーサーバを `0.0.0.0` 等、ローカル以外にバインドする。
+- `_gallery-state.json` を手で編集して整合性を崩す（サーバ経由の atomic 書き込みに
+  一本化する）。
+- keep/drop の記録だけで「ライブラリ整理が完了した」と報告する（実ファイルの削除・
+  INDEX 反映は別工程）。

package/vendor/skills/setup-library/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: setup-library
+description: AKARI Video を初めてセットアップするとき、または現在のプロジェクトに使える素材が足りず新しく揃えたいときに発動する。ffmpeg / whisper-cli / headless Chrome の道具チェック、catalog/ を読んだスターターパック提案、人間の明示承認、取得・配置・検証・INDEX 更新までを一気通貫で行う first-run スキル。
+---
+
+# FORBIDDEN 級ハードルール
+
+> **Language**: Respond in the user's language — 対話・質問・承認確認・レポートはユーザーの使用言語に合わせる（例: 英語で話しかけられたら英語で応答する）。
+
+次のいずれかに違反する形で素材セットアップを進めない。詳細リーフより常に優先する。
+
+1. **人間の明示承認なしに取得・購入・ログインを実行しない。** 承認前に catalog エントリを `assets/` へ書き込まない。
+2. **在庫を捏造しない。** `catalog/` に存在しないカテゴリ・エントリ・URL・ライセンス表記を提案・記録しない。カタログが空、または該当カテゴリが未整備なら「提案できる素材がない」と正直に報告する。
+3. **license が確定しない素材を `assets/` へ入れない。** `source.license_at_source` を鵜呑みにせず、確認できた範囲だけを書く。確定できなければ配置を止める。
+4. **`acquisition: login` / `purchase` はエージェントが代理取得しない。** URL を提示してユーザー自身に取得させ、置き場所を確認してから次工程へ進む。
+5. **`assets/` 配置後に `remote` フラグを残さない。** 実体が揃っていないのに `assets/` 側で「配置完了」と報告しない。
+6. **`attribution_required` が true の素材は記録を省略しない。** `assets/<category>/INDEX.md` への明記と、プロジェクト側クレジットが必要になる旨のユーザーへの明示を必須とする。
+7. **`node packages/schemas/bin/validate-asset.mjs` を通さずに「検証済み」と報告しない。**
+8. **既存の `assets/<category>/<id>/` を無断で上書きしない。** id が衝突したら内容を比較し、人間の判断を仰ぐ。
+
+# 実行順リーフ
+
+1. [tools-check.md](tools-check.md) — ffmpeg / whisper-cli / headless Chrome の実在確認
+2. [starter-pack.md](starter-pack.md) — `catalog/INDEX.md` を読み、用途を聞き、スターターパックを提案して承認を得る
+3. [fetch-and-validate.md](fetch-and-validate.md) — 承認された素材だけを取得し、`assets/` へ配置、検証、`INDEX.md` 更新
+
+詳細を先読みせず、現在の工程に対応するファイルだけを読む。承認が得られていない工程を先に進めない。
+
+## 根拠
+
+- 契約: [`docs/contract-2026-07-13-asset-library.md`](../../docs/contract-2026-07-13-asset-library.md)「カタログと取得スキル」§
+- 素材化・meta.json v0 の詳細規律: [../harvest-asset/SKILL.md](../harvest-asset/SKILL.md)
+- authoring hard rules: [../overlay-authoring/SKILL.md](../overlay-authoring/SKILL.md)

package/vendor/skills/setup-library/fetch-and-validate.md

@@ -0,0 +1,102 @@
+# 取得・配置・検証・INDEX 更新
+
+[starter-pack.md](starter-pack.md) で明示承認を得た catalog エントリだけを対象にする。承認されていない id を一緒に取得しない。
+
+## 1. 取得する（acquisition ごとに分岐）
+
+### acquisition: direct
+
+エージェントが `curl` 等で取得してよい。
+
+```sh
+curl -fsSL "<source.url または直接ファイル URL>" -o "<作業ディレクトリ>/<file>"
+```
+
+- 取得直後にファイル種別・サイズを確認する（`file`, `ls -la`）。想定外の HTML エラーページ等を実体と誤認しない。
+- `source.license_at_source` を出発点にしつつ、取得元ページで実際に確認できる範囲のライセンス表記と突き合わせる。矛盾したら取得を止めて報告する。
+
+### acquisition: login / purchase
+
+エージェントは取得しない。次をユーザーへ提示する。
+
+- `source.url`（取得先ページ）
+- 必要な手続き（会員登録・購入）の概要（catalog 側に書かれている範囲で。無い情報を推測で補わない）
+- 「取得したら、どこに置きましたか？」を聞き、ユーザーが答えたローカルパスを次工程の入力にする
+
+## 2. 選ばれたスコープの assets/<category>/<id>/ へ配置する
+
+配置前に**登録先スコープ**をユーザーに確認する（契約「アセットのスコープ階層」参照）: `user`（`~/.akari/assets/`、全プロジェクト共通 — スターターパックの既定候補）/ `local`（プロジェクト内 `assets/`）/ `shared`（上位ディレクトリの `.akari/assets/`）/ `builtin`（製品リポの `assets/` — 開発者がライブラリ自体を育てる場合のみ）。以降の `assets/...` 表記は選ばれた層のルートを指す。
+
+既存の同名ディレクトリがあれば上書きしない。内容を比較し、更新か新 id かの明示判断を人間から得る（[harvest-asset](../harvest-asset/SKILL.md) と同じ規律）。
+
+取得した実体の性質によって以降の作業量が異なる。
+
+- **authoring 不要な素材**（audio・broll など、取得した実体そのものが完成品）: meta.json をほぼそのまま複製し、下記の変更点だけ反映する。
+- **authoring が必要な素材**（3d モデル単体、書体ファイル単体など、`fragment.html` や `@font-face` 定義がまだ無いもの）: [harvest-asset](../harvest-asset/SKILL.md) 2 節と同じ手順（CSS 変数 → knobs、依存 → requires の自動抽出）を踏んでから配置する。catalog の meta.json はあくまで下書きの出発点として扱う。
+
+最低限そろえる: 実体ファイル + `meta.json` + `preview.png`。`preview.png` はカテゴリに応じて [harvest-asset](../harvest-asset/SKILL.md) 4 節の手順（HTML は headless Chrome、3D は代表 pose、B-roll は `ffmpeg` の代表フレーム、audio は waveform）で作る。生成できなければ理由を残し、実体と違う mock を preview として作らない。
+
+### meta.json の書き方
+
+catalog 側の `meta.json` をベースに、次を変更する。
+
+1. **`remote` キーを外す（削除する）。** 実体が揃った素材はカタログ専用フラグを持たない。既存の `assets/` 内の他素材も `remote` フィールドを持たない。
+2. **`provenance.origin` にカタログ由来である旨と取得元を記録する（必須）。** 例:
+   `"catalog/<category>/<id> 由来 / 取得元: <source.url> / acquisition: <direct|login|purchase> / license_at_source: <...> / 取得日: YYYY-MM-DD"`
+   分からない値を埋めない。取得日は実行日で確定する。
+3. `source` ブロックは残してもよい（schema 上、`remote` が無くても `source` object は valid）。機械可読な取得記録として残す場合は保持し、`source.url` は実際に取得したファイル/ページの URL に合わせて更新する。不要なら削除してよい。必須なのは 1・2 のみ。
+4. `license` / `tags` / `title` / `description` / `when_to_use` / `ai_usage` / `knobs` / `requires` / `author` / `price` は catalog 側の値を土台にする。authoring が必要な素材では、実際に作った `fragment.html` の CSS 変数・依存と食い違っていないか確認してから確定する。license が確定しない場合は `assets/` へ入れない。
+
+### font カテゴリの特例
+
+フォントは再配布ライセンスが同梱を許さないことが多い。
+
+- ライセンスが redistribution / embedding を明示的に許可する場合（OFL 系の多くの Google Fonts 等）だけ、バイナリを `assets/font/<id>/` へ実体として配置し、`remote` を外す。
+- 許可が確認できない場合、バイナリを `assets/` へコピーしない。`remote: true` を維持したまま、`ai_usage` にユーザーの実際のインストール先（OS フォントディレクトリ等）を記録し、`fragment.html` 側は `@font-face` でユーザー環境のフォント名を前提にする設計に留める。
+
+## 3. attribution_required を記録する
+
+`source.attribution_required` または `license.attribution_required` が true の場合、次の両方を行う。
+
+- `assets/<category>/INDEX.md` の該当行に「要クレジット」等、attribution が必要である旨を明記する。
+- ユーザーへ「この素材を書き出しに使う際は、プロジェクト側（エンドロール等）にクレジット表記が必要」と明示的に伝える。自動挿入は将来仕様であり、今は記録と告知のみ行う。
+
+## 4. validator で検証する
+
+```sh
+node packages/schemas/bin/validate-asset.mjs "assets/<category>/<id>"
+```
+
+失敗したら `meta.json`、最小 3 点セット、category 一致、相対参照、INDEX を直し、成功するまで再実行する。`packages/schemas/bin/validate-asset.mjs` または `packages/schemas/asset-meta.schema.json` が無い場合は成功扱いにせず、成果報告に次をそのまま残す。
+
+```text
+後で実行: node packages/schemas/bin/validate-asset.mjs（validator / schema 作成後）
+```
+
+## 5. assets/<category>/INDEX.md を更新する
+
+harvest-asset と同じ書式で 1 行追加する。
+
+```text
+<id> — <何で、どんな場面向けかを一文で>（要クレジットなど注記があれば併記）
+```
+
+重複行を作らない。新 category（font 等、`assets/` 側にまだ存在しないディレクトリ）を初めて作るときだけ `assets/INDEX.md` にもカテゴリ説明を追加する。
+
+## よくある間違い
+
+- ライセンスが未確認・不明確なまま取得を実行する（catalog の `license_at_source` を鵜呑みにし、取得元での実際の表記を確認しない）。
+- attribution_required の記録漏れ（INDEX にもユーザーにも伝えない）。
+- catalog の meta.json をそのまま `assets/<category>/<id>/meta.json` としてコピーし、`remote: true` が残る。
+- `login` / `purchase` のカタログエントリをエージェントが代理で取得しようとする。
+- フォントの再配布可否を確認せず、`assets/font/<id>/` へバイナリを無条件コピーする。
+- validator を通さず「配置完了」と報告する。
+- 承認されていない catalog エントリまで一緒に取得する。
+- 既存 `assets/` の同名ディレクトリを黙って上書きする。
+- 3d / font など authoring が必要な素材を、catalog の meta.json をそのまま流用して「完成」と扱う（knobs・requires が実体と食い違ったまま残る）。
+
+## 根拠
+
+- 契約: [`docs/contract-2026-07-13-asset-library.md`](../../docs/contract-2026-07-13-asset-library.md)「カタログと取得スキル」§
+- 素材化・meta.json v0 の詳細規律: [../harvest-asset/SKILL.md](../harvest-asset/SKILL.md)
+- authoring hard rules: [../overlay-authoring/SKILL.md](../overlay-authoring/SKILL.md)

package/vendor/skills/setup-library/starter-pack.md

@@ -0,0 +1,55 @@
+# カタログ閲覧とスターターパック提案
+
+## 1. catalog/INDEX.md から辿る
+
+`catalog/INDEX.md` → 各カテゴリの `catalog/<category>/INDEX.md` → 個々の `catalog/<category>/<id>/meta.json`（`remote: true`）の順で読む。`assets/` の LLM Wiki と同じ経路を踏む。
+
+カテゴリが「整備中」で `INDEX.md` にエントリ行が無い場合、そのカテゴリに提案できる素材はまだ無いとそのまま報告する。「後で追加予定」という記述を在庫の代わりに提案しない。存在しない id・url・license を発明しない。
+
+既存の `assets/<category>/INDEX.md` も合わせて確認し、同種の素材が既にローカルにあるなら重複提案しない。
+
+## 2. ユーザーの用途を聞く
+
+導出できない情報は必ず聞く。提案前に次を確認する。
+
+- 動画のジャンル・シーン（例: 製品デモ、インタビュー、B-roll 補完、テロップ強化）
+- 想定アスペクト比（16:9 / 9:16 / 両方）
+- 予算感（無料のみか、`acquisition: purchase` を含めてよいか）
+- ログインが要る取得元（`acquisition: login`）を許容するか
+
+## 3. CC0 優先でスターターパックを組む
+
+契約の CC0 ファースト方針に従う。
+
+- `source.license_at_source` が CC0 相当（帰属表示不要・商用利用可・改変可）のエントリを優先する
+- `source.attribution_required: true` のエントリを含めてもよいが、提案時に必ず明示する
+- `source.acquisition` が `login` / `purchase` のエントリは、ユーザーが許容した場合のみ候補に含める
+- 実際に `catalog/` に存在するエントリだけを列挙する
+
+## 4. 提案フォーマット
+
+カテゴリごとに、id・タイトル・license_at_source・acquisition・一言理由を並べて提示する。
+
+```text
+[telop] lower-third-clean は既存 assets/ に既にあるため対象外。
+[font]  <id> — <title>（license: CC0 1.0 / acquisition: direct）— 日本語見出し向け
+[3d]    <id> — <title>（license: CC-BY 4.0 / acquisition: direct / ⚠ attribution 必須）— 製品モックアップ
+```
+
+`⚠ attribution 必須` などの注記は省略しない。ユーザーが一覧だけ見て許容判断できる情報量にする。
+
+## 5. 人間の明示承認を得る
+
+「この一覧のうち、どれを取得しますか？」と問い、YES/NO または対象の絞り込みを明示的に得る。承認が得られるまで [fetch-and-validate.md](fetch-and-validate.md) の工程へ進まない。
+
+- 返信の話題転換・沈黙を承認とみなさない
+- 一部だけ承認された場合、承認された id だけを次工程の対象にする
+- 承認内容（対象 id 一覧）を次工程へそのまま引き継ぐ
+
+## よくある間違い
+
+- `catalog/` に存在しないカテゴリ・エントリを、需要に応えるためだけに提案する。
+- ユーザーの用途を聞かずに「とりあえず全部」提案する。
+- `attribution_required` や `acquisition: purchase` を隠して、または注記なしで提示する。
+- 明示的な YES を得ずに「承認されたはず」で次工程へ進む。
+- 既に `assets/` にある素材と同種のものを重複提案する。

package/vendor/skills/setup-library/tools-check.md

@@ -0,0 +1,83 @@
+# 道具チェック
+
+素材取得より前に実行する。3 つの道具の実在は宣言だけで済ませず、実際にコマンドを走らせて確認する。パスの存在を推測で報告しない。
+
+## ffmpeg
+
+```sh
+command -v ffmpeg && ffmpeg -version | head -1
+```
+
+用途: 取得した broll / audio 素材の preview frame・waveform 抽出（[harvest-asset](../harvest-asset/SKILL.md) 4 節と同じ手順）、fetch した動画・音声の実体確認。
+
+なければ: 導入コマンド（`brew install ffmpeg` 等）をユーザーに提示するだけに留める。エージェントが無断で環境変更を実行しない。
+
+## whisper-cli（whisper.cpp）
+
+実行ファイルとモデルは別々に確認する。探索順は [analyze-footage/media-and-transcript.md](../analyze-footage/media-and-transcript.md) と揃える。
+
+実行ファイル探索順:
+
+1. 明示指定（`$AKARI_WHISPER_BIN` 等）があれば最優先
+2. PATH 上の `whisper-cli`
+3. リポジトリ内/隣接する whisper.cpp checkout の `build/bin/whisper-cli`
+
+```sh
+command -v whisper-cli && whisper-cli -h | head -5
+```
+
+モデル探索順（実行ファイルが見つかったときだけ確認する）:
+
+1. 明示指定
+2. リポジトリ内 `models/` / `whisper.cpp/models/`
+3. `$HOME/.cache/whisper.cpp/`
+4. `$HOME/Library/Caches/whisper.cpp/`
+5. Homebrew `whisper-cpp` の share ディレクトリ
+6. VoiceInk の保存先: `$HOME/Library/Application Support/com.prakashjoshipax.VoiceInk/WhisperModels/`
+
+```sh
+ls -la "$HOME/Library/Application Support/com.prakashjoshipax.VoiceInk/WhisperModels/" 2>/dev/null
+```
+
+用途: 取得した audio 素材のナレーション・歌詞有無の確認、fetch 後の内容チェック補助。素材ライブラリの主経路ではないため、無くても致命的ではない。
+
+なければ: 文字起こしが絡む確認だけ省略し、他の工程は止めない。理由を報告する。
+
+## headless Chrome
+
+[overlay-authoring/thumbnail.md](../overlay-authoring/thumbnail.md) と同じ既定パスを使う。
+
+```sh
+CHROME="${AKARI_CHROME_BIN:-/Applications/Google Chrome.app/Contents/MacOS/Google Chrome}"
+test -x "$CHROME" && echo "OK: $CHROME"
+```
+
+用途: 取得した telop / motion / 3d 系素材の `fragment.html` を実際にレンダーして preview.png を作る、または見た目を検品する。
+
+なければ: 実体確認済みの preview 画像がカタログ側の `source.preview_url` にも無い限り、HTML 系素材の見た目確認を保留し理由を報告する。実物と違う mock を preview として作らない（[harvest-asset](../harvest-asset/SKILL.md) のよくある間違いを継承する）。
+
+## Blender（条件付き — 3D ベイクレシピを扱うときだけ）
+
+```sh
+BLENDER="${AKARI_BLENDER_BIN:-}"
+[ -z "$BLENDER" ] && BLENDER="$(command -v blender || true)"
+[ -z "$BLENDER" ] && BLENDER="/Applications/Blender.app/Contents/MacOS/Blender"
+test -x "$BLENDER" && "$BLENDER" --version | head -1
+```
+
+用途: 3d ベイクレシピ（`scene.py` 実体の素材）のヘッドレスレンダー。契約は `docs/contract-2026-07-14-3d-bake-recipe.md`、手順は [bake-3d/SKILL.md](../bake-3d/SKILL.md)。
+
+なければ: 導入コマンド（`brew install --cask blender`）をユーザーに提示するだけに留める。3d ベイクが絡まない工程は止めない。常設 3 道具のチェック結果にも影響させない。
+
+## 結果の扱い
+
+- 3 つとも見つかった場合のみ「道具チェック OK」と報告する。
+- 一部欠けている場合は、欠けている道具名と、それが後続のどの工程・どのカテゴリを制限するかを具体的に報告してから次の工程へ進む。工程全体は止めず、制限付きで進められる部分だけ進める。
+- インストールコマンドをユーザーに無断で実行しない。
+
+## よくある間違い
+
+- 道具が入っているかを実行確認せず、パスの存在を推測で報告する。
+- 欠けている道具を黙って別の代替（クラウド API 等）にすり替える。
+- `brew install` 等をユーザー確認なしに実行する。
+- whisper-cli はあるがモデルが無い状態を「OK」と報告する。

package/vendor/skills/verify/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: verify
+description: "AKARI Video（現行 Theia スタック）のタスク契約が要求する検証はしご（L0 / L1 / L2）を実行するときに発動する。タスクの受け入れ条件が「verify 層: L0」「L0+L1」等を指定しているとき、各層で実際に何を・どう叩くかを確認するために読む。"
+---
+
+# verify — 検証はしご（L0 / L1 / L2）
+
+> **Language**: Respond in the user's language — 対話・質問・承認確認・レポートはユーザーの使用言語に合わせる（例: 英語で話しかけられたら英語で応答する）。
+
+タスク契約テンプレート（内部リポ `tasks/_template/task.md`）が参照する対応表の実体。
+**発明した定義ではなく、直近タスクの `report.md` / `task.md` の実運用から帰納したもの**（帰納元は末尾「根拠」節）。
+
+## 対応表
+
+| 層 | 定義 | 判定者 | 現行スタックでの実例 |
+|---|---|---|---|
+| L0 | 静的・機械的検証。exit code だけで合否が決まる。実機起動・人間の目を要さない | エージェント単独 | ほぼ全タスクで必須の最下層 |
+| L1 | 実機観測（自動化）。Electron を実際に起動し、CDP/Playwright で操作・スクショ・性能実測を行う。人間の主観判断を要さず、スクリプトで再現可能 | エージェント単独（スクリプト） | 2026-07-15/16 の shell 系タスクはほぼ全て L0+L1 |
+| L2 | 自動化・スクリプトでは判定し切れない層（主観的な視覚品質判断・実配布物でのオーナー最終確認） | 人間（オーナー） | **現行 Theia スタックでは実例なし**（下記「L2 について」参照） |
+
+## L0 — 静的・機械的
+
+現行 Theia スタックでの実体は `apps/shell` の npm scripts:
+
+```sh
+cd apps/shell
+PYTHON=/usr/bin/python3 npm install --no-workspaces   # 初回・依存更新時のみ
+npm run build:ext                                      # tsc -b（6 拡張の型検査 + コンパイル）
+npm run lint                                            # eslint "extensions/*/src/**/*.{ts,tsx}"
+```
+
+- `build:ext` と `lint` が exit 0 = L0 合格の最低ライン。CI（`.github/workflows/ci.yml`）はこの 2 つを push/PR で自動実行する
+- `npm run build`（= `build:ext && theia build --mode production`）は、フロントエンド/バックエンド/electron のバンドル生成まで含むより厳密な L0 として個々のタスク契約が課すことがある（例: `shell-sb-surfaces` / `shell-sc-project` / `shell-sd-partner` / `governance-sanitize`）。ただし **CI には載せていない**（後述「地雷」参照）。タスクで `build` まで求められたら手元で `PYTHON=/usr/bin/python3 npm install --no-workspaces` 後、electron の postinstall が npm 11 の allow-scripts ゲートでスキップされて `theia build` が `ENOENT .../electron/dist/version` で落ちる点に注意し、`echo "<electron のバージョン>" > apps/shell/node_modules/electron/dist/version` で回避すること（`npm run package`/実機起動が要る L1 では、この回避では不十分 — 下記参照）
+- `packages/*` 配下に触るタスクは各 package.json の build/test スクリプトが L0 の実体になる（`waveplan-2026-07-15-sbcd-e5.md` §検収ゲート）
+
+### 既知の地雷（L0）
+
+1. **npm 11 の allow-scripts ゲート**: `npm install` は electron / `@theia/ffmpeg` / drivelist / keytar / node-pty 等 11 パッケージの install script を既定でスキップする（`npm warn allow-scripts ...`）。`build:ext` / `lint` は素の TypeScript / eslint 実行であり、これらのネイティブモジュールを必要としないため**スキップされたままで問題なく通る**（実測済み）。実機を起動する L1 以降で初めて効いてくる
+2. **Homebrew Python 3.14 と node-gyp**: macOS で `PYTHON=` を指定せず `npm install` すると、`drivelist` の `node-gyp rebuild` が Homebrew Python 3.14 の `pyexpat` ABI 不整合（`Symbol not found: _XML_SetAllocTrackerActivationThreshold`）で失敗し、install 自体が止まる。`PYTHON=/usr/bin/python3`（Apple 純正 Python）を必ず指定すること
+3. **`apps/shell/package-lock.json` は意図的に `.gitignore` 済み**（`apps/shell/.gitignore` 内 `package-lock.json`）。`npm ci` は使えない。再現性は Node バージョン固定 + `--no-workspaces` で確保する（後者が無いとリポ root へ依存が hoist され、実行時間が約 2 倍・依存解決範囲が変わることを実測済み）
+4. **grep マッチ 0 件は exit 1**。検証スクリプト内で grep を使うときは `|| true` を付ける
+
+## L1 — 実機観測（Electron を CDP/Playwright で観測する）
+
+現行スタックの L1 は「GUI スクショ必須」という形でほぼ全タスクに課されている
+（`preview-streaming` / `shell-s4-tabs` / `preview-open-repair` / `project-diff-repair` /
+`shell-s12-preview-tab` / `shell-sc-repair` / `shell-strip-menu-repair` 等）。
+以下は `shell-s4-tabs`（report.md §6-2）と `preview-streaming`（report.md §2）で確立・実証済みの再現手順。
+
+### 手順
+
+1. **ビルド**（L0 に加え electron 実体が要る）:
+   ```sh
+   cd apps/shell
+   PYTHON=/usr/bin/python3 npm install --no-workspaces
+   # electron の postinstall は allow-scripts ゲートでスキップされているため、
+   # 既存キャッシュから手動展開する（既にダウンロード済みの環境が前提）:
+   ditto -x -k ~/Library/Caches/electron/<hash>/electron-v<version>-darwin-<arch>.zip \
+     node_modules/electron/dist
+   echo "<version>" > node_modules/electron/dist/version
+   npm run build
+   ```
+2. **隔離ワークスペースを用意**: `templates/project-default/` を作業用一時ディレクトリへコピー（元ファイルは無改変）。検証対象の素材（動画等）が要るタスクは、この中に `ffmpeg` 等で実素材を生成する（例: `preview-streaming` は 4K/120 秒/836MB の MP4 を `ffmpeg -f lavfi ...` で生成し実測に使用。検証後は `rm -rf` で完全削除しコミットしない）
+3. **Electron を直接起動**（`theia start` CLI や Playwright の `_electron.launch()` は不使用 — 後者は argv 解釈に既知不具合があるため）:
+   ```sh
+   node_modules/electron/dist/Electron.app/Contents/MacOS/Electron \
+     <apps/shell 絶対パス> <隔離ワークスペース絶対パス> \
+     --remote-debugging-port=<port> --user-data-dir=<隔離ディレクトリ> --no-sandbox
+   ```
+   `THEIA_CONFIG_DIR=<隔離ディレクトリ>` を環境変数で渡し、通常の開発設定と衝突させない
+4. **`playwright-core` を検証用スクラッチディレクトリにのみ `npm install`**（リポジトリ本体には追加しない）し、
+   `chromium.connectOverCDP('http://127.0.0.1:<port>')` でアタッチする
+5. **入れ子 webview フレームへの到達**: Theia の `WebviewWidget` は外側 `webview.localhost` オリジンの iframe → 内側 `active-frame` という二重入れ子構成を取り、素朴な `page.frames()` 探索では実コンテンツに届かないことがある。CDP の `Page.getFrameTree` と `Runtime.executionContextCreated` イベントの `auxData.frameId` を突き合わせ、実際の内側 execution context を特定してから `Runtime.evaluate` で DOM 状態（`readyState` / `currentTime` / `data-*` 属性等）を直接読む自作クライアントが必要になる場合がある（`preview-streaming` report.md §2 参照）
+6. **観測・記録**:
+   - スクリーンショット: CDP `Page.captureScreenshot` または Playwright の screenshot API。保存先は検証対象拡張の `evidence/<機能名>/*.png`、1 枚 500KB 以下が目安
+   - 性能: `ps -o %cpu -p <pid>` を 1 秒間隔でサンプリングし GPU/renderer/main プロセスを分離して記録。タイミングは操作前後の CDP イベント/DOM 状態変化で実測（例: `readyState>=3` 到達までのミリ秒）
+   - API 境界: `window.theia.container` 経由で Inversify DI コンテナから直接サービスを呼び出し、フロントエンドのガードをバイパスしてもバックエンドが独立して拒否する（多重防御）ことを確認するのも有効（`preview-streaming` report.md の配信境界検証を参照）
+7. **後片付け**: 起動した Electron プロセスは `ps aux` で確認した実 PID を指定して `kill`（`pkill -f` のような広いパターンマッチは使わない）。隔離ワークスペース・巨大な生成素材は検証後に完全削除しコミットしない
+
+### 既知の地雷（L1）
+
+1. **拡張ディレクトリ内のネスト `node_modules`**: `apps/shell/extensions/<ext>/node_modules/` に `@theia/*` 等が残っていると、`apps/shell/node_modules/@theia/core` との二重解決で `FrontendApplicationConfigProvider` のようなモジュール単位シングルトンが分裂し、フロントエンドがプリロード画面のまま無限に止まる（dual-package hazard）。実機起動前に `find apps/shell/extensions/*/node_modules -maxdepth 0` を確認し、あれば削除してから `apps/shell/` 直下でクリーンリビルドする
+2. **Electron の起動エントリ**: `package.json` の `main` フィールドどおり `lib/backend/electron-main.js` を使う。`lib/backend/main.js` を直接指定すると `BrowserWindow` が生成されず `/json/list` が空のままになる
+3. **パッケージ版でのパス解決**: バンドル後の `__dirname` は開発時と異なる（`app.asar/lib/backend` 等）。`apps/shell` 外への相対パス探索を持つ機能は、`electron-builder --dir` 出力を `ELECTRON_RUN_AS_NODE=1` + `cwd=/` で実行して検証すること（`package-runtime-assets` task.md 参照）。開発時 (`npm start`) だけでの確認は不十分
+
+## L2 について
+
+**現行 Theia スタックへ移行した直近タスク群（2026-07-15/16、S-A〜S-D・S4/S6/S12・
+preview-streaming・preview-open-repair・project-diff-repair・package-runtime-assets・
+shell-sc-repair・shell-strip-menu-repair 等）で、L2 が受け入れ条件として課された実例は
+一件もない。** いずれも「verify 層: L0 + L1（実機 GUI スクショ必須）」の範囲で完結しており、
+自動化された実機観測（L1）が実質的な最高層として運用されている。
+
+L2 は旧 Tauri 実装期の verify スキルで使われていた概念で、当時の実例（帰納元）:
+
+- `2026-07-15-preview-band-artifact`: L2 = 実機での不具合再現・修正確認。加えて「オーナーが実機で帯の消失を確認」という**オーナー自身の目視**が最終ゲートに使われた
+- `2026-07-15-vlog-mvp-edit`: 「L2（実機アプリ）未実施」— L1（実書き出し・ffprobe 検証）は完了したが、実機アプリでの目視（プレビュー側の合成が理屈どおりに見えるか）は L2 として区別され、範囲外とされた
+- `2026-07-15-decision-cards-runtime`: 「実機（Tauri / companion 拡張 webview）での目視は本タスク範囲外（L2 非対象）」— headless Chrome での自動 DOM 検証（L1 相当）と、実アプリ webview での体感確認（L2）を明確に分けている
+- 非公開の内部タスク記録の契約書（dev-harness、2026-07-14 付）は「本表 L3 実機 ≒ verify L2（実機）」と明記し、本表 L3 は「オーナーによるフィールドテスト → handoff 記録」と定義される（同じく非公開の wave 計画書、2026-07-15 付、§6）
+
+これらに共通するのは、**L2 = 自動化・スクリプトでは判定し切れない層**という一線であり、
+「実素材を使うかどうか」では区別されない（L1 でも `preview-streaming` の 836MB 4K 実撮素材のように
+実素材を使うことが普通にある）。したがって現行スタックでの L2 は次のように定義する
+（現行スタックでの実例が無いため外挿であることを明記する）:
+
+> L2 = パッケージ配布物（`electron-builder` 出力）での実運用シナリオを、視覚的な質感・
+> 使用感など自動化スクリプトでは判定不能な観点についてオーナー自身が確認し、handoff に記録する層。
+
+### L2 を課すかどうかの判断基準
+
+- 受け入れ条件が **主観的な品質判断**（「違和感がない」「忠実に見える」等、数値化できない観測項目）を含む場合
+- L1 の自動観測（CDP/Playwright）では原理的に再現できない体験（実際の配布物でのインストール〜起動〜操作の一気通貫、実タッチ操作・実マウス操作の感触等）を確認する必要がある場合
+- 司令塔・オーナーが明示的に実機フィールドテストを求めた場合
+
+上記に当てはまらない限り、現行スタックのタスクは L0+L1 で完結させる（実際の運用がそうなっている）。
+
+## どの層を課すか（タスク側の判断基準）
+
+- **L0 のみ**: コードに実行時の観測可能な挙動変化が無いタスク（ドキュメント・CI 設定・型定義のみの変更等）。本タスク（`ci-and-verify-skill`）自身がこの例
+- **L0+L1**: `apps/shell/extensions/**` や `packages/preview-engine` 等、GUI・実行時挙動に影響するコード変更を含むタスクの既定。2026-07-15/16 の shell 系タスクはほぼ全てここに属する
+- **L0+L1+L2**: 上記「L2 を課すかどうかの判断基準」に該当する場合のみ。現行スタックでは前例なし
+
+## 根拠（帰納元）
+
+対応表・手順は非公開の内部タスク記録（`akari-video-internal`）の report.md / task.md から帰納したもの
+である。内部タスク記録そのものは本リポには置かない方針（`docs/design-2026-07-13-agent-native-architecture.md`
+§3 と同様の扱い）。検証手順そのもの（コマンド・観測対象・既知の地雷）は上記「L0」「L1」節に実行可能な形で
+記載済みであり、以下は帰納元タスクの識別のみを示す（すべて非公開）:
+
+- preview-streaming（2026-07-16）: L1 再現手順・836MB 実素材・入れ子 webview フレーム到達法
+- shell-s4-tabs（2026-07-16）: L1 再現手順・dual-package hazard・Electron 起動エントリの地雷（§6-2 に手順まとめ）
+- package-runtime-assets（2026-07-16）: パッケージ版 L1 の実施方法
+- 内部タスク記録の README: 検収フロー 4-c の CI 前提
+- 内部タスク記録のタスクテンプレート: verify 層の対応表という語彙そのものの出典
+- dev-harness 契約書（2026-07-14）・wave 計画書（2026-07-15）§6: 検証レイヤ表・L0/L1/L2/L3 の定義
+- preview-band-artifact・vlog-mvp-edit・decision-cards-runtime（いずれも 2026-07-15、旧 Tauri 期）:
+  L2 実例。現行スタックに L2 実例が無いため、L2 の定義根拠としてはこれらのみ