Document renderless Aetheria architecture

Aetheria.State/docs/client-runtime-conformance.md

@@ -5,9 +5,17 @@ gameplay body without replacing it with a new privileged runtime.
 
 The daemon owns Aetheria game state, simulation, generated level content,
 assets, render-field declarations, Eve/CultUI surfaces, and typed operations.
-Client runtimes lower those surfaces and submit typed operations. A runtime may
-own presentation, input hardware, local caches, native buffers, and frame
-timing. It must not own gameplay truth merely because it can draw the game.
+Eve owns the game-agnostic surface language: layout, interaction, state
+pointers, render-field instructions, and 2D/3D scalar/vector field
+visualization contracts. Client runtimes lower those surfaces and submit typed
+operations. A runtime may own presentation, input hardware, local caches, native
+buffers, and frame timing. It must not own gameplay truth merely because it can
+draw the game.
+
+The desired end state is renderless Aetheria. Aetheria should not preserve a
+Unity, Godot, Electron, or browser side path for game behavior. If a runtime
+needs an Aetheria-specific rendering rule to show the game, that rule belongs in
+daemon-authored Eve/CultUI or in a game-agnostic Eve lowering primitive.
 
 ## Runtime Roles
 
@@ -39,6 +47,10 @@ assumptions, or Unity-only gameplay adapters.
 - No Godot port of Unity scene code as the ARPG authority.
 - No Electron-only field, asset, or command interpretation that Hermodr cannot
   consume through shared Eve/CultMesh primitives.
+- No Aetheria-specific Unity, Godot, Electron, or Hermodr renderer compensator
+  for 2D or 3D scalar/vector field visualization.
+- No daemon-published Eve surface that requires a named runtime to understand
+  Aetheria gameplay semantics.
 
 ## Acceptance Gates
 
@@ -51,6 +63,9 @@ assumptions, or Unity-only gameplay adapters.
 5. Unity consumes the ARPG contract as a renderer/input shell, with remaining
    shims listed for deletion.
 6. Godot lowers the ARPG contract without inheriting Unity authority.
+7. Eve lowerers can reconstruct the required 2D and 3D gameplay surfaces from
+   daemon-authored state pointers, field documents, asset refs, and operation
+   descriptors without Aetheria runtime branches.
 
 Until those gates pass, Aetheria is daemon-authoritative in pieces, not free of
 Unity as a complete client dependency.

Aetheria.State/docs/verse-authority-policy.md

@@ -106,58 +106,35 @@ entity.hostile.
 That leaves the door open to witness-authoritative MMO policy later while
 keeping the co-op hot path as a few string/prefix checks and set lookups.
 
-## Simulation Host Deployment Shapes
+## Simulation Host Packaging
 
-Aetheria should not require the C# daemon process to exist as a separately
-deployed executable. A Verse needs at least one runtime capable of advancing
-simulation, but that runtime can be packaged in different surfaces:
+Aetheria should not require the current C# daemon executable to be the only
+packaging shape forever. It does require the Aetheria simulation host role to be
+daemon-shaped: a runtime that owns the typed state graph, applies Verse policy,
+advances simulation, publishes high-performance views, serves assets, and emits
+Eve/CultUI surfaces.
 
-- `dedicated-daemon`: a standalone C# daemon owns simulation and publishes
-  daemon frames.
-- `electron-launched-daemon`: Electron deploys/launches the same daemon and the
-  browser surface talks to the local CultMesh node.
-- `unity-host`: one Unity player runs the Aetheria simulation host in-process
-  or as an embedded sidecar and advertises itself as the host runtime for the
-  Verse.
-- `browser-wasm-host`: a browser runtime runs a WebAssembly simulation kernel
-  and advertises itself as the simulation host for a Verse.
-- `native-kernel-host`: a native Rust/CultLib runtime runs the same simulation
-  kernel outside Unity and outside the current C# daemon executable.
-- `distributed-trusted`: trusted Unity/RTS runtimes author claim subsets
-  directly according to policy; each still submits typed facts through the same
-  authority gate.
-- `observer-only`: browser/Eve/RTS clients render and submit typed commands but
-  do not advance simulation.
+A standalone process, embedded native host, or future WASM/native kernel can
+package that role. Those are deployment choices, not gameplay authority modes.
+Unity, Godot, Electron, Hermodr, and browser shells are render/input lowerers
+unless they are explicitly running the daemon-shaped simulation host behind the
+same typed CultMesh boundary. A renderer does not gain authority because it
+spawned, embedded, or happens to sit beside the host.
 
 The important boundary is not the executable. It is the policy document:
 
 ```text
-browser CultMesh client
+runtime CultMesh client
   -> typed command/proposal document
   -> Verse authority policy
   -> simulation-capable runtime lease/host
   -> committed facts and local projections
 ```
 
