TheTree_mock/docs/plans/original-completion-2026-10-02/execution/p24-02-evlog/SPEC.md

P24-02-EVLOG 出来事の一覧で読めない記録をなくす 仕様（登録の前の版 r01。P24-02 の補助の作業）

• 状態: 登録の前の仕様（実 Opus の commander、2026-10-25）。人の新しい決定は要らない。Root が main に docs/plans/original-completion-2026-10-02/execution/p24-02-evlog/SPEC.md として固定し、その commit を base_commit に通常の登録をする。製品は登録まで変えない。読んだ source は同じフォルダの SOURCE_PINS.json（main 50207e9）。
• 原本への加算: 0。原単位 P24-02 の原 work・原 AC は、この作業では閉じない（§8）。
• 表示だけの作業: Runtime の状態・記録の流れ・保存の形は変えない。変えるのは、出来事の一覧の画面の文の組み立てだけ。

1. 原本の条件（原文。変えない）

• docs/traceability/original/BASELINE.txt 223〜225 行（11.4 建設・通知UX）: 225 行 * **通知:** ユニット頭上のフキダシ（Zzz、怒り、ハート）、イベントログ。
• package P24「インスペクター・通知・操作完成」の acceptance の一部: 「ログの説明と実際の選択が一致。」
• 原単位 P24-02「操作と通知」の work「配置、無効ドロップ、モーダル、停止、再開、フキダシ、ログ、カットインを整える。」と acceptance「無効操作を説明し、クリック代替と日本語入力・表示倍率を確認する。」の、「ログ」の部分。
• 台帳の P24-02 の残件 event_log: 「実際の記録の流れ、日本語の金額・時刻・理由、停止と読み込みで重複しないこと」が残る。
• 既知の残件: P07-01-WX の残件「出来事の一覧で毎日の WEATHER_FORECAST_DRAWN が『未識別の記録』と出る」（work_packages.json の P07-01 の residuals_outside_unit_acceptance）。

2. 今の製品の欠落（main 50207e9、読むだけで確かめた）

• scripts/ui/event_log_dialog.gd の EVENT_NAMES（88 種類）に無い種類は、題が「未識別の記録」になる。製品の source が出す種類のうち、名前が無いのは次の2つ。
  • WEATHER_FORECAST_DRAWN（毎朝 06:00 の天候の抽選。autoload/simulation_runtime.gd の天候の抽選の箇所。対象の ID は無い）
  • WARP_TRAVELED（ワープの移動と料金。_charge_warp_fare。対象は connector の ID と乗った人の経路の actor の ID）
• 一覧の文は、記録の中身（payload）を出さない。そのため、予報の行は「未識別の記録 — 対象の指定なし」とだけ出て、天候と時刻が分からない。
• 対象の名前の解決（_entity_name）は、候補・施設・来客の ID だけを知る。次の ID の形は「名称を確認できない対象」になる。
  • 経路の actor の ID（staff:<職員の ID>・guest:<来客の ID>）: ワープと昇降機の記録の対象
  • ワープの connector の ID（warp.connector:<施設の ID>|<施設の ID>）
  • 昇降機の shaft の ID（transport.shaft.<層>.<x>.<y>.<幅>）
