286a9af389
Unscoped npm names are unclaimed and open to dependency confusion; cultcache-ts was already @gamecult/cultcache-ts. package.json names, intra-repo dependencies, package-lock, import specifiers (src, tests, samples, docs/start, first-call docs test), the workspace list in run-typescript-workspaces, the verify-eve module map and package READMEs now use the scoped names. Directory names, workspace paths in CI and release tag prefixes are unchanged. Historical cut docs and past CHANGELOG entries keep the old names. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
3.2 KiB
Eve Browser + Headless Counter
This is the real-process continuation of samples/eve-two-runtime:
- one C# provider owns a durable
.cccounter, the Eve surface, command idempotency, and canonical receipts; - one real Chromium page leases both documents through
@gamecult/cultmesh-browserand lowers the provider-owned Eve surface; - one retained C# headless client discovers the provider through the same Odin identity, observes the typed counter and canonical receipt ids, survives the provider route replacement, and invokes through the generic CultMesh client without application transport or reconnect code;
- one separate local Odin fixture answers the canonical CultMesh Verse catalog over binary CultNet WebSocket messages;
- one wrong-authority provider is deliberately advertised on a better-priority route, and both clients must ignore it because the route is bound to another runtime;
- the browser and C# clients speak the same binary CultNet schema-v0 WebSocket messages through the authenticated host adapter.
The provider registers typed commands through CultNetOperationServer.
Application code receives CultNetOperationContext<TRequest> and returns a
typed receipt; it does not parse base64, switch on wire envelopes, or construct
correlation responses. The counter's durable transaction still owns
idempotency and state mutation. The provider opens one public CultMeshNode;
it does not assemble a parallel CultCache/CultNet database host by hand.
Run the proof from the CultLib repository:
pwsh -File ./scripts/verify-eve-getting-started.ps1
The wrapper first proves clean package consumption, then runs this real-process
checkpoint. Run node scripts/verify-eve-browser-network.mjs --eve-root ../Eve
directly only to diagnose the network layer. Browser discovery is portable:
CHROME_PATH wins when configured, then common Chrome/Chromium/Edge locations
and Playwright's installed Chromium are checked.
The verifier clicks the Eve button twice with one idempotency key and requires
one state transition. It then restarts the provider on a different physical
port, updates the local Odin fixture, and requires both retained clients to
rediscover and resubscribe. The C# client invokes the second command through
CultMeshClient.InvokeAsync; Chromium observes the resulting count and both
clients observe both canonical receipt ids.
The retained C# client then sends 10,000 typed no-op operations over the same
real WebSocket session. The gate records p99 latency, throughput, managed heap,
and private memory, and rejects more than 8 MiB of post-GC managed growth or a
250 ms p99. The no-op provider handler stores no receipt history, so persistence
growth cannot impersonate a client leak.
The fixture speaks the production Verse-catalog contract; a deployment smoke
against the full Odin daemon remains a separate infrastructure gate.
The odin fixture defaults to this sample's Verse, but its --verse-id,
--verse-name, --authority-runtime-id, --transport-version, and
--rules-hash arguments can advertise another real provider during a product
route-rotation witness. The provider endpoint remains data owned by Odin; the
consumer still connects only by stable Verse and provider identity.