# Pixels to Motors 索引・データ品質設計の独立検証

検証日：2026-11-01（JST）／検証者：Codex
対象：`codex_plan_verification_request.md` の設計案と調査前提。

**判定：この設計案のまま実装を始めるのは NG。既存索引をつなぐ入口は有用だが、名前・日付による対応の確定、新しい判定台帳、点検の一体化は設計変更が必要。**

重大な発見は、①既に MASTER が3拠点の保存先を横断している、②記事本文には実データへの明示参照がある、③品質管理・派生履歴・点検の既存実装がある、④run と台帳には実際の差分があるが差分＝欠損ではない、の4点。

## 検証方法・範囲・再現資料

以下の略称を使う。

- I：`/Users/shimazueiichi/Library/Mobile Documents/com~apple~CloudDocs/デスクトップ/ADAPT DESIGN/じぶんの/PixelstoMotors`
- K：`/Volumes/KIOXIA/r2r2r-data`
- C：`/Users/shimazueiichi/r2r2r-scripts`
- R：`I/_index_review`

元データへの書き込み、移動、削除、リネーム、git コマンド、実機・学習スクリプトの実行は行っていない。書き込みは R のみ。KIOXIA 直下のキー類は**件数だけ確認し、内容は開いていない**。archive 配下のファイル本文も読んでいない。

初回に Python `os.walk` でルートから深さ4のディレクトリまで走査し、その各階層のファイル名を保存。`.git`、`node_modules`、`.venv`、`venv`、`__pycache__`、`_index_review` は除外。以降の一覧検索は `inventory.json` を再利用した。全階層の網羅調査ではない。必要な checkpoint の assets だけ追加で深さを絞って確認した。

| 対象 | 保存した項目数（ファイル＋ディレクトリ、隠しファイル等を含む） | 初回走査時間 |
|---|---:|---:|
| I | 14,502 | 0.562秒 |
| K | 63,411 | 6.605秒 |
| C | 2,330 | 0.086秒 |
| `~/pixelstomotors/cad` | 10 | 0.003秒 |

時間は今回の接続状態・キャッシュでの実測であり、cold scan やファイル本文検証の所要時間ではない。

主要な再集計コマンド（`R` は上記絶対パスに展開）：

```sh
python3 "$R/verify_evidence.py"
```

同スクリプトは保存済み一覧と実台帳・dataset index を読む。実行結果は `verification_metrics.json`。その他の証拠は `sample_links.json`、`article_evidence.json`、`run_reconciliation_all.json`、`metadata_audit.json`、`checkpoint_audit.json`。`run_reconciliation.json` は `run_数字` だけに狭めた予備集計であり、最終件数には使わない。

コードの既存実装の検索には次を実行し、該当箇所を `sed -n` で読んだ。

```sh
rg -n 'git_commit|git_sha|rev-parse|recording_meta|meta.json|code_version|commit_hash' \
  "$C/pi05" "$C/dynamic_tracking_limits/place/place_modules/recorder.py" \
  "$C/lab_train.sh" "$C/lab_start.sh" "$C/capture_top_frames_log07.py" \
  -g '*.py' -g '*.sh' -g '!*.bak*'
```

