非公開 読み取り専用allow非公開 読み取り専用amount非公開 読み取り専用from非公開 読み取り専用linked非公開 読み取り専用to非公開 読み取り専用to運ばれてきた相手（instrument）を丸ごと消すか（destroy、9.3節）。
入り切らない端数の行き先を決める側が読む（9.5.1節）——相手が消えるなら、出どころへ残した分は 相手ごと失われる。destroyを書ける場所のうち相手が居るのは操作だけなので、読むのもそこ（parseInteractions）。
相手（instrument）から移す輸送のうち、入り切らない分を出どころへ残すもの（allow_overflow が
既定のfalse）を含むか（9.5節）。
相手を消す操作でこれを含むのは、端数を黙って捨てる形なので、ロード時に落とす側が読む
（parseInteractions）——捨てるならallow_overflow: trueと名乗る（9.5.1節）。
この輸送の宣言（TransferReading参照）。出す側はamountだけ減り、受け取る側はto_amountだけ
増え、linked_addは全量移った場合の値で並ぶ。
在庫が満ちている前提の上限。 実際に動く量は出せる量と空きで目減りする（applyがそれを見る）。
移送先の残り（PropertyValue.remainingTransferCapacity）が尽きるまでに、何個ぶん移せるか。 移送先・移送元が解決できなければ、そこで打ち切る。
出す量は「出せる量」（PropertyValue.availableToTransferOut）とAmountの小さい方。allow_overflowが falseならさらに「受け取れる量」（remainingTransferCapacity）でも制限するが、単位が違えば 受け取れる量は移送先の単位なので、出す側の単位へ割り戻してから比べる。
linked_add（9.5節）は実際に出した量に比例（amount * actual_moved / Amount）してスケール適用する。 from/toが解決できない・対象がそのプロパティを持たない場合は何もしない。
受け取る側は、出した後に辿り直す。 出す側のon_minからbecome（9.9.1節）が走ると受け取る側の
プロパティは作り直されるので、先に掴んだ個体へ入れると、出した分が現物のどこにも残らない。
今この文脈で、この効果が行き先を持たないために、宣言している操作そのものが成立しないか（9.9節）。 成立しない操作は候補に出さない——落とせるのに何も起きない、を作らないため。
既定はfalse＝妨げない。 repeatLimitingVesselCountと同じく、取りこぼしても安全側（操作は出る）に 倒れるので抽象にしない。
輸送の両端を影響の辺として書き出す（PropertyInfluences参照）。
両端は互いの原因になる。 受け取る側が増えるのは出す側の在庫があるからで、出す側が減るのは 受け取る側へ持っていかれるから——1本の輸送が、どちらの端から見ても相手のせいで動いて見える。
この効果が何を宣言しているかを読み上げる（EffectReader参照）。抽象なのは取りこぼしを防ぐため ——既定を持たせると、動詞を1つ足したときに読み手が黙って何も受け取らなくなる。
移送先が全candidatesで共通なら、その値が器になる（1つ）。移送先がinstrumentなら、器はcandidateごとに 別なので回数の上限を決めない（0）。
transfer（9.5節）の1命令。fromプロパティの実体値から、実際に出せる量とAmountの小さい方だけを toプロパティへ移す（「在庫に応じて実際に動く量が変わる」移送）。YAMLは出どころと行き先を、 入れ子ではなくフラットなフィールドで表す（9.5節）。
fromとtoの単位が違う場合（mLの水 → tick数のhydration）は、
amountに対して受け取る側が どれだけ増えるかをto_amountが持つ。換算率をエンジンは知らず、移送する側が宣言する。