Tablet の解放情報は、コピーした route ではなく現在の menu から始めます。Sephiria の Steam page は strategic inventory で Tablet が Artifact を強化することを示しますが、完全な解放 catalog は公開していません。表示名、条件、chapter、mode、platform、version を写してから confirmed と呼びます。
base-game AppID 2436940 と、別 product の demo AppID 2686970 を混ぜません。Early Access の古い画面は歴史的な lead になり得ますが、public release の現在の条件とは分けます。
解放と初回使用を分ける
menu に名前が現れたこと、選択できること、run で実際に配置できることは別の確認です。ChaptersやAchievementsの進行が関係しそうでも、表示された message と実際の状態を一つずつ記録します。
提案された route を確認する
community の route は、何を変えれば条件が変わるかという問いにします。save、chapter、mode を固定して一つだけ条件を変え、menu を閉じた後にも Tablet が選べるかを確認します。結果はLayoutsで配置試験へつなぎます。
product と branch を確認する
base game と demo、public release と Early Access、solo と co-op の境界を毎回書きます。似た screenshot でも product が違えば requirement の証拠にはなりません。変更が official note に出ていればUpdatesを参照します。
曖昧な条件を記録する
「この辺りで解放された」という報告は、確定した手順へ膨らませません。表示された文字、直前の action、chapter、reward、save、version、confidence を残し、未確認の部分は pending と書きます。次に試す条件を一つに絞ります。
effect と別に解放を公開する
解放された事実は、その Tablet が全ての build に適することを意味しません。まず使える状態を確認し、その後に footprint、activation、Artifact との関係を別の protocol で試します。二つの記録を分離すると、unlock と recommendation が混ざりません。
menu が不明瞭なとき
表示が曖昧なら、画面の変化、保存後の状態、別の run での再現を順に確認します。確認できない route は削除せず、どの evidence が足りないかを明記します。追加の変化があればProgression、更新後の比較はUpdatesへ戻し、最後にもう一度Layoutsで使用結果を試します。
解放条件を調べる目的は、速い route を作ることだけではありません。どの状態が必要で、どの状態が無関係だったかを他の player が確認できるようにすることです。menu の文、直前の action、保存、chapter、mode、platform、version を一緒に残し、確定した事実と推測した意味を別の行にします。条件が変わったときは古い記録を消さず、どの release に属するかを付けます。
Tablet が使えるようになった後は、解放ページで performance を断定しません。まず配置できるか、見える effect があるか、戻したときに状態が変わるかを小さく試し、そこから build や synergy の別の問いへ進みます。解放と使い方を分離すれば、未確認の優劣が guide 全体へ広がりません。