ADR-0010: Inventory Replication — CARRY from Outcomes, SharedStorage and Node Lists on the Wire, Equipment, and the Id Codecs

Status

Accepted

Accepted 2026-09-11. Gate 0 confirmed GO the same day by the two-machine friend playtest (production/playtests/gate-0-2026-09-11/, record production/gate-checks/gate-0-provisional-pass-2026-09-11.md); the provisional note and revisit clause this ADR was written under are discharged. Playtest observation carried to the register: occasional remote stutter at ≈ 150–180 ms RTT (interpolation tuning, ADR-0009 §6).

Date

2026-09-11

Engine Compatibility

Revisit clause (Gate 0)

No section is at risk from a feel verdict. The two provisional items are ADR-0008's: the one-tick state lag (affects when a StorageNet row visibly changes relative to its InventoryTransferred outcome — presenters act on the outcome, §2) and the snapshot chunk size.

Documents Amended by This ADR

ADR Dependencies

Context

Problem Statement

The host already owns every bag and every chest: InventoryTx holds the per-PlayerKey carries and per-ContainerId storages, and InventoryTransferCommand/HarvestResolveCommand/PlaceStructureCommand mutate them inside the drain. What is undecided is how any of that reaches a client: the spec calls CARRY "owner-authoritative and client-predicted" while every mutation is a host command; SharedStorage must render host-confirmed state only; harvesting wants swingsRemaining "continuously replicated" and its EC16 wants that bounded; crafting's instanceTag and every ItemId/ContainerId are strings, and NetworkList<T> accepts only unmanaged rows. TR-inv-007 says the CARRY representation is "undefined; must be decided by the inventory replication ADR". This is that ADR.

Constraints

