6 lines
5.3 KiB
JSON
6 lines
5.3 KiB
JSON
{
|
|
"action": "wait",
|
|
"task_id": "P04-01",
|
|
"reason": "【読取専用の診断。正式受入レビュー、承認、追加repairではない】\n修復は2/2のまま維持し、第3repairや再登録は始めない。30/88の分母と部分点なしも変えない。D05は未承認で、数値や規則は採用しない。actionはwaitのままにする。\n\n■1 原本とA01の衝突\n- 提示された抜粋の範囲では、直接の衝突は見つからなかった。A01(保有時間按分維持費・00:00精算・未払い繰越)は再確認しない。\n- 原本64/67/71/72/183は、18:00交代、00:00決算、マナ枯渇時の全館停止を定める。閉店後の開始済サービスと最終勤務区間の意味は原本にない。どちらも未確定のままで、草案が補ってはいけない。\n- 要確認点が1つある。_process_daily_closeの手順にFINALIZE_PENDING_SERVICESがある。これが00:00時点で進行中のサービスを完了扱いにするのか、持ち越すのかは抜粋から読めない。この手順が候補1のA案(継続)とB案(休止)のどちらと整合するかも、抜粋では判定できない。\n- 草案の「TIME_BOUNDARIESが施設完了より先」は、現在の順序の観測にすぎない。承認規約にはなっていない。\n\n■2 EV安全降車と車内保持、救護の組\n- _advance_elevatorsは、マナが0以下、または昇降機モジュールがACTIVE/DEGRADEDでなければ、その軸を無電力にする。この処理は到着投影より前に行われる。\n- 安全降車の分岐はElevatorService287以降にあり、今回の抜粋には含まれない。降車先の有無で動作が分かれるという記述は、抜粋による裏付けがない。\n- _advance_staff_rescueは、搬送者(carrier)がBOARDEDの間だけ組の無効化・取消を保留する。患者側が乗車中かどうかは見ていない。\n - 搬送者が降車して患者が車内に残ると、組が分離する。次のtickで患者と搬送者のcurrent_cellが一致せず、rescue_transportが取消される。\n - 取消時にelevators.cancel_actorが車内の患者へ呼ばれた場合の挙動は未確認。\n- _apply_elevator_arrivalsは、投影のないactorを黙ってcontinueで飛ばす。緊急降車の到着が捨てられ、乗客・荷物・予約が孤立する恐れがある。\n- 枯渇時の全館停止に、安全降車の例外を認めるかどうかは未承認の論点。\n\n■3 購入の支払いと納品\n- _purchase_paidは、元倉庫へadd_stackした直後に、同じ処理内でPLAYER_CASHからOPERATING_EXPENSEへ振替える。支払いは購入確定の時点で、納品完了の時点ではない。\n- 失敗時はinventoryとeconomyのsnapshotを復元する。ledger_keyが渡されるので、再送の同一性は取れそうだが、実際に二重計上しないことは未実行。\n- 輸送中の在庫や納品状態を別に持つ物流経路は抜粋にない。購入を「納品」と呼べる範囲が不明。\n- 閉店・停電・破壊中の購入可否はpreview_purchaseの中にあり、抜粋にない。\n- 結論として、現状は「購入時払い」の観測であり、承認済みの費用時点ではない。\n\n■4 日跨ぎ帰属の証拠不足\n- サービス売上は、完了tickのabsolute_minuteで記帳される。冪等キーはservice.payment.<service_id>。台帳エントリに日の項目はない。\n- 日別決算は期間終了を排他(end-exclusive)で扱い、IDはdaily-close:<day>。この前提だと、00:00ちょうどに完了する売上は翌日に属する。ただしこの結論は、決算がサービス完了より先に走る現在の順序に依存する。決算手順にFINALIZE_PENDING_SERVICESがあるため、この結論も未確定。\n- 不足している証拠は次のとおり。\n 1. サービス売上以外のproducer(建設・仕入・給与・ワープ・炉取引)の記帳minuteと帰属日。\n 2. 帳簿の期間集計、UI、保存・復元が同じ帰属で動くこと。\n 3. 再送・復元時の二重計上の有無。\n\n■承認準備完了までの有限の残作業(新規の数値や規則は作らない)\n1. 全サービス種別について、営業時間終了・手動閉店・必要人員・完了課金を、定義と関数に対応させた表にする。FacilityService853とFacilityInstance208/212/243を含める。\n2. ElevatorService287以降と、EV/救護/物流の停止位置・復帰を実ソースで確認する。降車失敗(投影なし)時の孤立の有無を含める。\n3. 費目ごと(建設/仕入/給与/サービス/ワープ/炉取引)に、既承認の時点と未確定の時点を分けた表を作る。\n4. 日跨ぎの帰属を、帳簿の期間・UI・保存と突合した有限表にする。\n5. 候補1(A/B)と候補2(A/B)ごとに、原7領域の具体ケースと、進捗・予約・位置・人物・全台帳・通知の期待関係を示す。fixtureの数値を本番値にしない。\n6. 独立した読取専用レビューを受け、差異と影響をそろえてからオーナーに選択を提示する。\n\n規約が承認されても、生証拠、意味的来歴結合、全coverage、正式独立レビュー、統合は別に必要。現在のalways-fail preflightを受入gateとして採用しない。"
|
|
}
|