What
The README states "Fastest server" and "best-looking graphics" as established fact. Nothing in the repo measures either, and there is no comparison target. The docs already contain an honesty note conceding that one of the two is an aspiration — the README does not reflect it, and the server claim has no such note at all.
The claims
README.md:3
> **The best open-core MMORPG engine.** WoW-inspired, fully original IP, built by AI
> agents, in Rust. Fastest server, best-looking graphics, greatest DX for the agents
> that build it.
docs/initial-idea/README.md:5
... with the best-looking graphics and the fastest server.
docs/initial-idea/00-overview.md:4
Best-looking graphics, fastest server, greatest DX for the agents that build it.
What actually exists to back them
One benchmark, and it is not about the server:
crates/content-schema/benches/load-bench.rs <- the only bench in the repo
crates/content-schema/Cargo.toml:18 [[bench]]
CI never runs it. content-validation.yml:46-47 compiles it and stops:
- name: Compile content-schema benchmarks
run: cargo bench --package omm-content-schema --no-run
--no-run builds the harness and exits. So the single benchmark in the tree has never produced a number in CI, and no workflow measures server throughput, tick latency, CCU, or netcode at all. There is also no second implementation to be "fastest" relative to — the claim names no baseline, so it is not falsifiable as written.
The repo already concedes half of this
docs/initial-idea/03-tech-stack.md:30 carries an explicit "Client honesty note":
Bevy's renderer is not yet AAA-fidelity out of the box; "best-looking graphics" is an engineering goal we push via wgpu, PBR, and high-quality AI-generated PBR assets. Godot (with the Rust GDExtension) is the documented fallback if visual fidelity outpaces Bevy before launch.
That is the right posture, and it is undermined by the README asserting the same thing as fact three files away. There is no equivalent note for "fastest server", which is the stronger and less supportable of the two claims.
Why this is worth fixing rather than shrugging at
developerz-ai/wurk went through exactly this correction this week. Its README claimed to be faster than Sidekiq; measurement showed it runs at 0.45x-0.86x, and the claim was removed (wurk#366, and wurk#375 for the docs that were missed). Its CLAUDE.md now carries a standing rule:
do not add a "faster" claim to the README, site, or llms.txt until that doc's numbers support it
The same standard applied here means either publishing numbers or softening the claim. A superlative that no benchmark supports is a liability in a project whose pitch is explicitly "gamers-first, not extraction-first" — the honesty is the differentiator.
Options
- Soften to intent, matching the existing client-honesty note: "built for speed" / "performance is a design goal", with the aspiration stated as such.
- Publish numbers. Add a server benchmark with a named baseline, run it in CI rather than
--no-run, and keep a docs/benchmarks.md the way wurk now does.
- Keep the claim and accept that the first person to measure it decides whether it was true.
Option 1 costs a sentence and is honest today. Option 2 is the one that eventually earns the claim.
Also worth a look while here
cargo bench --no-run in CI means the benchmark compiles but is never executed, so a benchmark that panics or regresses arbitrarily would pass. If the intent was only to stop bench code from rotting, that is a legitimate cheap gate and worth a comment saying so; if the intent was to measure, it is not doing that.
What
The README states "Fastest server" and "best-looking graphics" as established fact. Nothing in the repo measures either, and there is no comparison target. The docs already contain an honesty note conceding that one of the two is an aspiration — the README does not reflect it, and the server claim has no such note at all.
The claims
What actually exists to back them
One benchmark, and it is not about the server:
CI never runs it.
content-validation.yml:46-47compiles it and stops:--no-runbuilds the harness and exits. So the single benchmark in the tree has never produced a number in CI, and no workflow measures server throughput, tick latency, CCU, or netcode at all. There is also no second implementation to be "fastest" relative to — the claim names no baseline, so it is not falsifiable as written.The repo already concedes half of this
docs/initial-idea/03-tech-stack.md:30carries an explicit "Client honesty note":That is the right posture, and it is undermined by the README asserting the same thing as fact three files away. There is no equivalent note for "fastest server", which is the stronger and less supportable of the two claims.
Why this is worth fixing rather than shrugging at
developerz-ai/wurkwent through exactly this correction this week. Its README claimed to be faster than Sidekiq; measurement showed it runs at 0.45x-0.86x, and the claim was removed (wurk#366, and wurk#375 for the docs that were missed). Its CLAUDE.md now carries a standing rule:The same standard applied here means either publishing numbers or softening the claim. A superlative that no benchmark supports is a liability in a project whose pitch is explicitly "gamers-first, not extraction-first" — the honesty is the differentiator.
Options
--no-run, and keep adocs/benchmarks.mdthe way wurk now does.Option 1 costs a sentence and is honest today. Option 2 is the one that eventually earns the claim.
Also worth a look while here
cargo bench --no-runin CI means the benchmark compiles but is never executed, so a benchmark that panics or regresses arbitrarily would pass. If the intent was only to stop bench code from rotting, that is a legitimate cheap gate and worth a comment saying so; if the intent was to measure, it is not doing that.