-If no dedicated daemon is deployed, a Unity player may become the simulation
-host by advertising a stable runtime id and by using `host-authoritative` or
-delegated rules that name that Unity runtime. Browser-only clients remain thin:
-they can control and observe the Verse through CultMesh, but they do not become
-authoritative unless a TS/WASM simulation runtime is explicitly added and named
-by policy.
-
-The first co-op fallback should be:
-
-```text
-simulation host: raven-unity
-default mode: host-authoritative
-
-*
-  *
-  host-authoritative
-```
-
-Then Starbridge can refine hot claims without changing client protocols:
+If no standalone daemon process is deployed, an embedded host may still run the
+same daemon-shaped simulation role and publish the same typed documents. The
+client shell around it remains a renderer/input surface. Starbridge can refine
+hot claims without changing client protocols:
 
 ```text
 entity.player.raven
@@ -170,20 +147,19 @@ entity.hostile.
 
 *
   inventory,economy,system
-  host-authoritative: raven-unity
+  host-authoritative
 ```
 
-This keeps the browser client honest: it can run CultMesh and submit typed
-commands, but someone with the Aetheria simulation assembly must own the
-simulation work.
+This keeps every client honest: it can run CultMesh and submit typed commands,
+but the daemon-shaped simulation host owns the committed game state.
 
 ## Current Local-Mirror Constraint
 
 The current C# implementation is not a pure remote-client architecture yet.
 Unity can select a remote CultMesh Verse, but gameplay boot still requires that
 Verse to be hydrated into a readable local CultCache replica before the Unity
-shell starts. The Electron RTS client likewise launches a local daemon and reads
-local daemon publications while using CultMesh for typed command submission.
+shell starts. The Electron Starbridge client likewise uses local daemon
+publications while using CultMesh for typed command submission.
 
 That constraint is acceptable as a migration bridge, but it must not become the
 architecture. The end state is:
@@ -215,9 +191,9 @@ The staged migration is:
    simulation decision behind that contract.
 3. Port the deterministic simulation kernel to Rust with matching schema
    bindings and fixture-based parity tests against the C# host.
-4. Compile the Rust kernel to native and WASM. Native hosts cover dedicated
-   daemon, Electron-launched daemon, and Unity sidecar deployment. WASM covers
-   browser simulation host deployment.
+4. Compile the Rust kernel to native and WASM. Native and WASM hosts package
+   the same daemon-shaped simulation role behind the same typed CultMesh
+   contract.
 5. Replace local-file-only readers with CultMesh subscriptions plus optional
    local cache hydration, so remote Verse access does not require a C# process
    on the same machine.

README.md

@@ -1,7 +1,13 @@
 # Aetheria
 Aetheria is an ambitious (AA quality) open source tactical action role-playing game with a sprawling sci-fi setting that combines stunning visuals with unprecedented simulation depth while maintaining accessibility.
 
