feat(web): the demo runs in the visitor's browser

[synacktraa]

The live demo ran in a serverless function behind /api/demo/run. It runs in the visitor's browser now, and the function, its concurrency flag and the EventSource are gone.

What the guard was actually doing

let running = false;   // module scope

On an always-on server there is one process, one running, and that line means what it says. On Vercel the route is a serverless function: each instance loads the module fresh and gets its own copy, and Vercel answers a queue by starting more instances. So it failed in both directions at once. Within one instance it turned the second visitor away from a run that is mostly idle on the network. Across instances it capped nothing, which is the only place a cap would have mattered.

What broke under load was friendbot. Every run funds a fresh owner through it, it rate limits by source address, and every function shared one Vercel egress. A hundred browsers are a hundred addresses, so moving the run removes the pressure rather than managing it. The 60 second function ceiling on this plan goes with it.

What had to be true first

the seller must let a page read its headers	the commit before this one
the SDK must not import node:crypto	#20, 0.1.2
the wasm must not need fetching	it does not: the hash is a constant the dashboard already deploys from

ensureWasm fetched the release asset only to hash it. GitHub sends no cross-origin headers on release assets, and the hash is what a deployment needs anyway, so WASM_HASH moved into params.ts and write.ts imports it from there instead of declaring its own. Buffer.from(agent.rawPublicKey()) became the raw key, which is what write.ts has always passed.

npm run bake was the route's other caller. It drives the generator directly now, through the same liveDeps the page uses, so there is one implementation instead of a server one and a browser one.

The import is dynamic. Most of the page's weight is stellar-sdk, and a reader who never presses the button should not carry it.

Verification

npm run bake completed eight rows in Node, both refusals, no server.

In the browser, the first attempt looked like a success and was not. The click landed before hydration, so the page simply rendered the baked run back, and the rows were right because they were a real run - the identical swap figure and transaction hash to baked.json are what gave it away. Worth recording, because the screenshot would have passed.

The real run produced a new contract and new hashes, and Horizon was asked directly rather than the page believed:

tx      3982e1d0b5268f40bf4272f73395a38a40a20b448a72c2da9fb7e0c0c5ae6385
        successful: true
source  GCS6COEVWTJ7MMZJL7XKIPKLDIONZLI6CTELQ6GW5447XIKNM4RQLXKB   the facilitator
move    0.0100000 USDC  from CBRRQC6ADHF7...  to GA4ND56VAGBN...   the contract, not an account

Both refusals appeared, the button returned to an enabled state, and no request touched an origin of ours.

32 unit tests, 27 Playwright tests, tsc --noEmit clean.

Deploying this

The seller has to ship before or with the web. Until it sends the headers, a browser can fetch it and still not read the terms, and the demo stops at the row that asks what the seller wants. They are separate Vercel projects and separate manual deploys.

🤖 Generated with Claude Code