Skip to content

Hostile Consumer Panels

This folder contains hostile-consumer teachable panels for the Crafting 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

Crafting exposes a supported runtime model in addition to abstractions.

Hostile consumer panels may use these documented runtime types:

CraftingServiceCore
RecipeCore
RecipeResolve
CraftJob
CraftJobSnapshot
CraftFailReason

These are part of the public runtime API, not internal implementation details.

Purpose of These Panels

Hostile-consumer panels serve two roles:

1️⃣ API Verification

They prove that the framework 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:

  • running preflight checks
  • enqueueing crafting jobs
  • observing job progress
  • reading service results
  • interacting with validators/modifiers
  • interacting with workbenches

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
  • temporarily modify service wiring
  • simulate optional runtime seams

are placed in the Demos folder instead.

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 Crafting 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 public API works.