-All mechanics are developed to be engine-agnostic, while Unity was chosen as a renderer and editor environment for its accessibility and extensibility. Many custom features have been developed, such as a database frontend with configurable backing store for managing game content, a novel visual input rebinding system, and a volumetric cloud renderer with groundbreaking fidelity, any of which can easily add value to other open source gamedev projects. We'd love to see other teams building on our foundation to deliver their own vision and contribute to the ecosystem we're creating.
+Aetheria is being rebuilt as a renderless daemon-owned game. The daemon owns
+rules, simulation state, level generation, assets, operations, and the
+high-performance view documents clients need to render the world. Eve/CultUI
+owns the portable surface and field-description contract. Unity, Godot,
+Electron, Hermodr, and later runtimes should be game-agnostic Eve lowerers:
+they render, capture input, cache native views, and submit typed operations
+without becoming gameplay authorities.
 
 It is our ambition to forge a new paradigm of open source game development, as to our knowledge there are no other open source projects of this scope building up a foundation from scratch. Game development is notoriously averse to this model and nobody wants to share their shiny toys for fear of losing their competitive advantage. By building and sharing immersive and compelling experiences like this, we hope to change that.
 
@@ -58,20 +64,31 @@ As a result of lessons learned, we then focused on the economy system, and built
 
 ## Current Work
 
-At the moment we are focused on implementing and polishing the ARPG gameplay as a standalone title, first as a rogue-lite combat demo and then adding a story-driven campaign mode.
+At the moment we are focused on moving Aetheria gameplay authority into the
+daemon and proving that both RTS and ARPG clients can be reconstructed from
+daemon-published typed state, CultMesh CDN assets, and Eve/CultUI surfaces.
+Starbridge is the first product pressure test for this model.
 
 ## Developer Navigation
 
 The repo is currently in a major typed-state migration. Before making runtime
 changes, read [docs/developer-navigation.md](docs/developer-navigation.md) for
-the current project map, command list, migration rules, and where the new
-Unity/daemon/Electron boundaries live.
+the current project map, command list, migration rules, and where the daemon,
+Eve, and runtime-lowering boundaries live. The target renderless architecture
+is mapped in
+[docs/renderless-aetheria-architecture.md](docs/renderless-aetheria-architecture.md).
 
 ## Architecture
 
 ### Project Structure
 
-There are two solutions in this repository. One is a Unity project containing the desktop client for Aetheria, and the other is a .NET Core application intended to run on Linux cloud servers. The bulk of the game's code is shared between them, located at [Assets/Scripts/ServerShared](Assets/Scripts/ServerShared), defining a common protocol, world simulation code and data serialization format.
+The current repository still contains Unity-era source, an Electron Starbridge
+client, shared runtime packages, and the C# Aetheria daemon. The target shape is
+not "two clients sharing a game library." The target shape is one daemon-owned
+game publishing typed CultMesh state, render fields, assets, operations, and
+Eve/CultUI surfaces. Runtime code is a lowering boundary: Unity and Godot lower
+ARPG surfaces, Electron and Hermodr lower RTS surfaces, and all of them consume
+the same game-agnostic Eve/runtime primitives.
 
 ### Third Party Libraries
 

docs/renderless-aetheria-architecture.md

