RuView 可复现见证审计全指南：以 SHA-256 证据链核验 WiFi CSI 感知能力（解读 WITNESS-LOG-028 / ADR-028 ESP32 能力审计）

导读

WITNESS-LOG-028 是 RuView（WiFi-DensePose）项目在特定 commit 上做的一次"机器可验证"仓库能力审计记录：它把 ESP32 CSI 感知链路上的每一项能力声明（从固件解析到神经网络、从信号算法到灾难检测），映射成可直接重跑的具体命令 + 预期输出 + SHA-256 密码学锚点。阅读本文后，你将掌握一套"克隆→检出→跑测试→比对哈希"的独立核验流程，能够亲自复现这份审计、读懂能力矩阵中 YES / NO / NOT MEASURED 三态语义所代表的诚实边界，并把同一套确定性证明方法复用到你自己的传感项目中。

本日志全文位于 docs/WITNESS-LOG-028.md，其对应架构决策见 ADR-028 ESP32 能力审计。

见证日志的本质：把"声明的能力"变成"可证伪的声明"

绝大多数开源项目的 README 都写满了能力，但缺少一种让第三方独立证伪的机制。WITNESS-LOG-028 的出发点（日志开头即声明）正相反：

Purpose: Machine-verifiable attestation of repository capabilities at a specific commit. Third parties can re-run these checks to confirm or refute each claim independently.

整份日志围绕四个原则组织：

1. 锚定 commit：所有结论都绑定唯一见证 commit 96b01008f71f4cbe2c138d63acb0e9bc6825286e，而不是笼统的"当前主分支"；
2. 命令可重放：每步给出精确 shell 命令与预期输出，任何人可复制执行；
3. 密码学固化：Python 管线、CIR 估计、空房间标定三组输出分别以 SHA-256 哈希落盘，代码一改哈希即变，篡改与漂移都会暴露；
4. 三态诚实披露：能力矩阵不只有"YES"，还明确标出 NO（未实现）与 NOT MEASURED（有基准但审计时刻未运行），刻意隐藏缺口会破坏整个证明体系的可信度。

仓库根目录的 verify 脚本把这一思想命名为 "Trust Kill Switch（信任杀手开关）"，它一次性串起 Python 管线哈希、生产代码 mock 扫描、Rust 工作区测试、PyO3 绑定、隐私不变量、crates.io / npm / Docker 发布物九大阶段。本文详解的 witness 日志，本质是同一方法论在 ESP32 能力主题上的单点深入审计。

审计快照的头部信息与演进提示

先看日志的 Attestation Header（见证头）：

字段	值	解读
Date	2026-03-01T20:44:05Z	审计执行时刻
Commit	96b01008...	结论绑定的唯一代码状态
Auditor	Claude Opus 4.6（automated 3-agent parallel audit）	3 个并行自动化代理交叉核验
Rust Toolchain	Stable（edition 2021）	编译环境前提
Workspace Version	0.2.0	当时工作区版本
Test Result	1,031 passed, 0 failed, 8 ignored	全工作区测试计数
ESP32 Serial Port	COM7（user-confirmed）	硬件验证依赖人工确认的串口

重要前提提示（基于当前仓库比对）：这份日志是 2026-03-01 在 commit 96b01008 上的历史快照。当前仓库 HEAD 已是 c4021f98，v2/Cargo.toml 中 workspace 版本已推进到 0.3.1，成员 crate 数量也远超当时"15 crates"；firmware/esp32-csi-node/main/ 目录现包含 50+ 个 C/H 文件（新增了 OTA、显示、毫米波、WASM、热管理等组件），esp32_parser.rs 已从审计记录的 385 行演进到约 579 行。因此复现本文命令时，行数、测试计数等精确数字应以当时提交为准、以实际输出为准——这正是"绑定 commit"的价值：哈希与数字只对它们锚定的那一次代码状态负责。

可复现验证步骤详解（软件层）

Step 1 — 检出见证 commit

git clone https://gitcode.com/GitHub_Trending/wi/RuView.git
cd RuView
git checkout 96b01008

git checkout 96b01008（可写全 40 位 SHA 96b01008f71f4cbe2c138d63acb0e9bc6825286e）保证之后所有验证都针对审计所看到的同一份代码。

