オプションgeneration: GenerationDefsオプションgeneratedTypes: GeneratedTypesオプションcraftingConditions: Requirements読み取り専用cardフィルターバーに並ぶボタン（card_filters、ScreenLayout.md 8.1.3節）。宣言順がそのまま
並び順で、絞り込みを解除する「すべて」は含まない（UIが常に先頭へ置く）。
非公開 読み取り専用crafting製作の工程を進めるのに満たしていなければならない条件（crafting_conditions、13.3節）。
全レシピ共通の1本で、宣言が無ければどんな状況でも作業できる。
読み取り専用generatedロード時に生成された型の座標表（GameElementDefinition.md 3.5節）。生成型は名前も表示名も 組み立てた結果でしかないため、素の型と軸の値の組をここへ残す。becomeの行き先解決も、 製作中オブジェクトから完成品を引くのも、この1つの表が答える。
読み取り専用generation地形生成の定義一式（terrain_generation.yaml）。 生成定義を1つも含まないロードではundefined（地形生成を使わないCodexも成立する）。
非公開object読み取り専用object読み取り専用objects読み取り専用property読み取り専用propertyプロパティのタグ（6.7節）の名前空間。object_defのタグ（tagNames）とは別で、property_tags で
宣言された順にIDが振られる。UIはこのIDの昇順をカテゴリの表示順として使ってよい。
読み取り専用recipeレシピ一覧の棚に使うタグ（recipe_categories、Windows.md 9節）のグローバルID。
並びが優先順位で、完成品は最初に一致した棚にだけ載る。
読み取り専用slot非公開symbolic読み取り専用symbol読み取り専用tag非公開variation読み取り専用vocabularyコードがYAMLの単語へ寄せている依存の一覧（WorldVocabulary参照）。
型を値に持つ（6.9節）と宣言されたプロパティのグローバルID。読み方はsymbolicPropertiesと同じで、 答えるのは「この値は型か」だけ。
シンボル型（6.6節）と宣言されたプロパティのグローバルID。同じ名前でも型ごとに宣言が違いうるので、 1つでもシンボル型として宣言していれば含める。
値をどう見せるかは読み手が決めるので、ここが答えるのは「この値はシンボルか」だけ。
このスロットへ、外から持ち込める型が1つでもあるか。単独で在れない型（bound_to_owner、7.9節）
しか受け付けないスロットは、持ち主の中で生まれる以外に入りようがない——怪我のスロットがこれ。
画面はこれを見て「落とせる場所」の空枠を出すかを決める。
その識別子の型が名乗る絵の名前（art、4.3節。宣言が無ければ識別子そのもの、ObjectDef.artName）。
登録の無い識別子でも識別子をそのまま返す——絵の在庫に無ければどのみち絵は出ない。
絵を引く鍵はこれであって識別子ではない。 識別子で引くと、1枚を共有している型が絵を持たない 扱いになる。
非公開 静的declaredロード時に自動生成された型か（3.5節）。一覧にも対応表にも自分の場所を持たない——名前も絵も 素の型から組み立てるので、並べても同じ物の別の顔が増えるだけになる。
変種の軸の値になっている型か（3.5.1節。液体の種類・食べ物の加工）。軸の先の変種へtraitを配るだけで、 この型自身の個体は作られない。
作りかけの軸は見ない——その値はレシピの名前で、型の名前ではない（RecipeSystem.md 1節）。 同じ名前の型が在っても、それは軸の値ではない。
タグ（4.1節）を持つobject_defの識別子を、宣言順（グローバルID順）で返す。誰も持たないタグでは空。 タグは型のグループを指す唯一の手段なので、「locationな型の一覧」「選べるキャラクタの一覧」は いずれもこれで引く。
受け取るのは名前ではなくID——コードが名指しするタグはWorldVocabularyに並んでいるので、
ここで文字列から引き直すと同じ語が2箇所に書かれる。タグを名前で名乗る宣言から引くなら、
呼ぶ側がtagNamesでIDへ直してから渡す。
非公開reason実効値が実体値と食い違いうる理由。一致するならundefined（requireRangeEventsOnUnmodifiedProperties参照）。
非公開require名前で引いたプロパティが、どこかの型で宣言されているか。名前を作る口（propsのキー）と
名指しする口が同じinternだと、綴りを間違えた宣言はその場で新しい名前を作って通ってしまう
——引く先が無いプロパティは実行時にただ「持っていない」と読まれるので、遊んでも何も起きない。
「どこかの型が宣言していればよい」までしか見ないのは、誰を見るかが実行時にしか決まらないため
（条件のsubjectもdeftnessの作り手も、指す相手は状況で変わる）。持っていない個体を引く宣言は
正しい書き方（「その腕を持つ者だけ速い」）なので、そこまでは踏み込めない。
非公開require名前で引いたスロットが、どこかの型で宣言されているか。見るのは「どこかの型が宣言しているか」 まで——requireDeclaredPropertyと同じ理由で、指した相手がそのスロットを持つかは実行時にしか 決まらない。
非公開require名指しした段（6.4節）が、そのプロパティのどこかの宣言に在るか。段は型ごとのPropertyDefが持つ ので、「どの型が持つか」ではなく「その名前の段を宣言した型が1つでも在るか」までを見る （requireDeclaredPropertyと同じ理由）。
綴りを間違えた段名はPropertyDef.isInStageが偽を返すだけなので、宣言は落ちずに一度も効かない。
非公開require名前で引いた型が、object_defs（生成された型を含む、3.5節）に在るか。
非公開require行き先をプロパティから引くなら、そのプロパティは型を値に持つと宣言されていなければならない
（value: {object: ...}、6.9節）。
ただの数値プロパティを引く宣言は書けてしまうが、実行時にはその値をグローバルIDとして扱うので、
無関係な型を引くか、黙って何も起きないかのどちらかになる。指せる先がsingletonかどうかは
ここでは分からない（プロパティは型ごとに違う値を持てる）が、それは宣言の側
（propsの{object: ...}）が既に受けている。
非公開requirerequired_props（4.2節）の約束を果たしているか。タグを名乗った以上、そのタグが要求する
プロパティは宣言されていなければならない。
宣言漏れは静かに効く——weightを書き忘れた道具は0gとして持ち運べ、loadを書き忘れた キャラクタは何を担いでも平気になる。テストではなくロード時に落とすのは、パックの定義も同じ 約束の下に置くため（テストは同梱のYAMLしか通らない）。
何をどのタグに要求するかはエンジンではなく世界が決める（要求を1つも書かない世界も成立する）。
非公開require著者が書いたon_max/on_min（6.3節）を持てるのは、実効値が実体値と一致するプロパティだけ。
端のイベントは実体値で発火し（PropertyValue.add）、段・バー・conditionsは実効値で読む （getEffectiveValue）。両方が食い違いうるプロパティが端のイベントを持つと、「バーは満ちているのに 何も起きない」「まだ空でないのに尽きる」が起こりうる。そのときの正しい挙動をまだ決めていないので、 決まるまでは書けないようにしておく。
食い違いの原因はmodify（8.3節）とbase（6.5節）。中身の重さの伝播もエンジンが生やす
modifyなので、前者に含まれる（containerPropagation）。
modifyされるかは型ひとつでは分からない（宣言するのは他の型）ので、世界全体を持つここで見る。
非公開require型の名前で行き先を指せるのは、世界にただ1つ在る型（singleton、15節）だけ。
複数在りうる型を指すと、どの個体へ行くかは世界の形が決め、著者の書いた通りには動かない ——島へ戻る航路が、出た浜ではなく島で最初の浜へ着いていた。
非公開require宣言が名指しした別の宣言（DeclarationReference）を、実際に指せているか。名指しの種類ごとに 見るものは違うが、どれも「書いた時点で分かる誤り」なので、遊んで気づくのではなくロード時に落とす。
指した先の型もプロパティの宣言も自分より後で読まれうる（複数ファイル・patch_object_defs）ので、
全部が揃ったここで見る。
世界にただ1つ存在する型（singleton: true、15節）のグローバルIDを宣言順で返す。
「1つだけ存在すべき」を「世界を作った時点で必ず1つ在る」と読む（NewGame.startNewGame）。そうでないと、
型の名前で行き先を指すmoveのto_object（9.6節）が、まだ湧いていない場所を指すことになる。
非公開 静的stage型が宣言したプロパティと、その宣言が持つ段（6.4節）の名前。プロパティを引けること自体が キーの有無なので、段を持たないプロパティは空の集合を持つ。
型を値に持つ（6.9節）と宣言されたプロパティの値を、型の名前へ戻す。越境の扱いは trySymbolNameOfPropertyValue と同じ。
シンボル型（6.6節）と宣言されたプロパティの値を、シンボルの名前へ戻す。宣言に数値リテラルが 書かれていれば、どのシンボルのIDでもないのでundefined。
値を名前まで戻すのはここ——値がどの名前空間のものかを知っているのは名前空間を全部持つ このクラスで、読み手（条件の文・カードの説明・天気の表示）はそれを訊くだけ。値からIDへの 読み替えそのものは symbolGlobalIdOfPropertyValue が持つ。
枠ごとに、その枠が空いているときに薄く敷いて見せる型（CardView.md 11節）。
枠数を宣言していないスロットでは空の並びを返す。
どの枠も同じ受け入れを宣言しているスロットでは空。 そこへ何が入るかはその場所そのものが
既に言っているので、枠が言っても二度目の答えになる——手持ちの空き枠に持ち物の絵を順に送っても、
何も絞られない。枠によって宣言が違うスロット（炉の火の中と石の上、FireSystem.md 1.1節）
でだけ、どの枠がどちらなのかを枠自身が名乗る。
単独で在れない型（bound_to_owner、7.9節）は挙げない。 探してくる先が無いので、
「これを持ってくればよい」の絵にならない。当てはまる型がまだ1つも無い枠も空になる。
絵にできない受け入れ（TypeMatchRule.canBePictured）も空。
製作の工程を進める条件のうち、agentが満たしていない最初の要件（満たしていればundefined）。
可否と「なぜできないか」を同じ1回の評価から返すのは、レシピの解放条件
（RecipeDef.unmetUnlockRequirement）と同じ理由。成果物のインスタンスはまだ無いので、
参照できるのはagentだけ（13.4節）。その1つを欠いた問いは無いので、agentは必ず要る。
この型が素の型からどれだけ動いた先に居るか（3.5節）。軸の名前 → その軸の値の識別子で、素の型では空。
どの軸かで扱いを分けません。 作りかけも中身入りも「素の型の変種」で、違うのは軸の名前と、
その名前に紐づく書式（Localization.md）だけです。
ロードされたYAMLファイル全体を表す集約オブジェクト（GameElementDefinition.md 3.1節）。 本体データ（ObjectDefTable）、独立した名前空間（object/property/slot/tag/property_tag/symbol）の NameRegistry、およびWorldVocabularyを持つ。ロード完了後は不変として扱う。 symbolNamesはシンボル型props（6節）の値の名前空間。実行時状態（WorldObject）は含まない （runtimeが担う）。
グローバルID→識別子の引き当ても引き受ける。名前空間をすべて持つのはここだけのため。