diff --git a/Aetheria.State/docs/client-runtime-conformance.md b/Aetheria.State/docs/client-runtime-conformance.md index f0ec98bc5..2842a4c82 100644 --- a/Aetheria.State/docs/client-runtime-conformance.md +++ b/Aetheria.State/docs/client-runtime-conformance.md @@ -23,7 +23,7 @@ daemon-authored Eve/CultUI or in a game-agnostic Eve lowering primitive. | --- | --- | --- | | Hermodr | Unspecialized Eve/browser lowering sanity check for the RTS surface. | It reconstructs the Aetheria RTS gameplay surface from daemon-advertised Eve surfaces, typed state pointers, typed operations, render-field declarations, and CultMesh CDN assets without Aetheria-specific renderer code. | | Electron | Player-facing Starbridge RTS client. | It renders the same daemon-authored RTS surface through the shared Eve package, with only app shell, launch, packaging, and runtime ergonomics outside Eve. | -| Unity | Current ARPG reference client and demolition target. | It behaves as a renderer/input shell over daemon state and Eve/CultUI/world-state surfaces; remaining GameObject, UI Toolkit, camera, input, and presentation adapters are classified shims or renderer-owned concerns. | +| Unity | Shared pilot reference client for Terminus, Starbridge, and Arena; also a demolition target. | It behaves as a renderer/input shell over daemon state and Eve/CultUI/world-state surfaces; remaining GameObject, UI Toolkit, camera, input, and presentation adapters are classified shims or renderer-owned concerns. It owns no Hangar, loadout, progression, or mode-session truth. | | Godot | Future unspecialized Eve/runtime parity target for the ARPG surface. | It reconstructs the ARPG gameplay surface from daemon API plus Eve/CultUI/render-field specs and CultMesh CDN assets, not from a Unity port or daemon-side Godot mode. | Hermodr is the purity test for the RTS surface. Electron is the shipped RTS diff --git a/Aetheria.State/docs/stage-7-thin-client-staged-implementation-plan.md b/Aetheria.State/docs/stage-7-thin-client-staged-implementation-plan.md index 587cee1a0..40a97778f 100644 --- a/Aetheria.State/docs/stage-7-thin-client-staged-implementation-plan.md +++ b/Aetheria.State/docs/stage-7-thin-client-staged-implementation-plan.md @@ -81,7 +81,7 @@ UI input The map viewport is just one projection. Selected object state, inventory, cargo, authority status, and peer health must follow the same pattern. -Starbridge is the current design pressure for this shape. One RTS commander and +Starbridge is the current Stage 7 mixed-authority pressure for this shape. One RTS commander and one to four Unity pilots must share the same Verse facts while each runtime authors only the typed claims it should own. diff --git a/Aetheria.State/docs/verse-authority-implementation-plan.md b/Aetheria.State/docs/verse-authority-implementation-plan.md index 81368ee20..4debab845 100644 --- a/Aetheria.State/docs/verse-authority-implementation-plan.md +++ b/Aetheria.State/docs/verse-authority-implementation-plan.md @@ -18,8 +18,12 @@ Raven and Starfire each run a local CultMesh/CultNet Verse node. - Future authority modes remain representable without forcing the first trusted co-op implementation to carry consensus machinery. -The immediate product target is Starbridge: one RTS chair and one to four pilot -clients defending the same base through shared Verse state. The RTS runtime +The first product spine contains Terminus single-player, Starbridge co-op, and +Arena PvP/simulation. All three must remain minimally executable while their +shared Hangar, deployment, loadout, and settlement organs are built. + +Starbridge is mixed-authority: one RTS chair and one to four pilot clients +defend the same base through shared Verse state. The RTS runtime naturally authors base, wave, hostile, infrastructure, fabrication, drone/turret, station-stock, construction-ghost, target-mark, and commander support claims. Pilot runtimes naturally author their own movement, local @@ -34,6 +38,15 @@ Starbridge into a generic RTS-client migration. Starbridge is the proof that Verse authority, typed state, station stock, equipment, heat, repair, salvage, construction, waves, and recovery are all one shared war machine. +Arena is server-authoritative. Its dedicated server owns admission, simulation, +rules, scoring, and outcomes. Human and AI controllers submit the same typed +operations and consume the same observations; accelerated or headless Arena +runs must not bypass the production command gate. Arena is the primary harness +for NPC-policy training and build-versus-build balance batches. Terminus uses +sole local-daemon authority for the same shared pilot mechanics. All three modes +must run headlessly; renderer attachment cannot become an authority input. The +cross-mode contract is defined in `docs/game-modes-and-progression.md`. + ## Hard Rules 1. No public stringly command APIs. @@ -1016,9 +1029,10 @@ strict than the architecture notes above it. Every stage has one product proof, one authority proof, and one demolition target. If a stage cannot name all three, it is not ready to build. -Design source: +Design sources: - `E:/Projects/AetheriaLore/Aetheria/Game Design/Aetheria Starbridge.md` +- `docs/game-modes-and-progression.md` Starbridge release spine: @@ -1751,24 +1765,33 @@ Unlocks: - future witness/quorum authority modes. -### Slice S8: Episode And Progression Documents +### Slice S8: Shared Hangar And Progression Documents -Stage: after first playable Starbridge loop. +Stage: the minimal Hangar/deployment/settlement boundary precedes all three +first-wave slices; progression depth follows the first playable Starbridge loop. Build: -- scenario completion, run score, persistent score currency, unlocks, and - shallow meta-progression documents; +- one canonical Hangar, deployment, loadout-template, settlement, progression, + and unlock document family shared by Terminus, Starbridge, and Arena; +- scenario completion, run score, persistent score currency, and + mode-provenance facts; - recovered technology pools tied to scenario/faction definitions. Demolition target: -- client-local unlock or score state. +- client-local or mode-private hangar, inventory, loadout, unlock, or score + state. Verifier: +- Terminus settlement, Starbridge completion, and Arena admission/outcome use + the same typed Hangar keys and operations; - completing a scenario writes typed progression facts that another runtime can - inspect without Unity. + inspect without Unity; +- Arena controllers cannot write score or progression directly, and Starbridge + authority policy changes claim ownership without changing the progression + schema. Progress: diff --git a/README.md b/README.md index 52f87b43d..22966aaf8 100644 --- a/README.md +++ b/README.md @@ -54,7 +54,12 @@ If you want to chat, please join [our Discord server](https://discord.gg/trbteNj The ARPG game design document is available [here](https://docs.google.com/document/d/1iULu1WsbuQoUM3c87XkGseb1P-8R5xlruoiyg03TsSE/edit?usp=sharing), while the RTS gameplay is documented [here](https://docs.google.com/document/d/1U3uGFqQboAiFJ_Y-nUOGpyixbXUHRbc5DiCuB59GM4w/edit?usp=sharing). There's also a document explaining how some of the shaders work [here](https://docs.google.com/document/d/1AFycvCtW6hA1jkKq1ZmYd3k6_uEWaaCqcZ4fYj4vU6A/edit?usp=sharing). -The eventual goal is to essentially create two games which both take place in the same persistent universe, allowing players with vastly different preferences to struggle together for the survival of mankind. Each instance of the game lasts until the inevitable destruction of the entire population at the hands of aliens, after which the universe resets. Each loop is designed to last up to a couple of months, during which the hostility of the aliens steadily increases until the players are unable to hold back the tide. As players gain proficiency with the systems, the length of the time loop may increase, allowing us to organically inject new content into the timeline. +The game has three modes over one simulation and progression spine: Terminus +single-player roguelike runs, mixed-authority Starbridge co-op, and +server-authoritative Arena PvP. Arena also provides deterministic headless +matches for NPC-policy training and build balancing. All modes share ships, +equipment, fitting rules, and Hangar progression without sharing live session +authority. ## Previous Work @@ -67,7 +72,12 @@ As a result of lessons learned, we then focused on the economy system, and built 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. +Terminus is the single-player roguelike mode, Starbridge is the mixed-authority +co-op RTS/pilot mode, and Arena is the server-authoritative PvP mode and primary +AI-training/build-balancing harness. All three can run headlessly, use the same +Hangar, ship-loadout, and progression model, and must remain minimally runnable from the first product +spine. The shared mode design is documented in +[docs/game-modes-and-progression.md](docs/game-modes-and-progression.md). ## Developer Navigation diff --git a/docs/aetheria-perfect-machine-map.md b/docs/aetheria-perfect-machine-map.md index 58c3bd5f7..654c70f7c 100644 --- a/docs/aetheria-perfect-machine-map.md +++ b/docs/aetheria-perfect-machine-map.md @@ -12,8 +12,11 @@ authority. Aetheria should persist and replicate game state as typed CultCache documents, publish multiplayer/service state through CultMesh, and render operator/runtime -interfaces from Eve CultUI surfaces. The old JSON, RethinkDB, JsonKnownTypes, -legacy catalog cache, and legacy UI paths should be migration-only or deleted. +interfaces from Eve CultUI surfaces. Terminus uses local-daemon authority, +Starbridge uses typed mixed authority, and Arena uses server authority; all +three share the target Hangar/deployment/settlement spine and can execute +headlessly. The old JSON, RethinkDB, JsonKnownTypes, legacy catalog cache, and +legacy UI paths should be migration-only or deleted. ## Current Mechanism @@ -1142,22 +1145,23 @@ lifecycle state. EveUnity resolves `effect.feedback.entity.destroyed` only after the provider has published authoritative destruction chronology. -### Daemon Terminus Scenario Ownership +### Daemon Terminus Mode And Witness Ownership -The generated Terminus world and deterministic released-client proofs are -separate daemon-owned scenarios. `standard` preserves the generated ship -loadouts. `released-client-proof` alone creates the one-hit raider and guaranteed +Terminus is the daemon-owned single-player roguelike product mode. `standard` +preserves generated ship loadouts and must be launchable through normal typed +mode selection. `released-client-proof` alone creates the one-hit raider and guaranteed salvage transaction; `cargo-capacity-rejection-proof` additionally fills every generated player cargo bay from typed catalog volume and bay capacity. The -scenario selects a distinct run identity, so an existing proof run cannot -impersonate ordinary play. Unity selects the scenario only as a launch input and -cannot write cargo, hull, pickups, or feedback. +proof profiles select distinct run identities, so a proof run cannot impersonate +ordinary play or settle durable Hangar progression. Unity selects the mode or +profile only as a typed launch input and cannot write cargo, hull, pickups, +feedback, Hangar, deployment, or settlement state. -Scenario generation may select an active run and default pilot name, but it is -not tutorial progression authority. It preserves `TutorialPassed`; only a -future daemon-owned tutorial completion transaction may cross that flag. The -fossil selected tutorial New Game while the flag was false, so merely entering -the Terminus proof arena cannot award completion. +Terminus run generation owns run-local world and encounter state, not shared +progression. A committed Hangar deployment instantiates the live ship/loadout; +an exactly-once settlement is the only path for permitted rewards or losses to +cross back into the Hangar. Witness profiles are structurally barred from that +settlement path. ### Daemon Terminus Clock And Attention Ownership @@ -1202,9 +1206,9 @@ the Terminus proof arena cannot award completion. - Shared paths: generation and parity smoke use the same CultMath random stream, Unity-compatible simplex semantics, weighted sample elimination, Delaunay graph, connectivity-preserving link pruning, and faction placement owner. -- Cut line: a generated Terminus proof arena cannot be relabelled as the - tutorial. New Game selects the daemon-persisted tutorial while completion is - false; Terminus remains a witness fixture. +- Cut line: tutorial topology is an onboarding run recipe, not a progression + owner or separate mode inventory. It may constrain a Terminus deployment but + cannot write Hangar state except through the shared settlement transaction. - Verification layer: smoke generates the authored 64-zone graph twice from one seed, proves point/adjacency repeatability, a connected undirected graph, six distinct role homes, an unowned entrance, and discovery containing exactly @@ -1217,11 +1221,12 @@ the Terminus proof arena cannot award completion. - Owner: the daemon tutorial materializer owns station, turret, faction-ship, starter-ship, orbit, and run persistence decisions. - Inputs: the immutable tutorial topology, each celestial plan and its exact - post-body CultMath state, typed faction/catalog data, player settings, and the - accepted New Game command. + post-body CultMath state, typed faction/catalog data, an authenticated Hangar + snapshot, a committed Terminus Deployment, and accepted typed Terminus + mode-selection/admission. - Outputs: 64 canonical zone documents, stable entity records, loadout generation receipts, one controlled entrance ship, tutorial discovery state, - and an Aetheria-mode game session. + and a Terminus session. - Agent work: each generated NPC ship receives one assigned `patrol` task with the fossil four-orbit shuffled circuit. Orbit circuits are typed separately from mining/survey body targets and survive bootstrap into the runtime @@ -1242,12 +1247,14 @@ the Terminus proof arena cannot award completion. - Derived state: wormhole exits derive from adjacency; generic Eve maps, cameras, scene objects, fog, and HUD state lower the persisted run. - Forbidden writers: Unity generators, menu callbacks, scene materializers, and - Terminus scenarios cannot create or select gameplay entities for this run. -- Shared paths: fresh daemon boot and accepted New Game use the same tutorial - run writer; the Unity product shell submits the Eve command and waits for a + Terminus witness profiles cannot create or select product gameplay entities + outside accepted deployment/admission. +- Shared paths: accepted Terminus deployment/admission and verification use the + same tutorial run writer; ready daemon boot creates no gameplay state. The + Unity product shell submits typed mode/deployment operations and waits for a newer tutorial sector-map publication before entering the scene. -- Cut line: New Game reloading the previous frame without sending its advertised - operation is dead. Celestial-only tutorial graphs are not playable runs. +- Cut line: reopening prior state without accepted deployment/admission is not a + new run. Celestial-only tutorial graphs are not playable runs. - Verification layer: focused smokes prove deterministic population, resolved orbital references and poses, distributed non-player spawns, fixed-step orbit phase/pose/velocity through Ymir, station/turret/agent @@ -1259,8 +1266,8 @@ the Terminus proof arena cannot award completion. ### Daemon Regular-Sector Topology Ownership - Owner: `AetheriaDaemonRegularTopologyGenerator` owns the non-tutorial sector - graph. It is distinct from tutorial role placement and from the Terminus - witness fixture. + graph. It is distinct from tutorial role placement and supplies a full + generated-world recipe for Terminus runs. - Inputs: the typed corporation/name catalog, the authored regular-sector settings (`196` zones, `0.5` link density, `12` corporations, `3` bosses), the serialized main cloud field, and one generation seed. @@ -1277,15 +1284,14 @@ the Terminus proof arena cannot award completion. celestial hierarchy, full-influence population, loadout, orbit, patrol, and CultCache persistence organs as the tutorial, under distinct regular-run identities. The entrance receives one equipped controlled starter; every - persisted run carries its explicit `aetheria` game mode. -- Shared paths: accepted New Game identity hashes to the regular generation - seed, so command replay cannot create a different sector. Fresh boot and menu - requests use `AetheriaDaemonRunFactory`; incomplete tutorial state selects the - tutorial writer and completed tutorial state selects the regular writer. -- Cut line: post-tutorial Terminus fallback selection is deleted. Terminus can - only be created when the daemon is explicitly launched with a - `--terminus-scenario` witness fixture; `IsTutorial=false` is no longer allowed - to decide session mode for new state. + persisted run carries its explicit `terminus` game mode and deployment id. +- Shared paths: committed Terminus deployment/admission identity hashes to the + regular generation seed, so command replay cannot create a different sector. + Mode selection chooses the run recipe; ready daemon boot creates no session. +- Cut line: `IsTutorial` cannot decide product mode or progression ownership. + Normal typed mode selection can create Terminus; proof-profile flags only + select non-progressing deterministic witness content. Tutorial and regular + generators remain run recipes beneath the Terminus mode boundary. - Verification layer: focused smoke generates the full sector twice and proves exact seeded repeatability, connected symmetric links, twelve homes, three boss zones, exit isolation, entrance distance, discovery, names, and home @@ -3433,9 +3439,9 @@ invent identity. `scripts/verify-aetheria-daemon.ps1` restores and runs the daemon smoke with one explicit CultLib/EveUnity/Ymir root set so a stale NuGet project graph cannot substitute another worktree during `--no-restore`. The unused Starbridge bootstrap that wrote invented stock, attacker, boss, and -technology keys has been deleted. A future Starbridge mode must enter through -the active daemon game-mode owner and typed catalogs; a dormant document seeder -is not a game mode. +technology keys has been deleted. Starbridge session bootstrap must enter +through shared Hangar deployment, typed mixed-authority policy, the active mode +owner, and typed catalogs; a dormant document seeder is not a game mode. Run-lifecycle ownership is deliberately narrower than a quest system: diff --git a/docs/developer-navigation.md b/docs/developer-navigation.md index 368f2d3b9..dfbc410a0 100644 --- a/docs/developer-navigation.md +++ b/docs/developer-navigation.md @@ -23,19 +23,22 @@ Read these in this order: 2. `docs/aetheria-current-codebase-model.md` Control-flow model of the codebase before the latest Stage 7 work. Some names have moved, but it is still the best broad map. -3. `Aetheria.State/docs/stage-7-thin-client-staged-implementation-plan.md` +3. `docs/game-modes-and-progression.md` + Product-mode and cross-mode progression authority: Terminus, Starbridge, + Arena, Hangar, deployment, and settlement. +4. `Aetheria.State/docs/stage-7-thin-client-staged-implementation-plan.md` The staged migration plan. Use this when deciding what to build next. -4. `Aetheria.State/docs/stage-7-client-surface-inventory.md` +5. `Aetheria.State/docs/stage-7-client-surface-inventory.md` Surface inventory and edit queue for Unity/Electron/client boundaries. -5. `docs/aetheria-verse-client-contract.md` +6. `docs/aetheria-verse-client-contract.md` Intended client contract: use typed Verse state, not daemon internals. -6. `docs/cultmesh-feature-implementation-guide.md` +7. `docs/cultmesh-feature-implementation-guide.md` Step-by-step guide for adding canonical typed state once, letting daemon authority own mutation, and consuming/interacting with the same document from Unity and other clients. -7. `Aetheria.State/docs/verse-authority-implementation-plan.md` +8. `Aetheria.State/docs/verse-authority-implementation-plan.md` Authority and Starbridge staged implementation map. -8. `docs/cockpit-doctrine-combat.md` +9. `docs/cockpit-doctrine-combat.md` Target pilot experience: first-person cockpit, direct and delegated helm, doctrine-owned combat intent, cognition-owned precision execution, and the typed state required to make delegation legible. This defines experience, diff --git a/docs/game-modes-and-progression.md b/docs/game-modes-and-progression.md new file mode 100644 index 000000000..1a8594de8 --- /dev/null +++ b/docs/game-modes-and-progression.md @@ -0,0 +1,197 @@ +# Aetheria Game Modes And Progression + +Status: adopted target design; shared Hangar state is not yet implemented + +## Product Modes + +The first product spine contains three named modes. All three must remain +runnable at a basic level from the start; depth may arrive unevenly, but no mode +is deferred behind a mode-specific rewrite. + +`Terminus` is Aetheria's single-player roguelike mode. A run begins from a +hangar-selected ship and loadout, crosses a daemon-generated sequence of +encounters and locations, and ends through extraction, victory, failure, or +abandonment. Its local daemon is the sole gameplay authority. Its minimum +complete loop is: + +```text +deploy -> fly -> fight -> salvage -> dock/refit -> choose risk -> continue + -> extract or die -> settle once into the Hangar +``` + +`Starbridge` is the cooperative mode. One commander and one to four pilots act +in one shared session. Starbridge is mixed-authority: typed authority policy +assigns bounded claim kinds to the commander, pilots, daemon, or leases while +all participants converge on the same canonical typed state and receipt +history. It uses the same player identity, hull catalog, equipment vocabulary, +loadout templates, fitting rules, and Hangar progression as Terminus while +adding the shared base, RTS projection, waves, fabrication, support systems, +and recovered-technology decisions. + +`Arena` is the PvP and competitive game-simulation mode. Arena is +server-authoritative: the server owns admission, world state, simulation, +rules, scoring, and outcomes. +Human players and AI controllers are clients of the same typed observation and +operation contracts. It is the primary harness for training and evaluating NPC +agent policies and for running build-versus-build balance matrices under exact +rules, seeds, and loadouts. An AI may run faster than real time or in a batch +harness, but it cannot mutate simulation state through a privileged in-process +shortcut. Arena admission policy may restrict, normalize, loan, or price +eligible Hangar equipment without forking the inventory/loadout schema or +trusting a client-authored ship. + +Headless execution is a capability of the shared simulation, not an Arena-only +implementation. Terminus, Starbridge, and Arena can all run without renderers +for regression, agent development, batch simulation, and operational hosting. +Attaching or removing Unity, Electron, or another Eve lowerer cannot change the +authoritative result. + +The tutorial is onboarding, not a progression authority or a fourth inventory. +It may constrain a deployment, teach a Terminus-style run, and grant rewards +only through the same settlement path as every other mode. + +## Authority Map + +- **Owner:** one authoritative typed `Hangar` aggregate owns durable cross-mode + progression for a player: owned hulls, stored equipment and cargo, currencies + and materials, unlocks, saved loadout templates, and docked ship + configuration. +- **Inputs:** authenticated player identity, accepted typed Hangar operations, + the typed catalog, and terminal settlement requests carrying session id, + deployment id, terminal fact id, mode-policy/version identity, and proposed + Hangar delta. +- **Outputs:** canonical Hangar state, saved loadout templates, + eligibility/affordability facts, and canonical settlement receipts and + chronology. +- **Derived state:** Eve menus, inventories, compatible-slot lists, run + summaries, scoreboards, and Unity/Electron presentation. A loadout template + is a recipe over canonical catalog keys, not a second inventory or a live + entity graph. +- **Forbidden writers:** Unity, Electron, AI controllers, Eve lowerers, proof + scenario seeders, run checkpoints, mode authorities, and mode-specific + bootstrap code cannot apply Hangar deltas or mint accepted settlement + receipts. The Hangar cannot rewrite a live session after deployment. +- **Shared paths:** every mode reads Hangar state by identity, requests + admission through a typed Deployment, and submits terminal outcomes through + the same Settlement boundary. Hangar refit and template edits use Hangar + operations. In-session dock/refit uses session operations and crosses the + boundary only at settlement. Resume reopens Hangar or session state by + identity and cannot redeploy or resettle. +- **Deletion line:** no `TerminusHangar`, `StarbridgeHangar`, Arena inventory, + client-local unlock store, or mode-private loadout authority may exist. + Fixture-only mutations remain confined to explicitly named witness profiles + and are structurally unable to settle progression. + +## Session Ownership + +A mode admission authority validates a typed deployment request against a +versioned Hangar snapshot and mode policy, then emits an immutable committed +Deployment receipt/snapshot. The Hangar owns available durable assets and +configuration; it does not own Arena admission or Starbridge role assignment. + +A mode session owns its live world: instantiated ships and equipment, damage, +temperature, energy, cargo gathered during the session, encounter state, +score, mode-local stock, and outcome. Starting a mode instantiates session state +from one committed deployment. After launch, changing the Hangar does not reach +into the live world. + +The authority policy differs without changing the document model: + +- **Terminus:** the local daemon decides all gameplay state. +- **Starbridge:** mixed authority assigns bounded claim kinds to participants; + typed policy and committed receipts make ownership visible and revocable. +- **Arena:** the authoritative server decides all gameplay state; humans and + AIs submit operations and consume observations. + +The exact deployment/risk policy belongs to typed mode policy. Terminus may +risk the deployed hull, insured value, carried equipment, extracted salvage, +or some combination without changing the ownership model. Starbridge may loan +or share session equipment. Arena may normalize deployments. In every case, +the policy is evaluated by the applicable authority and reported in the +deployment and settlement receipts, not inferred by a menu. + +## First-Wave Vertical Slices + +Each mode must prove the shared spine early: + +1. **Terminus:** deploy, fly, fight, salvage, dock/refit, and settle one run. +2. **Starbridge:** one commander and one pilot share a base/session, exercise + one policy-owned command each, and converge on one outcome. +3. **Arena:** start a deterministic dedicated-server match, attach at least two + controllers (human or AI), exchange typed observations/operations, resolve a + scored combat outcome, and reproduce it from the same seed and inputs. + +Arena is the canonical competitive simulation harness for AI development and +balance work. Batch and accelerated execution use the same server simulation, +admission policy, equipment rules, and command gate as live PvP. Controllers +can pit NPC policy versions against each other, compare ship/loadout builds, and +produce scored replayable outcomes. Renderers are optional consumers; headless +execution is not a separate gameplay implementation. + +Run-local loot and credits do not become durable merely because a client can +display them. A mode authority submits a terminal outcome and proposed delta; +the Hangar validates identity, policy, and idempotency before committing it. +Every accepted terminal outcome—extraction, victory, failure, or abandonment— +produces exactly one canonical Settlement receipt, even when its delta is zero. +Retries return the existing receipt. A session without an accepted terminal +fact produces none. Reconnect and restart resume canonical Hangar or session +state; they do not replay rewards. + +## Terminus Product And Witness Profiles + +Terminus is the product mode. Its standard run is not a fixture. The existing +deterministic scenarios remain useful subordinate verification profiles: + +- `released-client-proof` creates controlled combat and salvage conditions; +- `cargo-capacity-rejection-proof` creates a full-cargo rejection condition. + +Those profiles exercise the same Terminus simulation, Eve surfaces, operations, +and Unity lowering as the product. They use distinct run identities and cannot +write Hangar progression. A proof profile may simplify content; it may not own +a parallel gameplay path. + +## Current Migration Seam + +The daemon already owns typed run checkpoints, loadout templates, catalog keys, +combat, loot, docking, trade, and Terminus scenario generation. Starbridge has +typed session, station-stock, role, wave, and summary documents. These are +components of the design, not yet a durable shared Hangar owner. + +Arena does not yet have a named server/session/admission/score document family +or a preserved headless controller harness. Shared simulation smokes are useful +substrate, but they do not constitute the Arena mode. Starbridge's existing +documents also do not by themselves prove mixed-authority convergence. + +The next state-architecture cut is to define the canonical Hangar, Deployment, +and Settlement documents; define one typed mode-selection boundary; and keep a +minimal Terminus, Starbridge, and Arena vertical slice alive against it. Until +that cut lands, documentation and verification must not describe existing run +checkpoints or proof scenarios as cross-mode progression authority, or generic +simulation smokes as Arena product proof. + +## Required Proofs + +1. A saved Hangar loadout deploys into Terminus and Starbridge and enters Arena + admission through the same typed operation and catalog keys. +2. A Terminus run completes the playable loop, settles exactly once, and a new + session observes the resulting durable Hangar state. +3. Failure, abandonment, reconnect, and daemon restart cannot duplicate rewards + or resurrect losses. +4. Witness profiles cannot mutate Hangar progression. +5. Unity and Electron can read and request operations but cannot write Hangar, + deployment, session, or settlement state directly. +6. No mode-specific inventory or loadout document can override the canonical + Hangar. +7. Arena produces the same authoritative result for the same initial state, + seed, ordered typed operations, and simulation version whether controllers + are humans, AIs, rendered clients, or a headless batch harness. +8. Starbridge policy changes authority without changing document or operation + schemas, and denied claims expose the active owner and reason. +9. Terminus and Starbridge also complete representative scenarios headlessly; + attaching a renderer does not change their ordered facts or outcome. +10. Arena balance batches record simulation version, content/catalog version, + seed, admission policy, controller policy identities, deployments, ordered + operations, and scored outcome so build and AI comparisons are reproducible. +11. A terminal outcome cannot mutate Hangar state before Hangar acceptance; + duplicate or reordered delivery returns the same receipt and delta. + In-session refit and resume cannot invoke deployment or settlement. diff --git a/docs/original-game-migration-matrix.md b/docs/original-game-migration-matrix.md index d2b8e76a6..830f1bf38 100644 --- a/docs/original-game-migration-matrix.md +++ b/docs/original-game-migration-matrix.md @@ -15,7 +15,7 @@ validation proves contract shape, not wiring, exclusivity, lowering, or parity. | Organ | Original authority/evidence | Target owner | Eve contract | Runtime lowering | Current status | Required proof | |---|---|---|---|---|---|---| -| Run/session state | `ServerShared`, `ActionGameManager` | Aetheria daemon/CultCache | provider/session advertisement plus run lifecycle bindings | all clients | active/failed lifecycle is daemon-owned and restart-stable: controlled-entity destruction commits the fossil cause, terminal frame, one `run.failed` fact, releases control, rejects later gameplay commands, and freezes the world; Eve receives terminal presentation/input levers without becoming an owner. Terminus keeps persistent requested simulation rate distinct from effective rate: compressed batches inspect authoritative facts after each fixed step, stop at the causal damage/destruction/cargo/thermal/docking/weapon/wormhole/run event, pause effectively without erasing the request, and project the exact cause and executed-step count through Eve. Docked, travelling, fighting, mining, looting, and refitting remain derived world conditions rather than counterfeit durable phases. The distinct tutorial is now daemon-owned and selectable: authored 64-zone topology, bodies, post-body station/turret/agent population, resolved orbital placement, deterministic half-zone NPC distribution, starter entry ship, loadout receipts, discovery, and canonical persistence feed an Aetheria-mode session. Generated orbit facts carry the fossil distance-derived period; daemon fixed steps advance phase and project the shared graph into orbital pose/velocity before Ymir while Eve and body queries observe the same graph. New Game submits its Eve operation and waits for the new sector-map publication. The daemon also owns the distinct fossil regular sector: 196 weighted zones, pruned Delaunay graph, twelve selected corporations, three boss chokepoints, full influence radii, isolated exit, furthest entrance, discovery, order-four names, celestial/population/loadout materialization, controlled starter, patrol work, and CultCache persistence. Accepted New Game identity determines the seed. New runs explicitly carry `aetheria` mode; post-tutorial Terminus fallback selection is deleted and Terminus generation requires an explicit witness launch option | source-backed tutorial completion rule (none survived in the fossil); full-scale real-catalog daemon/client regular-sector witness, boss entity/narrative behavior where source evidence exists, full-daemon death/restart witness, broader attention taxonomy, and multi-client convergence | +| Run/session state | `ServerShared`, `ActionGameManager` | mode authority over canonical CultCache/CultMesh state | provider/session advertisement, mode policy, Hangar deployment/settlement, and run lifecycle bindings | all clients and headless controllers | active/failed lifecycle is restart-stable and renderer-independent. Terminus is the single-player roguelike under sole local-daemon authority; Starbridge is co-op under typed mixed-authority policy; Arena is server-authoritative PvP and the primary NPC-policy/build-balancing harness. All three use the same target Hangar, deployment, catalog-key, fitting, loadout-template, and settlement vocabulary while owning distinct live sessions. Tutorial and regular topology are Terminus run recipes, not progression owners. Deterministic Terminus proof profiles retain distinct identities and cannot settle Hangar progression. All modes must execute headlessly through the production simulation and operation gates. The shared Hangar/Deployment/Settlement owner is adopted design but not yet implemented | implement and prove one canonical Hangar/deployment/settlement spine; launch ordinary Terminus without a proof flag; mixed-authority Starbridge convergence; deterministic server-authoritative Arena with human/AI-equivalent operations and versioned build-versus-build replays; renderer/no-renderer outcome parity; restart and exactly-once settlement | | Entity identity/loadout | `ServerShared/Entity*` | daemon | typed entity and inventory surfaces | EveUnity/Electron | daemon-owned hull identity, exact installed placement/rotation and instance state, cargo stacks, weapon membership/held state, equipment wear, executable behavior state, weapon chronology, active-effect state, and loadout-generation provenance survive a hard CultCache close/reopen through the durable latest-frame checkpoint. An advertised generic Eve equip operation now translates into the typed daemon transaction before that checkpoint; its accepted placement survives restart and its consumed station-cargo source does not resurrect. Generic Eve rebuilds weapon and scalar thermostat controls from that restored truth; legacy per-entity documents are bootstrap inputs only when no live frame exists | live client refit witness and multi-client convergence | | Loadout generation | map/faction availability, item cost, hull hardpoints and role constraints | daemon using canonical galaxy, faction knowledge/economy and typed catalog | generated loadout plus provenance/availability facts | Eve inspection and refit surfaces | daemon now uses the fossil candidate filter and seeded weighted selection: manufacturer must be present and allied, ally weight decays by home-zone graph distance, price uses the authored exponent, and hardpoints require matching semantic type, rotated footprint containment, and controller role. Prelude generation retains the fossil exception that allied catalog manufacturers need not own one of the six tutorial home zones; unknown manufacturers remain zero-weight. The April 2021 catalog fossil restores the distinct common `Longinus`, rare AetherDrive-compatible `LonginusX`, and `Djinni` rows with their original IDs, shapes, hardpoints, prices, drag, and prefabs, plus missing Thruster rows required to fill their authored mounts; typed `rarity:rare` tags apply a 0.05 generation multiplier to `LonginusX` and AetherDrive equipment; the generator owns one mutable CultMath stream, fixing the readonly-struct defensive-copy bug that restarted every weighted draw; placement rotation survives durable state and reconnect; generation fills the largest compatible footprint before economic weighting; cargo/capacitor plus station docking equipment must fit remaining hull space; stations pack faction-available inventory largest-first; ordinary ships begin without invented scenario cargo; every generated entity persists a source/selection receipt that reaches Eve as `loadout.item` semantics | multi-zone generated-world parity and exact root-to-zone stream sequencing against the fossil | | Flight intent | `Ship`, `Thruster`, `AetherDrive`, `VelocityConversion`, `VelocityLimit`, input paths | daemon actuator simulation + Ymir integration | analog local helm/look/tractor plus actuator state | generic Eve input and scene lowerers | direct faction-speed velocity ownership is deleted; daemon persists local strafe/forward helm and desired look, allocates ordinary directional thruster banks by authored rotation, derives torque from hull/item placement, compensates lateral torque, gates execution through the shared energy ledger, deposits equipment-cell heat, publishes plume visibility and actuator state, applies hull drag, then runs operational velocity conversion with the fossil exponential damp equation and clamps the result through evaluated velocity limits before giving velocity/direction to Ymir. The evaluated limit remains in durable behavior state for reconnect and Eve inspection. Autonomous tasks translate world travel into the same local helm axes and issue look commands instead of mutating heading. AetherDrive rotor/coupling simulation is additive and explicitly non-default: common `Longinus` and `Djinni` hulls use ordinary thrusters; the rare `LonginusX` replaces those mounts with the single rare `Traction` AetherDrive path | hardpoint-transform direction parity, exact cross-equipment behavior execution ordering, CultMath/float32 parity harness, live production-frequency evidence, generic thrust/turn feedback lowering, and live handling screenshots | @@ -41,7 +41,7 @@ validation proves contract shape, not wiring, exclusivity, lowering, or parity. | Hit/lock/warnings | `ActionGameManager` feedback | daemon event facts | transient feedback stream | VFX/UI/audio | bounded deduplicated game-event ledger and Eve `feedback.stream` wired for pickup outcomes, projectile launch/impact, entity damage, alive-to-dead destruction, thermal-risk crossings, accepted dock/undock transitions, authoritative weapon reload chronology, lock start/acquired/lost chronology, and episode-deduplicated `weapon.fire.refused` facts for insufficient energy or missing ammunition; docking facts retain exact actor/parent/bay identity and rejected operations emit none; every lock transition carries authored weapon identity, target, reason, and prior/current progress, while reconnect priming prevents retained events from replaying as new feedback | broader negative transaction fixtures, provider lock/docking audio and effect roles, and broader runtime effect consumption | | Assets | `Assets/Resources` | Aetheria provider | asset catalog + CultMesh CDN | runtime cache/load | provider manifests name deterministic bundle-internal paths and now project each typed hull prefab through the same asset key in Eve scene and SoA identity state; the authoring build derives presentation-only prefabs, strips non-Eve gameplay scripts, externalizes embedded effects, preserves source material semantics, and verifies the loaded bundle ABI; released EveUnity `0.3.57` resolves Unity's lowercase bundle names against authored-case advertised keys. The released cold witness begins with an empty cache, transfers the 56,168,017-byte body through `cultmesh.content.v1`, atomically promotes its exact SHA-256 with no partial, selects `SharedFileMapping`, and lowers the shield-free hull while preserving pilot/map isolation | provider-to-client network zero-copy, shared-memory delivery, and GPU zero-copy remain open; the managed network session still copies and fragments payload bytes before verified promotion | | Save/resume | original persistence paths | daemon/CultCache | published current state | clients rehydrate | durable latest-frame checkpoints survive real CultCache directory-store close/reopen with complete loadout/behavior state, pending combat lock/trigger state, consumed pickup removal/cargo chronology, active autonomous task ownership, and a mid-wormhole multi-zone route. Fresh Ymir sessions reconstruct ordinary motion from committed world truth; loot replay safety comes from the same atomic durable pickup removal and cargo insertion rather than a private contact journal. Explore tasks resume through the same scheduler movement commands, complete exactly once, release helm ownership, and reach the generic Eve commander surface; cross-zone restart preserves the transition phase and exactly-once event chronology without cloning the worker | live process-kill/relaunch witness and version/catalog migration policy | -| Terminus loop | original game composition | daemon/Ymir/Eve | pilot surface | Aetheria.Unity | released minimum/full-session witnesses prove generic provider discovery, world/assets, dock/undock, trade, movement, targeting, fire, destruction, tractor motion, and feedback. The current released loop proves tractor delivery into daemon XZ proximity, one stable `pickup.collected` event, durable pickup removal, and cargo `0` to `1` without a Ymir fact receipt; its full-cargo sibling proves one stable rejection, unchanged cargo, and retained provider pickup state | richer trade content, docking transitions, and sustained combat encounters | +| Terminus loop | original game composition | local daemon/Ymir/Eve plus shared Hangar boundary | pilot surface and typed mode/deployment/settlement operations | Aetheria.Unity or headless controller | released witness profiles prove generic provider discovery, world/assets, dock/undock, trade, movement, targeting, fire, destruction, tractor motion, feedback, exactly-once pickup, and full-cargo rejection. These prove subordinate mechanics, not ordinary product launch or durable progression. Terminus is the canonical single-player roguelike and standard runs are product state | normal mode-selection launch without a proof flag; shared Hangar deployment; escalating run/choice/extraction loop; exactly-once settlement; richer trade/refit and sustained combat; headless/rendered parity | | Starbridge | original/shared architecture intent | one daemon session | pilot + commander surfaces | Unity + Electron | commander task board and autonomous explore execution wired; Electron Eve lowering and split-target proof missing | commander orders plus four pilots and autonomous workers | | Behavior engine | `ServerShared/Behaviors` composition | daemon | executable action/status projection | action bar and feedback | tick reconciles equipped catalog payloads into persistent behavior state; `Switch`, one-shot `Trigger`, normalized `Cooldown`, adjustable high/low-pass `Thermotoggle`, `EnergyDraw`, equipment `Heat`, atomic `ItemUsage`, and thermal `Wear` execute in authored group order and stop downstream effects on refusal; each row records whether the chain reached it. `Thruster`, rare `AetherDrive`, `Radiator`, `MiningTool`, and `ResourceScanner` pause their groups at the specialized owner, report the exact fossil success result, and resume common tails at most once. Invalid or out-of-range resource work therefore cannot consume trailing cargo or wear. Deferred tails now complete after the resource owners and before reactor settlement and thermal integration, preserving the fossil consumer-before-reactor order; radiator emission remains its independent always-update path. Cooldown projects generic progress and thermostat target is daemon-commanded state seeded from authored data. Equipped and timed-consumable `StatModifier` sources persist daemon-owned lifecycle state and every runtime stat reader applies the fossil `base × multiplier product + constant sum` rule through one query; legacy `Data` kind references and required-behavior filters are honored | remaining specialized return-value composition and canonical consumable-content proof | | Sensors/visibility | installed sensor sensitivity and angular curve, `Visibility`, `Reflector`, decaying signature sources, stellar light, ping state, and observer information thresholds | daemon | accumulated contacts, named visibility sources, and ping events | indicators/maps and provider environment lowering | every operational installed Sensor executes the fossil visibility/sensitivity/angle/distance information equation and decay; visibility is thresholded by the provider setting. Actor-scoped ping owns energy, cooldown, expansion radius, reconnect-stable crossed-target state, one-time information boost, and transient signature. Operational `Visibility` equipment publishes evaluated constant signature; committed weapons publish authored signature including charged-shot multiplication; transient weapon and ping sources decay by the fossil exponential rule. Reflectors multiply evaluated cross-section by the exponent-8 stellar `PowerPulse` after thermal settlement. Gameplay light and environment projection share resolved authored orbit/body centers and provider-owned sun radius inputs. Contact refresh no longer invents perfect information or overwrites emitted visibility; docked craft consume one daemon-derived union of craft and dock-parent contacts through both Eve rows and SoA bodies, with sensor-source provenance | active consumable visibility/reflector effects, complete source cardinality, classification timelines, and canonical catalog station-array data | diff --git a/docs/original-game-specification.md b/docs/original-game-specification.md index 2b23fe194..b83fafbd6 100644 --- a/docs/original-game-specification.md +++ b/docs/original-game-specification.md @@ -76,7 +76,11 @@ The principal source bodies are: Terminus is a single-player game mode using the pilot surface. The minimum complete loop is: fly, acquire or select a target, fire, survive return fire, destroy or disable something, scoop useful cargo, dock, and trade. It shares -pilot mechanics and presentation with the Starbridge pilot role. +pilot mechanics and presentation with the Starbridge pilot role. The target +product is a repeatable roguelike run: deploy from the persistent Hangar, +cross escalating encounters, salvage and refit, then extract, win, abandon, or +die. Only an accepted terminal settlement may move rewards or losses between +the run and the Hangar. ### Starbridge @@ -89,6 +93,26 @@ authoritative state: same strategic world facts; - view choice never creates a second simulation. +Starbridge is mixed-authority. Typed policy assigns bounded command/claim kinds +to the commander, pilots, daemon, or leases; every accepted mutation joins one +canonical state and receipt history. Mixed authority does not mean private +client worlds that reconcile after the fact. + +Terminus, Starbridge, and Arena share the canonical Hangar, deployment, +catalog keys, fitting rules, and saved loadout templates described in +[Game Modes And Progression](game-modes-and-progression.md). They do not share +live session entity graphs, encounter state, or mode-local stock. + +### Arena + +Arena is the server-authoritative PvP and competitive game-simulation mode. Human +players and AI controllers use identical typed observations and operations; +the server alone admits deployments, advances simulation, resolves combat, and +scores outcomes. Deterministic and accelerated Arena runs are the primary NPC +policy training/evaluation and build-versus-build balancing harness, not a +second rules implementation. Terminus and Starbridge must also run headlessly; +headless execution belongs to the shared simulation body, not to one mode. + ### Pilot View The pilot view follows the controlled ship in 3D. It presents world geometry, @@ -351,8 +375,10 @@ must preserve the original generation and transition rules before new content extends them. Terminus content may be sparse, but the machinery must support a repeatable -single-player loop. Starbridge uses the same world truth while adding commander -and multi-pilot coordination. +single-player roguelike loop. Starbridge reuses the same Hangar and pilot +machinery while adding its own shared session, commander, and multi-pilot +coordination under mixed authority. Arena reuses the same deployment vocabulary +under server-authoritative admission/normalization. Travel is embodied through nearby wormholes. Transition transfers the current entity, reveals destination adjacency, performs exit motion, and saves. @@ -397,9 +423,12 @@ activation from local particle collisions. ## Save, Resume, And Multiplayer Consistency -Authoritative run state persists in CultCache and is published through -CultMesh. Reconnect, reload, and view changes must reproduce the same current -entity, zone, loadout, docking, target, combat, cargo, and progression state. +Authoritative run state and durable Hangar progression are separate typed +CultCache state published through CultMesh. Reconnect, reload, and view changes +must reproduce the same current entity, zone, session loadout, docking, target, +combat, and run-local cargo. The Hangar separately preserves owned ships, +stored equipment, currencies/materials, unlocks, and saved loadout templates. +Only deployment and exactly-once settlement transactions cross that boundary. Presentation-only animation may restart; game decisions may not. Starbridge clients observe one shared session. A pilot and commander can issue @@ -425,6 +454,15 @@ different semantic commands, but neither owns a private copy of the world. state without client repair logic. 8. **Starbridge:** one commander and multiple pilots act in the same session; all projections converge on one command/receipt history. +9. **Cross-mode progression:** deploy one saved Hangar loadout into Terminus and + Starbridge through the same typed path; admit it into Arena through that path; + settle a Terminus outcome exactly + once; prove reconnect, failure, and proof scenarios cannot duplicate or + counterfeit durable progression. +10. **Arena simulation:** run a deterministic server-authoritative match with + human or AI controllers using the same typed operation boundary; reproduce + the scored outcome headlessly from the same seed and ordered inputs; compare + controller-policy and ship-build variants with versioned reproducible facts. ## Open Archaeology Ledger diff --git a/docs/original-game-world-economy-spec.md b/docs/original-game-world-economy-spec.md index 013c87d05..25fd1b20f 100644 --- a/docs/original-game-world-economy-spec.md +++ b/docs/original-game-world-economy-spec.md @@ -88,7 +88,10 @@ acceptance. Towing is a separate station-mediated relocation mechanic. ## Progression Spine -New game begins at the entrance with a generated player ship. Baseline +The fossil New Game begins at the entrance with a generated player ship. In the +target product, mode selection begins from a committed Hangar deployment; +generation may fill mode-owned world content and explicitly loaned session +equipment, but it does not replace durable cross-mode progression. Baseline progression consists of: - exploration and discovery; @@ -100,6 +103,17 @@ progression consists of: - narrative locations; - persistence of zone, entity, inventory, loadout, and action bindings. +The target separates two owners: + +- the shared Hangar owns durable hulls, stored equipment/cargo, currencies, + unlocks, and saved loadout templates across Terminus, Starbridge, and Arena; +- each mode session owns its instantiated ship, damage, run-local cargo, + encounter state, and score until one terminal settlement applies the mode's + explicit reward/loss policy. + +No mode owns a private inventory schema. See +[Game Modes And Progression](game-modes-and-progression.md). + The target daemon needs an explicit run-state machine linking these pieces, including new/continue, active encounter, docked service context, travel, failure/death, completion, and Starbridge session roles. A collection of diff --git a/docs/renderless-aetheria-architecture.md b/docs/renderless-aetheria-architecture.md index f527b4ad6..dd777b626 100644 --- a/docs/renderless-aetheria-architecture.md +++ b/docs/renderless-aetheria-architecture.md @@ -13,14 +13,18 @@ lowering semantics, and Aetheria clients are conformance targets. ## Objective -Aetheria should become a renderless daemon-owned game. +Aetheria should become a renderless, policy-authoritative game whose three +product modes share one simulation and progression spine. -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 world-state -rendering instruction contract. Unity, Godot, Electron, Hermodr, and later -runtimes lower Eve surfaces and submit typed operations; they do not own -Aetheria gameplay truth. +Terminus uses sole local-daemon authority. Starbridge uses typed mixed authority +across commander, pilots, daemon, and bounded leases. Arena uses sole +server authority. The applicable authorities own committed game state and +simulation claims; Aetheria providers publish canonical typed operations, +assets, and high-performance views of live state. Eve owns the portable UI and +world-state rendering instruction contract. Unity, Godot, Electron, Hermodr, +AI controllers, and later runtimes lower surfaces or submit typed operations; +renderer attachment is never an authority input. All three modes must also run +headlessly through the same simulation body. 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, @@ -34,16 +38,21 @@ daemon-authored contract, without inheriting Unity scene authority. ## Authority Map Owner: -Aetheria daemon owns committed game state and rules. +Typed mode policy owns the authority assignment. The Terminus local daemon and +Arena server own all gameplay claims in their sessions. Starbridge assigns +bounded claim kinds across participants while preserving one canonical state +and receipt history. The shared Hangar remains a separate authoritative typed +aggregate outside live sessions. Inputs: -The daemon may read typed CultCache/CultMesh documents, catalog data, authority -policy, player/client operation documents, simulation clock input, deterministic -generation seeds and asset manifests. Its simulation transaction may invoke the -embedded Ymir spatial kernel, but Ymir does not become a second state owner. +Applicable authorities may read typed CultCache/CultMesh documents, catalog +data, authority policy, player/AI operation documents, simulation clock input, +deterministic generation seeds and asset manifests. Simulation transactions may +invoke the embedded Ymir spatial kernel, but Ymir does not become a second state +owner. Outputs: -The daemon publishes typed state documents, committed facts, operation receipts, +The provider 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, typed CultMesh artifact manifests, managed content sessions, and Eve/CultUI surfaces. @@ -163,20 +172,24 @@ the fossil owner-security and faction-relationship rule. A visible hostile ship pre-empts circuit movement through the existing combat planner; the patrol task keeps its circuit index and resumes it when contact is lost. -New Game now submits its advertised Eve operation, waits for a newly published -daemon sector map, and selects the persisted 64-zone tutorial while -`TutorialPassed` is false. The handcrafted Terminus arena remains a proof -fixture and the fallback for the still-unmigrated post-tutorial sector path. -No surviving source defines tutorial completion, so entering this run does not -change `TutorialPassed`. +Mode selection submits an advertised Eve operation and waits for a newly +published daemon session. Terminus is the canonical single-player roguelike; +its standard launch is product state, not a witness fixture. The persisted +64-zone tutorial is an onboarding run recipe that may constrain a Terminus +deployment without owning a separate inventory or progression path. No +surviving fossil source defines tutorial completion, so the target completion +and settlement rule remains an explicit design seam. Target onboarding +completion must be a typed progression/settlement fact; the fossil +`TutorialPassed` boolean cannot select product mode or own Hangar progression. The non-tutorial sector has a separate daemon owner matching the fossil's 196-zone settings, corporation selection, entrance/exit isolation, boss chokepoints, full influence radii, discovery, and order-four names. It feeds the daemon celestial, population, loadout, patrol, and persistence pipeline and -enters through an explicit Aetheria-mode run. Post-tutorial New Game selects it -using a command-stable generation seed. Terminus is no longer a fallback; it is -created only by an explicit witness launch option. +is reusable as a full Terminus run recipe under a command-stable generation +seed. `released-client-proof` and `cargo-capacity-rejection-proof` remain +non-progressing Terminus witness profiles with distinct run identities; they +are not the only launch path for the product mode. ## Current Mechanism diff --git a/docs/unity-daemon-development.md b/docs/unity-daemon-development.md index 6814a6e8f..69cee7ffb 100644 --- a/docs/unity-daemon-development.md +++ b/docs/unity-daemon-development.md @@ -25,9 +25,11 @@ ready for the next connection. Starting the daemon does not create, load, or step a game world. It starts the typed state boundary and CultMesh transport in `ready` mode. A playable-world -subscription loads an existing run; the advertised New Game command generates -a new run. Only that activation boundary opens Ymir persistence and starts the -fixed simulation clock. When the last playable-world subscription is withdrawn, +subscription loads an existing run. Typed mode selection chooses authority and +policy; a committed deployment/admission creates session state through the +applicable provider or Arena server. Only that activation boundary opens +simulation persistence and starts the fixed simulation clock. When the last +playable-world subscription is withdrawn, the daemon commits the final public frame and matching private Ymir checkpoint, releases the active physics world, and returns to `ready`. A dropped client therefore leaves the daemon and saved world alive without making Unity Play