RuView/ruview-verify信任管道实战指南Rust 测试、确定性 Proof 与 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/RuViewRuView 是一个基于商用 WiFi 信号实现空间感知、生命体征监测与存在检测的免摄像头射频感知系统其生产实现集中在 Rust workspacev2/Python 参考管线位于archive/v1/。本文围绕仓库内置的/ruview-verify命令及其对应技能ruview-verify展开完整讲解 RuView 的信任管道trust pipeline——从 Rust workspace 全量测试、SHA-256 确定性 ProofTrust Kill Switch到 ADR-028 见证包的生成与一键自验证再到合并前的 12 项检查清单。读完本文你将掌握在代码变更后、合并 PR 前或为接收方生成可验证证明包时的标准验证流程并能理解每一条命令背后对应的源码实现与设计动机。1. 什么是/ruview-verifyRuView 的信任管道入口/ruview-verify是 RuView 仓库内置的 Claude Code 命令定义于 命令文件同时在 Codex 镜像 中提供等价提示词并在 技能文件 中以ruview-verify技能形式存在。三者描述的是同一套验证流程命令文件是其最精简的入口形式。命令通过$ARGUMENTS选择验证范围默认值为all支持四种取值取值执行内容通过标准testscd v2 cargo test --workspace --no-default-features1,400 通过、0 失败约 2 分钟proofpython archive/v1/data/proof/verify.py输出VERDICT: PASSbundlebash scripts/generate-witness-bundle.sh随后在生成的目录内运行bash VERIFY.sh7/7 PASSall按 tests → proof → bundle 顺序全部执行全部满足上述标准该命令定位为在重大变更之后、合并 PR 之前以及为接收方生成证明包时使用。RuView 将可验证性作为一等公民任何能力声明都可以通过命令复现来证实或证伪这与仓库 CLAUDE.md 中硬件验证必须来自真实硅片证据、性能声明必须标注 MEASURED/CLAIMED/SYNTHETIC的规则一脉相承。2. 第一站Rust workspace 全量测试cd v2 cargo test --workspace --no-default-features # 必须 1,400 通过、0 失败约 2 分钟这条命令是整个验证的第一道关卡。--no-default-features确保测试在无 GPU、无默认特性组合下也能全量通过避免特性门控掩盖回归。workspace 位于 v2/crates包含 70 个 crate覆盖信号处理wifi-densepose-signal、训练wifi-densepose-train、神经网络wifi-densepose-nn、硬件解析wifi-densepose-hardware、生命体征wifi-densepose-vitals、WiFi 扫描wifi-densepose-wifiscan以及 Homecore、nvsim、ruforecast 等家族 crate。迭代开发时无需每次都跑全量测试技能文档建议按 crate 收敛cargo check -p wifi-densepose-train --no-default-features cargo test -p wifi-densepose-signal --no-default-features见证日志 记录了历史审计时刻的测试分布可作为理解 crate 家族测试规模的参考signal 105、train 174、nn 23、mat 153、hardware 32另有各 crate 的 doc-tests 11 项。需要说明的是仓库 CLAUDE.md 明确要求不要将 crate、ADR 或测试数量硬编码进指令任务需要时动态推导因此本文引用的 1,400 与日志中的 1,031 均为历史快照实际应以当前分支跑出的结果为准。3. 第二站确定性 Python ProofTrust Kill Switch3.1 一句话理解它是什么cd .. python archive/v1/data/proof/verify.py # 必须打印 VERDICT: PASS这套证明系统在 verify.py 的文件头中被命名为TRUST KILL SWITCH信任终止开关它把这个管线是 mock 的从一个口头指控变成一句可用证据检验的陈述。原理是将一段已知的参考 CSI 信号喂入生产管线注意不是测试替身对输出做 SHA-256 哈希再与仓库中公布的期望哈希比对。任何行为漂移都会改变哈希从而让回归可证伪。3.2 源码视角验证脚本的内部工作流从源码看verify.py的主流程分为四步[0/4][4/4]源码溯源Source Provenance通过inspect.getfile()打印实际加载的CSIProcessor、CSIData、CSIFeatures的绝对路径以及 numpy/scipy 版本让任何人可以确认导入的是生产模块而非测试替身——这一设计直接服务于反 mock 指控。加载参考信号读取 sample_csi_data.json。该文件由 generate_reference_signal.py 生成包含 1,000 帧合成 CSI 数据3 天线、56 子载波、100 Hz 采样、10 秒其中建模了 0.3 Hz 呼吸调制、1.2 Hz 行走调制和 5 条确定性多径。所有参数由numpy.random.RandomState(42)一次性选定后固定生成过程不再使用任何随机性。验证时只取前VERIFICATION_FRAME_COUNT 100帧约 1 秒在覆盖时域动态Doppler 依赖历史帧的同时保持验证速度。跑真实管线用与生产一致的PROCESSOR_CONFIG构造CSIProcessor逐帧调用preprocess_csi_data()→extract_features()并把特征序列化为规范化字节流喂入 SHA-256。哈希比对并给出裁决输出VERDICT: PASS或VERDICT: FAIL失败时还会输出与参考向量的最大偏差并定位到具体特征块amp_mean/amp_var/phase_diff/corr/psd便于定位回归来源。其中PROCESSOR_CONFIG生产默认配置是理解该管线行为的关键参数表参数默认值含义sampling_rate100采样率Hzwindow_size56处理窗口大小对应 56 子载波overlap0.5滑窗重叠率noise_threshold-60噪声门限dBhuman_detection_threshold0.8人体检测置信门限smoothing_factor0.9平滑因子max_history_size500历史帧缓冲上限enable_preprocessing/enable_feature_extraction/enable_human_detectionTrue三个阶段开关3.3 哈希为什么能跨平台稳定量化精度与容差门这是整个 Proof 系统最精妙的技术点值得单独说明。源码注释对应 issue #560解释了背景scipy.fft的 pocketfft 内核在不同 SIMD 后端Intel AVX2/AVX-512 vs ARM NEON会以不同顺序重排浮点约简IEEE 754 只保证单次运算确定不保证重排后结合律一致。实测在 Ubuntu 24.04 / Python 3.11 / scipy 1.17 的连续两次 CI 运行中不同 Azure VM 微架构Skylake vs Cascade Lake会产出两个不同的 SHA-256。解决方案分两层量化features_to_bytes()在打包前对每个特征数组做np.round(flat, HASH_QUANTIZATION_DECIMALS)。量化精度默认 6 位小数可通过环境变量PROOF_HASH_DECIMALS覆盖在跨 Linux 微架构漂移之上留出约 6 个数量级余量同时远低于信号有意义的变化CSI 相位精度约 1e-3 rad。容差门由于哈希在跨平台Windows vs Linux上仍可能在个别元素跨越 6 位小数边界脚本额外提交了 expected_features_reference.npz 参考向量当位精确哈希不匹配时用np.allclose(computed, ref, rtol1e-4, atol1e-6)做相对容差比对。任一匹配即算通过哈希是同平台强证明容差是跨平台独立证明。值得注意的一个工程取舍doppler_shift特征被有意排除在哈希之外。原因是它做了峰值归一化spectrum / max(spectrum)当原始频谱出现近乎并列的峰值时argmax会因跨微架构浮点重排而翻转导致整个数组 O(1) 级漂移任何容差都无法吸收。其余五个特征幅值均值、幅值方差、相位差、相关矩阵、功率谱密度可确定性复现构成证明的主体。3.4 CLI 选项与哈希漂移处置选项作用--generate-hash重新计算并把期望哈希写入expected_features.sha256同时把参考向量写入 npz不比对--verbose打印详细特征统计、Doppler 频谱与 PSD 细节--audit扫描生产代码排除 tests/testing 目录中的np.random.*、random.random、mock/MagicMock/patch等可疑模式当哈希不匹配、且确认是合法的 numpy/scipy 升级导致的数值漂移时按技能文档的处置流程重新生成基准python archive/v1/data/proof/verify.py --generate-hash python archive/v1/data/proof/verify.py重新生成前应确认这不是真实的数值回归——verify.py在 FAIL 时会明确列出可能原因CSI 处理器代码改动改变了数值输出 / 真实的非微架构级数值回归。3.5 可选的 v1 Python 测试套件cd archive/v1 python -m pytest tests/ -x -q这是 Proof 的补充层-x遇错即停-q精简输出针对 Python 参考实现跑完整测试套件。4. 第三站ADR-028 见证包的生成与自验证4.1 生成见证包bash scripts/generate-witness-bundle.shgenerate-witness-bundle.sh 是一个set -euo pipefail的自包含脚本产出dist/witness-bundle-ADR028-commit短哈希.tar.gz。它的 7 个步骤恰好对应可独立复核的证据链步骤内容产物1/7拷贝见证文档WITNESS-LOG-028.md、ADR-028-esp32-capability-audit.md2/7拷贝证明系统proof/verify.py、expected_features.sha256、generate_reference_signal.py、reference_signal_metadata.json参考信号本体约 10MB只打包元数据3/7运行 Rust 全量测试并捕获输出test-results/rust-workspace-tests.log、test-results/summary.txt汇总 passed/failed/ignored4/7运行 Python Proof 验证proof/verification-output.log输出经scripts/redact-secrets.py清洗4b/7运行 CIR 确定性证明ADR-134proof/cir-verify.log、expected_cir_features.sha2565/7固件清单firmware-manifest/source-hashes.txtESP32 固件全部.c/.h的 SHA-256、source-line-counts.txt、supported-targets.txt、release_bins下 S3/C6 预编译 bin 哈希6/7crate 清单crate-manifest/versions.txt遍历v2/crates/*/Cargo.toml提取名称与版本6b/7npm 清单ADR-124npm-manifest/下ruvnet/rvagenttarball 的 sha256 与文件名7/7生成接收方验证脚本VERIFY.sh最后对所有文件生成MANIFEST.sha256并打包 tar.gz脚本中有一个值得注意的安全细节第 4 步的 Python 输出会先经scripts/redact-secrets.py清洗再写入日志。脚本注释说明verify.py在验证失败时会输出 Pydantic schema dump其中可能包含用户的.env内容Docker token、API key 等对应 ADR-110 wave 5 的事件记录。这也解释了为什么打包日志而非原始输出。4.2 一键自验证7/7 PASScd dist/witness-bundle-ADR028-*/ bash VERIFY.sh # 必须 7/7 PASSVERIFY.sh是写给接收方的自验证脚本接收方拿到 bundle 后无需信任任何声明只需运行它即可对照复验。脚本用check()函数累计 PASS/FAIL检查项包括见证文档存在WITNESS-LOG-028.md、ADR-028Proof 哈希文件存在并打印期望哈希Rust 测试汇总存在且0 failed固件源码哈希清单存在含文件计数crate 清单存在含 crate 计数npm tarball sha256 清单存在ruvnet/rvagentPython Proof 日志中存在VERDICT: PASSCIR Proof 日志ADR-134——PASS通过、BLOCKED占位哈希记为跳过脚本最终输出Results: N passed, M failed与VERDICT: ALL CHECKS PASSED (8/8)命令文档中的7/7指核心七项脚本实现实际含 CIR 相关子检查。需要说明当前 CIR 模块ADR-134尚未实现expected_cir_features.sha256仍是占位符因此verify-cir-proof.sh会输出BLOCKED并以退出码 2 结束VERIFY.sh将该项按跳过处理——这是仓库中诚实标注的已知缺口。5. 见证日志能力声明与证据的对照矩阵见证包的核心文档是 WITNESS-LOG-028.md它记录了审计时刻的 35 行能力证明矩阵每一行都遵循Claimed / Verified / Evidence三段式结构。例如ESP32-S3 CSI 帧解析ADR-018 二进制格式32 个 Rust 测试、esp32_parser.rs385 行Hampel 离群滤波hampel.rs240 行测试通过Fresnel 区呼吸模型fresnel.rs448 行测试通过确定性证明系统PASS哈希8c0680d7...匹配54,000 fps 实测吞吐NOT MEASURED——Criterion 基准存在但审计时未运行日志中同样诚实标注了未实现项如ESP32 端 ML 推理为 NO固件只流式传输原始 I/Q推理在聚合端、真实 CSI 数据集随包提供为 NO仅 seed42 合成参考信号。这种把缺口写进矩阵的做法与 CLAUDE.md 的声明规则一致是理解 RuView 可信度模型的关键。日志末尾给出三类使用指南开发者按 Step 2-8 复现测试审查者按 Step 2-10无需硬件复核软件声明并重点检查矩阵中标记YES的行硬件测试者按 Step 11 用 esptool 向 ESP32-S3 烧录固件。6. 合并前检查清单Pre-merge Checklist/ruview-verify的第三层职责是如果本次调用发生在代码变更之后应逐项走完来自 CLAUDE.md 的合并前检查清单。完整清单如下Rust 测试通过1,400、0 失败Python Proof 通过VERDICT: PASS作用域变更时更新README.md平台/crate/硬件表格、功能摘要作用域变更时更新CLAUDE.mdcrate 表、ADR 列表、模块表、版本CHANGELOG.md在[Unreleased]下新增条目新增数据源/CLI 标志/安装步骤时更新docs/user-guide.md新增 ADR 时在 README 文档表中递增 ADR 计数测试或 Proof 哈希变化时重新生成见证包仅当 Dockerfile/依赖/运行时行为变化时才重建 Docker Hub 镜像仅当已发布 crate 的公共 API 变化时才发布 crate按依赖顺序发布为新增构建产物/二进制更新.gitignore对触及硬件/网络边界的模块做安全审查这套清单的价值在于精确限定变更波及面不是全部重做而是哪些变了才动哪些——例如 Docker 镜像和 crate 发布都被明确标注为条件性动作避免无谓的全局重建。7. 安全扫描与 QEMU 固件 CI对于安全相关变更命令还要求额外执行npx claude-flow/clilatest security scan与之配套的参考资料包括 安全审计文档、QE 报告目录ADR-080 QE 修复计划、ADR-093 仪表盘差距分析。此外固件侧有独立的 QEMU CI 通道ADR-061CI 中 11 任务工作流 Firmware QEMU Tests本地可用 qemu-esp32s3-test.sh、qemu-mesh-test.sh、qemu-chaos-test.sh、qemu-snapshot-test.sh 与 install-qemu.sh 复现。技能文档给出的实操经验espressif/idf:v5.4容器在pip前需先source $IDF_PATH/export.shQEMU 需用esptool merge_bin --fill-flash-size 8MB无真实 WiFi 的 WARN 在 CI 中被视为 OK。这些细节表明验证体系对模拟器证据不等于硬件证据有清醒边界——CLAUDE.md 明确要求硬件验证必须来自真实硅片的启动/运行日志。8. 实战指引何时运行与典型故障处置何时运行ruview-verify默认all任何有意义的代码变更之后合并 PR 之前作为门禁需要向接收方/审查方提供可验证证明包时此时bundle是重点典型故障与处置现象原因与处置verify.py输出VERDICT: FAIL先确认是否真实回归查看DIVERGENCE段的最大偏差与超差特征块amp_mean/psd等若确为合法的 numpy/scipy 升级漂移--generate-hash后重跑并重新生成见证包verify-cir-proof.sh输出BLOCKEDCIR 模块ADR-134未实现属已知占位状态实现落地后需按提示用cir_proof_runner --generate-hash重新生成并提交哈希见证包VERIFY.sh出现 FAIL对照MANIFEST.sha256与各子项日志定位缺失/漂移文件修正后重新generate-witness-bundle.shRust 全量测试超时或失败先收敛到单 cratecargo test -p crate --no-default-features定位再回到全量一条纪律贯穿始终CLAUDE.md 要求仅在分类为瞬时失败或变更单一因果变量后重试不在不变证据上循环——验证失败时应先定位根因而不是盲目重跑。9. 总结从声称到可证伪/ruview-verify把 RuView 的工程质量主张压缩成三条可复现命令全量 Rust 测试证明代码能跑、SHA-256 Proof 证明生产管线确定且未被 mock、ADR-028 见证包证明整条证据链可移交、可复核。其设计哲学贯穿源码与文档源码溯源打印、量化与容差双轨哈希、秘密清洗、诚实标注 NOT MEASURED 的能力矩阵——每一层都在回答同一个问题你凭什么相信这个声称 对于希望在自己的项目里建立可验证 CI 门禁的工程师这套测试 确定性证明 见证包的组合是一个完整且可移植的参考范式。相关材料可从 命令定义、技能全文、验证脚本、见证包生成器 与 见证日志 继续深入阅读。【免费下载链接】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 `/ruview-verify` 信任管道实战指南：Rust 测试、确定性 Proof 与 ADR-028 见证包
RuView/ruview-verify信任管道实战指南Rust 测试、确定性 Proof 与 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/RuViewRuView 是一个基于商用 WiFi 信号实现空间感知、生命体征监测与存在检测的免摄像头射频感知系统其生产实现集中在 Rust workspacev2/Python 参考管线位于archive/v1/。本文围绕仓库内置的/ruview-verify命令及其对应技能ruview-verify展开完整讲解 RuView 的信任管道trust pipeline——从 Rust workspace 全量测试、SHA-256 确定性 ProofTrust Kill Switch到 ADR-028 见证包的生成与一键自验证再到合并前的 12 项检查清单。读完本文你将掌握在代码变更后、合并 PR 前或为接收方生成可验证证明包时的标准验证流程并能理解每一条命令背后对应的源码实现与设计动机。1. 什么是/ruview-verifyRuView 的信任管道入口/ruview-verify是 RuView 仓库内置的 Claude Code 命令定义于 命令文件同时在 Codex 镜像 中提供等价提示词并在 技能文件 中以ruview-verify技能形式存在。三者描述的是同一套验证流程命令文件是其最精简的入口形式。命令通过$ARGUMENTS选择验证范围默认值为all支持四种取值取值执行内容通过标准testscd v2 cargo test --workspace --no-default-features1,400 通过、0 失败约 2 分钟proofpython archive/v1/data/proof/verify.py输出VERDICT: PASSbundlebash scripts/generate-witness-bundle.sh随后在生成的目录内运行bash VERIFY.sh7/7 PASSall按 tests → proof → bundle 顺序全部执行全部满足上述标准该命令定位为在重大变更之后、合并 PR 之前以及为接收方生成证明包时使用。RuView 将可验证性作为一等公民任何能力声明都可以通过命令复现来证实或证伪这与仓库 CLAUDE.md 中硬件验证必须来自真实硅片证据、性能声明必须标注 MEASURED/CLAIMED/SYNTHETIC的规则一脉相承。2. 第一站Rust workspace 全量测试cd v2 cargo test --workspace --no-default-features # 必须 1,400 通过、0 失败约 2 分钟这条命令是整个验证的第一道关卡。--no-default-features确保测试在无 GPU、无默认特性组合下也能全量通过避免特性门控掩盖回归。workspace 位于 v2/crates包含 70 个 crate覆盖信号处理wifi-densepose-signal、训练wifi-densepose-train、神经网络wifi-densepose-nn、硬件解析wifi-densepose-hardware、生命体征wifi-densepose-vitals、WiFi 扫描wifi-densepose-wifiscan以及 Homecore、nvsim、ruforecast 等家族 crate。迭代开发时无需每次都跑全量测试技能文档建议按 crate 收敛cargo check -p wifi-densepose-train --no-default-features cargo test -p wifi-densepose-signal --no-default-features见证日志 记录了历史审计时刻的测试分布可作为理解 crate 家族测试规模的参考signal 105、train 174、nn 23、mat 153、hardware 32另有各 crate 的 doc-tests 11 项。需要说明的是仓库 CLAUDE.md 明确要求不要将 crate、ADR 或测试数量硬编码进指令任务需要时动态推导因此本文引用的 1,400 与日志中的 1,031 均为历史快照实际应以当前分支跑出的结果为准。3. 第二站确定性 Python ProofTrust Kill Switch3.1 一句话理解它是什么cd .. python archive/v1/data/proof/verify.py # 必须打印 VERDICT: PASS这套证明系统在 verify.py 的文件头中被命名为TRUST KILL SWITCH信任终止开关它把这个管线是 mock 的从一个口头指控变成一句可用证据检验的陈述。原理是将一段已知的参考 CSI 信号喂入生产管线注意不是测试替身对输出做 SHA-256 哈希再与仓库中公布的期望哈希比对。任何行为漂移都会改变哈希从而让回归可证伪。3.2 源码视角验证脚本的内部工作流从源码看verify.py的主流程分为四步[0/4][4/4]源码溯源Source Provenance通过inspect.getfile()打印实际加载的CSIProcessor、CSIData、CSIFeatures的绝对路径以及 numpy/scipy 版本让任何人可以确认导入的是生产模块而非测试替身——这一设计直接服务于反 mock 指控。加载参考信号读取 sample_csi_data.json。该文件由 generate_reference_signal.py 生成包含 1,000 帧合成 CSI 数据3 天线、56 子载波、100 Hz 采样、10 秒其中建模了 0.3 Hz 呼吸调制、1.2 Hz 行走调制和 5 条确定性多径。所有参数由numpy.random.RandomState(42)一次性选定后固定生成过程不再使用任何随机性。验证时只取前VERIFICATION_FRAME_COUNT 100帧约 1 秒在覆盖时域动态Doppler 依赖历史帧的同时保持验证速度。跑真实管线用与生产一致的PROCESSOR_CONFIG构造CSIProcessor逐帧调用preprocess_csi_data()→extract_features()并把特征序列化为规范化字节流喂入 SHA-256。哈希比对并给出裁决输出VERDICT: PASS或VERDICT: FAIL失败时还会输出与参考向量的最大偏差并定位到具体特征块amp_mean/amp_var/phase_diff/corr/psd便于定位回归来源。其中PROCESSOR_CONFIG生产默认配置是理解该管线行为的关键参数表参数默认值含义sampling_rate100采样率Hzwindow_size56处理窗口大小对应 56 子载波overlap0.5滑窗重叠率noise_threshold-60噪声门限dBhuman_detection_threshold0.8人体检测置信门限smoothing_factor0.9平滑因子max_history_size500历史帧缓冲上限enable_preprocessing/enable_feature_extraction/enable_human_detectionTrue三个阶段开关3.3 哈希为什么能跨平台稳定量化精度与容差门这是整个 Proof 系统最精妙的技术点值得单独说明。源码注释对应 issue #560解释了背景scipy.fft的 pocketfft 内核在不同 SIMD 后端Intel AVX2/AVX-512 vs ARM NEON会以不同顺序重排浮点约简IEEE 754 只保证单次运算确定不保证重排后结合律一致。实测在 Ubuntu 24.04 / Python 3.11 / scipy 1.17 的连续两次 CI 运行中不同 Azure VM 微架构Skylake vs Cascade Lake会产出两个不同的 SHA-256。解决方案分两层量化features_to_bytes()在打包前对每个特征数组做np.round(flat, HASH_QUANTIZATION_DECIMALS)。量化精度默认 6 位小数可通过环境变量PROOF_HASH_DECIMALS覆盖在跨 Linux 微架构漂移之上留出约 6 个数量级余量同时远低于信号有意义的变化CSI 相位精度约 1e-3 rad。容差门由于哈希在跨平台Windows vs Linux上仍可能在个别元素跨越 6 位小数边界脚本额外提交了 expected_features_reference.npz 参考向量当位精确哈希不匹配时用np.allclose(computed, ref, rtol1e-4, atol1e-6)做相对容差比对。任一匹配即算通过哈希是同平台强证明容差是跨平台独立证明。值得注意的一个工程取舍doppler_shift特征被有意排除在哈希之外。原因是它做了峰值归一化spectrum / max(spectrum)当原始频谱出现近乎并列的峰值时argmax会因跨微架构浮点重排而翻转导致整个数组 O(1) 级漂移任何容差都无法吸收。其余五个特征幅值均值、幅值方差、相位差、相关矩阵、功率谱密度可确定性复现构成证明的主体。3.4 CLI 选项与哈希漂移处置选项作用--generate-hash重新计算并把期望哈希写入expected_features.sha256同时把参考向量写入 npz不比对--verbose打印详细特征统计、Doppler 频谱与 PSD 细节--audit扫描生产代码排除 tests/testing 目录中的np.random.*、random.random、mock/MagicMock/patch等可疑模式当哈希不匹配、且确认是合法的 numpy/scipy 升级导致的数值漂移时按技能文档的处置流程重新生成基准python archive/v1/data/proof/verify.py --generate-hash python archive/v1/data/proof/verify.py重新生成前应确认这不是真实的数值回归——verify.py在 FAIL 时会明确列出可能原因CSI 处理器代码改动改变了数值输出 / 真实的非微架构级数值回归。3.5 可选的 v1 Python 测试套件cd archive/v1 python -m pytest tests/ -x -q这是 Proof 的补充层-x遇错即停-q精简输出针对 Python 参考实现跑完整测试套件。4. 第三站ADR-028 见证包的生成与自验证4.1 生成见证包bash scripts/generate-witness-bundle.shgenerate-witness-bundle.sh 是一个set -euo pipefail的自包含脚本产出dist/witness-bundle-ADR028-commit短哈希.tar.gz。它的 7 个步骤恰好对应可独立复核的证据链步骤内容产物1/7拷贝见证文档WITNESS-LOG-028.md、ADR-028-esp32-capability-audit.md2/7拷贝证明系统proof/verify.py、expected_features.sha256、generate_reference_signal.py、reference_signal_metadata.json参考信号本体约 10MB只打包元数据3/7运行 Rust 全量测试并捕获输出test-results/rust-workspace-tests.log、test-results/summary.txt汇总 passed/failed/ignored4/7运行 Python Proof 验证proof/verification-output.log输出经scripts/redact-secrets.py清洗4b/7运行 CIR 确定性证明ADR-134proof/cir-verify.log、expected_cir_features.sha2565/7固件清单firmware-manifest/source-hashes.txtESP32 固件全部.c/.h的 SHA-256、source-line-counts.txt、supported-targets.txt、release_bins下 S3/C6 预编译 bin 哈希6/7crate 清单crate-manifest/versions.txt遍历v2/crates/*/Cargo.toml提取名称与版本6b/7npm 清单ADR-124npm-manifest/下ruvnet/rvagenttarball 的 sha256 与文件名7/7生成接收方验证脚本VERIFY.sh最后对所有文件生成MANIFEST.sha256并打包 tar.gz脚本中有一个值得注意的安全细节第 4 步的 Python 输出会先经scripts/redact-secrets.py清洗再写入日志。脚本注释说明verify.py在验证失败时会输出 Pydantic schema dump其中可能包含用户的.env内容Docker token、API key 等对应 ADR-110 wave 5 的事件记录。这也解释了为什么打包日志而非原始输出。4.2 一键自验证7/7 PASScd dist/witness-bundle-ADR028-*/ bash VERIFY.sh # 必须 7/7 PASSVERIFY.sh是写给接收方的自验证脚本接收方拿到 bundle 后无需信任任何声明只需运行它即可对照复验。脚本用check()函数累计 PASS/FAIL检查项包括见证文档存在WITNESS-LOG-028.md、ADR-028Proof 哈希文件存在并打印期望哈希Rust 测试汇总存在且0 failed固件源码哈希清单存在含文件计数crate 清单存在含 crate 计数npm tarball sha256 清单存在ruvnet/rvagentPython Proof 日志中存在VERDICT: PASSCIR Proof 日志ADR-134——PASS通过、BLOCKED占位哈希记为跳过脚本最终输出Results: N passed, M failed与VERDICT: ALL CHECKS PASSED (8/8)命令文档中的7/7指核心七项脚本实现实际含 CIR 相关子检查。需要说明当前 CIR 模块ADR-134尚未实现expected_cir_features.sha256仍是占位符因此verify-cir-proof.sh会输出BLOCKED并以退出码 2 结束VERIFY.sh将该项按跳过处理——这是仓库中诚实标注的已知缺口。5. 见证日志能力声明与证据的对照矩阵见证包的核心文档是 WITNESS-LOG-028.md它记录了审计时刻的 35 行能力证明矩阵每一行都遵循Claimed / Verified / Evidence三段式结构。例如ESP32-S3 CSI 帧解析ADR-018 二进制格式32 个 Rust 测试、esp32_parser.rs385 行Hampel 离群滤波hampel.rs240 行测试通过Fresnel 区呼吸模型fresnel.rs448 行测试通过确定性证明系统PASS哈希8c0680d7...匹配54,000 fps 实测吞吐NOT MEASURED——Criterion 基准存在但审计时未运行日志中同样诚实标注了未实现项如ESP32 端 ML 推理为 NO固件只流式传输原始 I/Q推理在聚合端、真实 CSI 数据集随包提供为 NO仅 seed42 合成参考信号。这种把缺口写进矩阵的做法与 CLAUDE.md 的声明规则一致是理解 RuView 可信度模型的关键。日志末尾给出三类使用指南开发者按 Step 2-8 复现测试审查者按 Step 2-10无需硬件复核软件声明并重点检查矩阵中标记YES的行硬件测试者按 Step 11 用 esptool 向 ESP32-S3 烧录固件。6. 合并前检查清单Pre-merge Checklist/ruview-verify的第三层职责是如果本次调用发生在代码变更之后应逐项走完来自 CLAUDE.md 的合并前检查清单。完整清单如下Rust 测试通过1,400、0 失败Python Proof 通过VERDICT: PASS作用域变更时更新README.md平台/crate/硬件表格、功能摘要作用域变更时更新CLAUDE.mdcrate 表、ADR 列表、模块表、版本CHANGELOG.md在[Unreleased]下新增条目新增数据源/CLI 标志/安装步骤时更新docs/user-guide.md新增 ADR 时在 README 文档表中递增 ADR 计数测试或 Proof 哈希变化时重新生成见证包仅当 Dockerfile/依赖/运行时行为变化时才重建 Docker Hub 镜像仅当已发布 crate 的公共 API 变化时才发布 crate按依赖顺序发布为新增构建产物/二进制更新.gitignore对触及硬件/网络边界的模块做安全审查这套清单的价值在于精确限定变更波及面不是全部重做而是哪些变了才动哪些——例如 Docker 镜像和 crate 发布都被明确标注为条件性动作避免无谓的全局重建。7. 安全扫描与 QEMU 固件 CI对于安全相关变更命令还要求额外执行npx claude-flow/clilatest security scan与之配套的参考资料包括 安全审计文档、QE 报告目录ADR-080 QE 修复计划、ADR-093 仪表盘差距分析。此外固件侧有独立的 QEMU CI 通道ADR-061CI 中 11 任务工作流 Firmware QEMU Tests本地可用 qemu-esp32s3-test.sh、qemu-mesh-test.sh、qemu-chaos-test.sh、qemu-snapshot-test.sh 与 install-qemu.sh 复现。技能文档给出的实操经验espressif/idf:v5.4容器在pip前需先source $IDF_PATH/export.shQEMU 需用esptool merge_bin --fill-flash-size 8MB无真实 WiFi 的 WARN 在 CI 中被视为 OK。这些细节表明验证体系对模拟器证据不等于硬件证据有清醒边界——CLAUDE.md 明确要求硬件验证必须来自真实硅片的启动/运行日志。8. 实战指引何时运行与典型故障处置何时运行ruview-verify默认all任何有意义的代码变更之后合并 PR 之前作为门禁需要向接收方/审查方提供可验证证明包时此时bundle是重点典型故障与处置现象原因与处置verify.py输出VERDICT: FAIL先确认是否真实回归查看DIVERGENCE段的最大偏差与超差特征块amp_mean/psd等若确为合法的 numpy/scipy 升级漂移--generate-hash后重跑并重新生成见证包verify-cir-proof.sh输出BLOCKEDCIR 模块ADR-134未实现属已知占位状态实现落地后需按提示用cir_proof_runner --generate-hash重新生成并提交哈希见证包VERIFY.sh出现 FAIL对照MANIFEST.sha256与各子项日志定位缺失/漂移文件修正后重新generate-witness-bundle.shRust 全量测试超时或失败先收敛到单 cratecargo test -p crate --no-default-features定位再回到全量一条纪律贯穿始终CLAUDE.md 要求仅在分类为瞬时失败或变更单一因果变量后重试不在不变证据上循环——验证失败时应先定位根因而不是盲目重跑。9. 总结从声称到可证伪/ruview-verify把 RuView 的工程质量主张压缩成三条可复现命令全量 Rust 测试证明代码能跑、SHA-256 Proof 证明生产管线确定且未被 mock、ADR-028 见证包证明整条证据链可移交、可复核。其设计哲学贯穿源码与文档源码溯源打印、量化与容差双轨哈希、秘密清洗、诚实标注 NOT MEASURED 的能力矩阵——每一层都在回答同一个问题你凭什么相信这个声称 对于希望在自己的项目里建立可验证 CI 门禁的工程师这套测试 确定性证明 见证包的组合是一个完整且可移植的参考范式。相关材料可从 命令定义、技能全文、验证脚本、见证包生成器 与 见证日志 继续深入阅读。【免费下载链接】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），仅供参考