# P28-01 collector task 指示（worker 向け）

仕様は `SPEC.md`（同じディレクトリ）です。この指示と SPEC.md は変更しないでください。

## 作るもの（allowed_paths `docs/plans/original-completion-2026-10-02/execution/p28-01/collector/**` の中だけ）

1. **`collect_p28_01.py`**: r02 の `collect_perf.py` を基にした外部 collector です。
   - 1版（main の現 source）だけを、私有の CoW stage に materialize します。
   - import は1回だけ行い、その後は R の段階0、P1、P2、O の段階0、P3、P4 の順に、それぞれ別の engine プロセスで1つずつ実行します。
   - `--check` は入力と予定の argv を検証して表示するだけで、stage も engine も作りません。
   - `--run` は実測します。Root が実行します。
2. **`measure_p28_01.gd`**: windowed の main scene 用 probe です。
   - 代表入力（R）は `FileAccess.get_var(false)` で読み、既定の autoload `/root/SimulationRuntime.restore_snapshot` に復元します。新規開始（O）は何も復元しません。どちらの場合も、別の Runtime の生成や `initialize` の再呼出しはしません（SPEC §4.3）。保存は private user:// だけです。
   - main.tscn は、復元の後に root へ追加します。`_ready` で起きた Operations の実際の結果を記録します。
   - 速度は `main._set_speed`、一時停止の解除は `main._toggle_pause` で行い、あとは `SimulationKernel._process` が進めるのを観測するだけにします。直接 advance を呼んではいけません。
   - 計測は frame ごとに行います。
   - stdout にちょうど1行 `P28_01_PERF_REPORT=<json>` を出します。
3. **`check_p28_01_report.py`**: report と収集結果の checker です。合格の条件と、拒否すべき偽の report は下に示します。
4. **`test_collect_p28_01.py`**: 合成した入力だけで動く unittest です。engine も artifacts も不要にします。

## 必須事項

- SPEC.md の §4〜§7 と C1〜C9 を、そのとおりに実装します。
- **checker が拒否すべきもの**（それぞれに対応する拒否試験を書く）
  - x3 が直接 advance で作られている（Clock の速度と frame の記録が一致しない）
  - 登録数を稼働数や描画数の欄に流用している
  - seed の欄に RNG state が入っている
  - GPU 時間が 0 で、理由がない
  - 必須の欄が欠けている
  - source map が変わっている
  - raw stdout と report が一致しない
  - PID が一致しない
- **製品 source map の対象には触れません。** autoload、scripts、scenes、data、tests、assets、tools と、`project.godot`、`export_presets.cfg`、`Makefile`、`AGENTS.md` です。
- 予算の値、原30/88、受入分母は変えません。
- 次のことはしません。
  - 全回帰
  - native engine の起動（実測は Root が統合後に行います）
  - fixture の生成
  - P14 の再調査
- 必ず守ること: SPEC §4.3 の起動順序と、§6 の停止条件。§4.1 のとおり、代表入力（R）で Operations は開始できず、200客での Operations ON は製品の上限で不可能です。clock を巻き戻すこと、上限を上書きすること、客を再注入すること、状態を固定することは禁止です。
- 描画数は Node の数ではなく、SPEC §5 の model の定義で数えます。
- checker が証明するのは形式と矛盾だけです（SPEC §7）。経路や seed が事実かどうかは、静的レビューと Root の実測で確かめます。
- 依存は自己完結させます（SPEC §3）。gitignore 対象の windows_adapter.py とその legacy/support は import しません。import してよいのは `tools/run_all_tests.py` と `tools/regression/owned_outer.py` だけで、どちらも変更しません。unittest の中で、collector の import 先にこの2つ以外の外部パスがないことを確認します。
- 参照用の入力（r02 の `collect_perf.py`、`measure.gd`、`profile_guard.gd`、`run-r02/execution.json` と report、さらに adapter の `windows_adapter.py`・`legacy/windows_adapter.py`）は、Root が `build/p28-01-readonly/` に読取専用で置きます。SHA は SPEC.md §3 と REGISTRATION_PROPOSAL.json の readonly_inputs_for_worker のとおりです。それ以外の場所や、拒否されたパスにはアクセスしないでください。
- commit はしません（Runner が submit します）。最終出力には変更したファイルと、試験の実行結果をそのまま出します。

## 検証

Runner の validation `p28-01-collector-unit` が `test_collect_p28_01.py` を実行します。そのあと、独立した Opus（claude-opus-5-5）が内容をレビューします。自己申告や終了コード0は、合格の証拠になりません。