Artifact entry には表示名、日付、version、footprint、visible effect、weapon context が必要です。interface に number がなければ推測しません。公式説明は Artifact と Tablet の関係を示しますが、具体的な behavior は current run が証明します。
配置を試す
Artifact を置き、同じ action を三回行い、effect、reliability、movement cost を見ます。その後に外すか位置を変えます。Community の table を official database としてコピーせず、capture には version context を残します。
仕事で置き換える
出る部品と入る部品の仕事を比べます。rarity は良さの証明ではなく、退路を消す場合があります。Builds で目的を定義し、Tablet 依存ならその配置を記録します。
責任ある catalog
official、current in-game、community report、needs test の label を使います。Early Access と public 1.0 を混ぜない、短くても audit 可能な catalog にします。
maintenance
patch 後は中央の配置と optional combination を順に再試験します。古い結果を historical として残し、 と公式 Steam の記録に source をつなぎます。
recommendation の限界
一つの weapon で働く Artifact が別の weapon で失敗することがあります。試していない action も記録し、local observation を universal rule と誤解させません。
ficha を閉じる
mode、platform、version、次の試験で record を閉じます。新しい evidence が出たときに catalog を安全に広げられます。
catalog の一行は、他の player が同じ問いを試せる程度に具体的にします。どの部屋で、どの武器と配置を使い、何が画面に見えたかを記録します。名前だけを並べる一覧は検索には便利でも、更新や platform の違いが出たときに判断材料になりません。
Artifact の価値は、単独の effect と周囲の空間の両方から考えます。置くことで主行動が安定しても、退路や次の reward の候補を失うなら tradeoff があります。試験前後の layout を残し、入れ替えで何が良くなり何が悪くなったかを短く書きます。
結果が確かでないときは、catalog から消すのではなく label を pending に戻します。別の version、chapter、mode で確認できたかを分ければ、古い記録も歴史的な手がかりとして役立ちます。新しい observation が過去と違っても、どちらの条件だったかが分かれば誤った一般化を防げます。
配置試験では、Artifact を置く前の状態と、外した後の状態をできるだけ同じにします。変更したのが一つだけなら、効果、移動のしやすさ、次の reward を受ける余裕を比べやすくなります。二つ以上を入れ替えた場合は、その結果を広い synergy の証拠ではなく、次の切り分けが必要な観察として扱います。