RuView 信任流水线验证指南：Rust 全量测试、确定性证明与 ADR-028 见证包

RuView 信任流水线验证指南：Rust 全量测试、确定性证明与 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 仓库中 ruview-verify 操作提示词 展开，系统讲解其定义的"信任流水线（trust pipeline）"：如何在一个构建（build）上依次执行 Rust 工作区全量测试、Python 确定性"证明重放"（Trust Kill Switch）与 ADR-028 见证包生成/自校验，并在代码变更后走完发布前的完整核对清单。读完本文，你将掌握 RuView 一整套可复现、可被第三方独立复核的构建验证与交付证明流程，以及每个命令背后的源码级原理。

一、信任流水线是什么

RuView 是一个基于商品 WiFi 信号的无线感知系统（活跃实现为 v2 下的 Rust 工作区，历史参考实现位于archive/v1/），其核心卖点之一是可验证性：任何"它是 mock 的 / 数据是假的"的质疑，都可以用一条命令的重放来证伪。

ruview-verify把这种可验证性落地为一条可执行的信任流水线，其作用域由$ARGUMENTS控制，可取tests、proof、bundle、all四者之一，默认all：

该提示词是 Codex 侧的 operator 命令；仓库中同一能力的其他镜像实现还包括 Claude Code 插件命令 与 ruview-verify 技能定义，由plugins/ruview/scripts/smoke.sh保证二者逐字对齐。本文以下各节即按tests → proof → bundle → all的顺序逐一展开。

二、tests：Rust 工作区全量测试

2.1 标准命令与判定阈值

cd v2 cargo test --workspace --no-default-features

执行结果必须满足1,400+ passed、0 failed，常规耗时约 2 分钟。注意两点关键约束：

• --no-default-features：RuView 各 crate 默认不启用额外特性集，这一开关确保测试的是最基础、可移植的代码路径；
• --workspace：覆盖 v2 工作区 下的全部 crate（signal、train、nn、hardware、vitals、mat、wasm 等），而非单个包。

这一命令同时被仓库根目录的 verify 多阶段脚本 以 Phase 3 引用，并在其中默认追加--exclude cog-pose-estimation（其smoke集成测试在 Windows 上会因文件锁冲突失败，Linux CI 完全绿色），可以通过环境变量RUVIEW_RUST_EXCLUDE=""覆盖。

2.2 单 crate 快速迭代

在开发迭代阶段，不必每次跑全量，可以使用包级命令：

cargo test -p wifi-densepose-signal --no-default-features # 信号处理 crate cargo check -p wifi-densepose-train --no-default-features # 训练 crate（无需 GPU 的编译检查）

从 ADR-028 见证记录 的能力矩阵可见这些 crate 的测试覆盖重点：wifi-densepose-signal覆盖 Hampel 离群滤波、Fresnel 呼吸模型、BVP 速度谱、STFT 频谱、相位解卷与硬件归一化；wifi-densepose-hardware覆盖 ADR-018 二进制帧解析（魔数0xC5110001校验、截断帧拒绝、多天线帧）；wifi-densepose-train覆盖 MERIDIAN 域泛化与确定性复现。

三、proof：Python 确定性证明（Trust Kill Switch）

3.1 运行方式与判定标准

cd .. python archive/v1/data/proof/verify.py

该命令必须打印VERDICT: PASS。它的原理是：把一份已发布的参考 CSI 信号送入生产代码（非测试替身）的完整特征提取流水线，对输出做规范化序列化后计算 SHA-256，再与仓库中提交的期望哈希比对——任何行为漂移都会改变哈希，从而立刻暴露回归。

可选的补充步骤是运行 v1 Python 测试套件：

cd archive/v1 && python -m pytest tests/ -x -q

3.2 源码级原理：哈希如何做到跨平台确定

阅读 verify.py 可以还原整个证明链路：

