# 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 の入力ではない。