# P1 有料仕入れ・厨房・実配送

更新日: 2026-09-09。承認済み計画 PLAY-03／04／06 の供給経路を統合した記録。

## 接続した挙動

- 左の「商品」から「仕入れ」「厨房」「配送」を操作する。既存のKenney素材・クリーム色の管理パネルと断面表示を維持する。
- 完成倉庫に調理用食材を1個3Gで購入する。確定前に代金・購入後残金・保管上限を確認し、実在庫追加と台帳への費用記帳を同時に確定する。
- 厨房の自動生産を有効にすると、倉庫から原料を補給し、勤務中の調理人が4個の原料から15分で4個の基本料理を作る。来客の注文を生産開始の条件にしない。
- 運搬係の勤務・Task・Pathを使って、荷元へ歩く→積み込む→納品先へ歩く→納品する。運搬中の人物は既存の荷物表示と連動する。
- 食堂の実サービスが納品された料理を消費し、売上を計上する。厨房停止後も、すでに作った料理の出庫は続けられる。
- 食材は24時間、料理は12時間で期限切れになる。予約中の期限切れ、容量不足、経路断、人員不在は実在庫を保持した待機・再試行・廃棄へ接続する。積載中の経路断では荷物を持つ担当者を解除しない。
- Runtime保存形式はv7。厨房計画・進行中バッチを保存し、物流・人物・予約・貨物の参照を照合する。v6以前は厨房計画なしとして移行する。

供給値の採用理由と正本との差は [D-033](../DESIGN_DECISIONS.md) を参照する。

## 再現方法

```sh
make test-supply
make test-ui
make capture-supply
make preview-supply
```

`test_normal_supply_chain.gd` は通常Mainを起動し、初期5,000G・資材50から建設、採用、配属、購入の正式Commandを使う。人工の客・完成施設・在庫・無料資源を挿入しない。画面の購入・設定・Save復元は別の `test_supply_management.gd` で実Button／入力を操作する。

供給テストの配置はFRONTに受付 `(-8,0)`、食堂 `(2,0)`、客室 `(-8,2)`。BACKに倉庫 `(-8,0)`、厨房 `(2,0)`、職員ドア `(0,0)`。客室への通路はFRONT `(-4,1)` → `(-4,2)` → `(-5,2)`・`(-6,2)`。完成に必要な実時間を進めてから配属する。

アカネを受付、ジーナを倉庫、チカを厨房、イリスとユノを食堂へ日勤配属する。原料40個を購入し、厨房の目標在庫を8個に設定する。次の2営業日の06:00にも40個ずつ購入する。採用時の契約金と日々の給与も通常会計へ含める。

保存先はテスト専用 `user://tests/normal_supply_<process_id>/cargo`、その他の各テストもプロセス別の専用保存を使う。通常の手動保存や自動保存へ書き込まない。

`preview-supply` は初日の12:20で停止した試遊を開く。Spaceで再開し、商品・勤務・建設を試せる。手動保存・読込と自動保存は無効。

画像は `artifacts/supply-chain/{purchase,kitchen,delivery}.png`、3日運営の数値は `artifacts/supply-chain/normal-play-report.json`。`capture-supply` は初日の稼働場面を撮影して終了するため、3日間の受入そのものは `test-supply` の結果を見る。

## 検証結果

| 対象 | 確認結果 |
|---|---|
| 厨房の原料・生産・中断・期限・容量・復元 | 140項目 PASS |
| Runtime v7／旧v6の移行・偽装旧保存拒否 | 20項目 PASS |
| 実物流・途中保存・障害復旧・外部Command境界 | 81項目 PASS |
| 有料購入・決済失敗・停止後出庫・返送容量・複数倉庫 | 84項目 PASS |
| 商品UI・下書き・重複防止・待機購入Save復元 | 37項目 PASS、1280×720も実描画確認 |
| 通常初期予算→実供給→食堂売上→配送途中保存 | 初日の35項目 PASS、1440×810の3タブを目視確認 |
| 通常3営業日の締め・再仕入れ・最終Snapshot復元 | 45項目 PASS、終了コード0、SCRIPT ERRORなし |

通常初期5,000G・資材50から、原料を合計120個／360G仕入れた。倉庫→厨房30便、厨房→食堂51便が完了し、食堂売上は毎日1,400G、累計4,200G、宿泊売上は累計800Gだった。給与は毎日645G、3日とも未払0・照合差0。3日目の決算後残金は26,115G、資材は4。配送途中の専用ディスクSave復元と5分再生の全状態一致、3日完了時のSnapshot復元を確認した。完全ログは `artifacts/supply-chain/normal-play.log`。

大きな残金には受付の直接収入22,420Gが含まれる。この数字は供給・日次記帳の成立を示すもので、価格や利益バランスの合格ではない。今回の3日自動受入は、価格・営業Policyの通常UI、改善を怠った対照試遊、初見プレイヤーによる確認を代替しない。

既存回帰は構成ターゲットを分割して実行した。`test-s0/s1/s2/s3/s6/mvp` の38本・3,389項目が成功終了し、`check`・`test-s4`・`test-s5`（旧保存fixture補正後のDefense再確認を含む）・`test-acceptance`・`test-ui`・`test-perf` も完了した。性能のsmokeは部品を直接合成する検証で、通常シーン全体の描画性能を示さない。

## 長期運営の処理負荷

本番Runtime付きの通し受入は、部品smokeより大幅に時間を要した。途中保存のコピーから8ゲーム分だけを隔離再生した短い計測では、Main付き合計479.8msのうちSnapshot生成52.3ms・決定性Digest276.8ms・購読UI82.4msだった。UIを外しても合計375.0msで、Snapshot＋Digestが331.2msを占めた。客2人・台帳37件・Snapshot約380KBでの値であり、3日目の代表値や描画fpsではない。

主因はRuntimeが毎分全世界のSnapshotを再作成し、再帰的に正規化してSHAを計算する経路と判断する。物流は同じ8分で約4.5ms、施設／厨房は約0.3msだった。変更のない集約の再利用、画面更新頻度、履歴の増加に対する計測を後続課題にする。決定性の照合や保存検証を省いて高速化する変更は今回行わない。初日途中のSnapshotではイベント履歴が約166KB・単体Digest15.45msで最大だった。日数による劣化の程度は追加計測する。根拠は `artifacts/supply-chain/runtime-profile.log` と `runtime-profile-parts.log`。

## 残る課題

- 正本の料理ポイント・食器・施設解禁との統一、仕入れ設定の継続自動発注、価格・サービス会計の調整は残る。
- 建設済みの倉庫へ仕入れ品を直接受け取る方式で、外部業者の車両・納期はまだ扱わない。
- 職員ドアを使う実物流は接続したが、一般職員の出勤・職場到着後稼働、昇降機の実乗降はP2の別項目である。
- この検証だけで初見30分の遊びやすさ、経済バランス、Windows実機性能、P1全体の完成を判定しない。