diff --git a/Aetheria.State/docs/daemon-code-map-for-rust-port.md b/Aetheria.State/docs/daemon-code-map-for-rust-port.md index 6a6728789..cf5af95e1 100644 --- a/Aetheria.State/docs/daemon-code-map-for-rust-port.md +++ b/Aetheria.State/docs/daemon-code-map-for-rust-port.md @@ -71,10 +71,10 @@ These files define the deprecated reference surface. They should be treated as A | Area | Source | What to freeze | | --- | --- | --- | -| Host behavior | `Aetheria.State.Daemon/Program.cs` | CLI options, startup behavior, seed behavior, tick cadence, RUDP endpoint behavior, remote fact import behavior. | +| Host behavior | `Aetheria.State.Daemon/Program.cs` | CLI options, startup behavior, seed behavior, tick cadence, RUDP endpoint behavior, and the obsolete remote committed-fact import behavior that must become Pilot candidate selection plus Commander finality. | | CultMesh node wrapper | `Aetheria.State/AetheriaStateNode.cs` | Current record reads/writes, observed command query behavior, flush semantics. | | Registry | `Aetheria.State/AetheriaDocumentRegistry.cs` | C# document set currently exposed through CultCache/CultNet. | -| Replica sync | `Aetheria.State/AetheriaVerseReplica.cs` | Scoped snapshot fetch, document fetch, remote committed fact import dependency. | +| Replica sync | `Aetheria.State/AetheriaVerseReplica.cs` | Scoped snapshot/document fetch to preserve; remote committed-fact import is migration evidence, not target authority. | | Local publications | `Packages/org.gamecult.aetheria.state/Runtime/AetheriaRuntimeCultCacheDocumentStore.cs` | `.cc` compatibility files and their payload layout. | | Daemon documents | `Packages/org.gamecult.aetheria.state/Runtime/AetheriaRuntimeDaemonDocuments.cs` | Schema ids, command enum, frame, command, committed fact, viewport, health, provider, command boundary, surface docs. | | Snapshot documents | `Packages/org.gamecult.aetheria.state/Runtime/AetheriaRuntimeSnapshotDocuments.cs` | Run, zone, entity, body, equipment, cargo, loadout, stat grids. | @@ -122,7 +122,9 @@ The C# host does this today: - Step the daemon-owned Aetheria simulation. - Build a daemon frame. - Publish committed command facts. - - Import remote committed command facts. + - Import remote committed command facts (current behavior to delete or + quarantine; target Pilot output enters before finality as candidate + evidence and Commander correction/replay selects one canonical fact). - Publish frame, health, command boundary, provider docs, Starbridge summary, SoA view, and Eve surfaces. This is behavior to measure and learn from. It is not the desired architecture. diff --git a/Aetheria.State/docs/stage-7-client-surface-inventory.md b/Aetheria.State/docs/stage-7-client-surface-inventory.md index 640ba49fa..18986fb4b 100644 --- a/Aetheria.State/docs/stage-7-client-surface-inventory.md +++ b/Aetheria.State/docs/stage-7-client-surface-inventory.md @@ -26,7 +26,7 @@ Stage 7E passes. ```text client input -> local typed Verse command document -> local daemon local daemon state -> local typed projection/read -> renderer or UI panel -peer daemon facts -> local authority import -> local state +Pilot daemon candidate evidence -> Commander selection/finality -> shared local state ``` Forbidden as public client shape: 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 40a97778f..06d01fa71 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,9 +81,11 @@ 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 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. +Starbridge is the current Stage 7 mixed-authority pressure for this shape. One +RTS commander and one to four Unity pilots must share one Commander-finalized +Verse. The Commander player authors outside Pilot jurisdiction; Pilot daemons +publish candidates inside assigned jurisdictions; the Commander daemon owns +default simulation, correction/replay, and finality. The product source for that pressure is `E:/Projects/AetheriaLore/Aetheria/Game Design/Aetheria Starbridge.md`. Stage 7 @@ -123,9 +125,11 @@ local Verse state rather than through a peer viewport. ## Current Baseline -Completed and usable: +Completed and usable migration evidence: -- Stage 6 live committed fact import passes. +- Stage 6 scoped two-daemon fact transport passes, but committed peer-fact + import is not the target Starbridge finality model. It must become Pilot + candidate transport plus Commander selection/replay. - Electron public API exposes typed methods: `mapViewport`, `setMoveVector`, and `setTarget`. - Electron IPC exposes typed channels: @@ -210,7 +214,8 @@ Status: complete. Inputs: -- Stage 6 live committed fact import. +- Stage 6 scoped transport and the target Pilot-candidate/Commander-finality + contract. - Existing Unity shell. - Existing Electron RTS shell. @@ -1265,7 +1270,8 @@ Inputs: - Electron thin client from 7C. - Unity thin client from 7D. -- Stage 6 peer committed fact import. +- Stage 6 scoped transport plus the Pilot-candidate/Commander-finality contract; + the current peer committed-fact importer is migration evidence to remove. Build: @@ -1284,7 +1290,9 @@ Verifier: - Electron observes that pawn in map view. - Electron commands owned units. - Unity observes remote commanded units through the same daemon state. -- Both local daemons converge on imported committed facts. +- Pilot-scoped results enter as candidates; the Commander selects, replays any + provisional dependents, and publishes one Commander-finalized fact log that + both clients observe. Stop line: diff --git a/Aetheria.State/docs/verse-authority-implementation-plan.md b/Aetheria.State/docs/verse-authority-implementation-plan.md index 4debab845..9f032b95e 100644 --- a/Aetheria.State/docs/verse-authority-implementation-plan.md +++ b/Aetheria.State/docs/verse-authority-implementation-plan.md @@ -9,10 +9,12 @@ do not build the next stage on top of it. Raven and Starfire each run a local CultMesh/CultNet Verse node. -- Unity Raven is a thin renderer/input runtime for Raven-owned claims. -- Electron/RTS Starfire is a thin renderer/input runtime for RTS-owned claims. -- Aetheria state is synchronized as typed Verse documents and typed committed - facts. +- Unity Raven hosts the Pilot renderer/input shell and may host its bounded + prediction daemon. +- Electron/RTS Starfire hosts the Commander interface; the Commander daemon + owns default simulation, finality, persistence, and publication. +- Pilot output enters as typed candidate/prediction evidence, never as an + already committed fact. - Authority is selected by typed policy state, not by client type, transport branch, string operation names, or viewport queries. - Future authority modes remain representable without forcing the first trusted @@ -22,14 +24,13 @@ 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 -combat, salvage, docking, refit, anchoring, cooling, repair, survival-pod, -cargo/equipment, and local target-mark claims. These are policy-scoped claim -kinds, not client-type privileges. +Starbridge uses Commander-default simulation with jurisdictional Pilot +correction. One RTS chair and one to four pilots defend the same base. The +Commander daemon simulates all facts and owns the canonical log. Each Pilot +daemon independently predicts facts for its own ship, Commander-assigned nearest +environment entities, and assigned combat engagements. A validated mismatch +resolves toward the Pilot result; the Commander daemon corrects and replays its +provisional state. The Commander player owns Verse authorship everywhere else. The release-facing source for that product target is `E:/Projects/AetheriaLore/Aetheria/Game Design/Aetheria Starbridge.md`. This @@ -47,6 +48,11 @@ 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`. +These modes are the CultMesh authority runway: Terminus proves local authority, +Arena proves server authority, and Starbridge proves mixed authority. +Witness-authoritative operation is the next milestone only after the Arena and +Starbridge finality/replay proofs pass through the shared fact contract. + ## Hard Rules 1. No public stringly command APIs. @@ -95,17 +101,15 @@ Immediate Aetheria mappings: Target runtime flow: ```text -local input - -> typed command/proposal document - -> local Verse node - -> daemon tick command gate - -> authority policy decision - -> simulation mutation - -> typed committed command fact - -> local Verse document publication - -> peer scoped fact sync - -> peer fact import gate - -> peer local state mutation +Commander tick envelope + jurisdiction epoch + -> Commander default candidate for every fact slot + -> Pilot candidate for assigned slots + -> scoped candidate transport + -> jurisdiction/schema/rules validation + -> typed semantic comparison + -> Pilot-wins correction and Commander replay on mismatch + -> one Commander-finalized fact log + -> local Verse document publication and projections -> local viewport/projection query -> renderer ``` @@ -119,7 +123,8 @@ local client ``` Diagnostic and editor tools may ask a remote runtime for a projection, but game -clients must converge their local Verse state from typed facts. +clients must converge on Commander-finalized typed facts. Pilot output crosses +the network as candidate evidence, never as already committed truth. ## Current Code Map @@ -130,7 +135,7 @@ clients must converge their local Verse state from typed facts. | `AetheriaRuntimeVerseClient` | client-side typed state facade, but registry currently omits newer authority/fact documents | canonical thin client facade over the same typed Verse documents clients need | | `AetheriaRuntimeAuthorityRouter` | pure policy decision engine | keep pure, allocation-light, topology-free | | `AetheriaRuntimeDaemonTickRunner` | simulation tick and operation execution | only place local commands mutate sim state | -| `AetheriaRuntimeCommittedFactImporter` | replays trusted remote facts through policy gate | peer convergence path, eventually used by daemon loop | +| `AetheriaRuntimeCommittedFactImporter` | replays trusted remote facts through policy gate | delete or quarantine; replace with Pilot candidate ingestion, selection receipts, and Commander correction/replay | | `AetheriaVerseReplica.SyncSnapshotAsync` | broad snapshot helper used by smoke tests | diagnostic/scoped transport verifier, not gameplay architecture | | RTS web/Electron client | map renderer plus command sender | thin local Verse client using same state loop as Unity | | Unity shell | still has legacy gameplay shell pressure | input/rendering only, local Verse command submitter and state renderer | @@ -141,14 +146,15 @@ clients must converge their local Verse state from typed facts. 0. boundary inventory -> 1. typed policy schema -> 2. command gate - -> 3. deterministic two-role proof + -> 3. deterministic Commander/Pilot candidate proof -> 4. scoped live Verse document exchange - -> 5. live committed fact publication - -> 6. live committed fact import + -> 5. Commander candidate/fact publication + -> 6. live Pilot candidate selection and Commander finality -> 7. thin client mode parity -> 8. Unity gameplay shell demolition -> 9. leases - -> 10. future witness/quorum modes + -> 10. server + mixed authority product proofs + -> 11. witness-authoritative mode ``` Each stage consumes only artifacts from earlier stages. If stage 6 needs a @@ -164,7 +170,7 @@ starts. The active lane is: ```text -Stage 6 live fact import +Stage 6 Pilot candidate selection/finality -> Stage 7 client parity -> Stage 8 Unity shell demolition ``` @@ -176,15 +182,15 @@ Blocked lanes: client. - Do not optimize Unity rendering around mirrored gameplay hierarchy until Stage 8 decides what remains of Unity's local shell. -- Do not add witness/quorum machinery until the trusted co-op fast path is - clean. +- Do not add witness-authoritative machinery until Starbridge mixed authority + and Arena server authority pass live/restart/replay proofs. Stage gates: | Gate | Must prove | Must not introduce | | --- | --- | --- | | Transport gate | Scoped typed documents can move between live daemons | broad hot-loop shard sync | -| Fact gate | Remote committed facts mutate local state through the same authority router | viewport-as-gameplay-state | +| Fact gate | Pilot candidates correct Commander provisional state through typed selection before one final log append | peer committed-fact import, viewport-as-gameplay-state | | Client gate | Unity and Electron submit the same typed command documents | client-specific gameplay behavior | | Demolition gate | Unity has no authoritative gameplay state | new Unity-side simulation branches | @@ -196,12 +202,13 @@ either a verifier, a demolition step, or a documented dependency fix. Stage 6 depends on: - Stage 4 scoped document transport; -- Stage 5 committed command fact documents; +- Stage 5 Commander candidate/fact documents; - authority router decisions from Stage 1; - daemon command/tick accounting from Stage 2; - the two-role smoke harness from Stage 3. -Stage 7 depends on Stage 6 and may not invent another command surface. The RTS +Stage 7 depends on Stage 6 and may not invent another operation or candidate +surface. The RTS client's current `command` and `viewport` IPC shape is tolerated only as a diagnostic shell around CultMesh documents until Stage 7 replaces it with typed local Verse submission and local projection reads. @@ -355,9 +362,10 @@ Exit criteria: - Accounted commands are not re-evaluated forever. - The frame exposes the active authority shape for diagnostics. -## Stage 3: Deterministic Two-Role Proof +## Stage 3: Deterministic Commander/Pilot Candidate Proof -Status: implemented through in-process and once-mode daemon proofs. +Status: target corrected; existing two-role command-routing proof is migration +evidence and does not yet prove Pilot-wins reconciliation. Owner: `Aetheria.State.AuthoritySmoke`. @@ -365,31 +373,38 @@ Build: ```text raven-local - runtime: raven-unity - owns: Raven movement/combat claims + role: Pilot prediction daemon + jurisdiction: own ship, assigned nearest environment, assigned engagements starfire-local - runtime: starfire-rts - owns: hostile/RTS claims + role: Commander daemon + owns: default simulation, candidate selection, replay, final log ``` Verifier: -- In-process tick proof: - - Raven-authored Raven movement applies. - - Raven-authored hostile movement rejects. - - Starfire-authored hostile movement applies. - - Starfire-authored Raven movement rejects. -- Once-mode daemon process proof with the same receipt shape. +- Commander and Pilot receive the same immutable tick envelope, prior state + root, versions, inputs, seed position, and jurisdiction epoch. +- Matching candidates record agreement and finalize once. +- A valid differing Pilot candidate inside jurisdiction replaces the Commander + candidate; Commander provisional dependents replay from that fact boundary. +- Wrong-subject, wrong-epoch, invalid, and late Pilot candidates reject without + changing finalized state. +- A fact has exactly one Pilot jurisdiction holder; reassignment activates at a + named future tick rather than packet arrival order. +- Restart during an open window reproduces the same selected fact and state + root. Only finalized facts can affect score, settlement, or external effects. Demolition target: -- Any test or client path that assumes "local daemon means all authority." +- Peer facts imported as already committed truth. +- Commander results committed and later repaired as an unversioned side effect. +- Pilot authority inferred from client type or local proximity. Exit criteria: -- The same typed policy document loads in both stores. -- Two real daemon processes make opposite decisions deterministically. +- Two real daemon processes reproduce candidate comparison, Pilot-wins mismatch, + Commander replay, late-candidate rejection, and one Commander-persisted log. ## Stage 4: Scoped Live Verse Document Exchange @@ -465,30 +480,32 @@ Notes: as a patch so scoped reads do not delete unrelated local Verse state. - The authority smoke now waits separately for frame receipt visibility and committed fact visibility. -- Stage 6 satisfied the daemon hot-loop requirement through direct scoped typed - fetches. The running daemon now asks a peer only for committed fact documents - and decodes them through the CultNet document registry without opening a - heavyweight replica node on every tick. +- Legacy evidence only: scoped typed fetch proved live daemon transport without + opening a heavyweight replica node on every tick. Asking peers for committed + facts does not satisfy corrected Stage 6 and must leave the gameplay mutation + path; Pilot output must arrive as pre-finality candidate evidence. -## Stage 5: Live Committed Fact Publication +## Stage 5: Candidate And Final Fact Publication -Status: implemented for local commands and live peer visibility. +Status: committed-command publication exists as migration evidence; Pilot +candidate and Commander-finality publication remain to build. -Owner: daemon tick result publisher. +Owner: Pilot candidate publisher and Commander final fact publisher. Build: -- `AetheriaRuntimeCommittedCommandFactDocument` -- deterministic fact id/record key; -- applied fact creation for applied commands; -- rejected fact creation for policy-rejected commands; +- one typed fact envelope shared by Commander candidates, Pilot candidates, and + Commander-finalized facts; +- deterministic slot/candidate/final record keys; +- jurisdiction, validation, comparison, correction/replay, and finality + receipts; - CultCache and CultNet registry entries; -- publication from the daemon tick after local command handling. +- Commander-finalized publication after candidate selection. Allowed flow: ```text -tick result + original typed command -> committed command fact document +Commander tick envelope -> Commander/Pilot candidates -> selected final fact ``` Demolition target: @@ -497,107 +514,98 @@ Demolition target: Verifier: -- Live daemon peer can scoped-sync applied and rejected facts from another - daemon. -- Fact documents contain source runtime, source daemon, source frame, subject, - claim kind, command kind, outcome, and typed command payload. +- Commander can scoped-read Pilot candidate evidence for an open slot. +- Published envelopes contain producer, session/versions, state/input roots, + jurisdiction epoch, tick/substep, subject, engagement/claim, seed position, + candidate kind, payload hash, and typed payload. Exit criteria: -- Every applied local command has a fact. -- Every policy-rejected local command that was observed has a fact. -- Facts are durable enough for a peer that samples later. +- Every accepted Pilot simulation result has a candidate receipt. +- Every selected result is finalized and authored exactly once by the Commander + daemon. +- Provisional candidates are inspectable evidence but cannot impersonate final + facts. Verification: -- `Aetheria.State.AuthoritySmoke` proves that Starfire can observe Raven's - applied Raven movement fact and Raven's rejected hostile fact. -- `Aetheria.State.AuthoritySmoke` proves that Raven can observe Starfire's - applied hostile fact and Starfire's rejected Raven fact. +- Current evidence, not target proof: `Aetheria.State.AuthoritySmoke` can observe + applied/rejected command facts between peers. The corrected proof must observe + Pilot candidate publication, Commander selection/replay, and one finalized + Commander fact. -## Stage 6: Live Committed Fact Import +## Stage 6: Live Pilot Candidate Selection And Commander Finality -Status: implemented for the trusted co-op slice and verified by the live -two-daemon smoke. +Status: target corrected; the implemented peer committed-fact importer is an +obsolete convergence experiment and must not remain a gameplay mutation path. -Owner: fact importer and daemon peer loop. +Owner: Commander candidate selector/finality loop. Build: -- Poll/sync peer committed fact documents through Stage 4 scoped transport. -- Re-run authority policy using the fact's source runtime, subject, and claim. -- Reject unauthorized or malformed facts without local mutation. -- Keep imported fact ids so facts are idempotent. -- Publish import receipts. -- Use a direct scoped fact fetch or long-lived peer state reader. Do not open a - new full `AetheriaStateNode` replica in the tick hot path. -- Keep import bookkeeping in frame state until the durable import ledger exists: - - imported fact ids; - - rejected imported fact ids; - - duplicate imported fact ids; - - cumulative imported fact ids; - - cumulative rejected imported fact ids. +- Publish immutable tick envelopes and jurisdiction assignments before Pilot + simulation. +- Receive Pilot candidate facts through Stage 4 scoped transport while their + deterministic finality window remains open. +- Validate identity, versions, state/input roots, jurisdiction epoch, payload, + and rules before comparison. +- Compare typed semantic facts, not serialization bytes or rendered outcomes. +- On a valid mismatch, select the Pilot candidate and deterministically replay + Commander provisional dependents from the fact boundary. +- Persist one finalized Commander log plus comparison/veto/replay receipts. Allowed flow: ```text -remote committed fact -> local authority router -> tick runner import mode +Pilot candidate -> jurisdiction/validation gate -> typed comparison + -> Commander correction/replay when different -> one finalized fact ``` -Implementation slices: +Migration evidence: -1. Done: `AetheriaVerseReplica.FetchScopedSnapshotAsync` fetches a filtered raw - CultNet snapshot without opening a replica state node. -2. Done: `AetheriaVerseReplica.FetchScopedDocumentsAsync` decodes only the - requested typed documents through the CultNet document registry. -3. Done: the daemon peer loop reads peer committed facts with the direct scoped - fetch primitive and no broad replica open/pull. -4. Done: each peer fact is routed through - `AetheriaRuntimeCommittedFactImporter`. -5. Done: import, duplicate, reject, cumulative import, and cumulative reject - receipts are published into the daemon frame. -6. Done: the daemon publishes the final post-import frame locally after peer - import so clients read the converged state, not the pre-import tick. -7. Done: the live two-daemon smoke requires local state convergence: - - Starfire sees Raven movement through local state. - - Raven sees Starfire hostile movement through local state. - - unauthorized cross-role facts are rejected. +- Scoped typed fetch and two-daemon process harnesses are reusable. +- `AetheriaRuntimeCommittedFactImporter`, import counters, and peer facts that + mutate local state encode the wrong finality model. Replace them with + candidate evidence, selection receipts, and one Commander-owned log. Demolition target: - Remote viewport queries used as multiplayer gameplay state. - Any per-tick peer import path that pulls or replaces the whole shard. +- Any imported peer document that arrives labelled as canonical committed + gameplay truth. Verifier: -- Raven local Verse imports Starfire hostile/RTS facts. -- Starfire local Verse imports Raven pilot facts. -- Unauthorized hostile facts from Raven are rejected and leave local state - unchanged. -- Duplicate facts do not replay. +- Commander finalizes immediately outside Pilot jurisdiction. +- Commander results inside Pilot jurisdiction remain provisional until the + deterministic window/barrier closes. +- Valid Pilot mismatch wins and triggers deterministic Commander replay. +- Duplicate, late, invalid, and stale-epoch candidates do not replay or rewrite + finalized state. - Diagnostics on failure include: - source daemon id; - peer endpoint; - requested schema ids; - fetched fact count; - - imported/rejected/duplicate fact ids; + - candidate/selected/rejected/duplicate fact ids; - child daemon stdout/stderr tail. Exit criteria: -- Starfire sees Raven movement through local state, not remote viewport reads. -- Raven sees Starfire hostile updates through local state, not remote viewport - reads. -- The live smoke passes with two daemon processes and no broad snapshot in the - runtime path. +- Both runtimes observe one Commander-finalized state root and fact log. +- Same checkpoint, tick envelope, candidate chronology, and versions reproduce + the same mismatch selection and replay result. +- The live smoke passes with two daemon processes and no committed-peer-fact + import path. Notes: -- The verifier caught a useful distinction: accepting a movement fact is not the - same thing as applying movement locally. The smoke now seeds movement-capable - entities and checks X/Z movement, matching the runtime's current RTS axes. -- Stage 6 proves the trusted co-op fact lane only. It does not grant clients - permission to use remote viewport queries as gameplay state. +- Pilot prediction authority is not direct canonical mutation. The Pilot result + wins a valid mismatch, but the Commander daemon performs correction/replay and + appends the selected finalized fact. +- No provisional fact may affect Hangar settlement, score, rewards, or another + irreversible external effect. ## Stage 7: Thin Client Mode Parity @@ -949,14 +957,15 @@ Starbridge lease examples: an overheated ally, turret, or base module. - A pilot with equipped repair gear authors a bounded repair-support claim for a damaged structure or ship. -- Construction anchoring is a typed pilot claim over an RTS-authored ghost, not - a client-local completion event. +- Construction anchoring is a typed Pilot candidate over a Commander-authored + ghost inside an assigned jurisdiction, not a client-local completion event. Verifier: -- Starfire can lease close-combat response authority to Raven. -- Lease expiry returns authority to the base policy. -- Lease decisions are visible in receipts/diagnostics. +- Starfire can assign close-combat prediction jurisdiction to Raven. +- Assignment expiry returns the slot to Commander-only simulation at a named + future tick. +- Jurisdiction assignments are visible in receipts/diagnostics. Demolition target: @@ -964,15 +973,34 @@ Demolition target: Exit criteria: -- Leases are policy state, not gameplay special cases. +- Jurisdictions are policy state, not gameplay special cases. -## Stage 10: Future Witness/Quorum Modes +## Stage 10: Server And Mixed Authority Product Proofs -Status: deliberately deferred. +Status: required before witness authority. + +Verifier: + +- Arena proves server-authoritative live play, restart, deterministic replay, + human/AI-equivalent operations, and negative client-mutation checks. +- Starbridge proves same tick envelopes, jurisdiction epochs, validated + Pilot-wins mismatch, Commander correction/replay, late-candidate rejection, + restart during an open window, and one Commander-finalized log. +- Both use the shared fact/document/operation schemas and publish active + authority diagnostics. + +Demolition target: + +- Any mode-specific fact identity, replay contract, or authority side channel. + +## Stage 11: Witness-Authoritative Mode + +Status: deliberately deferred until Arena server authority and Starbridge mixed +authority pass live, restart, replay, and negative-authority proofs. Owner: future CultNet/CultMesh authority module. -Build later: +Build later from the shared fact/candidate/finality contract: - simulation observations; - quorum candidates; @@ -983,10 +1011,12 @@ Build later: Verifier: -- New modes plug into the same policy seam: +- Witness authority plugs into the same policy seam without mode-specific state + or operation schemas. ```text -operation/observation -> policy resolution -> authority decision -> commit path +operation/observation -> typed candidate/evidence -> policy resolution + -> finality decision -> one canonical commit path ``` Demolition target: @@ -996,7 +1026,7 @@ Demolition target: Exit criteria: -- Trusted co-op remains fast while additional authority modes become selectable +- Starbridge mixed authority remains fast while witness authority becomes selectable policy strategies. ## Immediate Work Queue @@ -1037,11 +1067,14 @@ Design sources: Starbridge release spine: - One RTS chair and one to four pilot clients defend one daemon-authored base. -- The RTS chair owns the operational interface: base systems, power, shields, - fabrication, drones, turrets, marks, construction ghosts, wave tools, and - station support. -- Pilots own embodied field execution: movement, combat, docking/refit, salvage, - anchoring, cooling, repair, cargo/equipment, survival pods, and local marks. +- The Commander player owns Verse authorship outside active Pilot jurisdiction: + base systems, power, shields, fabrication, drones, turrets, marks, + construction ghosts, wave tools, station support, and all unassigned world + facts. +- Each Pilot owns prediction/candidate authority for its own ship, explicitly + assigned nearest environment entities, and explicitly assigned combat + engagements. The Commander daemon still produces the default candidate for + those slots and owns correction/replay and final persistence. - Station stock, docked ships, loadouts, cargo, pricing, support gear, and recovered technology are shared Verse state. They are not Unity scene state, Electron UI state, or a sidecar gameplay API. @@ -1233,14 +1266,15 @@ Product proof: Authority proof: - Raven and Starfire each launch their own CultMesh/CultNet Verse node. -- Shared state converges through typed documents and committed facts, not a - remote viewport query or an Electron sidecar gameplay API. +- Shared state converges through typed documents, Pilot candidate evidence, and + Commander-finalized facts, not peer-imported committed facts, a remote + viewport query, or an Electron sidecar gameplay API. Allowed build: - launch harness for one Unity-shaped client and one Electron-shaped client; -- scoped peer sync checks for session, station/refit, authority policy, - committed facts, and latest projections; +- scoped peer sync checks for session, station/refit, authority policy, Pilot + candidates, Commander selection/finality, and latest projections; - diagnostics for source daemon, runtime id, policy id, and rejected facts. Demolition target: @@ -1264,7 +1298,8 @@ Product proof: Authority proof: -- Commander claims are policy-scoped state, not hardcoded RTS ownership. +- Commander player authorship is policy-scoped outside Pilot jurisdiction; + Commander-daemon simulation/finality is invariant, not hardcoded UI ownership. Allowed build: @@ -1294,8 +1329,9 @@ Product proof: Authority proof: -- Pilot claims are typed facts that the RTS runtime can project and reason - about; the outcome is not hidden in Unity scene objects. +- Pilot results are typed candidate facts for an assigned jurisdiction. The + Commander runtime can compare them, correct/replay on mismatch, and publish + one finalized result; the outcome is not hidden in Unity scene objects. Allowed build: @@ -1417,9 +1453,9 @@ Current staged work order: | 1 | Finish S2 station/refit read parity. `current_entity`, `current_docking`, inventory rows, source slot identity, and loadout templates are already moving; split remaining station stock, docked ship, cargo, equipment, pricing, and refit eligibility reads into canonical typed documents or derived projections as appropriate. | `AetheriaRuntimeGameViewportDocuments`, `AetheriaClient`, Unity inventory/trade menus, generated TS bindings. | `verify-stage7d-unity-parity.ps1`, `Aetheria.State.Verify`, `AuthoritySmoke`, `npm run check:rts-bindings`, Unity compile. | Menu logic may adapt Unity controls, but station/refit truth may not come from manager-global observed cargo, docked ship, catalog, pricing, or loadout caches. | | 2 | Add S2 typed refit operation parity. Dock, undock, select docked ship, equip, store, transfer, restore loadout, and purchase/refit become named operations with typed receipts. | `AetheriaRuntimeDaemonOperationClient`, `AetheriaRuntimeVerseClient`, generated TS operation bindings, Unity/Electron facade methods, daemon operation validation. | Cross-client operation smoke: one runtime issues an allowed refit operation, the other observes the committed result through local Verse state. | Delete or quarantine any public client path that mutates inventory/loadout through operation strings, raw item bags, UI-local rules, or Unity checkpoint rewrites. | | 3 | Contract Unity to a render/input shell for S2. Inventory/trade UI can remain Unity UI, but every gameplay read/write goes through typed state. | `InventoryMenu`, `InventoryPanel`, `TradeMenu`, `ActionGameManager`, `ZoneRenderer` shims. | Stage 7D verifier rejects direct manager-global refit reads, public manager gameplay reads, new command buses, and Unity-only command paths. | Remaining facade-object bridges must validate daemon keys against typed projections and name the Stage 8 projection/native slab that deletes them. | -| 4 | Prove 7E.1 two-client local Verse parity. Raven Unity and Starfire Electron are peers with separate local Verse nodes, not one runtime viewing another runtime's projection. | launch harness, scoped peer sync, committed facts, session/refit/authority projections, diagnostics. | Raven/Starfire smoke: both clients see the same session, station/refit state, controlled entities, policy id, and fact receipts through local Verse state. | No test may prove co-op by reading a remote viewport or one daemon's debug projection as gameplay state. | -| 5 | Build exactly one S3 commander verb. First candidate: target mark. Second candidate: construction ghost. | RTS facade, daemon command gate, typed mark/ghost documents, Unity HUD/map projection, authority diagnostics. | Raven/Starfire smoke: Starfire authors the commander claim, Raven observes the committed fact locally, and policy diagnostics name the claim kind and author runtime. | No browser-owned enemy/base gameplay, no HTTP sidecar gameplay surface, and no hardcoded "RTS owns this" branch outside policy. | -| 6 | Build exactly one S4 pilot field verb. First candidates: salvage pickup or construction anchoring. | Unity input facade, daemon command gate, typed support/salvage/anchor documents, RTS projection panel. | Raven/Starfire smoke: Raven authors the pilot claim, Starfire observes the committed fact locally, and daemon validation checks range/equipment/ownership/scenario state. | No Unity-only interaction result another runtime cannot inspect through typed state. | +| 4 | Prove 7E.1 two-client local Verse parity. Raven Unity and Starfire Electron are peers with separate local Verse nodes, not one runtime viewing another runtime's projection. | launch harness, scoped candidate transport, Commander-finalized facts, session/refit/authority projections, diagnostics. | Raven/Starfire smoke: both clients see the same session, station/refit state, controlled entities, policy/jurisdiction epoch, candidate receipts, and Commander-finalized facts through local Verse state. | No test may prove co-op by reading a remote viewport, importing a peer fact as already committed, or using one daemon's debug projection as gameplay state. | +| 5 | Build exactly one S3 commander verb. First candidate: target mark. Second candidate: construction ghost. | RTS facade, daemon command gate, typed mark/ghost documents, Unity HUD/map projection, authority diagnostics. | Raven/Starfire smoke: the Commander player authors the operation outside Pilot jurisdiction, the Commander daemon simulates/finalizes it, Raven observes the final fact, and diagnostics name authorship plus finality owner. | No browser-owned enemy/base gameplay, no HTTP sidecar gameplay surface, and no hardcoded "RTS owns this" branch outside policy. | +| 6 | Build exactly one S4 Pilot prediction path. First candidates: salvage pickup or construction anchoring. | Unity input facade, Pilot simulation candidate, Commander candidate selector/replay, typed support/salvage/anchor documents, RTS projection panel. | Raven/Starfire smoke: Raven publishes an in-jurisdiction candidate that differs, Starfire validates/selects it, Commander provisional state replays, and both observe one Commander-finalized fact. | No Unity-only result, direct Pilot log write, or peer committed-fact import. | | 7 | Move S5 loss/recovery and S6 waves/rewards into daemon state after field verbs prove the loop. | survival pod, wreck, recovery, replacement ship, wave, hostile intent, boss, victory/defeat, recovered-tech, score documents. | Complete Starbridge loop smoke from a state/catalog seed with both clients attached. | Death/respawn, hostile behavior, boss rewards, score, and wave resolution leave Unity scene ownership. | | 8 | Add S7 leases and diagnostics only after claim shapes are boring. | authority policy docs, bounded lease docs, claim diagnostics, client overlays. | Trusted-host policy smoke plus diagnostics showing owner, lease, expiry, and deny reason for each active claim. | Do not close the door to quorum, server-authoritative, operator-finality, or mergeable modes, but do not build them into the first fast co-op path. | @@ -1476,8 +1512,8 @@ Product staging from the Starbridge design: | B | Electron and Unity can render the same tactical map slice from local state. | XY gravity viewport, union-of-controlled-units object viewport, selected object/status reads | remote gameplay viewport reads, fog rules hidden in UI | both clients call equivalent facade reads for map and selection panels. | | C | A docked pilot can inspect station stock, ships, cargo, equipment, pricing, and loadout options. | current entity, current docking, station refit, station stock, loadout template, inventory projections | support gear behavior, survival pods, commander build orders | station/refit UI truth comes from typed projections, not manager-global Unity facade graphs. | | D | Either client can perform one refit/purchase/transfer operation and the other observes the committed result. | typed S2 operations, daemon validation, committed facts, cross-client smoke | broad inventory editor, client-local item rules | no public client refit API accepts operation strings or untyped payloads. | -| E | The RTS chair can issue one commander tactical verb that pilots can see. | target marks, construction ghost placement, fabrication/build order documents, base system projections | leases, full wave controller | Raven observes Starfire-authored commander facts through local Verse state. | -| F | A pilot can execute one field support verb that the RTS chair can see. | salvage, anchor, cooling, repair, support gear validity, local combat/support claim docs | pod recovery, boss rewards | Starfire observes Raven-authored pilot facts through local Verse state. | +| E | The RTS chair can issue one commander tactical verb that pilots can see. | target marks, construction ghost placement, fabrication/build order documents, base system projections | leases, full wave controller | Raven observes the Commander-finalized result of a Starfire-authored operation through local Verse state. | +| F | A pilot can execute one field support verb that the RTS chair can see. | salvage, anchor, cooling, repair, support gear validity, local combat/support claim docs | pod recovery, boss rewards | Starfire observes the Commander-finalized result selected from a Raven Pilot candidate through local Verse state. | | G | Losing a ship creates recoverable state instead of Unity object death authority. | survival pod, wreck, recovery, replacement ship, dock recovery operations | meta-progression, episode cadence | both clients inspect pod/wreck/recovery facts and Unity no longer owns death/respawn truth. | | H | A complete 20-30 minute Starbridge loop can run from daemon state. | waves, hostile intent, boss state, victory/defeat, recovered technology, score | witness quorum, adversarial peers | the first scenario can be played as RTS plus pilots with all outcomes represented as typed Verse facts. | | I | Authority policy becomes designer-visible diagnostics. | bounded leases, claim-kind ownership, denial reasons, active authority overlays | consensus or quorum implementation | changing policy changes who may author claims without changing operation schemas. | @@ -1490,8 +1526,8 @@ Release-facing gates from the design: | Session gate | A daemon-only seed describes the base, commander role, pilot roles, station stock, available ships, first wave forecast, and starting scenario. | The first release cannot depend on a Unity scene to define the defended base. | | Map gate | Electron and Unity render equivalent XY tactical projections: gravity influences, visible objects, controlled-unit visibility union, selected object status, and authority diagnostics. | The RTS chair and pilots are two distances from the same crisis, not two separate games. | | Station gate | A docked pilot can inspect, equip, store, transfer, purchase/refit, and restore loadouts from typed station state in both clients. | Support gear, ship loss, and salvage economy all depend on station stock being boring and shared. | -| First commander verb | Build exactly one RTS-authored tactical verb, preferably target mark before construction ghost. | It proves Starfire-authored facts appear to Raven without hiding base gameplay in the browser client. | -| First pilot verb | Build exactly one Raven-authored field verb, preferably salvage pickup or construction anchoring before cooling/repair. | It proves pilot field labor appears to the RTS chair without leaving Unity-only outcomes behind. | +| First commander verb | Build exactly one RTS-authored tactical operation, preferably target mark before construction ghost. | It proves Commander-finalized results of Starfire operations appear to Raven without hiding base gameplay in the browser client. | +| First pilot verb | Build exactly one Raven Pilot-candidate field result, preferably salvage pickup or construction anchoring before cooling/repair. | It proves Pilot candidate selection and Commander finality appear to the RTS chair without leaving Unity-only outcomes behind. | | Loss/recovery gate | Ship loss creates pod, wreck, recovery, replacement, and stock facts readable by both clients. | Player survival and material loss are central to Starbridge; Unity object lifetime cannot own that truth. | | Wave loop gate | Hostile intent, boss defeat, recovered technology choice, score, and victory/defeat are daemon facts. | The 20-30 minute co-op loop must be playable without client-local wave code. | | Episode gate | Scenario unlocks, score currency, recovered-tech pools, and faction/scenario metadata are content documents. | Live episodes must be authored against typed state instead of requiring new client code. | @@ -1745,25 +1781,27 @@ Stage: 9, after 7E proves parity. Build: -- policy documents that assign claim kinds to RTS, pilot, daemon, or lease - authority; -- bounded interest leases for close defense, drone reaction envelopes, repair, - cooling, and construction anchoring; +- policy documents that assign Commander-player authorship and Pilot candidate + jurisdiction while keeping Commander-daemon finality invariant; +- bounded jurisdiction assignments for nearest environment entities and combat + engagements; - diagnostics that show active policy, current lease holder, expiry, and denial reason. Demolition target: -- hardcoded "RTS owns X" or "Unity owns Y" branches outside policy. +- hardcoded "RTS owns X" or "Unity owns Y" branches outside policy; leases that + grant direct canonical mutation instead of candidate eligibility. Verifier: -- changing policy changes which runtime may author a claim without changing the - operation schema or client UI code. +- changing policy changes Commander-player authorship or Pilot candidate + jurisdiction without changing fact, operation, or client UI schemas; + Commander-daemon finality remains invariant. Unlocks: -- future witness/quorum authority modes. +- Stage 10 server/mixed product proofs, then Stage 11 witness authority. ### Slice S8: Shared Hangar And Progression Documents @@ -1925,9 +1963,10 @@ npm run build The focused Stage 4/5 verifier passes: live daemons can expose scoped frames and committed facts to an external verifier. -Stage 6 now passes for the trusted co-op fact lane: live daemons fetch scoped -typed peer facts, import authorized facts through the local authority router, -publish post-import frames, and converge in the two-daemon smoke. +The old Stage 6 peer committed-fact lane passes as migration evidence, but it no +longer satisfies the target. Starbridge requires Pilot candidates to enter +before Commander finality, validated mismatches to correct/replay Commander +provisional state, and one Commander-owned canonical log. The current known risk is Stage 7 client parity. RTS/Electron no longer exposes public generic `command` or `viewport` APIs, the TS contract metadata is diff --git a/Aetheria.State/docs/verse-authority-policy.md b/Aetheria.State/docs/verse-authority-policy.md index f6e0dd218..1fb5c36ff 100644 --- a/Aetheria.State/docs/verse-authority-policy.md +++ b/Aetheria.State/docs/verse-authority-policy.md @@ -8,30 +8,37 @@ use the same policy boundary: typed operation -> resolve subject and claim kind -> resolve authority mode from the active Verse policy --> apply, forward, defer, or reject +-> build immutable tick envelope and jurisdiction assignment +-> simulate Commander default candidate +-> accept, compare, defer, or reject Pilot candidate +-> correct/replay Commander provisional state on validated mismatch +-> commit one finalized fact ``` -The first implementation is intentionally fast for trusted co-op. It does not -build quorum consensus on the hot path. It compiles the active policy document -and authority leases into an in-memory routing table, then tests incoming typed -commands before simulation. +Starbridge does not use quorum consensus on the hot path. The Commander daemon +simulates everything by default and owns the canonical log. Policy assigns +prediction jurisdiction to Pilot daemons for their own ship, daemon-assigned +nearest environment entities, and assigned combat engagements. This is the +reverse of ordinary server-authoritative client prediction: when a valid Pilot +result disagrees, the Commander daemon corrects to the Pilot result. ## Policy Modes The policy schema names the authority shapes Aetheria needs without requiring all of them to be implemented at once. -- `any-trusted-runtime`: trusted co-op mode. Any runtime with the active Verse - rules may author matching claims. -- `host-authoritative`: only the configured host runtime may author matching - claims. -- `delegated-runtime`: one of the configured runtime ids may author matching - claims. -- `owning-runtime`: the runtime that owns the subject may author matching - claims. This is schema-level intent for now; ownership resolution must be - supplied by the runtime before this mode is enabled. -- `interest-lease`: a runtime with a matching unexpired lease may author - matching claims. +- `any-trusted-runtime`: a trusted runtime may submit matching operations or + candidates. It does not gain canonical finality. +- `host-authoritative`: only the configured host runtime is eligible to produce + matching candidates or operations. +- `delegated-runtime`: one configured runtime may submit matching operations or + candidates. +- `owning-runtime`: the runtime assigned to the subject is eligible to produce + matching candidates or operations. This is schema-level intent for now; + ownership resolution must be supplied before this mode is enabled. +- `interest-lease`: a runtime with a matching unexpired lease may produce a + prediction candidate for the leased fact slots. The lease grants neither log + mutation nor finality. - `witness-quorum`: eligible witnesses publish observations; policy forms a candidate; authority commits a fact. This is not implemented in the current Aetheria hot path. @@ -42,6 +49,14 @@ all of them to be implemented at once. Unsupported modes fail closed with an explicit policy rejection. This keeps the schema open without pretending future authority structures already exist. +Eligibility never implies direct canonical-log mutation; the active fact +strategy still decides candidate comparison and finality. + +The implementation order is product-grounded: Terminus proves local authority, +Arena proves server authority, and Starbridge proves Commander-default, +Pilot-corrected mixed authority. Witness-authoritative operation begins only +after the Arena and Starbridge configurations pass live, restart, deterministic +replay, and negative-authority proofs through this same typed policy seam. ## Command Claims @@ -73,38 +88,57 @@ The command executor only sees authorized commands. It should remain boring: validate payload shape, mutate the run, emit intents. Authority decisions belong to the policy router. -## Trusted Co-Op Shape +## Starbridge Prediction Jurisdiction -The default Aetheria policy is permissive trusted co-op: - -```text -* - * - any-trusted-runtime -``` - -Raven/Starfire tests can then tighten this without changing gameplay systems: +The Commander daemon owns default simulation and finality for every fact slot. +Policy narrows the slots where a Pilot candidate can correct that default: ```text entity.player.raven - movement,targeting,combat + simulation-fact.* delegated-runtime: raven-unity -entity.rts.starfire. - movement,targeting,ai - delegated-runtime: starfire-rts - -entity.hostile. - ai,movement,targeting - delegated-runtime: starfire-rts - -entity.hostile. - close-combat-response,combat +environment.assignment.raven.* + simulation-fact.* interest-lease + +engagement.assignment.raven.* + simulation-fact.* + delegated-runtime: raven-unity + +* + simulation-fact.* + host-authoritative: commander-daemon ``` -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. +The Commander player owns operation/claim authorship for everything outside +Pilot jurisdiction; the Commander daemon still simulates the default result for +all slots. Nearest-entity and engagement assignments are Commander-published +typed state with an epoch and exact effective tick. A Pilot cannot calculate a +larger jurisdiction from its divergent local positions. Overlap is resolved to +one holder before the tick, never by packet arrival order. + +Commander and Pilot candidates are comparable only when they share the exact +session, simulation/content version, state root, run/jurisdiction epoch, +tick/substep, fact kind, canonical subject, engagement/claim id, causal input +set, and deterministic seed position. Equality is typed semantic equality for +that fact kind. Presentation differences do not veto gameplay facts. + +Inside an open Pilot slot, the Commander result is provisional. A valid +different Pilot result wins; validation proves producer identity, versions, +state/input roots, jurisdiction, causal inputs, schema, and gameplay invariants. +It does not require agreement with the Commander output. The Commander daemon +rolls back or corrects and deterministically replays dependent provisional +state. + +The tick envelope names the deterministic barrier/deadline policy and eligible +candidate set. The finality receipt records how that set closed. If no eligible +Pilot candidate is present when the barrier closes, the Commander result +stands. Replay consumes the recorded candidate/selection chronology rather than +re-running wall-clock or packet timing. Restart preserves whether a slot is +open or closed plus its eligible candidates. Late candidates cannot rewrite +final history. Disconnect or seat transfer changes jurisdiction only at a +committed future epoch. ## Simulation Host Packaging @@ -125,33 +159,18 @@ The important boundary is not the executable. It is the policy document: ```text runtime CultMesh client - -> typed command/proposal document - -> Verse authority policy - -> simulation-capable runtime lease/host - -> committed facts and local projections + -> typed operation or prediction candidate + -> Verse jurisdiction and candidate gate + -> Commander default simulation and candidate selection + -> deterministic correction/replay when Pilot wins + -> one finalized fact log and local projections ``` 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 - movement,targeting,combat - delegated-runtime: raven-unity - -entity.hostile. - ai,movement,targeting - delegated-runtime: starfire-rts - -* - inventory,economy,system - host-authoritative -``` - -This keeps every client honest: it can run CultMesh and submit typed commands, -but the daemon-shaped simulation host owns the committed game state. +same Commander-daemon simulation/finality role and publish the same typed +documents. The client shell remains a renderer/input surface. Pilot simulation +may also be embedded beside its renderer, but its durable output is candidate +evidence; only the Commander daemon appends finalized state. ## Current Local-Mirror Constraint diff --git a/README.md b/README.md index 22966aaf8..f855f2399 100644 --- a/README.md +++ b/README.md @@ -55,8 +55,8 @@ 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 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 +single-player roguelike runs, Commander-default/Pilot-corrected 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. @@ -72,12 +72,16 @@ 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. -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 +Terminus is the single-player roguelike mode. Starbridge is the co-op RTS/pilot +mode, using Commander-daemon default simulation with jurisdictional Pilot +correction. 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 +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). +Together they prove local-authoritative, mixed-authority, and +server-authoritative CultMesh configurations; witness-authoritative operation +is the next authority milestone after the latter two are proven. ## Developer Navigation diff --git a/docs/aetheria-current-codebase-model.md b/docs/aetheria-current-codebase-model.md index 8e5aa8ee0..1249de686 100644 --- a/docs/aetheria-current-codebase-model.md +++ b/docs/aetheria-current-codebase-model.md @@ -587,8 +587,11 @@ The current UI direction is Eve/CultUI: The architectural note in `Aetheria.State/docs/verse-daemon-shape.md` still describes optional ecosystem indexing, but it is not the Aetheria session path. -Aetheria clients connect directly to the daemon's advertised CultMesh endpoint; -directly configured daemon peers exchange typed committed facts there as well. +Aetheria clients connect directly to the daemon's advertised CultMesh endpoint. +Current configured daemon peers also exchange typed committed facts there; this +is obsolete migration behavior, not target Starbridge authority. Pilot output +must instead enter as candidate evidence before Commander finality, and peer +committed facts must not mutate gameplay state. Odin may index the provider only when explicitly enabled. Eve/CultUI defines presentation, and the daemon owns side effects. diff --git a/docs/aetheria-perfect-machine-map.md b/docs/aetheria-perfect-machine-map.md index 654c70f7c..02f661b9e 100644 --- a/docs/aetheria-perfect-machine-map.md +++ b/docs/aetheria-perfect-machine-map.md @@ -13,11 +13,18 @@ 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. Terminus uses local-daemon authority, -Starbridge uses typed mixed authority, and Arena uses server authority; all +Starbridge uses Commander-default simulation with jurisdictional Pilot +correction, 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. +The product modes deliberately pressure different CultMesh authority shapes: +Terminus local authority, Arena server authority, and Starbridge +Commander-default/Pilot-corrected mixed authority. Witness-authoritative +operation is the next configuration after Arena and Starbridge prove shared fact identity, +finality, replay, and negative authority invariants. + ## Current Mechanism - `Aetheria.State.Daemon` is the first-class local Verse daemon host. It opens @@ -3440,7 +3447,7 @@ 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. Starbridge session bootstrap must enter -through shared Hangar deployment, typed mixed-authority policy, the active mode +through shared Hangar deployment, typed candidate/jurisdiction/finality 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/aetheria-verse-client-contract.md b/docs/aetheria-verse-client-contract.md index 0b8f78260..52cd1fd01 100644 --- a/docs/aetheria-verse-client-contract.md +++ b/docs/aetheria-verse-client-contract.md @@ -88,12 +88,14 @@ Verse, bind an Eve state pointer, or expose a native slab view. That decision is CultMesh infrastructure. The caller gets a typed domain value and diagnostics when it asks for them. -Client input follows the same rule. When a runtime has authority or prediction -rights, mutating the managed typed document is the ergonomic target; CultMesh -debounces, routes, records the prediction, and reconciles against canonical -state. When a runtime does not have direct write authority, it submits a typed -operation handle that the daemon validates and applies to the same canonical -document. +Client input follows the same rule. Ordinary and Arena clients submit typed +operations and reconcile to authoritative state. In Starbridge Pilot +jurisdiction the prediction policy is reversed: the Commander daemon publishes +the default provisional result, a Pilot daemon submits a candidate derived from +the same tick envelope, and a valid mismatch corrects/replays Commander state +to the Pilot result before finality. Mutating a managed typed document may be +the ergonomic prediction surface, but it never appends canonical state +directly. Outside Pilot jurisdiction, the Commander result stands. Unity should treat the client as its Aetheria-facing runtime surface. It can still use Burst, DOTS rendering, and native views for presentation, but the state diff --git a/docs/cultmesh-feature-implementation-guide.md b/docs/cultmesh-feature-implementation-guide.md index 2b328520d..4b5d64c3a 100644 --- a/docs/cultmesh-feature-implementation-guide.md +++ b/docs/cultmesh-feature-implementation-guide.md @@ -94,7 +94,9 @@ Simulation state should take two or three steps: ```text 1. Define the canonical typed document in the shared runtime package. 2. Let the daemon mutate/publish that document as the authority for the Verse. -3. Read or modify the same managed document from clients according to authority policy. +3. Read the same managed document from clients; submit typed operations or, + inside Starbridge Pilot jurisdiction, typed prediction candidates according + to authority policy. ``` Anything beyond that needs a clear reason. Performance-sensitive entity @@ -343,11 +345,13 @@ public sealed class AetheriaRuntimeStationSupportDocument The daemon validates operations, applies ticks, and publishes the canonical document into the Verse. Unity does not own gameplay truth, but Unity does not need a separate client-facing copy either. CultMesh handles sync. If the client -has prediction authority, local changes to the managed document are -predictions; reconciliation corrects them without requiring feature code to -manually shuttle deltas. +has ordinary prediction rights, local changes are provisional and reconcile to +authority. Starbridge Pilot jurisdiction deliberately reverses that mismatch +policy: a valid Pilot candidate corrects and replays Commander provisional +state before finality. In neither case does the managed client document append +the canonical log directly. -### Step 3: Read Or Mutate Through The Managed Handle +### Step 3: Read Or Submit Through The Managed Handle Unity reads the same document through the managed typed handle: @@ -356,8 +360,8 @@ var support = client.State.Reactive(); var cooling = support.Current?.CoolingReserve ?? 0; ``` -When the client does not have direct simulation authority, it submits a typed -operation: +When the client has no prediction jurisdiction for a fact, it submits a typed +operation to the applicable authority: ```csharp client.Operations.Submit(new AetheriaRuntimeDeploySupportDroneOperation @@ -371,10 +375,11 @@ client.Operations.Submit(new AetheriaRuntimeDeploySupportDroneOperation The daemon validates and applies the operation. The next published document is the authoritative result. -When the client has prediction or simulation authority, the ergonomic target is -even simpler: modifying the managed reactive document records a prediction, -debounced by the update frame, and CultMesh routes/reconciles it according to -the Verse authority policy. +When a Starbridge Pilot has prediction jurisdiction, modifying the managed +reactive document records a candidate keyed to the Commander tick envelope. +CultMesh routes it to the candidate selector. Matching state records agreement; +a valid mismatch selects the Pilot result and triggers Commander replay. Late, +invalid, or out-of-jurisdiction candidates cannot rewrite finalized state. ## SoA For Hot Paths diff --git a/docs/game-modes-and-progression.md b/docs/game-modes-and-progression.md index 1a8594de8..8f9a56f9d 100644 --- a/docs/game-modes-and-progression.md +++ b/docs/game-modes-and-progression.md @@ -20,10 +20,15 @@ deploy -> fly -> fight -> salvage -> dock/refit -> choose risk -> continue ``` `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, +in one shared session. Starbridge uses commander-default simulation with +jurisdictional pilot correction. The Commander daemon simulates the entire +session and owns canonical finality, persistence, and publication. Each Pilot +daemon independently predicts facts for its own ship, its daemon-assigned +nearest environment entities, and its assigned combat engagements. When a +validated pilot result differs from the Commander daemon's provisional result, +the pilot result wins and the Commander daemon corrects and deterministically +replays from that boundary. The Commander player owns Verse authorship for +everything outside pilot jurisdiction. It uses the same player identity, hull catalog, loadout templates, fitting rules, and Hangar progression as Terminus while adding the shared base, RTS projection, waves, fabrication, support systems, and recovered-technology decisions. @@ -98,11 +103,30 @@ 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. +- **Starbridge:** the Commander daemon owns default simulation and canonical + persistence. Pilot daemons have prediction authority plus mismatch priority + inside typed jurisdictions; the Commander daemon reconciles to a validated + differing pilot result rather than correcting the pilot to its own result. - **Arena:** the authoritative server decides all gameplay state; humans and AIs submit operations and consume observations. +Each mode is also a concrete CultMesh authority proof: + +- **Terminus proves local authority:** one local daemon owns simulation and + finality while clients remain replaceable lowerers. +- **Arena proves server authority:** remote human and AI controllers submit to + one authoritative simulation server. +- **Starbridge proves mixed authority:** the Commander daemon owns the default + simulation and final log while validated Pilot predictions correct facts in + explicitly assigned jurisdictions. + +After Starbridge mixed authority and Arena server authority are proven in live +play and deterministic replay, the next authority milestone is +**witness-authoritative** operation. Witness authority must reuse the same typed +fact slots, inputs, versions, evidence, finality, and replay contracts. It is +not permission to fork gameplay state or build consensus machinery before the +three product modes work. + 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 @@ -115,8 +139,9 @@ deployment and settlement receipts, not inferred by a menu. 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. +2. **Starbridge:** one commander and one pilot share a base/session, disagree on + one pilot-jurisdiction fact, select the pilot result, replay Commander state, + and converge on one finalized 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. @@ -185,8 +210,9 @@ simulation smokes as Arena product proof. 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. +8. Starbridge jurisdiction changes without changing fact/document schemas; + diagnostics expose assignment epoch, provisional Commander result, pilot + result, mismatch decision, replay boundary, and finalized result. 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, @@ -195,3 +221,11 @@ simulation smokes as Arena product proof. 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. +12. A Commander result inside active pilot jurisdiction cannot become externally + final before the prediction window closes. A valid differing pilot result + replaces it; stale, wrong-epoch, out-of-jurisdiction, or invalid pilot + results cannot rewrite finalized history. +13. Terminus, Starbridge, and Arena publish diagnostics identifying their active + CultMesh authority configuration. Witness-authoritative work begins only + after the Starbridge and Arena proofs pass without mode-specific state or + operation schemas. diff --git a/docs/original-game-migration-matrix.md b/docs/original-game-migration-matrix.md index 830f1bf38..000191ee3 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` | 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 | +| 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 uses Commander-default simulation and persistence plus jurisdictional Pilot prediction; a validated Pilot mismatch corrects and replays provisional Commander state before external finality. 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 execute headlessly through the production simulation and operation gates. The shared Hangar/Deployment/Settlement owner and Starbridge candidate/finality protocol are adopted design but not yet implemented | implement one canonical Hangar/deployment/settlement spine; launch ordinary Terminus; prove Starbridge same-tick envelopes, jurisdiction epochs, Pilot-wins mismatch, Commander replay, late-result rejection, and one final log; prove deterministic 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 | diff --git a/docs/original-game-specification.md b/docs/original-game-specification.md index b83fafbd6..cbbb5f315 100644 --- a/docs/original-game-specification.md +++ b/docs/original-game-specification.md @@ -93,10 +93,14 @@ 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. +Starbridge uses Commander-daemon default simulation with jurisdictional Pilot +correction. The Commander daemon simulates every fact and owns canonical +finality and persistence. Pilot daemons independently predict facts for their +own ship, daemon-assigned nearest environment entities, and assigned combat +engagements. A validated mismatch resolves toward the pilot result; the +Commander daemon corrects and replays its provisional state. Outside pilot +jurisdiction, the Commander player owns Verse authorship and the Commander +daemon result stands. No Pilot daemon owns a private persistent world. Terminus, Starbridge, and Arena share the canonical Hangar, deployment, catalog keys, fitting rules, and saved loadout templates described in diff --git a/docs/renderless-aetheria-architecture.md b/docs/renderless-aetheria-architecture.md index dd777b626..2129a84c6 100644 --- a/docs/renderless-aetheria-architecture.md +++ b/docs/renderless-aetheria-architecture.md @@ -16,16 +16,25 @@ lowering semantics, and Aetheria clients are conformance targets. Aetheria should become a renderless, policy-authoritative game whose three product modes share one simulation and progression spine. -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 +Terminus uses sole local-daemon authority. Starbridge uses Commander-default +simulation with jurisdictional Pilot correction. Arena uses sole server +authority. In Starbridge, the Commander daemon owns the full default simulation, +canonical log, persistence, and publication. Pilot daemons independently +predict facts inside assigned jurisdictions; a validated mismatch corrects the +Commander daemon to the pilot result before external finality. 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. +The modes are the authority runway: Terminus proves local authority, Arena +proves server authority, and Starbridge proves Commander-default/Pilot-corrected +mixed authority. Witness-authoritative operation follows only after the server +and mixed configurations pass live, restart, replay, and negative +authority proofs through the same typed fact contract. + 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 @@ -38,18 +47,21 @@ daemon-authored contract, without inheriting Unity scene authority. ## Authority Map Owner: -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. +Typed mode policy owns authority and jurisdiction assignment. The Terminus local +daemon and Arena server own all simulation and finality in their sessions. In +Starbridge, the Commander daemon owns simulation scheduling, the default +candidate for every fact, canonical selection, deterministic correction/replay, +persistence, receipts, and publication. A Pilot daemon owns the candidate result +for its assigned jurisdiction when that validated result differs. The shared +Hangar remains a separate authoritative typed aggregate outside live sessions. Inputs: -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. +The Commander daemon reads canonical CultCache/CultMesh state, catalog data, +authority policy, player operations, clock input, deterministic seeds, and asset +manifests. Before each Starbridge prediction window it publishes an immutable +tick envelope and jurisdiction table. Pilot candidates must use that same prior +state root, versions, inputs, and seed position. Simulation transactions may +invoke the embedded Ymir spatial kernel, but Ymir does not become a state owner. Outputs: The provider publishes typed state documents, committed facts, operation receipts, @@ -67,14 +79,32 @@ 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. +client-specific command routers must not write canonical gameplay state. A +Pilot daemon cannot expand its own jurisdiction, directly append the canonical +log, or correct a finalized fact. The Commander daemon cannot bypass an open +pilot prediction window, publish provisional results as final, or preserve its +own result after a valid in-window Pilot mismatch. + +Starbridge finality: +Every comparable fact slot is keyed by session, simulation/content versions, +run and jurisdiction epochs, tick/substep, fact kind, subject, engagement or +claim identity, and causal input-set hash. Jurisdiction is Commander-published +typed state effective at a named tick. Commander results inside Pilot +jurisdiction remain provisional for a deterministic tick/barrier window. A +schema-valid, rules-valid, in-jurisdiction Pilot mismatch replaces the Commander +candidate; dependent provisional state is replayed from that boundary. Silence +or a missed window leaves the Commander candidate. Late results are evidence, +not repairs. Only finalized facts may affect canonical gameplay checkpoints, +score, Hangar settlement, or irreversible external effects. Open candidate +windows and their evidence are durably journaled as protocol state so restart +does not discard or promote a dispute. 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. +through typed operations, scoped Pilot candidates, or an explicitly declared +mergeable-state strategy. None is a generic gameplay-document write path. Deletion line: Before adding new client behavior, delete or demote any path that lets a client