| Filename | Latest commit message | Latest commit date |
|---|---|---|
| .. | ||
| 01-persist-typed-state.md | ||
| 02-connect-by-identity.md | ||
| 03-publish-an-eve-surface.md | ||
| 04-keep-a-typescript-provider-alive.md | ||
| README.md | ||
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.
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.