RuView verify 技能深度解析确定性 SHA-256 证明、ADR-028 见证包与声明诚实性门禁【免费下载链接】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 将商品 WiFi 信号转化为空间智能、生命体征监测与存在检测但传感器结果是否真实始终是这类系统最容易被质疑的问题。本指南基于 harness/ruview/skills/verify.md 展开系统讲解 RuView 的证明一切prove everything验证体系通过确定性 SHA-256 流水线回放Trust Kill Switch证明处理代码真实且可复现通过 ADR-028 见证包Witness Bundle为发布提供一键可复验的凭证并通过ruview_claim_check对任何报告、README 或模型卡中的准确性声明做诚实性门禁。读完本文你将掌握在 RuView 仓库中运行完整验证、签发与校验见证包、以及撰写诚实技术声明的完整实战方法。一、verify 技能定位RuView 的证明一切门禁verify是 RuView 操作型 Harnessnpx ruview内置的六项技能之一onboard、verify、calibrate-room、provision-node、train-pose、cognitum-spaces其元数据定义如下name: verify description: Prove a RuView result is real — run the deterministic SHA-256 proof and the witness bundle (ADR-028), and lint any claim for MEASURED-vs-CLAIMED honesty.技能文件的正文第一句话就给出了它的地位The prove everything skill. Nothing ships as validated without this.证明一切技能。任何东西未经它验证不得发布。它由三个层次构成层次机制解决的问题确定性证明verify.pySHA-256 回放流水线是真实代码还是 mock发布级见证ADR-028 Witness Bundle这个版本的能力是否可被第三方独立复验声明诚实性ruview_claim_check报告里的准确率数字是 MEASURED 还是编造的这三层在 CLI 中分别对应ruview verify、bash scripts/generate-witness-bundle.sh与ruview claim-check命令映射定义于 harness/ruview/bin/cli.js。二、Trust Kill Switch确定性 SHA-256 流水线证明2.1 核心机制ruview_verify会调用 archive/v1/data/proof/verify.py其目标是把它是 mock 的从一句口号变成一个可证伪的、可度量且会因证据而失败的主张。verify.py 的文件头注释概括了完整流程加载已发布的参考 CSI 信号sample_csi_data.json将每一帧送入真实的CSI 处理器做特征提取把所有特征输出收敛为规范的字节表示计算全部特征输出的 SHA-256 哈希与expected_features.sha256中已发布的期望哈希比对打印 PASS 或 FAIL。关键在于第 2 步verify.py 直接导入生产模块而非测试替身verify.py 第 56-57 行 明确注释这些是生产模块不是 test doublefrom src.hardware.csi_extractor import CSIData from src.core.csi_processor import CSIProcessor, CSIFeatures运行时脚本还会通过inspect.getfile()打印三个类的实际源文件绝对路径、numpy/scipy 的路径与版本即SOURCE PROVENANCE源码溯源让任何人当场确认被验证的确实是生产代码。2.2 参考信号与处理器配置参考信号是合成的由generate_reference_signal.py生成固定随机种子其作用纯粹是验证流水线的确定性——验证对象不是信号本身真实而是处理信号的代码真实同一份代码既处理该参考信号也处理线上实时采集verify.py 第 19-22 行 的注释。处理器使用与生产默认一致的关键参数verify.py 第 61-72 行PROCESSOR_CONFIG { sampling_rate: 100, window_size: 56, overlap: 0.5, noise_threshold: -60, # dB human_detection_threshold: 0.8, smoothing_factor: 0.9, max_history_size: 500, enable_preprocessing: True, enable_feature_extraction: True, enable_human_detection: True, }验证会处理参考信号的前 100 帧约 1 秒VERIFICATION_FRAME_COUNT 100既保证速度又因 Doppler 需要历史窗口而覆盖了时间动态verify.py 第 77 行。2.3 命令行用法# 在仓库根目录运行标准验证最常用 ./verify # 或者直接调用底层 Python 证明脚本 python3 archive/v1/data/proof/verify.py # 查看详细特征统计与 Doppler/PSD 明细证明是真实 FFT 而非随机数 python3 archive/v1/data/proof/verify.py --verbose # 扫描生产代码库中的 mock/random 模式np.random.*、unittest.mock 等 python3 archive/v1/data/proof/verify.py --audit # 数值变更后重新生成期望哈希罕见操作 python3 archive/v1/data/proof/verify.py --generate-hash必须输出的结果行是VERDICT: PASS。verify.py 在退出码上同样严格匹配为 0PASS不匹配为 1FAIL缺少期望哈希文件时为 2SKIP。2.4 跨平台哈希稳定性量化精度与容差门这是本证明体系最精巧的工程细节。直接对浮点特征做 SHA-256 会因 CPU 微架构不同而失败scipy.fft 的 pocketfft 内核在不同 SIMD 后端Intel AVX2/AVX-512、ARM NEON、不同 x86 微架构下会以不同顺序重排向量化浮点运算IEEE 754 只保证单次运算的确定性不保证重排序下的可结合性。实测即使np.round(..., 9)也无法收敛流水线预处理 → 双二阶带通 → FFT → PSD → 方差累积会把 ~1e-14 的原始 FFT 差异放大到输入特征字节时的 ~1e-7 量级。解决方案verify.py 第 167-195 行对五个参与哈希的特征数组amplitude_mean、amplitude_variance、phase_difference、correlation_matrix、power_spectral_density先量化为 6 位小数再按小端 float64 打包后喂给 SHA-256量化精度可通过环境变量PROOF_HASH_DECIMALS覆盖默认6在 Windows 与 Linux/macOS 之间存在跨平台边界问题时可按需加粗到边界稳定的值doppler_shift被刻意排除在哈希之外它是峰值归一化spectrum / max(spectrum)当原始频谱出现接近并列的峰值时argmax在跨微架构浮点重排下会翻转导致整数组 O(1) 量级漂移任何容差都吸收不了。此外verify.py 还内置了跨平台容差门issue #560 后续位精确哈希只在同一 CPU 微架构内成立因此脚本同时提交了参考特征向量expected_features_reference.npz当位精确哈希不一致时若原始特征向量与参考向量满足rtol1e-4、atol1e-6的相对容差verify.py 第 256-258 行仍判定 TOLERANCE MATCH。该容差约为实测微架构漂移的 100 倍、低于任何信号意义变化的 10 倍——真实的流水线回归依然会失败而纯 CPU 微架构差异则被放行。2.5 何时重新生成哈希如果 numpy/scipy 版本升级、或有意修改了 CSI 处理器导致数值输出变化哈希会 FAIL。此时需要python3 archive/v1/data/proof/verify.py --generate-hash python3 archive/v1/data/proof/verify.py # 重新验证必须 PASS--generate-hash会同时写入新的expected_features.sha256和新的参考向量expected_features_reference.npz。但要注意docs/WITNESS-LOG-028.md中登记的审计期哈希8c0680d7...numpy 2.4.2 scipy 1.17.1与特定提交绑定重新生成哈希即意味着旧见证失效、需要重新签发见证包。三、ADR-028 见证包一键签发与一键复验3.1 生成与校验命令对于发布级release-grade认证技能文档给出了两条命令bash scripts/generate-witness-bundle.sh cd dist/witness-bundle-ADR028-*/ bash VERIFY.sh # 必须 7/7 PASS生成脚本 scripts/generate-witness-bundle.sh 会产出dist/witness-bundle-ADR028-commit短哈希.tar.gz内含见证日志、ADR、证明哈希、测试结果、固件清单、参考信号元数据以及一份供接收方一键复验的VERIFY.sh。3.2 包内 7 步内容以set -euo pipefail严格模式运行的生成器按 7 个步骤组装内容步骤内容细节[1/7] 见证文档docs/WITNESS-LOG-028.mddocs/adr/ADR-028-esp32-capability-audit.md记录被见证提交的能力矩阵[2/7] 证明系统verify.py、expected_features.sha256、generate_reference_signal.pyreference_signal_metadata.json参考信号约 10MB 只提取元数据含帧数、首帧字段、文件大小[3/7] Rust 测试日志cargo test --workspace --no-default-features输出 汇总用 awk 汇总出TOTAL: N passed, M failed[4/7] Python 证明回放verify.py输出经scripts/redact-secrets.py脱敏后落盘防止 Pydantic 校验失败时把.env中的 Docker token/API key 泄漏进日志ADR-110 wave 5 事故教训[4b/7] CIR 确定性证明scripts/verify-cir-proof.shADR-134expected_cir_features.sha256若未实现则如实标记 BLOCKED不伪装通过[5/7] 固件清单main/下 C/H 源码行数、逐文件sha256sum、预构建二进制哈希、支持目标列表明确列出 esp32s3生产与 esp32c6研究[6/7] crate 清单遍历v2/crates/*/Cargo.toml提取各 crate 版本形成versions.txt[6b] npm 清单npm pack构建ruvnet/rvagenttarball 并记录 SHA-256ADR-124tarball 只记录哈希不随包分发[7/7] VERIFY.sh生成接收方复验脚本并chmod x最后对整个包生成MANIFEST.sha256并打包3.3 VERIFY.sh 的检查项包内的VERIFY.sh对接收方完全自包含逐项比对打包时记录的结果见证文档存在WITNESS-LOG-028.md、ADR-028-esp32-capability-audit.md证明哈希文件存在并打印期望值Rust 测试汇总中 0 failed固件源码哈希清单存在含文件数crate 版本清单存在含 crate 数ruvnet/rvagentnpm tarball SHA-256 记录存在npm-pack-failed记为 FAILPython 证明日志中包含VERDICT: PASSCIR 证明ADR-134VERDICT: PASS为通过显式BLOCKED视为 SKIP 放行其余为 FAIL。所有检查通过后打印VERDICT: ALL CHECKS PASSED。技能文档中要求的7/7 PASS即对应这 8 项中可判定的核心集合——收到见证包的第三方无需信任发布者只需解包、bash VERIFY.sh即可独立复验该提交的能力声明。3.4 见证日志ADR-028 的能力矩阵见证的料来自 docs/WITNESS-LOG-028.md。该日志记录了审计期提交96b01008的完整能力矩阵核心数字包括Rust 工作区1,031 passed, 0 failed, 8 ignored跨 15 个 cratePython 证明哈希8c0680d7d285...numpy 2.4.2、scipy 1.17.1PASSCIR 证明哈希ADR-134与空房基线校准证明哈希ADR-135均已登记ESP32 帧魔术字0xC5110001。该矩阵的诚实性尤其值得注意Not measured 与 No 同样被如实登记——例如54,000 fps 实测吞吐被标注为NOT MEASUREDCriterion 基准存在但审计时未运行板载 ESP32 ML 推理被标注为NO固件只流式传输原始 I/Q。这正是声明诚实性哲学在文档层面的体现未验证的声明必须与已验证的声明区分开。四、声明诚实性检查ruview_claim_check4.1 使用方式技能文档要求在引用任何报告、README 章节、PR 描述或模型卡中的准确性数字之前先运行npx ruview claim-check --text Held-out PCK20 59.5% (MEASURED vs mean-pose baseline, verify.py). npx ruview claim-check --file docs/release-notes.mdCLI 的实现遵循**失败即关闭fail-closed**原则ADR-263 O1空输入是错误而非 PASS因为诚实性门禁绝不能在无输入时通过cli.js 第 118-122 行。同一逻辑也通过 MCP 工具ruview_claim_checkruview mcp start暴露与 claude-code 预输出钩子共享。4.2 三条核心规则技能文档列出的三条检查规则其静态实现位于 harness/ruview/src/guardrails.js未标记的准确性数字行内出现accuracy、pck、precision、recall、mpjpe、error rate等指标词METRIC_TERMS或词边界匹配的map/f1/auc/iou且同行携带数字时若没有measured、claimed、synthetic、unvalidated、baseline任一标签则报 medium 级 findingMEASURED 但无复现证据标签了measured却未引用任何复现器提示词verify.py、witness、held-out、sha256、boot log、pck20 vs、cargo test、tarball等见REPRODUCER_HINTS同样报 medium被撤回的100%/完美准确率表述perfect accuracy、flawless、never wrong等措辞或伴随指标词的裸100%一律报high级——这是项目曾公开撤回的具体表述任何形式的复现都不可接受除非该行明确包含 retract。实现中还有两处值得了解的边界处理反引号内的代码片段0.95不算声明文本会被剔除但若代码片段中的数字正是声明的一部分accuracy reached0.95则会保留判断F1/O2这类 finding/option 标签只有在紧跟分数/等号/百分号/冒号或同句出现数字时才被当作指标声明ADR-263 F11 的误报治理。4.3 输出与自检claimCheck()返回{ ok, findings }每条 finding 含severityhigh/medium、行号、原文摘录、原因与修改建议CLI 以 JSON 输出并给出人类可读摘要claim-check: 2 finding(s) (1 high) — accuracy claims need MEASURED/CLAIMED tags a reproducer.Harness 自带npx ruview doctor自检其中两项断言直接验证诚实性门禁本身cli.js 第 45-48 行checks.push([claim_check flags a 100% claim, !claimCheck(We hit 100% accuracy on poses.).ok]); checks.push([claim_check passes a tagged MEASURED claim, claimCheck(Held-out PCK20 59.5% (MEASURED vs mean-pose baseline, verify.py).).ok]);即未打标签的 100% 声明必须被拦截打了 MEASURED 标签并附复现器的声明必须放行。五、固件级验证真实硅片启动日志是硬门槛技能文档对固件修复提出了明确的验证底线仅凭编译通过build-passes信号不得合并或发布固件修复在获得真实芯片上捕获的启动日志之前不得称为硬件已验证hardware-validated。文档给出的判例是v0.8.1-esp32的 rev-v0.2 验证它由三段证据组成无头运行的实机启动日志running headless so CSI captures (#1000)—— 该输出确实存在于固件源码 firmware/esp32-csi-node/main/display_task.c表示无显示面板的板卡进入 headless 模式以启用 CSI 采集CSI 过滤器升级到 MGMTDATA对应 firmware/esp32-csi-node/README.md 描述的 RuView#893 MGMTDATA CSI 升级——仅捕获管理帧不足以支撑 RuView 的感知管线必须同时接收管理帧与数据帧无假阳性的 mmwave 探针在毫米波参考传感器对照下无虚假检测。从仓库结构看这组证据与ruview_node_monitor工具MCP 工具ruview_node_monitor打开串口断言 CSI 以 MGMTDATA 形式流动以及scripts/c6-presence-watcher.py、scripts/ruview-sensing-server.py等运行时脚本同属实机验证工具链Harness 的根级verify脚本第 5 阶段还专门检查identity_risk_score在 HAP/MCP 网关边界必须为NoneADR-125 §2.1.d 不变量防止隐私风险分数跨界泄漏。六、仓库根 verify 脚本九阶段多层证明除了技能文档主打的证明路径仓库根目录的 verify 脚本把Trust Kill Switch扩展为横跨整个技术栈的九阶段一次性证明阶段验证内容1Python 信号处理流水线 SHA-256 回放即 verify.py2生产代码 mock 模式扫描np.random.rand/randn排除测试目录3Rust 工作区测试cargo test --workspace默认排除cog-pose-estimation以规避 Windows 文件锁问题可用RUVIEW_RUST_EXCLUDE覆盖4PyO3 BFLD 绑定编译检查cargo check -p wifi-densepose-py5ADR-125 §2.1.d 不变量identity_risk_score永不出现在网关脚本的数值泄漏中6已发布 crates.io 包存在性检查12 个 crate7npmruvnet/rvagent发布检查8Docker Hub 多架构清单amd64 arm649Docker 镜像内嵌 HOMECORE 二进制homecore-server --help默认绑定0.0.0.0:8123脚本支持--quick跳过 cargo test 与 docker pull、--rust-only、--docker-only、--verbose、--audit、--generate-hash等标志退出码 0 表示所有执行过的阶段全部通过。这与技能文档的哲学一脉相承每一层都提供可复验的证据缺一层的声明就不能发布。七、落地实践建议把验证写进工作流任何 PR、模型卡或 release note 在合入前先跑npx ruview claim-check --file 文档再跑./verify --quick确认证明与扫描通过发布前用bash scripts/generate-witness-bundle.sh签发见证包并将VERIFY.sh的 PASS 结果连同提交哈希一起写进 release note。数值变更时规范重生成升级 numpy/scipy 或改动CSIProcessor后verify.py会 FAIL此时按 2.5 节用--generate-hash重生成并重新签发见证包——旧的见证哈希与旧提交绑定不可混用。诚实标签是硬规范写任何准确性数字必须带MEASURED并附verify.py、见证包或 held-out 对比均值姿态基线的复现路径、CLAIMED或SYNTHETIC100%/perfect 表述属于已撤回表述任何形式都不得复现。固件验证要留实机证据合并固件修复前至少收集真实芯片的启动日志含 MGMTDATA 升级证据与无假阳性探针记录仅编译通过不足以支撑硬件已验证。第三方独立核验拿到见证包后无需信任发布者解包运行bash VERIFY.sh即可对照提交哈希逐项复验审计docs/WITNESS-LOG-028.md的能力矩阵时重点关注标注NOT MEASURED与NO的行——它们同样是有价值的诚实信息。【免费下载链接】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），仅供参考 RuView verify 技能深度解析：确定性 SHA-256 证明、ADR-028 见证包与声明诚实性门禁
RuView verify 技能深度解析确定性 SHA-256 证明、ADR-028 见证包与声明诚实性门禁【免费下载链接】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 将商品 WiFi 信号转化为空间智能、生命体征监测与存在检测但传感器结果是否真实始终是这类系统最容易被质疑的问题。本指南基于 harness/ruview/skills/verify.md 展开系统讲解 RuView 的证明一切prove everything验证体系通过确定性 SHA-256 流水线回放Trust Kill Switch证明处理代码真实且可复现通过 ADR-028 见证包Witness Bundle为发布提供一键可复验的凭证并通过ruview_claim_check对任何报告、README 或模型卡中的准确性声明做诚实性门禁。读完本文你将掌握在 RuView 仓库中运行完整验证、签发与校验见证包、以及撰写诚实技术声明的完整实战方法。一、verify 技能定位RuView 的证明一切门禁verify是 RuView 操作型 Harnessnpx ruview内置的六项技能之一onboard、verify、calibrate-room、provision-node、train-pose、cognitum-spaces其元数据定义如下name: verify description: Prove a RuView result is real — run the deterministic SHA-256 proof and the witness bundle (ADR-028), and lint any claim for MEASURED-vs-CLAIMED honesty.技能文件的正文第一句话就给出了它的地位The prove everything skill. Nothing ships as validated without this.证明一切技能。任何东西未经它验证不得发布。它由三个层次构成层次机制解决的问题确定性证明verify.pySHA-256 回放流水线是真实代码还是 mock发布级见证ADR-028 Witness Bundle这个版本的能力是否可被第三方独立复验声明诚实性ruview_claim_check报告里的准确率数字是 MEASURED 还是编造的这三层在 CLI 中分别对应ruview verify、bash scripts/generate-witness-bundle.sh与ruview claim-check命令映射定义于 harness/ruview/bin/cli.js。二、Trust Kill Switch确定性 SHA-256 流水线证明2.1 核心机制ruview_verify会调用 archive/v1/data/proof/verify.py其目标是把它是 mock 的从一句口号变成一个可证伪的、可度量且会因证据而失败的主张。verify.py 的文件头注释概括了完整流程加载已发布的参考 CSI 信号sample_csi_data.json将每一帧送入真实的CSI 处理器做特征提取把所有特征输出收敛为规范的字节表示计算全部特征输出的 SHA-256 哈希与expected_features.sha256中已发布的期望哈希比对打印 PASS 或 FAIL。关键在于第 2 步verify.py 直接导入生产模块而非测试替身verify.py 第 56-57 行 明确注释这些是生产模块不是 test doublefrom src.hardware.csi_extractor import CSIData from src.core.csi_processor import CSIProcessor, CSIFeatures运行时脚本还会通过inspect.getfile()打印三个类的实际源文件绝对路径、numpy/scipy 的路径与版本即SOURCE PROVENANCE源码溯源让任何人当场确认被验证的确实是生产代码。2.2 参考信号与处理器配置参考信号是合成的由generate_reference_signal.py生成固定随机种子其作用纯粹是验证流水线的确定性——验证对象不是信号本身真实而是处理信号的代码真实同一份代码既处理该参考信号也处理线上实时采集verify.py 第 19-22 行 的注释。处理器使用与生产默认一致的关键参数verify.py 第 61-72 行PROCESSOR_CONFIG { sampling_rate: 100, window_size: 56, overlap: 0.5, noise_threshold: -60, # dB human_detection_threshold: 0.8, smoothing_factor: 0.9, max_history_size: 500, enable_preprocessing: True, enable_feature_extraction: True, enable_human_detection: True, }验证会处理参考信号的前 100 帧约 1 秒VERIFICATION_FRAME_COUNT 100既保证速度又因 Doppler 需要历史窗口而覆盖了时间动态verify.py 第 77 行。2.3 命令行用法# 在仓库根目录运行标准验证最常用 ./verify # 或者直接调用底层 Python 证明脚本 python3 archive/v1/data/proof/verify.py # 查看详细特征统计与 Doppler/PSD 明细证明是真实 FFT 而非随机数 python3 archive/v1/data/proof/verify.py --verbose # 扫描生产代码库中的 mock/random 模式np.random.*、unittest.mock 等 python3 archive/v1/data/proof/verify.py --audit # 数值变更后重新生成期望哈希罕见操作 python3 archive/v1/data/proof/verify.py --generate-hash必须输出的结果行是VERDICT: PASS。verify.py 在退出码上同样严格匹配为 0PASS不匹配为 1FAIL缺少期望哈希文件时为 2SKIP。2.4 跨平台哈希稳定性量化精度与容差门这是本证明体系最精巧的工程细节。直接对浮点特征做 SHA-256 会因 CPU 微架构不同而失败scipy.fft 的 pocketfft 内核在不同 SIMD 后端Intel AVX2/AVX-512、ARM NEON、不同 x86 微架构下会以不同顺序重排向量化浮点运算IEEE 754 只保证单次运算的确定性不保证重排序下的可结合性。实测即使np.round(..., 9)也无法收敛流水线预处理 → 双二阶带通 → FFT → PSD → 方差累积会把 ~1e-14 的原始 FFT 差异放大到输入特征字节时的 ~1e-7 量级。解决方案verify.py 第 167-195 行对五个参与哈希的特征数组amplitude_mean、amplitude_variance、phase_difference、correlation_matrix、power_spectral_density先量化为 6 位小数再按小端 float64 打包后喂给 SHA-256量化精度可通过环境变量PROOF_HASH_DECIMALS覆盖默认6在 Windows 与 Linux/macOS 之间存在跨平台边界问题时可按需加粗到边界稳定的值doppler_shift被刻意排除在哈希之外它是峰值归一化spectrum / max(spectrum)当原始频谱出现接近并列的峰值时argmax在跨微架构浮点重排下会翻转导致整数组 O(1) 量级漂移任何容差都吸收不了。此外verify.py 还内置了跨平台容差门issue #560 后续位精确哈希只在同一 CPU 微架构内成立因此脚本同时提交了参考特征向量expected_features_reference.npz当位精确哈希不一致时若原始特征向量与参考向量满足rtol1e-4、atol1e-6的相对容差verify.py 第 256-258 行仍判定 TOLERANCE MATCH。该容差约为实测微架构漂移的 100 倍、低于任何信号意义变化的 10 倍——真实的流水线回归依然会失败而纯 CPU 微架构差异则被放行。2.5 何时重新生成哈希如果 numpy/scipy 版本升级、或有意修改了 CSI 处理器导致数值输出变化哈希会 FAIL。此时需要python3 archive/v1/data/proof/verify.py --generate-hash python3 archive/v1/data/proof/verify.py # 重新验证必须 PASS--generate-hash会同时写入新的expected_features.sha256和新的参考向量expected_features_reference.npz。但要注意docs/WITNESS-LOG-028.md中登记的审计期哈希8c0680d7...numpy 2.4.2 scipy 1.17.1与特定提交绑定重新生成哈希即意味着旧见证失效、需要重新签发见证包。三、ADR-028 见证包一键签发与一键复验3.1 生成与校验命令对于发布级release-grade认证技能文档给出了两条命令bash scripts/generate-witness-bundle.sh cd dist/witness-bundle-ADR028-*/ bash VERIFY.sh # 必须 7/7 PASS生成脚本 scripts/generate-witness-bundle.sh 会产出dist/witness-bundle-ADR028-commit短哈希.tar.gz内含见证日志、ADR、证明哈希、测试结果、固件清单、参考信号元数据以及一份供接收方一键复验的VERIFY.sh。3.2 包内 7 步内容以set -euo pipefail严格模式运行的生成器按 7 个步骤组装内容步骤内容细节[1/7] 见证文档docs/WITNESS-LOG-028.mddocs/adr/ADR-028-esp32-capability-audit.md记录被见证提交的能力矩阵[2/7] 证明系统verify.py、expected_features.sha256、generate_reference_signal.pyreference_signal_metadata.json参考信号约 10MB 只提取元数据含帧数、首帧字段、文件大小[3/7] Rust 测试日志cargo test --workspace --no-default-features输出 汇总用 awk 汇总出TOTAL: N passed, M failed[4/7] Python 证明回放verify.py输出经scripts/redact-secrets.py脱敏后落盘防止 Pydantic 校验失败时把.env中的 Docker token/API key 泄漏进日志ADR-110 wave 5 事故教训[4b/7] CIR 确定性证明scripts/verify-cir-proof.shADR-134expected_cir_features.sha256若未实现则如实标记 BLOCKED不伪装通过[5/7] 固件清单main/下 C/H 源码行数、逐文件sha256sum、预构建二进制哈希、支持目标列表明确列出 esp32s3生产与 esp32c6研究[6/7] crate 清单遍历v2/crates/*/Cargo.toml提取各 crate 版本形成versions.txt[6b] npm 清单npm pack构建ruvnet/rvagenttarball 并记录 SHA-256ADR-124tarball 只记录哈希不随包分发[7/7] VERIFY.sh生成接收方复验脚本并chmod x最后对整个包生成MANIFEST.sha256并打包3.3 VERIFY.sh 的检查项包内的VERIFY.sh对接收方完全自包含逐项比对打包时记录的结果见证文档存在WITNESS-LOG-028.md、ADR-028-esp32-capability-audit.md证明哈希文件存在并打印期望值Rust 测试汇总中 0 failed固件源码哈希清单存在含文件数crate 版本清单存在含 crate 数ruvnet/rvagentnpm tarball SHA-256 记录存在npm-pack-failed记为 FAILPython 证明日志中包含VERDICT: PASSCIR 证明ADR-134VERDICT: PASS为通过显式BLOCKED视为 SKIP 放行其余为 FAIL。所有检查通过后打印VERDICT: ALL CHECKS PASSED。技能文档中要求的7/7 PASS即对应这 8 项中可判定的核心集合——收到见证包的第三方无需信任发布者只需解包、bash VERIFY.sh即可独立复验该提交的能力声明。3.4 见证日志ADR-028 的能力矩阵见证的料来自 docs/WITNESS-LOG-028.md。该日志记录了审计期提交96b01008的完整能力矩阵核心数字包括Rust 工作区1,031 passed, 0 failed, 8 ignored跨 15 个 cratePython 证明哈希8c0680d7d285...numpy 2.4.2、scipy 1.17.1PASSCIR 证明哈希ADR-134与空房基线校准证明哈希ADR-135均已登记ESP32 帧魔术字0xC5110001。该矩阵的诚实性尤其值得注意Not measured 与 No 同样被如实登记——例如54,000 fps 实测吞吐被标注为NOT MEASUREDCriterion 基准存在但审计时未运行板载 ESP32 ML 推理被标注为NO固件只流式传输原始 I/Q。这正是声明诚实性哲学在文档层面的体现未验证的声明必须与已验证的声明区分开。四、声明诚实性检查ruview_claim_check4.1 使用方式技能文档要求在引用任何报告、README 章节、PR 描述或模型卡中的准确性数字之前先运行npx ruview claim-check --text Held-out PCK20 59.5% (MEASURED vs mean-pose baseline, verify.py). npx ruview claim-check --file docs/release-notes.mdCLI 的实现遵循**失败即关闭fail-closed**原则ADR-263 O1空输入是错误而非 PASS因为诚实性门禁绝不能在无输入时通过cli.js 第 118-122 行。同一逻辑也通过 MCP 工具ruview_claim_checkruview mcp start暴露与 claude-code 预输出钩子共享。4.2 三条核心规则技能文档列出的三条检查规则其静态实现位于 harness/ruview/src/guardrails.js未标记的准确性数字行内出现accuracy、pck、precision、recall、mpjpe、error rate等指标词METRIC_TERMS或词边界匹配的map/f1/auc/iou且同行携带数字时若没有measured、claimed、synthetic、unvalidated、baseline任一标签则报 medium 级 findingMEASURED 但无复现证据标签了measured却未引用任何复现器提示词verify.py、witness、held-out、sha256、boot log、pck20 vs、cargo test、tarball等见REPRODUCER_HINTS同样报 medium被撤回的100%/完美准确率表述perfect accuracy、flawless、never wrong等措辞或伴随指标词的裸100%一律报high级——这是项目曾公开撤回的具体表述任何形式的复现都不可接受除非该行明确包含 retract。实现中还有两处值得了解的边界处理反引号内的代码片段0.95不算声明文本会被剔除但若代码片段中的数字正是声明的一部分accuracy reached0.95则会保留判断F1/O2这类 finding/option 标签只有在紧跟分数/等号/百分号/冒号或同句出现数字时才被当作指标声明ADR-263 F11 的误报治理。4.3 输出与自检claimCheck()返回{ ok, findings }每条 finding 含severityhigh/medium、行号、原文摘录、原因与修改建议CLI 以 JSON 输出并给出人类可读摘要claim-check: 2 finding(s) (1 high) — accuracy claims need MEASURED/CLAIMED tags a reproducer.Harness 自带npx ruview doctor自检其中两项断言直接验证诚实性门禁本身cli.js 第 45-48 行checks.push([claim_check flags a 100% claim, !claimCheck(We hit 100% accuracy on poses.).ok]); checks.push([claim_check passes a tagged MEASURED claim, claimCheck(Held-out PCK20 59.5% (MEASURED vs mean-pose baseline, verify.py).).ok]);即未打标签的 100% 声明必须被拦截打了 MEASURED 标签并附复现器的声明必须放行。五、固件级验证真实硅片启动日志是硬门槛技能文档对固件修复提出了明确的验证底线仅凭编译通过build-passes信号不得合并或发布固件修复在获得真实芯片上捕获的启动日志之前不得称为硬件已验证hardware-validated。文档给出的判例是v0.8.1-esp32的 rev-v0.2 验证它由三段证据组成无头运行的实机启动日志running headless so CSI captures (#1000)—— 该输出确实存在于固件源码 firmware/esp32-csi-node/main/display_task.c表示无显示面板的板卡进入 headless 模式以启用 CSI 采集CSI 过滤器升级到 MGMTDATA对应 firmware/esp32-csi-node/README.md 描述的 RuView#893 MGMTDATA CSI 升级——仅捕获管理帧不足以支撑 RuView 的感知管线必须同时接收管理帧与数据帧无假阳性的 mmwave 探针在毫米波参考传感器对照下无虚假检测。从仓库结构看这组证据与ruview_node_monitor工具MCP 工具ruview_node_monitor打开串口断言 CSI 以 MGMTDATA 形式流动以及scripts/c6-presence-watcher.py、scripts/ruview-sensing-server.py等运行时脚本同属实机验证工具链Harness 的根级verify脚本第 5 阶段还专门检查identity_risk_score在 HAP/MCP 网关边界必须为NoneADR-125 §2.1.d 不变量防止隐私风险分数跨界泄漏。六、仓库根 verify 脚本九阶段多层证明除了技能文档主打的证明路径仓库根目录的 verify 脚本把Trust Kill Switch扩展为横跨整个技术栈的九阶段一次性证明阶段验证内容1Python 信号处理流水线 SHA-256 回放即 verify.py2生产代码 mock 模式扫描np.random.rand/randn排除测试目录3Rust 工作区测试cargo test --workspace默认排除cog-pose-estimation以规避 Windows 文件锁问题可用RUVIEW_RUST_EXCLUDE覆盖4PyO3 BFLD 绑定编译检查cargo check -p wifi-densepose-py5ADR-125 §2.1.d 不变量identity_risk_score永不出现在网关脚本的数值泄漏中6已发布 crates.io 包存在性检查12 个 crate7npmruvnet/rvagent发布检查8Docker Hub 多架构清单amd64 arm649Docker 镜像内嵌 HOMECORE 二进制homecore-server --help默认绑定0.0.0.0:8123脚本支持--quick跳过 cargo test 与 docker pull、--rust-only、--docker-only、--verbose、--audit、--generate-hash等标志退出码 0 表示所有执行过的阶段全部通过。这与技能文档的哲学一脉相承每一层都提供可复验的证据缺一层的声明就不能发布。七、落地实践建议把验证写进工作流任何 PR、模型卡或 release note 在合入前先跑npx ruview claim-check --file 文档再跑./verify --quick确认证明与扫描通过发布前用bash scripts/generate-witness-bundle.sh签发见证包并将VERIFY.sh的 PASS 结果连同提交哈希一起写进 release note。数值变更时规范重生成升级 numpy/scipy 或改动CSIProcessor后verify.py会 FAIL此时按 2.5 节用--generate-hash重生成并重新签发见证包——旧的见证哈希与旧提交绑定不可混用。诚实标签是硬规范写任何准确性数字必须带MEASURED并附verify.py、见证包或 held-out 对比均值姿态基线的复现路径、CLAIMED或SYNTHETIC100%/perfect 表述属于已撤回表述任何形式都不得复现。固件验证要留实机证据合并固件修复前至少收集真实芯片的启动日志含 MGMTDATA 升级证据与无假阳性探针记录仅编译通过不足以支撑硬件已验证。第三方独立核验拿到见证包后无需信任发布者解包运行bash VERIFY.sh即可对照提交哈希逐项复验审计docs/WITNESS-LOG-028.md的能力矩阵时重点关注标注NOT MEASURED与NO的行——它们同样是有价值的诚实信息。【免费下载链接】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），仅供参考