Hostile Consumer Panels¶
This folder contains hostile-consumer teachable panels for the Inventory system.
These panels are intentionally written as if they lived in a completely separate Unity project consuming RevFramework from the outside.
They are used to verify that the public API surface is complete, stable, and usable without internal access.
What “Hostile Consumer” Means¶
Panels in this folder are restricted to using only:
- Public APIs
- Documented runtime types
- Supported extension seams
- Teaching UI utilities
They may not:
- reference
.Internalnamespaces - use reflection to access private state
- call undocumented
.Corehelpers - depend on sample/demo utilities
- modify runtime wiring with teaching-only helpers
If a panel requires any of those, the panel must not live in this folder.
Built-In Runtime Model¶
Inventory exposes a supported runtime model in addition to abstractions.
Hostile consumer panels may use these documented runtime types:
SceneInventoryService
InventoryResolve
CharacterInventory
CharacterEquipment
ItemDefinition
ItemStack
ContainerId
InventorySortSpec
InventorySortKey
InventorySnapshotOptions
MissingItemPolicy
InventorySnapshots
The save panel additionally uses the public save surface, which is owned by Runtime/Core and by the define-gated integration assembly rather than by Inventory:
IRevSaveParticipant
RevSaveCoordinator
RevSaveReport
StableId
StableIdOwners
InventorySaveParticipant
These are part of the public runtime API, not internal implementation details.
Panels must not access:
InventoryContainer
EquipmentContainer
ContainerInternal
EquipmentInternal
Those are internal implementation details used by the framework itself.
Panels in This Folder¶
Every Inventory teaching panel is a hostile consumer and lives here — there is no other subfolder. Each is the lead panel of the sample scene with the same number:
| Panel | Scene |
|---|---|
InventoryQuickstartPanel | 00_Quickstart_Minimal |
InventoryItemsAndStacksPanel | 01_Items_And_Stacks |
InventorySlotsAndRestrictionsPanel | 02_Slots_And_Restrictions |
InventorySearchAndSortPanel | 03_Search_And_Sort |
InventorySnapshotsPanel | 04_Snapshots |
InventorySavePanel | 05_Save |
Scenes 04 and 05 additionally carry an enabled InventoryQuickstartPanel, so items can be given and the container read without leaving the scene.
04_Snapshots and 05_Save are adjacent layers rather than alternatives. Snapshots is Inventory writing its own JSON for one inventory you bind; Save is the whole scene going into a save file alongside everything else, through the coordinator, with Inventory holding no privileged position in it.
Each panel demonstrates a specific area of the Inventory API while remaining fully compliant with the hostile-consumer rules.
Purpose of These Panels¶
Hostile-consumer panels serve two roles.
1. API Verification¶
They prove that the Inventory system can be used through its public surface only.
If a hostile-consumer panel breaks during refactoring, the public API has likely changed.
2. Teaching Real Usage¶
Unlike sample utilities, these panels demonstrate real production usage patterns, such as:
- giving items to containers
- reading inventory state
- equipping and unequipping items
- sorting inventory slots
- running service-backed search
- saving and restoring snapshots
Everything shown here uses the same public APIs developers use in production code.
Relationship to Other Teaching Panels¶
Not all teaching panels are hostile consumers.
Panels that:
- attach demo helpers
- simulate optional runtime seams
- modify service wiring for testing
belong in a sibling Demos/ folder instead — the arrangement several other systems use (Teaching/Crafting/Demos, Teaching/Currency/Demos, Teaching/Health/Demos, Teaching/StatusEffects/Demos).
Inventory has no Demos/ folder. No Inventory panel has needed one: every lesson here is reachable through the public API, which is the outcome this folder exists to prove. If one ever does, create the folder then rather than putting a non-hostile panel here.
Those panels exist to demonstrate behaviour, not to verify the public API surface.
Summary¶
Panels in this folder are API verification tools disguised as teaching panels.
They guarantee that:
- the Inventory public API is sufficient
- the runtime model is usable externally
- the framework can evolve internally without breaking consumers
If these panels compile and run, the Inventory public API works.