TheTree_mock/docs/plans/original-completion-2026-10-02/execution/p28-01/SPEC.md

P28-01 現HEADの性能基準：最小バッチ仕様

この文書は Runner の spec_ref です。work_packages.json 全体の代わりに、この対象に必要な原本定義だけを固定します。

1. 原本定義（変更しない）

• 分母は原30パッケージ・88成果単位で、部分点はありません。開始時点の正式完了は22/88、完了パッケージは4/30です。
• 成果単位 P28-01「現HEADの性能基準」（work_packages.json の P28.remaining_deliverables[0]）
  • work: 実Runtimeの20,000マス・200客・50職員・150施設を基準にTick、経路、snapshot、描画、保存を測る。
  • acceptance: 機種、ビルド、シード、速度、測定区間、平均・P95・最大を残す。
• パッケージ P28「性能・操作感・長期バランス」
  • requirement_ids: B-1.1, B-3.1a, B-4.3a, B-4.3c, B-11.1, B-12.1, B-14.4
  • decisions: D04, D08, D10
  • package acceptance（P28-01 の完了では満たしたことにしない）: 既存性能予算と新しいWindows描画目標を満たす。到達不可能な収支/信仰/ランク条件なし。高速自動再生だけでプレイ時間・操作感を合格にしない。
• P28 横断条件6件（各成果で適用し、適用外にするときは理由を記録する）
  1. 原本条件とUI操作が一致
  2. Runtimeの実利用・会計・行動へ接続
  3. 途中保存・再起動で再現
  4. 異常/境界/中断を検証
  5. 関連回帰PASS
  6. 要件別ログとソースハッシュを保存

2. 完全原本参照

docs/traceability/original/BASELINE.txt（SHA256 75e4bdbdeb379c9269553f0c776bdb9cc96e01f2d6aa5ca650d132c63a8aeb1a）。行番号は requirement_coverage.json の source_lines です。

ID	行	この対象での意味
B-1.1	2–10	PC (Windows)、想定プレイ時間
B-3.1a	58–60	現実10秒＝ゲーム1時間、Pause/x1/x2/x3
B-4.3a / B-4.3c	84–87	A*経路、EV待ち時間、渋滞時の50%減速
B-11.1	213–216	メイン画面、スクロール、ズーム、表と裏
B-12.1	228–230	ドット絵マップの描画
B-14.4	258	UIレスポンス向上

既存の予算値は scripts/core/performance_budget.gd:17-24 のとおりで、変更しません。x1 平均4 ms、x3 P95 12 ms、経路 P95 2 ms、main-thread stall の最大50 ms、保存5 s、読込8 s です。

3. 再利用する既存証拠（再生成しない）

• source: main 8c36c100b2073baf8a9c536528f319a5d0837a63。製品 source map は正式全回帰 p14-03-formal-regression-83b170a-r01 と同じ1407件です。この対象では製品と source map の対象（autoload/scripts/scenes/data/tests/assets/tools と直下4ファイル）を変更しません。変更がなければ、正式192 suite の証拠はそのまま有効です。
• 代表入力: artifacts/original-completion-2026-10-02/p28-current1299-runtime-scale-build-candidate-native-r01/fixture/reference.variant（SHA eb4f7700…f9bd）。20,000/200/50/150、Operations OFF です。全生成はしません。
• engine: /Applications/Godot.app/Contents/MacOS/Godot（SHA c7cccbf8…8ccf、4.7.2.stable.official.ed1daf0bf）。
• 既存の headless 実測 r02（p14-03-representative-perf-r01/run-r02/execution.json SHA 553971f5…9fc1）
  • 条件: Mac16,10・10コア・24 GB、Operations OFF、x1、300分
  • 1分 tick: 平均826.6 ms、P95 1702.7 ms、最大2918.1 ms
  • 経路 cold: P95 0.61 ms
  • snapshot: 平均77.6 ms
  • 保存: manual 297 ms、autosave 327 ms
  • 読込: 平均3193 ms、最大3368 ms
  • これは x1 headless・Operations OFF の行としてそのまま採用し、再測定しません。
• collector の型: p14-03-representative-perf-r01/collect_perf.py（SHA 43f3e429…c063）と measure.gd（SHA 95e59678…f76a）、run-r02/profile_guard.gd（SHA 597696c7…a6f）。以下を引き継ぎます。
  • 私有の CoW stage、private user:// 保存
  • owned Popen による PID の捕捉、guard、cleanup
  • 通常 player の保全
  • 全 raw stdout と SHA の結合
• 上の artifacts/ は gitignore 対象のため、Root が worker へ build/ 配下の読取専用として渡します。