1. 加载参考信号：读取archive/v1/data/proof/sample_csi_data.json（1,000 帧合成 CSI，seed=42，由generate_reference_signal.py生成），仅取前 100 帧（约 1 秒）参与哈希，既保证速度又覆盖时序动态（Doppler 需要历史帧）。
2. 运行生产流水线：使用与生产一致的PROCESSOR_CONFIG（sampling_rate=100、window_size=56、overlap=0.5、noise_threshold=-60dB、human_detection_threshold=0.8、smoothing_factor=0.9、max_history_size=500），逐帧调用CSIProcessor.preprocess_csi_data()与extract_features()。
3. 规范化序列化：将 5 个特征数组（amplitude_mean、amplitude_variance、phase_difference、correlation_matrix、power_spectral_density）量化为 6 位小数后按小端 float64 打包。doppler_shift被刻意排除——它是峰值归一化的，在跨微架构的浮点重排下argmax可能翻转，导致 O(1) 量级的不稳定（见源码注释，属已知的可复现性边界）。
4. 哈希比对与容差回退：位精确的 SHA-256 只在同一 CPU 微架构内成立（scipy pocketfft/BLAS 内核在 AVX2/AVX-512/NEON 下对浮点归约的重排不同）；因此当哈希不匹配时，脚本会回退到与提交的参考向量expected_features_reference.npz做rtol=1e-4 / atol=1e-6的相对容差比较——该容差约为观测到的微架构漂移的 100 倍、信号有意义变化的 1/10，保证真实回归仍会失败。量化精度可通过环境变量PROOF_HASH_DECIMALS覆盖。

此外脚本提供三个辅助参数：

python archive/v1/data/proof/verify.py --verbose # 输出特征统计、Doppler 频谱与 PSD 细节 python archive/v1/data/proof/verify.py --audit # 扫描生产代码中的 mock/random 模式 python archive/v1/data/proof/verify.py --generate-hash # 重新生成期望哈希（罕见操作）

--audit会遍历archive/v1/src/（排除testing、tests、test目录），查找np.random.*、random.*、Mock、@patch等可疑模式——这是"无随机性"承诺的代码级扫描。

3.3 哈希漂移后的处理

如果是在一次正当的 numpy/scipy 版本升级后出现哈希不匹配（即确认不是代码回归），按提示词给出的流程处理：

python archive/v1/data/proof/verify.py --generate-hash python archive/v1/data/proof/verify.py

首条命令会把当前计算出的哈希写入archive/v1/data/proof/expected_features.sha256，并同时输出参考向量；第二条命令重新验证。注意：这一操作只应在确认"代码未变、仅依赖数值环境变化"时执行；真实回归必须排查而不是重新生成哈希。

四、bundle：ADR-028 见证包生成与自校验

4.1 生成见证包

bash scripts/generate-witness-bundle.sh

脚本（generate-witness-bundle.sh）基于当前提交生成dist/witness-bundle-ADR028-<sha8>.tar.gz，内容编排如下：

4.2 接收方自校验

cd dist/witness-bundle-ADR028-*/ bash VERIFY.sh

提示词文档要求结果必须为 7/7 PASS。需要说明的是：生成的VERIFY.sh实际枚举的检查项会随 ADR-134 CIR 证明的加入而多于七项（脚本最终打印VERDICT: ALL CHECKS PASSED (8/8)），核心判据始终是FAIL_COUNT == 0，其中任何一项失败都必须调查而不是放行。

这些检查项包括：见证文档存在性、证明哈希文件存在性、Rust 测试汇总中0 failed、固件源码哈希清单、crate 清单、npm tarball 哈希、Python 证明日志包含VERDICT: PASS、CIR 证明日志通过或被显式标记为BLOCKED（占位哈希场景）。

4.3 见证记录本身是什么

WITNESS-LOG-028.md 是对仓库能力的一次时点见证（point-in-time attestation），包含：见证头（审计提交96b01008、审计时 1,031 项测试通过）、可复现的验证步骤（每一步都给出确切命令与期望输出）、35 行能力证明矩阵（每行独立可验证，且诚实标注NO/NOT MEASURED的未实现项），以及密码学锚点表（Python 证明哈希、CIR 哈希、校准证明哈希、ESP32 帧魔数0xC5110001）。配套的 ADR-028 记录了完整的审计方法论（硬件 / 信号-AI / 部署三个并行 agent）与确认的能力清单。

