Add Ghost Shell strategic vision - control substrate concept, layer model, phased extraction plan

2026-04-07 21:55:29 +00:00 · 2026-04-07 21:55:29 +00:00 · 52948c408f
commit 52948c408f
parent 91106f6738
1 changed files with 145 additions and 0 deletions
--- a/GHOST_SHELL_VISION.md
+++ b/GHOST_SHELL_VISION.md
@ -0,0 +1,145 @@
+# 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.