8.0 KiB
D05 同時発生と安全処理：未承認候補
状態は not_approval_ready。原P04-01未完、原30パッケージ/88成果・部分点なしを維持する。これは判断用の草案で、承認・製品変更・修正上限追加・別タスク再登録を行わない。金額、マナ量、猶予時間を新設しない。
原本BASELINE.txt64/67は18:00交代と06:00–18:00/18:00–06:00の勤務枠、71/72は00:00決算、183はマナ枯渇時の全館停止。A01の保有時間按分維持費・00:00精算・未払い繰越は承認済みで、再確認対象ではない。閉店後の開始済サービスや最終勤務区間の意味は原本値として補わない。
現在の観測
kernel123–153はcommand適用→時計増分/日境界→TIME_BOUNDARIES→MANA→建設→物流→施設完了→生理→事故/イベント→施設queue→AI→公開。同phase内はhandler ID順。Runtime8421では施設/厨房進行、8441では閉店queue解放後patience、8597では勤務/通勤/出勤投影/清掃と客再計画。FacilityService853以降は非稼働・停電・不足人員を確認して休止/待機/失敗を処理する。この順序の観測自体を承認規約とはしない。
判断候補1：閉店と開始済サービス
A（継続契約案）: 閉店を新規受付・待ち列の終了と区別し、開始済サービスは完了まで継続可能とする。ただし停電・破壊・必要人員不足等の停止を無効にしない。営業時間終了とプレイヤーの手動閉店を同じ扱いにするかは別に確定する。開始済契約を窓口の閉店だけで失敗させない利点があるが、閉店後も資源・人員が必要になる。
B（境界休止案）: 営業終了を完了処理より先に反映し、開始済サービスを進捗/人物/予約保持のまま休止する。営業復帰時に再開し、未完了のサービス完了課金をしない。閉店直前に始めた長時間サービスの滞在が翌営業時間まで延びるため、宿泊等の適用例外と人物退出との衝突を承認前に整理する。
どちらも原本に明示された既存規約とは主張しない。定義ごとの営業時間・有償処理・手動閉店の現実装を照合してから推薦を決める。全施設へ一律に適用する案としては未完成。
判断候補2：18:00最終区間
A（区間完了案）: [17:59,18:00)の実働が完了条件を満たしたサービスは18:00境界で一回完了できる。以後の新規受付/実働には夜番の実到着を必要とし、前の昼番の出勤投影を再利用しない。『18:00交代』と前区間の精算を分ける案。新規受付の前に勤務境界を反映する接続は、現コードでまだ証明されていない。
B（交代先行案）: 18:00の勤務終了と出勤解除を施設完了判定より先に適用する。夜番が未到着ならサービスは待機し、前の投影による完了を許さない。18:00ちょうどに終わる予定でも人員不足の待機が起きる可能性があり、最終1分の意味を規約として明記する必要がある。
原本の通勤渋滞による業務停止を両案で維持する。勤務・通勤・給与・サービスを別々に時間更新して二重進行する実装は採らない。候補はsource変更ではない。
安全処理と残る照合
マナ枯渇では全館停止を維持し、未完了を完了として課金しない。復帰が破壊/摘発等の別停止理由を解除しないことを検証する。EV/搬送の現在位置、乗客/対象ID、荷物、予約、残作業を保存することを受入不変条件にするが、緊急降車するか・移動途中のどの位置で停止するかは現EV/救護/物流処理との照合前に確定しない。
費用時点は、既承認の費目をこの草案で動かさない。建設/仕入/給与/サービス/ワープ/炉取引等の対象を列挙し、承認済時点と未確定を分ける必要がある。サービス完了取引の再送/復元は同じidentityを再計上しない。00:00はA01を保持し、同時service売上を終了日のどちらへ所属させるかは現帳簿の期間・UI・保存を突合して候補を仕上げる。
承認前に揃える内容
- 全サービス種別の営業時間終了/手動閉店/必要人員/完了課金を、既存定義と実関数に対応させる。
- EV/救護/物流の停止位置と復帰、関連費目の既承認時点、日跨ぎ帰属を有限表で示す。
- 各選択肢について原7領域の具体ケースと、進捗・予約・位置・人物・全台帳・通知の期待関係を示す。未承認の値をfixtureの数値で本番値にしない。
- 独立した読取専用レビューを受け、未承認差異と影響を揃えてオーナーへ選択を提示する。
P04-01修正2/2は維持し、第3repair/再登録を始めない。現在のalways-fail preflightを完成受入gateとして採用しない。原規約の決定後も、生証拠・意味的来歴結合・全coverage・正式独立レビュー・統合が必要であり、規約承認だけで成果を完了にしない。
追加静的照合（現ソースの観測、未受入）
scope-audit.jsonに全施設定義と現default/明示値の区別を保存した。数値を承認値に格上げしていない。定義存在を通常登録・稼働・完成素材の証明としない。重複プロパティは記録だけ行い、この作業で修正しない。
閉店: FacilityInstance208/212は閉店をstateに反映し、can_start_service243はOPEN/DEGRADEDだけを開始可能にする。一方FacilityService853の開始済サービス準備には、閉店単独を理由にpauseする分岐がない。開始済は破壊/関連施設/電力/人員の条件で止まる。継続案Aと近い現動作であるが、全定義の通常動作を試験した結果ではない。
EV: ElevatorService287以降の停止は安全な降車先の有無で分岐する。降車先ありなら乗車中人物をemergency arrivalとしてそこへ返し、未乗車要求は取消。降車先なしなら乗車中は車内保持し待機要求を取消する。これを原本の承認済み安全規則とはしない。判断候補は「現安全降車分岐を保持」と「停電時は常に車内保持」の比較になり、乗客/救護同伴/搬送荷物への反映を確認する必要がある。枯渇時全館停止に安全降車例外を許すかは未承認の論点である。
00:00: OperationsCoordinator1125のpayloadは終了期間をend-exclusive、日別精算IDをdaily-close:とする。TIME_BOUNDARIESが施設完了より先なのは現在の順序であり、帳簿帰属の全producer適合を証明していない。
境界処理の追加照合 r02
boundary-followup-r02.jsonに対象版のSHAと8関数の原文を固定した。決算APPLYは給与・維持費精算と期間財務の生成を行い、その関数本体には施設サービスの強制完了呼出しがない。FINALIZEという段階名だけから強制完了を推定しない。
確定財務は[start,end)を集計する。当日UIはcoordinatorの開始時刻から現在時刻までを含む現金流を表示し、確定日のsummaryは別に選択する。従って00:00ちょうどの完了売上の帰属は現順序と承認規約を区別して決める必要がある。給与は決算境界で現金記帳する一方、確定損益はnew_wages_totalを用いWAGE現金行を除外するため、UI現金支出と損益の数値を機械的に同値条件にしない。
EVのcancel_actorは乗車中の同伴組の単独取消を拒否する。停止時は同一の安全降車先について人物ごとのarrivalを生成し、Runtimeは人物ごとに位置を反映する。反映前提の欠損による分離は未再現であり、重大不具合として確定していない。通常操作・保存再開の受入を静的照合で代用しない。未承認・not_approval_ready・9/88は維持する。