RuView 验证体系实战指南确定性 SHA-256 证明、ADR-028 见证包与 MEASURED 声明诚信门禁【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView导读本文围绕 RuView 仓库中 verify 技能文档 展开系统讲解 RuViewWiFi-DensePose 无摄像头 WiFi CSI 感知系统prove everything证明一切的验证纪律通过确定性 SHA-256 证明Trust Kill Switch证明信号处理管线真实可复现通过 ADR-028 见证包把一次发布固化成可单命令复核的机器可验证证据并通过ruview_claim_check对任何报告、README、PR 与模型卡做 MEASURED / CLAIMED / SYNTHETIC 声明诚实性检查。读完本文你将掌握如何在 RuView 中运行验证命令、解读 VERDICT 输出、生成与复核见证包以及如何让自己的精度声明经得起门禁检查。一、验证文化的源头为什么 RuView 需要证明一切RuView 是一个通过商品 WiFi 的 Channel State InformationCSI推断粗粒度姿态、存在性与生命体征的系统核心定位是不是摄像头。正因为感知结果来自间接信号任何精度数字都可能被夸大项目也因此曾被质疑为AI 拼凑物AI-slop。作为回应RuView 建立了一条不可妥协的规则见 harness 操作说明 CLAUDE.md 与 守卫实现 guardrails.js任何被引用的精度数字必须标注MEASURED并指明可复现证据、CLAIMED或SYNTHETIC姿态 PCK 只能以相对 mean-pose 基线的增量形式引用且必须基于无泄漏的 held-out 划分否则基线本身就能让一个不可用的模型看起来很强任何报告 / PR / 模型卡发布前都要跑ruview_claim_check它专门拦截未标注的数字与项目已撤回的完美精度表述固件只有在真实芯片上捕获到boot log才算硬件验证通过仅凭编译通过不能合并或发布。这套纪律被落成代码verify技能所描述的三种验证手段——确定性证明、见证包、声明诚信检查——正是上述规则的可执行形态。其中ruview_verify、ruview_claim_check两个工具同时以 CLI 动词npx ruview verify/npx ruview claim-check和 MCP 服务器工具npx ruview mcp start两种方式暴露注册表见 tools.js 工具注册表。二、确定性证明Trust Kill Switch一条命令戳穿它是假的2.1 原理把管线是真的变成可证伪的测量ruview_verify的核心是运行 archive/v1/data/proof/verify.pyTrust Kill Switch信任杀死开关。其设计初衷写在脚本头注释里如果有人说公开演示是 mock 的那么它是假的应该是一个可证伪、可测量的论断。验证流程为从sample_csi_data.json加载已发布的参考 CSI 信号合成信号由generate_reference_signal.py生成仅用于验证管线确定性把每一帧送入生产环境的真实处理器CSIProcessor.preprocess_csi_data()与CSIProcessor.extract_features()从src/core/csi_processor.py直接 import不是测试替身做特征提取把所有特征输出序列化为规范化字节表示计算整个特征输出的 SHA-256与expected_features.sha256中发布的目标哈希比对输出VERDICT: PASS或VERDICT: FAIL。脚本会在 [0/4] 阶段打印SOURCE PROVENANCE来源溯源用inspect.getfile()输出CSIProcessor、CSIData、CSIFeatures的实际绝对路径以及 numpy/scipy 版本让任何人都能肉眼确认导入的是生产模块而非测试桩。2.2 跨平台哈希稳定性的工程细节SHA-256 的比特级相等只在同一 CPU 微架构内成立。verify.py 对此做了两层设计源码注释记录了 issue #560 的排查过程量化层features_to_bytes()先把每个特征数组按HASH_QUANTIZATION_DECIMALS默认 6可用环境变量PROOF_HASH_DECIMALS覆盖做np.round再按小端 float64 打包。原因是 scipy.fft 的 pocketfft 内核在不同 SIMD 后端Intel AVX2/AVX-512 与 ARM NEON上对浮点归约的排序不同而 IEEE 754 只保证单次运算确定、不保证重排后的结合性实测 9 位小数都无法消除分歧6 位ppm 量级相对观测到的 ULP 漂移留出约 6 个数量级余量又远低于信号有意义的变化CSI 相位精度约 1e-3 rad。doppler_shift特征被有意排除在哈希之外——它是峰值归一化的原始频谱出现近并列峰时 argmax 会跨微架构翻转。容差层即使量化后跨微架构的 ~1e-6 相对漂移仍可能落在大幅值 PSD 桶上超出任何固定小数网格的承受力。因此脚本同时提交一份参考特征向量expected_features_reference.npz当比特级哈希不一致时用np.allclose(..., rtol1e-4, atol1e-6)做相对容差比对容差约为观测漂移的 100 倍、信号有意义变化1e-3 rad的 1/10真实回归依然会失败。任一匹配即 PASS。2.3 命令行用法与参数在仓库根目录或任意子目录harness 会向上自动探测仓库根执行python archive/v1/data/proof/verify.py # 运行验证比对已发布哈希 python archive/v1/data/proof/verify.py --verbose # 额外打印特征统计、Doppler 频谱、PSD 细节 python archive/v1/data/proof/verify.py --audit # 扫描生产代码中的 mock/随机模式 python archive/v1/data/proof/verify.py --generate-hash # 重新生成并写入期望哈希谨慎使用各参数行为参数作用无加载参考信号 → 生产管线处理前 100 帧1 秒→ 哈希比对 → 输出 VERDICT--verbose打印每 25 帧进度、末帧各特征 shape/min/max/mean、Doppler 前 8 bin 与频谱熵、PSD 前 8 bin 与峰值频率--audit用audit_codebase()扫描v1/src/排除 testing/tests/test/pycache/.git中的np.random.*、random.random(、unittest.mock、MagicMock、patch(等模式命中即列出[类型] 文件:行号--generate-hash把计算哈希写入expected_features.sha256同时把全精度特征向量写入expected_features_reference.npz随后需不带该参数重新验证--generate-hash必须谨慎使用它只应在有意变更管线数值行为后执行脚本 FAIL 输出会提示To update after an intentional change: python verify.py --generate-hash。如果只是 numpy/scipy 升级导致哈希漂移按技能文档的说法应先重新生成哈希再重新验证。当前仓库中已发布的期望哈希为f8e76f21a0f9852b70b6d9dd5318239f6b20cbcb4cdd995863263cecdc446f7a见 expected_features.sha256。VERDICT 判定逻辑tools.js 中 ruview_verify 处理器子进程退出码为 0 且 stdout 匹配VERDICT:\s*PASS才算成功若未处于 RuView 仓库内、找不到verify.py、或找不到 python则 fail-closed 返回明确原因not_in_ruview_repo/proof_missing/python_missing绝不伪造成功——这与项目整体 fail-closed 姿态一致。三、ADR-028 见证包一次发布一条命令复核3.1 见证包是什么确定性证明只覆盖信号处理管线本身一次完整发布还涉及 Rust 测试、固件源码、crate 版本、npm 产物等多个维度。ADR-028docs/adr/ADR-028-esp32-capability-audit.md将仓库能力审计固化为见证记录witness record——一个时间点的机器可验证公证第三方可以据此逐条确认仓库实际有什么 vs 声明了什么。配套的 WITNESS-LOG-028 记录了审计时刻提交96b01008、Rust workspace 1,031 通过 0 失败 8 忽略、ESP32 串口 COM7 等。3.2 生成与复核命令bash scripts/generate-witness-bundle.sh cd dist/witness-bundle-ADR028-*/ bash VERIFY.sh # 技能文档要求 7/7 PASS技能文档中必须 7/7 PASS对应的是原始七步检查当前 generate-witness-bundle.sh 已扩展生成阶段分 7 步 打包而它写出的VERIFY.sh实际执行8 项检查含 ADR-134 的 CIR 确定性证明全部通过时输出VERDICT: ALL CHECKS PASSED (8/8)。实际以脚本输出为准核心不变所有检查必须全部通过任何一项 FAIL 都要追查。3.3 生成阶段逐步拆解7 步脚本以git rev-parse HEAD取当前提交产物命名witness-bundle-ADR028-commit8位输出到dist/并打成 tar.gz见证文档复制docs/WITNESS-LOG-028.md与docs/adr/ADR-028-esp32-capability-audit.md进包证明系统复制verify.py、expected_features.sha256、generate_reference_signal.py并对约 10MB 的sample_csi_data.json仅提取元数据frame 数、首帧 key、文件大小等生成reference_signal_metadata.jsonRust 测试在v2/下跑cargo test --workspace --no-default-featurestee 出完整日志并用 awk 汇总TOTAL: N passed, M failed, K ignoredPython 确定性证明运行verify.py并经 scripts/redact-secrets.py 脱敏——这是 ADR-110 事故的教训verify.py 校验失败时的 Pydantic schema dump 可能泄漏用户.envDocker token、API key 等打包日志前必须清洗 4b.CIR 确定性证明ADR-134执行 scripts/verify-cir-proof.sh结果写入proof/cir-verify.log并复制expected_cir_features.sha256若 CIR 模块尚未实现则标记 BLOCKED固件清单对firmware/esp32-csi-node/main/下所有.c/.h统计行数并逐一sha256sum生成source-hashes.txt若存在release_bins/s3-adr110、c6-adr110则记录二进制哈希同时写入supported-targets.txtesp32s3 生产节点 / esp32c6 研究目标crate 清单遍历v2/crates/*/Cargo.toml提取版本号生成versions.txt 6b.npm 清单ADR-124在tools/ruview-mcp构建并npm pack出ruvnet/rvagenttarball记录其 SHA-256tarball 本身不进包生成 VERIFY.sh为接收方生成一键复核脚本并在包内对全部文件除 MANIFEST.sha256再打一层MANIFEST.sha256。3.4 VERIFY.sh 的 8 项接收方检查接收方只需进入解包目录执行bash VERIFY.sh脚本即自动核对见证日志与 ADR-028 文档存在期望哈希文件存在并打印哈希值Rust 测试汇总中0 failed否则 FAIL固件源码哈希清单存在打印文件数crate 清单存在打印 crate 数ruvnet/rvagenttarball 的 SHA-256 记录存在npm-pack-failed视为 FAILverification-output.log中存在VERDICT: PASScir-verify.log中存在VERDICT: PASSBLOCKED 占位哈希按 SKIP 放行且expected_cir_features.sha256存在。最终汇总Results: N passed, M failed0 失败则VERDICT: ALL CHECKS PASSED。这正是技能文档所说包含 Rust 测试日志、证明 期望哈希、固件 SHA-256 清单与 crate 版本——接收方一条命令即可重新验证。四、声明诚实性ruview_claim_check如何拦截夸大精度4.1 用法# CLI 方式 npx ruview claim-check --text Our model reaches 92.9% PCK on the test set. npx ruview claim-check --file REPORT.md # 对文件逐行 lint # 空输入是错误而非 PASSfail-closed退出码 2 npx ruview claim-checkCLI 实现见 bin/cli.js--file读入后转为text空文本直接打印错误并以退出码 2 返回有发现时退出码 1。MCP 侧则通过ruview_claim_check工具tools.js以 JSON-Schema 校验text参数空串返回{ ok: false, reason: empty_text }。4.2 判定规则源码拆解guardrails.jsclaimCheck(text)逐行 lint核心逻辑如下指标词识别METRIC_TERMSaccuracy / pck / precision / recall / mpjpe / error rate / detection rate / true positive 等短词map / f1 / auc / iou需词边界且所在行剔除代码 span 与 F/O 编号标签后含数字才算命中避免把 .map文件、F1 是 finding 编号、O1–O9 选项标签 误判为指标。标签要求行中出现百分比或指标词时必须含measured / claimed / synthetic / unvalidated / baseline之一否则记为 medium 级 findingAccuracy claim is not tagged MEASURED / CLAIMED / SYNTHETIC.。MEASURED 必须带可复现证据REPRODUCER_HINTS包含verify.py、witness、mean-pose、held-out、sha256、boot log、pck20 vs、npm pack、cargo test等标了 MEASURED 却没有任何证据词仍记 medium finding。撤回表述拦截high 级PERFECT_PCT_RE100%/100.0%与PERFECT_WORD_REperfect accuracy/flawless/never wrong/never fails命中的行除非同时出现 retract 字样否则直接记 high 级 finding原因注明States perfect/100% accuracy — this is the exact framing the project retracted.返回结构为{ ok, findings: [{ severity, line, excerpt, reason, suggestion }] }summarize()生成一行人类可读摘要如claim-check: PASS — no untagged or overstated accuracy claims.或claim-check: N finding(s) (M high) — accuracy claims need MEASURED/CLAIMED tags a reproducer.。4.3 测试用例给出的正反样例harness/ruview/test/tools.test.mjs 中的测试直接定义了什么是诚实声明输入期望原因Our model reaches 100% accuracy on every pose.拦截撤回的完美精度表述We hit 92.9% PCK on the test set.拦截未标注的百分比精度声明Held-out PCK20 59.5% vs 50% mean-pose baseline 9.4pp (MEASURED, verify.py).通过MEASURED 相对基线 指明 verify.py 复现器Presence detection 97% (MEASURED).拦截标了 MEASURED 但无复现器Count accuracy reached \0.95 in our tests.拦截数字藏在代码 span 中仍构成声明Every accuracy number must be MEASURED against a baseline.通过无数字是规则陈述而非声明F-numbers map to findings./Options O1–O9 are tracked in ADR-263 O2.通过F/O 编号是标签不是指标正确写法的范例Held-out PCK20 59.5% vs 50% mean-pose baseline 9.4pp (MEASURED, verify.py)——同时满足标注来源类型、给出相对基线、指明可复现证据三条要求。五、固件验证的硬标准boot log on real silicon技能文档最后强调固件修复不能仅凭编译通过就宣称硬件验证通过。必须提供真实芯片上捕获的启动日志文档举的范例是v0.8.1-esp32rev-v0.2 验证需同时满足running headless so CSI captures (#1000)——无头运行且 CSI 捕获持续CSI filter upgraded to MGMTDATA——CSI 过滤器升级为同时捕获管理帧与数据帧一次无虚警的 mmwave 探测no-false-detect。这与 tools.js 中ruview_node_monitor的设计呼应该工具打开 ESP32 串口、在时间窗口内统计CSI cb/csi_collector回调数并检测MGMTDATA升级标记csi_callbacks 0才算通过——且需要 Python pyserial 与真实端口缺失时 fail-closed。ruview_node_flash同样坚持即使在 Windows/ESP-IDF 环境且用户confirm: true也只会返回确切的烧录命令而拒绝无人值守自动烧录从机制上杜绝未在真机验证就放行。固件源码清单与二进制哈希的见证则由见证包第 5 步覆盖见 firmware/esp32-csi-node/main。六、把三者串成发布工作流结合 verify 技能文档 与 harness README一次合规的发布或对外声明应走如下闭环改代码 → 跑测试cargo test --workspace --no-default-features见证包会自动收集日志与汇总跑确定性证明npx ruview verify或直接python archive/v1/data/proof/verify.py确认输出VERDICT: PASS若因有意变更导致哈希漂移先--generate-hash再重新验证生成见证包bash scripts/generate-witness-bundle.sh然后进入dist/witness-bundle-ADR028-*/执行bash VERIFY.sh确认全部检查 PASS将产物随发布归档声明前过门禁对任何报告 / README 段落 / PR 描述 / 模型卡执行npx ruview claim-check --file path保证所有精度数字带 MEASURED/CLAIMED/SYNTHETIC 标签、MEASURED 指明复现器、相对 mean-pose 基线引用 PCK、绝不出现100%/完美精度表述固件单独把关涉及固件时附上真实芯片 boot log含 CSI 捕获与 MGMTDATA 升级证据后才允许合并或发布。全程由 harness 的 fail-closed 设计兜底仓库缺失、Python 缺失、二进制缺失、端口缺失、空输入一律返回诚实的否定结果而非编造的成功——这正是证明一切规则从口号到工程实践的完整落地。想深入了解每个环节的实现可继续阅读 verify.py 源码、见证包生成脚本、声明检查守卫 及其 测试用例。【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