@@ -0,0 +1,216 @@
+# Renderless Aetheria Architecture
+
+Date: 2026-07-06
+
+This document records the intended architecture before the next demolition pass.
+It is not an implementation claim. It is the map the implementation must be
+measured against.
+
+## Objective
+
+Aetheria should become a renderless daemon-owned game.
+
+The Aetheria daemon owns game state, simulation rules, generated content,
+game-feel settings, authority policy, typed operations, assets, and
+high-performance views of live state. Eve owns the portable UI and rendering
+instruction contract. Unity, Godot, Electron, Hermodr, and later runtimes lower
+Eve surfaces and submit typed operations; they do not own Aetheria gameplay
+truth.
+
+Hermodr is the RTS sanity check: an unspecialized Eve/browser client must be
+able to reconstruct the same RTS gameplay surface as Electron from the Eve spec,
+daemon API, state pointers, render-field documents, operation descriptors, and
+CultMesh CDN asset references.
+
+Godot is the corresponding ARPG sanity check: an unspecialized non-Unity client
+must be able to reconstruct the 3D action-game surface from the same kind of
+daemon-authored contract, without inheriting Unity scene authority.
+
+## Authority Map
+
+Owner:
+Aetheria daemon owns committed game state and rules.
+
+Inputs:
+The daemon may read typed CultCache/CultMesh documents, catalog data, authority
+policy, player/client operation documents, simulation clock input, deterministic
+generation seeds, asset manifests, and physics-service results.
+
+Outputs:
+The daemon publishes typed state documents, committed facts, operation receipts,
+simulation frames, SoA/native view descriptors, scalar and vector field
+documents, render splats, entity/object render rows, asset manifests, CultMesh
+CDN asset blobs, and Eve/CultUI surfaces.
+
+Derived state:
+Unity GameObjects, Electron canvases, Hermodr browser nodes, Godot scene nodes,
+local native buffers, local caches, and local input state are derived
+presentation/runtime state. They may improve performance or UX. They do not
+decide committed Aetheria truth.
+
+Forbidden writers:
+Renderer-local gameplay compensators, Unity scene lifetime, Unity collision
+callbacks, Electron-only map builders, Hermodr Aetheria plugins, Godot-specific
+daemon branches, local file sidecars, renderer-owned asset fallbacks, and
+client-specific command routers must not write or define canonical gameplay
+state.
+
+Shared paths:
+Unity, Godot, Electron, Hermodr, tests, tools, and future clients should all
+consume the same daemon-published documents and Eve surfaces. Direct user input,
+programmatic commands, replay/import, reconnect, and automation should all enter
+through typed operations or policy-governed typed document writes.
+
+Deletion line:
+Before adding new client behavior, delete or demote any path that lets a client
+invent gameplay state, reconstruct daemon-owned documents from broader frames,
+or patch missing Eve semantics with Aetheria-specific renderer code.
+
+## Current Mechanism
+
+The repo is mid-migration.
+
+The C# daemon currently publishes typed runtime state, command boundaries, Eve
+surfaces, Starbridge documents, viewport documents, asset manifests, and
+CultMesh-facing transport hooks. Electron has been moved toward consuming
+daemon-authored Eve surfaces and managed documents instead of rebuilding them
+from a daemon frame. Unity has been moved toward observing daemon frames and
+submitting typed operations instead of ticking local simulation, but it still
+contains Unity-era presentation, object restoration, input, camera, UI, weapon,
+and gameplay-adapter code.
+
+This means Aetheria is not yet fully renderless. The desired ownership is clear,
+but the repo still contains migration bridges and Unity-shaped presentation
+state that must be audited before they can be deleted or demoted.
+
+## Invariants
+
+- Aetheria gameplay truth lives in daemon-owned typed state, not renderer state.
+- Eve surfaces contain the UI and render instructions required by clients.
+- Dynamic contents are state pointers or managed document references, not copied
+  live state embedded into the surface document.
+- CultMesh CDN serves assets advertised by the daemon.
+- Renderer-local code may lower, cache, batch, interpolate, and display. It may
+  not invent gameplay semantics.
+- Game-feel settings belong to daemon config or typed state, not client-local
+  constants.
+- Runtime-specific names may describe packaging or product shells, but not
+  gameplay authority branches.
+- Hermodr and Electron must render the same RTS surface from the same Eve
+  contract.
+- Godot and Unity must render the same ARPG surface from the same Eve contract.
+
+## Eve Surface Contract
+
+An Aetheria Eve surface should be rich enough to describe both the 2D RTS view
+and the 3D ARPG view.
+
+The surface should be able to declare:
+
+- layout, rows, columns, grids, modal placement, fields, and command bindings;
+- state pointers to daemon-owned typed documents;
+- operation descriptors with typed payload schemas and route hints;
+- 2D scalar fields, such as gravity heightmaps;
+- 2D vector/color fields, such as nebula tint or fog/tint splats;
+- 3D vector fields, such as flow fields derived from volumetric simulation;
+- field visualizers, such as isolines, shaded height, probes, volume slices, or
+  particle/flow overlays;
+- render splat buffers and accumulation rules;
+- entity/object render rows with asset refs, transforms, labels, and selection
+  metadata;
+- asset refs resolved through CultMesh CDN.
+
+The Eve package should own the game-agnostic lowering primitives for these
+contracts. Aetheria may define game documents and author surfaces, but it should
+not require Electron, Hermodr, Unity, or Godot to carry private Aetheria
+rendering knowledge.
+
+## Field Documents
+
+Gravity is a 2D scalar field for the RTS view. It should be produced from
+daemon-owned simulation/generation state and exposed as a high-performance view
+or field document. Isolines are one visualization of that scalar field, not the
+field itself.
+
+Nebula tint is a 2D vector/color field. Tint splats are color times the
+appropriate Aetheria brush/window function accumulated into a color buffer.
+Those rules belong in daemon-authored render-field declarations or
+game-agnostic Eve field primitives, not in renderer-local compensation code.
+
+The ARPG surface also needs 3D fields. Flow from the volumetric shader family is
+a 3D vector field. A 2D renderer does not need the full 3D flow field, but the
+contract should not be designed as if all Aetheria views are flat maps.
+
+## Asset Contract
+
+The daemon advertises assets through typed asset manifests and CultMesh CDN
+refs. Clients resolve those refs through their runtime asset bridge.
+
+Clients should not synthesize icon paths, substitute improvised SVGs, or embed
+fallback asset lore when the daemon fails to advertise an asset. A missing asset
+should be visible as missing provider data, not silently repaired by the
+renderer.
+
+## Runtime Roles
+
+Hermodr:
+Generic Eve/browser lowering witness for the RTS surface. It proves the
+contract is not Electron-specific.
+
+Electron:
+Player-facing Starbridge RTS shell. It may own packaging, windowing, app
+lifecycle, local daemon launch ergonomics, and platform bridges. It should not
+own Aetheria gameplay semantics.
+
+Unity:
+Current ARPG reference client and migration source. It may own engine
+presentation, input capture, camera, GameObject restoration, and temporary
+adapters. It should not remain the owner of rules, state, level generation,
+physics truth, or UI semantics.
+
+Godot:
+Future ARPG conformance runtime. It should prove the ARPG client can be rebuilt
+from the daemon and Eve contract rather than ported from Unity scene authority.
+
+Eve:
+Game-agnostic surface and lowering contract. Eve owns reusable primitives for
+state binding, operation invocation, modal placement, field visualization,
+asset refs, and runtime-neutral UI/render semantics.
+
+Aetheria:
+Game daemon, documents, rules, authored surfaces, assets, generation,
+simulation, and authority policy.
+
+## Migration Gates
+
+1. Daemon publishes the RTS surface as Eve/CultUI plus state pointers, field
+   documents, typed operations, and CultMesh CDN assets.
+2. Hermodr lowers that RTS surface with no Aetheria-specific renderer plugin.
+3. Electron renders the same RTS surface through shared Eve primitives.
+4. Daemon publishes equivalent ARPG surfaces and 3D render contracts.
+5. Unity consumes the ARPG contract as a renderer/input shell, with remaining
+   shims named and bounded.
+6. Godot lowers the ARPG contract without Unity scene authority.
+7. Unity-only simulation, generation, physics, UI semantics, and asset fallback
+   paths are deleted or demoted to renderer presentation.
+
+## Verification Strategy
+
+Documentation comes first. Verifier pressure should be added only after this
+map is accepted.
+
+When enforcement starts, the verifier should prove:
+
+- active docs describe renderless Aetheria and game-agnostic Eve lowerers;
+- daemon code owns simulation, generation, operation acceptance, assets, and
+  high-performance view publication;
+- Electron does not rebuild daemon-owned documents from frames;
+- Hermodr has no Aetheria-specific rendering branch;
+- Unity gameplay code does not tick local simulation or write canonical state;
+- Godot work does not introduce a daemon-side Godot mode;
+- asset refs come from daemon manifests and CultMesh CDN;
+- field visualization settings come from Eve/daemon documents, not renderer
+  constants.
+
+The goal is not to outlaw useful runtime code. The goal is to make ownership
+legible: renderers render, the daemon decides, Eve carries the contract.