Record three-day supply acceptance and recovery checkpoint
This commit is contained in:
Takeshi
@@ -1,6 +1,6 @@
|
||||
# 制作課題台帳
|
||||
|
||||
更新日: 2026-09-09。承認済み [全体制作計画](DEVELOPMENT_PLAN.md) の実行台帳。基準はドット断面版コミット `423fd6dd2e75da926e38b35ac8c435e462b168d9`、制作ブランチは `codex/first-operating-loop`。P1の通常開業ガイド・継続配属API／パネル・日次帳簿を接続し、通常初期予算での最小宿を単日受入・専用保存復元で確認した。全自動テストの構成ターゲットは成功終了。その後、有料仕入れ・厨房の自律生産・実配送を通常の商品UIへ接続した。3営業日の最終受入は進行中。部品の接続、単日成立、段階全体の完成を区別する。
|
||||
更新日: 2026-09-09。承認済み [全体制作計画](DEVELOPMENT_PLAN.md) の実行台帳。基準はドット断面版コミット `423fd6dd2e75da926e38b35ac8c435e462b168d9`、制作ブランチは `codex/first-operating-loop`。P1の通常開業ガイド・継続配属API／パネル・日次帳簿を接続し、通常初期予算での最小宿を単日受入・専用保存復元で確認した。全自動テストの構成ターゲットは成功終了。その後、有料仕入れ・厨房の自律生産・実配送を通常の商品UIへ接続した。供給込み3営業日の自動受入45項目も合格した。部品の接続、単日成立、段階全体の完成を区別する。
|
||||
|
||||
## 状態の読み方
|
||||
|
||||
@@ -31,13 +31,15 @@ P0の保存物はGit管理対象の制作ファイル。`.godot/`、`build/`、`
|
||||
|
||||
| ID | 実装済みの根拠 | 未接続・仕様差・検証残と次の確認 |
|
||||
|---|---|---|
|
||||
| PLAY-01 | **最小ループ実装済み・単日確認**。初期Gold 5,000／資材50、通常UIの建築経路で受付1・一般客室2・通路7、アカネ雇用・配属、自然来客の宿泊320G、翌06:00決算まで確認。`test_first_operating_day.gd` | 受入は見学Fixture・無料在庫・客挿入なし。**3営業日未検証／バランス調整残**。受付売上6,020G等の数値を正本と照合し、補給・厨房・配送込みの序盤へ広げる |
|
||||
| PLAY-02 | **通常UI接続済み・個別API103項目／単日確認**。雇用済み一覧、配属・再配属・未配属、DAY／NIGHT継続計画、変更不可・経路・定員等の理由、予約Commandと保存復元。StaffService v4、D-032 | 実通勤と到着後の稼働はMOVE-07へ分離。現在は経路存在を検証して論理配属し、人物位置は変えない。長期の複数施設・人員不足対応は3営業日受入で検証 |
|
||||
| PLAY-01 | **最小ループ実装済み・単日確認**。初期Gold 5,000／資材50、通常UIの建築経路で受付1・一般客室2・通路7、アカネ雇用・配属、自然来客の宿泊320G、翌06:00決算まで確認。`test_first_operating_day.gd` | 受入は見学Fixture・無料在庫・客挿入なし。**供給込み3営業日も自動確認／バランス調整残**。受付売上6,020G等の数値を正本と照合し、受付の直接収入と価格・営業Policyを調整する |
|
||||
| PLAY-02 | **通常UI接続済み・個別API103項目／単日確認**。雇用済み一覧、配属・再配属・未配属、DAY／NIGHT継続計画、変更不可・経路・定員等の理由、予約Commandと保存復元。StaffService v4、D-032 | 実通勤と到着後の稼働はMOVE-07へ分離。現在は経路存在を検証して論理配属し、人物位置は変えない。5職員・複数施設・3営業日の継続配属は供給受入で確認。実通勤と人手不足への人手試遊は残る |
|
||||
| PLAY-03 | **通常UI接続済み**。完成倉庫への有料購入、容量・期限・予約、実porter TaskとPathによる倉庫→厨房→食堂。物流81項目、管理処理84項目、商品UI37項目の回帰 | 仕入れは倉庫への即納。外部業者の納期、継続自動購入、複数品目、正本の食器・消耗品は後続。経路断・満杯・腐敗・担当不能での保持／再試行／返送を検証 |
|
||||
| PLAY-04 | **自律生産接続済み・140項目確認**。明示設定した厨房で原料4→料理4、15稼働分、目標在庫、入力予約・出力容量・期限・中断復帰を扱う。見学用の無料在庫に依存しない | **仕様差をD-033で明記**。今回の原料／基本料理を維持し、料理ポイント＋食器、食堂価格・所要時間との統一は残す |
|
||||
| PLAY-05 | **日次帳簿UI接続済み・単日確認**。06:00営業日、入出金と建築、確定売上・運営費・給与・利益・前日差・未払・施設別損益を表示。翌朝給与120G、未払0、照合一致 | **操作未接続／仕様差・調整残**。価格・営業／休業Policy UI、受付の直接収入、宿泊の決済・記帳時点、維持費分類を正本と照合。受付売上6,020G・全利益6,040Gは製品バランス合格ではない |
|
||||
| PLAY-06 | **Runtime v7と配送途中Save復元を確認**。厨房計画・バッチ、Request・Task・carrier・貨物・予約を照合。旧v6移行20項目、商品UIの待機購入も再読込後に一度だけ確定 | 建設中・行列中・配送中を組み合わせた再起動の人手試遊、手動10枠UIと製品の保存導線は残る |
|
||||
|
||||
追加の供給受入では初期予算から倉庫・厨房・食堂と職員5人を運営し、3日とも給与645G・未払0・照合差0を確認した。食堂売上4,200G、原料360G、実配送81便。配送途中のディスクSaveと最終Snapshotを復元。詳細は [供給検証記録](qa/P1_SUPPLY_CHAIN.md)。価格・営業Policy・改善対照試遊が残るためP1全体は未合格とする。
|
||||
|
||||
確認済みの単日経路: 通常初期予算→建設→アカネの日勤配属→自然来客宿泊→翌06:00給与・決算→専用保存復元。`make test-opening` で再現し、`make capture-opening` は `artifacts/first-operating-day/{opening,staffed,first-close}.png` を出力する。建築は現金出金、営業成績は確定損益として分離した。最終UIはPixel238・Dashboard121・Staff44・開業35項目が合格し、既存全自動テストの構成ターゲットも成功終了した。詳細は [P1単日検証記録](qa/P1_FIRST_OPERATING_DAY.md) を参照する。
|
||||
|
||||
## P2：上下移動と混雑
|
||||
@@ -89,6 +91,8 @@ P0の保存物はGit管理対象の制作ファイル。`.godot/`、`build/`、`
|
||||
|
||||
過去の全System合格記録、直前のUI・カメラ359項目、見学のPNGは、それぞれ対象が異なる。この台帳の作成では全System試験やWindows実機を再実行していない。
|
||||
|
||||
通常Runtimeの性能に追加の計測課題がある。供給受入の途中保存から8分を再生した短い測定では、Main付き479.8msの約69%が全Snapshot生成＋Digest、約17%が購読UIだった。部品smoke合格とは区別し、3日以上の履歴増加とx1/x4の実シーンで測る。詳細は [供給検証記録](qa/P1_SUPPLY_CHAIN.md)。
|
||||
|
||||
## P6・P7：製品版と配布
|
||||
|
||||
- **画面へ未接続／未実装**: Rank 4〜7の本編進行、拡張施設、研究・投資・探索、長編本文と結末。基盤やDefinitionの存在と、遊べる章の完成を分ける。
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
作成日: 2026-09-09
|
||||
基準: The Tower SPを参考にしたドット絵の断面経営ゲーム。ローカル制作版を正本とする。
|
||||
状態: 2026-09-09 ユーザー承認済み。P0の基準点整備を完了し、P1の通常営業の最小ループを実装・単日確認済み。有料仕入れ・厨房・実配送を通常UIへ接続し、部品・UI・配送途中保存の検証は合格。3営業日の最終受入を進行中。
|
||||
状態: 2026-09-09 ユーザー承認済み。P0の基準点整備を完了し、P1の通常営業の最小ループを実装・単日確認済み。有料仕入れ・厨房・実配送を通常UIへ接続し、部品・UI・配送途中保存の検証は合格。通常予算からの供給込み3営業日も45項目合格。価格・営業Policy、性能と初見試遊は継続課題。
|
||||
|
||||
## 1. 目指す体験と計画の前提
|
||||
|
||||
|
||||
@@ -172,6 +172,7 @@
|
||||
- SupplyLogisticsBridge は勤務中のporterへ実Taskを割り当て、荷元への歩行→積込→納品先への歩行→納品を実行する。満杯・経路断・担当不能では貨物を保持し、部分腐敗時は残った品を実際に荷元へ返す。
|
||||
- 配送中の保存、無効参照の拒否、厨房counterの再使用防止を含むRuntime v7を追加。旧v6以下は生産計画なしとして復元し、既存の物流Commandは維持する。供給配送の到着確認は手動advanceで迂回できない。
|
||||
- 倉庫の担当職種を実catalogのporterへ補正し、食堂はattendantも配属可能にした。設定値・正本の料理ポイント／食器等との差はD-033へ記録。
|
||||
- 初期5,000G・資材50、通常建設と採用5人、有料食材120個で3営業日を45項目確認。食堂売上4,200G、実配送81便、3日とも給与645G・未払0・帳簿一致。配送途中のディスク保存と最終Snapshotを復元した。
|
||||
- 部品・UI・通常運営の検証範囲は [供給検証記録](qa/P1_SUPPLY_CHAIN.md)。`make test-supply`、`make capture-supply` で再現する。
|
||||
|
||||
## 統合済みの運営縦断
|
||||
@@ -192,7 +193,7 @@
|
||||
- 配置と同一Shiftから関係Event候補を生成する接触判定と事前リスクPreview
|
||||
- 夕方混雑、FRONT／BACK比較、健全／地下収支を直接比較するScenario Test
|
||||
- 100客・30従業員の実描画Frame試験
|
||||
- 通常開始からの建設・雇用・配属・厨房生産・仕入れ・配送・収支確認・保存再開による3営業日運営
|
||||
- 供給込み3営業日の自動受入を踏まえた、価格・営業Policy操作と欠品・人手不足・経路不足の改善比較、初見プレイヤーの継続試遊
|
||||
- 専用ドット動作、製品用アート、音響、物語本文、完全なチュートリアル、バランス調整
|
||||
|
||||
## 実行方法
|
||||
|
||||
@@ -19,6 +19,17 @@ bundleはこの基準点までの完全なGit履歴を保持します。作成
|
||||
|
||||
元Drive版は内容照合が終わるまで復旧候補として残します。制作正本へ自動で同期したり、復旧のために元Drive版を削除したりしません。
|
||||
|
||||
## 追加の保存点
|
||||
|
||||
基準版を保持したまま、同じバックアップフォルダへ次の完全履歴bundleを追加する。
|
||||
|
||||
| 内容 | 実装コミット | bundle名 |
|
||||
|---|---|---|
|
||||
| 通常開業ガイド・継続配属・単日決算 | `29a660a` | `the-tree-first-operating-day-2026-09-09.bundle` |
|
||||
| 有料仕入れ・厨房・実配送・商品パネル | `627b200` | `the-tree-supply-chain-2026-09-09.bundle` |
|
||||
|
||||
供給版bundleは実装後の最終検証記録まで含む。先端は `git bundle list-heads` で確認する。SHA-256は同名の `.bundle.sha256` ファイルに記録する。供給版の復元・試遊では、下の基準版bundleのファイル名を供給版へ置き換え、インポート後に `make test-supply` または `make preview-supply` を使う。3タブのPNGと検証ログはGit外の `artifacts/supply-chain/` にあり、bundleには含まれない。
|
||||
|
||||
## 1. bundleを確認する
|
||||
|
||||
現在の制作フォルダで実行します。いずれも読み取り専用です。
|
||||
|
||||
@@ -45,10 +45,20 @@ make preview-supply
|
||||
| 有料購入・決済失敗・停止後出庫・返送容量・複数倉庫 | 84項目 PASS |
|
||||
| 商品UI・下書き・重複防止・待機購入Save復元 | 37項目 PASS、1280×720も実描画確認 |
|
||||
| 通常初期予算→実供給→食堂売上→配送途中保存 | 初日の35項目 PASS、1440×810の3タブを目視確認 |
|
||||
| 通常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`。
|
||||
|
||||
## 残る課題
|
||||
|
||||
- 正本の料理ポイント・食器・施設解禁との統一、仕入れ設定の継続自動発注、価格・サービス会計の調整は残る。
|
||||
|
||||
Reference in New Issue
Block a user