公開サイトの正本リポジトリ [PixelstoMotors/p2m-site](https://github.com/PixelstoMotors/p2m-site) は取得を試みたが取得失敗。現在の公開記事・GitHub の内容は未検証であり、ローカルアーカイブを公開正本の代用とは判定していない。`data_manifest_rules.md` はローカルに**2026-10-11 のアーカイブ写し**があり読めたが、現行正本とは扱わない。

## A. 前提

### A1. 調査結果1〜4 — ❌ NG（一部は正しいが、欠如の断定と数が不正確）

**1：既存索引の実在は確認。** `Path.read_text()`／保存一覧で次を独立確認した。

- `I/site_archive/README.md`：作成2026-10-12。`index/00`〜`09` は10ファイル存在。README に DAY1〜332、取得日2026-10-12 と明記。「古い」は現行サイト索引として使う場合の問題であり、過去時点のアーカイブとしては正常。
- `I/research/README.md`：本文中の日付の最大値を正規表現で抽出して **2026-10-30**。ファイル更新日時だけで判定していない。
- `K/runs/README.md`、pick-place 台帳、handover 台帳、集約 index を実読。pick-place は **750データ行・82列**、handover は **8データ行・44列**、`runs/run_pick_place/index.csv` は **1データ行・49列**。集約 index を全試行の代用にすると大きく欠ける。
- datasets は直下 **10フォルダすべてに index.json**、README は **8/10**。「各フォルダに README もある」なら誤り。scripted_v1、teach_v1 にはない。
- `I/依頼箱/README.md` は存在し、箱の運用を説明する。個別データを列挙する索引とは性質が違う。

**2：古いが、6対13という説明は誤り。** `K/README.md` は最終更新2026-06-13。冒頭のツリーは6フォルダだが、末尾には既に `mecharm_calibration/` の節があり、本文全体では7種類を説明している。実際の直下ディレクトリは **12個**：datasets、recordings、runs、checkpoints、fk_tables、archive、mecharm_calibration、diag、vision、lab、videos、service_sim。本文にもないのは **5個**（diag、vision、lab、videos、service_sim）。冒頭ツリーとの差は6個。

古さはフォルダ数だけではない。K/README は runs を学習 run と説明し、recordings に「不要なら消す」とある。MASTER の現在の実機ログの置き方・測定データのコピーのみ規則と整合しない。新 INDEX だけを加えても既存 README の誤誘導は残る。

**3：「3か所横断の入口がない」は反証された。** `I/マスターMD/MASTER.md` の「データ保管」「保存先テーブル」は C・K・I と公開正本を既に横断している。`site_archive/index/07_作業ファイルとコード.md` にもコードと KIOXIA 写しへの導線がある。実際に本文の文字列を数えると KIOXIA 3出現、r2r2r-scripts 182出現、lab/ 7出現。これは参照の数であり独立資産数ではない。**現行の具体的資産を検索する一枚の一覧が弱い**、という限定した課題なら残る。

**4：「名前から推測するしかない」は反証された。** B2 の12件すべてで記事本文が K の対象パスを明示している。全体を統一した機械可読対応表は調査範囲で確認できなかったが、既存の明示参照を捨てて推測から作り直す必要はない。

### A2. 見落とし索引 — ❌ NG（重要な既存資産を落としている）

保存一覧から basename を小文字化し、README／index／ledger／manifest／一覧／台帳を検索し、次の代表例を実読した。README 以外の一覧として `WORKING_ASSETS.md` も確認した。

| 見落とし | 実在パス | 役割・含意 |
|---|---|---|
| 動くコードの一覧 | `C/WORKING_ASSETS.md` | DAY230・2026-06-11。コード、役割、実機実績、データ、依存の入口。古さを表示してリンクすべき |
| 校正の採用／不採用 | `K/mecharm_calibration/README.md`、`j0_sweep_adopted/_INDEX_source.md`、`j0_sweep_classified/*/_LEDGER.md` | 元データ・phase・完走・detect・採用を説明。新しい注記台帳と重複 |
| 姿勢索引 | `K/mecharm_calibration/pick_z_postures_DAY243/_INDEX.md`、`pick_z_postures_index.csv` | 系統別の既存索引（名称・存在を確認） |
| Unity の横断台帳 | `K/service_sim/unity/unity_ledger_v1.csv` と README | 条件・結果・設計書への導線。索引対象を実機だけに限定できない |
| 録画一覧 | `K/service_sim/unity/night/20261030_rec/rec_index.csv`、`20261031_rec/rec_index.csv` | 条件と録画の対応（存在確認） |
| 実験の個別索引 | `K/runs/experiments/grasp_lift_test/grasp_lift_index.csv` 等 | 一般 run だけを調べると取りこぼす（存在確認） |
| 動画の利用根拠 | `I/research/robot_video_ledger.md`、動画作業フォルダの「よその映像の台帳.md」 | 学習採用とは別の、公開素材の扱いの台帳（存在確認） |
| アーカイブの索引と生成器 | `I/site_archive/data/pages.csv`、`work_files/_MANIFEST.md`、`tools/gen_index.py`、`tools/gen_files_index.py` | 既存索引の再利用対象。アーカイブ写しと現役を混ぜない |
| 学習前点検 | `C/pi05/check_dataset.py` | 画像枚数、shape、停止、関節範囲、action 等の既存 read-only 点検。方法3の設計前に再利用すべき |

README だけの最新化では、記事とデータを結ぶ機械可読の関係は揃わない。一方、「入口も品質管理もゼロから必要」という問題設定は成立しない。

## B. Log 対応（最重要）

### B1. 番号体系 — ❌ NG（単一番号に正規化して結べない）

少なくとも **7つの意味の異なる識別体系**がある：①全記事通番（DAY／大文字LOG）、②シリーズ内 Log、③日付時刻、④run の試行連番、⑤pi05 の run ID、⑥dataset の版、⑦checkpoint の step。さらに phase、pose、trial の番号を含む。DAY と LOG は全記事通番に見えるが、全範囲で同一名前空間だという仕様は未確認。

保存一覧の各 basename を正規表現で数えた値（複製、退避、AppleDouble 等も含む**字面の数**。資産数や体系数ではない）：

| パターン | 該当項目 | 異なるトークン数 |
|---|---:|---:|
| `DAY\d+` | 2,585 | 347 |
| `LOG\d+` | 1,058 | 76 |
| `Log\d+` | 34 | 14 |
| 8桁日付 `20\d{6}`（数字境界あり） | 11,566 | 98 |
| `run_\d{4}` | 4,903 | 12 |
| `pi05_YYYYMMDD_HHMMSS` | 209 | 109 |

意味の反証：LOG352 の記事は研究室 Log#9、LOG355 は研究室 Log#10、DAY317 は画像認識 Log#10。`lab/Log10` と `vision/measurements/Log10` は別物。`run_0001` は多数の日付で繰り返すため、全 run_stem を主キーにする必要がある。checkpoint の 3999 は記事番号ではない。

修正案：`article_global_id`、`series_id`、`series_log_no`、`run_id`、`dataset_id`、`checkpoint_id + step` を分離する。関係は一対一にせず、作成・使用・派生・評価などの多対多の辺として持つ。

### B2. 12件の実照合 — ⚠️ 要注意（明示参照は利用できるが、名前だけでは不足）

**手順**：現役の作業記事を読み、本文が明記するパスを取り出し、K のフォルダが存在し、下表のファイルがあることを確認。タイトルのシリーズ内 Log も照合した。主張の数値や全ログの再現性まで真と判定したものではない。対象に偏りのある意図的サンプルで、全資産の精度推定には使わない。

記事の共通親は `I/デジタルツイン学習R2R2R/`。最初の9件は「フィジカルAI研究室を作る」、最後の3件は「画像認識と物体検出を学び直す」。

| 作業記事 | シリーズ内番号 | 本文から確認した K の対応先 | 対象側の実在例 |
|---|---:|---|---|
| LOG345_article.md | 6 | `lab/Log06` | `20261017_pi05_execute_finger_on_block.mp4`、serve.log |
| LOG348_article.md | 7 | `lab/Log07` | train_resume.log、serve_4000.log |
| LOG352_article.md | 9 | `mecharm_calibration/teach_poses_LOG352` | measure_20261019_131420.json、README.md |
| LOG355_article.md | 10 | `lab/Log10` | README.md、pod/、logs/ |
| LOG358_article.md | 11 | `lab/Log11` | serve.log、pod_trim2_logs/ |
| LOG361_article.md | 12 | `lab/Log12` | serve_evening.log、LOG361_v3_success_181602_red.mp4 |
| LOG363_article.md | 13 | `lab/Log13` | serve.log |
| LOG401_article.md | 14 | `lab/Log14` | terminal_1155-1215.txt 等 |
| LOG407_article.md | 16 | `lab/Log16` | terminal_1836-1915.txt、serve.log |
| DAY299_vision_article.md | 2 | `vision/measurements/Log02` | region_stats.csv、run_meta_captured.json |
| DAY309_vision_article.md | 7 | `vision/captured/Log07` | flat_0_20260802_072613/meta.json |
| DAY310_vision_article.md | 8 | `vision/captured/Log08` | flat_0_20260807_082025/ 等 |

**件数**：本文の明示参照＋対象実在は **正しい対応12／誤対応0／未対応0**（この判定範囲内）。

名前だけの対照実験は、記事ファイルの DAY／LOG の整数と、上表のデータフォルダ名の Log／LOG の整数が一致するときだけ結び、異なる場合は棄権する保守的ルールを明示して実施した。**正しい1（LOG352）／誤り0／未対応11**。これは提案スクリプトの精度ではなく、命名だけで自明には決まらないことの実証。親フォルダ配下の全ファイル名まで探索するなど、別の規則なら結果は変わる。

日付も一意にならない。LOG345 と LOG348 の記事 frontmatter は両方 **2026-10-17**。保存一覧で同日を basename に持つ K の非 archive 項目は recordings 1、runs 20、lab 4。LOG355 の日付2026-10-20では lab の basename 日付一致は0、videos は21。一致した日付の全件を採用すれば関連のない資産を混ぜ、1件を任意採用すれば誤対応を作る。mtime はコピー・同期で変わるので、この不足を埋める確定根拠にできない。

**設計変更**：本文・既存 manifest の明示参照を第一候補にする。本文の参照でも「この回で作った」「過去データを使った」「コード例」の区別が必要。名前・日付のみは「候補」で止め、根拠パスと行、確認者・確認日を残す。「未対応」と「曖昧で複数候補」と「対応対象なし」を分ける。

### B3. 自信のある誤対応 — ❌ NG（現物の反例あり）

- シリーズを落とすと、画像認識 Log#7（DAY309）を研究室 `lab/Log07`（LOG348）へ結ぶ。両方が実在するため、存在チェックでも防げない。
- LOG352 をシリーズ内352と解釈すると、本来の Log#9を失う。大文字小文字を無条件に潰す処理は危険。
- LOG361 の記事本文は **この回の lab/Log12** と **前回の lab/Log11/offline_eval** の両方を参照する。「出現した Log は全部この回の出力」も誤り。
- `K/vision/measurements/Log12/README.md` は番号が**仮**で、記事化時に確認すると明記。フォルダの存在は公開シリーズ番号の確定を意味しない。
- 同じデータが複数の記事で使用され、同日の異なる実験が複数ある。番号・日付の近さに点数を付けても、対応確定の証拠にはならない。

受入条件に、上記反例を「確定対応にしない」ことを加える。

## C. 有用性と害

### C1. 古さ・不完全観測 — ❌ NG（状態設計がない）

実物に `K/checkpoints/pi05_mecharm_trim_corr_lora_v1/.incoming_1499_20261101_012353_54379/` があり、同時に正式な `1499/` もある。中身を重みとして開かず名称を確認した。全フォルダを完成済みとして載せる設計は既に反例を持つ。

K 未接続は「0件」とせず unavailable と記録。既存の正常な索引を空の結果で置換しない。`Path.exists()` だけではマウントの代用にならない。実際、trim2 README にも `is_mount()` に直した履歴がある。

iCloud は今回 `.icloud` という名前の項目は一覧上0件だったが、これで全ファイルのローカル実体を保証できない。未取得・読取失敗・走査上限・書込中を別状態で表示する。検証済み／候補／未観測を混ぜない。実行開始・終了時刻、対象 root、到達深度、エラー数を出力に残す。書込中 CSV は終了後再試行し、前後のサイズ・mtime が変化したものを安定済み扱いしない。これら障害注入テストは今回未実施。

### C2. iCloud 直下への生成 — ⚠️ 要注意

`I/site_archive/content/record/DAY327_pi05-libero-benchmark-first-run 2/` が実在し、`iterdir()` の結果は **空**。無印側には article.md がある。他にも「 2」のディレクトリ名が多数あるが、原因を同期衝突だとは断定できない。空の別名フォルダを別記事として数える危険は実在する。

単一端末・単一 writer に限定し、同一ディレクトリの一時ファイルから rename で公開し、同時実行を防ぐ。atomic rename は同期競合そのものの解決ではない。「INDEX 2.md」等を自動で正本に昇格させない。入口の場所は MASTER に先に登録し、既存ファイルを上書きしない初期作成手順も決める。

### C3. コスト — ⚠️ 要注意（軽量走査は可能、全面内容検査は未評価）

K の深さ制限付き一覧取得 **63,411項目／6.605秒** は週1回の入口更新には現実的。ただし videos の decode、archive の再帰全ハッシュ、checkpoint の全読込は測っておらず、この数字で実行可能と保証できない。

入口生成は許可した階層のディレクトリ名・小さな manifest に限定。archive は原則走査対象外、videos は上位名と既存台帳を利用し、media の内容検査・重複ハッシュは別コマンドで対象を明示する。変更のない巨大ファイルを毎週再読しない。低速・切断時に時間上限で止め、未検証と報告する。

### C4. 秘密情報 — ❌ NG（除外規則なしでは不可）

`/Volumes/KIOXIA` 直下で、指定のキー名パターンまたは keys に当たる項目は **7件**。存在と件数のみを確認し、名前の列挙や本文の読取はしていない。提案の K root は r2r2r-data なので直下のキーは外側だが、探索 root を親へ拡張すると事故になる。

root と読取ファイル種別の allowlist を先に決める。`.env*`、key/token/credential、keys、`.git`、設定の秘密値、秘密鍵、URL の認証情報・query を除外。symlink を追わず、解決後のパスが許可 root 内か確認する。ファイル名自体に秘密がある場合もあるため、除外対象は名前も出さない。小さい JSON だから全文を INDEX に転載する、という実装は不可。明示したフィールドのみ抜き出す。

### C5. MASTER との二重管理 — ❌ NG（正の境界を明示する必要）

MASTER は「場所を増やす前に保存先テーブルへ追記」「台帳の中身は data_manifest_rules を唯一の正」と明記。新 INDEX の場所・品質台帳の保存先が未定のまま実装するのはこれと整合しない。

正を、**配置規則＝MASTER、台帳の列・状態＝現行 data_manifest_rules、観測した資産一覧＝生成結果**に分ける。INDEX は規則を独自に書き直さず、規則のリンク・参照版と実測結果を表示する。現行の data_manifest_rules が取得できなければ「未確認」とし、2026-10-11 のアーカイブ写しを現在の正として配布しない。

## D. 対案

### D1. 対案 — ⚠️ 要注意（小さな入口＋関係データ＋既存点検の再利用）

推奨する最小構成：

1. MASTER から辿れる短い入口を1つ作り、現役の README・台帳・既存の点検コマンドにリンク。アーカイブには取得時点を表示する。既存の「作業ファイルとコード」生成器の対象範囲も調べ、流用可能な部分を使う。
2. 記事と実験・dataset・checkpoint の**明示的な関係**だけを、承認した1か所に少量の機械可読レコードとして持つ。シリーズ ID、全記事 ID、関係種別、対象 root＋相対パス、証拠、確認状態を持つ。元データの横へ一律に注記ファイルをばらまかない。
3. 既存メタ情報の欠ける列を、これからの出力で補う。run/episode ID を記事がなくても発行する。記事が後から付く場合は関係だけを後で足す。
4. 入口の生成と品質点検は実行単位を分ける。共有の読取層はよいが、重い検査が失敗して入口まで消える構成にしない。

README 更新だけの案は検索関係を補えず、各データへの手動注記案は保守場所を増やす。新 INDEX 一枚に全てを埋め込む案は、根拠と運用の境界が曖昧になる。

### D2. 推奨 — ⚠️ 要注意（修正案を推奨）

上の対案を推奨。12件すべてに既存の参照があり、10 dataset に index があるため、既存証拠をつなぐ費用が推測を検証し続ける費用より小さい。INDEX.md 自体は表示として採用してよいが、自動推定を正本にしない。「新規2ファイルだけ」という制限は、手動確認した関係・注記履歴を保存する段階では成立しない。生成物と保存すべき手入力を別に設計する必要がある。

## E. データ品質

### E1. 注記台帳の重複 — ❌ NG（現案の用途が広すぎる）

実データに次が既にある。

- pick-place 台帳の pick/place verdict・reason、handover 台帳の outcome・source・abort 情報。
- 各 dataset の index の `used`、`reason`。corr_v1〜v3 はそれぞれ5件。teach_v1 は候補20件中 used=true が19件。
- `K/mecharm_calibration/teach_poses_LOG352/README.md` は `measure_20261019_131420.json` を使わないことと、`measure_20261019_152546.json` が外れ値である理由を明記。これは方法1の機能を既に実施している。
- 校正の `_LEDGER.md`／`_INDEX_source.md` には採用・不採用と根拠がある。

ただし VLM の把持 yes は「学習に使ってよい」と同義ではない。用途・期間・データセット版を伴う利用判断、後から判明した例外の履歴には補足の余地がある。

新しい台帳は、**既存判定を複写せず、既存を覆す例外・用途制限だけ**に限定する。`対象ID＋用途＋判定＋理由＋根拠＋event_id＋supersedes＋記入者＋適用時点` を持つ追記履歴が必要。「最後の記入日が勝つ」だけでは同時追記・同日変更・取消を処理できない。対象パスだけではコピー先や改名後の同一性も不明。

「1種類=1ルート」は別種の例外イベントを一つの正規 root に置くことまで禁止しない。ただし現役台帳の複製を別 root に作るなら違反・二重管理になる。規則を先に追加し、生成時の解決規則と学習側での適用方法も決める。台帳を書くだけでは不適切データの学習利用は止まらない。

### E2. 出力メタ情報の現状 — ⚠️ 要注意（新設ではなく不足分の補完）

以下を実読した。少なくとも3件という条件に対し、5種類の具体例を確認。

| 実在例 | 既にある情報 | 足りない／保証できない情報 |
|---|---|---|
| `K/runs/run_pick_place/smoke_day287_01/recording/recording_meta.json` | run_stem、開始終了、228 captured/written、fps、画像寸法、status=ok | コード版、機体・カメラの恒久ID、記事ID |
| `K/runs/run_pick_place/run_0001_20261019_191257/run_0001_20261019_191257.json` | script、source、measure、teach、constants、結果、abort、judgments 等のキー | git commit はこの構造から自動的には保証されない |
| `K/datasets/mecharm_redblock_box_teach_v1/raw_episodes/run_0001_20261019_191257/meta.json` | 205 steps、fps=10、state_names、action の意味、human_verdict | 変換コード版、元ファイル指紋、dataset 全体の生成レシピ |
| `K/vision/captured/Log07/flat_0_20260802_072613/meta.json` | 撮影日時、カメラ解決番号・backend、1920×1080、5フレーム、対象寸法 | カメラ番号は恒久IDではない。code commit・公開記事との確定関係 |
| `K/lab/Log10/README.md` | dataset、checkpoint、設定、GPU、学習条件、**openpi: 215abfb** | C 側のローカル変更・addon の厳密な版は特定しきれない |

git のコミット番号が残るデータは**ある**（lab/Log10 の openpi 版）。全データにないという断定は誤り。ただし、保存一覧にある非 archive の `meta.json`／`recording_meta.json` **254ファイル**を JSON parse して commit／git_sha／revision／code_version というキーを再帰検索すると、該当 **0件**、parse error **0件**（`metadata_audit.json`）。他のJSON・ログ・README全体にコミットがない、という意味ではない。

`C/pi05/build_demo_episodes.py` は既に meta を出力し、`recorder.py` は `recording_meta.json.tmp` からの atomic write を持つ。`policy_recorder.py` には別形式の top_meta.json がある。共通の meta.json をもう1枚必須にする前に、既存形式へ schema_version、code repo＋commit＋dirty状態、入力ID／版、単位・座標系・実行状態を追加する方針にする。成功は「処理が完了」と「タスク達成」を分離する。abort では meta が残らない場合も recorder のコメントに明記されており、「metaなし＝古いデータ」だけではない。

### E3. 一部点検の実行結果 — ⚠️ 要注意（差分は実在、原因の一括断定不可）

#### (a) run と pick-place 台帳

`csv.DictReader` で run_stem を集合化し、保存一覧の `runs/run_pick_place/` **直下の全ディレクトリ名**と完全一致で比較。`run_数字` だけでなく pick_then_place_auto と smoke も含めた。

| 比較 | 件数 |
|---|---:|
| 台帳データ行／unique run_stem | 750／750 |
| 直下ディレクトリ | 849 |
| 両方にある | 716 |
| 台帳だけ | **34** |
| ディレクトリだけ | **133** |
| 重複 run_stem | 0 |
| CSV行幅 | ヘッダを含め751行すべて82列 |

台帳だけの例：`run_0042_test`、`run_0001_20260618_142436`、`pick_then_place_auto_20260621_192329`。ディレクトリだけの例：`run_0001_20260711_183351`、`run_0001_20261015_102101`、`smoke_day287_01`。

**34件すべてを「実行ログが消えた」としない。** 比較は指定 root 直下との関係。台帳だけ34件のうち、run_dir が非空かつその記載先が存在する行は **1件**。別の階層や旧形式の可能性がある。ディレクトリだけ133件には **smoke_ 6件**が含まれる。また **25件**は今回の深さ範囲で通常ファイルを観測できなかった（完全に空との断定ではない）。試験・dry-run・中断・旧形式を分類した上で、追記義務違反を別途判断する。

一般的な `run_数字` だけを対象にすると 783フォルダ、共通664、台帳だけ86、フォルダだけ119になり、採用すべき最終結果と変わる。この実例からも、点検対象の定義を先に固定する必要がある。最終の全差分は `run_reconciliation_all.json` に保存。

#### (b) dataset と checkpoint の由来

「記載がない」の基準を二つに分けた。名前だけの想像を由来の証拠とはしない。

- **手掛かり基準**：元 run ID・元 dataset ID・元パスのいずれかが index/meta/README/assets にあるか。
- **再現基準**：入力の厳密な版、変換／学習コマンドと設定、実行コード版が対象と結び付いているか。これはより厳しい。

**dataset：10フォルダ。index.json がないもの0、READMEがないもの2。** README がない scripted_v1 と teach_v1 も index の run ID と per-episode meta を持つので、「由来の手掛かりゼロ」とは数えない。各1件で元 `runs/run_pick_place/<run_stem>` が実在することも確認。残り8件は README に元データ／生成コマンドがある。したがって今回の手掛かり基準では **由来記載なし0/10**、一方で **dataset 直下の明示的な元パス・生成レシピ文書がない2/10**。全 episode の入力指紋・コード版まで満たす件数は未検証。

**checkpoint：4モデル root／正式な数値 step は5。**

| モデル root | step | assets 配下の norm_stats の dataset ID |
|---|---|---|
| pi05_mecharm_lora_v1 | 1999、4000 | local/mecharm_redblock_box_v1 |
| pi05_mecharm_teach_lora_v1 | 3999 | local/mecharm_redblock_box_teach_v1 |
| pi05_mecharm_trim_lora_v1 | 3999 | local/mecharm_redblock_box_teach_v1_trim2 |
| pi05_mecharm_trim_corr_lora_v1 | 1499 | local/mecharm_redblock_box_teach_v1_trim2_corr_v3 |

手掛かり基準の由来記載なしは **0/4モデル（0/5 step）**。ただし **1/4モデル（2/5 step）** の `mecharm_redblock_box_v1` は現在の datasets 直下名と一致せず、別名の対応規則が要る。norm_stats のIDは学習入力そのものの証明ではない。5 step すべての `_CHECKPOINT_METADATA.custom_metadata` は `{}` であり、checkpoint 内だけで学習 run・入力版・コード版を結ぶ provenance が揃うと判断できたものは **0/5**。外側の lab/Log10 README のような記録を関係表に取り込むべきである。

上の0件と不足件数は矛盾しない。「何も書かれていない」と「再現可能な来歴が揃わない」を混同しないために両方示した。mp4の全面decode、CSVと録画の全行対応、全ファイルhashは実施していない。

### E4. trim・corr の派生来歴 — ✅ OK（人が読む由来は既にある）／⚠️ 厳密な版固定は不足

全 **8派生フォルダ**の README と index を実読した。

| 派生 | 記載された元と処理 |
|---|---|
| teach_v1_trim | teach_v1、途中の停止を詰めるコマンドと理由 |
| teach_v1_trim2 | teach_v1、前版trim、レビュー6件の修正、t_orig、グリッパー保護等 |
| corr_v1 | runs/pi05_policy の成功 run、model/correct 採用、rewind等の除外 |
| corr_v2 | 同上＋ `--gap-fill speed20` |
| corr_v3 | 同上＋ `--gap-fill speed20 --trim-hold` |
| teach_v1_trim2_corr_v1 | trim2＋corr_v1、mergeコマンド、19＋5＝24本、4,186コマ |
| teach_v1_trim2_corr_v2 | trim2＋corr_v2、24本、3,876コマ |
| teach_v1_trim2_corr_v3 | trim2＋corr_v3、24本、3,443コマ |

この8件で「元はどれで何をしたか」の**説明がないものは0件**。merge の index は sources と episode ごとの from_dataset を持つ。`source` が空の episode でも from_dataset があるので、単一キーの空欄だけで来歴欠如に数える点検は誤り。

方法4は未着手ではない。ただし `--run <19本を列挙>` は実行コマンドの完全保存ではなく、元ファイル指紋・処理コード版・全入力の固定が不足する。存在する説明と、完全な再現保証は区別する。

### E5. 優先順位 — ❌ NG（現状を踏まえて組み替える）

「2→1→3→4」では、既存点検を再実装し、既にある派生来歴を後回しにする。推奨順：

1. **規則と既存資産の対応を確定**：MASTER と現行 manifest の正を確認し、対象の単位・ID・完了状態・例外判断の意味を決める。保存先未定のまま増やさない。
2. **方法3の軽量部分を先行**：今回の台帳差分と既存 index/meta の読み取り、既存 check_dataset の再利用。全履歴の是正を始めず、既知差分はベースラインとして残し、新規差分を識別する。
3. **方法2と方法4を一緒に補強**：新規出力にコード版・入力版・schema・終了状態を付け、変換／学習ごとに来歴を残す。記事番号未定でも記録可能にする。使用・学習の直前に必要条件を検証する。
4. **方法1は必要な例外だけ**：校正READMEやdataset indexにない、用途を伴う後日判断に限定。例外が増える実例を確認してから1本の正本を設計する。

品質判断は四つを別々にする：処理の正常終了、タスクの成功、構造の整合、特定用途への利用可否。たとえば成功のみの抽出は模倣学習には適しても、失敗検知の評価データを欠落させる。未判定を自動で「使う」に昇格させない。

## 最終サマリ

### このまま着手してよいか

**不可。** 入口の試作に進むなら、既存索引へのリンクと観測状態の表示までに限定する。推測の確定対応、汎用の採否台帳、重い検査の週次一括実行は、その前に設計を修正する。

### 作る前に変える点（優先順）

1. **番号と関係の仕様**：全記事通番とシリーズ内番号を分離し、明示参照を優先。候補と確定を分ける。関係種別と多対多を許容する。
2. **正本と保存先**：MASTER を配置規則の正、現行 data_manifest_rules を列・状態の正とする。新しい保存先を登録し、既存台帳の複製を増やさない。
3. **未観測と完成の仕様**：未接続、iCloud読取失敗、書込中、incoming、仮Logを欠損・完成済みと混同しない。
4. **走査・公開の安全性**：root/field allowlist、秘密情報除外、symlink制限、単一writer、atomic出力。失敗時に正常版を空へ置換しない。
5. **既存実装の再利用**：check_dataset、dataset index/meta、校正台帳、Unity台帳、アーカイブ生成器を先に調べる。入口生成と重い検査の実行を分ける。
6. **新規データの来歴固定**：コードcommitだけでなくdirty状態、設定、入力ID/版、単位・座標系、変換レシピを持つ。checkpointと学習runを明示接続する。

### 方法1〜4の採否

| 方法 | 判定 | 理由 |
|---|---|---|
| 1 注記台帳 | **変える** | 既存 verdict/used/校正注記と重複する。用途別の後日例外・取消履歴に限定し、実際の利用時に適用する |
| 2 取得時メタ情報 | **採る・既存形式を拡張** | 254件の既存metaがあり新設一律化は不要。欠けるコード版・入力版・終了状態を補う |
| 3 自動点検 | **採る・軽重を分離** | 差分は実測で存在。既存点検を利用し、差分を即欠損扱いしない。全動画decode/全hashは通常更新から分離 |
| 4 選別した新しい版 | **採る・既存運用を正式化** | 8派生すべてに元と処理の説明がある。完全な入力・コード版固定を追加し、元データ不変を維持 |

未解決：現行GitHubと現行 data_manifest_rules の内容、すべてのepisodeの来歴解決、差分167件の個別原因、媒体の全内容整合、障害時の生成器挙動。これらを検証済みとはしていない。本検証で元データの修正や索引の本実装は行っていない。