| Filename | Latest commit message | Latest commit date |
|---|---|---|
89687fceb4
Eve refuses to build a command intent for a surface that has not
advertised a command boundary and receipt schema, and the intent it
builds now carries the operation under operation.operationId. The
browser sample did neither: the click was refused inside the page and
the checkpoint saw only a 30 s timeout on the receipt.
The C# provider now publishes its gamecult.eve.provider_advertisement.v1
document with the surface's worldInteraction, and the page leases that
and hands it to the lowering as `provider`. The provider owns the
declaration; the page reads it rather than restating it. The command
sink reads intent.operation.operationId.
The checkpoint now forwards the page's console and pageerror output.
"CultMesh browser operation is required." took one run to find with it
and had been a bare timeout without it.
scripts/verify-eve-getting-started.ps1 -EveRoot ..\Eve (Eve main)
-> Eve getting-started verification passed: clean .NET and TypeScript
artifacts, DOM and headless convergence, real Chromium and C#
clients, Odin discovery, authority-bound routes, receipts,
persistence, and route replacement.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
||
| .. | ||
| browser | ||
| EveBrowserNetworkSample.csproj | ||
| Program.cs | ||
| README.md | ||
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
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.