五、all：完整流水线

all就是把前三节按tests → proof → bundle的顺序依次执行，作为一次构建交付前的完整把关。这也是 verify 根脚本 的设计思路，不过后者扩展为九阶段的多层证明（Python 哈希重放、生产代码随机性扫描、Rust 测试、PyO3 BFLD 绑定编译、ADR-125 隐私不变量、crates.io/npm/Docker 发布物核查），并支持--quick、--rust-only、--docker-only等子集模式。

六、代码变更后的 Pre-merge 核对清单

若本次验证发生在一次代码变更之后，提示词要求按 CLAUDE.md 的发布前核对清单逐项走查（ruview-verify 技能 中整理为 12 项）：

1. Rust 测试通过（1,400+，0 失败）；
2. Python 证明通过（VERDICT: PASS）；
3. README.md在作用域变化时更新（平台 / crate / 硬件表格、功能摘要）；
4. CLAUDE.md在作用域变化时更新（crate 表、ADR 列表、模块表、版本）；
5. CHANGELOG.md在[Unreleased]下新增条目；
6. docs/user-guide.md 在新增数据源 / CLI 参数 / 安装步骤时更新；
7. 新增 ADR 时在 README 的文档表中递增 ADR 计数；
8. 测试或证明哈希变化时重新生成见证包；
9. 仅在 Dockerfile / 依赖 / 运行时行为变化时才重建 Docker 镜像；
10. 仅当已发布 crate 的公共 API 变化时才发布 crate，且按依赖顺序发布（见 CLAUDE.md）；
11. .gitignore覆盖新增的构建产物 / 二进制；
12. 对触及硬件 / 网络边界的新模块进行安全评审。

七、安全扫描与固件 CI

对安全相关的变更，额外执行：

npx @claude-flow/cli@latest security scan

此外，ADR-061 定义了 QEMU 固件 CI（"Firmware QEMU Tests" 工作流），本地调试可借助仓库内的辅助脚本：

• scripts/qemu-esp32s3-test.sh — ESP32-S3 单节点测试
• scripts/qemu-mesh-test.sh — 多节点 mesh 测试
• scripts/qemu-chaos-test.sh — 混沌/故障注入测试
• scripts/qemu-snapshot-test.sh — 快照测试
• scripts/install-qemu.sh — QEMU 环境安装

实操要点（来自 ruview-verify 技能）：espressif/idf:v5.4容器在pip之前需要先source $IDF_PATH/export.sh；QEMU 烧录需要esptool merge_bin --fill-flash-size 8MB；CI 中无真实 WiFi 的 WARN 视为通过。注意 QEMU 只能证明固件逻辑与启动行为，硬件级验证仍需真实芯片的运行日志——这是 CLAUDE.md 中"非协商规则"的明确要求。

八、实践建议与证据延伸

• 把all作为发布门槛：在合并 PR 之前执行一次完整流水线，让"可验证"成为事实而非口号；
• 区分哈希重放与回归：proof失败时先判断是依赖数值环境漂移（走--generate-hash）还是真实代码回归（必须修复）；
• 让接收方自证：交付时附上见证包并引导对方运行VERIFY.sh，实现"无需信任发布者"的独立复核。

想深入理解本流水线各环节的底层实现，可以继续阅读以下文件：

• 信任流水线定义：plugins/ruview/codex/prompts/ruview-verify.md、plugins/ruview/commands/ruview-verify.md、plugins/ruview/skills/ruview-verify/SKILL.md
• 确定性证明实现：archive/v1/data/proof/verify.py、参考信号 sample_csi_data.json、期望哈希 expected_features.sha256
• 见证包生成：scripts/generate-witness-bundle.sh
• 见证记录与审计报告：docs/WITNESS-LOG-028.md、docs/adr/ADR-028-esp32-capability-audit.md
• 九阶段总控脚本：verify
• 仓库规则与核对清单来源：CLAUDE.md

【免费下载链接】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