Step 2 — Rust 工作区全量测试

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

预期输出：1,031 passed, 0 failed, 8 ignored（覆盖全部 15 个 crate）。--no-default-features 是关键参数：它剥离默认特性，验证最小核心路径的可编译性与正确性，降低对系统依赖（如 BLAS、CUDA）的耦合。

测试按 crate 家族的分布是理解代码布局的捷径：

Crate Group	Tests	覆盖主题
wifi-densepose-signal	105+	信号处理（Hampel、Fresnel、BVP、频谱图、相位、运动）
wifi-densepose-train	174+	训练管线、指标、损失、数据集、模型、证明、MERIDIAN
wifi-densepose-nn	23	神经网络推理、DensePose head、translator
wifi-densepose-mat	153	灾害检测、检伤分诊、定位、告警
wifi-densepose-hardware	32	ESP32 解析器、CSI 帧、桥接、聚合器
wifi-densepose-vitals	计入全量	呼吸、心率、异常检测
wifi-densepose-wifiscan	计入全量	WiFi 扫描适配器（Windows/macOS/Linux）
Doc-tests（全 crate）	11	文档内联示例即测试

这一分层与 v2/Cargo.toml 的 workspace members 一一对应，cargo test -p <crate> 可以精确到单 crate 重跑。

Step 3 — 发布版本核验（在线校验）

for crate in core config db signal nn api hardware mat train ruvector wasm vitals wifiscan sensing-server cli; do
  echo -n "wifi-densepose-$crate: "
  curl -s "https://crates.io/api/v1/crates/wifi-densepose-$crate" | grep -o '"max_version":"[^"]*"'
done

预期：全部返回 "max_version":"0.2.0"。这一步确认"代码在 crates.io 上确实发布过、且版本与工作区一致"，防止仓库内有一份、线上发布物是另一份的割裂。仓库根目录的 verify Phase 6 实现了同款在线核验逻辑，并同时检查了 npm 包（Phase 7）与 Docker 多架构清单（Phase 8）。此类步骤依赖外网注册表，离线时可直接跳过，不影响本地确定性验证。

Step 4 / 5 — 固件源码与预编译产物

