データの契約

本ドキュメントは、データについて守り続ける契約だけを置く。 具体的なフィールド名・型・JSON の実例は書かない。それはコードが正である（ドキュメントの規約）。数値そのものはバランス、実装の方針はコーディング規約。

定義データとセーブデータの区別

この2つを混ぜないこと。 セーブデータに定義データの中身をコピーせず、ID 参照だけを保存する。

.tres Resource で持つ（ADR-0010）。ページ・敵・バランスの3種類。

定義の ID は一意で、一度振ったら変更しない。 セーブデータから参照されるため、変えると既存のセーブが壊れる
ページの定義は、未来面と過去面の両方ぶんの効果を持つ（ADR-0025）。配布時にどちらの面が書かれているかは定義側の属性である。まだ書かれていない面の効果も定義に存在し、プレイヤーへ提示される — 白紙は「未定義」ではなく「未取得」である
ペン強化後の作用列も面ごとに定義に存在し、プレイヤーへ提示される（ADR-0038）。差し替え後の列を使う前から確認できる
銘 = 刻のプレイに専用の定義は持たせない。 過去面 → 未来面の順に実行することで表現する
バランス定義はバランスと一対一に対応させる。 バランス調整がこのファイルの編集のみで完結し、コード変更を伴わないことを設計目標とする

この2つはバランス定義の中に持つ。 どちらも効果が「1つの数値を1つのパラメータに足す」だけであり、Resource に切り出しても中身が数値1つになるためである。

効果の合成や条件分岐を持つようになった時点で、ページと同じ作用の列（ADR-0035）へ移す。

盤面上の1枚が持つ状態は、定義とは別のオブジェクトに置く。 .tres は共有キャッシュされるため、定義を直接書き換えると同じ定義を使う全ての札に波及する（コーディング規約）。

同じ定義から作られた複数枚を区別できる識別子を、実行時インスタンス側に持たせる。

ペンの状態は面ごとに持つ。 1枚のページについて、未来面と過去面それぞれが「白紙／書かれている／ペンで強化済み」のいずれかの状態を取る（ADR-0025）。ページ単位のフラグ1つでは表現できない。

プレイヤーの選択を待つ作用は、原子的な操作として扱う。 選択の途中では中断できず、選択待ち状態はセーブ対象に含めない（効果システム）。

to_dict() / from_dict() を各集約に実装し、JSON で保存する。 ResourceSaver / var_to_bytes() は使わない（理由は ADR-0015）。

戦闘中に中断した場合のみ、戦闘状態が保存される。戦闘中でなければ空である。

山札・手札・捨て札は順序が意味を持つ。 集合ではなく配列として保存すること。

「保存前と見分けがつかない状態」の定義がこれである。 以下が全て保存されていなければ復元できない。

セーブデータの先頭に version を持つ
読み込み時、version が現在より古ければマイグレーションを適用する
プロトタイプ期間中は、マイグレーションを書かずに「読めないセーブは破棄する」方針でよい。 ただし version フィールド自体は最初から持つこと（後から追加できない）

保存先は user://save.json の1本のみである（ADR-0021）。

敵の付随効果の具体的な種類はプロトタイプのスコープ外である（PRD スコープ境界）。