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

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

接続した挙動

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

供給値の採用理由と正本との差は D-033 を参照する。

再現方法

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全体の完成を判定しない。

7.0 KiB Raw Blame History Unescape Escape