4. 不足を埋める測定（この対象の新規分）

windowed（非headless）の main scene で、1回の collector 実行の中に次の4 phase を置きます。

phase	Operations	速度
P1	OFF	x1
P2	OFF	x3
P3	ON	x1
P4	ON	x3

各 phase の区間は warm-up 30ゲーム分のあと、計測120ゲーム分です。

1. 実UIと同じ Clock 経路を使う。 速度は main.gd::_set_speed（速度ボタンと同じ処理）で設定し、時間は SimulationKernel._process → process_real_delta（MAX_TICKS_PER_FRAME 8、MAX_BACKLOG 120）だけで進めます。advance_minutes(3) などを直接呼んで出した値を x3 frame とは呼びません。

2. SHA と実数を分けて残す。 元 fixture の SHA と、各 phase の準備状態の SHA を記録します。数は sample ごとに3種類を区別して残します。

   • 登録総数（客・職員・施設）
   • 実稼働数（在館で、退館中でない客、勤務中の職員、稼働中の施設）
   • 描画対象の数（viewport 内で可視の node）

   warm-up で客が減った後の値を「200客の測定」とは呼ばず、実数を併記します。

3. seed と RNG state を別欄にする。 seed は restore 後の SimulationRuntime.world_seed の実値です。RNG state（rng_streams）は別欄に記録し、state を seed の名前で代用しません。

4. 未取得は null と理由にする。 GPU 時間は RenderingServer.viewport_set_measure_render_time と viewport_get_measured_render_time_gpu で取得します。非対応・未取得なら null と理由を残し、0 や合格で補いません。CPU の描画時間、frame 時間、Performance.TIME_PROCESS も同じ扱いです。

5. 段階を踏んで実行する。

   • 所要時間の見積り: 1分 tick 827 ms から、(30＋120)分 × 4 phase ＝ 約500 s の CPU 時間。起動と import は別。
   • 同じ collector の段階0として、Operations ON の限定動作を先に1回行います。enable の結果、10ゲーム分の1分ごとの時間、実数、完了時間を見ます。
   • 段階0の実測から P3・P4 の所要時間を外挿し、記録してから長い計測へ進みます。
   • 時間の超過（phase ごとに上限1800 s）や実数の不足があれば、その時点の原記録を保存して止めます。次の最小手順は判断担当が決めます。

6. 各 sample に残すもの

   • 機種: hw.model、コア数、メモリ
   • build: engine の文字列・hash・SHA、project の commit、source map の SHA
   • seed と RNG state（3. のとおり別欄）
   • 速度、区間（開始・終了のゲーム分と wall 時刻）
   • frame 時間、1分 tick、stall（50 ms 超の frame の数と最大）、描画 CPU/GPU のそれぞれについて、平均・P95・最大・標本数
   • 予算は合否を生の値で並べるだけで、新しい許容値は作りません。

5. 対象外と非主張

• Windows 実機は未検証のまま残します（P02-03 / P28-03 の範囲）。
• P28 パッケージの予算達成、P28-02、P28-03、長期バランス、プレイ時間は対象外です。
• 4回分の全回帰と、fixture の全生成は行いません。

6. 完了の扱い

• この Runner task: collector、probe、checker が下の C1〜C8 を満たし、Runner の validation、独立レビュー、integration、final を通ること。これで原本の加算は0です。
• 原本 P28-01 の完了: Root が統合済みの collector で実測し、その receipt を結合した後の証拠ゲートが通ったときに限ります。予算が未達でも、記録の項目がそろえば P28-01 の受入は成立します。未達の予算は P28 パッケージの未達として残します。

7. 登録条件（collector task の baseline）

• C1: 速度は実UI/Clock の経路だけで与え、x3 を直接 advance の値で代用しないことを、checker が拒否試験で確認する。
• C2: 元 fixture と各 phase の準備状態の SHA、および sample ごとの登録・稼働・描画の3種類の実数を、別々の欄に記録する。
• C3: seed の実値と RNG state を別欄にし、取得できなければ null と理由にする。
• C4: GPU や描画時間を取得できなければ null と理由にする。0 や合格への補完を checker が拒否する。
• C5: 段階0（Operations ON の限定動作）と外挿の記録、phase ごとの上限、超過時に原記録を保存して止めることを実装する。
• C6: private user://、owned PID・guard・cleanup・通常 player の保全・全 raw ログと SHA の結合を、r02 と同等に保つ。
• C7: 製品 source map が変わらないことを開始前と終了後に照合する。変われば拒否する。
• C8: 機種・build・seed・速度・区間・平均・P95・最大の各欄を全 sample に要求する。欠けた欄や偽の値は checker が拒否する。