📦 Crafting — Inventory Abstractions¶
This folder defines the inventory integration seam for the Crafting system.
Crafting does not depend on a concrete inventory implementation. Instead, all inventory interaction flows through these interfaces.
✅ Primary adapter¶
ICraftingInventoryAdapter¶
The required inventory adapter used for: - resolving containers - counting items - checking space - consuming inputs - adding outputs - deferring or batching inventory events (if supported)
Every Crafting setup must provide an implementation of this interface.
Implementations define what constitutes a valid container handle and how inventory semantics behave.
🧭 Inventory context¶
CraftingInventoryContext¶
A lightweight value wrapper combining: - an inventory adapter - an opaque container handle
This is the only supported way Crafting code interacts with containers. It intentionally hides adapter-specific handle types.
Contexts are considered valid only when both the adapter and handle are non-null. When invalid, mutation methods fail safely and count queries return zero.
Contexts are created by the Crafting service.
Consumers should not attempt to construct them directly.
🛡️ Strong / escrow crafting (optional)¶
Reservation interfaces¶
ICraftingInventoryReservationAdapterICraftingInputReservationICraftingOutputReservation
These interfaces enable strong crafting workflows by allowing: - inputs to be reserved - output capacity to be reserved - commits to be performed atomically by the adapter
Correctness guarantees (atomicity, idempotency) are provided by the adapter implementation. The Crafting service relies on these guarantees but cannot enforce them.
They are optional and only required for advanced escrow-style workflows.