2.1 KiB
CultMesh And Eve Getting Started
This series builds one typed application state and presents it through multiple Eve runtimes. It is maintained as an API acceptance test: examples use public APIs, name the owner of each decision, and include a verification checkpoint.
Run the current clean-consumer checkpoint first:
pwsh -File ./scripts/verify-eve-two-runtime-sample.ps1 -EveRoot ../Eve
From clean CultLib and Eve checkouts, the command installs the package build
dependencies when absent, packs the five TypeScript packages, installs only
those artifacts into an empty temporary project, validates the Eve
surface and receipt, executes one idempotent counter command, proves two local
consumers converge, and reopens the durable .cc store. It is deliberately not
called a networked-browser proof; chapter 3 names that remaining boundary.
Follow the chapters in order:
- Persist typed application state
- Connect a client by stable identity
- Publish one Eve surface to multiple runtimes
- Keep a TypeScript provider alive
The intended application shape is small:
provider daemon -> typed CultCache documents -> CultMesh advertisement
|
+------------------------+--------------------+
| | |
Eve browser EveUnity another lowerer
The provider owns live truth. Eve owns the surface contract. Each runtime owns native projection. CultMesh owns discovery and connection continuity.
Maintenance Contract
- A chapter must not tell an application to choose physical endpoints, build a reconnect loop, or duplicate provider state.
- Code must compile against the package version named by the release that publishes it.
- Every release changing a demonstrated API must update this series in the same pull request.
- A setup step that depends on repository internals is an API defect, not acceptable tutorial folklore.