• ADR-0008 §5: state a joiner needs = server-written NetworkVariable/NetworkList on the owning object; an edge = OutcomeRpc; never both for one fact (exception: append-only InstanceMetadata). ADR-0008 §4: outcome payloads are fixed-layout, no strings.
• Inventory Rules 1, 6, 7: two components, never one system; transfers atomic on the host in arrival order; prediction only on the player's own CARRY; storage renders host-confirmed state only; the duplication/loss invariant.
• Harvesting: yield-into-bag flash and crack stages are host-confirmed broadcast only (no predicted harvest); EC1 (a disconnected player's in-flight swing still lands in its persisted CARRY).
• Crafting Rule 4/7: gear identity is a host-monotonic instanceId riding the stack as an opaque tag; InstanceMetadata permanent.
• BB Rule 12 / storageEmpty: a storage placement instantiates one SharedStorage; demolish requires contentCount == 0.
• ADR-0004: carries (per player, equipment inside), sharedStorage (per container), harvestDiffs (droppable) are the persisted tables; only the host loads and reconciles.
• Shipped shapes are kept: ItemStack(ItemId, Count, string InstanceTag), ICarryInventory/ISharedStorage (string tags), IInventoryTx, NodeTable keyed (SocketId, NodeId), NodeId.Value = the node's index in LandInstance.Nodes (assigned nextId++ by Layout.Build — deterministic on every machine).

Requirements

TR-inv-002 (CARRY owner-side + predicted; SharedStorage host-auth, N instances), TR-inv-004 (no world items; two equipment slots outside the bag), TR-inv-007 (CARRY representation), TR-inv-003 (atomic transfers — already met by InventoryTransferCommand; this ADR adds the client half), TR-harv-001 (swingsRemaining replicated), TR-harv-007's crack-stage half (host-confirmed), TR-craft-004/008 (instance ids on the wire; craft commit deltas reach the bag view), TR-bb-006 (storage placement instantiates a container).

Decision

Alternative A: the host's tables are the only truth. A player's CARRY never rides a NetworkVariable: the owner's CarryView is seeded by a CarrySync outcome when its SessionReady executes and thereafter applies the outcomes the host already broadcasts (HarvestResolved, InventoryTransferred, CraftCommitted, StructurePlaced/Demolished, EquipmentChanged), with a predicted overlay for the owner's own transfer clicks only; each SharedStorage is a StorageNet NetworkObject spawned by the placement command carrying a slot-indexed NetworkList<StackNetRow> mirrored from the host table after every drain; each docked land's nodes are a NetworkList<NodeNetRow> on LandNet, written before Spawn() and on every Decrement; string ids cross the wire through two deterministic codecs (ItemIndexTable, TagCodec); equipment is two commands and one outcome.

1. Ids on the wire — the two codecs

2. CARRY — host truth, owner view from outcomes, prediction for transfers only

• Truth: InventoryTx._carries[PlayerKey] on the host (shipped). Every mutation is a command's Execute (harvest yield, transfer, craft consume/produce, structure cost/refund, equip/unequip). Nothing on any client is authoritative for a bag — the spec's "owner-authoritative" reduces, on the wire, to owner-visible and owner-predicted, which is what its Rule 7 and AC "own bag updates within one frame of input" actually require. TR-inv-002 is satisfied in that reading and this ADR states the reduction rather than pretending a second authority exists.
• CarryView (Runtime.Inventory, one per local player; the HUD's ICarryView): Confirmed : StackBag + Pending : List<CarryDelta>; Visible = Confirmed with pending deltas applied. Seeded by CarrySync and updated by outcomes:

Two shipped commands mutate without a bag-delta outcome (TD C1). (i) HarvestResolveCommand's post-Decrement BagFull path spends the node's swing and adds nothing: the node row moves (§4) and the owner receives CommandRejected(BagFull) with a ClientSeq that matches no Pending entry (harvests are never predicted). The fold treats a CommandRejected with no matching pending entry as a no-op on Confirmed, never an error — by rule, not by luck. (ii) InventoryTransferCommand's restore path (Add fails, the source takes its stack back, Fail(BagFull)) leaves both tables net-unchanged and dirty-marks neither; StorageReplicator's dirty set is therefore correct by construction. Both are asserted (Inv_FoldHandlesUnmatchedRejection; a replicator test over the restore path). A future bag-touching command must broadcast a delta-bearing outcome — the total-switch fence catches a declared kind without a fold case, but it cannot catch a mutation with no outcome at all, which is why this rule is written down and reviewed per command. The view is therefore a pure fold over an ordered stream (Rules.Inventory.CarryFold.Apply(confirmed, pending, outcome, self, data) — engine-free, EditMode-tested), and OutcomeRpc is reliable and per-object ordered (ADR-0008 §3), so Confirmed equals the host table after every outcome by construction. No NetworkVariable, no per-tick lag (ADR-0008 §2's lag is for state; outcomes leave the same tick).

• Prediction (Rule 7, AC "within one frame"): on a deposit/withdraw click the owner submits InventoryTransfer and pushes CarryDelta{ClientSeq, Direction, Item, Count, Tag} to Pending; Visible updates that frame. The storage side is never predicted (StorageView renders StorageNet rows only — Rule 7's honest no-op: the loser's row vanishes on the host's delta, its bag never shows the stack). Harvest yields are not predicted (harvesting: yield flash is host-confirmed). Crafts and placements are not predicted either (their commit is the host's; the stance/ghost FX are).
• Why CarrySync on SessionReady and not in the snapshot: a disconnected player's in-flight swing still lands in its CARRY (harvesting EC1) and a transfer from another player cannot touch it, but a HarvestResolved that lands between the snapshot build and the joiner's SessionReady would be an outcome the joiner never received (no player object yet — ADR-0008 §6). Sending the bag from inside SessionReadyCommand.Execute — the same drain that creates the row — closes the window: every later outcome for that key follows CarrySync on the same ordered object. ADR-0008's snapshot therefore carries no CARRY at all (amended); CarrySync is also the only resync tool (host-initiated; there is no client "request resync" path — if a view ever diverged, the next CarrySync is at rejoin, and divergence is a bug the EditMode fold tests exist to prevent).
• The host's own CarryView is seeded by CarrySync too (TD C4): StartHost enqueues a local SessionReadyCommand for the host's PlayerKey on the channel, so host and client take one code path. Size bound: CarrySync at bagSlots = 10 is ≈ 90 B; the 128 B envelope holds bagSlots ≤ 14. inventory.json's range (8–16) is therefore validated against the wire cap (bagSlots ≤ 14 until ADR-0008's envelope is amended) — a data tweak can never silently overrun the wire.
• transferBatchWindow (inventory.json, default 0): one command per click. If raised, the owner coalesces clicks of the same direction/item/tag inside the window into one InventoryTransfer with the summed Count and one Pending entry — no wire change.
• Other players' bags are never on any client. No party-bag inspection at MVP (HUD spec); a Tier 1 feature would be an owner-addressed outcome, not a variable.

3. SharedStorage — one StorageNet per container, slot-indexed list

• Object: StorageNet : NetworkBehaviour on the SharedStorage prefab (in NetworkPrefabsList, not addressable): NetworkVariable<uint> StructureInstance (server-write, set before Spawn()), NetworkList<StackNetRow> Rows (server-write, fixed length = storageSlots, one row per slot, ItemIndex = 0xFFFF for an empty slot). Slot-indexing means a transfer changes exactly the rows it touches via the indexer (Rows[i] = row — V2), never Add/RemoveAt, so clients see no reordering and the UI slot grid maps 1:1.
• Spawn/despawn ride the drain's deferred effects (ADR-0002 §5 step 4): PlaceStructureCommand (storage category) calls ctx.QueueSpawn(SpawnRequest.SharedStorage(instance, slots)) → after the envelope loop the host instantiates the prefab, sets StructureInstance, fills Rows from InventoryTx._storages[container].Snapshot (empty at placement; non-empty on load — see below), and Spawn()s. DemolishCommand gates on ChestNotEmpty (shipped ReasonCode) then ctx.QueueDespawn(instance) → after the loop, Despawn(destroy: true). StorageSpawned/Despawned are not outcomes: the object's existence is the state (ADR-0008 rule); StructurePlaced/Demolished are the edges presenters use (ADR-0011).
• StorageNet.Rows is a mirror, not host-rail state (TD C3): no command gate reads it, no save table contains it, and it is reconstructible from InventoryTx at any instant. ADR-0002's invariant 4 governs the tables; the mirror is written by exactly one host-side writer after the drain, in the same phase-4 window as the outcome flush, so a client can never observe a row that no command produced.
• Mirror, single writer: StorageReplicator (host) runs once after every Drain() (ADR-0002 step 4, before Save.EndOfDrain) and, for every StorageNet whose table changed this drain (dirty set from ctx.Persist(inv.StorageTable)), diffs Snapshot.Slots against Rows and writes only the changed indexes. Nothing else writes Rows (fence). Cost: ≤ storageSlots comparisons per dirty container per drain.
• Load: on host boot the reconciled sharedStorage table (ADR-0004 stage 7) is applied to tables before StartHost; the containers themselves are spawned when the structure registry is instantiated (ADR-0011's boot step) with Rows pre-filled. A late joiner receives every StorageNet with its rows in the spawn message (V1's twin) — which is why the snapshot drops the sharedStorage table.
• Clients: StorageView per StorageNet (Rows + OnListChanged → UI); InventoryTransferred is the feedback edge (flyout, sound) and may arrive one tick before the row delta (ADR-0008 §2) — presenters act on the outcome's payload, the grid on the row (registered rule).
• Rule 7 on the wire: two withdraws of the last stack → both InventoryTransfer commands drain in arrival order; the first succeeds (InventoryTransferred + row delta), the second fails NotEnoughMaterials → CommandRejected to its owner → that owner's Pending entry is dropped and its bag view never showed the stack in Confirmed. Total items conserved by the command's own conservation check (shipped).

4. Nodes — NetworkList<NodeNetRow> on LandNet, written before Spawn()

• LandNet.Nodes : NetworkList<NodeNetRow{ushort NodeIndex, byte SwingsRemaining}> (server-write), index-aligned with LandInstance.Nodes (NodeIndex == NodeId.Value, redundant but self-describing on the wire). swingsTotal is data (HarvestConfig), not replicated.
• Population before spawn — the shipped INodeSeeder seam (LandSeams.cs; NoOpNodeSeeder today) is implemented by NodeListSeeder: on LandActivated, after NodeTable.OnLandActivated(instance, swingsTotal, keptDiffs) (which already applies kept HarvestDiff rows — EC5), copy every node's SwingsRemaining into Nodes before ILandNetSpawner.Spawn(...) (ADR-0005 activation order step 2 → 3). V1 (confirmed from source) — the spawn message carries the full list; NodesReady is not needed and ADR-0005's contingency clause is closed by this ADR.
• Decrement: LandStateAdapter.Decrement (shipped: node + diff row in one call) additionally sets Nodes[NodeIndex] = new NodeNetRow(NodeIndex, after.SwingsRemaining) — the same critical section, so the list can never disagree with the table.
• Clients: NodeView (per node visual, presentation) subscribes to OnListChanged for its index and derives the crack stage from SwingsRemaining / swingsTotal (harvesting: derivation is Harvesting's, visualisation is UI's — the presenters epic already ships the flyout over HarvestResolved). Harvesting EC16: a mid-docking joiner gets the whole list with the land's spawn; staleness is bounded by ADR-0008's one tick.
• Teardown: LandNet despawn (ADR-0005) takes the list with it; NodeTable.OnLandTornDown forgets the socket. Nothing persists from the list — harvestDiffs is the host's save table (ADR-0004), a client never needs it (snapshot drops it). This discharges ADR-0008 §6's "ADR-0010 owns the merge": with harvestDiffs out of the snapshot there is no second source to merge against — the list is the only node truth a client ever sees (TD C7).

5. Equipment — two slots outside the bag, two commands, one outcome

• State: the host's CarryInventory.Equipment[2] (EquipmentSlot.Weapon, .Armor; each an ItemStack? — the tagged stack itself, moved out of the bag) — persisted in the carries table's equipment array (ADR-0004, the shipped reserved field). CombatState.PlayerActor.Equipped{Weapon, Armor : InstanceId?} (ADR-0015) mirrors it through ICombatState.SetEquipped, written only by these commands (single writer holds).
• EquipCommand(slot, instanceTag): gates — the tagged stack is in the owner's CARRY; the item's GearDef matches the slot (IGameData); then: remove from bag (frees a slot), previous occupant (if any) goes into the freed slot, SetEquipped, Persist(carries), Broadcast(EquipmentChanged). UnequipCommand(slot): gates — slot occupied; CanAdd of the occupant to the bag (BagFull otherwise); then the inverse. Inventory Rule 4's "never requires bag slots" is thereby narrowed to the swap case (always possible); a bare unequip into a full bag is an honest no-op — the spec is amended to say so (Documents Amended).
• Capacity consequence (TD C5): moving the stack out of the bag means equipping frees a bag slot — bag capacity is equipment-dependent. This is a design-visible reading of inventory Rule 4 ("equipment is not bag space") — decided by the user 2026-09-11: equipping frees a bag slot; a bare unequip into a full bag is an honest no-op; swaps always work; the rejected fallback (the slot holds a reference to a stack that stays in the bag; capacity constant; a bare unequip never fails) is a one-line change here, not a redesign.
• EquipmentChanged{Player, Slot, InstanceId?} is owner-visible (the fold applies it); other players' equipment is not visible at MVP (no gear visuals on remote bodies — art bible Tier 1 territory). Gear hooks on the host read Equipped (ADR-0015); nothing on the wire carries a stat.

6. What is deliberately not replicated

Other players' CARRY; enemy inventories (none); harvestDiffs; InstanceMetadata beyond ADR-0008's snapshot + CraftCommitted row; any count of anything for HUD purposes other than through the structures above.

7. Fences (EditMode, every CI pass)

Architecture Diagram

HOST (drain)                                                              CLIENTS
InventoryTx tables ◄── commands: HarvestResolve · InventoryTransfer · CraftCommit · PlaceStructure/Demolish · Equip/Unequip
   │ phase 4 flush ── OutcomeRpc ──────────────────────────────────────► owner: CarryView.Confirmed = CarryFold(prev, outcome, data); Pending consumed/dropped
   │                  CarrySync (owner-addressed, from SessionReady)  ─► seeds the view on join/rejoin; no CARRY in the snapshot
   │ after Drain: StorageReplicator diffs Snapshot → StorageNet.Rows[i] ═══ NetworkList deltas ═══► StorageView (grid = rows; flyout = InventoryTransferred)
   │ QueueSpawn(SharedStorage) / QueueDespawn ── after the loop ── spawn/despawn StorageNet (rows in the spawn message)
LandActivated: NodeTable → NodeListSeeder → LandNet.Nodes (before Spawn) ═══ spawn message ═══► NodeView crack stages
Decrement: NodeTable + diff row + Nodes[i] ═══ delta ═══► NodeView
ids: ItemId ⇄ ItemIndexTable (hash in snapshot header) · InstanceTag ⇄ TagCodec(uint) · NodeId.Value = NodeIndex · ContainerId = structureInstanceId

Key Interfaces

namespace Driftlands.Rules.Inventory                    // engine-free
{
    public enum EquipmentSlot : byte { Weapon, Armor }
    public readonly record struct CarryDelta(uint ClientSeq, TransferDirection Direction, ItemId Item, int Count, string InstanceTag);
    public static class CarryFold { public static (StackBag confirmed, IReadOnlyList<CarryDelta> pending) Apply(StackBag confirmed, IReadOnlyList<CarryDelta> pending, IOutcome o, PlayerKey self, IGameData data); }
    public sealed record EquipCommand(ulong OwnerClientId, uint ClientSeq, PlayerKey Player, EquipmentSlot Slot, string InstanceTag) : ICommand;
    public sealed record UnequipCommand(ulong OwnerClientId, uint ClientSeq, PlayerKey Player, EquipmentSlot Slot) : ICommand;
    public sealed record EquipmentChanged(PlayerKey Player, EquipmentSlot Slot, string InstanceTag /* null = emptied */) : IOutcome;
    public sealed record CarrySync(PlayerKey Player, IReadOnlyList<ItemStack> Slots, ItemStack Weapon, ItemStack Armor) : IOutcome;   // owner-addressed; ≤ 128 B on the wire
}

namespace Driftlands.Rules.Commands
{
    public enum SpawnKind : byte { SharedStorage }
    public readonly record struct SpawnRequest(SpawnKind Kind, uint StructureInstance, Cell Origin, int Slots) { public static SpawnRequest SharedStorage(uint instance, Cell origin, int slots) => new(SpawnKind.SharedStorage, instance, origin, slots); }
    public readonly record struct DespawnRequest(uint StructureInstance);
    // HostContext.QueueSpawn(SpawnRequest) exists (ADR-0003); QueueDespawn(DespawnRequest) is added as its sibling. ADR-0003's member list is reviewed at each new ADR (its §Risks mitigation);
    // this ADR exercises that review and takes HostContext to NINETEEN members — Tests/EditMode/HostContextMemberCountTests' constant moves 18 → 19 in the same story (TD C2).
}

namespace Driftlands.Runtime.Inventory
{
    public struct StackNetRow : IEquatable<StackNetRow>   // unmanaged + IEquatable is the whole NetworkList constraint (src) { public ushort ItemIndex; public ushort Count; public uint InstanceId; }   // 8 B; ItemIndex 0xFFFF = empty
    public sealed class ItemIndexTable { public ushort Of(ItemId id); public ItemId At(ushort i); public uint Hash { get; } public static ItemIndexTable Build(IGameData data); }
    public static class TagCodec { public static uint ToWire(string tag); public static string FromWire(uint id); }   // 0 ⇄ null
    public sealed class StorageNet : NetworkBehaviour {                                    // one per SharedStorage; prefab in NetworkPrefabsList
        public NetworkVariable<uint> StructureInstance = new(writePerm: NetworkVariableWritePermission.Server);
        public NetworkList<StackNetRow> Rows = new(writePerm: NetworkVariableWritePermission.Server);   // fixed length = storageSlots
        internal void Initialise(uint instance, StackBag snapshot, ItemIndexTable idx);   // host, before Spawn()
    }
    public sealed class StorageReplicator { public void AfterDrain(IReadOnlyCollection<ContainerId> dirty); }   // the ONLY runtime writer of Rows
    public sealed class CarryView : ICarryView { public StackBag Confirmed { get; } public StackBag Visible { get; } public void Predict(CarryDelta d); public void OnOutcome(IOutcome o); }
    public sealed class StorageView { public StackBag Rows { get; } public event Action<int> SlotChanged; }
}

namespace Driftlands.Runtime.Harvest
{
    public struct NodeNetRow : IEquatable<NodeNetRow> { public ushort NodeIndex; public byte SwingsRemaining; }
    public sealed class NodeListSeeder : INodeSeeder { public void Seed(LandInstance instance); }        // writes LandNet.Nodes before Spawn (ADR-0005 step 2→3)
    // LandNet (ADR-0005/story 009) gains: public NetworkList<NodeNetRow> Nodes = new(writePerm: Server);  [+ NetworkVariable<bool> NodesReady iff V1 fails]
}

namespace Driftlands.Rules.Combat { public partial interface ICombatState { void SetEquipped(PlayerKey key, EquipmentSlot slot, InstanceId? instance); } }   // ADR-0015 amended; written only by Equip/Unequip

Alternatives Considered

Alternative B: an owner-read NetworkVariable<CarryNet> for the bag

• Description: server-written, ReadPermission.Owner, ten fixed rows + equipment.
• Pros: the bag is "just state"; a joiner needs no CarrySync.
• Cons: duplicates every bag-touching outcome (the rule forbids both for one fact); a fixed 10-row struct hard-codes bagSlots; the one-tick lag would make the bag visibly trail its own flyout; owner-only read permission is one more post-cutoff surface.
• Rejection Reason: user decision 2026-09-11 — the outcomes already exist and are ordered; a pure fold over them is testable in EditMode with no engine.

Alternative C: everything outcome-driven (no NetworkList for storage or nodes)

• Cons: a late joiner needs a snapshot for every chest and every land's nodes and can miss an edge between snapshot and player spawn; per-row deltas are exactly what NetworkList provides for free with spawn-time sync.
• Rejection Reason: user decision 2026-09-11; state is state.

Alternative D: one NetworkVariable<byte> per node

• Rejection Reason: LP review (QQ-13) — 40–80 variables per land on one behaviour for no gain; user decision 2026-09-11.

Alternative E: ContainerId as an arbitrary string with a runtime id map

• Cons: a second mapping table replicated or snapshotted; two ids for one chest.
• Rejection Reason: BB already issues a host-monotonic structure instance id; the container is that structure.

Alternative F: own CARRY inside the snapshot (ADR-0008 as first written)

• Cons: the snapshot-to-SessionReady window can lose a HarvestResolved for a rejoining player (harvesting EC1); a view with no resync path.
• Rejection Reason: CarrySync from the same drain that creates the row is race-free by construction and doubles as the only resync mechanism.

Consequences

Positive

• Every bag change on every client is a pure fold over an ordered outcome stream — one EditMode-tested function, no engine, no lag, no drift path that a test cannot reach.
• Chests and nodes are plain NGO lists delivered with their objects; late join needs nothing bespoke for them and the snapshot shrinks to world tables.
• Every string id has one deterministic numeric form with a hash check; the codecs are the only place a string meets the wire.
• Equipment stops being a reserved array: two commands, one outcome, one persisted field.

Negative

• The owner's bag is only as correct as the outcome stream and the fold; a bag-touching outcome added without a fold case is a silent divergence (fenced by Inv_CarryFoldIsPure's total-switch test, but the fence is on the author).
• OutcomeEnvelope grows to 128 B for one message kind (CarrySync).
• A StorageNet per chest means N NetworkObjects at the base (tens, not hundreds — BB's "low hundreds of rows at most" is structures, chests are fewer).
• A bare unequip into a full bag is an honest no-op — a spec narrowing the user must accept (Documents Amended).

Risks

• A future NGO release changes spawn-time list sync (V1 is confirmed for 2.13.2 only): the OnNetworkSpawn count assertion fails loudly in PlayMode; the NodesReady gate is the one-line fallback, kept in ADR-0005's history.
• Fold divergence in the field (a missed outcome kind): the symptom is a bag that disagrees with what the host lets you do (a transfer rejected for a stack you see). Mitigation: CommandRejected reasons surface in the debug HUD; CarrySync at rejoin restores truth; the total-switch fence prevents the class at build time.
• ItemIndexTable drift if a client's data files differ from the host's: caught by itemIndexHash at join (disconnect), never a silent mis-map.
• Storage row churn on a busy base: StorageReplicator writes only changed indexes; worst case storageSlots deltas per container per drain, ≪ 1 KB.

GDD Requirements Addressed

Performance Implications

• CPU (host): StorageReplicator ≤ storageSlots comparisons per dirty container per drain; node row set inside Decrement O(1). CPU (client): one fold per bag-touching outcome (µs).
• Memory: one NativeList per chest and per docked land (hundreds of bytes each); ItemIndexTable ≈ item count × 2 dictionaries.
• Network: node row 3 B + list delta overhead per swing; storage 8 B per changed slot; CarrySync ≤ 90 B per join; spawn messages carry ≤ 320 B of rows.
• Load time: ItemIndexTable.Build at data load, microseconds.

Migration Plan

• ItemIndexTable, TagCodec, row structs + Inv_* fences (EditMode) — first inventory replication story.
• CarryFold + CarryView with EditMode tests: a scripted outcome stream reproduces the host table for every kind; Pending consumption and rejection; CarrySync replace. CarrySync codec (ADR-0008 outcome cap raised to 128 B in the same story).
• StorageNet + StorageReplicator + SpawnRequest/DespawnRequest shapes + HostContext.QueueDespawn (member count pin 18 → 19); PlaceStructure (storage) and Demolish wire-ups belong to ADR-0011's stories, this ADR ships the object and the mirror.
• NodeListSeeder + LandNet.Nodes + Decrement row write — inside land story 009 (NGO LandNet), with V1 decided there.
• Equip/Unequip commands + EquipmentChanged + ICombatState.SetEquipped + carries.equipment live — the crafting runtime epic's first story or an inventory story, whichever lands first.
• HUD inventory/storage screens (presentation-ui-hud-screens) bind to ICarryView/StorageView.

Validation Criteria

• EditMode: the eight §7 fences with companion negatives; CarryFold reproduces the host table over a 200-outcome fixture stream (mutation-checked: dropping any fold case turns the comparison red); conservation across a transfer + rejection sequence; TagCodec/ItemIndexTable round-trips; a non-numeric tag fixture fails.
• PlayMode (host only): StorageNet rows equal Snapshot.Slots after every drain over a scripted transfer sequence; Rows.Count == storageSlots throughout; Nodes[i] tracks Decrement.
• Documented playtest / two standalone builds: V1 (list in spawn message — land and chest), V2 (indexer delta), two-client last-stack race (inventory INTEGRATION AC: exactly one succeeds, items conserved), rejoin mid-docking receives CarrySync then later outcomes in order; a joiner's node crack stages match the host's on arrival (EC16).

Related Decisions

• ADR-0008 (outcomes, snapshot, codecs' envelope), ADR-0002 (InventoryTransfer, deferred spawn), ADR-0003 (IInventoryTx, ItemStack), ADR-0004 (tables), ADR-0005 (LandNet, seeder seam), ADR-0015 (Equipped), ADR-0011 (structure/chest lifecycle), ADR-0006 (ItemIndexTable from validated data).
• design/quick-specs/inventory-hauling-2026-08-26.md, harvesting-system.md, crafting-system.md, base-building.md; architecture.md row 10, QQ-13; epics core-inventory-carry (pure half, Done) and core-harvesting (declared limbs re-opened here).

Amendments — 2026-09-11 (ADR-0011 structure registry replication)

• The ContainerId = "s" + structureInstanceId constraint is accepted by ADR-0011; StorageNet.StructureInstance is the join key to the registry row, bound lazily in either order (row before object or object before row). CarryFold applies StructurePlaced as −StructureDef.Cost for the placer and StructureDemolished as +100 % of the current cost for the demolisher, or nothing when RefundIsZero (relics). A client with a chest panel open closes it on the row's Remove event.

Editorial amendments — 2026-09-11 (TD-MANIFEST C2)

• §2 wrote CarryFold.Apply as a three-argument shorthand (bag, outcome, data) in 1 place(s) while Key Interfaces declares the five-argument form (confirmed, pending, outcome, self, data) — the only form that can consume a Pending entry, which §2's InventoryTransferred/CommandRejected rows require. Corrected in place to the five-argument form. No decision changed.

Amendments — 2026-09-13 (NetcodeSession story-006b — SpawnRequest union)

• SpawnRequest (Rules.Commands, readonly struct) gets the union shape this ADR owed: { SpawnKind Kind; ulong ClientId; PlayerKey Key; Vector2 Position; ContainerId Container; int EnemyArchetype } with enum SpawnKind : byte { Player, SharedStorage, Enemy } (append-only; fenced closed at exactly these three — Net_SpawnKindUnionIsClosed). Only SpawnRequest.Player(ulong, PlayerKey, Vector2) is constructed today; SharedStorage/Enemy are declared fields for this ADR's own StorageNet story and ADR-0012's enemy simulation story respectively, and PlayerSpawner.Spawn throws NotSupportedException naming the owning story if either is reached before then.
• SessionReadyCommand.Execute seeds CarrySync(player, rows: Array.Empty<CarryStackRow>(), equipment: Array.Empty<CarryStackRow>()) on every join — IInventoryTx exposes no row reader yet, so the sync ships genuinely empty until this ADR's CarryFold/ItemIndexTable story lands and can supply the real rows. Register item, not a defect: a joiner sees their bag populate on the FIRST bag-touching outcome after join, not at join time, until then.