t27_paper_claims: recompute the numbers printed in the GoldenFloat, Golden Ruler and TNF papers

[gHashTag]

Refs gHashTag/t27#10392

What

This PR adds a new tool, t27_paper_claims. It recomputes the numbers printed in the GoldenFloat paper (arXiv:2606.05017), the Golden Ruler paper (arXiv:2606.09686) and the TNF paper, and returns one row per claim:

• printed value
• recomputed value
• verdict: fits, does not fit, or not checkable

Two filters narrow the rows: paper (all/gf/ruler/tnf/repo) and verdict (all/fits/misfit/unchecked).

• wasm/paper_claims.wasm and wasm/paper_claims_table.mjs are generated on the Railway lab from specs/numeric/paper_claims.t27 (gHashTag/t27, PR for #10392). The recipe and sha256 values are in wasm/BUILD.
• server.mjs gains the loader and the tool (+43 lines). smoke.mjs gains 4 checks.

Checked

node smoke.mjs on the lab printed "all checks passed" across 27 tools. The 4 new checks:

• totals: 34 fit, 8 do not, 3 not checkable
• Golden Ruler: prints 12 clusters, the catalog has 13
• TNF: kappa ratio printed 1.683, exact arithmetic gives 1.682
• the paper filter keeps the 23 TNF rows, 15 of which fit

🤖 Generated with Claude Code

[tri-claw]

Summary by t27-bees

This PR adds a t27_paper_claims tool that recomputes 45 numeric claims from three papers (GoldenFloat, Golden Ruler, TNF) using exact integer arithmetic in a WASM module built from specs/numeric/paper_claims.t27. The tool exposes filters by paper and verdict, and includes smoke tests verifying known mismatches (e.g., Golden Ruler prints 12 clusters but catalog has 13; TNF kappa ratio printed as 1.683 vs. exact 1.682).

Worth a look

• server.mjs:89 — Number(W.row_recomputed(i)) converts a WASM u64 (returned as BigInt) to Number. This loses precision silently for values > 2⁵³. Current test data stays well below that, but the spec declares row_recomputed(u32) -> u64 and nothing prevents future claims from exceeding safe-integer range.
• server.mjs:73 — pcWasm._initialize() is called but _initialize is not listed in wasm/BUILD exports (only row_verdict, row_recomputed, count_verdict are). If the Zig build doesn't export it automatically, the first tool call will crash.
• server.mjs:80–84 — The U_SCI3 formatter hardcodes e- (negative exponent): `e-${v % 1000}`. The encoding packs mantissa*1000 + exponent; if any claim ever uses a positive exponent it will be printed with a spurious minus sign. Only one row (index 8, p=1.04e-3) uses this unit today.
• wasm/BUILD:324–325 — The sha256 for paper_claims_table.mjs (4dd53304b17ce5af…) is recorded, but the file is committed directly in this PR. If the generated file is ever regenerated without updating the hash, the build doc will be misleading.
• server.mjs:70–71 — No error handling around readFileSync / WebAssembly.Module / Instance. A missing or corrupt paper_claims.wasm will throw uncaught, taking down the tool (and potentially the server if the error propagates). Other tools in this codebase may share the pattern, but it's a reliability gap here.

---

_{Read: 7 files, +269 -1, the whole diff. Head f71ae42. Model: openai-compatible/nvidia/nemotron-3-ultra-550b-a55b. Commands: @t27-bees review | summary | help | pause | resume. Free for every repository.}

[gHashTag]

t27_paper_claims already has a row in specs/t27mcp/tool_schema.t27 (gHashTag/t27#10446, used by #24). When this rebases on #24, drop the inline inputSchema: schema.mjs supplies it from the row, and a tool without a row stops the server at start.

🤖 Generated with Claude Code