用途：报告 Honey 的基准测试记分板，即 bench/ 中按任务层级（代码、面向用户、智能体间）提交的质量与 token 结果。强调只报告已提交的可复现结果，不使用猜测值或每次会话的数字，也不使用可能与 bench 漂移的内嵌副本。
主要能力：在使用时从已提交记录重新计算，而非凭记忆背诵；优先使用原始记录而非渲染后的表格（渲染会过时，记录不会）。命令：cd bench && node src/report.js --stamp full-opus48 --by-type。离线运行，无 API 花费。将 --stamp full-opus48 换成 full-gpt55 可得跨提供商数据，去掉 --by-type 可得整套结果。Hive 交接数字见 bench/hive/RESULTS.md。
报告方式：层级表格需简洁，包含 Δ LOC 与 Δ output，各自附 p 值，判定为 win/loss/tie，以及每个变体的测试通过率。层级拆分本身就是发现——在代码和交接上最深，在面向用户上输出为统计平局（polish 例外）。以 Δ LOC 开头：它直接衡量 Lever 1，而输出 token 混合了代码与周围文字，两者会分离。
规则：引用任何 delta 都必须附 p 值，将 (ns) 结果称为平局而非胜利。每个数字都是按任务配对的 median；arm 总量之比不可引用。文字渲染（bench/README.md、results/combined.md）是次要的；若与新的 --stamp 重算不一致，以重算为准，并说明渲染已不同步。质量是平局而非增益，这是诚实的说法，不要升级。成本/CO₂ 节省是建模的反事实而非实测，属于 honey-eco 并有其标注，此处不要陈述美元节省。若被问及本仓库的数字：bench 在固定任务套件上衡量该技能，而非用户代码库——应提供 cd bench && npm run bench，不要外推。一个诚实的说明：23 个作者编写的任务，judge 噪声——客观测试通过列才是可信的正确性信号。切勿复活旧的不可复现的 92%/78%/73% / −57%/−65%/−70% 数字，或已被取代的 arm 总量数字（−49% 代码、−15% 汇总），见 bench/METHODOLOGY.md。