• 種類の全数の取り方（実装の時に試験で固める）:
  • SimulationDomainEvent.new( の2つ目の引数の文字の種類
  • _publish_actor_event( の1つ目の引数の文字の種類
  • _complete_save_operation( の2つ目の引数の文字の種類
  • 変数で種類を渡す2か所（保存の終わり・検査の到着と遮断）の式の中の文字の種類
  • main 50207e9 では、これで出す種類の全てが EVENT_NAMES の 88 種類と上の2つに入る。

3. 挙動（この作業で作るもの）

1. 名前: WEATHER_FORECAST_DRAWN と WARP_TRAVELED に、日本語の題を足す（例「その日の天候が決まった」「ワープで移動」。文言は実装で決めて記録する）。未知の種類の「未識別の記録」の守りは残す。
2. 予報の行: 天候の名前を、上部の表示と同じ語（晴れ・雨・嵐・マナ霧）で出す。雨などは始まりと終わりの時刻（HH:MM〜HH:MM）を、晴れは変化が無いことを出す。語は1か所にまとめ、上部の表示と一覧で同じものを使う。
3. ワープの行: 出発と到着の施設の名前、乗った人の名前と人数、払ったマナ（payload の mana）を出す。
4. 対象の名前: 経路の actor の ID は、職員の名前（候補の表示の名前）または「来客」に、ワープの connector は両端の施設の名前に、昇降機の shaft は、その位置の昇降機の施設の名前に解決する。名前を確認できない対象は、今の守り（「名称を確認できない対象（n件）」）のまま。
5. 一覧を開く・読む・選ぶ・文を組み立てることは、Runtime の状態を変えない（今と同じ）。

4. 変えないもの

• Runtime の記録の流れ（DomainEventStream）、記録の種類・中身・順序、保存の形と照合。
• 他の画面（上部の天候の表示の文は、語を共有するだけで変えない）。
• 未知の種類と未知の対象の守り。

5. 比べ方

• 画面の操作と文の組み立ての前後で、Runtime の snapshot の全体が bytes で同じ（今の tests/ui/test_event_log_ui.gd と同じ比べ方）。

6. 受入条件

• P24-02-EVLOG-F1 名前の全数: §2 の取り方で集めた、製品の source が出す全ての記録の種類に、日本語の題がある。新しい種類が題なしで足されると、試験が止まる。未知の種類は「未識別の記録」のまま。
• P24-02-EVLOG-F2 天候の予報: 本物の Runtime の毎朝 06:00 の抽選の行が、上部の表示と同じ語の天候の名前と、時刻（雨・嵐・マナ霧は始まり〜終わり、晴れは変化なし）を出す。4つの天候の全てで確かめる。
• P24-02-EVLOG-F3 ワープ: 本物のワープの移動の行が、出発と到着の施設の名前、乗った人の名前と人数、払ったマナを出す。客の移動と、職員の移動（救護の2人を含む）で確かめる。
• P24-02-EVLOG-F4 対象の名前: 経路の actor の ID（職員・来客）、ワープの connector、昇降機の shaft を、今の名前に解決する。昇降機の記録の行（依頼・乗車・到着・救護の依頼）でも確かめる。名前を確認できない対象は今の守りのまま。
• P24-02-EVLOG-F5 状態を変えない: 一覧を開く・読む・選ぶ・文を組み立てる前後で、Runtime の snapshot の全体が bytes で同じ。
• P24-02-EVLOG-F6 保存と読み込み: 予報とワープの行を含む保存を、同じ process と別の process で読むと、行は重複せず、同じ文で出る（読み込みの記録の1行が足されるだけ）。
• P24-02-EVLOG-F7 通常の画面: ゲームの本物の Runtime と Main で、viewport の入力（root.push_input。キーとボタンの押しと離しを local の座標で送る）で出来事の一覧を開き、予報とワープの行を選ぶと、その文が一覧と詳細に出る。OS の入力の受入は主張しない。
• P24-02-EVLOG-F8 回帰: 関連の回帰（狭い roster と再開の2段）と最終の S の全 roster が PASS。既存の試験の期待値の変更は EXPECTATION_CHANGES.json に変更前後と根拠を一覧にする。

7. 実装の範囲（allowed_paths）

• scripts/ui/event_log_dialog.gd（題・文・対象の名前の解決）
• scenes/main/main.gd（上部の天候の語を共有する場合だけ。上部の表示の文は変えない）
• tests/**、tools/run_p24_evlog_tests.py、tools/regression/suite-policy.json
• docs/plans/original-completion-2026-10-02/execution/p24-02-evlog/**、docs/plans/original-completion-2026-10-02/execution/completion_marker_contracts.json
• autoload/simulation_runtime.gd と他の製品の file は変えない。新しい .gd の file を足すなら、import が作る .uid も同じ範囲（tests/**）の中に限る。製品の側に新しい file が要るなら、登録の前に Root と範囲を見直す。

8. 原単位との差（開示）

• P24-02 の残りは未達のまま: 配置・無効ドロップ・モーダル・停止と再開・フキダシ・カットイン・クリックの代替・日本語の入力と表示の倍率、event_log のうち「理由」（操作の失敗の理由を日本語で出す）と、長い通常の記録の流れ。
• P24 の package の上流（P09・P15・P16・P18・P19・P23）は、インスペクター・思考の記録・フキダシ・カットインなどに要る。この作業は、今の製品が出す記録の表示だけを扱うので、その上流を要らない。P24 の package の完了には数えない。
• P07-01-WX の残件「予報が未識別の記録と出る」は、この作業の受入で解消する。P07-01 の原単位は、この作業では変わらない。

9. 検証

• validation p24-evlog（tools/run_p24_evlog_tests.py --output {build_dir}/p24-evlog-evidence。tools/run_p16_dismiss_tests.py と同じ guarded の段の手順を、名前・名簿・再開の段・handoff・protocol 名の明示の置き換えで作る）。
• 狭い roster: 新しい suite tests/ui/test_event_log_readable.gd（F1〜F7）と、既存の tests/ui/test_event_log_ui.gd・tests/transport/test_runtime_warp.gd・tests/environment/test_p07_weather_runtime.gd・tests/staff/test_rescue_elevator.gd・tests/s6/test_runtime_snapshot_serialization.gd・tests/s6/test_runtime_save_lifecycle.gd。再開の2段 tests/ui/test_event_log_readable_restart_1_write.gd（予報とワープの行を含む保存。唯一の生成ファイルは handoff）と ..._2_read.gd（別の process で読み、行と文が同じで重複しないことを確かめる）。
• その後: 正式の validation → 最終の S の全 roster を1回 → fresh な独立レビュー（この補助の作業の範囲。原単位の whole-unit の受入ではない）。速度の調整の作業と、微小な変更ごとの全回帰はしない。

10. 開示

• UI は今の部品のまま（完成の見た目ではない）。Windows 実機・IME・OS の倍率は後。
• 題の文言（§3 の 1）は実装の選択で、人の新しい承認ではない。天候の語は上部の表示の既存の語を使う。
• 試験の入力は viewport の入力で、OS の入力ではない。