# Ghost Shell — Strategic Vision

**Status**: Concept phase. Do not build yet. ZLH must stabilize first.  
**Last Updated**: April 7, 2026

---

## The Core Insight

ZeroLagHub is not a game host.  
It is a **control substrate over Proxmox**.  
Gaming is the first application layer.

Strip away Minecraft and dev container presets. What remains is:

- VMID allocator
- LXC provisioning logic
- Bridge assignment model
- API-driven lifecycle management
- Agent-based execution abstraction
- PTY console streaming
- Metrics aggregation
- Versioned agent updates
- Tenant isolation enforcement
- Auth + RBAC
- Billing integration

That is not gaming infrastructure. That is an **orchestration framework**.

---

## The Layer Model

```
Layer 0 — Infrastructure
  Proxmox, Storage, Networking, Bridges, VMID ranges

Layer 1 — Control Plane (Ghost Shell Core)
  API, Auth, Provisioning logic, Agent lifecycle,
  Metrics aggregation, Isolation enforcement

Layer 2 — Execution Substrate
  LXC containers, Agent runtime

Layer 3 — Application Layer (Pluggable)
  Minecraft
  Dev environments
  Future workloads
```

Gaming lives in Layer 3.  
Everything below it is generic.  
**Ghost Shell is Layers 0–2.**

---

## What Ghost Shell Is

A branded-neutral, multi-tenant, API-first LXC control plane with agent-based execution.

More precisely: **infrastructure middleware**.

Closer to a lightweight Render, Railway, or Fly.io — but:
- Self-hosted
- On bare metal
- Your cost structure
- Proxmox-native

---

## The Strategic Separation

**ZeroLagHub** = Product built on Ghost Shell (gaming application layer)  
**Ghost Shell** = The core platform  
**Red Castle / other ventures** = Different products built on the same governance model

This means you are not building two companies.  
You are building **one core capability** with multiple market applications:

> Governed edge execution over deterministic container environments.

That is the niche. Not gaming. Not hosting. Not PLCs.  
**Control plane engineering.**

---

## Critical Constraints (Must Preserve Now)

For Ghost Shell to remain viable, these rules apply to ZLH development today:

1. **Keep game logic out of core provisioning code** — Minecraft is a workload definition, not a foundation
2. **Keep the agent generic** — it runs any workload, not just game servers
3. **Keep template definitions abstract** — game types are plugins, not hardcoded paths
4. **Treat application layer as pluggable** — Layer 3 must be swappable

If Minecraft becomes embedded in lifecycle logic, Ghost Shell dies.  
If Minecraft is a plug-in workload definition, Ghost Shell lives.

These constraints should be checked in every architectural review.

---

## Phased Extraction Plan

```
Phase 1 — ZLH as application layer (NOW)
  Build ZLH on top of what will become Ghost Shell.
  Do not abstract yet.

Phase 2 — Stabilize core (NEXT)
  ZLH reaches: stable, operational, minimal rewrite pressure.
  Revenue generating.

Phase 3 — Extract core into Ghost Shell
  Clean separation of Layer 1-2 from Layer 3.
  Ghost Shell becomes a named, standalone codebase.

Phase 4 — ZLH becomes one implementation of Ghost Shell
  Other products can be built on the same substrate.
```

**The wrong move is abstracting too early — it will stall ZLH.**

---

## Open Strategic Question

The answer to this determines architecture decisions being made now:

**How do you intend to use Ghost Shell?**

- A) Selling it as a Proxmox SaaS control panel competitor
- B) Selling it to MSPs
- C) Using it internally across multiple ventures (Red Castle, etc.)
- D) Open-core with monetized extensions

This question is deliberately left open. The answer should be committed here when decided, because early architectural decisions will lock or unlock each option.

---

## Connection to Owner Background

This architecture emerged naturally from controls engineering thinking applied to cloud infrastructure. The layer model above is structurally identical to how industrial control systems are organized (field devices → controllers → supervisory → operator interface). That is not accidental — it is trained instinct applied to a new domain.

See `OWNER_PROFILE.md` for full context.