ls firmware/esp32-csi-node/main/*.c firmware/esp32-csi-node/main/*.h
wc -l firmware/esp32-csi-node/main/*.c firmware/esp32-csi-node/main/*.h

审计时刻的固件由 7 个文件、共 606 行组成：

• 实现：main.c（144）、csi_collector.c（176）、stream_sender.c（77）、nvs_config.c（88）
• 头文件：csi_collector.h（38）、stream_sender.h（44）、nvs_config.h（39）

功能划分清晰：main.c 负责启动与任务编排，csi_collector.c 采集 CSI（信道状态信息）I/Q 数据，stream_sender.c 负责 UDP 上送，nvs_config.c 管理 NVS（非易失存储）配置。当前仓库此目录已大幅扩充（新增 ota_update、display_*、mmwave_sensor、rv_mesh、wasm_runtime、thermal、power_mgmt 等模块），审计记录的是最小核心 7 文件的基线形态。

预编译产物核验：

ls firmware/esp32-csi-node/build/bootloader/bootloader.bin
ls firmware/esp32-csi-node/build/*.bin 2>/dev/null || echo "App binary in build/esp32-csi-node.bin"

预期 bootloader.bin 存在，应用镜像位于 build 目录。仓库同时维护了 firmware/esp32-csi-node/release_bins/ 用于发布固件产物。

Step 6 — ADR-018 二进制帧解析器

cd v2
cargo test -p wifi-densepose-hardware --no-default-features

预期 32 个测试通过。帧解析是整条链路的入口契约，代表用例及其语义：

• parse_valid_frame — 校验帧魔数 0xC5110001 与字段提取正确性；
• parse_invalid_magic — 拒绝非 CSI 数据（魔数不符直接丢弃）；
• parse_insufficient_data — 拒绝截断帧（长度不足报错而非越界）；
• multi_antenna_frame — 覆盖 MIMO 多天线配置；
• amplitude_phase_conversion — I/Q 复数 →（幅度，相位）的数学转换；
• bridge_from_known_iq — hardware crate → signal crate 的跨层桥接。

实现位于 esp32_parser.rs，其二进制帧格式由 ADR-018 ESP32 设备实现 定义。魔数 0xC5110001 同时被记录在密码学锚点表中，作为线上帧协议的可检索标识。

Step 7 — 信号处理算法

cargo test -p wifi-densepose-signal --no-default-features

预期 105+ 测试通过。这些算法是把"原始 I/Q 包"翻译成"人体活动可读信号"的核心，全部有独立模块与测试（括号内为当前仓库文件，行数较审计时刻已随演进增长）：

能力	审计记录模块	当前源码
Hampel 离群滤波	hampel.rs（240 行）	hampel.rs（约 291 行）
SpotFi 相位校正（共轭相乘）	csi_ratio.rs（198 行）	csi_ratio.rs（约 257 行）
Fresnel 菲涅尔区呼吸模型	fresnel.rs（448 行）	fresnel.rs（约 452 行）
BVP 身体速度轮廓提取	bvp.rs（381 行）	bvp.rs（约 405 行）
STFT 频谱图（4 种窗函数）	spectrogram.rs（367 行）	spectrogram.rs（约 519 行）
硬件归一化（ESP32-S3 → 56 子载波）	hardware_norm.rs（399 行）	hardware_norm.rs（约 511 行）

覆盖的测试面包括：Hampel 滤波、Fresnel 呼吸建模、BVP 提取、STFT 频谱生成、相位清洗与解卷绕、以及硬件归一化——把不同芯片（ESP32-S3 等）采集到不同子载波数的 CSI 统一到规范的 56 子载波，是多芯片支持的关键一环。

Step 8 — MERIDIAN 跨环境域泛化（ADR-027）

cargo test -p wifi-densepose-train --no-default-features

预期 174+ 测试通过，其中代表用例直接对应 ADR-027 跨环境域泛化：

• domain_within_configured_ranges — 虚拟域参数被限制在配置边界内；
• augment_frame_preserves_length — 数据增强不改输出形状；
• augment_frame_identity_domain_approx_input — 恒等变换 ≈ 原输入（增强的保守性）；
• deterministic_same_seed_same_output — 同种子可复现；
• adapt_empty_buffer_returns_error — 空输入返回 Result::Err 而非 panic；
• adapt_zero_rank_returns_error — 非法配置同样安全失败；
• buffer_cap_evicts_oldest — 有界内存：最多缓存 10,000 帧，超出驱逐最旧。

这些测试验证了 MERIDIAN 三件套——梯度反转层（domain.rs，约 439 行）、几何条件 FiLM（geometry.rs，约 474 行，Fourier 特征 + DeepSets + FiLM）、虚拟域增强（virtual_aug.rs，约 382 行），以及快速自适应/测试时训练 TTT（rapid_adapt.rs，约 580 行）。尤其注意后三个用例的 Result 返回 + 有界缓冲设计：这保证了域自适应模块在真实边缘设备上遇到冷启动或异常输入时优雅降级，而不是把进程打崩。

密码学确定性证明系统：把"没造假"变成可执行事实

Step 9 — v1 Python 证明系统

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

预期输出：

VERDICT: PASS
Pipeline hash: 8c0680d7d285739ea9597715e84959d9c356c87ee3ad35b5f1e69a4ca41151c6

verify.py 自称 "TRUST KILL SWITCH"，其运行逻辑是：

1. 从 sample_csi_data.json 加载一份公开的合成参考信号（由 generate_reference_signal.py 生成，固定 seed=42）；
2. 让真实特征提取代码逐帧处理该参考信号；
3. 把全部特征输出序列化为规范字节表示；
4. 计算整条管线的 SHA-256，与提交的 expected_features.sha256 比对。

这里的反直觉要点在脚本注释中讲得很透：参考信号是合成的不要紧，重点是处理它的"管线代码"是真的——同一套代码也处理线上实时捕获。因此若有人声称"这是 mock 的"，只需运行 python verify.py：PASS 即证明产出该哈希的代码与仓库内代码逐字节一致，FAIL 即说明有东西变了、必须解释。

运行环境要求 numpy 2.4.2 + scipy 1.17.1（Python 3.13），审计时刻该哈希按上述精确版本重新生成过。相关校验文件 expected_features_reference.npz、sample_csi_meta.json 与各 .sha256 文件均保存在 archive/v1/data/proof/ 目录。

Step 10 — Docker 镜像核验（在线校验）

docker pull ruvnet/wifi-densepose:latest
docker inspect ruvnet/wifi-densepose:latest --format='{{.Size}}'   # 预期约 132 MB
docker pull ruvnet/wifi-densepose:python
docker inspect ruvnet/wifi-densepose:python --format='{{.Size}}'   # 预期约 569 MB

两个镜像分别承载 Rust 二进制运行时与 Python 工具链，尺寸声明差异巨大（132 MB vs 569 MB）恰恰用于交叉验证镜像内容构成是否符合预期。此步依赖 Docker Hub 在线拉取。

Step 10b — CIR 确定性证明（ADR-134）与同类标定证明（ADR-135）

bash scripts/verify-cir-proof.sh

审计时刻该脚本预期输出 VERDICT: PASS (CIR hash matches)，但当时由于 expected_cir_features.sha256 内含占位符而输出 BLOCKED——这是证明系统"诚实"的又一体现：功能未落地前，验证脚本宁可直接拒绝，也不用假哈希糊弄。查看 scripts/verify-cir-proof.sh 源码可以看到明确的退出码契约：

• 0 — VERDICT: PASS（哈希匹配）；
• 1 — VERDICT: FAIL（哈希不匹配或构建失败）；
• 2 — BLOCKED（检测到占位符 PLACEHOLDER_REGENERATE，模块尚未实现）。

当 ADR-134 CSI 到 CIR 时域多径 的 cir 模块实现落地后，需重新生成并提交哈希：

cd v2 && cargo run -p wifi-densepose-signal --bin cir_proof_runner \
  --release --no-default-features -- --generate-hash \
  > ../archive/v1/data/proof/expected_cir_features.sha256

同样的机制已延伸至 ADR-135 空房间基线标定（Welford 在线统计 + von Mises 相位分布），由 verify-calibration-proof.sh 复现（脚本注释记录了其确定性输入：xorshift32 seed=42、HT20、600 帧静止数据），哈希锚定在 expected_calibration_features.sha256，重建命令使用 calibration_proof_runner。当前仓库中这两个哈希文件均已填写真实值（CIR：304d5469...，Calibration：d6bce07e...），表明两模块的证明链已在后续提交中打通。

ESP32 硬件验证与烧录（Step 11）

硬件验证是唯一需要真实设备的一步。ESP32-S3-DevKitC-1（约 $10 的开发板）即可：

pip install esptool
python -m esptool --chip esp32s3 --port COM7 chip_id
# 预期：返回 ESP32-S3 chip ID

# 完整烧录（可选）
python -m esptool --chip esp32s3 --port COM7 --baud 460800 \
  write_flash --flash_mode dio --flash_size 4MB \
  0x0 firmware/esp32-csi-node/build/bootloader/bootloader.bin \
  0x8000 firmware/esp32-csi-node/build/partition_table/partition-table.bin \
  0x10000 firmware/esp32-csi-node/build/esp32-csi-node.bin

烧录布局遵循 ESP-IDF 标准三段式：0x0 bootloader、0x8000 分区表、0x10000 应用镜像，--baud 460800 提高烧录速度，--flash_mode dio 与 --flash_size 4MB 需与板卡实际 flash 配置一致。上电后固件会把采集的原始 I/Q 数据经 UDP 上送聚合器：

cargo run -p wifi-densepose-hardware --bin aggregator
# 观察 UDP 5005 端口上的 CSI 帧流

值得注意的是，能力矩阵第 31 行明确标注板端 ML 推理为 NO：固件只做原始 I/Q 采集与上送，DensePose 等推理全部在聚合器/服务端完成——这是架构边界的诚实声明，不是疏漏。

能力矩阵全表：35 项声明逐一可验证

矩阵每一行都可独立复核，"Status" 反映审计时刻的真实发现。完整列表如下：

#	能力	Claimed	Verified	证据要点（审计时刻）
1	ESP32-S3 CSI 帧解析（ADR-018 二进制格式）	Yes	YES	32 个 Rust 测试，esp32_parser.rs（385 行）
2	ESP32 固件（C，ESP-IDF v5.2）	Yes	YES	firmware/esp32-csi-node/main/ 共 606 行
3	预编译固件二进制	Yes	YES	bootloader.bin + build/ 下应用镜像
4	多芯片支持（ESP32-S3、Intel 5300、Atheros）	Yes	YES	HardwareType 枚举、自动探测、Catmull-Rom 重采样
5	UDP 聚合器（多节点流式）	Yes	YES	aggregator/mod.rs、loopback UDP 测试
6	Hampel 离群滤波	Yes	YES	hampel.rs（240 行），测试通过
7	SpotFi 相位校正（共轭相乘）	Yes	YES	csi_ratio.rs（198 行），测试通过
8	Fresnel 菲涅尔区呼吸模型	Yes	YES	fresnel.rs（448 行），测试通过
9	Body Velocity Profile 提取	Yes	YES	bvp.rs（381 行），测试通过
10	STFT 频谱图（4 种窗函数）	Yes	YES	spectrogram.rs（367 行），测试通过
11	硬件归一化（MERIDIAN Phase 1）	Yes	YES	hardware_norm.rs（399 行），10+ 测试
12	DensePose 神经网络（24 部位 + UV）	Yes	YES	densepose.rs（589 行），nn crate 测试
13	17 个 COCO 关键点检测	Yes	YES	nn crate 的 KeypointHead，热图回归
14	10 阶段训练管线	Yes	YES	14 个模块共 9,051 行
15	RuVector v2.0.4 集成（5 crates）	Yes	YES	5 个 crate 全部进入工作区，用于 metrics/model/dataset/subcarrier/bvp
16	梯度反转层（ADR-027）	Yes	YES	domain.rs（400 行），对抗调度测试
17	几何条件 FiLM（ADR-027）	Yes	YES	geometry.rs（365 行），Fourier + DeepSets + FiLM
18	虚拟域增强（ADR-027）	Yes	YES	virtual_aug.rs（297 行），确定性测试
19	快速自适应 / TTT（ADR-027）	Yes	YES	rapid_adapt.rs（317 行），有界缓冲、Result 返回
20	对比自监督学习（ADR-024）	Yes	YES	model.rs 中投影头、InfoNCE + VICReg
21	生命体征检测（呼吸 + 心跳）	Yes	YES	vitals crate（1,863 行），6–30 BPM / 40–120 BPM
22	WiFi-MAT 灾害响应（START 检伤分诊）	Yes	YES	mat crate，153 测试，检测+定位+告警
23	确定性证明系统（SHA-256）	Yes	YES	PASS — 哈希 8c0680d7... 匹配（numpy 2.4.2, scipy 1.17.1）
24	crates.io 发布 15 crates @ v0.2.0	Yes	YES	2026-03-01 全部发布
25	Docker Hub 镜像	Yes	YES	:latest（132 MB）、:python（569 MB）
26	WASM 浏览器部署	Yes	YES	wasm crate + wasm-bindgen + Three.js
27	跨平台 WiFi 扫描（Win/Mac/Linux）	Yes	YES	wifiscan crate，#[cfg(target_os)] 适配器
28	4 条 CI/CD 工作流（CI、security、CD、verify）	Yes	YES	.github/workflows/
29	27 份架构决策记录	Yes	YES	docs/adr/ADR-001 至 ADR-027
30	1,031 个 Rust 测试通过	Yes	YES	审计时刻 cargo test --workspace --no-default-features
31	板端 ESP32 ML 推理	No	NO	固件仅上送原始 I/Q，推理在聚合器端
32	打包真实 CSI 数据集	No	NO	仅有合成参考信号（seed=42）
33	实测 54,000 fps 吞吐	Claimed	NOT MEASURED	Criterion 基准存在但审计时刻未运行
34	CIR 估计（ADR-134，ISTA via NeumannSolver）	Yes	PASS	expected_cir_features.sha256 + verify-cir-proof.sh
35	空房间基线标定（ADR-135，Welford + von Mises）	Yes	PASS	expected_calibration_features.sha256 + verify-calibration-proof.sh

如何读这张表：前 30 行的证据（测试名、模块、行数）大多仍可在当前仓库源码中定位——例如 hampel.rs、fresnel.rs、hardware_norm.rs 等信号模块与 vitals、mat、train 各 crate 均持续演进维护；第 31–33 行则揭示了刻意不承诺的部分：板端推理缺位、无真实数据集打包、吞吐基准有代码但未经权威测量。第 34、35 行还给出了"故意改动后如何重新生成证明"的标准动作（--generate-hash 重写 .sha256），把能力变更纳入版本控制。

密码学锚点表：用固定值固化证据链

Anchor	Value
Witness commit SHA	96b01008f71f4cbe2c138d63acb0e9bc6825286e
Python proof hash（numpy 2.4.2, scipy 1.17.1）	8c0680d7d285739ea9597715e84959d9c356c87ee3ad35b5f1e69a4ca41151c6
CIR proof hash（ADR-134）	120bd7b1f549f57f3773971a389c48c2bdd99b4ab1f205935867a16e95583995
Calibration proof hash（ADR-135）	d6bce07ecb1648e6936561df44bf4a3bfc17bb0ba5f692646b2301d105b52f67
ESP32 frame magic	0xC5110001
Workspace crate version	0.2.0

锚点表的设计意义：commit SHA 锚定代码、算法哈希锚定输出、魔数锚定线上协议、版本号锚定发布物——四类标识共同构成一条无需信任审计者话语的证据链，任何一方都可独立重建并比对。

如何使用这份日志（按角色）

对开发者

1. 在见证 commit 检出仓库；
2. 运行 Step 2–8，确认代码可编译、测试全绿；
3. 借助能力矩阵分清"什么是真实现、什么只是计划"（例如板端推理是 NO、真实数据集是 NO）；
4. firmware/ 目录提供了在 COM7 上烧录 ESP32-S3 的全部所需产物。

对审查者 / 尽职调查方

1. 运行 Step 2–10（无需硬件），确认全部软件声明；
2. 检查能力矩阵：标记 YES 的行都有通过的测试作证；标记 NO 与 NOT MEASURED 的行是公开的诚实缺口而非隐藏风险——对审查而言，被主动披露的缺口远比事后暴露的缺口可信；
3. Step 9 的证明系统（以及后续 Step 10b 扩展出的 CIR、标定两条证明链）体现了项目对"可验证性"的持续投入，可对照 verify 根脚本的九阶段设计理解其全貌。

对硬件测试者

1. 准备 ESP32-S3-DevKitC-1（约 $10）；
2. 按 Step 11 烧录固件；
3. 运行聚合器 cargo run -p wifi-densepose-hardware --bin aggregator；
4. 观察 UDP 5005 端口上 CSI 帧流到达。

方法论的边界与启示

在复现或借鉴这份见证日志时，有三个边界值得记住：

• 快照与演进：所有精确数字都绑定 2026-03-01 的 96b01008。当前仓库（HEAD c4021f98）的测试规模、模块行数、crate 数量均已增长，跨提交比对时应以各提交的实际输出为准，这也解释了为何代码目录旁总要维护哈希文件让"变更即失效、失效即重建"。
• 在线步骤的依赖：Step 3、Step 10、以及根脚本 verify 的 Phase 6–9 依赖 crates.io、npm、Docker Hub 等外部服务；纯本地可重放的确定性核心是 Step 2、6–9 与两个 proof 脚本。
• 合成信号不等于真实数据：证明系统确保"管线代码真实且确定"，能力矩阵第 32 行则如实说明未捆绑真实 CSI 数据集——两类事实被刻意分开表述，避免"确定性证明"被误读为"真实场景性能证明"。

WITNESS-LOG-028 为开源传感项目示范了一种可迁移的工程纪律：把"我做了 X"改写成"在 commit C 上运行命令 M 得到输出 H"，让每一个读者都成为审计者。仓库内另有后续的 WITNESS-LOG-110 延续同一实践，其配套的架构决策记录见 ADR-028 ESP32 能力审计 及信号链路相关决策 ADR-018、ADR-027、ADR-134、ADR-135。