[NN0X]

Phase 2 of the overhaul replaces the demo mocks with the real C++, compiled to WebAssembly.

What's in it

• scripts/build-wasm.sh (npm run wasm):
  • Fetches Brutus-Encryption and CiceroTokenizer at pinned commits and compiles them unmodified with Emscripten.
  • Small bindings in wasm/ expose brutusText, ciceroTokenize and friends.
  • The output in public/wasm/ is committed, so building the site doesn't need Emscripten: Brutus 140 KB, Cicero 120 KB, plus the 380 KB dictionary that loads with the demo.
• Demos: the nvim demo tabs and the cicero / brutus shell commands now run the real code. Cicero shows each token's text and ID, and the dictionary size.
• Cicero runs in a Web Worker with a timeout. See the first finding below for why.

Two findings in the C++ (your repos are untouched)

1. Cicero loops forever on characters its dictionary has no single-character token for. That includes digits, -, ' and any non-ASCII letter: native cicero -i "great 5" never returns, and neither does cicero -i "zażółć". This is presumably why the old site stripped input in PHP. Here, input is filtered against the loaded dictionary, and the page says what it left out. The worker timeout is a second line of defence. A fix in Cicero itself would be to skip, or map to an unknown token, any character with no dictionary entry.
2. Brutus gives different ciphertexts on x86 and ARM. genPseudouniqueInteger casts out-of-range doubles to unsigned long long, which is undefined behaviour. ARM and WebAssembly saturate, while x86-64 does not. So the WebAssembly build matches what the Raspberry Pi produced on the old site, but an x86 build of the same commit prints something else. A fix in Brutus would be an explicit, well-defined conversion (for example fmod into range, or saturation), followed by documenting that existing ciphertexts change on one of the two platforms.

Checks

• npm run verify: lint, type check, 21 tests, build.
• tests/wasm.test.ts runs both WebAssembly builds in Node and compares them with native clang++ builds of the same commits.
  • Cicero matches the native build exactly.
  • Brutus matches a native build compiled with ARM-style saturating casts. I confirmed the x86-vs-ARM difference above that way, since I have no ARM machine here.
• Browser check on the built site:
  • The Cicero tab returns the native IDs for "great product would buy again" (48480 36936 35723 23378 38441). Input with digits and Polish letters is filtered without hanging.
  • Brutus's output in the page matches the expected value byte for byte.
  • The shell commands give the same results.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Nq9YrSAj91fqZFLCbH3CUM

---

Generated by Claude Code