Record original-alignment implementation and traceability checkpoint

Capture current source, content data, tests, asset licenses, and original-specification traceability. Original implementation remains incomplete. The accepted matching UI generation passed 154 suites and 12,253 checks, with eight rendered staff-contract screens reviewed. Latest native Windows and full-original acceptance remain outstanding.

docs/ART_ASSET_PRODUCTION_SPECIFICATION.md

@@ -2,7 +2,9 @@
 
 ## 1. 目的
 
-この文書は、本作に必要な画像を制作し、安全に差し替えるための正本とする。
+この文書は、本作に必要な画像の制作・差し替え手順を定める派生資料とする。基本仕様の原本はユーザー指定の基本仕様書であり、差異がある場合は原本を優先する。
+
+2026-09-29: [原本別の素材実在・必要枠台帳](plans/original-completion-2026-09-29/execution/assets/README.md)を追加。既存素材とコード描画の候補は、完成認定と区別して記録する。
 
 **2026-09-09更新：現在のマップは『The Tower SP』を参考にしたドット絵の断面表示を採用する。** 施設の内装と小さな人物の動きが主役で、Kenney Tiny Dungeon・Tiny Townの16px素材と専用のドット描画を使う。旧生成背景や人物Bustを現在のマップへ戻すための仕様ではない。操作と実装上の制約は [ドット絵表示と見学ガイド](PIXEL_TOWER_VISUALS.md) を参照する。
 
@@ -10,6 +12,8 @@
 
 ## 2. 現在のアートディレクション
 
+2026-09-28: ユーザー提供の『The Tower 2』実ファイルを追加参考として確認した。[素材の観察結果と現実装との差分](THE_TOWER_2_REFERENCE_2026-09-28.md) に沿って、部屋の利用状態・家具に対応した人物位置・待機列・観察時の画面構成を改善する。画像から確認できた事実と未確認の実行時挙動を区別する。ゲーム仕様はユーザー指定の基本仕様書と施設パラメータ訂正を優先する。
+
 - 世界樹の正面断面を大きく見せる。受付・客室・食堂などを内装で識別でき、小さな客と従業員の移動・待機・仕事が読める構成とする。
 - 基本素材はKenneyの16×16pxドット絵。Nearestフィルターを使い、通常表示では整数倍率を優先する。高解像度の絵をぼかして縮小した人物をマップの主役にしない。
 - 幹・葉・部屋・家具は同じドット密度と色調で専用描画する。主色は木色・クリーム・濃緑、裏方の補助色は青緑とする。

docs/DEBUG_COMPLETION_2026-09-27.md

@@ -0,0 +1,55 @@
+# 全件修正・通しデバッグ（2026-09-27）
+
+## 原因と修正
+
+職員配置UIの4件の失敗は、テスト用建物の上下移動を客用通路だけで構成していたことが原因。実装済みの明示的な階段必須ルールではその客室へ到達できず、開業ガイドは正しく「道をつなぐ」を返していた。
+
+`test_staff_management.gd` を、初日営業の受入試験と同じく客用階段で上下をつなぐ配置へ修正した。期待値を緩めたり、到達判定・配置条件を無効にしたりしていない。途中までの階段では配属案内へ進まない負例を追加。昼勤・配属解除・夜勤予定の従来の4判定も維持し、47項目が成功した。
+
+`test_first_operating_day.gd` はディスク保存からのロード後、翌朝120分の営業を継続してから同じチェックポイントを再実行し、客・従業員・会計・イベントを含む状態digestが一致する検証を追加した。
+
+## 全件実行の範囲
+
+`tests/**/test*.gd` と `tests/run_tests.gd` を全件確認。`test_kernel_and_save.gd` は単独起動用ではなく `run_tests.gd` から呼び出すため、重複起動せず内包試験として実行する（ソース側79エントリーポイント）。書き出したPCKを必要とする `tests/export/test_exported_opening.gd` は配布アプリ生成後に別途実行。通常の `make test` の呼び出しに含まれていなかった交通比較試験も対象とする。
+
+再実行用に `tools/run_all_tests.py` と `make test-all` を追加した。失敗で後続試験を打ち切らずログと一覧を残し、1件でも失敗すれば非ゼロで終了する。ユーザーの通常セーブを使わず、既存試験の専用保存先を使用する。
+
+## 通しデバッグの範囲
+
+全ソース試験成功後、通常の描画を有効にした実シーンで、次を順番に確認し、すべて成功した。
+
+1. 初期資金から受付・客室・階段を建設し、雇用・配属、自然入客、宿泊売上、翌朝決算、ディスク保存・ロード、翌朝の営業継続と一致再実行。
+2. 初期資金から倉庫・厨房・食堂を建設し、食材購入、運搬員の実移動、調理、配膳、自然入客の売上、搬送途中の保存復元、3営業日の仕入れ・給与・会計照合。
+3. エレベーターの建設・増設、実際の乗車・到着、乗車途中の保存復元。
+4. 客と職員のドットアニメーションの連続描画。
+
+これは自動操作・実描画による上記シナリオのデバッグであり、未実装のシナリオ内容や全ルートを完走した意味ではない。各結果・画像・ログは `artifacts/debug-2026-09-27/` に保存する。
+
+全件試験内の3営業日供給受入: 49項目成功。食堂売上3,000G、原材料配送30便、料理配送72便、残金2,855G。約746秒で完了。これは全件通過後の描画付き再検証とは別に記録する。
+
+## 全件試験結果
+
+ソース側79エントリーポイント・6,850チェック、全件PASS。配布PCK起動13チェック、2万セルのフル負荷試験24チェックも全件PASS。`all-tests-summary.json` に重複のないソース側集計を保存。全件成功を確認後に描画付きの通しデバッグを開始した。
+
+配布アプリ本体はソース外の `/tmp` を作業場所として `--headless --quit-after 5` で正常起動・終了（終了コード0）を確認した。初回の検証用 `--main-pack` 指定はreleaseテンプレートの仕様により拒否されたため、その試行を合格に数えず、通常の内蔵PCK起動で再確認した。配布PCKの13項目は別途開発用Godotから実行して合格。
+
+## 通しデバッグの最終結果
+
+|描画付きシナリオ|結果|
+|---|---|
+|新規開始〜翌朝決算〜保存ロード〜翌朝の営業継続・一致再実行|46チェック成功|
+|仕入れ・実搬送・調理・販売・3営業日の給与と会計照合|49チェック成功|
+|昇降機建設・増設・乗車・到着・途中保存と客の重複描画防止|32チェック成功|
+|ドットアニメーション|72フレーム取得、実画像を確認|
+
+供給シナリオの描画あり・なしで、所持金2,855G、食堂売上3,000G、宿泊売上、配送件数（原材料30便・料理72便）、3日分の決算が一致。3日とも帳簿照合済み・給与未払0。画面は開業案内、ロード後の翌朝帳簿、厨房、配送、昇降機内の乗客、客・職員のアニメーションを確認した。
+
+今回の全件修正と上記範囲の通しデバッグを完了した。既知の4失敗は解消され、通し実行で新たな失敗は発生しなかった。テスト対象ソースのハッシュが実行後も一致することを確認済み。
+
+- [全件集計](../artifacts/debug-2026-09-27/all-tests-summary.json)
+- [完了記録](../artifacts/debug-2026-09-27/completion.json)
+- [通しアニメーション](../artifacts/debug-2026-09-27/walkthrough.gif)
+- [翌朝の帳簿画面](../artifacts/debug-2026-09-27/opening-images/second-morning.png)
+- [昇降機の画面](../artifacts/debug-2026-09-27/elevator-cabin.png)
+
+起動先は `build/macos/TheTree-Verified-2026-09-27.app`。ローカルとGoogle Drive双方の `TheTree-ドット版を起動.command` をこの検証済み版へ更新した。旧アプリと通常プレイのセーブは保持している。Windows実機や未実装ルートの完走を今回の完了範囲に含めない。

docs/DEVELOPMENT_BACKLOG.md

@@ -1,5 +1,11 @@
+> 原本優先: 利用者指定の基本仕様書と施設パラメータ訂正が本書に優先します。現在の差異・未完了項目は [原本との実装対応](traceability/original/IMPLEMENTATION_STATUS.md) を参照してください。
+
+2026-09-29救護追記: 医療職の回収→裏通路・扉・階段での搬送→医務室治療、体力/救護状態UI、保存復元を接続。[検証記録](traceability/original/STAFF_RESCUE_VERIFICATION_2026-09-29.md)。同伴エレベーター乗車と待機室での休息を追加実装。[続報](traceability/original/LABOR_COMPLETION_2026-09-29.md)。
+
 # 制作課題台帳
 
+2026-09-29追記: 原本B-4.2の最大欲求優先AIを実装し、HUDへ来客観察パネルを追加。関連627項目を再検証し、配布版を更新した。[検証記録](traceability/original/GUEST_AI_VERIFICATION_2026-09-29.md)。天候等は継続残件。救護搬送の現行版統合は下記参照。
+
 更新日: 2026-09-09。承認済み [全体制作計画](DEVELOPMENT_PLAN.md) の実行台帳。基準はドット断面版コミット `423fd6dd2e75da926e38b35ac8c435e462b168d9`、制作ブランチは `codex/first-operating-loop`。P1の通常開業ガイド・継続配属API／パネル・日次帳簿を接続し、通常初期予算での最小宿を単日受入・専用保存復元で確認した。全自動テストの構成ターゲットは成功終了。その後、有料仕入れ・厨房の自律生産・実配送を通常の商品UIへ接続した。供給込み3営業日の自動受入45項目も合格した。部品の接続、単日成立、段階全体の完成を区別する。
 
 ## 状態の読み方
@@ -58,6 +64,12 @@ P0の保存物はGit管理対象の制作ファイル。`.godot/`、`build/`、`
 
 ## P3：営みと初見の操作
 
+2026-09-29追記: T2-V01〜V05の表示改善を実装。施設状態・室内利用位置・共用通路の待機列・初期カメラと営業階への復帰・実乗客と満員表示を接続した。[最新検証と配布版](THE_TOWER_2_COMPLETION_2026-09-29.md) を参照。下記の9月28日の残件記述は履歴。P1〜P5全体、Windows実機性能、原本の未実装項目が完了したという意味ではない。
+
+実機記録の受領後: [Windows実機レビュー](THE_TOWER_2_WINDOWS_REVIEW_2026-09-28.md) に基づき、T2-V03の一部として「画面移動」ボタンと左ドラッグを実装。建設・掘削との排他切替、Esc解除、ドラッグ取り残し防止を関連370項目で確認。初期カメラ・列・施設状態・混雑表現の改善は引き続き残件。
+
+2026-09-28追加: ユーザー提供の『The Tower 2』を参考資料として確認。[T2-V01〜V05](THE_TOWER_2_REFERENCE_2026-09-28.md) を表示改善の残件とする。施設状態の内装表現、施設別利用位置と待機列、初期カメラ、昇降機の混雑表現を順に改善する。参照調査は完了、これらの改善実装・受入は未完了。LIFE-02の古い足スライス方式は現在の横向き専用ポーズへ置換済みであり、[2026-09-27の描画変更記録](PIXEL_ANIMATION_2026-09-27.md) を現状の根拠とする。
+
 | ID | 現在地 | 次の完了判定 |
 |---|---|---|
 | LIFE-01 | **一部実装済み**。Runtime位置、サービス中位置の描画投影、待機・利用・作業Badge、停止 | 実状態に基づく歩行／待機／利用／睡眠／清掃／運搬／休憩の一覧と利用位置を確定する |

docs/IMPLEMENTATION_STATUS.md

@@ -1,8 +1,10 @@
 # 実装状況
 
-この文書は仕様書そのものではなく、現在のコードがどこまで到達しているかを記録する。ゲームルールの正本は `GAME_SPECIFICATION.md`、System境界と不変条件の正本は `SYSTEM_SPECIFICATION.md` とする。
+この文書は仕様書そのものではなく、現在のコードがどこまで到達しているかを記録する。利用者指定の基本仕様書が原本であり、`GAME_SPECIFICATION.md` と `SYSTEM_SPECIFICATION.md` は派生資料として扱う。現行の判定は [原本との対応](traceability/original/IMPLEMENTATION_STATUS.md) を参照。
 
-更新日: 2026-09-09。ドット断面版の基準コミットは `423fd6dd2e75da926e38b35ac8c435e462b168d9`。復旧方法は [RECOVERY_GUIDE.md](RECOVERY_GUIDE.md)、承認済み制作計画の課題と検証残は [DEVELOPMENT_BACKLOG.md](DEVELOPMENT_BACKLOG.md) を参照する。
+以下は2026-09-09時点の履歴。00:00決算・x3・同伴救護・待機室休息の現行記録は [労務検証](traceability/original/LABOR_COMPLETION_2026-09-29.md) と原本対応表を優先する。
+
+旧更新日: 2026-09-09。ドット断面版の基準コミットは `423fd6dd2e75da926e38b35ac8c435e462b168d9`。復旧方法は [RECOVERY_GUIDE.md](RECOVERY_GUIDE.md)、承認済み制作計画の課題と検証残は [DEVELOPMENT_BACKLOG.md](DEVELOPMENT_BACKLOG.md) を参照する。
 
 以下のSystem別一覧は既存の実装・試験記録を引き継いでいる。直前のドット版変更では起動とUI・カメラの359項目、その後の配属APIでは103項目の個別確認記録がある。P1追加後に `make check` と `make test` の全構成ターゲットを2群に分けて実行し、全件が成功終了した。追加の配属API103項目、スタッフ画面44項目、通常開業35項目も合格。対象と制約は [P1単日検証記録](qa/P1_FIRST_OPERATING_DAY.md) に記録した。通常初期予算での最小宿は単日受入・保存復元を確認したが、14日MVP、Windows実機性能、通常操作だけによる3営業日は別の完成条件として残る。
 

docs/PIXEL_ANIMATION_2026-09-27.md

@@ -0,0 +1,20 @@
+# ドットアニメーション表示の修正（2026-09-27）
+
+通常の制作先 `/Users/korizatou114/Projects/とりにく工房ゲーム制作部` を変更した。Google Drive側の旧ソースは混在を避けて上書きせず、ローカルの修正版アプリを開く `TheTree-ドット版を起動.command` を双方に配置した。
+
+## 変更
+
+既存の部屋・家具・階層のドット断面表示とKenney素材を維持し、人物を専用の横向き16×18グリッド描画に変更。静的アトラスの足部分の移動から、8段階の脚・腕・上下動による歩行へ置き換えた。清掃、作業、食事、荷物運搬、睡眠、気絶を状態に応じて描き分ける。左右反転、既存の移動補間・速度・一時停止に対応。シミュレーションの位置や経済は変更しない。
+
+既存Kenney素材には横向きの専用歩行フレームがないため、人物のみコードで独自のポーズを描画する。Kenneyの部屋用素材とライセンスは保持。The Towerの画像・キャラクターは使用していない。
+
+## 検証
+
+- ピクセル表示・カメラ等の既存試験238項目、ダッシュボード121項目成功。
+- `make check` 成功。
+- 1440×810、2倍ズームの実運営画面を確認。6秒・12fpsの72フレームを取得し、72枚すべて異なることとワールド領域の変化を確認。ポーズ別の網羅的映像受入ではない。
+- macOSアプリを書き出し、ソース非依存のPCK起動・初回建設13項目成功。今回は描画変更の関連試験を行い、ゲーム全体の全試験は再実行していない。
+
+[動画プレビュー](../artifacts/pixel-animation-2026-09-27/preview.gif) / [確認画像](../artifacts/pixel-animation-2026-09-27/preview.png)
+
+起動用アプリ: `build/macos/TheTree-Pixel-2026-09-27.app`。過去の配布アプリは上書きしていない。Windows版は今回再配布していない。

docs/PIXEL_TOWER_VISUALS.md

@@ -22,8 +22,11 @@ make test-pixel-ui  # ドット表示・カメラ・実施設クリックの回
 
 | 操作 | 動作 |
 |---|---|
+| 上部の来客ボタン | 客を選び、四欲求・所持金・忍耐・現在の目的地を確認 |
 | ホイール | カーソル付近を基準に拡大・縮小 |
 | 中ボタンドラッグ | 断面を移動 |
+| 画面移動ボタン → 左ドラッグ | 断面を移動。再度ボタンを押すかEscで解除。建設・掘削選択時も解除 |
+| 営業階 | 現在の層の建設済み施設にカメラを合わせる（最大200%） |
 | Home | 全体表示へ戻す |
 | G | 格子と混雑表示を切り替え |
 | B | 建築パレットを開閉 |
@@ -31,27 +34,34 @@ make test-pixel-ui  # ドット表示・カメラ・実施設クリックの回
 | H | 雇用候補を開閉 |
 | Tab | 客用の表層 / 裏方の裏層を切り替え |
 | E / R | 掘削モード / 建築物を回転 |
-| Space / 1・2・4 | 停止・再開 / 時間倍率を変更 |
+| Space / 1・2・3 | 停止・再開 / 時間倍率を変更 |
 | Esc | 雇用候補・使用中のツールを解除。ツール未使用時はパネルも閉じる |
 | 施設をクリック | 営業・待機列・人員などの実状態を右側に表示 |
 
-初期状態では建築パレットと運営詳細を閉じ、マップを広く見せる。詳細はマップ右側に重ねて開く。判断が必要なイベントは詳細パネルを開き、選択肢を表示する。案内は下部に常時表示する。
+初期状態では建築パレットと運営詳細を閉じ、空の宿は入口付近を200%で表示する。施設がある場合は施設範囲へ合わせる。プレイ中は自動でカメラを追従させず、必要な時に「営業階」を押す。詳細はマップ右側に重ねて開く。判断が必要なイベントは詳細パネルを開き、選択肢を表示する。案内は下部に常時表示する。
 
 ## 現在の表示
 
 - 世界樹、空、幹、葉、床と室内をドット主体で描く。受付のカウンター、客室のベッド、食堂の卓、厨房などを施設ごとに描き分ける。
 - Kenneyの[Tiny Dungeon](https://kenney.nl/assets/tiny-dungeon)と[Tiny Town](https://kenney.nl/assets/tiny-town)を人物・小物・庭木に利用する。16×16px素材、Nearest、Mipmap無効で表示する。配布元とCC0ライセンスは[素材一覧](../assets/kenney/README.md)と各パックの`License.txt`に記録している。
-- 客と従業員はRuntime上の実在人物で、移動元と現在セルの間を補間する。同じ元絵の足のずらし・上下動・左右反転で歩行を表現し、待機・利用・作業の小さな状態表示を添える。停止中はアニメーションも止まり、人物位置は確定セルを表示する。
+- 客と従業員はRuntime上の実在人物で、移動元と現在セルの間を補間する。独自の横向きドット人物の歩行・待機・食事・睡眠・清掃・作業・運搬ポーズで表現する。停止中はアニメーションも止まり、人物位置は確定セルを表示する。
 - UIは濃緑・クリーム・木色の小さな平坦な枠を使用する。従来の高解像度生成背景・人物Bust・装飾Skinは現在のマップに使用しない。小型のUIアイコンは既存Theme参照を残す。
 - ズーム・移動・表示レイヤー・格子の切替は描画側だけで扱う。建築の占有セルや保存データの形式は変えない。
 
 ## 制約と次の制作
 
-- Kenneyの導入パックは静止画である。現在の歩行はコードによる元絵の加工であり、手描きの歩行・食事・清掃・運搬の専用アニメーションは今後追加する。Atlasで隣にいる別人物を歩行差分として再生していない。
-- エレベーター本体の昇降・乗降・待ち行列を含む運行は未実装。施設カタログの昇降機は接続の試作用で、見学では既存の上階通路を使って人物の行動を確認する。
+- 人物は `pixel_people.gd` の独自ポーズを使う。Kenneyは家具・小物などに使用し、原作ゲームから抽出した画像は配布物に含めない。
+- エレベーターは実運行・乗降と連動する。待機者は歩ける乗り場の外側へ並べ、実乗客はかご内だけに描画する。定員・満員・停止と待機人数を表示する。入りきらない人数は重ねず「他N人」で示す。
 - 見学は在庫を用意した再現用の運営場面であり、収支・配送・混雑の完成度を保証する受入試験ではない。キャプチャにはその時点の実状態が出る。
 - 施設ラベルは表示幅・選択・ホバーに応じて省略する。大きい世界を全体表示すると縮小されるため、人物の動きはズームして確認する。
 
 表示の主な実装は`scenes/main/world_preview.gd`、専用の家具描画は`scripts/ui/pixel_tower_art.gd`、UIは`scenes/main/main.gd`。見学シナリオは`scripts/ui/pixel_tower_demo.gd`、出力処理は`tests/ui/capture_pixel_tower.gd`にある。回帰テスト`tests/ui/test_pixel_tower.gd`は実受付の建設・完工を経由して、ズームと移動後の占有セル命中、表裏の選択、地下を含む座標往復、停止時アニメーション、描画操作前後のシミュレーションダイジェスト不変を確認する。
 
 接客・宿泊サービス中の客は、経路上のアクセスセルから施設内の利用位置へ描画上だけ投影する。経路探索、権威セル、保存状態は変更しない。
+
+2026-09-29: 未稼働は暗い内装、破壊・摘発後の休止は閉鎖線と文字、稼働中は実利用人数と照明で識別する。利用位置と家具を共通化し、人物を同じ枠へ循環配置しない。`customer_capacity` と在庫容量は区別する。描画は稼働状態・料金・休止解除条件を変更しない。[実装・検証記録](THE_TOWER_2_COMPLETION_2026-09-29.md)。
+
+
+2026-09-29: 救護中の患者を担当医療職の位置に重ねて表示し、医務室治療中はベッドに表示。治療人数は実タスクから集計。従業員パネルに体力と救護段階を表示。
+
+2026-09-29続報: 業務用EVは患者と救護者の2席を表示。待機室は到着済みの非番従業員を室内に描画し、休憩人数を表示する。状態ラベルも実際の移動・到着に連動する。

docs/PLAYTEST_GUIDE.md

@@ -12,7 +12,7 @@
 | エディター | `make editor` | 開いた後に実行ボタンまたはF5で起動 |
 | 建設済みの宿を見学 | `make preview-pixel` | 受付、食堂、厨房、客室、通路、実際の客・従業員を用意。保存なし |
 | 時間差の画像を出力 | `make capture-pixel` | `artifacts/pixel-tower/` にPNG 2枚と運営状態JSONを生成 |
-| 通常開業の単日受入 | `make test-opening` | 見学Fixtureなしで通常UIのCommand経路を使い、初売上・翌06:00・保存復元を検証 |
+| 通常開業の単日受入 | `make test-opening` | 見学Fixtureなしで通常UIのCommand経路を使い、初売上・00:00決算・翌朝・保存復元を検証 |
 | 仕入れ・厨房・配送をすぐ試遊 | `make preview-supply` | 初期予算から通常建設・実購入した宿を12:20まで進め、停止して開く。Spaceで再開。保存なし |
 | 有料仕入れ・厨房・配送の検証 | `make test-supply` | 通常予算から供給を接続し、配送途中保存と3営業日の運営を検証 |
 | 稼働中の商品パネルを撮影 | `make capture-supply` | 通常建設・実購入で用意した初日の仕入れ／厨房／配送をPNG出力 |
@@ -42,7 +42,7 @@
 | 開業ガイドを折り畳む | マップ左上の「開業の手引き」の見出しをクリック |
 | FRONT／BACK切替 | 下部の「客用・表層」「裏方・裏層」、または `Tab` |
 | 一時停止／再開 | 上部の「停止／再開」、または `Space` |
-| 速度変更 | 上部のx1／x2／x4、または `1`、`2`、`4` |
+| 速度変更 | 上部のx1／x2／x3、または `1`、`2`、`3` |
 | 拡大・縮小 | マップ上でホイール。カーソル付近を基準に拡縮 |
 | 断面を移動 | マップ上で中ボタンドラッグ |
 | 全体表示に戻す | `Home` |
@@ -72,29 +72,29 @@
 3. 「客用階段」を `(-4, 2)` へ配置し、10ゲーム分進めます。続いて「客用階段」を `(-4, 3)` に、「客用通路」を `(-8, 3)`、`(-7, 3)`、`(-6, 3)`、`(-5, 3)` に置き、さらに10ゲーム分進めます。階段は3セル、横の通路は4セルです。
 4. `Esc`で建築を解除します。左の「従業員」から「候補を見る」または `H` で雇用候補を開き、受付係のアカネを雇用します。契約金と日給を確認してください。
 5. 「雇用済み」を開いてアカネを選び、配属先を建てた受付、勤務帯を「日勤 06:00〜18:00」にして「配属・勤務帯を変更」を押します。成功表示を確認し、時間進行中の予約Commandなら次の処理まで待ちます。勤務帯は翌日以降も繰り返す計画として保存されます。
-6. `Space`で再開し、必要なら `1`または`4`で速度を選んで、自然に到着した客の宿泊を観察します。現在の宿泊サービスは完了時に売上を記帳するため、到着直後に宿泊売上が出るとは限りません。客が来ない・利用されない場合は施設を選び、接続と人員の理由を確認します。
-7. 翌朝06:00まで進め、左の「帳簿」で第1営業日の確定値を選びます。売上、運営費（契約金等）、給与、営業利益、未払、施設別損益、照合結果を確認します。00:00はまだ同じ営業日です。
+6. `Space`で再開し、必要なら `1`または`3`で速度を選んで、自然に到着した客の宿泊を観察します。現在の宿泊サービスは完了時に売上を記帳するため、到着直後に宿泊売上が出るとは限りません。客が来ない・利用されない場合は施設を選び、接続と人員の理由を確認します。
+7. 00:00まで進め、左の「帳簿」で第1営業日の確定値を選びます。売上、運営費（契約金等）、給与、営業利益、未払、施設別損益、照合結果を確認します。00:00に前日を締め、06:00に再度締めることはありません。
 8. 通常モードの下部「保存」で結果を確認し、その後に時間を進めて「読込」を押します。時刻、配属計画、決算、開業達成表示が保存時点へ戻ることを確かめます。手動UIは `user://saves/manual_ui` の1枠です。
 
 この経路はUIの建築・雇用・配属処理から実行する自動受入で確認しています。受入の途中保存は通常スロットへ触れず、専用 `user://tests/first_operating_day_<process_id>/restore-check` を使用して復元後に整理します。実ユーザーによる初見30分の試遊合格や、見学Fixtureを使わない3営業日の完成とは別の判定です。
 
-現在の配属は経路が存在することを事前検証してから論理的に確定します。配属操作だけで人物の位置は変えず、職場まで実際に通勤して到着後に人員として稼働する統合は今後のMOVE課題です。
+現在の配属は経路が存在することを事前検証してから論理的に確定します。配属操作だけで人物の位置は変わりません。職場まで実際に通勤し、到着後に稼働人数へ加わります。
 
 ## 単日確認の結果と読み方
 
-Seed `424242`、通常初期予算、受付1・一般客室2・通路7・アカネ1人の受入で、次を確認しました。客・サービスの直接挿入、無料の在庫追加、見学Fixtureは使っていません。
+Seed `424242`、通常初期予算、受付1・一般客室2・客用階段3・通路4・アカネ1人の受入で、次を確認しました。客・サービスの直接挿入、無料の在庫追加、見学Fixtureは使っていません。
 
 | 確認項目 | 結果 |
 |---|---|
-| 自然来客による宿泊売上 | 320G |
-| 受付売上 | 6,020G |
-| 翌06:00の給与 | 120G |
+| 自然来客による宿泊売上 | 240G |
+| 受付売上 | 0G |
+| 00:00の給与 | 120G |
 | 未払給与 | 0G |
-| 全体の営業利益 | 6,040G |
+| 全体の営業利益 | -60G |
 | 帳簿照合 | 一致 |
 | 専用テスト保存からの復元 | 決算値・配属・開業達成を復元 |
 
-受付売上が大きく、現在の数値は製品版の黒字基準や推奨バランスではありません。価格、受付の会計上の役割、宿泊料金の決済・記帳タイミングは仕様との差を調整する必要があります。建築出金は資金増減として表示し、営業利益から分けています。また、06:00の給与支払は新営業日の現金出金に、前営業日の給与費用は確定決算に表示されます。
+2026-09-29の描画付き受入結果です。契約金180Gと給与120Gを差し引いた営業利益は-60G。建築出金は資金増減として表示し、営業利益から分けています。これは固定シナリオの検証値であり、推奨バランスではありません。日次決算・給与計上は00:00です。
 
 `make capture-opening` の出力は `artifacts/first-operating-day/opening.png`、`staffed.png`、`first-close.png` です。開始画面、配属後、翌朝の帳簿を比較できます。
 
@@ -146,7 +146,7 @@ Windows書き出しコマンドの存在はWindows実機合格を意味しませ
 
 `make preview-business` で、通常予算から建てた供給可能な宿を開く。Spaceで再開し、左「営業」から食堂の料金を変える。値上げ前に受付済みの客は元の見積額を払い、新しく検討する客には新料金が反映される。休業すると新規受付が止まり、待機客は別の施設を探す。すでに利用中の客はサービスを完了する。給与は休業中も発生する。
 
-商品で仕入れ・厨房・配送、帳簿で翌06:00の給与と施設別利益を確認する。この試遊は保存なし。新設の標準料金は食堂25G・客室120G・受付無料。旧保存の既存施設は保存された基準料金を引き継ぐ。検証結果は [営業設定QA](qa/P1_BUSINESS_MANAGEMENT.md)。
+商品で仕入れ・厨房・配送、帳簿で00:00の給与と施設別利益を確認する。この試遊は保存なし。新設の標準料金は食堂25G・客室120G・受付無料。旧保存の既存施設は保存された基準料金を引き継ぐ。検証結果は [営業設定QA](qa/P1_BUSINESS_MANAGEMENT.md)。
 
 ## 昇降機と通勤の試遊
 
@@ -162,3 +162,10 @@ Windows書き出しコマンドの存在はWindows実機合格を意味しませ
 完成した昇降機をクリックすると、かごの現在階、人数、待機人数、運行の停止／再開が表示されます。最近の乗車記録の平均待ちと95%の待ち時間、現在の最長待ちも確認できます。平均・95%は保持中の乗車サンプルなので、詳しい集計範囲は表示のツールチップを確認してください。
 
 以前のセーブの上下通路は、読み込むと「既設の階段」として同じ移動時間・利用権限で使えます。小さな階段マークをクリックして接続階を確認できます。その足場を撤去した後に新しい普通の通路を置いても階段は戻らないため、必要なら階段施設を建設します。
+
+
+## 非番の休息と救護
+
+非番の体力回復には、稼働中の裏層の待機室と到達経路が必要です。従業員は実際に移動してから休憩します。体力0の従業員には、医務室と医療職テッサを用意してください。患者と救護者は業務用EVの二人分の席を使用し、同じ便で乗降します。
+
+[労務・同伴救護の検証](traceability/original/LABOR_COMPLETION_2026-09-29.md)

docs/SYSTEM_PERFORMANCE_2026-09-27.md

@@ -0,0 +1,50 @@
+# システム処理の精査と軽量化（2026-09-27）
+
+対象は通常制作先 `/Users/korizatou114/Projects/とりにく工房ゲーム制作部`。既存のドット人物アニメーション変更を保持した。
+
+## 精査結果と変更
+
+|対象|確認した処理|対応|
+|---|---|---|
+|PathService._run_a_star|最小コスト候補を毎回全件走査。昇降機等の接続がある場合はヒューリスティック0となり、広い候補集合を繰り返し走査する|問い合わせ内だけの最小ヒープへ変更。同コスト時のx/y/層の順序、より良い親による再探索、動的混雑コスト、アクセス権、通行停止を維持。古い候補は取り出し時に棄却|
+|WorldPreview._service|セルの位置計算からRuntimeの全プロパティ一覧を何度も生成・走査|1回の描画内で取得済みサービスを再利用|
+|WorldPreview._world_bounds / _cell_dimensions / get_map_rect|同一フレームの全セルで同じ境界・拡大率・矩形を再計算|描画開始で空にしたキャッシュを共有し、描画終了で破棄。カメラ操作・保存復元・Runtime再設定を跨いで保持しない|
+|Runtime._publish_snapshot / create_snapshot|毎分の各システム状態と履歴の複製・digest生成|保存整合性・イベント配信・決定性に関わるため頻度を変えない。既存digest性能テストを確認対象にした|
+|FacilityService.advance_one_minute|施設状態評価、稼働中サービスの更新・完了・補充|完了コールバック中の変更検査と処理順を維持。今回は業務更新の省略を行わない|
+|Runtime._advance_runtime_path_traffic|客・職員の決定的順序での移動、昇降機待ち|順序を維持。内部で利用する経路探索の改善を適用|
+
+ヒープの領域は問い合わせ終了で解放される。描画キャッシュは次フレームまで残さない。セーブ形式・ゲーム内時間の進み方・料金・キャラクターの位置は変更していない。
+
+## 計測方法
+
+同じプロセス内で変更前の線形探索と変更後を比較。1,200セル、固定シードの120経路、通行停止・動的コスト・層間接続・アクセス拒否を含む。経路配列、コスト、到達不能理由、最終スナップショットが一致することを検証した。旧アルゴリズムはテスト用fixtureに限定して保持。
+
+描画は1200×700の実SubViewportを使用。初期世界、停止中、描画命令発行のCPU時間を35フレーム測定し、先頭5フレームを除外。同じ画像になることをピクセル比較した。GPU時間・画面全体のFPS・長時間運営の総所要時間の測定ではない。
+
+追加試験 `tests/performance/test_system_optimization.gd` は282項目。カメラ0.5/1/2/4倍で座標の一致も比較する。`make test-perf` に組み込んだ。時間の絶対値をテストの成否条件にせず、機器負荷による不安定な失敗を避ける。
+
+## 既存の失敗
+
+`tests/ui/test_staff_management.gd` の職員配置ガイドに関する4項目が失敗。軽量化前のPathServiceとWorldPreviewを戻した独立コピー `/tmp/thetree-performance-baseline` でも同じ4項目が失敗することを確認した。これを軽量化の成功に含めず、既存テストの失敗として別件に残す。
+
+計測・検証ログは `artifacts/performance-2026-09-27/`。新アプリは `build/macos/TheTree-Optimized-2026-09-27.app`。旧版アプリは上書きせず保持する。
+
+## 計測結果
+
+|対象|変更前|変更後|条件|
+|---|---:|---:|---|
+|経路120件・3回の中央値|1,417 ms|908 ms|約36%短縮。3回の比率は0.638〜0.650|
+|描画CPUの中央値|74.251 ms|1.272 ms|初期世界30フレーム。画像は完全一致|
+|描画CPUのp95|77.452 ms|1.290 ms|GPU・全体FPSを除く|
+
+絶対時間は開発マシンの負荷に左右される。ゲーム全体が同じ割合で速くなったことを示す数値ではない。
+
+`make check`、macOS書き出し、配布PCKの初回建設13項目を通過。起動コマンドは新しい軽量化版アプリへ更新済み。
+
+## 最終検証結果
+
+経路・ワールド、職員・客、保存、運営、UI、初日運営、digest・性能試験を実行。重複した比較ベンチマーク3回と配布PCK試験を除き、集計は3,651チェック、うち3,647成功・既存の4失敗。失敗は上記の職員配置ガイドに限定。追加282項目はこの集計に含む。詳細は `artifacts/performance-2026-09-27/regression-results.json`。`make test` 全体の実行ではない。
+
+## 後続修正
+
+上記の既存4失敗は、階段必須仕様に対して試験用建物が上下を通路だけで接続していたことが原因だった。試験用建物に実階段を配置し、未接続時の負例も追加して修正済み。後続の全79エントリーポイント・6,850チェックはすべて成功。詳細は [全件修正・通しデバッグ](DEBUG_COMPLETION_2026-09-27.md) を参照。上記の3,647成功・4失敗は修正前の検証履歴として残す。

docs/THE_TOWER_2_COMPLETION_2026-09-29.md

@@ -0,0 +1,62 @@
+# The Tower 2を参考にした表示改善：実装と検証
+
+2026-09-29。対象は参照調査で整理したT2-V01〜V05。制作・書き出しは `/Users/korizatou114/Projects/とりにく工房ゲーム制作部` で実施した。原本全体の完成とは区別し、原本の未実装項目は [実装対応表](traceability/original/IMPLEMENTATION_STATUS.md) に残す。
+
+## 変更した動作
+
+| ID | 実装結果 | 根拠 |
+|---|---|---|
+| T2-V01 | 未稼働は暗い内装と閉鎖線、破壊・摘発後の休止は遮断線と文字、稼働は利用人数と照明で表示。実サービスの顧客IDを集計する | `room_presentation.gd`、状態別の実描画、94項目の表示回帰 |
+| T2-V02 | 客室・飲食施設の家具と利用位置を共通化。実利用者を安定したID順で置き、描画枠を循環させない。待機列は歩行可能な隣接通路へ配置し、隣接する列同士も同じ場所を使わない。収まらない人数は「他N人」で示す | 狭い部屋・6人・9人の列・複数入口の共有通路の回帰。従業員は実際に現地にいる時のみ作業台へ表示 |
+| T2-V03 | 新規開業は入口付近を200%で表示。「営業階」で建設済み施設へ合わせ、Homeで全体へ戻せる。画面移動ボタン・左ドラッグを維持 | 通常予算の開業53項目、Pixel243項目、Dashboard127項目。拡大と座標命中、解像度変更、各操作モードを確認 |
+| T2-V04 | 実際の待機者は乗り場外、乗車中はかご内だけへ描画。実乗客数・定員・満員・停止を表示し、待機人数と分離 | 実ElevatorServiceへ9件を要求し、4人乗車・5人待機の描画を確認。輸送と保存の既存回帰も実行 |
+| T2-V05 | 停止・速度・ズーム・表裏切替・保存復元を回帰。手動読込では表示用の移動履歴を破棄して復元状態から再描画。同一状態の描画時間を比較 | 下記の全体試験・実描画・測定・配布物確認 |
+
+利用人数には `customer_capacity` を使い、保管量・生産量の `capacity` や待機人数と混同しない。描画は料金や稼働条件を変更せず、休止の自動解除も追加しない。原作ゲームの画像・実行ファイルは配布物に含めず、独自人物と既存Kenney素材を使う。
+
+## 検証結果
+
+全83本の試験は、修正後の再試験を含めて **83本PASS・未解決の失敗0**。最終集計は [verification-summary.json](../artifacts/tower2-completion-2026-09-28/verification-summary.json) に保存した。初回は82本PASS・供給シナリオ1本に修正前の列配置の型エラーを記録。最終コードで当該シナリオを再実行し、49項目・エラー0・終了コード0を確認した。初回ログは削除せず、再試験への対応を最終集計に記録している。
+
+- 3営業日の通常供給シナリオ: **49項目PASS**。自然来客の食堂売上3,000G、原料配送30便・料理配送80便、現金2,855G。各日の給与未払0・帳簿照合一致、配送途中のディスクSaveと最終状態の復元を確認。
+- 新しい室内・列・実乗車・復元・カメラ回帰: **94項目PASS**。
+- 通常初期予算から建設・雇用・営業・決算・翌朝までの実描画付き受入: **53項目PASS**。
+- `make check` と `git diff --check`。エディター読み込みと通常起動を確認。
+- macOS / Windowsの出力PCKをソースフォルダーに依存しない別ディレクトリで検証: **各13項目PASS**。全18施設の読込、受付選択、実建設、500G支出、完工、次の案内を確認。
+- macOS配布実行ファイルを実描画で起動して正常終了。Windows向けEXE/PCKは書き出し済みだが、今回のWindows実機起動・入力・FPS測定は未実施。
+
+### 描画時間
+
+Apple M4 / Godot 4.7.2 / Compatibility / 1440×810 / 200%表示。同じ一時停止中の状態を、変更前と変更後で各80フレーム描画し、先頭10を除く70点を比較。前後のSimulationDigest一致も確認した。
+
+| 表示人数 | 変更前 中央値 / P95 | 変更後 中央値 / P95 |
+|---|---|---|
+| 6人 | 1.750 / 1.915 ms | 1.928 / 2.041 ms |
+| 200人 | 4.390 / 4.595 ms | 4.431 / 4.550 ms |
+
+200人の中央値増加は約0.9%。施設の状態と列情報を一描画内で共有し、輸送レポートも一度だけ取得する。これは `_draw` のCPU処理時間であり、GPUを含む全フレーム時間・Windows性能・長時間AI負荷の達成値ではない。200人は計測用に作成した静止した実GuestRuntimeであり、200人が自律営業した記録ではない。同時に他の回帰試験も動いていたため微小差を性能改善とは断定しない。
+
+## 実画面と記録
+
+- [稼働中](../artifacts/tower2-completion-2026-09-28/operating.png)
+- [未稼働](../artifacts/tower2-completion-2026-09-28/inactive.png)
+- [摘発後の休止](../artifacts/tower2-completion-2026-09-28/suspended.png)
+- [裏層](../artifacts/tower2-completion-2026-09-28/back.png)
+- [乗り場の待機列](../artifacts/tower2-completion-2026-09-28/lift-queue.png)
+- [4人乗車・5人待機](../artifacts/tower2-completion-2026-09-28/lift-full.png)
+- [通常開業の翌朝](../artifacts/tower2-completion-2026-09-28/opening-images/second-morning.png)
+- [描画測定JSON](../artifacts/tower2-completion-2026-09-28/draw-benchmark.json)
+
+状態比較画像は条件を固定した描画Fixture。昇降機画像では実Runtimeの有料建設後に検証用9人を生成し、魔力供給をFixtureから有効にして実輸送要求を発行した。通常経営での自然来客・魔力供給の受入とは区別する。通常開業53項目と供給の通し試験は別の実シナリオで確認する。
+
+## 配布ファイル
+
+- macOS: `build/macos/TheTree-Tower2-2026-09-29.app`
+- 起動用: `TheTree-ドット版を起動.command`（ローカルとDrive側の既存起動リンクを更新）
+- Windows: `build/TheTree-Windows-Tower2-2026-09-29.zip`。展開後 `build/windows-tower2-2026-09-29/TheTree.exe` を起動し、同梱PCKを同じフォルダーに置く。
+
+以前のビルドは保存したまま。証跡・ハッシュは上記artifactsフォルダーに保存する。
+
+## 残る範囲
+
+今回のT2表示改善は、原本の全施設・経済・人物物語・天候・全ランクの統合実装や、Windows基準機での長時間実測を完了したという意味ではない。狭い室内や長い列では全員を重ねて描かず人数表示にまとめる。施設ラベルは遠景で省略されるため、詳細確認は「営業階」または選択・拡大で行う。

docs/THE_TOWER_2_REFERENCE_2026-09-28.md

@@ -0,0 +1,72 @@
+# The Tower 2：提供ファイルの確認とThe Treeへの適用
+
+2026-09-29追記: T2-V01〜V05の実装・最新の検証範囲は [表示改善の完了記録](THE_TOWER_2_COMPLETION_2026-09-29.md) を参照。以下は2026-09-28時点の調査・受領記録として保存する。
+
+確認日: 2026-09-28。ユーザー提供のゲームファイルを、断面表示・人物表現・施設状態の見せ方の参考として調査した。ゲームの仕様は引き続き [基本仕様書原本](traceability/original/BASELINE.txt) とユーザーの施設パラメータ訂正を優先する。本書の改善案は実装完了を意味しない。
+
+追記: Windows側で作成された実機記録を受領し、[操作・動作の確認結果とThe Treeへの反映](THE_TOWER_2_WINDOWS_REVIEW_2026-09-28.md) を追加した。以下はそれ以前の静的調査記録。T2-V03の操作モード明示部分として「画面移動」ボタンと左ドラッグを実装済み。その他の残件は継続する。
+
+## 取得・調査範囲
+
+- [提供元のGoogle Driveファイル](https://drive.google.com/file/d/1ea5OeYIuvThC5YtTutjdbGlrZYF03QF4/view)
+- ファイル名: `The Tower 2.zip`、240,984,598 bytes、530エントリ。
+- SHA-256: `cf111aff88d59de6854f4bfbddff2af62b5345f3d4c67bf4c3f52a111e3fdec1`
+- 保存先: `/Users/korizatou114/Projects/reference-materials/the-tower-2/`。ZIP・抽出画像はゲームの配布用アセットに追加していない。
+- 主な内容: Windows実行ファイル1、DLL4、施設等の `.t2p` 338、MOV50、AVI10。一般的なPDF・HTML・TXT形式の説明書は一覧に見当たらない。
+- 選定した11ファイルから509リソースを列挙し、134ビットマップをPNGに変換。変換エラー0。施設・人物・昇降機・UIの主要画像を目視確認した。全338プラグインの精査ではない。
+- Windows実行環境が現在のMacにないため、ゲーム本体は未実行。フレーム順序、切替条件、歩行速度、経路選択、運行ロジック、実画面の配置は未検証。
+- `S02.avi` は240×180・15fps・28.8秒。抽出した画面は人物中心の映像で、ビル経営の操作画面ではない。ゲームプレイ映像として扱わない。
+
+再確認用の外部資料:
+
+- [ZIP全体の一覧](/Users/korizatou114/Projects/reference-materials/the-tower-2/archive-inventory.json)
+- [リソース一覧と画像寸法](/Users/korizatou114/Projects/reference-materials/the-tower-2/resource-inventory.json)
+- [代表画像の拡大比較](/Users/korizatou114/Projects/reference-materials/the-tower-2/inspect/selected-details.png)
+- [読み取り・画像変換スクリプト](/Users/korizatou114/Projects/reference-materials/the-tower-2/tools/inspect_resources.py)
+
+## 素材から直接確認したこと
+
+以下のIDはWindowsリソースの「種別/番号/言語」。画像全体の寸法であり、ゲーム内の表示倍率ではない。
+
+| 根拠 | 確認できた表現 | The Treeで参考にする点 |
+|---|---|---|
+| `Cafe.t2p`、`2/1000/1041`、96×108 | カウンター・椅子・棚のある内装と、人物の少ない／多い内装の差分が縦に並ぶ | 飲食施設は実際の利用人数を家具周辺に配置して見せる。看板だけで種類を区別しない |
+| `Office.t2p`、`2/1000/1041`、72×336 | 机・椅子・端末など、複数の内装と明暗差分 | 施設の用途が小さな断面でも読める家具配置。明暗差分の実際の切替条件は未確認 |
+| `Single.t2p`、`2/1000/1041`、32×240 | ベッド主体の小部屋に、明暗・寝具等の差分 | 客室の利用・睡眠・清掃状態を部屋内で伝える。各差分が何の状態に対応するかは未確定 |
+| `StdElev.t2p`、`2/200/1041`、28×160 | 空のかご、人物1人・複数人が入ったかご、停止を想起させる記号 | 乗車密度を可視化する。かごの人物は実乗客に対応させる |
+| `Sinjyuku.t2p`、`2/300/1041`、`2/350/1041`、各16×216 | 横向き人物の複数の手足の姿勢。ほかにも多数の人物画像がある | 小さい人物でも姿勢と向きで行動を伝える。画像の並びだけから再生順・fpsは決めない |
+| `T2.exe`、文字列32771〜32773 | 100%・50%・25%の表示倍率のラベル | 近景の営みと遠景の全体把握を両立する。The Treeの倍率を同じ値にする必然性はない |
+
+## 現在のThe Treeとの比較
+
+比較には、現在のソースと [2026-09-27の実描画キャプチャ](../artifacts/midnight-2026-09-27/opening-images/first-close.png) を用いた。キャプチャは今回の変更後の画面ではない。
+
+すでにあるもの:
+
+- `pixel_people.gd`: 横向き16×18の独自人物。歩行・待機・食事・清掃・作業・運搬・睡眠・気絶の姿勢。
+- `world_preview.gd`: 実位置に基づく移動補間、サービス利用中の室内描画、かごと乗客・扉の描画、待機人数表示。これらを未実装として作り直さない。
+- `pixel_tower_art.gd`: 施設別の家具、世界樹の断面、Kenney素材。世界樹の色調と表裏層は本作固有の表現として維持する。
+
+改善が必要な箇所:
+
+- 部屋の描画に利用人数や稼働状態が渡っておらず、稼働は主に小さい色ランプで示す。家具・照明・人の組み合わせから状態を読める余地がある。
+- サービス利用位置は共通の4枠循環。狭い部屋や5人以上の利用で同じ位置に重なり得る。施設ごとの利用場所・実定員に合わせる必要がある。
+- 待機人数のバッジと同一セルの人物オフセットはあるが、入口・乗り場に沿った整列を優先した表現ではない。
+- かごの人物描画には表示人数の上限がある。人数が上限を超えた際にも、密度と実人数を読み取れるようにする。
+- 開業時のキャプチャでは稼働している部屋が小さく、未開発の幹と管理パネルが大きい。初期カメラと詳細パネルを改善し、運営中の断面を眺めやすくする。
+
+## 次の実装・受入項目
+
+これは提供素材の分析から定めた改善順序であり、原作ゲーム内部の仕様を再現したものではない。
+
+| ID | 優先度 | 作業 | 完了を判定する画面・動作 |
+|---|---|---|---|
+| T2-V01 | 高 | 客室・食堂・受付の状態を内装、照明、家具と実利用者で表現 | 同じ施設で未稼働／稼働／破壊・摘発後の休止を識別。実利用0人／少数／満員の差を確認。休止から勝手に復帰させない |
+| T2-V02 | 高 | 施設別の利用位置と入口付近の待機列 | 小部屋・5人以上・複数入口・同じ階の隣接施設で人物が重ならず、待機者と利用者が区別できる |
+| T2-V03 | 高 | 初期カメラと観察時のUI占有面積を調整 | 通常初期予算から作る宿で、歩行・着席・就寝を拡大操作なしでも追える。管理パネル開閉・解像度変更で配置操作がずれない |
+| T2-V04 | 中 | 昇降機の乗り場待機と乗車密度を改善 | 待機→乗車→移動→降車を追え、乗車中の人物が廊下に重複しない。満員・停止も判別できる |
+| T2-V05 | 共通 | 人数・画面状態別の描画検証と性能測定 | 停止／速度変更／ズーム／表裏切替／保存復元で表示と実状態が一致。描画のための架空客や経済変更を追加せず、混雑時のフレーム時間を同条件で比較 |
+
+実装時は独自のドット表現と既存Kenney素材を使う。施設の「顧客同時利用最大人数」は保管・生産等にも使う `capacity` と区別し、待機列の人数とも混同しない。原本・ユーザー指定で未設定の料金加算率や休止解除条件を、参考ゲームから推定して確定しない。
+
+今回の変更は参考資料の取得・分析と制作資料への反映まで。ゲームコード、保存形式、配布アプリは変更していない。したがってゲームの全件PASSや通しデバッグ完了を新たに宣言するものではない。

docs/THE_TOWER_2_WINDOWS_REVIEW_2026-09-28.md

@@ -0,0 +1,47 @@
+# The Tower II Windows実機記録の受領と反映
+
+2026-09-29追記: T2-V01〜V05の実装・最新の検証範囲は [表示改善の完了記録](THE_TOWER_2_COMPLETION_2026-09-29.md) を参照。以下は2026-09-28時点の調査・受領記録として保存する。
+
+2026-09-28。ユーザーがWindows側で作成した実機確認資料を受領し、レポート全文・時刻ログ・主要スクリーンショットを確認した。本チャットでWindowsゲームを再操作した結果ではなく、提供された検証証拠のレビューである。
+
+## 受領物
+
+- [提供ZIP](https://drive.google.com/file/d/1ds7StSFXKCgILOHqt05RCO3BYSEn6e5J/view): `The-Tower-II-reference-record.zip`、10,674,377 bytes。
+- SHA-256: `4d0fd7f4c1e904b41444f0d6b7bf2b941049c02b915d3ab1efaf181f0ec632e1`。
+- スクリーンショット78枚、Markdown/HTMLレポート、時刻ログ、新規セーブ334,412 bytes。
+- セーブSHA-256は添付レポートの値と一致: `5a1f072eeaf8dcee364fa403235f45646ecb0bdef33c3fb9b3e3665f511ffca8`。
+- [受領レポート全文](/Users/korizatou114/Projects/reference-materials/the-tower-2/windows-reference-record/tower2-evidence/report.md)。元のZIP・画像・セーブは外部参考資料フォルダに保存し、配布ゲームへ混入させていない。
+
+## 確認された範囲と限界
+
+新宿西口副都心、ロビー＋オフィス7区画＋昇降機1基で、建設・手のひらドラッグ・倍率変更・一時停止と再開・人物の列・かご移動・別名保存後のアプリ再起動と読込が記録されている。
+
+| 記録 | 判断 |
+|---|---|
+| ロビーの階制限、下階からはみ出す建設の拒否、工事から内装への変化 | 配置制約と施工状態を操作直後に伝えることが重要。原作の制約や金額をThe Treeに追加する根拠にはしない |
+| 手のひらで約162pxのドラッグ、同程度の画面移動 | 移動ツールを明示し、左ボタンだけで断面を探索できる操作を採用する |
+| 倍率ツールの右クリックで寸法約半分、左クリックで元へ戻る | 概観と近景の行き来ができる。既存The Treeのカーソル基準ホイールズームを維持する |
+| 低速で20.263実秒に40ゲーム分 | 約1.97ゲーム分/秒は当該端末・区間のみの観測値。全速度や歩行フレームの確定値として使わない |
+| 1階の列、かご内人物、4階へのかご移動、後の列解消 | 移動需要を断面の人物で見せる。個体追跡、定員、乗降順序、満員の積み残しは未確認 |
+| 11:42に停止保存し、再起動後最初の画像が11:44・再生中。資金79,745万円、人口42人を復元 | 配置・主要数値の復元の証拠。人物ごとの状態・乱数の厳密復元や停止状態の維持を検証済みとはしない |
+
+画像 `21-boarding-0.png` の乗り場の列と上階のかご、`23-zoom-out-0.png` の広域表示、`28-reopened-2.png` の時刻・資金・人口をこのチャットでも目視確認した。レポートと画像の間の動作を新たな実測として補わない。
+
+## 今回実装した操作改善
+
+The Treeの下部ツールバーに「画面移動」ボタンを追加した。有効中は左ドラッグで断面を移動し、施設選択・建設クリックを送らない。もう一度押すかEscで通常操作に戻る。建設・掘削との切り替えは排他的とし、既存の中ボタンドラッグ、カーソル基準ズーム、Homeの全体表示も維持する。
+
+ドラッグ中にアプリのフォーカスを失った場合や、画面外でボタンを離してから戻った場合は移動を解除する。カメラ操作でシミュレーション時間やRuntime状態は変えない。
+
+変更先: `scenes/main/main.gd`、`scenes/main/world_preview.gd`。画像素材の追加やゲームルールの変更はない。
+
+## 検証
+
+- [カメラ・描画・実施設選択の回帰](../artifacts/tower2-reference-2026-09-28/pixel.log): 243項目PASS。左ドラッグ、誤選択抑止、画面外での解除、フォーカス喪失、操作後のRuntimeダイジェスト一致を含む。
+- [ダッシュボード回帰](../artifacts/tower2-reference-2026-09-28/dashboard.log): 127項目PASS。ボタン・建設・掘削・Escの切り替え、1280×720〜3840×2160の既存レイアウトチェックを含む。
+- [実描画](../artifacts/tower2-reference-2026-09-28/preview.png): 1440×810で下部ボタンと断面の表示を目視確認。時刻の異なる2枚を生成。
+- ゲーム全体の全試験は今回再実行していない。配布アプリも今回更新していないため、変更確認にはローカル制作フォルダから `make run` を使う。修正後のWindows実機操作は未実施。
+
+## 残る改善
+
+[T2-V01〜V05](THE_TOWER_2_REFERENCE_2026-09-28.md) のうち、今回完了したのはT2-V03の操作モード明示部分。部屋の状態表現、施設別利用位置と待機列、初期カメラ、昇降機の混雑表現、混雑時の性能比較は未完了。提供された原作の実機検証完了と、The Treeの改善実装完了を区別する。

docs/UI_OPERATION_SPECIFICATION.md

@@ -12,7 +12,7 @@
 
 | 領域 | 現在の情報・操作 | 表示状態 |
 |---|---|---|
-| 上部 | 営業日、時刻、時間帯、来客、宿泊予定、資金、Mana、資材、Faith、Heat、停止、x1／x2／x4 | 常設の小型HUD |
+| 上部 | 営業日、時刻、時間帯、来客、宿泊予定、資金、Mana、資材、Faith、Heat、停止、x1／x2／x3 | 常設の小型HUD |
 | 左側 | 従業員、施設、商品、探索、投資、帳簿の入口 | 常設の細いカテゴリ列。入口があるだけの準備中項目を含む |
 | 中央 | 世界樹の断面、施設の室内、客、従業員、工事、待機、混雑、6段階の開業手引き | 手引きは左上の見出しで折り畳める。断面を広く使用 |
 | 右側 | 運営概要、施設状態、雇用候補／雇用済み人物の配属、帳簿、要対応イベント | `I`、カテゴリ、施設選択で必要な内容を開く重ね表示。初期は閉じる |
@@ -79,15 +79,15 @@
 
 商品、探索、投資の準備中案内を完成した経営機能として説明しない。
 
-## 7. 時間進行と06:00決算
+## 7. 時間進行と00:00決算
 
 時間操作は上部の時計の近くへ置き、停止・通常・2倍・4倍を一操作で切り替える。重要な選択肢では右パネルを開き、選択と解決後の停止解除を接続する。
 
-Runtimeでは00:00の暦日更新と、06:00の前営業日締め・朝運用を別の境界として扱う。帳簿は当営業日の現金入出金・うち建築・給与支払と、選んだ確定営業日の売上・運営費・給与・その他費用・利益・前日差・未払・照合・施設別損益を表示する。建築による資金減少を営業赤字と混同しない。06:00の給与現金支払が新営業日の出金、費用が前営業日の決算に属する点を案内する。
+Runtimeでは00:00に前営業日を締め、給与を計上する。06:00の朝運用では決算を重複させない。帳簿は当営業日の現金入出金・うち建築・給与支払と、選んだ確定営業日の売上・運営費・給与・その他費用・利益・前日差・未払・照合・施設別損益を表示する。建築による資金減少を営業赤字と混同しない。00:00の給与現金支払が新営業日の出金、費用が前営業日の決算に属する点を案内する。
 
-開業の手引きは受付→客室→接続→配属→初宿泊売上→翌朝決算の6段階を実状態から示す。達成後は売上と決算の履歴を先に評価し、夜間の勤務外や配属変更だけで達成が消えないようにする。Save復元では新しいServiceから読み直す。手引きは状態を書き換えず、ボタンから通常の建築・従業員・時間・帳簿操作へ進める。
+開業の手引きは受付→客室→接続→配属→初宿泊売上→00:00決算の6段階を実状態から示す。達成後は売上と決算の履歴を先に評価し、夜間の勤務外や配属変更だけで達成が消えないようにする。Save復元では新しいServiceから読み直す。手引きは状態を書き換えず、ボタンから通常の建築・従業員・時間・帳簿操作へ進める。
 
-通常初期予算での宿泊売上320G、翌06:00の給与120G・未払0・照合一致・専用保存復元を単日確認した。受付売上6,020Gと全利益6,040Gの現結果は調整対象で、価格や宿泊の決済時点を今回のUI追加で改定していない。厨房・補給・実配送を含む3営業日運営、初見試遊、製品バランスは残る。
+2026-09-29の描画付き開業受入では、通常初期予算から宿泊売上240G・受付売上0G・給与120G・営業利益-60G・未払0・照合一致と翌朝の保存再開を確認した。製品バランスと初見の人手試遊は別の判定とする。
 
 帳簿は表示中だけ更新し、日付のPopup操作中は選択肢を再構築しない。画面を閉じれば断面の観察へ戻る。
 
@@ -126,4 +126,9 @@ Runtimeでは00:00の暦日更新と、06:00の前営業日締め・朝運用を
 
 左の「営業」は商品・勤務・帳簿と排他の管理パネル。施設を選び、価格5段階と営業状態を確定する。見積額、満足補正、受付済み価格の維持、休業時の待機／利用中の挙動、給与が続くことを表示する。受付や倉庫は開閉のみ。施設ごとの未確定入力は切替で保持する。Escで閉じる。
 
-施設別の当日記帳は確定給与配賦を含む営業利益と区別し、06:00の帳簿へ誘導する。1280×720では既存の縦スクロールを使う。試遊は `make preview-business`、通常データの保存を更新せずSpaceで時間を再開できる。
+施設別の当日記帳は確定給与配賦を含む営業利益と区別し、00:00の帳簿へ誘導する。1280×720では既存の縦スクロールを使う。試遊は `make preview-business`、通常データの保存を更新せずSpaceで時間を再開できる。
+
+
+## 従業員の休息・救護表示（2026-09-29）
+
+体力と休息先への移動・到着、気絶後の救護待ち・迎え・搬送・治療を従業員パネルに表示する。待機室内の人物・休憩人数、医務室の患者、救護EVの2席は実際のRuntime状態から描画する。

docs/plans/original-completion-2026-09-29/FIRST_INCREMENT.md

@@ -0,0 +1,34 @@
+# 初回の実装単位：維持費を通常営業へ接続する
+
+計画の最初の実装単位。2026-09-29に着手。進捗・試験証拠・残件は [実装記録](execution/UPKEEP_IMPLEMENTATION.md) を参照。
+
+## 着手条件
+
+P00–P04の必要部分を完了し、費用計上時点・未払い・閉店中/休止中の扱いをD04/D05で整理する。原本が未指定の金額を勝手に本番値として確定しない。既存の00:00決算・3連続赤字・保存復元を保護する。
+
+## 5つの小さな変更
+
+| 順 | 変更 | 主な対象 | 受入 |
+|---|---|---|---|
+| E01 | 運用費の仕様と例 | 原子要件台帳、未設定値台帳 | 営業/閉店/休止/日跨ぎ別の期待計上を具体的な台帳例にする |
+| E02 | 版付きの課金状態 | 保存/移行サービス、FacilityInstance周辺 | 旧セーブ読込時に過去費用を二重徴収しない。途中保存から再開可能 |
+| E03 | 一度だけ計上する処理 | 新規の運用費サービス、EconomyService | 同一営業日/施設/費目の再送で重複しない。資金不足時の債務処理が決まった規約通り |
+| E04 | Runtimeと00:00決算へ接続 | SimulationRuntime、OperationsCoordinator | 通常Tickの支出が施設別帳簿・現金・損益と一致。3連続赤字の既存判定を維持 |
+| E05 | UIと縦断検証 | OperatingLedgerPanel、BusinessManagementPanel | 通常建設→営業→閉店/休止→00:00→保存→再起動を操作し内訳一致 |
+
+各変更で影響する既存試験を実行し、E05で全体回帰を実行する。いきなり借金・税・天候まで同時に入れず、維持費の一連の経路を完成させてからP05の次の費目へ進む。
+
+## 具体的な試験ケース
+
+- 稼働施設1件と複数件で費目・施設・総額が一致する。
+- 建設中/閉店/休止/破壊/撤去の日跨ぎを仕様通り処理する。
+- 23:59保存→00:00→ロード再開で計上結果が一致する。
+- 課金直前/直後に保存し、再送でも二重課金しない。
+- 資金不足・部分支払い・未払いの扱いと翌日の処理が一致する。
+- 既存セーブ移行で過去確定日の収支を書き換えない。
+- 追加費用による黒字→赤字、連続2回→3回の終了を検証する。
+- 画面上の費目合計、台帳総額、施設別損益の照合差額が0。
+
+## この単位の完了証拠
+
+要件ID、変更ソース、採用した費用規約、試験ログ、代表セーブ、実画面、ソースハッシュを同じ検証記録へまとめる。「maintenance_goldを読むコードを追加した」だけで完了にしない。

docs/plans/original-completion-2026-09-29/IMPLEMENTATION_PLAN.md

@@ -0,0 +1,462 @@
+# 原本準拠・全実装に向けた作業計画 v2
+
+作成: 2026-09-29。状態: 自己レビュー反映済みの計画。実装着手・完了を示すものではない。
+
+## 1. 目標と前提
+
+保存済み原本75要件群（機能・内容71、工程4）と会話で追加された施設主要10項目を、通常プレイ・保存復元・UI・配布版の証拠まで追跡する。原本の最新再取得はP00で行う。今回の計画は2026-09-29監査に基づく。
+
+対象はローカル制作コピー `/Users/korizatou114/Projects/とりにく工房ゲーム制作部`。既存の変更を保全し、Driveコピーを制作対象にすり替えない。The Towerは操作/観察体験の参考であり、提供ゲームの画像・音・プログラムを取り込む前提にはしない。
+
+現状: 検証済み8、一部実装52、実装あり全受入未検証2、該当機能未実装9、工程4。原本30施設は通常登録12・定義のみ3・対応定義なし15。90スイートPASSと全原本実装は別。75群は粒度が異なるため完成率の分母にしない。
+
+本計画は全原本の対応先を落とさず記録するが、露骨な性的場面や性的強要の表現制作は具体化しない。該当内容は未制作のまま台帳で識別し、非露骨なイベント構造・状態・資産管理とは分ける。未制作内容が残る限り原本全実装とは認定しない。
+
+## 2. 完了条件
+
+各原子要件について、(1)原本条件、(2)定義、(3)実行サービス、(4)通常UI入口、(5)保存/移行、(6)境界試験、(7)画面/配布版、(8)証拠が揃うこと。関係しない項目は理由付きN/Aとし、未実装をN/Aにしない。
+
+最終条件は、対応漏れ0・未承認の原本差異0・現仕様で必須の値の未設定0（明示的に未設定の拡張仕様は除く）・未制作必須資産0・重大不具合0・Windows実機の同一ビルド合格。工程4件は機能PASSから除き、現在の工程達成と過去日程の達成を区別する。ユーザーが内容を変更した場合は変更承認を記録し「改訂仕様準拠」と表記する。
+
+## 3. 実装順序と到達点
+
+| 段階 | 作業 | 到達点・次段階への条件 |
+|---|---|---|
+| 0 | P00–P02 | 原本/要件/既存回帰の基準を固定。決定待ちを切り分ける。 |
+| 1 | P03–P04、P22 | 保存契約・更新順・素材仕様が揃い、手戻りを減らす。 |
+| 2 | P05–P07 | 費用・停電・天候が実際の営業へ作用する。 |
+| 3 | P08–P14、P23 | 原本施設の配置と営業、交通、レイヤー画面が通常操作で通る。 |
+| 4 | P15–P19、P24 | 客/職員/人物/関係/イベントの状態と操作がつながる。 |
+| 5 | P20–P21、P25–P26 | 進行・防衛・演出・制作内容を完成へ接続する。 |
+| 6 | P27–P29 | 横断試験→性能/長期プレイ→Windows配布版→最終監査。 |
+
+段階番号は見通しであり、厳密な着手条件は各パッケージの依存関係。P08はP03後、P22はP01後、P23はP08/P22後に先行できる。これは作業順の分離であり、エージェントへの並列委任を自動的に許可するものではない。
+
+主要な長い依存経路は P00→P01/P02→P03→P04→P05/P06→P09→P12/P14→P15→P16→P17→P18→P19→P20→P26→P27→P28→P29。素材制作・仕様回答も同程度に納期へ影響し得る。
+
+## 4. 作業パッケージ
+
+規模は暫定の技術作業人日: S=1–3、M=3–7、L=7–15。1人日は担当者の集中作業量の単位であり、AIの実行時間や日数保証ではない。Lは着手時に縦に完結する変更へ分割する。以下の受入は共通完了条件に追加する。
+
+### P00 原本・作業対象の固定
+
+- 段階: 0 / 規模: S（1–3人日、暫定）
+- 前提: なし
+- 原本: B-1.1, B-14.1, B-14.2, B-14.3, B-14.4
+- 実装: 指定Drive原本を再照合し差分を保存。ローカル制作コピーの全ソース・現在のセーブ形式・既存成果物を識別する。今回計画の原本は保存版であり最新取得済みとは扱わない。
+- 受入: 原本SHAと変更履歴、制作対象、現在の実装証拠が再現可能。原本更新があれば影響要件を再評価。
+- 決定待ち: なし
+
+### P01 原子要件と受入台帳
+
+- 段階: 0 / 規模: M（3–7人日、暫定）
+- 前提: P00
+- 原本: B-1.1, B-1.2, B-1.3, B-1.4, B-1.5, B-1.6, B-14.1, B-14.2, B-14.3, B-14.4
+- 実装: 75複合要件を単独判定できる条件へ分割。原本の各文、追加10項目、UI入口、Runtime、保存、試験、資産、完了責任を対応付ける。
+- 受入: 全原本文に対応先があり、未設定・未実装・未検証が別状態。派生仕様の独自ルールを確定仕様に昇格させない。
+- 決定待ち: D01, D02, D03, D04, D05, D06, D07, D08, D09, D10
+
+### P02 既存機能の回帰基準
+
+- 段階: 0 / 規模: M（3–7人日、暫定）
+- 前提: P00
+- 原本: B-3.1a, B-3.1b, B-3.3, B-3.4a, B-3.4b, B-4.2, B-4.3c, B-5.4
+- 実装: 時計、停止中建設、最高欲求、混雑、決算、赤字終了、救護/EV同伴/休息の既存証拠を新規開発の基準にする。必要な代表セーブを固定。
+- 受入: 日付・入力・乱数・セーブを固定して再実行できる。既存PASS8群を新仕様導入で失わない。
+- 決定待ち: なし
+
+### P03 保存形式と移行契約
+
+- 段階: 1 / 規模: L（7–15人日、暫定）
+- 前提: P01, P02
+- 原本: B-2.1, B-4.1, B-5.2, B-6.3, B-7.2, B-8.1, B-9.1
+- 実装: 施設、会計、客、職員、関係値、天候の新項目を版管理。原本と異なる関係値は一対一変換を仮定せず旧値を保全。移行は検証成功時のみ確定する。
+- 受入: 旧版/欠損/未知版/破損/途中書込の試験。失敗時に元セーブを変更しない。新しい状態は途中保存から同一結果で再開。
+- 決定待ち: D06, D07
+
+### P04 更新順序・責務の整理
+
+- 段階: 1 / 規模: M（3–7人日、暫定）
+- 前提: P03
+- 原本: B-1.3, B-1.4, B-3.2, B-9.2
+- 実装: 一分更新、00:00決算、時間帯・天候更新、施設稼働判定、客選択の適用順を仕様化。新機能は分離サービスで実装しRuntimeから接続。全体の一括書換えはしない。
+- 受入: 同一Tickでの閉店/停電/退出/課金順が決定的。コマンド再送で二重課金・二重生成しない。
+- 決定待ち: D05
+
+### P05 全収支・維持費・税・借入
+
+- 段階: 2 / 規模: L（7–15人日、暫定）
+- 前提: P04
+- 原本: B-3.4a, B-3.4b, B-9.1, B-9.2, B-9.3
+- 実装: 表/裏収入区分、維持費、返済元本/利息、税、未払いを帳簿に接続。金庫上限・購買・銀行のサービス契約を先に作る。決算損益と現金収支を区別。
+- 受入: 3営業日の費目別総額が台帳・施設別・資金と一致。借入元本を売上にしない。支払い失敗/再送/復元/3赤字を検証。
+- 決定待ち: D04, D05
+
+### P06 マナ枯渇と全館停止
+
+- 段階: 2 / 規模: L（7–15人日、暫定）
+- 前提: P04
+- 原本: B-2.6, B-9.1, B-10.6, B-10.7
+- 実装: 供給/蓄積/消費と世界樹初期源の扱いを整理。全館停止時のサービス、EV、物流、救護、入館と安全な復帰を接続。休止状態は停電復旧で解除しない。
+- 受入: 残量境界、停止中利用者、EV乗車中、搬送中、同日復旧を試験。停止中の売上や生産が無条件に継続しない。
+- 決定待ち: D04, D05
+
+### P07 天候・流行・環境
+
+- 段階: 2 / 規模: L（7–15人日、暫定）
+- 前提: P04
+- 原本: B-2.3, B-2.6, B-3.2, B-3.5, B-4.5, B-11.1
+- 実装: 雨/嵐/マナ霧、流行ニュース、ゾーンの採光/遮音/隠蔽、景観/清潔/騒音を段階導入。係数と乱数系列を保存しHUDと予測へ表示。
+- 受入: 嵐で新規入館0、雨で来客減/滞在延長。天候変化の瞬間と保存再開が一致。環境変更に応じて満足度と対象売上が変わる。
+- 決定待ち: D04, D05
+
+### P08 施設寸法・既存配置の整合
+
+- 段階: 3 / 規模: M（3–7人日、暫定）
+- 前提: P03, P01
+- 原本: B-2.1, B-8.1, B-10.1, B-10.2, B-10.3, B-10.4, B-10.5, B-10.6, B-10.7
+- 実装: 上級客室4×1、宿舎2×1、闇市場4×2へ原本準拠。30施設を正規IDで管理し類似施設を代用扱いしない。旧占有・支持・接続の移行を検証。
+- 受入: 新規建設の寸法/層/地上地下が全30件で一致。旧施設の拡縮で重複・経路断を起こさず、解消不能な移行は元データを保つ。
+- 決定待ち: D06
+
+### P09 施設共通契約と追加10項目
+
+- 段階: 3 / 規模: L（7–15人日、暫定）
+- 前提: P05, P06, P08
+- 原本: B-8.1, B-8.2, B-8.3, B-8.5, B-9.2
+- 実装: 人数専用上限、staff_min/max、3稼働状態、関連施設、サービス属性、価格、施設レベルを統合。全35既存定義を点検し原本30施設の値を台帳化。
+- 受入: 本番UI→コマンド→Runtime→人数/料金→台帳→保存まで接続。不一致属性でも利用可能。待機者と利用者を混同せず、人数超過/停止中課金/勝手な休止復帰を防ぐ。
+- 決定待ち: D01, D02, D03, D04, D05
+
+### P10 宿泊・飲食施設の完成
+
+- 段階: 3 / 規模: L（7–15人日、暫定）
+- 前提: P09
+- 原本: B-8.2, B-10.1, B-10.2
+- 実装: 一般/上級/VIP/ドミトリー、食堂/レストラン/酒場/屋台を建設・厨房・在庫・従業員・客AI・UIへ接続。高層/景観要件と厨房依存を含む。
+- 受入: 各施設を通常パレットから建設して一営業日利用し、必要条件喪失と再開、売上、人数上限、保存を検証。
+- 決定待ち: D04
+
+### P11 衛生・娯楽・礼拝施設
+
+- 段階: 3 / 規模: L（7–15人日、暫定）
+- 前提: P09, P07
+- 原本: B-8.2, B-10.3
+- 実装: 浴場/カジノ/闘技場/礼拝堂の役割、利用、収支、職種、信仰への接続を実装。機能ごとの通常UIを用意。
+- 受入: 4施設が定義だけでなく通常営業できる。礼拝の信仰をランク条件へ接続し、停止・退店・精算を再現。
+- 決定待ち: D04, D05
+
+### P12 バックヤード施設完成
+
+- 段階: 3 / 規模: L（7–15人日、暫定）
+- 前提: P09
+- 原本: B-2.4, B-5.3, B-5.4, B-8.3, B-10.5
+- 実装: 宿舎・清掃員室を追加し厨房/倉庫/待機/警備/医務を統一契約へ移行。リネンシュート・隠し扉の動線も個別に追跡する。
+- 受入: 7施設と追加設備の職員行動、客の侵入禁止、在庫/清掃/休息/救護を通常プレイで検証。重複救護と孤立物資が残らない。
+- 決定待ち: D04, D05
+
+### P13 特殊・地下施設の非描写システム接続
+
+- 段階: 3 / 規模: L（7–15人日、暫定）
+- 前提: P09, P12
+- 原本: B-1.6, B-2.5, B-8.2, B-8.3, B-10.4, B-10.6
+- 実装: 原本にある地下/特殊施設の配置、アクセス制御、役割、会計、イベント状態を接続。覗き部屋は対象施設背面と裏通路寸断、地下牢/マナ炉は明示状態遷移として追跡。表現資産は別工程。
+- 受入: 特殊条件が建設時と運用時の両方で効く。無効配置や失われた対象への操作を拒否。イベント状態を保存でき、実装範囲と未制作内容を分けて報告。
+- 決定待ち: D04, D05, D08
+
+### P14 垂直交通・ワープ完成
+
+- 段階: 3 / 規模: L（7–15人日、暫定）
+- 前提: P06, P09
+- 原本: B-2.4, B-4.3a, B-4.3b, B-4.3c, B-8.4, B-10.7
+- 実装: 客/業務EV、階段にマナワープと費用を追加。待ち時間の経路費用、容量、職員アクセス、停止時退避を統一。魔法砲台はP21で接続。
+- 受入: 全交通を通常建設し経路選択・実移動を検証。待ち時間増で別経路を選択。ワープ中/EV中保存、マナ不足、救護同伴時の人数を検証。
+- 決定待ち: D04, D05
+
+### P15 客の全パラメータ・時間帯AI
+
+- 段階: 4 / 規模: L（7–15人日、暫定）
+- 前提: P07, P10, P11, P14, P13
+- 原本: B-3.2, B-4.1, B-4.2, B-4.4, B-4.5, B-9.4
+- 実装: 戦利品、清潔度と汚染伝播、クラス/種族反応、朝夕の移動目的、依存と信用限度の非描写状態処理を追加。最大欲求選択を維持。
+- 受入: 一般/貴族/聖職者/エルフ/魔族等で期待行動を再現。朝下り/夕上りの目的地分布、清潔伝播、装備処分・破産状態を保存再開まで検証。
+- 決定待ち: D04, D05, D08
+
+### P16 雇用・職種・労務完成
+
+- 段階: 4 / 規模: L（7–15人日、暫定）
+- 前提: P12, P15, P13
+- 原本: B-5.1, B-5.2, B-5.3, B-5.4, B-5.5
+- 実装: 雇用区分別費用、全職種業務、生成時特性、獲得/退職/処分の非描写状態処理を整理。乱数特性は生成時に固定しセーブへ保存。
+- 受入: 求人から配置・業務・休息・精算・退職まで通常UIで通る。費用/忠誠/特性効果の変化が可視化され、ロードで特性が再抽選されない。
+- 決定待ち: D04, D05, D08
+
+### P17 ユニーク7名・固有効果・成長
+
+- 段階: 4 / 規模: L（7–15人日、暫定）
+- 前提: P16, P05, P11
+- 原本: B-1.5, B-6.1, B-6.2, B-6.3, B-6.4, B-6.5
+- 実装: 7ヒロインと指定ライバル、無料/削除禁止、業務EXP/Lv99、固有パッシブを実装。アンリの配置階売上+20%など原本の明示数値を優先。衣装/超過勤務/離脱を状態として接続。
+- 受入: 7名全員で固有効果の適用前後、配置変更/同時配置、99上限、削除禁止を試験。24時間警告から継続/中止ができ、保存復元で効果を重複適用しない。
+- 決定待ち: D04, D07, D08
+
+### P18 関係パラメータ・盾・確定遷移
+
+- 段階: 4 / 規模: L（7–15人日、暫定）
+- 前提: P03, P17
+- 原本: B-7.1, B-7.2, B-7.3
+- 実装: 原本の感情値と盾の非描写シミュレーションを専用モデルに分離。好感度と盾最大、軽減、接触、閾値、ルート固定を接続。既存の汎用関係値を黙って同義変換しない。
+- 受入: 境界値・盾破壊前後・同配置/別配置・一度確定したルートの再読込を試験。操作と表示の値が一致し、旧セーブ移行の意味を説明できる。
+- 決定待ち: D04, D07, D08
+
+### P19 イベント・決闘・行動・履歴基盤
+
+- 段階: 4 / 規模: L（7–15人日、暫定）
+- 前提: P18, P05
+- 原本: B-7.1, B-7.4, B-7.5, B-7.6, B-11.3
+- 実装: 原本の決闘種別、プレイヤー行動、結果、履歴、人物外見状態を非描写のデータ/遷移/画面として実装。専用カメラは証拠IDとイベント基盤を接続。内容制作はP26に分離。
+- 受入: 各分岐が到達可能で勝敗/費用/盾/履歴を一度だけ反映。中断・対象離脱・取消・ロード後も矛盾なし。専用画面は中立テスト内容で操作を検証。
+- 決定待ち: D04, D07, D08
+
+### P20 ランク・信仰・物語進行
+
+- 段階: 5 / 規模: L（7–15人日、暫定）
+- 前提: P05, P11, P15, P19
+- 原本: B-1.1, B-1.2, B-1.3, B-1.4, B-1.5, B-6.4, B-6.5, B-8.1, B-8.5
+- 実装: 信仰/評判/裏影響、ランク条件、施設/方針/スキル解放、章とエンドを接続。条件評価APIだけでは進行完了としない。
+- 受入: デバッグで条件値を直接書き込まず新規ゲームから最終ランクと本編終点へ到達。条件未達の理由が画面で分かり、分岐復元が一致。
+- 決定待ち: D04, D08
+
+### P21 防衛・監査・銀行・砲台
+
+- 段階: 5 / 規模: L（7–15人日、暫定）
+- 前提: P05, P13, P14, P17
+- 原本: B-1.3, B-6.4, B-6.5, B-9.3, B-10.7, B-11.4
+- 実装: 原本の脅威発生から警告、準備、戦闘、能動スキル、魔法砲台、結果、施設損傷・休止へ接続。返済滞納と襲撃を接続。
+- 受入: API直呼びでなく通常営業から発生。勝利/敗北/退避/破壊・摘発/復元を検証。敗北で意図しない恒久ロストや勝手な休止解除がない。
+- 決定待ち: D03, D04, D05, D08
+
+### P22 素材台帳・量産仕様の先行確定
+
+- 段階: 1 / 規模: M（3–7人日、暫定）
+- 前提: P01
+- 原本: B-12.1, B-12.3, B-12.4, B-13.1, B-13.2, B-13.3, B-13.4, B-13.5
+- 実装: 全施設Lv1〜3×表裏、7人物、状態差分、背景、UI、音響の必要枠を列挙。既存Kenney素材と新規制作を区別しサイズ/命名/ライセンス/差替契約を定義。
+- 受入: 各資産が利用要件・画面・状態・制作者・仮素材/完成品に紐付く。必要数未確定のまま完成時期を断定しない。
+- 決定待ち: D08, D09
+
+### P23 タワー画面・レイヤー演出
+
+- 段階: 3 / 規模: L（7–15人日、暫定）
+- 前提: P08, P22
+- 原本: B-2.2, B-11.1, B-11.4, B-12.1, B-12.2, B-12.4
+- 実装: 非選択層の半透明/ワイヤー、波紋切替、上下移動/ズーム/視認性、原本に沿ったHUD配置と表裏スキンを実装。座標変換と選択判定を共通化。
+- 受入: 切替前後に選択・クリック座標が一致。パン/ズーム中の建設、異層施設の視認性、連続切替、速度x3で破綻しない。
+- 決定待ち: D09, D10
+
+### P24 インスペクター・通知・操作完成
+
+- 段階: 4 / 規模: L（7–15人日、暫定）
+- 前提: P09, P15, P16, P18, P23, P19
+- 原本: B-11.1, B-11.2, B-11.3, B-11.4, B-13.4
+- 実装: シフトのドラッグ配置、欲求/思考ログ、感情/盾、料金内訳、稼働阻害理由、接続線、フキダシ、カットインを接続。クリックによる代替操作も用意。
+- 受入: 無効ドロップで状態を壊さず理由を表示。保存後も対象選択を回復。ログの説明と実際の選択が一致。モーダル/停止/再開の入力を検証。
+- 決定待ち: D09
+
+### P25 ドット人物・施設差分・音響接続
+
+- 段階: 5 / 規模: L（7–15人日、暫定）
+- 前提: P22, P23, P12, P17
+- 原本: B-12.1, B-12.3, B-12.4, B-13.2, B-13.3, B-13.4, B-13.5
+- 実装: 状態駆動の歩行/作業/搬送/休息、施設Lv差分、背景、表裏BGMクロスフェード、環境/操作音を接続。実シミュレーションの状態を演出源にする。
+- 受入: 停止中は人物移動が進まない。搬送/休息は実位置に一致。音量/連続切替/ロードで二重再生しない。完成資産の欠損とライセンス記録漏れ0。
+- 決定待ち: D08, D09
+
+### P26 シナリオ・立ち絵・内容資産の制作受入
+
+- 段階: 5 / 規模: L（7–15人日、暫定）
+- 前提: P19, P20, P22
+- 原本: B-1.1, B-1.5, B-1.6, B-7.5, B-7.6, B-12.1, B-12.3, B-13.1, B-13.5
+- 実装: 全章・人物別ルート・終点・台詞・立ち絵・音声を台帳で制作/接続/受入。成人向け内容は表現仕様と制作可否を別途確認し、今回は非露骨な構造・資産管理・分岐検証のみ計画対象とする。
+- 受入: 仮素材や未制作の場面を完了扱いしない。全必要分岐と資産の欠損を一覧化。制作できない内容は原本との差分として残し、全実装完了を宣言しない。
+- 決定待ち: D08, D09
+
+### P27 統合・境界・障害復旧試験
+
+- 段階: 6 / 規模: L（7–15人日、暫定）
+- 前提: P10, P11, P12, P13, P14, P15, P16, P17, P18, P19, P20, P21, P24, P25, P26
+- 原本: B-1.1, B-1.3, B-14.4
+- 実装: 新規営業/停電/嵐/救護/決算/破産/襲撃/ルート進行の横断シナリオを実施。代表地点で保存・終了・起動を挟む。失敗を再現ケースに固定。
+- 受入: 全原子要件に合否証拠。進行不能・セーブ破損・帳簿不整合・原本との未承認差異0。未設定や未制作をスキップPASSしない。
+- 決定待ち: D01, D02, D03, D04, D05, D06, D07, D08, D09, D10
+
+### P28 性能・操作感・長期バランス
+
+- 段階: 6 / 規模: L（7–15人日、暫定）
+- 前提: P27
+- 原本: B-1.1, B-3.1a, B-4.3a, B-4.3c, B-11.1, B-12.1, B-14.4
+- 実装: 既存高負荷条件でCPU/経路/描画/保存を測定。通常プレイのラッシュ/満室/負荷ピークと長期経済を評価。20〜30時間本編・50時間以上全攻略は実プレイ記録で確認。
+- 受入: 既存性能予算と新しいWindows描画目標を満たす。到達不可能な収支/信仰/ランク条件なし。高速自動再生だけでプレイ時間・操作感を合格にしない。
+- 決定待ち: D04, D08, D10
+
+### P29 Windows実機・配布版・最終監査
+
+- 段階: 6 / 規模: M（3–7人日、暫定）
+- 前提: P28
+- 原本: B-1.1, B-14.1, B-14.2, B-14.3, B-14.4
+- 実装: 実EXEで新規→建設→営業→保存→終了→再起動→継続を操作。入力/表示倍率/音/日本語パス/回復を確認し、ビルドとソースのハッシュを固定。75要件と追加仕様を最終再監査。
+- 受入: 同一リリース候補のソース試験・PCK試験・Windowsネイティブ試験・プレイ記録・資産台帳が揃う。原本差異0で初めて全実装完了。工程の過去納期達成は別判定。
+- 決定待ち: D10
+
+## 5. 工数と日程の扱い
+
+30パッケージの技術作業単純合計は **180–390人日**。監査ベースの粗い仮置きで、確度は低い。制作量未確定の脚本/絵/音声、外部発注待ち、ユーザー判断待ち、実プレイ時間は含めていない。P26の見積は台帳・接続・受入の技術作業のみ。予備枠として技術作業の30%を別途確保する案とし、P01/P22後に実績で見直す。
+
+人数や稼働率が未指定のため固定の発売日を置かない。各マイルストーン後に残工数・回答待ち・制作待ちを再見積する。原本の2027年12月マスターアップは比較対象の目標であり、本計画から達成可能と断定しない。
+
+## 6. 決定待ち台帳
+
+未設定値をコードの都合で確定しない。まず影響、選択肢、推奨案、検証方法を具体化し、関連実装へ固定する直前に必要事項をまとめて確認する。現在は計画作成のため、回答を待って全作業を止める必要はない。
+
+| ID | 決める事項 | 決まるまで進められること | 固定が必要になる地点 |
+|---|---|---|
+| D01 | 欲求一致加算の額/率、不足基準、属性割当、複数属性/重複 | 計算契約、未解決状態、非一致利用、テスト入力を実装 | P09の本番課金。未設定を0円確定と扱わない |
+| D02 | 全施設の顧客専用上限・職員上限、Lv別の変化 | 人数集計、上限超過拒否、データ表を作る | P09/各施設の本番値。capacityから転記しない |
+| D03 | 休止からの復帰、関連施設の複数指定/AND/ORを採用するか | 現指定の永続休止・単一関連先を維持し接続試験 | 新しい解除/複数条件を追加する前。未設定のままなら追加しない |
+| D04 | 原本にない経済/天候/環境/役割/技能/成長/依存係数 | 原本明示数値を固定し、未指定値の比較試験を作る | バランス用本番データの凍結前 |
+| D05 | 全館停止中の搬送/EV安全処理、費用計上時点、日跨ぎ順序 | 状態遷移案・矛盾ケース・台帳例を作る | P04–P06の更新規約固定前 |
+| D06 | 寸法変更で重なる旧配置と旧拡張定義の移行方法 | 移行プレビュー、バックアップ、拒否時の原状保持 | 移行不能な既存セーブへの適用前 |
+| D07 | 旧5関係値から原本3値への意味付け、既存進行の扱い | 新旧を保存し、新規ゲームの原本モデルを作る | 旧プレイ進行の変換前。推測変換しない |
+| D08 | ルート/章/イベントの内容、成人向け範囲、制作可能な資産、必要量 | 非露骨な状態/分岐/中立テスト資産で接続検証 | P19/P20/P26の内容凍結前。未制作を完成扱いしない |
+| D09 | 立ち絵/ドット/音/声の品質と制作担当・予算・権利 | Kenney等既存素材の台帳、差替契約、必要枠の算出 | 外部発注/完成素材受入前 |
+| D10 | Windows対象機スペック/解像度/描画目標と最終評価者 | 手元環境の性能・機能を計測 | 性能合否とP29。未接続端末を確認済みとしない |
+
+D03のようにユーザーが明示的に未設定とした拡張仕様は「決定がないと現仕様を実装できない」わけではない。単一依存・解除なしで現要件を満たし、新たな挙動を発明しない。
+
+## 7. 検証計画
+
+| 層 | 検証対象 | 合格証拠 |
+|---|---|---|
+| 仕様/データ | 75群の原子条件・30施設・追加10項目・資産 | 対応表、寸法/層/属性/役割検査、未設定台帳 |
+| 部品 | 価格/会計/人数/条件/経路/関係/成長 | 境界/失敗/重複試験。実装をなぞるだけの試験は作らない |
+| Runtime | 通常Tick、コマンド、停止、実利用、損益 | 同一シードの実行ログと整合性検査 |
+| 保存 | 更新前後/営業中/乗車/搬送/イベント/日付境界 | 復元後同一再生、不正入力の原状保持、旧版移行 |
+| UI | 通常メニューから操作し結果を観察 | 実描画の入力・画像・状態一致。サービス直呼びで代替しない |
+| 配布 | ビルドに同梱されたデータ | ソース/ビルドハッシュ、PCK試験、Windows実EXE操作ログ |
+| 長期 | 新規から本編完走/全分岐/経済/負荷 | 実プレイ記録、到達性表、性能計測、未解決不具合一覧 |
+
+P02でWindows基準環境を準備し、P10/P14/P23/P24で部分実機確認を行う。P10/P17/P20では初期/中盤/終盤のプレイ試行を行い、問題を最後まで持ち越さない。更新・経路・描画の変更は代表負荷を都度計測する。利用できない環境の結果は未検証として残す。
+
+各パッケージでは関連試験を先に行い、統合点で全体回帰を実行する。全体PASS後に通しデバッグへ進み、修正が入った場合は該当回帰と通しシナリオを再実施する。過去ログを現在ビルドの証拠として無条件に使い回さない。
+
+横断シナリオ: (A)新規→開業→3日決算、(B)雨→嵐→霧→回復、(C)停電とEV乗車/救護の同時発生、(D)昼夜交代ラッシュと休息、(E)施設依存喪失/破壊/摘発/保存復元、(F)最高欲求と行列/価格/階層、(G)返済滞納→襲撃→結果、(H)ランク解放と全施設、(I)人物進行と全分岐、(J)旧版移行と最終配布。
+
+## 8. 性能と互換性の基準
+
+既存コードの基準を継続する: simulation_x1平均4ms、simulation_x3 P95 12ms、path_query P95 2ms、主スレッド停滞最大50ms、保存最大5秒、読込最大8秒。これらはシミュレーション等の予算であり描画FPS保証ではない。対象ハードと描画目標はD10で別定義する。
+
+既存の20,000マス/200客/50従業員/150施設を回帰条件とし、最終ランクで必要な規模が上回る場合は新しい負荷条件も追加。計測機・ビルド・シード・速度・観測区間・P95/最大値を保存する。メモリは複数回のロード/場面遷移後に安定するかを確認し、持続増加を調べる。
+
+サイズ変更、関係値変更、マナ/会計変更は別移行段階とする。旧セーブを上書きしてから検証しない。移行に失敗したデータを「復旧成功」として進めない。
+
+各パッケージの実装担当はコードと完了証拠を作成し、受入担当が原本条件を確認する。素材/内容の制作担当はP22/P26で確定する。人数・実名は未割当であり、並列体制や独立レビューを既に確保したとは扱わない。
+
+## 9. 初回実装時に行う順番
+
+1. P00で原本/ローカルソース/セーブの識別を固定する。
+2. P01で最初に経済・マナ・施設追加仕様の原子受入を作る。残りも台帳から落とさない。
+3. P02の既存回帰を確認し、P03の保存変更を先に実装する。
+4. P04の00:00・天候・停止・課金の順序を決め、P05を維持費→台帳→決算→UIの小さな縦断変更として通す。
+5. P06、P07へ進み、P08/P22の独立準備も順次行う。未回答項目に依存しない作業を継続する。
+
+最初の維持費実装は `FIRST_INCREMENT.md` に5つの変更と具体的な受入ケースへ分割した。
+
+この順番は今回の計画であり、バックグラウンド実行や定期実行の設定は行っていない。
+
+## 10. 自己レビューと改訂
+
+別紙 `SELF_REVIEW.md` に初案の問題点とv2の修正を記録。主な改訂は、保存移行の前倒し、経済/マナを施設量産の前に配置、素材設計の先行、通常UIと内容制作の分離、Windows実機と実プレイの独立ゲート、未設定値の局所ブロック化。
+
+## 11. 原本75要件の作業対応
+
+| 原本ID | 要件 | 実装/検証パッケージ |
+|---|---|---|
+| B-1.1 | 基本情報・Windows・2D・20〜30時間/50時間以上 | P00, P01, P20, P26, P27, P28, P29 |
+| B-1.2 | 地上/地下の二面性経営・観察介入・権威/富 | P01, P20 |
+| B-1.3 | 建設→集客→収益→管理→拡張防衛 | P01, P04, P20, P21, P27 |
+| B-1.4 | 二層・自律AI・渋滞・信仰と依存 | P01, P04, P20 |
+| B-1.5 | 世界観・主人公・7ヒロイン3運命 | P01, P17, P20, P26 |
+| B-1.6 | 成人向けルートと経営的搾取 | P01, P13, P26 |
+| B-2.1 | グリッド・Y正負・支持・領域拡張 | P03, P08 |
+| B-2.2 | 同座標Front/Back・半透明/ワイヤー表示 | P23 |
+| B-2.3 | 客エリアと景観/清潔/騒音の満足度効果 | P07 |
+| B-2.4 | バックヤード・職員ドア・客通行禁止 | P12, P14 |
+| B-2.5 | 覗き部屋の配置制約・通路寸断・証拠収集 | P13 |
+| B-2.6 | 地上/地下の採光・マナ・遮音・隠蔽ボーナス | P06, P07 |
+| B-3.1a | 10秒=1時間、Pause/x1/x2/x3 | P02, P28 |
+| B-3.1b | アクティブポーズ中も建設・指示 | P02 |
+| B-3.2 | 4時間帯と朝下り/夕上り/夜行動 | P04, P07, P15 |
+| B-3.3 | 昼夜シフト・体力0気絶・救護・通勤混雑 | P02 |
+| B-3.4a | 毎日00:00に決算レポート | P02, P05 |
+| B-3.4b | 3回連続赤字でゲームオーバー | P02, P05 |
+| B-3.5 | 雨・嵐・マナの霧・流行ニュース | P07 |
+| B-4.1 | 所持金/戦利品・四欲求・忍耐/清潔/依存 | P03, P15 |
+| B-4.2 | 最大欲求優先と距離/行列/価格選択 | P02, P15 |
+| B-4.3a | A*とエレベーター待ち時間コスト | P14, P28 |
+| B-4.3b | 4種垂直移動のゲーム内利用 | P14 |
+| B-4.3c | 重なり時速度50%低下 | P02, P14, P28 |
+| B-4.4 | 依存Lv3退店拒否・装備売却・性別別破産 | P15 |
+| B-4.5 | 貴族/聖職者/エルフ/魔族のAI特性 | P07, P15 |
+| B-5.1 | 一般雇用と奴隷の費用/耐性/売却区別 | P16 |
+| B-5.2 | 体力/ストレス/忠誠/技能/ランダム特性 | P03, P16 |
+| B-5.3 | 接客/裏方/救護/防衛等の職種 | P12, P16 |
+| B-5.4 | シフト休息と気絶回収 | P02, P12, P16 |
+| B-5.5 | 求人/市場/破産捕獲・退職金/売買価格 | P16 |
+| B-6.1 | ユニーク無料・高成長・解雇売却不可 | P17 |
+| B-6.2 | 7ヒロインの指定固有効果とライバル | P17 |
+| B-6.3 | 基礎技能と業務EXP・Lv99 | P03, P17 |
+| B-6.4 | 配置パッシブ・任意発動・ルート別スキル | P17, P20, P21 |
+| B-6.5 | 24時間勤務警告・衣装補正・限定離脱 | P17, P20, P21 |
+| B-7.1 | 三感情・盾・決闘の3ルート運命 | P18, P19 |
+| B-7.2 | 好感/淫乱/NTR・好感度=盾最大・淫乱軽減 | P03, P18 |
+| B-7.3 | 同配置接触→盾破壊→NTR上昇→不可逆陥落 | P18 |
+| B-7.4 | 3種決闘・勝利追放/隷属/盾回復・敗北確定 | P19 |
+| B-7.5 | 会話/デート/隔離・覗き・薬による各ルート | P19, P26 |
+| B-7.6 | 履歴・妊娠/父親・刻印立ち絵 | P19, P26 |
+| B-8.1 | 隣接/通路必須とLv拡張 | P03, P08, P09, P20 |
+| B-8.2 | 表層全施設・飲食と厨房セット | P09, P10, P11, P13 |
+| B-8.3 | 裏層全施設と特殊設備 | P09, P12, P13 |
+| B-8.4 | EV/階段/ワープ/通路/職員ドア | P14 |
+| B-8.5 | Lv解放の価格/食材/混浴/ハード/イカサマ設定 | P09, P20 |
+| B-9.1 | 表金/裏金・マナ全館停止・資材 | P03, P05, P06 |
+| B-9.2 | 全収益/人件費/維持/仕入/借金/ランク税 | P04, P05, P09 |
+| B-9.3 | 受付/金庫/購買/闇銀行 | P05, P21 |
+| B-9.4 | 依存客の娯楽優先・信用超過の破産拘束 | P15 |
+| B-10.1 | 宿泊施設の寸法/層/ゾーン | P08, P10 |
+| B-10.2 | 飲食施設の寸法/層/ゾーン | P08, P10 |
+| B-10.3 | 衛生/娯楽施設の寸法/層/ゾーン | P08, P11 |
+| B-10.4 | アングラ施設の寸法/層/ゾーン | P08, P13 |
+| B-10.5 | バックヤード施設の寸法/層/ゾーン | P08, P12 |
+| B-10.6 | 特殊施設の寸法/層/ゾーン | P06, P08, P13 |
+| B-10.7 | インフラ/防衛施設の寸法/層/ゾーン | P06, P08, P14, P21 |
+| B-11.1 | 資源/時間/天候/Rank・下部切替・スクロールズーム | P07, P23, P24, P28 |
+| B-11.2 | Policy/ドラッグ配置・欲求/思考/感情グラフ/盾 | P24 |
+| B-11.3 | カメラ入口・覗きアングル/撮影/介入 | P19, P24 |
+| B-11.4 | グリッド/接続警告・フキダシ/ログ・カットイン | P21, P23, P24 |
+| B-12.1 | 二面性・高精細ドットとアニメ立ち絵 | P22, P23, P25, P26, P28 |
+| B-12.2 | 魔法レンズ風の波紋切替 | P23 |
+| B-12.3 | SD各モーション・立ち絵破損/汚れ/刻印差分 | P22, P25, P26 |
+| B-12.4 | 表裏UIスキン・BGMクロスフェード・環境音/SE | P22, P23, P25 |
+| B-13.1 | 立ち絵/CG/差分 | P22, P26 |
+| B-13.2 | SDモーション/エフェクト | P22, P25 |
+| B-13.3 | Lv1〜3表裏タイル/背景 | P22, P25 |
+| B-13.4 | 表裏スキン/感情/覗き素材 | P22, P24, P25 |
+| B-13.5 | BGM/環境/操作/成人向けSE/声 | P22, P25, P26 |
+| B-14.1 | 2026/03〜08 プロトタイプ | P00, P01, P29 |
+| B-14.2 | 2026/09〜2027/02 アルファ | P00, P01, P29 |
+| B-14.3 | 2027/03〜08 ベータ/成人向け | P00, P01, P29 |
+| B-14.4 | 2027/09〜12 ポリッシュ | P00, P01, P27, P28, P29 |
+
+追加施設10項目は全件P09が統合責任を持ち、費用はP05、稼働/マナはP06、寸法はP08、施設データはP10–P13、UIはP24と連携する。
+
+計画整合性は `plan_validation.json` を参照。全75要件と追加10項目の対応、依存先存在、循環なしを機械検証した。これは計画の整合性検証であり、ゲーム実装の合格ではない。

docs/plans/original-completion-2026-09-29/SELF_REVIEW.md

@@ -0,0 +1,35 @@
+# 計画の自己レビューと改訂記録
+
+2026-09-29。作成者自身によるレビュー。独立した第三者レビューや実装検証を行ったという意味ではない。
+
+初案の骨格は「基盤→経済→施設→AI/人物→演出→総合試験」。この順序を、既存セーブ、通常UI、制作物、原本未設定事項、納期を壊さないかという観点で見直した。下表の修正はv2へ反映済み。
+
+| No. | 初案・検討時の問題 | v2へ反映した修正 | 確認方法 |
+|---|---|---|---|
+| R01 | 75複合要件への紐付けだけでは、一部条件を落としても完了にできる | P01で原文単位の原子受入を作り、最後は全条件ANDで判定 | 原文行→原子条件→実装→証拠を検査 |
+| R02 | 寸法や関係値を先に変えると旧セーブを破壊し得る | P03で移行契約を先行。P08/P18に保全・不一致時拒否を追加 | 配置重複/支持喪失/意味不明な変換の試験 |
+| R03 | 施設量産後に維持費・マナを接続すると収支と稼働条件を作り直す | P09の前提をP05/P06/P08とする | 施設量産の着手時に共通契約の受入を確認 |
+| R04 | P15の破産状態とP16の獲得処理が対象施設より先行できていた | P15/P16の依存にP13を追加 | DAG検査、通常配置先まで通す受入 |
+| R05 | P24の専用イベントUIがイベント操作APIより先行できていた | P24の依存にP19を追加 | UIから選択→費用/結果→保存を確認 |
+| R06 | 最後にまとめてWindows検証すると入力・描画の問題が遅れて発覚 | P02でWindows基準環境を準備し、P10/P14/P23/P24で部分実機確認 | 実EXEの操作証拠。接続不能時は未検証と記録 |
+| R07 | 性能と長期バランスが最終工程に偏る | 更新/経路変更ごとに代表負荷、P10/P17/P20でプレイ試行を追加 | プロファイルと初期/中盤/終盤の収支・操作記録 |
+| R08 | 未設定の複数依存や休止解除を、全実装に必須の新機能と誤解し得る | D03は拡張時のみ決定。現仕様の単一依存・解除なしは実装可能 | 最終未設定0の条件を「現仕様で必須の値」に限定 |
+| R09 | 料金APIがあるだけで加算完了にできる | P09で本番属性・不足判定・人数・見積・実請求・台帳・ロードを一連で受入 | 仮値の単体試験とは別に本番データで操作する |
+| R10 | 素材制作を後回しにすると必要数と外部待ちが最終日程を支配する | P22をP01直後から着手可能に。P26の技術と内容制作を分離 | 未制作枠/制作担当/ライセンスの台帳 |
+| R11 | 声・CG・露骨な内容を技術パッケージに隠して全実装を約束し得る | 内容制作可能範囲を明示し、未制作を残件として扱う | 仮素材や制作範囲外をPASSにしない |
+| R12 | 大きなパッケージの概算を確定納期と誤読し得る | 180–390人日は粗い技術概算と明記。制作・実プレイ・待ち・予備枠を分離 | P01/P22後、各節目で実績に基づき再見積 |
+| R13 | 定義登録数19を原本30施設の充足数と混同し得る | 原本30施設と既存35定義の対応を別表で管理 | 通常登録/パレット/役割/寸法を別列で検査 |
+| R14 | 項目の担当が曖昧で最後に証拠だけ残らない | 各作業に実装・受入・制作の役割を記載。担当者の実名割当は未指定のまま | 完了証拠作成を実装担当の作業に含める |
+| R15 | 原本が変わるとこの計画の前提が古くなる | P00で再照合し、監査SHAを計画に保持 | 差分が出た要件のみ影響分析し再計画 |
+
+## 修正後の検査
+
+- 全75要件に作業の対応先がある。
+- 追加施設10項目に対応先がある。
+- 存在しない依存ID、循環依存はない。
+- 検証済み8群を作り直し対象にせず、回帰対象として維持している。
+- 仕様未設定、コード未実装、内容未制作、実機未検証を別に扱っている。
+- 新規ゲームの正常系だけでなく、旧セーブ・中断・失敗・復旧を各受入に含めている。
+- 計画の整合性とゲームの実装完了を混同していない。
+
+実行結果は `plan_validation.json`。以上で計画の抜け漏れが絶対にないことを保証するものではない。P01の原子要件化、P22の必要資産数確定、最初の縦断実装の実績で再レビューする。

docs/plans/original-completion-2026-09-29/execution/ACTOR_SELECTION_RESTORE.md

@@ -0,0 +1,11 @@
+# 従業員・来客の選択復元
+
+2026-09-30。P24の「保存後も対象選択を回復」を従業員管理と来客観察へ接続。施設等の選択とは別の任意保存情報として、各実在IDと画面の開閉を保存する。手動保存とRuntimeが実行するチェックポイントは同じ情報収集処理を使う。
+
+成功した厳格読込・復旧候補読込で各IDを独立検証し、実際に読み込んだ候補の対象を表示する。閉じていた観察画面も表示せずに対象を復元できるよう、画面生成と表示を分離。存在しないID・不正型・過長ID・未知版・旧形式はゲーム進行を壊さず通常表示へ戻す。読込失敗では現在の選択と表示を保持。未確定の配属・シフト入力は保存対象としない。
+
+通常の候補ボタンで2名を雇用し、独立した来客2名をRuntimeの生成コマンドで作成。来客は境界試験用の制御された到着であり、自然入館の受入とは扱わない。通常の従業員ボタン・来客プルダウンを操作し、手動保存、厳格読込、画面破棄/再生成、閉じた画面、2世代の実自動保存候補、失敗、旧版/不正な任意情報を検証。100項目PASS。実描画101項目PASS、画像でバルドの詳細、来客selection_guest_b、所持金910G・食欲83を確認。関連7スイート552項目PASS。
+
+ゲーム状態の照合では測定時間を含む通知データだけを除外。読込試行が診断イベントIDを1個採番する場合はその増分を明示照合し、他の採番器・乱数・業務状態は保持して比較する。初回のサービス直接生成は財布等のRuntime横断契約を欠いたため、正しい生成コマンドへ検証用入力を修正。修正前ログを保全した。検証ドライバーの最初の停止はダッシュボードのPASS出力形式を認識しなかったためで、ゲーム試験の失敗ではない。双方の合格形式を読めるよう修正した。
+
+証拠: artifacts/actor-selection-2026-09-30/。main.before.gd、main.diff、before*.log、headless.log、rendered.log、targeted.json、verification.json、restored-actor-inspectors.png。最新144スイート全件PASS、全件PASS後の実描画開業通し103項目PASS。追加の別プロセス選択復元は書込103・読込13＝116項目PASSし、保存された両ID・画面の開閉、ゲーム状態JSONと型付きdigestが一致した。証拠: artifacts/actor-selection-restart-2026-09-30/。Windows更新は同梱PCK12回・計2,094項目PASS、ZIP CRC/同梱SHA一致で完了（CURRENT_WINDOWS_PACKAGE.md）。同一ビルドWindows実機、P24全項目、原本全実装は未完了。

docs/plans/original-completion-2026-09-29/execution/ADAPTER_VALIDATION_CACHE.md

@@ -0,0 +1,10 @@
+# Route adapter validation cache
+
+P28 partial performance work. Route invariant validation now retains one private successfully parsed snapshot, like the facility projector. A fresh serialized snapshot is compared by complete content on each call; changed records/revisions/quarantine state are re-parsed. Live source/graph checks remain outside the cache. Restore still always invokes the strict parser. All snapshot arrays are independently allocated, and no save schema changes were made. This adds memory for one retained adapter snapshot; maximum-history memory acceptance remains outstanding.
+
+Evidence:
+- Route adapter184 checks PASS, including unchanged/repaired history, fingerprint corruption without a revision change, mutated exported containers and independently changed/repaired live graph.
+- Facility projector192, Runtime infrastructure162 and Runtime integration20 checks PASS on this production change. The integration suite covers disk save/load and deterministic replay.
+- Small production headless fixture: adapter validation average1.423ms →0.424ms; nested projector validation2.536ms →1.533ms; x1 average16.348ms →14.359ms; x3 P9560.411ms →53.828ms.
+
+Performance budgets4ms/12ms remain failed. No high-load/GPU/Windows acceptance is claimed. Source/log hashes: adapter-cache-validation.json. Performance reports: production-projector-cache.json and production-adapter-cache.json. Snapshot-component diagnostic completed: production-snapshot-costs.json. Snapshot total average7.999ms; OperationsCoordinator.create_snapshot3.622ms; whole-snapshot deep copy1.095ms. These standalone component samples are not an additive phase decomposition. Source inspection identifies recursive tree/shape validation plus serialization in OperationsCoordinator; its corruption rejection contract must remain intact in the next optimization.

docs/plans/original-completion-2026-09-29/execution/AMELIA_DONATIONS.md

@@ -0,0 +1,17 @@
+# アメリアの寄付金3倍
+
+原本6.2「寄付金3倍」、6.4「配置するだけで自動発動」を礼拝堂の価格経路へ接続。ユニーク雇用・聖職者・ID heroine_amelia の人物が配属された礼拝堂を対象とし、他の礼拝堂や宿泊料金へは波及しない。出勤状態ではなく配置を参照する。
+
+既存の寄付を礼拝サービス料金として扱う契約に沿い、価格方針適用後の寄付額を3倍、その後に既存のアンリ配置階補正を一度適用。標準20Gは60G、アンリ併用では72G。客の支払額と施設売上は一致し、受理済みの見積は料金変更や保存復元で書き換わらない。営業画面の現在値・変更後予測・効果説明にも反映。
+
+通常加入の初期能力・加入条件は未設定のまま。試験では register_staff によるユニーク人物fixtureを使用し、その後の配置は従業員画面、来客は通常AI、礼拝・支払・信仰加算はRuntimeで動かした。アメリアの通常加入、回復速度2倍、人物の全実装を完了と扱わない。
+
+検証: 専用macOS実描画39チェックPASS。料金60G、別施設・別職種・一般雇用への非適用、アンリ併用72Gと解除、礼拝中に90Gへ変更しても受理済み60G維持、復元、客支出と帳簿一致、信仰は寄付額に関係なく完了ごと1を検証。営業画面gameplay.pngで60G・寄付金3倍・信仰+1を目視確認。
+
+関連回帰: 通常礼拝堂16、アンリ48、営業画面72チェックPASS。初回2回の専用試験は信仰を1で固定していたため失敗した。他の自律客も礼拝を完了して信仰2となっており、礼拝完了件数との一致に改めた。失敗ログも保持する。
+
+証拠: artifacts/amelia-donations-2026-09-29/。全原本・Windows・長期プレイは未完了。通し再起動の最終結果は追記する。
+
+## 通し検証完了
+
+実描画の別プロセス再起動: 書込80・読込17の計97チェックPASS、両方終了コード0。書込62.68秒・読込47.65秒。source-change.jsonは空、write/read-gameplay.json一致。通常開業・3回決算の回帰であり、アメリア固有の効果試験は上記39チェックで別に検証。

docs/plans/original-completion-2026-09-29/execution/ANRI_APPROVED_INTEGRATION.md

@@ -0,0 +1,10 @@
+# アンリの通常加入・料金補正に関するユーザー決定
+
+今回の会話でユーザーが以下を明示承認した。
+
+1. 「従業員画面で無料加入を選ぶ」。新規ゲーム開始時の自動在籍や未指定イベント条件に置き換えない。
+2. 「利用料金を20%増やし、客の支払額と施設収入を一致させる」。架空の追加収益や補助金として20%を生成しない。
+
+原本の配置フロア全施設への効果、雇用／維持費無料、解雇売却不可は維持する。加入処理、画面、配属、料金見積もり、財布／台帳、途中保存の接続は未完了。この文書は実装完了を示さない。
+
+接続時の既存コード課題: staff_hire_payload と雇用済みID復元検査は一般候補のみを受け付ける。雇用後検査が FREE_HIRE 固定。候補UIと管理UIの表示名参照も一般候補のみ。アンリの innkeeper 職種と施設の required_roles の整合を明示し、一般職の偽装で代用しない。保存マニフェストの通常候補20件とユニークの別ID一覧を維持して、雇用済み集合の解釈を拡張する必要がある。

docs/plans/original-completion-2026-09-29/execution/ANRI_FLOOR_PRICING.md

@@ -0,0 +1,27 @@
+# アンリの配置フロア料金+20%を実行処理へ接続
+
+ユーザー承認の料金方式を実装。正規加入したアンリの職種 innkeeper と UNIQUE 属性を確認し、通常の従業員配置コマンドで施設へ管理配置する。staff_max と経路の検査は維持する。女将は運搬員などの専門職に変換せず、施設の稼働最低人数には数えない。保存復元側にも同じ管理配置の職種例外を適用した。
+
+適用範囲は確定した施設配置のY座標が同じフロアの全施設（表裏双方）。原本「配置するだけ」のため予定として保持される配置から導出し、通勤完了・勤務時間を新たな発動条件にしない。配置解除／配置施設不在で補正なし。同じ人物の効果を積み重ねない。基準料金に営業方針の倍率を適用した後、12000bpを一度適用し、既存料金と同じ整数Gの四捨五入を使う。無料受付は0のまま。
+
+自律客の候補見積もり、通常サービス申請の既定価格、営業画面の現行価格と方針変更プレビューを共通計算へ接続。営業画面に「アンリ配置フロア：利用料金＋20%」を表示する。受付後は従来通り ServiceRequest／ServiceInstance の価格を固定する。
+
+Runtime22項目PASS: 通常建設した上級客室と同階裏層倉庫、業務階段、正規加入、到達可能な管理配置、別階への非適用、264Gの受付／実サービス完了／財布減算／同額施設売上／台帳整合、途中保存と解除後の220G復帰を確認。女将が倉庫の運搬員として稼働人数を満たさないことも確認。支払試験は明示的なゲスト財布・サービス申請の制御fixtureであり、自律客の来館から最終退館までの実プレイではない。
+
+macOS描画ありUI19項目PASS: 無料加入と保存、通常画面で受付へ女将を配置、大浴場の24G表示、150%方針の設定後36G表示、効果の説明を確認。画像 anri-floor-assigned.png を視認した。既存営業UI65／従業員UI87もPASS。最初のRuntime試験で保存時の職種照合の不一致を検出し修正した。試験側の誤った台帳API名も修正済み。
+
+証拠は artifacts/facility-dimensions-2026-09-29/anri-floor-validation.json。初回の今回画像取得で旧 anri-recruited.png が更新されたため、旧加入マニフェストの画像ハッシュは歴史的証拠。現行画像は専用名へ分離した。
+
+残件: 自律来館からの通し営業、配置変更／夜勤等の追加境界、他6名の固有効果・成長・物語、Windows同一ビルド。P17全体／全原本の完了ではない。
+
+## 自律客の利用と支払の追加確認
+
+Runtime試験を36項目へ拡張し全PASS。通常の建設コマンドで表層階段を追加し、アンリを再配置。客の初期欲求・所持金を制御して生成した後、目的地・経路・価格を指定せず、客自身の選択、階段移動、利用開始、264Gでの宿泊完了を確認した。移動途中の保存を復元すると利用開始時の全スナップショットが一致する。財布の減算264Gと施設売上264Gも一致し、完了後の保存復元・台帳整合が通る。ランダム来館から退館までの実プレイ受入を完了した意味ではない。
+
+同じ版で加入UI17項目もheadlessでPASS。今回の変更は追加試験・証拠・進捗記録であり、追加の本体修正は不要だった。証拠: `artifacts/facility-dimensions-2026-09-29/anri-autonomous-validation.json`。
+
+## 配置変更・夜勤・撤去境界
+
+Runtime試験48項目PASS。同じアンリを上階の昼勤配置から地上階の夜勤配置へ変更し、旧階の料金が220Gへ戻り、新階だけが12000bpとなることを確認。staff_max=0の客室への変更は拒否され、元の配置・補正が保持される。配置中の倉庫撤去はSTAFF_ASSIGNEDで拒否され、施設と効果を保持する。夜勤配置の全スナップショットを3回復元しても完全一致し、補正が累積しない。元の階への再配置でも同じ料金へ戻る。これは予定配置の切替試験であり、一晩の勤務行動すべてを検証したものではない。
+
+今回追加した境界では本体不具合は検出されず、本体コードの変更はない。ログ: `artifacts/facility-dimensions-2026-09-29/anri-placement-boundaries.log`。

docs/plans/original-completion-2026-09-29/execution/ANRI_INTEGRATED_UI_REGRESSION.md

@@ -0,0 +1,9 @@
+# Anri integrated UI regression
+
+make test-ui GODOT=/opt/homebrew/bin/godot completed in 106.08 seconds with exit code 0. Godot 4.7.2, macOS, headless. Source hashes remained unchanged throughout the run.
+
+20 direct scripts passed 992 checks. The separate-process upkeep save/write and read phases also passed. The direct scripts cover Anri pricing (48), recruitment (17), layer skin, rank, pointer controls, migration, upkeep inspector, rest, rescue, guest observer, room/pixel presentation, dashboard, staff, supply, business, elevator and first operating day (59). The latter includes opening, time progression and daily settlement.
+
+Evidence: artifacts/facility-dimensions-2026-09-29/anri-full-ui.log and anri-full-ui-result.json (source hashes). The fresh-process evidence was copied to anri-upkeep-write.log, anri-upkeep-read.log and anri-upkeep-result.json in that directory.
+
+This proves the UI regression scope only, not full original acceptance, Windows native behavior, visual acceptance, all characters/facilities, long-term progression or performance compliance. Known production performance failures and remaining work packages remain open.

docs/plans/original-completion-2026-09-29/execution/ANRI_OPENING_GUIDE_ROLE.md

@@ -0,0 +1,11 @@
+# Opening guide must require receptionist coverage
+
+Confirmed a user-visible integration defect: the guide counted any repeating work assignment at reception as receptionist coverage. Anri can be placed there for her floor passive but is excluded from required operational staffing. Consequently the guide could invite the player to wait for sales while no receptionist was assigned. The same error survived load.
+
+The guide now checks the facility definition's required roles before counting active staff, repeating plans or legacy shifts. It still accepts an actual receptionist's off-duty recurring plan and does not alter simulation staffing or Anri's floor price effect.
+
+Before-fix evidence: anri-guide-before.log reports 22 checks with 2 failures (manager mistaken for receptionist, including after load). After-fix Anri UI coverage: 22 checks PASS. The first-operating-day scenario additionally places Anri via staff controls after constructing reachable rooms, verifies the displayed guide remains on staff recruitment and the floor multiplier remains 12000, then restores the ordinary scenario and continues natural arrival, sales and settlement. Read its completed log for acceptance; no synthetic guest was added to that operating-day scenario.
+
+Evidence directory: artifacts/facility-dimensions-2026-09-29. This fix does not complete other unique characters, full original acceptance or Windows validation.
+
+Completed: Anri recruitment UI 22 checks PASS and first operating day 63 checks PASS, both exit code 0. Source/log hashes recorded in anri-guide-validation.json.

docs/plans/original-completion-2026-09-29/execution/ANRI_ORIGINAL_EFFECT.md

@@ -0,0 +1,11 @@
+# アンリの固有効果定義を原本へ修正
+
+原本 B-6.2 は「配置フロアの全施設売上+20%」、B-6.4 は配置によるパッシブ発動を指定。従来の mvp_unique_characters.json は assigned_floor_patience_loss_multiplier_bp=9000 とし、忍耐減少を軽減する別効果を定義していた。この値は原本準拠ではない。
+
+現在のアンリ定義を assigned_floor_revenue_multiplier_bp=12000 へ修正し、カタログのホワイトリストと heroine 必須効果を同じキーへ変更した。旧忍耐キーの不在と12000、返却データの防御コピー、係数の検証を試験する。人物ID、年齢、他の未承認バランス値、ライバル効果はこの修正で変更しない。
+
+検証: MvpContentCatalog213、Runtime content/progression108項目 PASS。後者は通常候補雇用、カタログ保存マニフェスト、改ざん拒否、24時間保存再生を含む。Runtime のマニフェストは人物IDを保持し効果の辞書を保存していないため、この定義修正に伴う保存形式変更はない。ソースとログの SHA-256 は anri-original-definition-validation.json。
+
+重要な残件: 現 Runtime は unique_characters を通常の hire_staff_candidate に接続しておらず、アンリの配置も売上倍率も営業処理に適用しない。この変更は定義差異の是正のみで、B-6.2／P17 の実装完了ではない。単なる料金+20%で「売上+20%」を代用してよいとも決めていない。通常の加入／配置導線、原本全7名と職種、無料／解雇不可、施設・フロア範囲、シフトとの関係、価格と売上補正の会計契約、保存復元、表示、通常営業の受入が必要。
+
+次の作業では既存の一般雇用とユニーク加入を区別し、原本に数値のない加入条件等を仮定せずに接続契約を整理する。忍耐効果が元から Runtime に効いていたとは報告しない。

docs/plans/original-completion-2026-09-29/execution/ANRI_RECRUITMENT.md

@@ -0,0 +1,11 @@
+# アンリの無料加入を通常UIへ接続
+
+ユーザー指定の「従業員画面で無料加入」を実装。一般候補20名のカタログ区分を保ち、加入可能一覧へ承認済みのアンリだけを加えた。ライバル加入条件は追加しない。アンリは女将 innkeeper／UNIQUE、契約金0／日給0、既存定義の技能・希望勤務帯で加入する。未定の業務適性は一般職の偽装や任意タグで代用しない。
+
+既存の検証済み雇用トランザクションを再利用し、保存の加入済みID検査と人物属性の照合を UNIQUE に対応させた。登録の迂回は引き続き拒否し、加入済みアンリの欠落・FREE_HIREへの降格を復元時に拒否する。一般求人のID一覧と保存マニフェストの区分は変更しない。管理画面はユニーク定義の名前と女将の職種名を表示する。
+
+通常画面のボタンから申請→重複送信拒否→手動保存→対照状態へ復元→読込→次の時間更新で加入→加入後保存・読込を検証。アンリ本人のUNIQUE属性、所持金不変、日給0、加入済み表示、退職拒否、不正な保存の原状保持を確認。headless13、macOS描画あり15項目PASS。anri-recruited.pngを視認し、アンリ（女将）・日給G0・未配属を確認した。
+
+関連回帰: catalog213、Runtime content116（24時間保存再生を含む）、dashboard139、staff UI87項目PASS。ダッシュボードの候補数期待値は一般20+アンリ=21へ更新。初回画像取得は試験がパネルを閉じてしまっていたため、可視性を明示検査するよう修正して再取得した。
+
+証拠とSHA-256: artifacts/facility-dimensions-2026-09-29/anri-recruitment-validation.json。通常配属とフロア料金+20%はまだ接続していないため、固有効果・P17・全原本の完了ではない。Windows同一ビルド未検証。

docs/plans/original-completion-2026-09-29/execution/BUSINESS_CUSTOMER_COUNTS.md

@@ -0,0 +1,7 @@
+# Business panel counts people separately from services
+
+The business report exposed active service/request counts, but the panel labelled them as people. This undercounted multi-person services and queues. Added active_customer_count (FacilityInstance.customer_count), queued_customer_count (distinct guest IDs from queued requests), and customer_capacity to the read model. Existing active_count/queued_count retain their service/request semantics. The panel now uses actual people and explicitly displays the customer-only limit;0 and unspecified(-1) remain distinct. No capacity values, billing, service lifecycle, or saved fields were changed.
+
+Controlled grouped UI fixture: one active service/two people and one queued request/three people; explicit limit3, unspecified and zero; original fixture restored before later tests. This verifies display/read-model semantics, not a new group-arrival gameplay feature. Business UI72 checks passed headless and native macOS; chapel16 passed; original facility control result is recorded in the validation file. Native1280x720 screenshot visually reviewed: labels and actions remain inside scrollable sidebar.
+
+Evidence: artifacts/business-people-2026-09-29/validation.json and logs/screenshots. Prior full128 suite and3-day run predate this display-only change. Facility customer values and other original implementation gaps remain open.

docs/plans/original-completion-2026-09-29/execution/CHAPEL_ANRI_WINDOWS_PACKAGE.md

@@ -0,0 +1,12 @@
+# Chapel/Anri Windows development package
+
+Built the current local production source using Godot4.7.2 Windows Desktop export into `build/windows/chapel-anri-2026-09-29`. Export exited0; EXE is PE32+ x86-64. Production-source/asset hashes were captured before export and remained unchanged through verification. This is an incremental development package, not completion of P29 or the original specification.
+
+Validation ran each external test driver from an empty temporary directory with `--main-pack`, so game data/implementation came from the PCK rather than the checkout. Opening test explicitly verified absence of raw source project/definition files:28 PASS. Anri normal recruitment/assignment/fee/SaveLoad:22 PASS. Chapel normal construction/cleric/guest/worship/payment/Faith/SaveLoad:16 PASS. The same packed chapel scenario rendered on macOS:17 PASS; packed-chapel.png was visually inspected. These are repeated/overlapping scopes, not83 independent acceptance requirements. No Windows EXE was executed.
+
+Source regression reference:127 source suites completed before the latest ledger label correction; the correction was subsequently covered by97 checks in the rendered two-process three-close flow. Keep those scopes separate from PCK tests. Performance budgets, full original facilities/stories/assets and Windows native acceptance remain open.
+
+Pack contains EXE, PCK, Japanese README with current feature/verification boundaries and Windows smoke steps, BUILD_MANIFEST.json, existing Kenney licenses/source records, and Godot license/third-party notices obtained from the installed engine's license APIs. ZIP CRC verified. Build/source/screenshot results are retained under `artifacts/chapel-package-2026-09-29`.
+
+ZIP: build/windows/TheTree-Windows-chapel-anri-2026-09-29.zip
+SHA-256: 08c759e8d4cca0268fdd4d3be0f3f9d79bf390f9cd6deb8749d95dd6dfca6ba5

docs/plans/original-completion-2026-09-29/execution/CHAPEL_APPROVED_INTEGRATION.md

@@ -0,0 +1,27 @@
+# Chapel integration - approved balance and first service boundary
+
+User explicitly approved the proposed initial trial values: construction 1200G, materials12, duration180min; simultaneous customers8; cleric minimum1 and staff maximum2; worship60min, donation20G, completion Faith+1; daily upkeep6G. Original specifies footprint4x3, FRONT. Values are initial trial balance, not original numeric requirements. Queue capacity8, default quality50 and no mana upkeep are provisional inherited/implementation choices, not stated original values.
+
+Implemented a staged chapel Resource at data/facilities/expansion/chapel.tres and a nonnegative FacilityDefinition.faith_per_service property (default0). DefinitionRegistry rejects negative reward values. Runtime completion now applies the faith resource and progression faith_lifetime metric at the existing service settlement boundary after inventory/payment/output checks. Failure rolls back inventory, economy, resources and progression; the service does not complete. Existing definitions have zero reward. Duplicate paid completion is rejected by the existing payment idempotency key and terminal services do not re-complete after restore.
+
+The staged test explicitly adds the chapel to its registry, constructs via normal build command, and uses controlled staff availability and payer wallet. It checks dimensions, approved values, unstaffed closure, service start, no early payment/reward, midway restore, donation20G, Faith+1 and lifetime+1, completed reload without duplicate, exact replay, and failed progression with payment rollback and one recovered reward. This is not normal recruitment or autonomous guest acceptance.
+
+Remaining before normal catalog exposure: cleric recruitment with appropriate wage/hiring balance, catalog/save compatibility, normal construction palette and role labels, autonomous worship selection/arrival/queue/payment, staff-loss interruption, capacity8, upkeep6G and UI faith explanation, native screenshots and Windows. Do not count the chapel as a normally playable completed facility yet.
+
+Evidence: artifacts/facility-dimensions-2026-09-29/chapel-service.log, chapel-existing-cycle.log, chapel-anri-pricing.log. Their completed outputs are authoritative for pass counts.
+
+## Normal catalog and cleric recruitment
+
+Chapel is now registered in the original-facility catalog and main construction palette. A licensed existing theme icon is reused as a placeholder, not claimed as completed chapel art. Added regular cleric staff_uma with Japanese role label. Hiring210G/day wage130G and service skill74 use the existing attendant candidate's initial balance; these staff values are implementation trial values, not original or user-approved facility figures. Original20 candidates remain unchanged. Catalog manifest v2 adds exactly this candidate. The exact historical v1 manifest remains accepted only without the new candidate already present/hired; arbitrary missing IDs are rejected.
+
+New normal-scene test uses construction/hire/assignment controls, actual clerk commuting/staff projection and controlled arrival followed by autonomous guest selection, arrival, worship,20G payment and Faith/lifetime+1. It also covers original manifest migration, malformed manifest rejection and in-service/completed save. It does not prove random-arrival frequency, all-day economics, guest capacity8 or staff-loss interruption.
+
+Native macOS verification completed: 17 chapel gameplay checks PASS, with screenshot chapel-gameplay.png visually reviewed. The business panel shows20G per use and Faith+1 per worship completion; HUD Faith1 and today's revenue20G match actual settlement. Chapel art remains generic placeholder room art. Before the final business-text and malformed-legacy-row guard changes, the complete make test-ui passed (including 14 chapel gameplay checks); final targeted native gameplay, business and content tests cover those last changes.
+
+## Capacity and loss of cleric coverage
+
+Added tests/mvp/test_chapel_boundaries.gd using normal catalog construction, real cleric hire/assignment/attendance and controlled wallets/service requests for capacity boundaries. Eight services start and a ninth waits separately. A normal unassignment triggers WAITING_FOR_STAFF with frozen progress; no early donation or Faith occurs. The paused state and grace deadline restore exactly, and continued absence fails service without reward/charge. Restoring the staffed checkpoint then completes all nine requests for180G and Faith9, never exceeding8 simultaneous users. These first35 assertions passed.
+
+The same test continues in a separate fresh operating game (required06:00 start), builds and staffs a chapel and advances two normal days without inserting guests/services. It checks partial-day upkeep, the full-day6G rate, natural donation/Faith reconciliation and close/reload boundaries. Its final log, not this plan text, is the authority for full acceptance. An initial fixture attempted to enable operations midway, violating the existing start-time contract; corrected to a new game without changing production rules.
+
+Completed boundary/operating run: 46 checks PASS, exit0. First partial-day upkeep3G and next full-day upkeep6G; positive natural donation revenue equals Faith*20, lifetime Faith matches held Faith, ledger balanced and no Runtime failure latch. Both midnight boundaries and second-day completed close restore successfully. Evidence: chapel-boundaries-validation.json. This is one seed over two days, not a long-term economy or Windows acceptance.

docs/plans/original-completion-2026-09-29/execution/CHAPEL_FULL_REGRESSION.md

@@ -0,0 +1,21 @@
+# Full source regression after chapel integration
+
+Started tools/run_all_tests.py with Godot4.7.2 and output artifacts/chapel-full-regression-2026-09-29. all-tests.json is incremental and does not establish full completion until the runner exits. Source hashes at launch are in source-start.json. The runner excludes exported-package tests and the kernel module invoked by run_tests.gd. A separate packaged-build acceptance is still required.
+
+Read-only audit identified obsolete21-facility expectations in Runtime integration, Runtime stairs and exported opening. The two source tests were independently run before changing them and each failed only on that old count. Updated expected count to22, including chapel, and added explicit chapel registration assertion. Targeted reruns: Runtime integration21 checks PASS; stairs67 checks PASS. Export expectations updated for the future rebuilt pack; no exported package has been verified by this action.
+
+Only these three test files changed after source-start.json during the sweep; the production source was not changed by this regression repair. The full runner will later execute the corrected source tests. Preserve before/after logs instead of treating the original failure as a gameplay defect. Final source hashes and the complete result must be checked when the runner finishes.
+
+Runner exec session18695 was confirmed live during this turn, processing test_chapel_boundaries.gd. Continue polling the same session; do not restart solely because a poll times out.
+
+## Public catalog lookup correction during regression
+
+Read-only audit found that `FacilityCatalog.by_id` omitted ORIGINAL_FACILITY_PATHS. Chapel was therefore registered in normal Runtime construction but returned null from this common query. Expanded the lookup to include original-facility paths without altering baseline/optional expansion lists. Added a contract test that every normally registered resource resolves to the identical definition through the public lookup. Before: one failure out of310 (chapel only). After:310 PASS, exit0. Evidence: catalog-lookup-repair.json and before/after logs.
+
+The sweep had already run the previous266-check registry test when this correction was made. Production catalog and registry test are two additional files changed since source-start.json, beyond the three count-repair test files. Therefore retain the sweep result and this targeted correction as distinct evidence; do not claim the sweep alone covered one frozen final source revision. No production caller of by_id was found in scenes, scripts or autoload besides the catalog definition; normal Runtime builds its own registry from explicit paths.
+
+## Completed source sweep
+
+Runner session18695 exited0. All127 unique source suites passed with zero failures. Recomputed discovery matches executed paths exactly (no missing or unexpected suite). `completion.json`, `all-tests.json` and `source-end.json` retain the result. Five previously documented files differ from launch hashes: three count repairs plus catalog lookup and its regression test. The latter's final310-check run separately passes. This is combined regression evidence, not a single immutable-source full sweep. Export/PCK and Windows are not included. New paired restart-debug fixture/runner were prepared separately and were not part of this discovery list.
+
+After this successful sweep, started rendered `run_opening_restart_flow.py` into artifacts/opening-restart-debug-2026-09-29. Read its result.json and phase logs for completion; launch alone is not acceptance.

docs/plans/original-completion-2026-09-29/execution/CHAPEL_ROOM_PRESENTATION.md

@@ -0,0 +1,9 @@
+# Chapel room presentation
+
+Replaced the generic chapel table with code-native furnishings: a world-tree glass motif, altar with cloth and candles, and paired pews separated by a central aisle. Visitor anchors share the furniture layout, cap at8 visible people, reserve upper wall space for the altar, and adapt to canonical4x3 and rotated3x4 footprints. Suppressed the generic upper-wall worker counter in this room. Simulation position, service state and finances are untouched.
+
+Asset sourcing: inspected the existing Kenney Tiny Town/Tiny Dungeon package inventory and existing renderer conventions. Existing packs and character/environment sprites remain under their recorded CC0 licenses (assets/kenney/sources.json and package License.txt). New altar/window/pew geometry is authored in scripts/ui/pixel_tower_art.gd rather than imported bitmap media. No new external assets or rights were introduced. The palette icon still reuses an existing generic theme icon.
+
+Tests cover8 anchors and non-overlap at0.5/1/2/4 scale and rotated footprint, alongside existing room state/pixel behavior. Native gameplay captures the real worship visitors,20G revenue and Faith1 in chapel-art.png. This is an initial chapel visual, not completion of the original Lv1-3 asset set, all animation states, audio or Windows acceptance.
+
+Evidence directory: artifacts/facility-dimensions-2026-09-29, chapel-art-rooms.log, chapel-art-pixel.log, chapel-art-native.log, chapel-art.png. The first art capture reused chapel-gameplay.png, so the older normal-validation screenshot hash is historical; the current art evidence now has its own filename and the capture harness supports THE_TREE_CHAPEL_CAPTURE_PATH for future preservation.

docs/plans/original-completion-2026-09-29/execution/CLEANING_ACCESS_FOLLOWUP.md

@@ -0,0 +1,15 @@
+# 清掃の経路・表示追補
+
+2026-09-29。清掃先の最初の通行可能セルが孤立すると、別の入口が到達可能でも作業を開始できなかった。未割当の予約で到達可能な入口を選び直し、移動中の経路喪失時も同じ仕事の目的地を再評価するよう修正。到達可能な既存目的地は維持する。すべて孤立した場合は移動せず待機し、再接続後に再開する。汎用の行き詰まり救済による移動をこの待機には適用しない。
+
+保存検証では、清掃目的地が施設に接する正しい位置かという条件と、その時点で歩けるかという条件を分けた。経路喪失中の待機先は幾何的に妥当な位置を維持できる。作業中の床が通行不能になれば作業を中断する。承認された8分/25回復などの値は変更していない。
+
+清掃員室の営業画面を「清掃業務を有効にする」「顧客利用なし・清掃員の業務拠点」に変更し、停止時は途中作業も中断すると説明。料金のない施設を顧客受付として案内しない。
+
+証拠: `artifacts/cleaning-access-2026-09-29/targeted.json` の6スイートがPASS。経路6項目は実PathServiceと配置を限定したfixtureで、孤立入口/代替/全閉塞/保存対象位置/再接続/対象撤去を検証。通常Mainの建設・雇用・配置・清掃・中断・保存再開は82項目PASS。営業画面・通勤・snapshot ownershipも再試験。`source-hashes.json`に最終ソースを固定。
+
+実描画の追加結果は同ディレクトリ `native.log` と `cleaning-room-ui.png`。この再実行は同じ操作シナリオであり、独立した受入項目として重複加算しない。
+
+全体回帰は既存セッション59503を継続しており、再起動していない。実行中に本追補のソース変更が入ったため、`cleanliness-runtime-2026-09-29/source-start.json` と同一の固定ソースで全件通過した証拠にはしない。本追補後の関連再試験と、既存全体回帰の結果を別々に扱う。全体終了後に失敗を確認し、最終候補の全体確認・通しデバッグへ進む。
+
+なお経路fixtureだけでWindows実機や長期営業、すべての建設/撤去/勤務交代の組合せを受入済みとはしない。清掃専用モーション、満足度/汚染伝播、原本の他の残件は継続中。

docs/plans/original-completion-2026-09-29/execution/CLEANING_ANIMATION.md

@@ -0,0 +1,19 @@
+# 清掃アニメーションと実作業の一致
+
+P25 / B-12.3、B-13.2 の部分対応。清掃員の職種とWORKING状態だけでモップ姿勢を選ぶ表示を修正。実際のfacility_cleanタスクがWORKINGで、現地・依存元施設・移動状態等の作業条件を満たす場合だけ清掃姿勢を選ぶ。拠点の待機はidle、移動は既存の歩行表示を使う。
+
+既存PixelPeopleの独自描画モップ姿勢を利用し、外部素材の追加はない。保存形式・清掃の数値・課金には変更なし。
+
+通常画面を通す清掃テスト90チェックPASS（待機、移動、現地作業、保存復元、完了、中断を含む）。macOS実描画版は画像保存1件を加え91チェックPASS。停止中のアニメーションとシミュレーション分離を含むpixel_tower、room_presentation、staff_rest、staff_rescueの4スイートPASS。working.pngで実位置と清掃中0/8分の表示を確認した。
+
+証拠: artifacts/cleaning-animation-2026-09-29/。表示修正後の営業・決算・別プロセス再起動の通し再検証は同フォルダopening-restartで実行中。以前の132スイート合格は表示修正前の証拠であり、今回の全体回帰とは数えない。全P25、全原本、Windows実機の完了を意味しない。
+
+## 再起動検証で判明した清潔度の順序不整合
+
+opening-restartとrestart-diagnosisは再起動時の状態ダイジェスト比較で失敗。3日分の会計は一致したが、診断用に保存したwrite-gameplay.json/read-gameplay.jsonではfacility_cleanliness.facilitiesの最初の2施設だけが逆順だった。StringNameキーの既定ソートに依存していたため、清潔度スナップショットと清掃予約対象列挙をStringへの変換による明示的比較へ変更した。旧データの施設配列順は受け入れ、出力を正規順序へ揃える。schemaや数値の変更はない。
+
+生成ID32件と逆順保存入力の回帰を追加。清潔度モデル49チェック、Runtime、清掃経路、清掃UI90チェックの4スイートPASS。比較から清潔度や配列を除外せず、通しデバッグをrestart-fixedで再実行中。失敗ログも保持している。
+
+## 修正後の通し検証完了
+
+restart-fixedは両プロセス終了コード0、書込側80・読込側17の合計97チェックPASS。全ゲーム状態ダイジェスト、保存したJSON状態、3回決算の一致を確認。source-change.jsonは空で実行中のソース変更なし。修正前の失敗は隠さず保持した。全体回帰132件の証拠は前のソースに対するもので、今回は変更対象の関連試験と通し再検証を実施した。

docs/plans/original-completion-2026-09-29/execution/CLEANING_APPROVAL_RECHECK.md

@@ -0,0 +1,9 @@
+# 清掃承認値の現行実装再確認
+
+2026-09-29。清掃員室・清掃業務は回答済みの初期試験値を維持。施設定義は2×1・裏層、350G・資材4・60分、清掃員1人必須／上限2人、顧客0・料金0・維持費2G/日。ポリシーは初期100・上限100、75以下で予約、現地8分、完了時25回復。未定義の汚れ量は補完していない。
+
+現行ソースで再実行: 清掃モデル49、Runtime29、経路6、通常UI清掃90、合計174チェック、失敗0。通常UI清掃試験は建設・雇用・配置・実到着・8分作業・保存再現・最終作業前の閉店／停電中断を含む。
+
+macOS実描画の通し検証は書込側80・別プロセス再読込側17、合計97チェックPASS、双方終了コード0。書込62.34秒、読込47.89秒。ゲーム状態JSON一致、試験中ソース変更なし。2日目朝の画面で日本語帳簿とドット施設・人物を確認。
+
+証拠: `artifacts/cleaning-approved-recheck-2026-09-29/`。今回の追加機能実装ではなく、承認値の反映済み確認と現行コードの再検証。清掃固有試験と開業・再起動試験は別シナリオ。原本全項目、長期プレイ、Windows実機、性能予算の完了を意味しない。

docs/plans/original-completion-2026-09-29/execution/CLEANING_APPROVED_FOUNDATION.md

@@ -0,0 +1,31 @@
+# 清掃員室・清掃業務の承認済み初期試験値と実装状況
+
+2026-09-29。ユーザー回答 `call_6ktCNjGSwiR0e3x5HukIZKfA` の項目0・1はいずれも「この初期値で試験・調整する」。再承認は不要。原本未指定の数値を原本由来として扱わず、試験用の承認値として管理する。
+
+## 承認内容
+
+清掃員室: 原本指定2×1・裏層。建築350G、資材4、工期60分、清掃員1人必須・配置上限2人、顧客同時利用0人、利用料なし、維持費2G/日。
+
+清掃: 清潔度0〜100・初期100。既存の `cleanliness_decay_per_service` を利用完了時に適用。75以下で予約。現地で8分作業し、完了時25回復、上限100。未定義施設の汚れ量は補完しない。
+
+## 今回の成果
+
+- `data/facilities/expansion/cleaning_room.tres`: 上記初期値の施設定義。通常カタログ・建設パレットへはまだ登録していない。
+- `data/environment/cleaning_policy.json` と `scripts/environment/facility_cleaning_policy.gd`: 承認値と厳格な読込・検証。欠損、未知版、非整数、不正な境界は既存値を変更せず拒否。
+- `scripts/environment/facility_cleanliness_service.gd`: 利用・清掃完了IDによる重複反映防止、上下限、順序を保持する履歴、保存復元、破損時の原子性、施設削除。
+- `tests/environment/test_facility_cleanliness.gd`: 47 checks、0 failures。Godot4.7.2、macOS headless。`Makefile` test-s2に登録。
+- 証拠: `artifacts/cleanliness-foundation-2026-09-29/approved-policy.log`。初期の新クラスキャッシュ未更新による失敗ログも保存。editor import後にモデル試験が通過し、今回ポリシー検証追加後の47項目も通過。
+
+## 次の接続と完了条件（未実装）
+
+1. Runtimeの施設登録・利用完了・撤去と清潔度を接続。建設・撤去・営業トランザクション失敗時に清潔度も巻き戻す。単体モデルを通常動作済みとは扱わない。
+2. Runtime保存版12を追加し、天候版11の条件を独立定数へ切り出す。旧版は既存施設を100で初期化。新版欠損・孤立施設・不正履歴を拒否。旧版試験データから新項目を除く。
+3. 稼働中の清掃員室に配置された清掃員、実到着、現地8分作業、25回復を接続。閾値75、重複予約、経路なし、勤務交代、休止、停電、撤去、途中保存を検証。既存デモの清掃タスクを本機能の完了と取り違えない。
+4. 通常カタログ・パレット、施設詳細の清潔度と清掃状況、ドット表示を接続。通常UIの建設→雇用→配置→清掃→保存再開を実証。
+5. 関連回帰と通しデバッグ、現在ビルドの配布・Windows実機確認。全原本実装の認定は引き続き未達。
+
+今回の47項目は基礎モデル・定義・設定の検証であり、Runtime統合、清掃員室の通常営業、描画、Windowsの合格ではない。P07/P09/P12/P16/P24は完了に変更しない。
+
+## 接続後の更新
+
+通常ゲーム接続が進んだため、現在の成果と残件は `CLEANING_RUNTIME_INTEGRATION.md` を参照。上記の「未実装」は基礎モデル段階の記録として保持する。

docs/plans/original-completion-2026-09-29/execution/CLEANING_REGRESSION_RECHECK.md

@@ -0,0 +1,21 @@
+# 清掃統合後の全体回帰と現行ソース再確認
+
+全体回帰セッション59503は終了コード1で完了。131スイートのうち130がPASS、`tests/ui/test_main_dashboard.gd` が139チェック中2失敗。建設パレットとアイコン付きボタンの期待値が22のまま残っていたため、通常登録済み23施設に合わせて修正した。従業員候補の22件という別の期待値は維持。
+
+途中で経路・清掃員室表示の修正が入ったため、全体回帰が同一ソースで実行されたとは認定しない。`artifacts/cleaning-regression-final-2026-09-29/recheck.py` が、最後の共通実装変更より後にログを新規作成して開始した105スイートの合格を保持し、それ以前の25件・失敗した画面試験・新規経路試験の計27件を現行ソースで再実行している。テスト自身の変更は当該エントリを再実行対象にし、Makefileの追加は直接起動されるGodotスイートの実装変更とは区別。
+
+再確認の実行ハンドル26042。`selection.json`に根拠、`rechecks.json`に進捗、`source-start.json`にソース識別を記録。終了時は全132件の網羅性・失敗0・再確認中の全対象ソース不変を `verification.json` で確認する。現時点は実行中で、全132件PASSとはまだ言わない。
+
+この確認が通ってから `tools/run_opening_restart_flow.py --rendered` を新しい証拠ディレクトリで実行し、3回決算とプロセスを終了した後の再起動・ロード・継続の一致を検証する。原本の全実装やWindows実機の完了を意味しない。
+
+## 再確認の完了
+
+27件の再実行が全件PASSで終了コード0。保持105件と合わせて132/132件を網羅し、失敗0・未実行0。`verification.json`で再確認開始/終了のソースハッシュ一致を確認した。
+
+実描画の通しデバッグを `artifacts/cleaning-opening-restart-2026-09-29` へ開始（実行ハンドル19187）。このシナリオは通常開業・3回決算・別プロセスでの再読込を対象とし、清掃員の派遣固有シナリオは別の清掃UI試験で検証している。完了結果は後記。
+
+## 実描画の通しデバッグ結果
+
+macOS / Godot 4.7.2、実描画で書込側80・再起動側17の合計97チェックPASS、両プロセス終了コード0。通常開業から3回決算し、2日目08:00の保存を別プロセスで読み込んだ継続結果が一致。ゲーム状態比較では計測時間を含むdomain_eventsだけを除外し、他の状態・ID・乱数を比較した。
+
+各日損益は-64G、+346G、+346G。3決算すべて帳簿照合一致。`source-change.json`は空配列で実行中の対象ソース変更なし。再起動後3回目決算の画像も確認し、日本語帳簿・施設名・金額の表示を確認した。証拠は`artifacts/cleaning-opening-restart-2026-09-29/`のresult.json、write.log、read.log、expected.json、3画像。Windowsネイティブ、全原本、性能予算、長期プレイの合格を示すものではない。

docs/plans/original-completion-2026-09-29/execution/CLEANING_RUNTIME_INTEGRATION.md

@@ -0,0 +1,40 @@
+# 清掃の通常ゲーム接続（2026-09-29）
+
+作業対象: ローカル制作コピー。承認値は `CLEANING_APPROVED_FOUNDATION.md` を継承。P03/P07/P09/P12/P16/P24の増分実装であり、各パッケージや全原本の完了判定ではない。
+
+## 接続内容
+
+- 清掃員室を通常カタログ・建設パレットへ登録。2×1裏層、350G・資材4・60分、清掃員1〜2人、顧客0人、維持費2G/日。通常登録施設は22→23。
+- 通常建設完了で清潔度100を作成。定義済みの利用後汚れ量を成功したサービス精算に含める。未定義の汚れ量は追加しない。撤去で当該状態・履歴と未完了の清掃作業を除去。
+- 75以下で `facility_clean` タスクを一施設一件予約。稼働中の清掃員室へ実出勤した清掃員を既存Staff/Shift/Path/Taskで派遣し、到着後8分で25回復。移動中・未完了作業には回復なし。完成IDで二重反映を防止。
+- 出張清掃中の職員は清掃員室の業務従事者として稼働を維持する。一般の固定勤務地職員の在席判定は変えない。閉鎖・停電で作業を取り消し、部分回復を与えず、汚れた施設は待機予約へ戻す。
+- 清掃の時間は通常のゲーム時間で進む。ユーザー向け汎用タスクコマンドで生成や進捗の早送りはできない。
+- Runtime保存版12。天候の導入版11を独立定数として維持。旧版は既存施設を100から開始し、過去の利用から汚れを推測しない。新版では欠落・孤立した施設や存在しない完了履歴を拒否。清掃中の人員・仕事・位置、完成後の効果履歴を復元。
+- 建設・撤去・Operations/Event/Authority/Defenseの施設を含む巻き戻しトークンへ清潔度を含める。
+- 営業画面に清潔度と清掃待ち・移動・作業分数を表示。清掃員室には既存パレットを用いた自作コード描画の棚・モップ・バケツを追加。アイコンは既存テーマのF12を再利用し、新しい外部素材は取り込んでいない。
+
+## 証拠と範囲
+
+`artifacts/cleanliness-runtime-2026-09-29/`:
+
+- `focused.log`: Runtime cleanliness 29項目PASS。通常受付建設・利用・汚れ・再開・v11移行・破損拒否・巻き戻し・撤去。清掃員派遣接続前の段階試験。
+- `targeted.json`: 関連18スイートPASS。天候、旧版移行、交通、維持費、決算、礼拝、snapshot ownership、営業画面。これも派遣接続前の段階試験で、最終ソースの全体合格とは区別。
+- `gameplay-boundaries.log`: 操作を含む81項目PASS。通常Main建設・雇用・配置を使用。汚れを直接書き換えず、25件の実サービス完了を発生させた。利用要求の投入は制御された財布/要求fixtureであり、25人全員の自然入館を検証したものではない。通常客の入館も並行して動作し、清掃後は再び汚れる。
+- `gameplay-native.log`: macOS OpenGL実描画、同81項目＋画像保存1項目＝82項目PASS。1280×720の営業画面で清潔度97を視認確認（清掃後に通常の客が再利用）。
+- `capture-extra.log`: 同じ操作シナリオを実描画で再実行、81項目PASS。`cleaning-working.png`に清潔度75・清掃中0/8分、`cleaning-room.png`に裏層の室内を確認。重複実行を独立受入数として加算しない。
+- `full-regression/`: 最終変更後の全ソース回帰を実行中。実行ハンドル59503。完了前に全件PASSとしない。
+- `source-start.json`: 全体回帰開始時の対象ソースSHA-256。
+
+最初のUI試験の2失敗は、清掃後の新規利用による汚れを考慮せず100維持を期待したため。回復の完了記録が一件だけ存在することと、UIがその時点の実値を表示することへ受入条件を修正。ゲーム内の汚れ量は変更していない。
+
+## 継続する確認・調整
+
+- 全体回帰の完了確認、失敗修正、現在ソース識別、3営業日・再起動の通しデバッグ。
+- 清掃員室に残る汎用営業文言「受付」を業務に合わせる。
+- 複数入口のうち一部が孤立する配置、途中の経路喪失、休止・勤務交代・対象撤去・再開の追加境界試験。現在の予約先は安定順の最初の通行可能セルであり、別の入口だけが到達可能なケースの再選択を改善する。
+- 人物の清掃専用動作、全レベル・表裏の完成素材、清潔度から満足度/客の汚染伝播への原本接続は未完了。
+- 現行Windows配布物は今回の変更を含まない。今回の実描画はmacOSであり、Windows実機確認の代替ではない。
+
+## 経路・文言の追補
+
+複数入口の再選択と清掃員室専用文言を実装。`CLEANING_ACCESS_FOLLOWUP.md`を参照。全体回帰の途中変更があるため、開始時SHA固定の全件合格とは扱わない。

docs/plans/original-completion-2026-09-29/execution/CLEANING_WINDOWS_PACKAGE.md

@@ -0,0 +1,25 @@
+# 清掃業務反映 Windows 開発確認版 — 2026-09-29
+
+制作元: `/Users/korizatou114/Projects/とりにく工房ゲーム制作部`。
+配布: `build/windows/TheTree-Windows-cleaning-2026-09-29.zip`。
+Godot 4.7.2、Windows x86_64 PE32+ EXEと外部PCK。通常施設23種。
+
+承認された清掃員室・清掃業務の初期値、移動・現地作業・中断・保存復元・清潔度表示を配布用データへ反映。既存の礼拝堂・アンリも含む。フィーネとアメリアの効果は含むが通常加入は未接続。
+
+## 配布物に対する検証
+
+- 空の一時ディレクトリからPCKを読み、ソース側へのフォールバックを排除。
+- `tools/verify_exported_opening.py`: 起動・建設・ディスク保存復元28チェックPASS。
+- `tests/ui/test_cleaning_gameplay.gd`を外部ドライバーとして使用: 清掃91チェックPASS（元90に隔離確認1を追加）。
+- 同じドライバーのmacOS描画あり実行: 92チェックPASS（スクリーンショット保存1を追加）。画面の日本語、清潔度、清掃業務の専用操作を目視確認。
+- 清掃試験は作業途中のスナップショット復元と再実行一致、閉店・停電時の中断、二重完了防止を含む。
+- EXE形式確認、ZIP CRC、同梱ファイルSHA256、ビルド前後の追跡ソース変更なしを確認。
+- エンジンバージョンとKenney素材が前回配布と同じためライセンスを継承し、素材出典ファイルのハッシュ一致を確認。
+
+証拠: `artifacts/cleaning-package-2026-09-29/` の export.log、packed-opening.log、packed-cleaning.log、packed-cleaning-rendered.log、packed-cleaning.png、外部ドライバー、source-start/end.json、build-validation.json。
+
+## 検証範囲の限界
+
+この版のWindows実機操作は未実施。macOSで同じPCKを検証した結果をWindowsネイティブ検証と扱わない。
+ソース側137スイートの検証内訳と描画あり通し97チェックは CURRENT_FULL_REGRESSION.md を参照し、今回のPCK検証とは区別する。
+原本30施設のうち通常実装16、定義のみ1、未対応13等が残る。原本全実装・長期プレイ・性能受入およびP29完了とは判定しない。

docs/plans/original-completion-2026-09-29/execution/COMPACT_OPERATIONS_HUD.md

@@ -0,0 +1,15 @@
+# Compact operations HUD projection
+
+Measured the main dashboard refresh: approximately9.75ms, including3.64ms spent obtaining a complete OperationsCoordinator snapshot for a short status label. Added get_dashboard_summary on the coordinator and get_operations_dashboard_report on Runtime. They return only live flags, action points, total arrears, terminal/loss/legacy status and the latest close day/profit. UI uses this compact API with old-report fallback for fixtures. Full reports and save snapshots are unchanged. Returned dictionaries/arrays are newly allocated and contain no mutable references to stored summaries.
+
+Dashboard136 checks PASS. Same production fixture: operations text average3635us before /11.75us after; full x1 average34.410ms /30.374ms. x3 P95124.341ms /122.392ms, still above12ms. No claim of budget compliance or GPU/Windows performance.
+
+Opening/save/replay test completed with58 checks,0 failures,exit0 (compact-operations-opening.log), including10 new projection-equivalence and defensive-copy checks. Evidence: compact-operations-ui.log, production-ui-costs.json, production-compact-operations.json.
+
+## Pause/speed projection follow-up
+
+The dashboard still fetched the full operations snapshot inside `_update_pause_and_speed`. Added `deferred_runtime_minute` to the compact API and switched this consumer to it, retaining fallback for older fixtures. No simulation or save contract changed.
+
+Targeted dashboard139 checks PASS,exit0: includes injected deferred-state warning/retry labels and clear-to-resume checks. These validate projection/display, not a complete fault-recovery scenario. Production diagnostic (`production-compact-pause.json`) reports x1 average22.057ms, x3 P9575.145ms, dashboard refresh2.009ms. Compared with the preceding compact-text run30.374ms/122.392ms, the measured update is faster; both budgets remain failed. Runs are headless, small fixture, no GPU/Windows acceptance. Guide subprofile (`production-guide-costs.json`) measured refresh1.115ms, so it did not explain the whole previous dashboard cost.
+
+Latest initial-day/save/replay test completed with59 checks,0 failures,exit0 (`compact-pause-opening.log`), including the added deferred-field equivalence check. Previous58-check pass applies to the preceding increment.

docs/plans/original-completion-2026-09-29/execution/COMPOSED_INFRASTRUCTURE_VALIDATION.md

@@ -0,0 +1,11 @@
+# Reuse composed infrastructure validation without skipping live guards
+
+Current-scene measurement identified snapshot publication and infrastructure validation as major synchronous costs. A trial homogeneous-key shortcut in Operations canonical-collision inspection passed its254 checks but produced no clear improvement (snapshot component2429.85→2416.4us, whole snapshot6656.8→7311.85us). That trial was fully reverted; the retained Operations source is byte-identical to the before copy.
+
+Retained change: Runtime infrastructure crosslink validation no longer independently repeats Spatial and RouteAdapter invariant checks when the active FacilityInfrastructureProjector already validates those exact bound services. Added a read-only identity-binding query. Different bindings and quarantine retain the independent source/adapter checks; all projector-owned history validation, live graph/managed namespace checks, excavation, route-cell and construction crosslinks remain. No revision-only cache, validation limit removal, update-rate change or snapshot-format change was introduced.
+
+Additional integration cases use counted dependencies to verify one source/adapter audit, exact object binding, raw source/adapter corruption rejection, quarantine fallback and different-binding fallback. Current targeted results: infrastructure180, projector192, ordinary opening/SaveLoad/replay63 checks PASS, total435. Existing rollback/callback/strict restore cases remain included in the two infrastructure suites.
+
+Single paired small-scene measurement: construction phase2515.5→1877.025us (~25% lower), x1 average13309.8→12849.475us (~3.5% lower), x3 P9548441→46529us (~3.9% lower). Seed424242,40 samples per speed, macOS Godot4.7.2 headless, deferred UI refresh included, autosave disabled. These are not repeated statistical estimates or full-load/Windows results. Budgets4ms/12ms remain FAILED; snapshot publication remains the larger remaining cost.
+
+Evidence: artifacts/runtime-profile-2026-09-29/validation.json and referenced profiles/logs. The chapel/Anri Windows ZIP was produced before this optimization and has not been rebuilt in this step. Original completion and P28 acceptance remain open.

docs/plans/original-completion-2026-09-29/execution/CURRENT_FACILITY_AUDIT.md

@@ -0,0 +1,54 @@
+# 原本30施設・現行登録監査
+
+通常登録 16、定義のみ 1、対応定義なし 13。通常登録全23件のうち原本30施設以外は7件。
+
+登録状態と読込済み定義の監査。実営業・保存移行・完成資産・Windows・全要件の受入完了は証明しない。
+
+対応定義の寸法・層の不一致: 0件。人数専用上限が未設定: 13件。capacityから人数値を転記していない。高層・背面・騒音・サービス条件は別途受入が必要。
+
+| 原本 | 施設 | ID | 登録 | 寸法 / 層 / ゾーン | 顧客人数上限 |
+|---|---|---|---|---|---|
+| 10.1 | 一般客室 | standard_room | 通常登録・パレット掲載 | 2×1 / FRONT / ANY | 未設定 |
+| 10.1 | 上級客室 | premium_room | 通常登録・パレット掲載 | 4×1 / FRONT / ANY | 2 |
+| 10.1 | VIPスイート | — | 対応定義なし | 未定義 | 未設定 |
+| 10.1 | ドミトリー | — | 対応定義なし | 未定義 | 未設定 |
+| 10.2 | 大衆食堂 | cafeteria | 通常登録・パレット掲載 | 4×2 / FRONT / ANY | 未設定 |
+| 10.2 | レストラン | — | 対応定義なし | 未定義 | 未設定 |
+| 10.2 | 酒場 | tavern | 通常登録・パレット掲載 | 4×2 / FRONT / ANY | 未設定 |
+| 10.2 | 屋台 | — | 対応定義なし | 未定義 | 未設定 |
+| 10.3 | 大浴場 | public_bath | 通常登録・パレット掲載 | 6×2 / FRONT / ANY | 未設定 |
+| 10.3 | カジノ | — | 対応定義なし | 未定義 | 未設定 |
+| 10.3 | 闘技場 | — | 対応定義なし | 未定義 | 未設定 |
+| 10.3 | 礼拝堂 | chapel | 通常登録・パレット掲載 | 4×3 / FRONT / ANY | 8 |
+| 10.4 | 風俗個室 | adult_private_room | 通常登録・パレット掲載 | 2×1 / FRONT / UNDERGROUND | 未設定 |
+| 10.4 | 高級ソープ | — | 対応定義なし | 未定義 | 未設定 |
+| 10.4 | SM拷問室 | — | 対応定義なし | 未定義 | 未設定 |
+| 10.4 | 闇市場 | black_market | 定義のみ | 4×2 / FRONT / UNDERGROUND | 未設定 |
+| 10.5 | 厨房 | kitchen | 通常登録・パレット掲載 | 4×2 / BACK / ANY | 未設定 |
+| 10.5 | 倉庫 | warehouse | 通常登録・パレット掲載 | 4×2 / BACK / ANY | 未設定 |
+| 10.5 | 待機室 | staff_waiting_room | 通常登録・パレット掲載 | 4×2 / BACK / ANY | 未設定 |
+| 10.5 | 従業員寮 | staff_dormitory | 通常登録・パレット掲載 | 2×1 / BACK / ANY | 0 |
+| 10.5 | 警備員詰所 | security_station | 通常登録・パレット掲載 | 2×2 / BACK / ANY | 未設定 |
+| 10.5 | 清掃員室 | cleaning_room | 通常登録・パレット掲載 | 2×1 / BACK / ANY | 0 |
+| 10.5 | 医務室 | infirmary | 通常登録・パレット掲載 | 4×2 / BACK / ANY | 未設定 |
+| 10.6 | 覗き部屋 | — | 対応定義なし | 未定義 | 未設定 |
+| 10.6 | 地下牢 | — | 対応定義なし | 未定義 | 未設定 |
+| 10.6 | マナ炉 | — | 対応定義なし | 未定義 | 未設定 |
+| 10.7 | 蔓の昇降機 | guest_elevator | 通常登録・パレット掲載 | 2×2 / FRONT / ANY | 未設定 |
+| 10.7 | 業務用EV | service_elevator | 通常登録・パレット掲載 | 3×2 / BACK / ANY | 未設定 |
+| 10.7 | ワープ | — | 対応定義なし | 未定義 | 未設定 |
+| 10.7 | 魔法砲台 | — | 対応定義なし | 未定義 | 未設定 |
+
+## 未接続施設
+
+対応定義なし: VIPスイート、ドミトリー、レストラン、屋台、カジノ、闘技場、高級ソープ、SM拷問室、覗き部屋、地下牢、マナ炉、ワープ、魔法砲台。
+
+定義のみ: 闇市場。
+
+## 次の受入
+
+未定義施設は寸法・層だけでなく経済値、人数、業務、通常操作、保存を接続する。登録済み施設は未設定人数とサービス属性、営業時間・停止・経路・客/職員行動を個別検証する。施設追加のたびにこの監査を再実行する。
+
+再現: `python3 tools/run_facility_audit.py --godot /opt/homebrew/bin/godot --output artifacts/facility-audit-current-2026-09-29`。原本SHA・入力ソースSHA・取得中の変更なしは同ディレクトリのsource-start/end/change.jsonを参照。
+
+前回の15施設登録時点の記録は`FACILITY_AUDIT_BEFORE_CLEANING.md`へ保全。清掃員室の登録と一般客室・上級客室・従業員寮のゾーン修正を現行定義で再取得した。全施設一覧への入口と定義値の監査であり、登録数を完成数とは扱わない。

docs/plans/original-completion-2026-09-29/execution/CURRENT_FULL_LOAD.md

@@ -0,0 +1,15 @@
+# 現行ソースの指定規模・部品統合負荷試験
+
+更新注記: GUIDE_ASSIGNMENT_SCAN.mdの受付担当検索の軽量化は本記録より後の変更。本記録の全回帰・配布・負荷結果にこの変更を含めない。
+
+2026-09-29。PERF-MVP-001 full tierをmacOS/Apple M4、Godot4.7.2、headlessで実行。検証済み軽量化版ソースから差分0。終了コード0、24項目PASS、スキップ0。
+
+実初期値: 20,000マス、200客、50職員、150施設、行列500、物流200、選択待ちイベント50。1,440分（x3、480フレーム）を完走。物流200件完了、在庫非負、貸借一致、部品スナップショット復元を確認。行列最大待ち46分、物流最大待ち4分。
+
+x3平均6.948ms、P95 7.419ms（基準12ms）、最大22.204ms（主スレッド停滞基準50ms）。経路P95 0.037ms（基準2ms、5760回中の末尾512件の窓）。全シミュレーション3.365秒。
+
+限界: public APIで各部品を組み合わせた専用ハーネスであり、本番SimulationRuntime・スナップショット公開・UI更新・描画を測定しない。物流更新はハーネスが担う。初期の行列と物流は処理後補充せず、終了時は双方0件。イベントは選択待ち50件。このPASSを継続満員・実営業・GPU・Windowsの合格へ拡張しない。x1、全体保存/読込所要時間、長期プレイもこの試験の対象外。
+
+現行本番デモではx1平均9.372ms、x3 P95 32.728msで目標未達（SNAPSHOT_CALL_REUSE.md）。異なる試験の数値を直接の改善率として比較しない。次の性能作業は本番Runtimeの統合更新・状態公開・UIコストを対象とし、本番規模での持続負荷受入は別途必要。
+
+証拠: artifacts/full-load-current-2026-09-29/{full.log,report.json,verification.json}。実行: godot --headless --path . --script res://tests/performance/test_perf_mvp_001.gd -- --full。

docs/plans/original-completion-2026-09-29/execution/CURRENT_FULL_REGRESSION.md

@@ -0,0 +1,13 @@
+# 防衛画面表示更新・全回帰と通し検証
+
+2026-09-30。148/148スイートPASS、657.68秒。欠落・余分・重複・失敗・実行中ソース変更0。新Event防衛186項目、表示/選択105項目を含む。
+
+macOS実描画の新規開業・3回決算・保存・終了・別プロセス再起動は83＋20＝103項目PASS（48.06秒/32.18秒）。4日目00:00、所持金4,228G、帳簿一致、営業利益＋346Gを実画像で確認した。
+
+同じ凍結ソースの関連描画5実行453項目PASS。全回帰の同じソース実ログ5件720項目を参照し、新実行扱いしない。Event処理で生成した襲撃のviewport操作・戦闘途中保存・別プロセス再開は34＋32＝66項目PASS。状態JSONとtyped digest一致、全DomainEvent/採番/乱数を保全する。Save/Loadの2種類のI/O観測type/payloadのみ明示normalizationする。
+
+防衛画面の実OptionButtonと概要には事件名と保存された元の発生日/時刻が表示され、完全IDはmetadataと選択に保持される。write/readの途中・終了の4実観測とnonce・state比較が合格、human_readable_defense_labels=true。実画像で520pxの窓幅と内部ID非表示を確認した。初回は新しい通しdriverの4bool変数の型推論でコンパイル失敗し、型注釈だけを直して再試験した。本番変更は0、失敗ログはfirst-parse-failure/へ保全している。
+
+現在ソースと同じWindows版の隔離export・18PCK実行2,926項目・ZIP CRC/ファイルSHA検証がPASS。PCK描画はmacOSで実施。Windowsネイティブ操作、原本全実装、通常脅威producer、性能予算、高負荷/長期プレイは未完了。
+
+証拠: artifacts/full-regression-after-event-defense-labels-2026-09-30/、artifacts/event-defense-labels-related-2026-09-30/、artifacts/event-defense-labels-restart-2026-09-30/。source-end SHA256: 0395e515c1cb090408c11c7235b36f8b2015bf350fe412b2d894b286b249ef6c。

docs/plans/original-completion-2026-09-29/execution/CURRENT_PERFORMANCE.md

@@ -0,0 +1,9 @@
+# Current performance regression
+
+make test-perf and make test-perf-full both exited0 with no script errors. Path/camera compatibility282 checks PASS; digest compatibility/performance71 checks PASS; smoke24 and full24 fixture checks PASS.
+
+Full fixture: 20,000 cells, 200 guests, 50 staff, 150 facilities, 500 queued customers, 200 logistics requests and 50 active events, simulated1440 minutes at x3. Simulation x3 P95=7.845ms (budget12ms), path query P95=0.036ms (budget2ms), maximum measured main-thread batch22.037ms (budget50ms). No checks skipped.
+
+This harness composes public domain APIs and orchestrates logistics itself. It does not measure the production SimulationRuntime tick, rendered UI, GPU frame time, Windows, natural campaign play or long-term balance. Geometry helper and digest microbenchmarks are likewise not frame-rate guarantees. These passing measurements do not close P28.
+
+Evidence: artifacts/facility-dimensions-2026-09-29/current-performance-validation.json with host, full reports and log hashes. No production code changed in this measurement increment.

docs/plans/original-completion-2026-09-29/execution/CURRENT_WINDOWS_PACKAGE.md

@@ -0,0 +1,11 @@
+# 防衛画面表示更新・Windows開発確認版
+
+2026-09-30。build/windows/TheTree-Windows-event-defense-labels-2026-09-30.zip を作成した。Godot 4.7.2・debug export・Windows x86_64 PE32+。Runtime13、設定済みイベントからの防衛準備生成、事件名・元の発生日/時刻表示、完全IDによる操作と保存を含む。
+
+ZIP: 73,203,090 bytes、SHA256 2e22d793d113fa3f2eba4839d6812ec69f9762bdfe86c8804b943f79f4b1bad4。PCK SHA256 acd46e235282212392c99db43851285cea33afd1912b960ef92eec796c4616d8。ZIP CRC・全同梱ファイルSHA・5ライセンス/出典・マニフェスト・ソース変更0を検証した。
+
+ソース148/148 PASS、開業・3決算・保存・別process再起動103、関連実描画453、イベント防衛保存再開66項目PASS。同梱PCKだけを読む隔離環境の18実行2,926項目PASS（headless2,468、macOS実描画458）。全18実行が同一PCK SHA、4枚captureを検証し、防衛画面と自動保存復旧画像を目視した。ソースの851実行入力を普通copyし、本体のeditor importなしで隔離exportした。import/exportでcopy・本体ソースの変更0。
+
+Windowsネイティブ操作は未確認。通常営業から盗賊・暴動・借入滞納・摘発を自動生成するproducer、原本未指定値の決定、全施設・人物・物語・資産、性能予算・長期プレイは未完了。開発確認版であり、全原本受入や最終リリースとは扱わない。
+
+証拠: artifacts/windows-event-defense-labels-release-prep-2026-09-30/。表示修正前のsealed event-defense世代準備は実行せず保全した。旧Runtime12 ZIPも保全している。

docs/plans/original-completion-2026-09-29/execution/DASHBOARD_REFRESH_COALESCING.md

@@ -0,0 +1,9 @@
+# Dashboard refresh coalescing
+
+Main scene snapshot notifications now schedule one deferred dashboard refresh per batch rather than rebuilding the same dashboard for every simulated minute before rendering. Snapshot publication and simulation still run each tick. Elevator pending-command synchronization, pause/speed status and daily-close detection remain synchronous. Explicit user action refreshes remain immediate. Existing UI assertions passed without timing changes.
+
+A counted main-scene subclass verifies three minutes still advance, three publications result in one deferred refresh, no empty duplicate refresh, the next frame refreshes again, display work cannot mutate the snapshot, and checkpoint replay remains identical: 10 checks PASS. Registered in make test-ui after it ran separately. The existing full make test-ui passed 992 direct checks plus 37 fresh-process upkeep checks (exit 0), including first operating day and daily-close UI.
+
+The production diagnostic now flushes pending dashboard work INSIDE each timed batch. This prevents deferred work from being hidden outside measurement. Previous retained key-budget-after baseline versus this run: x1 average 13487.4 -> 13774.475 us (no improvement demonstrated); x3 P95 51750 -> 43334 us (about 16 percent lower in this pair). Small scenario, seed 424242, 40 samples per speed, macOS Godot 4.7.2 headless. This excludes GPU rendering, is a single comparison, and is not Windows or full-load acceptance. Both production budgets still FAIL.
+
+Evidence in artifacts/facility-dimensions-2026-09-29: dashboard-coalescing-ui.log, dashboard-coalescing-test.log, dashboard-coalescing-profile.json, dashboard-coalescing-validation.json, and copied dashboard-coalescing-upkeep-* logs. Full original completion remains unproven.

docs/plans/original-completion-2026-09-29/execution/DEFENSE_CLOCK.md

@@ -0,0 +1,13 @@
+# 防衛画面・通常時計による攻防
+
+2026-09-30。本番の防衛画面と ACTIVE 攻防の自動進行を接続した。新しい敵・戦闘間隔・準備締切を確定せず、既存レイドの保存済み round_minutes と取引境界を使用する。準備と次波開始は既存の明示操作を維持。
+
+通常管理の防衛ボタンと警戒欄から参加者、対象施設、撤退方針、開始、次波、撤退を操作できる。選択した incident と画面の開閉を手動/自動保存へ記録する。ロード前の確認をロード後の別 queue へ適用しない。無料の敵消去となる準備取消ボタンはレビューで削除した。
+
+通常時計の防衛 phase は due raid を安定したID順に1回ずつ解決する。手動の実取引失敗を同分の自動成功で隠さず、履歴再送だけでは正当な due round を抑止しない。明示IDを持つ旧有効セーブとの採番衝突を避け、ID空間の枯渇・技能費用・RNG・施設/職員結果の失敗時に巻き戻す。自動失敗では時計を停止し、同分に再試行しない。成功 restore では一時実行 guard を消去する。
+
+初回の新自動周期試験188項目PASS、既存Runtime防衛162項目PASS。最新関連のheadless 1,703項目（同じ固定ソースの全回帰内で再実行した自動周期188項目を含む）と実描画5実行403項目PASS、実行中の入力差分0。証拠は `artifacts/defense-autonomy-2026-09-30/`。初回自動周期ログ後の変更は試験説明コメントだけで、最新全回帰で再実行する。独立静的レビューは `artifacts/defense-autonomy-independent-review-2026-09-30/`。
+
+全回帰146/146スイートPASS、全合格後の開業・3回決算・別プロセス再開103項目PASS。さらに戦闘途中の保存から別プロセスで同じ攻防・損傷・資金・乱数・IDへ到達する描画通し試験19＋19＝38項目PASS。スクロールとviewport入力で通常防衛操作を確認した。同じソースのWindows PCKも16実行2,559項目PASS、ZIP生成と全同梱ファイルSHA検証が完了。Windows実機は未確認。
+
+P21全体は未完了。脅威は試験fixtureで生成し、通常営業からの盗賊/暴動/銀行滞納発生、実敵コンテンツ、実技能/UI、魔法砲台、開始演出は未接続。原本全実装、同一Windows実機、性能予算、長期プレイを合格とは扱わない。

docs/plans/original-completion-2026-09-29/execution/DEFENSE_HUD.md

@@ -0,0 +1,21 @@
+# 防衛状態のタワー画面表示
+
+2026-09-29。P21/P24の警告表示を接続。DefenseServiceの現在状態から準備中・戦闘中・次波待ちを集計し、上部警戒欄へ襲撃件数、運営画面へ状態別件数を表示する。準備中も従業員配置がロックされるため集計に含める。終了済みの履歴は進行中件数に含めない。ツールチップで配属制限を説明する。
+
+集計は戦闘履歴・参加者の全コピーを作らず、状態ごとの件数だけを返す。保存形式や襲撃発生条件、戦闘数値は変更なし。Runtimeの状態公開を受け、取消と保存復元でも表示を更新する。
+
+関連試験: 防衛507、Runtime防衛135、ダッシュボード149、macOS実描画150チェックPASS、全プロセス終了コード0。実描画は同じUIシナリオの再試験＋画像保存確認。準備中の表示、取消、復元、古いツールチップ解除、次波待ちと戦闘の区別、終結後除外、読み取りで原本状態を変更しないことを検証。1440×810の画像で上部・運営画面の日本語が収まることを目視。
+
+証拠: artifacts/defense-hud-2026-09-29/。preparing.png、ログ、targeted-verification.json。
+
+未完: 通常営業からの襲撃発生、準備・戦闘操作UI、借入滞納との接続、砲台と能動スキル、Windows実機。今回のUI試験はRuntimeコマンドで脅威を用意しており、通常営業での発生は証明しない。前回140全回帰・配布ZIPは今回の表示追加前のソースを対象とする。
+
+## 全回帰で検出した配置操作への影響と修正
+
+初回全回帰は140スイート中139PASS・1FAIL。従業員UIの防衛取消後の再ドラッグが2ケース失敗したため、通し検証は実行しなかった。失敗ログはartifacts/full-regression-after-defense-hud-2026-09-29/に保存。
+
+襲撃の開始/終了で運営サマリーの行数を増減させると、その下の従業員ボタンが移動し、次のドラッグ開始位置が変わっていた。防衛サマリーを0件時も常設することで行の位置を固定。上部の襲撃警告は0件時に解除する。画面側の試験も0件表示を確認するよう更新。
+
+修正後: 従業員UI131チェックがheadlessとmacOS実描画の両方でPASS。ダッシュボード実描画150、更新集約10チェックPASS。全プロセス終了コード0。layout-fix-verification.json参照。修正後の全回帰は別ディレクトリfull-regression-after-defense-hud-fixed-2026-09-29で再実行し、初回失敗記録を上書きしない。
+
+修正後の全140スイートおよび実描画通し97項目もPASS。CURRENT_FULL_REGRESSION.md参照。

docs/plans/original-completion-2026-09-29/execution/DEFENSE_HUMAN_LABELS.md

@@ -0,0 +1,11 @@
+# 防衛戦の原因・発生日時表示
+
+2026-09-30。通し再起動画像で、83文字の内部raid IDが選択欄と概要に表示され、想定520pxの窓幅が約796pxへ広がることを確認した。
+
+本番報告に保存済みevent_sourceのsource_kindとcreated_atをowned scalarとして渡し、画面には原因と発生日・時刻を表示する。同原因・同時刻の複数事件は決定的な一覧順の番号で区別する。内部IDから原因を推測しない。未知または手動登録は「防衛戦」、日時がない場合は「時刻不明」。選択metadata、コマンド対象、UI保存値には完全IDを保持する。
+
+OptionButtonは最長項目への自動拡張を止め、長い表示には省略と人間向けtooltipを使う。独立した隔離コピーで関連6試験1,244項目＋実描画106項目＝1,350項目PASS。実画像は日本語原因・日時で520px内に表示する。検証された3ファイルをSHA比較とバックアップ後に制作コピーへ反映した。
+
+修正後の全148回帰、開業再起動103、関連描画453、事件表示を含む防衛再開66項目がPASS。Windows同梱PCKの18実行2,926項目がPASS。Windowsネイティブ操作は未確認。通常営業からの脅威発生、全P21、全原本完成を証明する変更ではない。
+
+証拠: artifacts/event-defense-labels-integration-2026-09-30/、artifacts/event-defense-ui-presentation-audit-2026-09-30/。

docs/plans/original-completion-2026-09-29/execution/DEFENSE_PREPARATION_CANCEL.md

@@ -0,0 +1,17 @@
+# 防衛準備中の取消と未登録目標
+
+2026-09-29。P21/P27の不具合修正。PREPARINGの襲撃は目標施設の登録前でも妥当な状態だが、取消後の検証が「全目標登録済み」を要求していたため、cancel_defense_raidが拒否され従業員の防衛ロックを解除できなかった。
+
+CANCELLEDかつstarted_at == -1の、実際に戦闘を開始していない場合だけ目標登録完了の条件を免除する。戦闘開始時の全目標登録条件、開始後の取消・保存検証、その他の不変条件は維持。保存形式と数値の変更なし。
+
+新規回帰で目標未登録・2目標中1件登録の双方を修正前に再現（before.log、2 failures）。修正後は取消成功、未開始・0ラウンドの維持、架空の施設を生成しないこと、JSON保存復元、取消再送の不変性を検証。開始済みに改変した破損保存は原状を保って拒否する。
+
+防衛サービス494、Runtime135、従業員UI131、保存ライフサイクル96の計856チェックPASS。従業員UIは目標登録済み/未登録の双方で、ドラッグ中の防衛登録→拒否→実ファイル保存/読込→取消→再配置まで確認。macOS実描画も131チェックPASS（同一シナリオ）。通常営業からの襲撃発生の合格ではない。
+
+証拠: artifacts/defense-preparation-cancel-2026-09-29/。全140スイートはfull_verify.py、実行ハンドル64718で開始。対象ソースの開始/終了SHAを比較し、全件PASSかつソース変更0の場合だけ実描画の開業・3決算・再起動フローへ進む。進捗はartifacts/full-regression-after-defense-2026-09-29/suites/all-tests.json、最終結果はverification.json。現在は実行中であり全体PASSとはしない。
+
+既存Windows配布版は今回の修正未反映。Windows実機、全原本機能・資産、性能予算、長期プレイは未完了。
+
+完了追補: 実行ハンドル64718は正常終了。全140スイートPASS、漏れ/重複/ソース変更0。続けて実描画の開業・決算・再起動97チェックPASS、ゲーム状態一致。CURRENT_FULL_REGRESSION.md参照。
+
+配布追補: 上記検証済みソースのWindows開発確認版を作成し、同梱PCK655チェックを検証。CURRENT_WINDOWS_PACKAGE.md参照。Windows実機は未検証。

docs/plans/original-completion-2026-09-29/execution/DIGEST_SCALAR_CACHE.md

@@ -0,0 +1,9 @@
+# Bounded per-call scalar digest cache
+
+SimulationDigest now reuses canonical encodings for integers (up to512 values), short strings and StringNames (separate type-tagged caches, up to256 values each, length<=128). Caches exist only for one canonical encoding call. Mutable containers and floats are not cached; the v1 byte format and digest contract are unchanged.
+
+Final compatibility75 checks PASS, including reference-byte equality, dictionary order/type tags, depth/invalid values, long histories, cache saturation and changed inputs across calls. Synthetic5000-record history median129.949ms versus272.166ms in the original reference encoder; this ratio includes earlier optimizations and is not the gain from this patch alone.
+
+Same production scenario diagnostic: x1 average63.616ms before /62.711ms after, x3 P95 234.396ms before /228.869ms after; digest average26.328ms before /25.983ms after. Single-run differences are small and may include timing noise; no substantial production performance improvement is established. Both remain outside the4ms/12ms budgets. Main performance defect remains open.
+
+Evidence: digest-scalar-final.log, production-scalar-profile.json and production-scalar-profile.log under artifacts/facility-dimensions-2026-09-29. Next work should address the dominant complete snapshot/digest traversal and redundant infrastructure work without weakening replay correctness.

docs/plans/original-completion-2026-09-29/execution/EVENT_DEFENSE_INTEGRATION.md

@@ -0,0 +1,17 @@
+# Event → Defense の実行・保存契約
+
+2026-09-30。制作ソースへ適用済み。現在、全148スイートと同一ソースの描画・別プロセス再開・配布版を検証中。これらの完了は各最新証拠で別に判定する。
+
+明示された原因ID・脅威種別・完全な戦闘テンプレートを、実際のEvent処理から防衛準備状態へ接続する。敵の強度・周期・標的を補完せず、職員配属や戦闘開始も代行しない。通常の防衛画面で準備し、既存のゲーム時計で戦闘を進める。
+
+EventInstanceとactionの組から安定した襲撃IDを作り、乱数・採番・プレイヤーコマンドを消費しない。再送は進行中の損傷・名簿・退避方針を保つ。異なるテンプレートによる同IDの置換は拒否する。後続actionや実際の料金確定が失敗すると、新しい襲撃とその公開履歴を巻き戻す。以前の戦闘の同時刻再試行制御と失敗診断は保持する。
+
+Runtime保存形式13へ更新し、形式12の必須清掃データを維持する。イベント原因・元テンプレートと保存された襲撃の不変構成を照合し、周期・波の強度・上限等の不一致を確定前に拒否する。合法な退避方針変更や戦闘進行は復元できる。旧手動襲撃にイベント履歴を捏造しない。
+
+隔離候補の18関連スイート2,022項目と、拡張4スイート366項目を実行してPASS。後者の新Event専用試験は最終186項目。両段階には重複実行があるため合算を独立要件数にしない。初回の追加失敗試験は非終端ラウンドで終端callbackを期待して3件失敗した。終端を発生させる試験値へ修正して再実行した記録を残し、ゲームの不具合修正とは扱わない。
+
+独立レビューで、未知のserialized actionを整数clampで新しい破壊的actionへ変換する不具合と、元テンプレートのdigestだけを見て実際の襲撃構成を照合しない不具合を修正した。未知actionを除去して成功扱いすることも防ぐ。
+
+本実装は通常脅威producerの完成ではない。男性の所持金0・高依存、盗賊、世界樹の銀行滞納、監査の原因を同一条件に読み替えない。性別・通常利用の依存増加・原因episode・承認済み敵テンプレート等は残件。原本未指定の数値を試験値から本番へ転記していない。警告/カットインは将来commit後の通知として接続する必要があり、取消不能な同期signalを完成UIの証拠にしない。
+
+実装・適用の証拠: `artifacts/event-defense-integration-2026-09-30/`。独立レビュー: `artifacts/defense-event-bridge-independent-review-2026-09-30/`。通常producerの現物監査: `artifacts/defense-bankruptcy-producer-audit-2026-09-30/`。原本全実装、全P21、性能目標、高負荷/長期プレイ、同一版Windows実機は未完了。

docs/plans/original-completion-2026-09-29/execution/EVENT_HISTORY_SNAPSHOT_CACHE.md

@@ -0,0 +1,9 @@
+# Event ID snapshot ordering cache
+
+DomainEventStream converts committed IDs to typed Strings and uses native lexical sort. It caches that sorted ID list until a successful nonempty publish batch or successful restore. Every snapshot returns a separate array; callers cannot mutate the cache. Recent event payloads continue to serialize live and no published ID is discarded. Invalid batch/restore leaves canonical state intact.
+
+Domain-event33 checks PASS, including10 added cache/Unicode/order/defensive-copy/restore tests and existing atomic/reentrant publication tests. Runtime integration20 checks PASS, including disk digest round trip, pending-command single execution and deterministic24-hour replay.
+
+Production small-scenario profile: x1 average33.704ms, x3 P95136.757ms, snapshot creation average7.954ms. No clear whole-update speed improvement over the prior lazy-digest measurement; x3 was slower in this run. This cache removes repeated sorting when history has not changed, but does not establish production budget compliance. Budgets remain failed.
+
+Evidence under artifacts/facility-dimensions-2026-09-29: event-id-cache-regression.log, event-cache-runtime-regression.log, production-event-cache-profile.json. Full UI and Windows not rerun for this increment.

docs/plans/original-completion-2026-09-29/execution/EXACT_CELL_SET_VALIDATION.md

@@ -0,0 +1,9 @@
+# Exact cell-set crosslink validation
+
+Found a correctness issue while reviewing the remaining P28 validation overhead. Runtime._same_vector3i_set checked that every actual cell appeared in the expected set, but did not reject repeated actual cells. Equal-length arrays [A,B] and [A,A] were incorrectly accepted. The validator now removes each matched expected cell, rejecting duplicates/missing cells while retaining order independence and layer/type checks. This affects infrastructure world/route/projection crosslink checks; no schema or intended valid-save behavior changed.
+
+Runtime infrastructure168 checks PASS,exit0, including6 new equality boundary cases (reorder, duplicate actual, duplicate expected, empty, wrong layer, wrong type). Log: exact-cell-set-runtime.log.
+
+Also investigated fusing OperationsCoordinator snapshot validation and conversion. Existing230 coordinator checks passed, but small production measurements showed only3.622ms→3.459ms in coordinator serialization and x3 P9553.431ms→54.428ms. The experiment was reverted completely to the pre-experiment source (byte comparison confirmed). No new fused implementation is retained. Diagnostic reports remain as historical experiment evidence, not a performance acceptance result.
+
+Full make test-ui completed with exit0, unchanged source hashes and no ERROR/SCRIPT ERROR/FAIL markers. Log: post-validation-cache-full-ui.log; result: post-validation-cache-ui-result.json. Includes17 direct Godot scripts and independent upkeep write/read processes. Headless UI acceptance covers this source snapshot; Windows/native rendering and whole-original completion are not proven. Original P00–P29 scope, high-load and Windows acceptance remain incomplete.

docs/plans/original-completion-2026-09-29/execution/FACILITY_AUDIT_BEFORE_CLEANING.md

@@ -0,0 +1,52 @@
+# 原本30施設・現在の登録対応（2026-09-29）
+
+原本10.1–10.7を再照合し、通常Runtimeの登録一覧、建設パレット、FacilityCatalog.by_idが返す定義を実行して照合した。通常登録15、定義のみ1、対応定義なし14。通常カタログ全22件のうち7件はこの30施設以外であり、原本施設の代用として数えない。登録済みは全受入完了を意味しない。
+
+対応定義16件の寸法・層は原本と一致する。地上/地下・高層・背面・騒音などの追加条件、実営業、保存移行、専用画像は別途受入が必要。一般客室・上級客室・従業員寮のABOVE_GROUND制限は原本10章の層指定だけでは正当化できず、残る配置差異として精査する。
+
+人数専用customer_capacityが未設定（-1）の対応定義は13件。FacilityInstance.can_accept_customersはこの場合に人数専用上限を適用せず、available_slotsは既存capacityからサービス数を計算する。保管量・生産量と人数を混同した値を確定しない。バックヤード等の0指定、旅客交通の乗員容量との区分、施設ごとの人数値を整理する必要がある。
+
+対応定義16件すべてでservice_attributeは空欄。属性・一致加算のモデルが存在しても、全施設で追加仕様を運用済みとは判定しない。加算額・不足基準・複数属性等は未設定のまま残す。
+
+原本対応表original_facility_mapping.jsonを独立させ、旧監査facilities.jsonは歴史的証拠として保全した。礼拝堂をchapelへ対応付け、素材台帳もこの現行表を入力にする。これで礼拝堂の必要枠が未対応施設として生成される不整合を防ぐ。新表は対応関係のみを保持し、稼働検証状態はruntime-facilities.jsonで別管理する。
+
+証拠: artifacts/facility-audit-2026-09-29/runtime-facilities.json、summary.json、source-hashes.json、runtime-audit.log、capture-runtime-facilities.gd。再現はローカル制作コピーから `godot --headless --path . --script res://artifacts/facility-audit-2026-09-29/capture-runtime-facilities.gd`。この取得スクリプトは監査時の対応表（旧監査＋礼拝堂）を固定して再現するものであり、将来の新規施設を自動対応させるものではない。
+
+次の優先作業: 人数専用値と層/ゾーン差異の解消、未接続施設の通常プレイ統合。現在の全体回帰中は本体ソースを固定し、完了後に保存・再起動を含む通しデバッグを先に行う。
+
+| Original | Facility | ID | State | Dimensions / Layer | Customer limit |
+|---|---|---|---|---|---|
+| 10.1 | 一般客室 | standard_room | normal + palette | 2x1 / FRONT | unspecified |
+| 10.1 | 上級客室 | premium_room | normal + palette | 4x1 / FRONT | 2 |
+| 10.1 | VIPスイート | - | missing definition | - | unspecified |
+| 10.1 | ドミトリー | - | missing definition | - | unspecified |
+| 10.2 | 大衆食堂 | cafeteria | normal + palette | 4x2 / FRONT | unspecified |
+| 10.2 | レストラン | - | missing definition | - | unspecified |
+| 10.2 | 酒場 | tavern | normal + palette | 4x2 / FRONT | unspecified |
+| 10.2 | 屋台 | - | missing definition | - | unspecified |
+| 10.3 | 大浴場 | public_bath | normal + palette | 6x2 / FRONT | unspecified |
+| 10.3 | カジノ | - | missing definition | - | unspecified |
+| 10.3 | 闘技場 | - | missing definition | - | unspecified |
+| 10.3 | 礼拝堂 | chapel | normal + palette | 4x3 / FRONT | 8 |
+| 10.4 | 風俗個室 | adult_private_room | normal + palette | 2x1 / FRONT | unspecified |
+| 10.4 | 高級ソープ | - | missing definition | - | unspecified |
+| 10.4 | SM拷問室 | - | missing definition | - | unspecified |
+| 10.4 | 闇市場 | black_market | definition only | 4x2 / FRONT | unspecified |
+| 10.5 | 厨房 | kitchen | normal + palette | 4x2 / BACK | unspecified |
+| 10.5 | 倉庫 | warehouse | normal + palette | 4x2 / BACK | unspecified |
+| 10.5 | 待機室 | staff_waiting_room | normal + palette | 4x2 / BACK | unspecified |
+| 10.5 | 従業員寮 | staff_dormitory | normal + palette | 2x1 / BACK | 0 |
+| 10.5 | 警備員詰所 | security_station | normal + palette | 2x2 / BACK | unspecified |
+| 10.5 | 清掃員室 | - | missing definition | - | unspecified |
+| 10.5 | 医務室 | infirmary | normal + palette | 4x2 / BACK | unspecified |
+| 10.6 | 覗き部屋 | - | missing definition | - | unspecified |
+| 10.6 | 地下牢 | - | missing definition | - | unspecified |
+| 10.6 | マナ炉 | - | missing definition | - | unspecified |
+| 10.7 | 蔓の昇降機 | guest_elevator | normal + palette | 2x2 / FRONT | unspecified |
+| 10.7 | 業務用EV | service_elevator | normal + palette | 3x2 / BACK | unspecified |
+| 10.7 | ワープ | - | missing definition | - | unspecified |
+| 10.7 | 魔法砲台 | - | missing definition | - | unspecified |
+
+## 配置差異の追記
+
+一般客室・上級客室・従業員寮の地上限定差異は`ORIGINAL_ROOM_ZONES.md`で修正/関連検証済み。この表の登録数・清掃員室未対応表示は監査時点の記録で、清掃員室の後続統合を反映していない。最新の清掃統合は`CLEANING_RUNTIME_INTEGRATION.md`を参照。

docs/plans/original-completion-2026-09-29/execution/FACILITY_DIMENSION_MIGRATION.md

@@ -0,0 +1,108 @@
+# P08 施設寸法移行の事前確認
+
+原本の上級客室4×1、従業員寮2×1、闇市場4×2に対し、現拡張定義は3×2、4×2、3×2。調査はfacility-dimension-preflight.json参照。
+
+## 実装済み
+
+`facility_resize_preview.gd` はWorldServiceと現施設の明示された旧占有を受け、変更後のセル、追加/削除セル、衝突、未掘削、境界外、地下制約、支持喪失を返す。現在定義から旧占有を推測せず、旧形または変更後の形と保存の占有所有者が一致することを要求する。別WorldServiceへ複製して検証するため、成功/失敗どちらでも元ワールドの占有と版番号を変更しない。90/270度では寸法軸を交換し、層を保持。
+
+14項目PASS: 上級客室の3×2→4×1、重なり拒否、上階の支持喪失、旧占有の矛盾/重複/不正ID/回転拒否、裏層の回転した寮、地下闇市場の未掘削/掘削後/境界外を実WorldServiceで確認。証拠 `artifacts/facility-dimensions-2026-09-29/validation.json`。
+
+## 適用前に必要な処理
+
+この判定のgeometry_okは寸法とWorldServiceの抽象的支持モデルの部分判定であり、移行実行許可ではない。ready_to_applyは常にfalse。特に周辺施設の実定義別重量、経路と職員/客の位置、建設中ジョブ、FacilityService/Construction/Pathの相互参照、バックアップと原子的保存への接続は残る。全ゲートを省略してプレビュー結果を本番へ書き戻してはならない。
+
+定義の寸法・既存セーブはまだ変更していない。次はRuntimeから実重量/経路/旧配置を捕捉する移行プレビューへ接続し、変更できない配置を元データを保ったまま示す。P08全体および原本30施設の通常建設対応は未完了。
+
+
+## 実重量とRuntimeへの接続
+
+WorldService.validate_supportへ任意の占有者別重量を追加した。指定のない既存呼出は従来どおり。未登録ID・負/非整数重量は拒否し、支持モデルと保存状態を変更しない。闇市場の拡張で、従来の簡略重量では合格するが隣接施設の実重量を加えると容量超過になる例を検証した。
+
+Runtime.preview_facility_dimension_migrationは完成施設と現定義を読み、全完成施設のweight_per_cellで判定する。削除予定セルにいる客/職員と建設ジョブを報告し、実状態は変更しない。形状・支持のプレビューが通ってもready_to_applyはfalseで、移動経路/建設中/保存取引のゲートが残る。
+
+試験は既存の拡張定義を明示登録し、受付を通常建設した上に旧3×2の上級客室を通常コマンドで建設。最初は地上専用施設をロビー階へ置いて拒否されたため配置を修正した。削除セル上の職員検出は、通常通行できない旧座標を診断入力として設定した限定試験。通常歩行・配置移行の受入とは区別する。初回の建設失敗と通行不能セルへの登録失敗ログも保持。
+
+実重量/Runtime14項目、WorldService60、Construction105、Runtime建設37項目がPASS。証拠 weighted-final-validation.json。施設定義の寸法と既存セーブは未変更。次は経路と実占有の事前検証、UI、適用トランザクションへ接続する。
+
+## Construction migration candidate (2026-09-29)
+
+Added prepare_construction_candidate: validate source, copy world, resize ownership, update facility and source-job cells together, then validate via ConstructionService.restore_snapshot. Active jobs are supported; costs, progress and timestamps are retained. Runtime preview exposes the candidate. No live state or disk write occurs.
+
+Validation: Runtime 22 checks and geometry 14 checks PASS. Initial retry changed world revision; fixed by skipping occupancy replacement when already resized. Initial failure log retained. Active-job fixture covers progress zero only; partially built continuation remains unverified.
+
+Remaining: valid actor relocation and routes, other Runtime crosslinks, partial-job continuation, backup and atomic application, UI and canonical dimensions. This is not full migration acceptance.
+
+## Partial construction and full snapshot candidate (2026-09-29)
+
+Runtime now assembles world, construction and operational facility geometry into a copied full snapshot. Actors on removed cells require relocation before assembly. ready_to_apply remains false: caller still needs isolated validation, route/actor checks and disk backup/atomic commit.
+
+Focused suite: 33 checks PASS; geometry suite: 14 PASS. Partial construction now advances 7 minutes before migration, restores, rejects duplicate work for the saved minute, completes exactly once, preserves original cost/start/duration and restores after completion. Full snapshot candidate for an unoccupied premium room restores through a separate Runtime with the fixture expansion registry. This is one fixture, not all-facility or route relocation acceptance.
+
+Evidence: full-snapshot-candidate.log and full-candidate-geometry.log. Canonical definitions, normal palette registration, actor relocation, route continuation and disk migration are still incomplete.
+
+## Route preservation gate (2026-09-29)
+
+prepare_facility_dimension_snapshot now restores its candidate into an isolated Runtime using the source definition registry. It compares entrance access, guests targeting the facility and staff workplace access using production route queries. Loss of existing reachability rejects the candidate; moving guests with a changed destination require explicit retargeting. No live actor relocation or disk write occurs.
+
+40 focused checks PASS; make check exits 0. Controlled topology cases prove that removing an upper facility row can lose access even when the path graph itself is unchanged, and that an alternative entrance still requires updating the moving guest target. The first fixture omitted the vertical connector, causing two expected-reachability failures; explicit connector setup fixes the fixture. Initial failure retained. Controlled graph/guest edits are route-unit fixtures, not normal UI play evidence. The earlier valid full Runtime restore is tested separately.
+
+Still pending: staff commute/task and elevator-in-flight migration acceptance, real actor relocation, automatic route retargeting, disk backup/atomic commit/UI, canonical definition changes and all-30 normal construction acceptance. The gate does not turn these remaining items into completion.
+
+## Candidate guest retargeting (2026-09-29)
+
+Added an all-or-nothing replan batch for isolated candidate guests. Every guest must still be MOVING with the expected old destination, a reachable replacement and no active elevator trip. Only path_handle target and graph revision change. Position, wallet, service state and movement credit remain untouched. Runtime candidate preparation applies the batch, captures/restores the resulting candidate again, and repeats access comparison. Live source and disk are unchanged.
+
+46 focused checks PASS, 91 existing Runtime path/traffic checks PASS, make check exit0. Controlled topology fixture checks invalid second replan rollback, stale-plan rejection, retained guest fields and production movement toward the replacement lower entrance. This is not normal construction/UI or a full moving-guest save migration scenario; those remain unverified. No in-flight EV retargeting or physical actor relocation is claimed.
+
+## Canonical dimensions applied (2026-09-29)
+
+Changed expansion definitions: premium_room 4x1 FRONT, staff_dormitory 2x1 BACK, black_market 4x2 FRONT underground, matching original chapter 10. Costs, duration and other fields unchanged. These expansion definitions are still outside the normal palette registry; normal all-30 construction remains incomplete.
+
+The old premium_room resource is archived under tests/fixtures/legacy_premium_room.tres. Migration tests reserve using this explicit old resource, then switch to current definitions before progress, candidate generation and restore. Thus legacy occupancy is tested against corrected definitions instead of leaving production data at old sizes. Existing saves are not rewritten.
+
+New-construction tests use real WorldService/ConstructionService and a funded test budget. All three definitions at four rotations reserve, finish, pay once and restore:63 checks PASS. Legacy Runtime migration:47 PASS. Definition registry:266 PASS. Content catalog:212 PASS. make check exits0. Migration/geometry/new-dimension tests are now included in make test-s1. Earlier preflight records are historical evidence of the old mismatch.
+
+Remaining: normal palette and role integration, all30 original facilities, actor relocation, staff tasks/EV migration, full moving-guest save acceptance, backup/atomic application and UI. Canonical dimension correction alone does not complete P08.
+
+## Verified disk migration (2026-09-29)
+
+SaveService.replace_snapshot_with_backup reuses the existing package migration transaction for same-format domain changes. It requires a valid candidate and an exact expected-source match, checksum-verifies candidate and backup, and atomically promotes using the existing recovery protocol. Repeated identical migration preserves the initial backup. Different package versions require their format migration first.
+
+Runtime.migrate_facility_dimensions_at_path loads an explicit path into an isolated Runtime, prepares/validates the dimension candidate and routes, then replaces the package with backup. It does not change live Runtime. Tests use unique disposable user save paths, not production saves.
+
+56 focused checks PASS,127 SaveService regression checks PASS; make check passed before the final format guard, and final Godot suites compiled that guard. Tests prove backup snapshot/bytes, repeat migration, stale-source and invalid-candidate rejection, separate-Runtime reload and live-state preservation. Existing save regression covers interruption/failed migration paths.
+
+This completes the explicit disk API for accepted candidates, not the whole migration user flow. Actor relocation, EV/tasks, normal UI invocation and post-migration load flow, all30 normal construction remain incomplete.
+
+## Staff rest and assigned-task migration gates (2026-09-29)
+
+Route preservation now includes off-duty workers whose selected rest facility is resized, even without a workplace assignment. Pending/assigned tasks targeting the facility or its rescue destination must retain exact state and a valid destination in the resized facility access cells. Assigned-task reachability uses normal staff routing; rescue tasks use the same backyard restriction as production movement. Changed task destinations require coordinated migration and are rejected for now rather than silently retained.
+
+25 focused checks PASS in dormitory-migration-tasks.log. A HEAD-version legacy4x2 dormitory fixture is built through normal construction and service stairs, then registry switches to canonical2x1. A worker resting on the valid upper stair landing preserves position through full snapshot migration and physically descends to the new lower entrance after resume. Blocking the lower entrance rejects migration without changing source. An old-upper-entry task rejects with TASK_DESTINATION_CHANGED. A retained-entry task assigned through StaffService preserves its exact snapshot after candidate restore. This covers an assigned/reserved task, not every working logistics/rescue case.
+
+Existing premium/disk migration56 checks PASS; make check exit0. Remaining: physical actors on removed cells, coordinated task retargeting, in-flight elevator/rescue/logistics acceptance, migration UI/load flow, all30 normal facility acceptance. No production save changed.
+
+## Whole-save completed-facility batch (2026-09-29)
+
+migrate_facility_dimensions_at_path now accepts an omitted facility ID to migrate all mismatched completed facilities. It loads once into an isolated Runtime, prepares/restores each candidate there, and commits only the final snapshot through one verified backup transaction. Already-canonical facilities are skipped. Failed candidate restores the isolated original and leaves disk/live state untouched. Active legacy construction is explicitly reported as requiring migration, not silently skipped.
+
+23 batch checks PASS (batch-save-final.log): premium room and dormitory old definitions built normally, one backup retains both originals, final full Runtime restores both corrected sizes, repeat preserves initial backup. A valid task at the second facility's removed entrance rejects the batch after the first candidate; rollback and unchanged formal save/live state/previous backup are verified. Existing single-facility/disk suite56 PASS. make check passed before final unchanged-shape skip; final Godot batch compiles and exercises that change.
+
+Remaining: active-job full Runtime migration, joint spatial rearrangements requiring coordinated ordering, actor relocation/task retargeting/in-flight transport, normal UI/load flow and all30 facility acceptance. Sequential candidate validation is not a general simultaneous layout solver. Tests use disposable saves; production saves untouched.
+
+## Active construction included in Runtime/disk batch (2026-09-29)
+
+Active legacy jobs now join the batch target list. Their world reservations and construction snapshots are converted by the existing geometry/weight gate, then validated in an isolated full Runtime before promotion. They do not fabricate an operating facility before completion. Paid cost, work units, progress and timestamps are retained.
+
+active-job-runtime.log:63 checks PASS. A normally started legacy premium-room job advances7minutes, is saved to a disposable package and batch-migrated with backup. The full migrated Runtime restores the four-cell reservation with original progress/cost, advances normally to an operating4x1 room, and restores after completion. Original partial-job backup remains exact. Completed batch23 and dormitory rest/task25 regression checks PASS; make check exit0.
+
+The earlier ACTIVE_CONSTRUCTION_MIGRATION_REQUIRED limitation is removed for candidates accepted by these gates. This evidence covers the premium partial-job fixture, not every mixed-job/actor/transport layout. Remaining: coordinated spatial ordering, actors on removed cells and lost task destinations, in-flight transport/rescue/logistics, normal migration UI/load flow and all30 facility acceptance.
+
+## Migration review and load UI (2026-09-29)
+
+The bottom toolbar now provides 読込 ▾ → 旧寸法を修正して読み込む. Preview loads the saved package into an isolated Runtime, validates the complete candidate, and lists affected facilities and target sizes before confirmation. Cancel clears the pending token. Confirmation requires the original preview digest; a changed save is rejected before migration. Successful promotion retains the source backup and strictly loads the migrated formal save, without falling back to an old backup while claiming migration success. Ordinary load retains its existing recovery behavior.
+
+Native macOS rendered UI handler flow:13 checks PASS, including cancel, changed-source rejection, original backup equality, corrected live room and already-current handling. Screenshot migration-dialog.png visually inspected: facility name,4×1 target, backup and unsaved-progress explanation, cancel/confirm buttons readable. Dashboard regression136 and batch-save regression23 checks PASS. These are rendered UI signal-handler tests using a controlled legacy fixture; OS pointer input and Windows execution were not tested. Makefile test-ui includes the new flow.
+
+Remaining: coordinated spatial ordering, actors on removed cells, task retargeting, in-flight transport/rescue/logistics, all30 facilities and Windows acceptance. P08 remains in progress.

docs/plans/original-completion-2026-09-29/execution/FACILITY_REACHABILITY.md

@@ -0,0 +1,21 @@
+# 施設到達可否の表示処理軽量化 — 2026-09-29
+
+## 変更
+
+開業ガイドは到達可否しか表示しないが、従来は施設の全候補入口から最安経路を選ぶ詳細レポートを取得していた。
+Runtime に `is_facility_reachable` を追加し、到達可能な候補が一つ見つかれば終了する。候補生成を Guest AI と共用し、入口、アクセス禁止、通行制約は同じとする。状態キャッシュは追加せず、遮断や復元後もその時点の経路で判断する。
+実際の客の移動は従来の最安経路選択を維持。保存形式・ゲーム内経済・施設数に変更なし。
+
+## 検証
+
+- 新規回帰 `tests/performance/test_facility_reachability.gd`: 33チェックPASS。実際に建設した複数階施設で既存詳細レポートとの一致、存在しない施設、アクセス禁止、入口遮断、保存復元を確認。
+- 既存のインフラ統合180、スナップショット所有権89、清掃アクセス6チェックPASS。
+- 同一プロセス・同一状態・順序を交替する100回の計測（各回はデモ全施設の一巡）: 詳細レポート平均6222.41µs/P95 6391µs、到達可否平均4222.04µs/P95 4335µs。平均約32%短縮。
+- 計測機: macOS Apple M4、Godot 4.7.2、headless。小規模デモのこの照会処理だけの測定であり、全体Tick予算やWindows描画性能の合格ではない。
+
+証拠: `artifacts/facility-reachability-2026-09-29/` の comparison.json、comparison-summary.json、関連試験ログ、変更前ソース。
+通しデバッグの結果は同ディレクトリの opening-restart に保存する。
+
+前回の Windows-cleaning ZIP は変更前のソースを固定した成果物であり、この軽量化を含むとは扱わない。
+
+描画あり通しデバッグ: 書込80＋再起動読込17＝97チェックPASS（62.91秒＋48.00秒）。実行中のソース変更なし、再起動前後のゲーム状態JSON一致。3営業日の決算まで完走し、再起動後の3日目決算画面を目視確認。

docs/plans/original-completion-2026-09-29/execution/FINE_CLEANING_EFFECT.md

@@ -0,0 +1,13 @@
+# フィーネの清掃速度・作業更新の接続
+
+原本6.2の清掃速度3倍をRuntimeへ接続。heroine_fine・UNIQUE・cleanerが一致する作業者は毎分3作業単位、通常は1。8単位の清掃は1分刻みのゲーム時間では3分目に完了する（2分時点6/8）。到着前の移動速度や他業務は変更しない。回復25・一度だけ適用・途中取消の回復なしは維持。清掃状況は3倍速と残り実時間を表示する。
+
+実装中の検証で汎用StaffService更新が先に1単位進め、Runtimeの清掃専用判定が同分重複扱いで走らない点を発見。汎用更新に進捗ポリシーを設け、清掃は0としてRuntime側へ委ねた。出勤・施設稼働・取消を確認後、作業量を一度だけ進める。既存の物流の外部駆動契約は変更しない。
+
+採用UI・初期能力は未指定で確認待ち。通常カタログにフィーネを追加していない。テストではregister_staffコマンドでUNIQUE/cleanerの本人を登録し、実際のUI配置・移動・汚れ・清掃を検証する。これは通常募集からの加入完了の証拠ではない。暗殺確率UP、成長、他固有効果・人物素材も残件。
+
+関連6スイートPASS: Fine効果、通常清掃UI、StaffService、通勤、物流ブリッジ、救護UI。通常8分/固有3分・途中保存同一再生・完了直前の閉鎖/停電・一般雇用/別職種への誤適用防止を含む。実描画と3日営業の別プロセス再起動は実行中。証拠: artifacts/fine-cleaning-effect-2026-09-29/。
+
+## 実描画・再起動結果
+
+固有效果95チェック、実描画は画像取得を加え96チェックPASS。working.pngで3倍速・残り3分を確認。通常開業から3回決算、別プロセスの保存再開97チェックPASS。source-change.jsonは空、両プロセスのゲーム状態JSONも一致。通常加入への接続は依然未完了で、募集経路・初期値の回答が必要。

docs/plans/original-completion-2026-09-29/execution/FULL_REGRESSION_AFTER_GUEST_LOG.md

@@ -0,0 +1,25 @@
+# 現行ソースの全回帰 — 来客判断ログ追加後
+
+139ソーススイートを単一のソース状態で実行し、139PASS・失敗0。所要798.08秒。実行対象と実行結果の完全一致、未実行0、重複0、開始・終了のソースハッシュ一致を確認した。
+対象は `tests/run_tests.gd` と `tests/**/test*.gd`。RefCountedのkernelモジュールはrun_testsから実行し、配布PCK専用試験は別工程。
+
+来客判断履歴・候補除外理由・経路到達判定の軽量化を含む現行コードの回帰証拠。原本全実装・Windows実機・実プレイ時間・全体性能予算の達成を示すものではない。
+
+証拠: `artifacts/full-regression-after-guest-log-2026-09-29/` の expected-tests.json、all-tests.json、全ログ、source-start/end.json、verification.json。
+全件PASS後の描画あり通し検証は同ディレクトリの opening-restart/ へ記録する。
+
+前回の137スイート（136合格＋期待値修正後1合格）の経緯は FULL_REGRESSION_BEFORE_GUEST_LOG.md に保存した。今回の139スイートは単一走査ですべて合格した。
+
+## 独立した調査
+
+顧客人数0で生産できないという初期仮説は、顧客向けサービスと厨房生産を混同していた。KitchenProductionServiceの全fixtureを顧客人数0にした追加試験141チェックがPASSし、仮説を棄却した。本番の人数判定は変更していない。ZERO_CUSTOMER_PRODUCTION_BUG.md参照。
+
+## 全回帰後の通しデバッグ完了
+
+描画あり80＋17＝97チェックPASS。書込・読込の両プロセス終了コード0。ソース変更なし、write/read-gameplay.json一致。通常開業から3回決算、終了・再起動後の継続を確認。
+
+現行差分の追記: この139スイート一括実行後にサービス開始結果の枠番号を修正した。変更後の関連回帰・通しデバッグは SERVICE_START_SLOTS.md を参照。この一括結果を変更後140スイートの合格として扱わない。
+
+追加差分: 従業員ドラッグがロード前後をまたがないよう修正した。変更後の回帰証拠は STAFF_DRAG_LOAD.md を参照。
+
+追加差分: インフラ投影の重複した経路状態検査を削減。変更後の関連回帰・性能・通し検証は PROJECTOR_SINGLE_LIVE_CHECK.md を参照。

docs/plans/original-completion-2026-09-29/execution/FULL_REGRESSION_BEFORE_ACTOR_SELECTION.md

@@ -0,0 +1,9 @@
+# 現行ソースの全回帰 — 自動保存・直接読込の選択復元後
+
+2026-09-30。143/143スイートPASS。失敗・未実行・余分な実行・重複・ソースハッシュ差分0。合計1039.40秒。
+
+全件PASS後のmacOS実描画通し試験は、新規開業・3回決算・保存・終了・別プロセス再起動・継続で83＋20＝103項目PASS。書込49.98秒、再読込36.28秒、終了コードともに0。ゲーム状態の比較は一致。再起動後の画像で4日目00:00、帳簿一致、営業利益＋346Gを確認。
+
+証拠: artifacts/full-regression-after-selection-autosave-2026-09-30/。coverage-verification.json、source-start/end.json、verification.json、opening-restart/。以前の記録はFULL_REGRESSION_BEFORE_SELECTION_AUTOSAVE.md。
+
+この結果は全原本実装・Windows実機・長期プレイ・性能予算の合格ではない。現在のWindows配布版は選択復元の変更を含まない。後続変更として従業員・来客の選択復元を実装し、100項目・実描画101項目・関連552項目PASS。この143スイートの証拠には含めず、最新144スイートの全回帰と通しを再実行する。ACTOR_SELECTION_RESTORE.mdを参照。

docs/plans/original-completion-2026-09-29/execution/FULL_REGRESSION_BEFORE_DEFENSE_AUTONOMY.md

@@ -0,0 +1,13 @@
+# 現行ソースの全回帰 — 従業員・来客選択復元後
+
+2026-09-30。144/144スイートPASS。失敗・未実行・余分な実行・重複・ソースハッシュ差分0。合計762.12秒。
+
+全件PASS後のmacOS実描画通し試験は、新規開業・3回決算・保存・終了・別プロセス再起動・継続で83＋20＝103項目PASS。書込49.68秒、再読込36.90秒、終了コードともに0。ゲーム状態JSON一致。再起動後の画像で4日目00:00、帳簿一致、営業利益＋346Gを確認。
+
+追加の従業員・来客選択復元も、別プロセス書込103項目・読込13項目、計116項目PASS。実際の保存データで選択IDと画面の開閉、ゲーム状態JSONと型を含むdigestの一致を確認。読込側画像を目視確認。
+
+証拠: artifacts/full-regression-after-actor-selection-2026-09-30/。coverage-verification.json、source-start/end.json、verification.json、opening-restart/。別プロセス選択復元はartifacts/actor-selection-restart-2026-09-30/。以前の143スイート記録はFULL_REGRESSION_BEFORE_ACTOR_SELECTION.mdへ保全。
+
+この結果は全原本実装・Windows実機・長期プレイ・性能予算の合格を示さない。Windows配布版の更新は別検証で進める。選択復元の変更と対象試験はACTOR_SELECTION_RESTORE.mdを参照。
+
+後続変更: 防衛操作画面を実装し、対象54・実描画55・関連1,250項目PASS。上記144スイートはこの変更前の証拠。自律戦闘の接続を続け、変更後の全回帰・通しを再実行する。

docs/plans/original-completion-2026-09-29/execution/FULL_REGRESSION_BEFORE_DEFENSE_HUD.md

@@ -0,0 +1,15 @@
+# 現行ソースの全回帰 — 防衛準備中取消修正後
+
+更新注記: 防衛HUD追加（DEFENSE_HUD.md）はこの記録・配布版の後の変更。追加後の関連試験はPASS。追加後の全回帰・通し・再配布は別途確認する。
+
+2026-09-29。140ソーススイートを単一ソース状態で実行し、140PASS・失敗0。スイート実行時間合計783.63秒。期待対象と結果は完全一致し、未実行・余分な実行・重複は各0。開始/終了のソースハッシュ差分0。
+
+対象はtests/run_tests.gdとtests/**/test*.gd。RefCountedのkernelモジュールはrun_testsから実行し、配布PCK専用試験は別工程。サービス開始時の枠番号、ロード前後のドラッグ無効化、インフラ投影の重複検査削減、従業員の配属阻害理由表示、防衛準備中取消の修正を含む。
+
+全件PASS後に実描画の通しデバッグを実行。通常開業・3回決算・保存・終了・別プロセス再起動・継続が80＋17＝97チェックPASS。write/read両プロセス終了コード0、実行中ソース変更0、write-gameplay.jsonとread-gameplay.json完全一致。再起動後の決算画像も目視し、3日目利益+346G、帳簿照合一致、日本語表示を確認。
+
+証拠はartifacts/full-regression-after-defense-2026-09-29/。expected-tests.json、suites/all-tests.jsonと全ログ、source-start/end.json、source-change.json、coverage-verification.json、verification.json、opening-restart/を参照。
+
+前回139スイートの記録はFULL_REGRESSION_AFTER_GUEST_LOG.mdへ保全。今回の全回帰はソース版の検証であり、Windows配布版はこの修正をまだ含まない。Windows実機、未実装の原本機能・資産、長期実プレイ、全体性能予算の合格を示すものではない。NEXT_MECHANICS_AUDIT.mdに仕入れ補正と通常防衛UIの未実装を現行ソースから追記した。
+
+配布追補: 上記検証済みソースのWindows開発確認版を作成し、同梱PCK655チェックを検証。CURRENT_WINDOWS_PACKAGE.md参照。Windows実機は未検証。

docs/plans/original-completion-2026-09-29/execution/FULL_REGRESSION_BEFORE_EVENT_DEFENSE.md

@@ -0,0 +1,13 @@
+# 現行ソースの全回帰 — catalog manifest cache
+
+2026-09-30。147/147スイートPASS。欠落・余分・重複・失敗・実行中入力差分0。合計708.21秒。新cache専用試験は79項目PASSで、旧146スイートも全件保持。
+
+全件PASS後、macOS実描画で新規開業・3回決算・保存・終了・別プロセス再起動・継続を83＋20＝103項目PASS。書込46.55秒、読込34.92秒、ゲーム状態JSON一致。再起動画像を目視確認し、4日目00:00、帳簿一致、営業利益＋346Gを確認。
+
+同じ凍結ソースで関連描画5実行・403項目PASS（職員131、自動保存76、施設選択39、人物選択101、防衛画面56）。全回帰の実headless4ログを同じソースの証拠として参照し、484項目を再実行扱いにしない。
+
+戦闘途中の別プロセス保存・復元は19＋19＝38項目PASS。有料受付建設、通常採用、viewportのスクロール・クリックによる登録/開始/次波操作、ゲーム時間による2波撃退を確認。途中・最終の全ゲーム状態JSONと型付きdigestが一致。書込2.87秒、読込2.62秒。脅威作成だけ開示fixture。読込後の撃退画面と自動保存復旧画面を目視確認。
+
+証拠: artifacts/full-regression-after-manifest-cache-2026-09-30/、artifacts/manifest-cache-related-2026-09-30/、artifacts/manifest-cache-defense-restart-2026-09-30/。現在source-end SHA256: c09bc629442d319a3e4b928859213d23735943cfb32d91855f50380d5724449d。前146スイートの証拠は FULL_REGRESSION_BEFORE_MANIFEST_CACHE.mdへ保全。変更と測定は MVP_CATALOG_MANIFEST_CACHE.md を参照。
+
+既存試験と今回の通し試験の合格であり、原本全実装、通常脅威発生、性能予算、高負荷/長期プレイ、同じ版のWindows実機は未完了。Windows配布は別証拠に記録。

docs/plans/original-completion-2026-09-29/execution/FULL_REGRESSION_BEFORE_EVENT_LABELS.md

@@ -0,0 +1,13 @@
+# Event → Defense・全回帰と通し確認
+
+2026-09-30。148/148スイートPASS。欠落・余分・重複・失敗・実行中ソース変更0。合計670.50秒。新Event専用試験186項目を含む。
+
+全件PASS後、macOS実描画で新規開業・3回決算・保存・終了・別プロセス再起動を83＋20＝103項目PASS（43.89秒/32.84秒）。ゲーム状態JSON一致、4日目00:00・帳簿一致・営業利益＋346Gを目視確認。
+
+同じ凍結ソースで関連描画5実行403項目PASS。全回帰の同じソース実ログ5件670項目を参照し、再実行扱いしない。Event queue/時計から生成された襲撃のviewport操作・戦闘途中保存・終了・別プロセス再開は22＋20＝42項目PASS。全ゲーム状態とtyped digest一致、全domain event/採番/乱数を保全し、Save/Loadの2種類のI/O観測type/payloadのみ明示normalization。
+
+通し画像で防衛画面に長い内部IDが露出する問題を発見。これを修正するため、現在の画面受入は完了としない。現在ソースと同じWindows版のexport/PCK検証は未実行。封印済み配布準備は実行せず、表示修正後に新証拠世代で検証する。
+
+証拠: artifacts/full-regression-after-event-defense-2026-09-30/、artifacts/event-defense-related-2026-09-30/、artifacts/event-defense-restart-2026-09-30/。source-end SHA256: 319b76d51c268a64e6ea1cddf8e2b0a02b05cfb87730749394ecb985a1fdeac1。
+
+原本全実装、通常脅威producer、性能予算、高負荷/長期プレイ、同じ版のWindows実機は未完了。

docs/plans/original-completion-2026-09-29/execution/FULL_REGRESSION_BEFORE_GUEST_LOG.md

@@ -0,0 +1,17 @@
+# 現行ソースの全回帰と期待値修正
+
+全137ソーススイートを実行し、136合格・1失敗でランナー終了コード1。実行中ソース変更なし、未実行0、重複0をverification.jsonで確認。失敗ログを消去せず残す。
+
+失敗はtests/s0/test_definition_registry.gdのANYゾーン一覧にstandard_roomが無いこと。原本準拠の地上限定解除は既に実装・地下建設検証済みだったが、この期待値が古いままだった。一般客室をANY一覧へ追加して312チェックPASS、地下配置の回帰も40チェックPASS。
+
+修正前後のハッシュ差は当該テスト1ファイルのみ。製品コード・共通試験コードは不変。保持136合格＋修正済み1合格により現行137スイートの合格を網羅した。単一の全件PASS走査ではないことをcorrected-verification.jsonに明記。
+
+証拠: artifacts/current-full-regression-2026-09-29/。expected-suites.json、all-tests.json、各ログ、source-start/end.json、verification.json、corrected-source.json、corrected-verification.json。
+
+対象はtests/run_tests.gdおよびtests配下のtest*.gd。RefCountedのkernelモジュールはrun_tests経由、配布PCK試験は別工程。全原本実装・Windows実機・製品性能予算・長期プレイの合格ではない。
+
+全スイートの結果確定後、同じ製品ソースで実描画の開業・3回決算・別プロセス再起動を開始。実行ハンドル38791、出力opening-restart/。この通し結果は完了後に追記する。
+
+## 通し検証完了
+
+書込80・読込17、合計97チェックPASS。両プロセス終了コード0。書込63.11秒、読込48.00秒。source-change.jsonは空配列、write/read-gameplay.json一致。通常開業・3回決算・アプリ終了後の再起動継続まで確認した。全原本・Windows・長期プレイの合格ではない。

docs/plans/original-completion-2026-09-29/execution/FULL_REGRESSION_BEFORE_MANIFEST_CACHE.md

@@ -0,0 +1,11 @@
+# 現行ソースの全回帰 — 防衛画面・自動進行後
+
+2026-09-30。146/146スイートPASS。欠落・余分・重複・失敗・実行中入力差分0。合計743.93秒。
+
+全件PASS後のmacOS実描画通し試験は、新規開業・3回決算・保存・終了・別プロセス再起動・継続で83＋20＝103項目PASS。書込48.18秒、読込35.76秒、終了コード0。ゲーム状態JSON一致。再起動後画像で4日目00:00、帳簿一致、営業利益＋346Gを確認。
+
+続く戦闘途中の別プロセス保存復元は、実際の有料受付建設・通常採用・スクロールとviewportクリックによる参加/対象登録/開始・2分後の通常UI保存・終了・再起動・残り間隔・次波クリック・時計による撃退まで19＋19＝38項目PASS。書込3.22秒、読込2.33秒。途中と最終の全ゲーム状態JSONと型付きdigestが一致し、採番・乱数・資金・職員・施設を保持。脅威作成のみ開示fixture。画像4枚のうち読込後の撃退画面を目視確認。前のスクロール位置の画像も保全。
+
+証拠: artifacts/full-regression-after-defense-autonomy-2026-09-30/ (coverage-verification.json、source-start/end/change.json、verification.json、suites、opening-restart)。戦闘再開は artifacts/defense-autonomy-restart-2026-09-30/。対象と静的レビューは DEFENSE_CLOCK.md を参照。以前の144スイート結果は FULL_REGRESSION_BEFORE_DEFENSE_AUTONOMY.md へ保全。
+
+この結果は実装済みの試験と現在の2通しシナリオの合格。原本全実装、通常脅威発生、性能予算、長期プレイ、同じビルドのWindows実機は未完了。Windows配布更新は別証拠で記録する。

docs/plans/original-completion-2026-09-29/execution/FULL_REGRESSION_BEFORE_SELECTION_AUTOSAVE.md

@@ -0,0 +1,11 @@
+# 現行ソースの全回帰 — 手動選択復元・受付担当検索改善後
+
+2026-09-29。141/141スイートPASS。失敗・未実行・余分な実行・重複・ソースハッシュ差分0。合計678.83秒。
+
+全件PASS後の実描画通し試験は、新規開業・3回決算・保存・終了・別プロセス再起動・継続で83＋20＝103項目PASS。書込46.53秒、再読込34.53秒、終了コードともに0。ゲーム状態の比較は一致。保存読込後の受付の選択枠と詳細表示を画像でも確認。
+
+証拠: artifacts/full-regression-after-selection-restore-2026-09-29/。coverage-verification.json、source-start/end.json、verification.json、opening-restart/。以前の記録はFULL_REGRESSION_BEFORE_SELECTION_RESTORE.md。
+
+この結果は全原本実装・Windows実機・長期プレイ・性能予算の合格ではない。現在のWindows配布版はこれらの変更を含まない。
+
+後続変更: 自動保存・直接読込の選択復元を追加中。この全回帰結果には含まない。

docs/plans/original-completion-2026-09-29/execution/FULL_REGRESSION_BEFORE_SELECTION_RESTORE.md

@@ -0,0 +1,13 @@
+# 現行ソースの全回帰 — 営業履歴スナップショット軽量化後
+
+更新注記: GUIDE_ASSIGNMENT_SCAN.mdの受付担当検索の軽量化とSELECTION_RESTORE.mdの手動選択復元は本記録より後の変更。本記録の全回帰・配布・負荷結果にこの変更を含めない。
+
+2026-09-29。140/140スイートPASS、失敗・未実行・余分な実行・重複はすべて0。実行時間合計674.21秒。開始/終了および確認時のソースハッシュ差分0。
+
+全件PASS後の実描画通し検証は、新規開業・3回決算・保存・終了・別プロセス再起動・継続で80＋17＝97項目PASS。書込46.57秒、再読込34.75秒、双方終了コード0。ソース差分0、write-gameplay.jsonとread-gameplay.json一致。再起動後画面で3日目利益+346G、帳簿照合一致、日本語とドット施設・人物を確認。
+
+証拠: artifacts/full-regression-after-snapshot-reuse-2026-09-29/ の全ログ、expected-tests.json、coverage-verification.json、source-start/end.json、source-change.json、verification.json、opening-restart/。前回記録はFULL_REGRESSION_BEFORE_SNAPSHOT_REUSE.md。変更内容と個別性能測定はSNAPSHOT_CALL_REUSE.md。
+
+これは既存のソース試験と開業シナリオの合格であり、全原本実装・長期プレイ・性能予算・Windows実機の合格ではない。全スイート実行時間は性能基準の判定に使用しない。
+
+同一ソースからWindows開発確認版を生成。隔離PCK1,527項目、同PCKのmacOS実描画従業員操作132項目PASS。Windows実機は未確認。CURRENT_WINDOWS_PACKAGE.md参照。

docs/plans/original-completion-2026-09-29/execution/FULL_REGRESSION_BEFORE_SNAPSHOT_REUSE.md

@@ -0,0 +1,15 @@
+# 現行ソースの全回帰 — 防衛HUDの配置安定化後
+
+更新注記: SNAPSHOT_CALL_REUSE.mdの営業履歴軽量化は、この全回帰・配布記録より後の変更。追加後の全回帰と通し検証は実施中であり、本記録の合格に含めない。
+
+2026-09-29。140/140スイートPASS、失敗・未実行・余分な実行・重複はすべて0。実行時間合計783.88秒。開始/終了および確認時のソースハッシュ差分0。
+
+初回の防衛HUD追加では、表示行の増減で従業員欄が動き、取消後のドラッグ再配置に失敗した。防衛サマリーを常設して修正。初回失敗ログはartifacts/full-regression-after-defense-hud-2026-09-29/に保存し、今回とは区別。
+
+全件PASS後の実描画通し検証は、新規開業・3回決算・保存・終了・別プロセス再起動・継続で80＋17＝97項目PASS。書込62.34秒、再読込47.24秒、双方終了コード0。ソース差分0、write-gameplay.jsonとread-gameplay.json一致。再起動後画面で3日目利益+346G、帳簿照合一致、日本語とドット施設・人物を確認。
+
+証拠: artifacts/full-regression-after-defense-hud-fixed-2026-09-29/ の全ログ、expected-tests.json、coverage-verification.json、source-start/end.json、source-change.json、verification.json、opening-restart/。前回記録はFULL_REGRESSION_BEFORE_DEFENSE_HUD.md。
+
+これは既存のソース試験と開業シナリオの合格であり、全原本実装・長期プレイ・性能予算・Windows実機の合格ではない。今回のソースの配布版検証は別途CURRENT_WINDOWS_PACKAGE.mdへ記録する。
+
+配布追補: 同一ソースからWindows開発確認版を生成し、隔離PCK677項目とmacOS実描画の従業員操作132項目PASS。CURRENT_WINDOWS_PACKAGE.md参照。Windows実機は未検証。

docs/plans/original-completion-2026-09-29/execution/GUEST_DECISION_LOG.md

@@ -0,0 +1,31 @@
+# 来客の行先判断記録 — 2026-09-29
+
+原本11.2の思考ログ、計画P15/P24への部分実装。現行の自律AIと `decide_guest` コマンドを同じ記録関数へ接続した。
+
+## 実装した挙動
+
+- 成功した施設選択・退館判断について、判断時の欲求、最大欲求、選択先、欲求優先度、比較評価、移動分数、待ち分数、見込料金を `GUEST_DECISION_RECORDED` イベントへ記録する。
+- 判断失敗は記録しない。実際の選択結果を保存し、表示時に候補選択を再実行しない。
+- 通常のHUD「来客」から、現在の欲求と直近判断時の情報を区別して確認できる。
+- 既存のイベント保存形式を使用し、ロード後も記録が残っている範囲では完全一致する。返す辞書はコピーし、観察画面から内部状態を変えられない。
+- 長い説明をスクロール領域へ収め、1280×720で閉じるボタンを画面内に維持した。
+
+## 範囲と制限
+
+全イベント共通の直近256件に含まれる記録のみ表示する。永続的な全行動履歴ではない。旧セーブ、判断前、履歴範囲外は「記録なし」と表示し、履歴を捏造しない。実際に利用開始した料金や現在料金ではなく、判断時点の見込料金を表示する。
+全候補の評価比較、除外理由一覧、ゲストの戦利品・種族反応等の残件は別途必要。原本11.2全体およびP15/P24全完了とはしない。
+
+## 検証
+
+- 自然到着・実際の自律選択による記録、選択先一致、保存復元、現在欲求変更後の過去記録不変、読み取り専用、失敗時記録なし、退館理由を試験。
+- 描画あり新規試験18チェックPASS。最初の描画でダイアログのはみ出しを発見し、スクロール対応後の画像で修正を確認した。
+- 既存来客観察22、GuestService137、Runtime来客循環40チェックPASS。循環試験には24時間の再生・完全スナップショット一致を含む。
+- 証拠: `artifacts/guest-decision-log-2026-09-29/`。最初の描画と修正後の描画を両方保存。
+
+前回のWindows配布ZIPにはこの変更は含まれない。
+
+追加境界: コマンド経由の候補が `price_gold` / `quoted_price` を使う場合も、GuestServiceと同じ優先順と非負補正で記録する。`price_gold=37` の実判断を追加し、0Gの誤表示を防止。新規追加試験の初回は20チェック中2件失敗（headlessでのウィンドウサイズ判定、料金別名ケース）。ウィンドウサイズを明示し、料金ケースに品質100と生存資金控除無効を指定して試験条件を修正。初期失敗ログを保持した。
+
+最終検証: 修正済みの同一テスト本文でheadless20、描画あり21チェックPASS。描画確認後に本文を本番テストパスへ保存した。実装ソースは通し試験中から変更なし。
+
+最終ソースの描画あり開業→保存→プロセス再起動→3日決算は80＋17＝97チェックPASS。実行中のソース変更なし、復元前後のゲーム状態JSON一致。証拠は opening-restart-final/。

docs/plans/original-completion-2026-09-29/execution/GUEST_REJECTION_LOG.md

@@ -0,0 +1,23 @@
+# 来客の候補除外理由 — 2026-09-29
+
+原本11.2・P15/P24の思考ログを拡張。来客の判断結果を作る際、GuestServiceが実際に返した除外理由を記録し、通常HUDの来客画面に表示する。
+
+## 実装
+
+- 閉店・稼働停止、経路なし、利用可能資金不足、到着期限、待ち時間、品質、危険度、利用条件等を日本語表示する。
+- 食材・資材不足は、以前はRuntimeの候補生成時に黙って除外されていた。除外自体は維持し、経路計算を行わず `inputs_available=false` の候補をGuestServiceに渡して `MISSING_INPUTS` を記録する。
+- 理由別件数は全件集計し、施設別の例は先頭8件を保存。省略件数を明記する。既存のイベント保存・復元を利用し、現在状態から過去の理由を再計算しない。
+- 古い判断イベントに理由情報がない場合は、理由記録なしと表示する。除外0件と混同しない。
+
+## 検証と限界
+
+新規の判断記録試験を28チェックに拡張しPASS、描画あり29チェックPASS。閉店9施設・経路なし1・資金不足1・食材不足1の計12候補について、実際のフィルター、正確な件数、8例への制限、画面表示、イベント復元を確認した。画像は境界試験用候補を通常UIで表示したもの。
+既存の来客観察22、GuestService137、Runtime来客循環40、商品管理42チェックPASS。
+初回のGDScript型推論エラーを修正し、失敗ログも保存した。
+
+候補の全比較順位や低評価・予約失敗による不選択の詳細はまだ表示していない。職員専用施設やチェックイン済み受付など、最初から検討対象に入らない施設も一覧化しない。履歴は全イベント共通の直近256件であり、永続的な全履歴ではない。
+原本全実装・P15/P24全完了の判定ではなく、Windows配布ZIPには未反映。
+
+証拠: `artifacts/guest-rejection-log-2026-09-29/`。
+
+描画あり通常営業→保存→終了→別プロセス読込→3日決算は80＋17＝97チェックPASS。ソース変更なし、再起動前後のゲーム状態JSON一致。opening-restart/に保存。

docs/plans/original-completion-2026-09-29/execution/GUIDE_ASSIGNMENT_SCAN.md

@@ -0,0 +1,13 @@
+# 開業案内の受付担当検索を一回の履歴走査へ変更
+
+2026-09-29。InnOpeningGuide._has_reception_assignmentを変更。該当職種の現在配置または繰返し勤務計画が見つかった時点で返す。繰返し計画のない職員IDのみを集め、シフト履歴を一度取得・走査する。従来は職員ごとに履歴全件のソート/列挙を繰り返していた。
+
+判定の意味は維持: 管理職は受付要員に数えない。現役受付要員は有効、勤務時間外の繰返し配属は有効。明示的な他施設への再配属があれば旧シフトで上書きしない。取消済み、現在時刻に終了、存在しない職員のシフトは無効。キャッシュを永続化せず、配属変更・読込は毎回の現状態を参照する。保存形式変更なし。
+
+旧/候補を決定的な500ケースで比較し全件一致。50人・1,000件の終了済み履歴・繰返し計画なしの模擬読取サービスで、交互100回ずつ計測: 旧平均5,970.79µs→新212.48µs。模擬サービスは配列を複製するがソートしない。この値は対象関数の特定ケースであり、ゲーム全体や本番UIの改善率ではない。
+
+恒久境界13、ダッシュボード149、初日営業63、従業員操作131、合計356項目PASS。続くmacOS実描画の開業・3回決算・保存・終了・再起動は80＋17＝97項目PASS。書込46.09秒、読込34.28秒、双方終了0。保存前後の営業状態一致、検証中ソース差分0。再起動画面で開業案内完了・3日目利益+346G・帳簿照合一致を視認。
+
+証拠: artifacts/guide-assignment-2026-09-29/。変更前、候補、差分比較、comparison.json、境界/関連試験ログ、opening-restart、verification.json。対象: scripts/ui/inn_opening_guide.gd、tests/ui/test_opening_assignment.gd。
+
+直前の140スイート全回帰およびWindows snapshot-reuse版はこの変更を含まない。変更後の全回帰・配布版・Windows実機は未検証。本番性能予算の達成、原本全実装の完了を示すものではない。

docs/plans/original-completion-2026-09-29/execution/LAYER_INTERFACE_SKIN.md

@@ -0,0 +1,15 @@
+# Persistent HUD layer skin
+
+Partial P23/P25, original B-12.4 and B-13.4. Removed the permanent green HUD override and restored the existing fantasy profile's parchment/brown/gold FRONT palette. BACK uses dark iron blue/grey panels, monitor-green selection and pale readable text. Main HUD frames, navigation/build/action buttons, headings and facility/staff information change with the normal layer button/Tab path. Dynamically constructed main buttons pick up the active layer. Existing warning colours remain semantic. No art files, asset rights or simulation schema changed. The current flat-frame art style remains; this is not acceptance of all final skin assets or BGM.
+
+Theme changes while the build palette was open left its old expanded height after collapse, causing five viewport-layout failures. Closing the palette now defers BottomBar.reset_size until theme/layout updates resolve. Styles also initialize in the current saved layer and traverse only on later layer changes, avoiding redundant startup work. Final main dashboard139 checks PASS. Native layer-skin11 checks PASS: normal BACK control, panel/text contrast palette, toolbar bounds, unchanged map coordinates, repeated exact FRONT restoration, paused time, initial BACK selection and subsequent FRONT restoration; includes2 captured images. FRONT/BACK screenshots visually inspected at1440x810.
+
+Remaining: auxiliary dialogs, opening guide and specialist panels still have their own skins; full surface skin integration, material texture polish, saved-game UI reload and Windows acceptance remain. This does not complete P23/P25. Evidence: layer-skin-native.log, layer-skin-dashboard-final.log, layer-skin-front.png, layer-skin-back.png and layer-skin-validation.json.
+
+## Opening guide follow-up
+
+The guide panel, body text and header/action button states now register with the shared layer skin. Startup receives the current layer; later toggles flow through the existing main layer path. Folding/unfolding explicitly schedules size recalculation even while paused, without changing guide progress or actions.
+
+Native16 checks PASS and dashboard139 checks PASS on this increment. Native checks include guide BACK palette, unchanged progress/action, paused collapse/reopen, exact FRONT restoration and existing-BACK startup. Current captures guide-skin-front.png and guide-skin-back.png; BACK image visually inspected. The first capture run reused layer-skin-front/back.png, so those older screenshot paths are superseded by this increment and the old manifest's screenshot hashes are historical, not current-file verification. Use guide-skin-validation.json for current evidence. No new assets were introduced.
+
+First operating day/save replay completed with59 checks,0 failures,exit0 (guide-skin-opening.log). Specialist panels/dialogs, final asset polish/BGM, Windows and broader original completion remain outstanding.

docs/plans/original-completion-2026-09-29/execution/LAYER_PRESENTATION.md

@@ -0,0 +1,29 @@
+# 表裏レイヤー表示・魔法レンズ切替（2026-09-29）
+
+原本B-2.2/B-12.2、P23の途中成果。表層では実在する裏層施設の部屋描画を低透明度で重ね、裏層では表層施設の占有輪郭を表示。建設サービスの正規配置から描画し、画面外は除外する。裏層の人物や未完成工事を表示する実装ではない。
+
+切替時に画面を読み取るGPUシェーダーで波紋状の屈折を0.55秒表示する。演出は停止中も終了し、人物のアニメーション時間やゲーム時刻を進めない。再切替は同一オーバーレイを再利用し、終了後は非表示。半透明描画ノードは入力を持たず、レンズControlは入力を透過する。選択は従来どおり選択層の占有データで判定する。
+
+描画中の施設一覧を1回取得して部屋・非選択層・施設ラベルで共有し、追加描画による一覧の重複コピーを避けた。キャッシュは描画終了時に破棄する。Windows高負荷時のGPU性能は未測定。
+
+検証: 最終ソースのmacOS実描画18検査PASS、直前のheadless15検査PASS。表裏で同座標の受付/倉庫、裏専用の待機室、非選択施設へのクリック禁止、座標維持、停止中の演出/人物時間分離、16回切替、全Runtimeスナップショット不変を確認。既存ピクセル画面243検査、ダッシュボード136検査、make checkもPASS（最後の描画用一覧キャッシュ追加前）。最終実描画はキャッシュ追加後のソースで実施。
+
+layer-front.png / layer-back.png / layer-ripple.png を確認。半透明の倉庫/待機室、表層の輪郭、波紋の屈折を目視した。既存Kenney素材をそのまま再利用し、新しい外部素材は導入していない。
+
+未完了: 建設中/旧設備を含む全異層表現、混雑時やx3連続切替の描画性能、Windows同一ビルド実機、表裏UIスキン/BGMなどP23/P25残件。P23全体や全原本実装の完了ではない。
+
+## Opposite-layer active construction (2026-09-29)
+
+Active construction reservations now appear in the opposite layer with amber hatching and a FRONT/BACK progress badge. They do not render completed room furniture. Geometry comes directly from reserved_cells and progress from ConstructionJob; blocked/planned jobs remain visible, completed/cancelled jobs are excluded. Completed jobs switch to existing facility art/outline. Drawing shares the job list with selected-layer construction labels for one frame, avoiding duplicate list retrieval.
+
+Final native32 checks PASS in layer-construction-final.log, including two ordinary construction commands, exact reserved footprint, real partial progress, opposite-layer hit isolation, full snapshot preservation, restore, cancel and normal completion. layer-front-construction.png and layer-back-construction.png visually inspected: opposite footprints and labeled progress are visible independently of active-layer hatching. Pixel camera regression243 PASS before the final per-draw job-list cache; final native suite compiles and exercises that cache.
+
+This removes the active-construction visibility gap. Legacy infrastructure representation, x3/high-load GPU tests, Windows same-build acceptance and remaining HUD/skin requirements remain open.
+
+## Opposite-layer legacy stairs (2026-09-29)
+
+LegacyStairService records now join opposite-layer visual data even when the viewing fixture has no ConstructionService. Each stair uses the same compact upper-landing rectangle as active-layer rendering/selection. FRONT shows the backyard stair glyph at low opacity; BACK shows the front stair outline. Active and opposite filters are disjoint. Legacy metadata is cached only during a draw so selected and opposite passes share one snapshot retrieval; query calls outside drawing still get defensive copies.
+
+Final evidence: layer-legacy-native.log30 checks PASS; layer-legacy-migration.log67 checks PASS; layer-legacy-regression.log27 checks PASS. Actual Runtime8/Path4 migration materializes two original vertical connectors; the BACK view contains exactly those two legacy IDs, and visualization leaves the entire canonical save unchanged. Native UI coverage uses a small canonical LegacyStairService fixture and checks compact geometry, selection isolation, and defensive metadata; both layer screenshots were visually inspected. No migration or path behavior was changed.
+
+The legacy stair visibility gap is resolved for these fixtures. This is not exhaustive acceptance of every old transport topology; other legacy infrastructure, x3/high-load rendering, Windows same-build and remaining HUD/skin requirements remain unverified.

docs/plans/original-completion-2026-09-29/execution/LAZY_PUBLICATION_DIGEST.md

@@ -0,0 +1,21 @@
+# Separate UI notification from digest computation
+
+UI subscribers do not need the digest; main uses snapshot settlement data. Added state_updated for these subscribers. Runtime still captures latest_snapshot at the same publication point; latest_digest now computes and caches its exact SHA on demand. When any legacy snapshot_published subscriber exists, its snapshot+digest notification remains eager and exact. Every publication invalidates the previous cached digest. No save format, history or simulation phase was removed.
+
+World preview and main/staff/business/supply panels prefer state_updated and retain a snapshot_published fallback for older test doubles. The notification carries the already-generated snapshot and omits only the digest. Callback defaults support the missing digest argument.
+
+Contract11 checks PASS: lazy invalidation/read caching, exact hash, legacy observer notifications, disconnect behavior and full-state equality between observed/unobserved replay. Registered under make test-perf.
+
+Same small production scene: x1 average33.536ms, x3 P95123.101ms, down from approximately62ms/230ms before. Still fails4ms/12ms budgets. Scene rendering, GPU, full-load and Windows excluded. latest_snapshot creation and infrastructure validation remain significant costs.
+
+UI regression session39911 ended with failure in the automatic midnight-ledger assertion. After fixing the snapshot payload, contract11 checks PASS; opening regression is running in session54965, log lazy-digest-opening-fixed.log. Do not claim final UI acceptance until the rerun finishes. Evidence: lazy-digest-contract.log and production-lazy-profile.json. This is partial P28 progress.
+
+UI regression caught the missing snapshot payload through the automatic midnight-ledger assertion. state_updated now carries latest_snapshot; no new snapshot or digest computation is introduced. Initial failed UI log is preserved.
+
+Final payload-fix rerun: contract11 and first-operating-day48 checks PASS, including automatic midnight-ledger presentation and deterministic next-morning replay. Core test-s0 also passed before the payload fix. The previous full UI invocation itself failed; broader post-payload UI rerun remains outstanding.
+
+## Full post-fix UI regression
+
+make test-ui completed with exit0 on the corrected snapshot-payload implementation. All17 direct Godot commands and both separate upkeep save/read processes passed; no ERROR output. Start/end hashes for131 source/test/build files are unchanged. Final opening48 checks includes the previously failing midnight-ledger presentation and next-morning replay.
+
+Evidence: lazy-payload-full-ui.log, lazy-payload-full-ui-validation.json and archived upkeep logs under artifacts/facility-dimensions-2026-09-29. This supersedes the earlier pending UI status. Performance budgets and Windows acceptance remain unresolved.

docs/plans/original-completion-2026-09-29/execution/LEDGER_INTERFACE_SKIN.md

@@ -0,0 +1,7 @@
+# 帳簿画面の表裏スキン
+
+P23/P24 の部分実装。帳簿の見出し・本文を共通パレットへ接続し、日付選択にも既存のボタンスタイルを適用。生成直後でシーンツリーへの追加前でも正しい色になるよう setup に初期レイヤーを明示的に渡す。共通レイヤー参照はツリー外の場合に絶対パス検索を行わない。
+
+検証対象は通常 UI で建設した閉店受付の所有時間維持費、日跨ぎ精算、帳簿表示、保存、別プロセスでの読込。追加のスキン検証は表裏で金額／決算テキスト／経済 snapshot が変わらないこと、表色への復帰、裏層の画面描画を確認する。原本全会計や全 UI 完了を意味しない。
+
+最初の試行でツリー追加前の絶対パス参照エラーを検出し修正。最終結果と SHA-256 は ledger-skin-validation.json。画像 ledger-skin-back-read.png は暗いパネル上で所持金4498G、維持費2G、未払い0G、損益−2Gが判読できることを確認した。ランク画面変更後にも両プロセスの試験を再実施し、headless write23/read14、macOS 描画あり write25/read16 が全件 PASS。

docs/plans/original-completion-2026-09-29/execution/MANAGEMENT_INTERFACE_SKIN.md

@@ -0,0 +1,9 @@
+# Supply and business layer skins
+
+Partial P23/P24/P25. Supply and business body text and result labels now use the shared layer palette. CheckButton text records its original colours and switches normal/pressed/hover/focus/disabled colours without changing the control value. Read-only layer lookup is shared; Runtime commands, drafts, inventory/accounting and save schema are unchanged. Buttons continue through the existing main style callback.
+
+Regression: supply42 and business65 headless checks PASS. Native runs43/66 PASS, each adding a BACK screenshot; both images visually inspected at1280x720. Existing suites exercise paid purchase/stock/money reconciliation, kitchen policy and logistics, business prices/open status, deferred commands, save/load and replay. Five new cases per suite cover refreshed BACK text, hover/disabled toggle colours, warning colours, FRONT restoration and unchanged policy-toggle value. Shared layer/guide14 checks PASS.
+
+Artifacts: supply-skin-headless.log, business-skin-headless.log, supply-skin-native.log, business-skin-native.log, supply-skin-back.png, business-skin-back.png, management-skin-layer.log; hashes in management-skin-validation.json.
+
+Remaining skin surfaces include ledger, rank/other dialogs and popup menus; final art/audio and Windows remain unverified. This does not complete the full original plan or all UI skins.

docs/plans/original-completion-2026-09-29/execution/MANA_INTEGRATION.md

@@ -0,0 +1,114 @@
+# P06 マナ枯渇・全館停止の実行準備
+
+2026-09-29。状態: 全館停止のRuntime接続と停電境界試験をローカル制作コピーへ反映済み。反映後の関連7本とmake checkがPASS。以下の準備時記録より末尾の進捗を優先する。原本全実装完了ではない。
+
+## 実証した差異
+
+原本B-9.1はマナ枯渇で全館機能停止を要求する。`artifacts/mana-2026-09-29/probe_zero_reserve.gd` は通常建設コマンドで受付を完成させ、その後に診断用として残量だけを0へ変更して時計を進める。490分時点で残量0、施設power_available=true、マナ網のgeneration=100、allocated=1を観測した。人員不足で受付そのものは未稼働だが、必要な電力停止条件が成立していない。これは診断フィクスチャであり、通常プレイの受入結果とは区別する。
+
+証拠: `artifacts/mana-2026-09-29/zero-reserve-probe.json` と `.log`。
+
+## 既存処理と接続先
+
+- GameStateのmanaは初期100の所持資源。ManaNetworkServiceの初期供給源は出力100で別管理。Runtimeの施設配電は10分周期の網評価でのみ変わり、所持マナ0を参照しない。
+- `_advance_mana` はstate_changesに現れた施設だけpower_availableを更新する。全館停止は差分の有無や施設の消費量0に左右されてはならない。
+- FacilityServiceはpower_available=falseで開始済みサービスを一時停止し、復帰時の再開処理を持つ。破壊・摘発のsuspension_reasonは独立して保持する必要がある。
+- KitchenProductionServiceはNO_POWER判定済み。枯渇がこのフラグへ届くこと、途中バッチと材料の所有権が保たれることを検証する。
+- `_advance_elevators` は各モジュールの網状態を参照する。全館停止とのAND条件が必要。ElevatorService.set_poweredには最寄り有効停止階への退避と、有効停止階がない場合の保持処理が既存。新たなテレポート規則を作らずこの契約を使う。
+- `_operations_arrival_boundary` は現在人口上限だけを捕捉する。停止時の入館抑止は決定的な境界として接続し、客IDや乱数の二重消費を防ぐ。
+- `_advance_inventory_and_logistics` は期限切れと配送を毎分進める。停電で時間・腐敗・費用を止めず、新規配送と搬送中荷物、救護同伴の扱いを分ける。
+
+## 原子受入と実装順
+
+| ID | 条件 | 現状 |
+|---|---|---|
+| MNA-01 | 供給・消費・余剰・不足が整数で一致し、負残量を作らない | 残量コンポーネント33項目PASS。施設別需要の集計/Runtime接続は残 |
+| MNA-02 | 残量0なら消費0の施設を含め全館停止 | 差異再現済み |
+| MNA-03 | 既存サービス・厨房の進捗/課金/材料が停止し再開で重複しない | 接続未検証 |
+| MNA-04 | EV乗客・救護同伴者が安全な階へ戻るか保持され、所有権が消えない | 網停電の既存処理あり、全館接続未実装 |
+| MNA-05 | 停止中の入館・新規物流を抑止し、在庫期限・時計・経費は進む | 未実装 |
+| MNA-06 | 復旧しても破壊・摘発の休止を解除しない | 既存状態分離あり、全館接続未検証 |
+| MNA-07 | 枯渇直前/直後/復旧直前の保存復元が一致 | 未実装 |
+| MNA-08 | 旧保存の残量を保全し、過去の消費を遡及適用しない | v11移行設計が必要 |
+| MNA-09 | HUDで残量・供給/消費・停止理由・復旧条件が分かる | 未実装 |
+| MNA-10 | 通常営業で自然に枯渇・復旧し、Windows配布版で再現 | 未検証 |
+
+数値非依存の残量計算・保存契約を実装した。次はRuntimeへ順次接続する。GameStateと専用サービスに残量を二重保持するなら照合を必須とし、どちらを正とするか曖昧にしない。新しい停止理由・更新順・移行はP03/P04にも記録する。
+
+## 未指定値
+
+D04の局所確認として、初期100・上限100・10分ごと世界樹供給5・既存maintenance_manaを同周期消費する試験開始案をユーザーへ質問した。未回答。確定値・原本記載値として本番へ適用しない。稼働中の消費条件、全館停止中は供給を蓄積して復旧可能にすること、同一境界で消費と再開を繰り返さないことを計算契約の試験対象にする。
+
+## 残量コンポーネントの実装
+
+`scripts/mana/mana_reserve_balance.gd` はレートや周期を決めず、呼出側から各区間の供給総量・需要総量を受け取る。供給を需要へ使用した後の余剰を容量まで蓄積し、供給不足と容量超過を別々に返す。保存には容量・残量・時刻・最後の収支を保持し、収支不一致や未知フィールドは拒否する。失敗時に既存状態を変更しない。同一時刻・同一入力は再送扱い、同一時刻で異なる入力は拒否。
+
+保存版1のコンポーネント試験 `tests/s2/test_mana_reserve_balance.gd` は33項目PASS。証拠は `artifacts/mana-2026-09-29/reserve-balance.log`。供給を先に容量で切り捨てると同一区間の需要に使えるマナを失うため、需要充足→余剰蓄積の順を採用した。これは計算契約であり、原本明示値として扱わない。
+
+まだRuntimeから呼ばれていないため、MNA-02の不具合は未修正。本番供給量・消費間隔は未決定。既存の維持費回帰対象240ファイルは変更していないが、この新規コンポーネント2ファイルはその回帰には含まれず、別の上記試験で検証した。
+
+## 全館給電条件の反映コンポーネント
+
+`scripts/mana/mana_power_projection.gd` を追加。残量>0と網のACTIVE/DEGRADEDをANDで判定し、消費者ノードを持たない無消費施設にも残量0を適用する。施設の営業方針・耐久・依存先・休止理由には書き込まない。供給不足の理由だけを更新し、変化がなければ状態更新を繰り返さない。
+
+`tests/s2/test_mana_power_projection.gd` は実FacilityService/ManaNetworkServiceを使って14項目PASS。残量0の全施設停止、消費0の停止、摘発休止の維持、手動閉店の維持、部分給電、復元後の復旧、負数入力拒否を確認した。初回に試験定数名がGodot組み込みProjectionと衝突し、修正後にPASS。ログ `power-projection.log` と `power-projection-recheck.log` を保持。
+
+Runtimeへの接続は未完了で、通常プレイの残量0不具合はまだ解消していない。接続時には全ての正消費施設を先にマナ網へ登録すること、電力フラグの正本をこの投影処理に統一することが必要。呼出中の外部コールバック失敗はRuntimeの既存トランザクションに含めて扱う。EV・入館・物流の停止はこの施設フラグだけで完了扱いにしない。
+
+## Runtime接続の作業用コピー
+
+固定ソース回帰を混在させないため、`mana-staging.json` の作業用コピーで実Runtimeへ接続した。毎分の施設給電、無消費施設の停止、EV給電、新規入館の上限0、新規補給生成の抑止、開始直前の残量確認、完成直後の停電反映を追加。物流の搬出/搬入可否へpower_availableを接続し、期限切れ処理と搬送中荷物の所有権は保持する。
+
+`test_runtime_mana_depletion.gd` 15項目PASS。通常建設した受付と一般客室を使い、10分周期の外でも残量0で停止すること、全Runtime保存復元、供給回復後の破壊休止維持を確認した。残量の変更は診断入力であり、自然な消費・回復のバランス試験ではない。
+
+初回に建設完了から最初の配電評価までの既存契約を変えて営業回帰が失敗した。未評価ノードの既存状態を保持し、残量0だけは必ず優先する修正後、既存営業循環52項目がPASS。営業と物流の関連試験もPASSし、EV回帰は継続中。詳細は作業用コピーの `mana-validation-recheck/results.json`。制作コピーへの反映は未実施。パッチは `artifacts/mana-2026-09-29/staged-runtime/runtime-integration.patch`。
+
+次の受入は、実乗車中のEV枯渇、利用中サービスの課金/一時停止、荷物搬送中の停電。数値未回答を理由にこれらを省略しない。新しい有限残量計算コンポーネントの周期・供給・消費への接続と保存契約も未完了。
+
+
+## 停電境界の追加受入（作業用コピー）
+
+- 接客循環58項目PASS。利用中の停電で5分間の進捗と財布・材料所有数を保持し、停電保存を復元後、配電評価と接客完了を待って25Gを一度だけ課金した。最初の試験は未評価ノードの復旧を3分後と仮定して失敗。既存の10分配電境界を待つ試験へ修正しPASS。初回失敗ログも保存している。
+- 物流109項目PASS。積載済み8個を停電中30分保持し、納入0、保存復元と所有権照合を確認。復旧後に一度だけ納入して積荷0・納入先8となる。
+- EV37項目PASS。実乗車中に残量を0へ変更し、有効停止階への緊急到着イベントが各乗客に一度だけ発生すること、経路要求の解消、停電保存復元と再給電を確認した。救護同伴者や有効停止階なしの全館停電は別途残る。
+
+証拠: `artifacts/mana-2026-09-29/staged-runtime/outage-validation.json` と同階層のログ。残量変更のみ診断入力であり、自然な消費・回復ではない。本番の供給量・消費間隔は未回答で適用していない。P06全体、画面・配布版受入の完了を意味しない。
+
+
+## 更新順の確認（P04連携）
+
+SimulationKernelの順序はコマンド→時刻境界→MANA→建設→物流→施設完了→生体/環境→事件→施設待機列→AI→公開保存。施設完了でサービス、続いて厨房を更新する。AIでEV、その後救護を更新する。したがってMANAで給電を確定してから同じ分の物流・接客・生産・EVへ適用される。建設はMANAの後なので、新規完成施設にも残量0を登録時に反映する。入館境界は施設状態の更新待ちにせず残量を直接確認する。
+
+停止・復旧は給電条件のみを更新し、破壊/摘発の休止理由を解除しない。毎分判定しても給電と減力理由が変わらない施設は状態更新を発行しない。既存の障害復旧suffixも同じMANA→建設→物流→施設の順序を呼ぶ。残量計算を将来MANAへ接続する際は、供給/消費の確定をこの給電投影より前に置く必要がある。まだ未接続なのでこの記録を有限残量収支の受入完了とはしない。
+
+
+## ローカル制作コピーへの反映
+
+維持費の固定ソース回帰98本が終了。240ファイルのSHAが開始時と一致した。97本は初回PASS、営業管理UIの説明文期待値だけ1件失敗し、「給与と施設維持費」へ更新した試験を本体で再実行して60項目PASS。初回結果は上書きせず `artifacts/upkeep-2026-09-29/frozen-regression/final-gate.json` に再試験と併記。
+
+その後、作業用コピーの8対象ファイルについて本体の変更前SHAと候補SHAを照合して反映した（UI期待値修正1、マナ対応7）。`mana-staging.json` のproduction_applied=trueを参照。現在の本体は既存の98本回帰時から変更されているため、あの98本をマナ統合後の全体PASSとは扱わない。反映後の部品/Runtime/接客/積荷/EV/性能試験とmake checkは `artifacts/mana-2026-09-29/production-integration` へ記録する。
+
+反映後の7本は全PASS、make checkも終了コード0。部品33/14、Runtime15、接客58、物流109、EV37項目を再確認し、性能回帰もPASS。対象8ファイルのSHAが作業用コピーの検証済み候補と一致することを確認した。未完了条件は前述のとおり。
+
+
+## 厨房・救護同伴・HUDの追加受入
+
+制作コピーで追加検証。厨房は通常建設と購入配送済み8個の食材、雇用・配置した調理職員を使用。調理3分の時点で残量を0にし、30分の停電中にバッチID・予約・進捗が不変、原料8/完成品0、完全保存復元後の復旧で原料4/完成品4となることを確認した。物流試験全体121項目PASS。
+
+救護同伴の実乗車中に残量を0にし、職員と患者が同じ有効停止階へ退避。20分停止しても患者は未治療で位置保持、完全保存復元が一致。給電回復後は同じ患者の救護・治療が完了し、所有権の不整合なし。救護EV試験全体30項目PASS。患者の体調とマナ0は診断入力であり自然発症/自然枯渇ではない。
+
+HUDは残量0を「マナ 0・停止」と警告色で表示。ツールチップで停止範囲、残量と配電の回復、破壊・摘発の休止は解除されないことを説明。復旧で通常表示・元のテーマ色へ戻る。実描画のダッシュボード131項目PASS、outage-hud.pngを目視確認。サービス直呼びの代用画面ではなく本番シーンだが、OSのポインター操作/Windows受入は未実施。
+
+証拠: `artifacts/mana-2026-09-29/kitchen-rescue-ui-validation.json`。有限残量の自動収支/供給・消費表示/旧保存への新収支モデル移行/通常営業での自然枯渇復旧は未完了。有効停止階が全て失われた場合の停電受入も残る。
+
+
+## 有効停止階なしの停電（Runtime境界）
+
+`test_runtime_transport.gd` に実乗車中の全停止階封鎖→残量0の受入を追加。安全な降車先がない間は乗車状態と経路所有権を保持し、20分経過しても残り移動時間を進めない。全Runtimeの保存復元が完全一致することを確認する。その後、停止階の封鎖と停電を解除して移動を再開し、乗車要求と経路要求が残らず、復旧後も保存できることを確認する。これは交通障害と残量の診断入力を用いるRuntime試験であり、通常プレイの自然枯渇を証明しない。結果は `artifacts/mana-2026-09-29/no-landing-outage.log` を参照。
+
+
+## 旧保存の残量0境界
+
+維持費導入前のv9形式フィクスチャ（新規建設後、旧形式への変換とupkeep項目の除去）を使用。残量0・古い給電フラグありの状態を読込し、入力セーブを変更せず残量/時刻/停止を保全。読込以前の維持費を課さず、最初のTick前でも新規入館の許容数は0。再開後はMANAがサービス・物流・EVより先に古い給電状態を停止へ反映する。負のマナを入れた破損保存は現在の完全スナップショットを変えず拒否した。Runtimeマナ試験21項目PASS。
+
+注意: 古い給電フラグそのものは停止中の読込直後に書き換えず、次のTickで更新する。即時正規化した保存への移行や、新たな有限マナ収支モデルの移行まで検証したわけではない。証拠 `artifacts/mana-2026-09-29/legacy-zero-save-validation.json`。

docs/plans/original-completion-2026-09-29/execution/MVP_CATALOG_MANIFEST_CACHE.md

@@ -0,0 +1,29 @@
+# Catalog manifest の反復生成を削減
+
+2026-09-30。制作ソースへ適用済み。同じソースの全回帰・実描画・再起動・更新Windows配布を検証済み。
+
+Runtime が完全 snapshot を作るたび、同じ catalog から顧客定義32個と class/species entry64複製を生成して manifest のID一覧だけを読んでいた。catalog object と rebuild世代が同じ場合は、元builderで作った private manifest を再利用する。返り値は初回・再利用とも全階層を複製し、呼出元の改変を次の状態へ持ち込まない。catalog rebuild、初期化、成功した復元で無効化。復元候補の一時catalogは毎回元builderで検証し、失敗した復元は現行cacheを変更しない。
+
+元builderと GuestDefinition 全フィールドの復元比較はbyte同一。保存schema12とmanifest version2を維持し、既存のchapel前manifest version1も従来の限定条件で読める。新しいbalance値は導入していない。
+
+普通の独立コピー2組でABBA順に測定。各実行はx1/x3をそれぞれ200回。実際のRuntime一分更新とそのbatchのdeferred dashboard更新を時間に含める。小さな営業シナリオ（7施設・初期4従業員）であり、GPU描画・高負荷条件・Windows native・長期経済の受入には使わない。各variant2回の平均を比較する。
+
+| 測定 | 変更前 | 採用候補 | 短縮 |
+|---|---:|---:|---:|
+| x1 更新平均 | 12.052 ms | 10.789 ms | 10.48% |
+| x3 更新P95の2回平均 | 63.445 ms | 52.130 ms | 17.84% |
+| x1 snapshot公開phase平均 | 5.383 ms | 4.420 ms | 17.88% |
+
+元のx1平均4ms・x3P9512msの目標は未達。直接のmanifest再読込は候補で2.20/2.25µs、変更前803.50/997.60µs。cold missと復元用temporary catalogは元の全生成を行う。
+
+各4実行のcheckpointとfinalは store_var の保存byte全体が一致し、domain eventsも除外していない。保存byteのSHAを complete-state-byte-verification.json に記録。乱数、採番、イベントdigestも一致。
+
+隔離環境の専用確認はreference39＋candidate44項目PASS。候補でcatalog216・Runtime content116・snapshot ownership89・SaveOperations127・Runtime save96・防衛自動周期188＝832項目PASS。採用後の本番専用回帰は79項目PASSし、キー型・配列型・canonical bytes、nested mutation、rebuild失敗と復帰、catalog交換、旧保存、破損保存の原状保持、late guest登録、完全tick再実行を確認。最初の集計driverは結果表記の判定とresume読取に誤りがあり、成功した元ログを initial-driver-matcher-errors/ に保全してrunnerを修正した。ゲーム側の失敗ではない。
+
+証拠は artifacts/manifest-cache-evaluation-2026-09-30/。独立静的監査は artifacts/snapshot-publication-major-audit-2026-09-30/。元の候補manifestのuncompiled/unmeasured記述は作成時点の記録で、採用と実測は新applied-manifest.json/measurement.jsonに記録する。
+
+原本全実装、性能目標、高負荷/Windows、実プレイ時間は未完了。
+
+## 採用後の統合確認
+
+147/147スイートPASS（708.21秒）、開業・決算・別プロセス再起動103項目PASS、関連描画403項目PASS、戦闘途中の別プロセス保存復元38項目PASS。各入力差分0。全回帰の79 cache回帰もPASS。現行Windows版は17 PCK実行2,639項目PASSで、packed cache80判定を含む。実描画とPCKはmacOS実施。最終証拠は verification.json と CURRENT_FULL_REGRESSION.md / CURRENT_WINDOWS_PACKAGE.md。

docs/plans/original-completion-2026-09-29/execution/NEXT_MECHANICS_AUDIT.md

@@ -0,0 +1,31 @@
+# 次の機能接続の現行ソース確認
+
+2026-09-29。全体回帰実行中の読み取り監査。実装・数値は変更していない。
+
+## P17 ミミの仕入れ・売却補正
+
+原本6.2は仕入れ-20%、売却+20%。現在のunique_charactersはアンリとライのみ。SupplyManagementService.preview_purchaseはSupplyCatalogの単価を直接使用し、購入可能最大数と合計金額を計算。purchaseも同じ見積を使い、PLAYER_CASHからOPERATING_EXPENSEへ決済する。SupplyManagementPanelはカタログ単価を直接表示するため、将来補正時は見積の実単価・合計との一致が必要。
+
+通常仕入れは原材料1個3G。20%減を単品丸めすると2Gまたは3Gとなり、合計額丸めとは結果が異なる。例として5個購入は合計15G→12G、単価を2Gに丸めれば10Gになる。原本は端数方法、配置先と適用範囲、加入時期を定めていない。原本未指定値の包括的試験設定権限の回答は未取得なので、勝手に確定しない。
+
+供給UIのタブは仕入れ・厨房・配送。通常商品の売却入口と売却基準価格は未実装。RuntimeのSERVICE_SALEは顧客サービス利用料金の精算であり、これをそのまま商品の売却と見なさない。仕入れ補正だけでミミ全効果完了としない。
+
+次の縦断実装では、適用根拠付き見積→UI単価/合計→決済→数量/帳簿→保存復元・再送を揃える。加入・適用範囲・端数・商品売却の基準値は決定後に本番接続する。
+
+参照: baseline-fetched-2026-09-29.txt:118–124、data/characters/mvp_unique_characters.json、scripts/supply/supply_management_service.gd、scripts/supply/supply_catalog.gd、scripts/ui/supply_management_panel.gd:234、autoload/simulation_runtime.gd:11209。
+
+## P21 防衛の通常プレイ入口
+
+Runtimeには襲撃作成・防衛者/目標登録・開始・取消のコマンドがあり、従業員画面は参加中の配属変更を拒否できる。今回の回帰は実コマンドによる防衛fixtureであり、通常営業からの脅威発生を証明しない。main.gdとscripts/uiには防衛の準備/開始/撤退を操作する画面がない。警告→準備→戦闘→結果の通常UI、借金滞納との接続、砲台と能動スキルの入口を別受入として残す。
+
+P17/P21は未完了のまま。回帰PASS数をこれらの完成判定に使わない。
+
+## P17 24時間勤務と既存残業の区別
+
+防衛HUD追加後の全回帰中に読み取り確認。原本6.5は警告を無視した24時間勤務とストレス激増を要求する。現行StaffService.set_work_assignmentはDAY/NIGHTのみを受け付け、ShiftInstance.create_standardも同じ2種類。StaffRuntimeにはstressとis_overtimeがあり、ShiftInstanceにはworked_minutes/overtime_minutesが保存されるが、これだけで原本対応済みとは判定できない。
+
+既存の残業は、シフト終了時に中断不可作業が残る場合、または予約解放が失敗する場合の継続処理。任意の24時間勤務への警告と継続選択ではない。scripts/autoload内のadd_stress呼出しを調べたところ、定義のみで呼出元はなかった。勤務によるストレス増加の接続は別途必要。
+
+次の実装では、警告への継続/中止応答、実際の連続勤務区間、休息による区切り、保存復元時の同意と時間、重複コマンドへの耐性を揃える。シフト別の累計勤務分数をそのまま連続勤務時間へ転記しない。通常の業務終了待ちをユニーク人物の過労同意と扱わない。ストレス係数は原本未指定であり、試験値の包括承認は未回答のため未確定。
+
+参照: scripts/staff/staff_service.gd:set_work_assignment/_update_shift_states、scripts/staff/shift_instance.gd:create_standard/record_duty_minute、scripts/staff/staff_runtime.gd:add_stress。今回、製品コードや試験ソースは変更していない。

docs/plans/original-completion-2026-09-29/execution/OPENING_RESTART_DEBUG.md

@@ -0,0 +1,25 @@
+# Natural opening and fresh-process continuation debug
+
+Prepared `tools/run_opening_restart_flow.py` and `tests/ui/fixtures/opening_restart_flow.gd` as a continuation of the normal opening scenario. The original first-day flow uses default funds, construction/hiring/assignment UI handlers and natural arrivals; it does not insert guests or sales. The restart extension uses the actual dashboard Save button and load menu with a unique test-only slot.
+
+Write phase: complete the existing opening flow through day2 08:00, save using the dashboard, load the same saved state, continue naturally through day4 00:00 (three closed days) and retain the expected gameplay digest and complete three-day financial reports. Read phase: a separate Godot process creates the normal main scene, loads the same slot via the menu, advances to the same third close and compares results. The digest excludes only the domain-event stream because SAVE_LOADED records measured wall time; ID counters, random streams and every other captured gameplay subsystem remain included. Both phases independently require three balanced closes, no Runtime failure latch and the latest close displayed in the ledger.
+
+The fixture lives under fixtures and is invoked only by its two-process runner. It is intentionally not a standalone test*.gd in the source sweep, which would not provide a shared isolated slot or paired phase. Python compilation and Godot --check-only passed before execution. A rendered run additionally retains screenshots. Execution results must be read from the runner's result.json and logs; preparation alone does not establish a pass.
+
+This covers the currently available simple inn over three days, not all original facilities, story routes, loans/defense or long-term balance. It is accelerated simulation with real UI handlers, not manual pointer validation or Windows acceptance. Production performance budgets remain independently unmet until measured otherwise.
+
+## First rendered run and visible defect
+
+Initial rendered run completed both processes: write77 and read14 checks, total91 PASS, both exit0, and source-change.json empty. All three closes balanced; net profits were -64G, +346G, +346G. The full gameplay snapshot (excluding the timed domain-event stream) and all financial reports matched across process restart. Saved-second-morning and restarted-third-close screenshots were visually inspected.
+
+Visual review of restarted-third-close.png revealed an additional UI defect: corridor/stair upkeep rows displayed raw facility_... IDs. OperatingLedgerPanel resolved names only through the service-instance registry, while transport/pass-through infrastructure is stored in completed construction. Added a construction-entity fallback that resolves the display name and coordinates without modifying accounting. The restart fixture now checks readable infrastructure names on both sides of the process boundary. Rerun output is isolated under artifacts/opening-restart-debug-2026-09-29/ledger-name-fix; retain the original screenshot as before evidence.
+
+The127-suite source sweep predates this ledger display correction. The rerun provides targeted UI and three-day/restart coverage for this final change; it does not rewrite the earlier sweep's source scope.
+
+## Final corrected run
+
+Rendered rerun completed: write80 and read17 checks, total97 PASS, both exit0. No tracked source changed during this run. Final validation.json records the result and screenshot hashes. Final uninterrupted-third-close.png shows guest corridor/stair names and coordinates instead of internal instance IDs. Full gameplay comparison (same explicit timed-event exclusion), all three financial reports, latest-report UI, natural advancement and ledger balances passed again after the correction. No manual pointer/Windows/full-original completion is implied.
+
+## Reverified after infrastructure and snapshot optimizations
+
+After all128 source suites passed on frozen source, rendered writer80/reader17 passed again (97 total). Artifacts: artifacts/snapshot-opening-restart-2026-09-29. Both processes exit0, source-change.json empty; three balanced closes remain -64,+346,+346G. Full continuation comparison and ledger labels pass. Final screenshots reviewed on macOS; Windows/manual-input/complete-original scope remains outstanding.

docs/plans/original-completion-2026-09-29/execution/OPERATIONS_KEYPASS_TRIAL.md

@@ -0,0 +1,5 @@
+# 営業スナップショットのキー変換共有試験
+
+キーの重複検査とエンコードで文字列化結果を共有する変更を比較した。同一営業状態を変更前後それぞれ100回、交互に保存。出力の一致は100回確認できたが、平均2038.87µsから2141.25µs、P95は2143µsから2260µsへ悪化したため採用しない。製品コードは試験前の内容へ復元済み。
+
+証拠: `artifacts/operations-keypass-2026-09-29/comparison.log`、`interleaved.json`、`before.txt`。先行2回の参照実装ハーネスの構文エラーは失敗記録として残す。全体フレーム、Windows、性能予算の合格を示す試験ではない。

docs/plans/original-completion-2026-09-29/execution/OPERATIONS_SNAPSHOT_COPY_REDUCTION.md

@@ -0,0 +1,9 @@
+# 営業状態スナップショットの重複コピー削減
+
+P28 の部分改善。create_snapshot の履歴・朝レポート・日次決算・通知・隔離レポートは、最終の _to_snapshot_variant が辞書／配列を再帰的に新規生成する。その前段の duplicate(true) を取り除き、一時的な参照を同期メソッド内だけで使う。公開 getter の防御コピー、型／容量／形状検証、決定的なキー順、保存形式は維持した。参照を外部へ渡すコールバックや await はこの処理中にない。
+
+回帰: Operations233、Runtime Operations51、開業UI59項目 PASS。追加3項目は、返却された全辞書／配列を再帰的に変更してもライブ状態が不変であること、履歴が進んでも以前の保存を復元できること、同じ決算コールバックで復元再生した結果が一致することを確認する。最初の追加試験は復元側の決算コールバックが欠けて不一致となり、同一 fixture での比較へ修正した。既存230項目に失敗はなかった。
+
+同じ小規模実ゲーム測定で変更前→後: 営業スナップショット平均3.612→3.550ms、全スナップショット8.040→7.830ms、通常速度平均14.503→14.256ms、3倍速P95 54.366→52.113ms。単回比較のため改善幅を保証しない。目標4ms／12msは依然 FAIL。ヘッドレスでGPU／Windows／大規模負荷は対象外。
+
+証拠とソース SHA-256: artifacts/facility-dimensions-2026-09-29/copy-reduction-validation.json。最新変更後の全UI一括実行ではなく、保存と開業への関連回帰である。全原本完了ではない。

docs/plans/original-completion-2026-09-29/execution/OPERATIONS_SNAPSHOT_ENCODING.md

@@ -0,0 +1,17 @@
+# Operations snapshot validation and encoding
+
+OperationsCoordinator.create_snapshot validated the assembled output tree and then traversed it again to canonicalize all containers. The new shared visitor can validate alone or validate while constructing the detached canonical output. Internal-state validation and shape checks are retained; only the final output validation/conversion passes are combined. Canonical String keys are sorted by the engine after insertion instead of repeated Variant string comparator callbacks. The project targets Godot4.7, matching the tested runtime.
+
+Safety contracts remain: depth/node/collection/string budgets, finite numbers, permitted key types, collision rejection before conversion, original insertion-order error precedence, fully detached nested arrays/dictionaries, and exact canonical ordering. Failure returns no partially encoded value. Snapshot version and public saved schema are unchanged. The standalone canonical converter remains for existing restore comparisons.
+
+Coordinator300 checks PASS (46 added for the checked-encoding path), ownership87, Runtime save/recovery96, midnight29, and Runtime operating integration51:563 targeted checks PASS. Source stayed fixed throughout that selected regression. Interleaved old/new comparison additionally checks100 byte-identical complete Operations snapshots on the same production-derived state, alternating timing order.
+
+Interleaved microbenchmark: old2384.77us average/P952441us; new1999.03us/P952051us (about16% lower). The old implementation is retained as operations-before.gd.txt; reference_operations.gd adapts only standalone class/self-construction typing so both versions can be loaded together. Initial adapter parse failures are preserved separately and were fixed before the successful interleaved-final.log run. The game did not fail these harness-only attempts.
+
+One paired full small-scene profile: Operations2466.65→2027.6us; whole snapshot5884.1→5382.55us; x1 update11417.825→10867.475us; x3P9537096→35841us. Same seed424242, macOS AppleM4/Godot4.7.2 headless,40 samples per speed, deferred dashboard flush included, autosave/GPU excluded. The4ms/12ms budgets still FAIL. This is not Windows/full-load/long-term acceptance.
+
+Evidence: artifacts/operations-encoding-2026-09-29/validation.json, regression.json, source-start/source-change, change.patch, before/final-profile.json, interleaved.json and logs. Previous128-suite complete regression predates this change. A rendered three-day opening and separate-process continuation is running in opening-restart (session64200); do not count it passed until both phases finish.
+
+## Rendered restart complete
+
+Both phases finished with exit0: writer80 and reader17,97 checks PASS (targeted plus continuation660). No production/data/test source changed during either phase. Three closes balanced with net profits -64,+346,+346G. Full gameplay state except timed domain events and complete reports match the uninterrupted path. Both third-close screenshots reviewed: Japanese ledger labels, balances and guest/staff scene intact. This is the current optimized source, still not latest Windows executable acceptance or complete original feature coverage.

docs/plans/original-completion-2026-09-29/execution/OPERATIONS_SNAPSHOT_PROFILE.md

@@ -0,0 +1,37 @@
+# 営業履歴スナップショットの軽量化試行
+
+2026-09-29。P28。状態公開フェーズ内のスナップショット生成に注目し、OperationsCoordinatorの辞書キー二重文字列化を調査した。
+
+同じデモ状態を復元した変更前・変更後のインスタンスを交互に200回ずつ測定し、全400回の出力辞書一致を確認。
+
+- キー文字列を配列へ保存して再利用する案: 旧平均1570.25µs/P95 1660µs、新1652.045µs/P95 1725µs。約5.2%遅いため不採用。
+- Stringキーのstr変換だけを省く案: 旧平均1570.865µs/P95 1613µs、新1621.955µs/P95 1663µs。約3.3%遅いため不採用。
+
+両案を取り下げ、検証済み配布版のソースマニフェストと全ファイルの一致を確認。検証や保存の安全性を削って高速化したことにせず、製品コード変更0。
+
+現行版を40サンプルずつ再計測: x1平均9734.7µs、x3 P95 34201µs。目標4000/12000µsは未達。スナップショット平均5156.8µs、うち営業集計スナップショット平均2048.2µs。前回の値との差は別実行のばらつきを含むため改善とは主張しない。
+
+計測は小規模な使い捨てデモ、macOS headless、オートセーブ無効。同期Tickに遅延ダッシュボード更新を含むが、GPU描画やWindows、高負荷の最終受入ではない。
+
+初回比較ドライバーは参照クラスの戻り値型が元クラス名のままでコンパイル失敗し停止。対象プロセスを終了し、参照ドライバーの戻り値注釈だけを調整して再実行。失敗ログはinitial-driver-error.logに保全。
+
+次の調査対象は営業履歴全体に対する保存可否検査・正規化・コピーの各費用。検査省略や履歴の無断切捨てではなく、エラー優先順・深さ/ノード/文字数上限・正規順・所有権を維持した最適化が必要。
+
+証拠: artifacts/operations-key-profile-2026-09-29/。before.gd.txt、参照ドライバー、却下した2案、paired JSON、current-baseline.json、verification.json。前回140スイート・通し97項目・配布版は変更されていない。
+
+## 同一状態の工程別計測
+
+200回、全回で元スナップショットとの一致を確認。計測用コピーへの時刻取得挿入による値であり、本番全体の改善率には使用しない。
+
+| 工程 | 平均µs | P95 µs |
+|---|---:|---:|
+| 内部値の保存可否検査 | 694.115 | 714 |
+| コレクション形状検査 | 1.340 | 2 |
+| 出力項目の組立 | 38.825 | 41 |
+| 出力検査・正規化・ソート | 805.315 | 829 |
+
+内部検査と出力検査は異なる構造・上限を確認するため、そのまま重複とみなして削除できない。入力で不正な値が出力への変換で隠れるケースも保持が必要。
+
+辞書キー型の配列内検索をmatchへ置換する第3案は、別の計測用コピーを用い、従来版と交互に200回ずつ比較。旧平均1563.045µs/P95 1605、新1596.075µs/P95 1647。約2.1%遅く、改善を確認できないため不採用。全400回の辞書一致。製品ソースは編集していない。
+
+証拠: `artifacts/snapshot-stage-profile-2026-09-29/` の計測ドライバー、stages.json、paired.json、各ログ、verification.json。最新配布版のソースマニフェストに記録された全ファイルのハッシュ一致を再確認。性能予算は引き続き未達。

docs/plans/original-completion-2026-09-29/execution/ORIGINAL_FACILITIES_EXPORT.md

@@ -0,0 +1,13 @@
+# 原本施設統合の配布データ検証（2026-09-29）
+
+P10/P12の途中成果をWindows Desktopリリース形式に出力した。成果物は `build/windows/original-facilities-2026-09-29/TheTree.exe` と同名PCK。EXEはPE32+ x86-64。全原本実装・P29完了ではない。
+
+通常登録21施設とパレット、受付・上級客室・倉庫・従業員宿舎の実建設、原本寸法、承認済み0.5%維持費、ディスク保存と全ゲーム状態復元を検証。配布PCKのみを一時ディレクトリから読み、ソース資源へのフォールバックがないことを検査した。テストスクリプトは外部から渡し、施設/UI/Runtimeは同梱資源を使用。
+
+初回ソース試験は保存復元1件が不合格。原因は読込が意図的に追加するSAVE_LOADED履歴とID消費を期待値が含まなかったこと。成功イベントがちょうど1件であることと、それ以外の全状態一致を分けて検証した。修正後、headless PCK28件、macOS実描画PCK28件が合格。make check exit0。original-pack-ui.pngを目視し、宿舎・倉庫・建設パレット・日本語ラベルを確認。
+
+新しい読込メニューへの変更で、保存なしのドット見学／物流試遊から読込・移行へ入れる抜け道があったため、そのメニューも無効化。通常ゲームの読込は維持した。
+
+証拠: artifacts/facility-dimensions-2026-09-29/original-export-validation.json、original-export-source-sha256.json、original-pack-check.log、original-pack-rendered.log、original-windows-export.log、original-export-check.log。
+
+未検証: Windows実EXE操作、OSポインタ入力、宿泊・休息の通常一日プレイ、全30施設。現在の試験はUIハンドラ経由であり、物理クリックの証拠ではない。

docs/plans/original-completion-2026-09-29/execution/ORIGINAL_ROOM_ZONES.md

@@ -0,0 +1,9 @@
+# 原本の宿泊・宿舎配置ゾーン
+
+原本10.1は一般客室2×1表・上級客室4×1表、10.5は従業員寮2×1裏と指定し、地上限定を指定していない。既存定義のABOVE_GROUNDをANYへ変更し、原本にない地上限定制約を解消した。層・寸法・料金・人数・維持費は変更なし。明示的に地下指定の施設や地上境界を必要とする受付は変更していない。
+
+P08/P09の部分対応。通常Runtimeでランク2へ進める試験用資金/評判を用意し、未掘削拒否・異層拒否・通常掘削コマンド・3施設の地下建設完了・保存復元の40チェックPASS。地上の上級客室営業、従業員寮、寮の旧寸法移行、建設制約、Runtime建設の計6スイートPASS。Makefileに新規回帰を登録した。
+
+macOS実描画では通常パレット選択/マップ入力ハンドラから3施設を地下建設し、保存復元と画像取得を含む41チェックPASS。OSポインタ操作やWindows実機ではない。試験用ランク解放を使用し、新規ゲームからのランク到達・地下での集客/交通/休息全体の受入を示すものではない。
+
+証拠: artifacts/original-room-zones-2026-09-29/related.json、native.log、underground.png、source-hashes.json。地下顧客ドミトリーは従業員寮とは別施設で、依然未実装。全原本の完了ではない。

docs/plans/original-completion-2026-09-29/execution/PATH_MEMBERSHIP_OPTIMIZATION.md

@@ -0,0 +1,9 @@
+# Direct path membership comparison
+
+Runtime infrastructure validation previously serialized PathService (traffic, connectors, actors and related state) solely to compare passable cells. It now uses matches_passable_cells: count equality, membership and duplicate rejection. It does not cache mutable state or skip the validation. The serialized snapshot validator remains unchanged for save/restore validation.
+
+Reference comparison8 checks PASS: equal, empty, missing, duplicate, different, reordered cells, no mutation and empty graph. Runtime infrastructure integration162 checks PASS, including fault/rollback, route projection and rank expansion. New regression registered under make test-perf.
+
+Same production fixture measured x1 average62.711ms before /62.168ms after; construction phase9.416ms before /9.272ms after. Small single-run difference, not a material performance recovery. The4ms/12ms budgets remain unmet. Remaining major cost is snapshot publication and other infrastructure invariant traversal.
+
+Evidence under artifacts/facility-dimensions-2026-09-29: path-membership.log, membership-infrastructure-regression.log, production-membership-profile.json. No claim of full high-load or Windows performance acceptance.

docs/plans/original-completion-2026-09-29/execution/POST_SKIN_PRODUCTION_PERFORMANCE.md

@@ -0,0 +1,9 @@
+# 最新 UI 統合後の実ゲーム性能
+
+UI 回帰と同一ソースで既存 profile_production_scene.gd を再実行。測定プロセスは終了コード0、ログにエラーなし。これは計測完了であり性能 PASS ではない。
+
+通常速度平均 14.503ms（予算4ms）、3倍速 P95 54.366ms（予算12ms）。引き続き FAIL。通常速度の PUBLISH_SNAPSHOT 平均9.559ms、CONSTRUCTION平均2.526ms。最新スキン統合後も主要な残課題は状態公開・シリアライズとインフラ検証である。今回の測定だけで旧測定との差を回帰や改善と断定しない。
+
+既存の同一チェックポイント、シード424242、各速度40サンプルを使用。小規模の通常 Runtime＋メイン画面で、同期UI更新を含み、自動保存・GPU描画は含まない。高負荷・Windows受入を代替しない。
+
+証拠: post-skin-production-profile.json / .log と post-skin-full-ui-source.json。プロファイル後にもソース SHA-256 一致を確認。次は状態公開時の重複コピーや検証の費用を、セーブ互換性と不正状態検出を維持して削減する。

docs/plans/original-completion-2026-09-29/execution/POST_SKIN_UI_REGRESSION.md

@@ -0,0 +1,11 @@
+# 表裏スキン統合後の UI 回帰
+
+共通 HUD、開業ガイド、従業員／商品／営業管理、帳簿、ランク画面のスキン変更を含む現在の制作コピーで `make test-ui GODOT=/opt/homebrew/bin/godot` を実行。終了コード0、96.21秒、18本の直接実行スクリプトと維持費の write/read 別プロセスが PASS。試験前後の対象ソース SHA-256 は一致し、ERROR / SCRIPT ERROR は検出なし。
+
+直接実行の結果: layer skin16、rank27、rank pointer11、layer presentation27、original build pointer36、dimension migration12、upkeep inspector6、staff rest8、rescue13、guest observer22、room94、pixel tower243、dashboard139、staff management67、supply42、business65、elevator20、first operating day59。維持費は write23/read14。
+
+開業シナリオは通常操作の建設、雇用、仕入、営業から翌日の営業までを通し、宿泊売上240G、人件費120G、維持費4G、未払い0G、決算 balanced=true、保存再生を確認する。全原本の通しデバッグや全ゲームの長期プレイではない。
+
+証拠は artifacts/facility-dimensions-2026-09-29/post-skin-full-ui-result.json、同接頭辞の .log と -source.json、および post-skin-upkeep-{write.log,read.log,result.json}。維持費の既定出力先は後続実行で更新され得るため、この回帰専用のコピーを保存した。
+
+これは headless 検証であり GPU、Windows 実機、全施設・全分岐の受入ではない。P27 の全原本条件は未完了。

docs/plans/original-completion-2026-09-29/execution/PREMIUM_ROOM_INTEGRATION.md

@@ -0,0 +1,34 @@
+# Premium room normal registration (2026-09-29)
+
+Status: partial P08/P10 progress, not whole-package acceptance.
+
+Added premium_room to ORIGINAL_FACILITY_PATHS and normal Runtime registry (20 definitions), main construction palette, shared lodging icon, bedroom furniture and sleeping presentation. Original dimensions 4x1 remain canonical. Explicit customer capacity is 2. Approved initial daily upkeep formula ceil(900*0.005) gives 5G; this is a tuning value, not an original-spec numeric claim. Existing price220G, duration720minutes and mana demand1 remain unchanged.
+
+Evidence:
+- premium-service.log:15 checks PASS. Ordinary Runtime construction commands create reception and premium room without a test registry. Service request at definition price/duration starts, restores halfway, completes with one220G charge, balances ledger and restores at midnight. The payer is a service-wallet fixture; autonomous walking/admission is not tested here.
+- premium-dashboard-final.log:136 native rendered checks PASS. Main palette selects the4x1 definition. premium-palette.png visually inspected: visible and selected premium-room button at900G/material10. Shared generic room icon is reused, not a finished unique art claim.
+- premium-runtime-regression.log:20 PASS; premium-migration-regression.log:56 PASS; premium-stairs.log:65 PASS; premium-check.log:make check exit0.
+
+Remaining: actual guest AI access/arrival and lodging after normal placement, full-day normal operation with capacity/outages, other original facilities, staff/transport-safe migration UI, Windows acceptance. No complete P08/P09/P10 claim.
+
+## Autonomous guest acceptance (2026-09-29)
+
+Added test_premium_room_guest_flow.gd to make test-mvp. 30 checks PASS in premium-autonomous-final.log. Construction uses ordinary commands for reception, premium room and two guest stairs, with no direct geometry or route injection. Guests enter through the spawn command with controlled sleep needs and funds; target facility and path are not supplied. The real AI selects premium lodging and moves via the first stair landing before automatic queue/service creation.
+
+Actual stair-save replay reproduces the complete arrival snapshot. Real guest lodging restores mid-service. Empty mana pauses elapsed service and avoids charging; a disposable disk snapshot restores the paused guest/service, then mana recovery completes the service with one220G charge. Midnight ledger and full snapshot restore pass. A second normal-built fixture sends three deciding guests; observed concurrent usage reaches2 but never exceeds2, the third guest is observed QUEUING separately, and crowded state restores exactly.
+
+These are deterministic Runtime acceptance scenarios using controlled guest inputs, not natural production arrival distribution, physical UI pointer placement or Windows acceptance. Original-spec all-facility completion, other lodging/dining, prices and long-term balance remain pending. No new production behavior was changed in this verification increment.
+
+## Viewport input and natural opening day (2026-09-29)
+
+Added tests/ui/test_original_build_pointer.gd to test-ui. Initial5000G, normal production loop and natural arrivals; no guest spawn, target/path injection or direct build/hire/assignment/save/load handler calls. Mouse events traverse viewport GUI hit testing for the palette, horizontal scroll, map placement, hire/assignment controls and save menu. Popup keyboard events use Input.parse_input_event and the target window ID. Time is advanced by the clock API, not real-time playback. This is synthesized engine input, not OS pointer automation or Windows acceptance.
+
+The scenario builds reception, premium room and two stairs, hires Akane and assigns the receptionist, completes natural lodging for440G by first midnight, verifies the ledger, saves/loads via controls, compares facilities/economy/guest/staff/construction state and replays the next30minutes exactly. Native rendered run36 checks PASS. original-pointer.png visually inspected at Day2 00:30: premium room occupied, separate queue, guide reports first-day completion.
+
+This exposed a production bug: opening guidance recognized only standard_room for room existence and first lodging sales. It now recognizes FRONT lodging definitions (service type or legacy lodging tag), and recognizes their active construction. Default recommended build remains the inexpensive standard room. Staff dormitories do not count as guest rooms.
+
+Initial failures are retained in original-pointer-day*.log: infrastructure stairs belong to ConstructionService rather than FacilityService, and injecting keys directly into PopupMenu's viewport bypassed native popup processing. Those were test-harness issues; the guide's hard-coded standard-room checks were the production issue.
+
+The previous Windows EXE/PCK predates this guide fix; do not treat its prior acceptance as validation of this revision. Remaining: actual OS/Windows input, other original lodging/dining facilities, broader seeds and long-term balance.
+
+Final verification: original-pointer-day-complete.log36 checks PASS (headless, includes active premium construction guide); original-guide-standard-regression.log48 checks PASS, preserving ordinary standard-room opening through next-morning save/replay; original-guide-check.log make check exit0. Native36 run preceded the final active-construction hint adjustment; that adjustment is covered by the final headless run.

docs/plans/original-completion-2026-09-29/execution/PRODUCTION_RUNTIME_PERFORMANCE.md

@@ -0,0 +1,19 @@
+# Production Runtime performance: budget failure
+
+Measured the normal main scene with a disposable PixelTowerDemo built via Runtime commands and natural arrivals. Automatic saves disabled, headless, paused clock advanced synchronously. Both x1 and x3 start from the same snapshot; 40 samples each, with a process frame between samples. Timing includes synchronous UI subscribers but excludes rendering/GPU. Small scenario, not the 20,000-cell load fixture.
+
+Final phase-instrumented measurement: x1 average63.616ms (budget4ms); x3 P95=234.396ms (budget12ms). Both fail. Exit0 means profiling completed and produced a report, NOT performance acceptance. The report explicitly sets within_budget=false.
+
+Largest per-minute phases: PUBLISH_SNAPSHOT average46.905ms in x1 /47.952ms in x3; CONSTRUCTION9.432ms /9.775ms; AI_DECISIONS3.494ms /4.896ms. Publish includes snapshot creation, canonical digest and all synchronous notification subscribers. Snapshot and digest are also separately measured in the report; their micro-costs must not be added again to publish time.
+
+This contradicts any inference that the earlier standalone domain benchmark proves production performance. The production bottleneck remains unresolved. Next work: preserve save/digest/replay contracts while reducing snapshot publication cost; inspect repeated infrastructure validation on idle construction ticks; remeasure identical checkpoints and validate deterministic behavior. Do not skip correctness checks or lower the acceptance budget to declare success.
+
+Evidence: production-scene-profile.json and production-scene-phases.log; diagnostic script tests/performance/profile_production_scene.gd. No production behavior changed by this increment.
+
+## Section profiling and rejected text batching experiment
+
+Added per-runtime-section canonical digest micro-measurements to profile_production_scene.gd. Largest measured sections: domain_events5.883ms, facility_infrastructure2.764ms, command_queue2.631ms, guests2.230ms, construction1.905ms. Section timings use fresh encoding contexts and must not be summed as an exact whole-digest decomposition.
+
+Tested batching typed string-array output in64-entry chunks. Reference compatibility83 checks passed including63/64/65/129 entries, UTF-8 and NUL values. The10,000-event-ID microbenchmark improved from about7.25ms to6.64ms, but the production scenario did not improve (x1 average61.810ms before /62.546ms after; event section5.883ms /5.906ms). The batching production change was reverted. Boundary tests and the diagnostic breakdown remain. Reverted encoder83 checks PASS.
+
+Evidence: production-sections-profile.json, production-text-profile.json, digest-text-final.log, digest-text-reverted.log. Performance remains FAIL. Next investigation should address complete repeated traversal rather than another scalar-level optimization.

docs/plans/original-completion-2026-09-29/execution/PROJECTOR_SINGLE_LIVE_CHECK.md

@@ -0,0 +1,19 @@
+# インフラ投影の重複検査削減
+
+2026-09-29。P28の部分改善。macOS Apple M4 / Godot4.7.2、headless測定。
+
+FacilityInfrastructureProjectorの依存検査は、RouteAdapterのis_projection_staleとvalidate_invariantsの両方から同じ経路状態を列挙・比較していた。正確に同じSpatial/Pathへの接続と非隔離状態を先に検証し、後者に含まれるstaleness検査だけを使う。Spatialの独立した不変条件検査、Adapter自身の保存構造検査、個々の施設投影・名前空間衝突検査は維持する。検査頻度やTick、保存形式は変えない。
+
+## 検証結果
+
+証拠: artifacts/runtime-profile-next-2026-09-29/。
+
+- インフラ投影192、経路投影184、Runtimeインフラ180、snapshot所有権89、計645項目PASS。
+- 旧コードをprojector-before.gd.txtに保存。比較用reference_projector.gdはclass_nameだけ除去した旧実装。
+- 同一の実営業デモ状態で旧・新の検査を交互に各200回実行。すべて正常判定、シミュレーション状態不変。
+- 検査平均1494.195→1165.750µs（約22%削減）。P95は1545→1216µs。
+- 通常シーン40サンプルずつ: 建設フェーズ平均x1 1855.925→1640.550µs、x3 1909.742→1544.658µs。
+- 全体x1平均10245.350→10826.525µs、x3 P95 36446→34639µs。x1は悪化しており全体改善とは断定しない。4ms/12msの性能目標は依然FAIL。
+- 描画付きの開業→3決算→別プロセス再起動: 97項目PASS。両プロセス終了0、ソース変更なし、営業状態JSON一致。書込62.56秒・読込47.41秒。
+
+部分検査の測定を全ゲーム高速化・2万マス高負荷・Windows性能の証拠にしない。Operationsのスナップショットなど、残る主要負荷の調査が必要。

docs/plans/original-completion-2026-09-29/execution/PROJECTOR_VALIDATION_CACHE.md

@@ -0,0 +1,14 @@
+# Facility infrastructure validation cache
+
+P28 partial performance improvement; not full acceptance.
+
+The production diagnostic measured the projector invariant check at7.139ms. It reconstructed and parsed the unchanged complete projection/request history every minute. Validation now retains one private successfully parsed serialized snapshot. Every invocation still creates a fresh snapshot and compares its complete contents; any changed projection, history, revision or quarantine metadata invokes the strict parser again. Current spatial/route/path crosslinks are checked every time, including cache hits. Restore always uses the original strict parser. No saved fields or digest contract changed. The cache holds one snapshot, never a growing list.
+
+Regression evidence:
+- Projector192 checks PASS,exit0, including fresh/unchanged checks, externally mutated returned snapshot, projection fingerprint corruption at unchanged revision, request-history corruption, changed live path, repaired path and later unprojection.
+- Runtime infrastructure162 checks PASS,exit0, including existing rollback/restore/construction boundaries.
+- The new path-corruption test initially tried restoring traffic before rebuilding the graph; fixed the test to restore the graph first, matching the existing Path restore contract. Production code was not changed to bypass that contract.
+
+Production headless diagnostic: projector invariant average7.139ms →2.536ms. Current x1 average16.348ms; x3 P9560.411ms. Both remain above4ms/12ms. The fixture is small and uses the normal Runtime/main scene; it excludes GPU/rendering and Windows acceptance. This comparison is a diagnostic single-run result, not statistical certification. Extra memory from one retained serialized snapshot has not yet been assessed at the maximum history size.
+
+Artifacts: production-validation-costs.json, production-projector-cache.json, projector-validation-cache.log, projector-cache-runtime.log, projector-cache-validation.json.

docs/plans/original-completion-2026-09-29/execution/RANK_INTERFACE_SKIN.md

@@ -0,0 +1,11 @@
+# 世界樹ランク画面の表裏スキン
+
+P23/P24 の部分実装。原本 B-12.4 の表モード（羊皮紙・ファンタジー）／裏モード（黒鉄・モニター風）の切替をランク昇格画面に適用した。Window 専用のローカル Theme と既存の共通パレットを使用し、条件文、枠、ボタンの通常・ホバー・押下・フォーカス・無効色を変更する。内部ラベル／ボタンは明示的に更新する。初回から裏層の場合にも適用する。新規外部素材、ゲームルール、セーブ形式の追加はない。
+
+検証: test_world_tree_rank.gd headless 27 / macOS 描画あり 28、test_rank_pointer.gd 11、test_layer_skin.gd 16、いずれも failures 0。条件表示・無効ボタン、表裏往復後の全 Runtime snapshot 一致、昇格前の再評価、申請キュー、重複防止、保存・復元、昇格後の建設範囲拡張を含む。裏層起動の色も確認した。rank-skin-back.png を視認確認し、条件文と無効ボタンの判読、枠内配置を確認した。
+
+試験中、内部 Control が通常の子走査の対象外となることを検出し、個別更新に修正した。また選択レイヤー自体は保存対象なので、完全 snapshot の不変性は表→裏→表の往復後に比較する。
+
+成果物: artifacts/facility-dimensions-2026-09-29/rank-skin-{headless,native,pointer,layer}.log、rank-skin-back.png。ソース／ログの SHA-256 は rank-skin-validation.json。
+
+これは操作接続と表示の検証であり、新規ゲームから自然に全ランクへ到達した証拠ではない。その他のダイアログ／ポップアップ、完成素材・音響、Windows 同一ビルド、全原本受入は未完了。

docs/plans/original-completion-2026-09-29/execution/SELECTION_AUTOSAVE.md

@@ -0,0 +1,16 @@
+# 自動保存・直接読込での選択復元
+
+2026-09-29。毎日06:00の自動保存、遅延手動チェックポイント、Runtimeの直接読込をP24の選択復元へ接続。
+
+Runtimeは実保存時に任意の画面情報を信号で収集し、interface_selectionだけをコピーする。呼出元が明示した情報を上書きしない。画面が存在しない場合も保存可能。成功したload/recovery/recovery_candidate通知で共通UI復元を行い、手動ボタンからの二重復元を防止する。失敗、保存、移行の通知で選択を変更しない。
+
+通常開業から翌々日06:00まで営業し、実自動保存→別の施設選択→自動保存候補の読込を検証。保存予約後に選択を変えた場合は実保存時点の選択を保存。直接厳格読込の成功/失敗も確認。headless75項目PASS、ダッシュボード168、従業員131、画面なしRuntime保存ライフサイクル96項目PASS。旧保存互換試験はUI通知を通さない旧形式のパッケージを作り、任意情報がない保存を検証する。
+
+実描画76項目PASS。通し試験は83＋20＝103項目PASS、書込47.25秒・読込34.58秒、ゲーム状態一致、ソース差分0。画像で自動保存候補読込後の受付選択枠と詳細を確認。証拠: artifacts/selection-autosave-2026-09-29/。変更前、差分、各ログを保存。
+
+後続の選択ライフサイクル試験はheadless38項目・実描画39項目PASS。工事、完成施設、建設済み階段、掘削、旧版移行で実体化された既設階段を実パッケージから復元。画面破棄後の保存・再生成後の直接読込・自動保存の古い世代と新しい世代の選択も確認。証拠: artifacts/selection-lifecycle-2026-09-30/。追加試験初回の呼出し誤りはログに保全し、正しい公開APIへ修正後に再実行。今回変更後の全回帰143スイートPASS。全件合格後の実描画・別プロセス再起動103項目PASS、ゲーム状態一致、ソース差分0。CURRENT_FULL_REGRESSION.mdを参照。Windows配布/実機は未完了。この変更だけでP24全体や原本全実装を完了とはしない。
+
+
+## 次の接続対象（現在ソースの読取監査）
+
+GuestObservationPanel.selected_guest_idとStaffManagementPanel.selected_staff_idは主画面の施設選択とは別に保持される。現在のinterface_selectionはkind/idだけで、これらを保存しない。したがって施設・工事・掘削・階段の選択復元が通っても、従業員・来客の全詳細画面の選択復元を達成したとは判定しない。次は、保存時に選ばれた実在IDと表示入口を任意情報として保存し、採用候補の情報から復元する。現行の全回帰中は本体へ適用しない。

docs/plans/original-completion-2026-09-29/execution/SELECTION_RESTORE.md

@@ -0,0 +1,21 @@
+# 手動保存した選択対象の復元
+
+2026-09-29。P24「保存後も対象選択を回復」の手動セーブ入口を接続。保存ボタンはmanifestにinterface_selection version1（kind/id）を記録する。成功した通常/復旧読込で、その候補のmanifestから選択を復元し、マップ強調表示と管理パネルへ反映。GameStateが保持する保存時の表/裏レイヤーを画面へ同期する。ゲーム状態の保存スキーマ変更なし。
+
+選択メタデータは任意。欠落、未知版、型不正、未知種別、存在しないIDは無視し、ゲーム状態の読込を妨げない。失敗した読込は現在の選択を変更しない。施設（建設済みインフラ含む）、工事、掘削、既設階段をそれぞれ対応サービスで存在確認してから反映する。
+
+ダッシュボード168項目PASS。保存パッケージにIDが残ること、通常/厳格読込、保存時レイヤー、旧版/不正UI情報、失敗時の選択保持、正式セーブ破損時にバックアップ候補の選択情報を使うことを確認。従業員131項目PASS。
+
+通常保存ボタン/読込メニューを使う実描画通しシナリオに選択復元の検証を追加。書込側83・新規プロセス読込側20＝103項目PASS。書込46.27秒・読込34.41秒、双方終了0、ソース差分0。3日目までの営業状態・帳簿が一致。保存後読込画面で受付の強調表示と詳細表示を視認。
+
+証拠: artifacts/selection-restore-2026-09-29/。変更前ソース、dashboard.log、staff.log、opening-restart（selection.json、画像、両ログ、営業状態）、targeted-verification.json。全回帰141/141 PASS、欠落・重複・ソース差分0。全件PASS後の実描画通し103項目もPASS。artifacts/full-regression-after-selection-restore-2026-09-29/参照。
+
+後続の自動保存/直接読込対応はSELECTION_AUTOSAVE.mdを参照。残件: 工事/掘削/既設階段の全個別受入、Windows配布/実機、より広いP24は未完了。今回の実装を全選択・全保存入口の完了とは判定しない。
+
+## 自動保存・直接読込への接続調査
+
+全回帰中に現行ソースを読み取り確認。Runtime._process_save_checkpointsは毎日06:00に_perform_checkpoint_saveを直接呼び、画面選択はmetadataに含めない。遅延手動チェックポイントも同じ保存関数を使う。したがって手動ボタンのmetadata追加だけでは自動保存へ反映されない。
+
+次の接続点は_perform_checkpoint_saveの任意プレゼンテーション情報収集と、既存save_operation_completed通知。load_from_path/load_with_recovery/load_recovery_candidateの結果には実際に採用したmanifestとoperationが残る。画面側は成功した読込操作だけを扱い、save/migration/inspect/失敗を読込と混同しない。_load_manualの現在のUI再接続を共通化し、通知とボタン後処理で二重に復元しないことが必要。
+
+受入追加: 06:00自動保存→別候補選択→自動保存候補読込、キュー投入から保存時刻までの選択変更、成功/失敗した直接読込、UIのないheadless保存、画面破棄/再生成、古い選択ID、履歴世代ごとの異なる選択。任意表示情報の異常でゲーム保存を壊さず、保存情報取得でゲーム状態を変えない。この調査後、全回帰完了を確認して接続を実装。SELECTION_AUTOSAVE.mdに後続検証を記録。

docs/plans/original-completion-2026-09-29/execution/SERVICE_START_SLOTS.md

@@ -0,0 +1,19 @@
+# サービス開始結果の枠番号修正
+
+2026-09-29。対象: ローカル制作コピー。P09/P27の部分修正。
+
+顧客同時利用人数とサービス枠を分離した際、開始結果の `slot` が人数制限を含む `available_slots()` に依存していた。サービス容量100・人数上限3で2人組を最初に開始すると、0ではなく98を返していた。また開始通知のコールバックで次のサービスを開始すると、外側の結果が次の開始の影響を受けていた。
+
+挿入前の実行中サービス数を今回の開始インデックスとして確定し、通知後もその値を返す。これは開始時点のインデックスであり、永続的な座席IDではない。利用者人数制限・待機列・料金・保存形式は変更しない。
+
+## 検証
+
+証拠: `artifacts/service-start-slots-2026-09-29/`。
+
+- 修正前: 新規25項目中3件失敗（before.log）。
+- 修正後: 新規25項目PASS（after.log）。容量2/100、2人組と1人組、人数超過拒否、保存復元一致、通知中の再入を確認。
+- 既存関連: FacilityService61・追加施設パラメータ29・Runtime客周期40・清掃通常操作90、計220項目PASS。
+- 初回再現試験の終了時リークは、試験の通知コールバックがサービスを参照する循環を切断して解消。修正後ログに終了時エラーなし。
+- 描画付き開業・決算・再起動試験: 80＋17＝97項目PASS。書込62.79秒、読込48.07秒、両プロセス終了コード0。3回決算までの営業状態が再起動前後で一致、実行中ソース変更なし。
+
+前回の139スイート一括PASSはこの修正前の証拠。今回の変更後に全140スイートを一括実行したとは扱わない。Windows配布版は未更新、実機試験と原本全体の受入は未完了。

docs/plans/original-completion-2026-09-29/execution/SNAPSHOT_CALL_REUSE.md

@@ -0,0 +1,13 @@
+# 営業履歴スナップショットの同一呼び出し内再利用
+
+2026-09-29。OperationsCoordinator.create_snapshotの内部検査と出力検査で、構造・深さが一致する4フィールド（demand_history、arrival_reports、alerts、quarantine_report）を再利用する。最初の検査で所有権を分離した正規化コピーとノード数・文字数を記録し、同じ呼び出しの出力組立だけに使う。呼び出しをまたぐキャッシュは作らない。その他の変換項目は再検査する。
+
+合計上限に抵触し得る場合は元の再帰検査へ戻し、従来のエラー優先順を維持。履歴の削除、検査上限の緩和、保存形式変更なし。全体スナップショットを公開時に生成する契約も維持。
+
+同一デモ状態を交互に200回ずつ計測: 旧平均1561.75µs/P95 1601、新1073.165µs/P95 1110（平均約31.3%短縮）。400回すべて出力一致。既存300チェックと差分比較549チェックを通過し、後者を恒久回帰へ組込み、製品コードで849チェックPASS。比較にはUnicode・キー衝突・非有限数・深さ・集合サイズ・文字数/ノード数の累計超過・正規順・出力と元状態の分離を含む。
+
+ゲーム全体の小規模デモで、x1平均9882.775→9371.8µs、x3 P95 34674→32728µs。全スナップショット平均5074.2→4525.65µs。別実行の測定なのでばらつきを含む。macOS headless、オートセーブ無効、同期Tick＋遅延UI更新を含む。GPU描画・Windows・最終高負荷条件は未検証。目標4000/12000µsは引き続き未達。
+
+証拠: artifacts/snapshot-call-reuse-2026-09-29/。変更前ソース、候補と参照ドライバー、比較・既存回帰ログ、runtime-before/after.json、comparison.json。
+
+関連試験: Runtime統合21、Runtime営業51、ダッシュボード149チェックPASS、各終了コード0。全回帰140/140スイートPASS（674.21秒）、欠落・余分・重複・ソース差分0。続く実描画の開業・3回決算・保存・終了・再起動97項目PASS、保存前後の営業状態一致。証拠はartifacts/full-regression-after-snapshot-reuse-2026-09-29/。CURRENT_FULL_REGRESSION.md参照。今回の軽量化を含むWindows開発確認版を生成。隔離PCK1,527項目とmacOS実描画従業員操作132項目PASS。Windows実機未検証。CURRENT_WINDOWS_PACKAGE.md参照。

docs/plans/original-completion-2026-09-29/execution/SNAPSHOT_KEY_BUDGET.md

@@ -0,0 +1,11 @@
+# Dictionary key validation cost reduction
+
+OperationsCoordinator canonical dictionary keys are always strings after key-type validation. Validate that leaf inline instead of calling the recursive general Variant inspector for every key. The existing preflight collision scan, type restrictions, depth-before-node precedence, single-string limit, total string budget and value recursion are unchanged. No limits were raised and no validation was removed.
+
+Added six dictionary-specific edge assertions (depth/count effects, node budget, aggregate and individual string length, integer canonical key length). The Operations suite passes 254 checks including existing corruption, canonical collision, ownership, byte compatibility and save tests.
+
+Measured using the same production-scene fixture, seed 424242 and 40 samples per speed, macOS Godot 4.7.2 headless with autosave disabled. Before -> after: Operations snapshot average 3174.95 -> 2419.45 us; full snapshot average 7717.4 -> 6620.5 us; x1 average 13979.775 -> 13487.4 us; x3 P95 54880 -> 51750 us. This is a single paired measurement, not a statistical performance guarantee. Full production budgets (4000 us x1 average, 12000 us x3 P95) still FAIL. Rendering/GPU, full-load fixture and Windows are not measured here.
+
+Evidence: artifacts/facility-dimensions-2026-09-29/key-budget-before.json, key-budget-after.json, key-budget-tests.log, key-budget-runtime.log, key-budget-opening.log, key-budget-validation.json. Runtime and opening results must be taken from their finished logs/manifest, not inferred from the unit suite.
+
+Completed follow-up: Runtime Operations integration 51 checks PASS; first operating day 59 checks PASS; both exit code 0. Combined with 254 Operations checks, 364 checks passed on the retained change.

docs/plans/original-completion-2026-09-29/execution/SNAPSHOT_OWNERSHIP.md

@@ -0,0 +1,21 @@
+# Transfer detached subsystem snapshots without a second full copy
+
+Runtime create_snapshot previously assembled the results of every subsystem snapshot/serializer, then passed the complete tree into SimulationSnapshot.capture, which deep-copied it again. Runtime now assembles those freshly owned containers, captures the clock/resource envelope at the same point, and attaches the owned systems tree directly. Generic SimulationSnapshot.capture remains unchanged and still deep-copies arbitrary caller extras. No schema, ordering, hash format or publication frequency changes.
+
+Reviewed component snapshot builders: world/path/infrastructure build serialized rows and detached cells; operation serialization recursively creates canonical containers; economy/command/event records return detached dictionaries; facility/guest/staff serializers copy nested policies, histories, tasks and definitions; inventory/logistics/kitchen, construction/excavation, authority/defense/relationships/progression and weather use copies or new scalar rows. Runtime manifest/RNG/movement/logistics/event-definition wrappers likewise create new arrays/dictionaries. The Runtime path now relies on that existing component ownership contract rather than masking aliases with another aggregate clone.
+
+Added a regression registered in make test-perf. It independently mutates all40 Runtime snapshot sections in new-game and populated-demo states, including adding values to empty typed arrays and clearing/replacing nested dictionaries; live state must remain identical. It also covers the clock/resources, retained snapshots while live time advances, exact restore/replay, and generic caller-extra isolation. Before and after both87 checks PASS. Runtime Save/Load/recovery/atomic-rejection96 checks PASS, targeted total183.
+
+Single paired small production-scene profile: snapshot average6766.5→5457.4us (~19% lower); x1 average12636.875→11957.1us (~5% lower); x3 P9544193→36908us (~16% lower). Same seed424242,40 samples per speed, macOS Godot4.7.2 headless, includes deferred dashboard flush, excludes GPU and autosave. Both4ms/12ms budgets remain FAILED. This is not a statistical/full-load/Windows acceptance claim.
+
+Because the change spans every saved subsystem, started the complete source regression in artifacts/snapshot-full-regression-2026-09-29 (expected128 unique scripts). Runner session74488 is the handle to resume. Inspect authoritative completion and compare source-start.json at the end; do not infer success from partial all-tests.json. After successful regression, rerun the paired opening/restart scenario. The last Windows ZIP still predates this and the preceding infrastructure validation optimization.
+
+Evidence: artifacts/snapshot-ownership-2026-09-29/validation.json, before/after ownership logs, save-lifecycle.log, profile-before.json and profile-after.json. Ownership checks exercise current fixtures, not a proof that every possible future subsystem branch can never introduce an alias; retain this test and the general capture contract when adding new components.
+
+## Complete source regression after both optimizations
+
+Runner session74488 terminated with exit0. All128 unique discovered source test scripts passed; missing/unexpected scripts and ERROR/SCRIPT ERROR logs were empty. All283 tracked source/data/scene/test files match the starting manifest, including no newly added or removed files. completion.json and source-end.json are retained in artifacts/snapshot-full-regression-2026-09-29. Tooling/docs changes during the run are outside that production-source manifest and do not alter the tested game. This closes the regression gap for the infrastructure-validation and snapshot-ownership optimizations, as well as the prior ledger display correction. It does not certify missing original features or unmet performance budgets.
+
+A new rendered paired opening/restart run started after that success, output artifacts/snapshot-opening-restart-2026-09-29, runner session84272. It remains pending until both processes and source-change comparison finish; prior runs are not substituted for this result.
+
+Paired rendered continuation completed after the128-suite pass: writer80 and fresh-process reader17 checks, total97PASS, both exit0, no source changes. All three closes balance (-64,+346,+346G). Gameplay state (excluding only wall-clock domain events) and complete financial reports match across process restart. Both third-close screenshots were visually reviewed. Evidence: artifacts/snapshot-opening-restart-2026-09-29/validation.json. This validates the existing three-day inn flow after both optimizations, not the full unfinished original game.

docs/plans/original-completion-2026-09-29/execution/SNAPSHOT_TREE_BUDGET.md

@@ -0,0 +1,11 @@
+# 状態検証カウンターの軽量化
+
+P28 部分改善。OperationsCoordinator の保存データ走査で用いるノード数／合計文字数を、キー付き Dictionary から共有 Array[int] の2要素へ変更。各ノードでのキー検索と型変換を除去した。検査順序、深さ／件数／単一文字列／総文字数／コレクションの上限、有限数／キー衝突検出、外部へ返す検証レポートは維持する。カウンターは走査ごとに生成し、キャッシュによる検査省略は行わない。
+
+キーを一度 String 化してネイティブ sort する案も試したが、営業スナップショット3.550→3.561ms、通常速度14.256→14.388msで改善が見られず、こちらは完全に戻した。旧エンコーダとの正規化出力比較5項目をテストに残した。
+
+採用変更の計測: 営業スナップショット平均3.550→3.167ms、通常速度平均14.256→14.031ms、3倍速P95 52.113→50.911ms。同一小規模 fixture の単回比較であり速度向上率の保証ではない。目標4ms／12msは依然 FAIL。GPU、大規模負荷、Windows は未評価。
+
+Operations248項目と、通常開業→翌日営業・決算・保存再生59項目が PASS。追加の境界10項目はノード数／総文字数／深さの上限一致と次の値の拒否、Unicode文字数、文字列長、集合サイズ、非有限数を検証。カウンターを上限直前から開始する試験も用い、200万ノードを生成するだけの冗長な試験は行わない。既存の検証／復元失敗ケースも維持。
+
+ソース・ログ・計測の SHA-256 は artifacts/facility-dimensions-2026-09-29/tree-budget-validation.json。全原本、全UI、最終性能受入の完了を意味しない。