Skip to content

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 .Internal namespaces
  • use reflection to access private state
  • call undocumented .Core helpers
  • 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.