🔗 Integrations — System Bridges & Adapters¶

This folder contains optional integration layers between RevFramework systems.

These are not part of the core runtime.

They exist purely to connect systems together in a modular, opt-in way.

🧠 What This Folder Is¶

Each subfolder represents a bridge between two (or more) systems, for example:

Crafting → Inventory
Crafting → Currency
Inventory → Pickups
Pickups → Health
StatusEffects → Health

These integrations:

Live outside runtime to keep systems clean and independent
Compile only when required systems are present (via REV_* defines)
Fail safely when dependencies are missing
Use adapters, bridges, and optional Unity-facing components

⚠️ What This Folder Is NOT¶

Let’s be crystal clear:

❌ Not a core dependency layer
❌ Not required for any system to function
❌ Not a general “third-party integration SDK”

This is internal system wiring for RevFramework systems.

🧩 Intended Usage¶

These integrations are designed to:

Connect RevFramework systems together without tight coupling
Provide ready-to-use bridges so you don’t have to write glue code
Demonstrate correct integration patterns (adapters, context passing, safe failure)

Depending on the SKU(s) installed:

👉 You will only see integrations relevant to the systems you have

🌍 Third-Party / Custom System Use¶

These integrations are built and supported for RevFramework systems only.

Some patterns may be useful when integrating with external or custom systems, but those setups are not supported by this integration layer.

If you are connecting RevFramework to non-RevFramework systems:

Treat these integrations as reference examples only
Write your own adapter or bridge for your project
Use the public APIs exposed by each RevFramework system

👉 RevFramework supports its own integration contracts — not every possible third-party setup.

🧱 Design Principles¶

All integrations in this folder follow strict rules:

Optional by design
Remove any integration folder → nothing breaks
Define-gated
Compiled only when required systems exist
Safe failure
Missing services = no crashes, just no-ops or failed ops
No hidden coupling
All cross-system behaviour is explicit and visible here
Adapter-first approach
Systems talk through interfaces, not concrete types

📂 Example Structure¶

Integrations/
  Crafting/
    CurrencyIntegration/
    InventoryIntegration/

  Inventory/
    PickupsIntegration/
    CurrencyIntegration/

  Pickups/
    HealthIntegration/
    InventoryIntegration/
    CurrencyIntegration/

  StatusEffects/
    HealthIntegration/
    PickupsIntegration/

🧠 Mental Model¶

Think of this folder as:

“The glue layer between otherwise completely independent systems.”

Each system works perfectly fine on its own.

These integrations simply allow them to cooperate when installed together.

🧹 Safe to Remove?¶

Yes.

If you delete:

An entire integration folder
Or even the whole Integrations directory

👉 The framework will still function
👉 You just lose cross-system behaviour

💬 Final Note¶

This separation is intentional.

Runtime stays clean, minimal, and independent.
Integrations stay explicit, optional, and replaceable.

No hidden magic. No surprise dependencies.

🔥 Rab’s blunt take¶

This was a solid architectural correction.

Before:

“Why is Crafting randomly aware of Inventory?”

Now:

“Ah — it’s not. There’s a bridge. I can delete it.”

That’s the difference between:

a tool
and a proper framework