RuView PROOF 复现机制解析：用一条命令、一份分级体系把 WiFi 传感项目的每一个宣称变成可验证事实

π RuView（wifi-densepose）是一个把普通 WiFi 信号转化为空间感知、生命体征监测与存在检测的开源传感平台。本文围绕仓库根目录的 PROOF.md 展开：当项目被公开质疑为 "AI slop / fake" 时，这份文档给出的不是辩护词，而是一套可运行的"反造伪"机制——克隆仓库、执行一条脚本，所有头条宣称要么在本机被验证，要么被明确标注为"CLAIMED，尚未在此复现（并精确说明它还需要什么）"。读完本文，你将掌握 RuView 的证据分级体系、prove.sh 与 verify 两条复现入口的执行语义、SHA-256 确定性证明的内部原理，以及那些"诚实负面声明"为什么是整份证明里最有说服力的部分。

为什么需要一份"可复现证明"（PROOF）文档

PROOF.md 的开篇即点明了这份文档的使命：

This project (RuView / wifi-densepose) has been publicly called "AI slop" and "fake." This document is the answer: a skeptic can clone the repo, run one script, and have every headline claim either verified on their own machine or shown — explicitly — as "CLAIMED, not yet reproduced (here's exactly what it needs)."

这里有两层值得注意的设计取向：

1. 对抗性受众预设：文档的假想读者不是项目粉丝，而是怀疑者。因此它不要求读者信任任何作者描述，只要求读者运行命令。
2. "Nothing below is asserted without a command you can run." —— 这是全文的纪律红线：每一个结论都必须附带一条可执行命令，这是它与普通 README 最本质的区别。

仓库中承担这一职责的不止 PROOF.md 一处。根目录的 verify 脚本自称 "Trust Kill Switch（信任杀手开关）"，是跨 9 层栈的复合证明；而 scripts/prove.sh 则是 PROOF.md 直接指向的核心门禁。两者共同构成了仓库的"可证伪性基础设施"。

一条命令开始复现：prove.sh 与 verify 两条入口

PROOF.md 给出的最简复现路径只有三条命令：

git clone https://gitcode.com/GitHub_Trending/wi/RuView && cd RuView
bash scripts/prove.sh          # core gate + the anti-slop assertion tests
bash scripts/prove.sh --full   # also attempt the feature-gated subset

需要先说明 --full 与默认模式的差别：scripts/prove.sh 中的 FULL 开关在默认情况下只运行非门控（non-gated）的宣称；--full 会额外尝试那些依赖 GPU、数据集、真实硬件或已训练权重的"特性门控"宣称。但即便在 --full 模式下，门控宣称也永远不会导致运行失败——它们只会打印自己缺少的前置条件（libtorch、GPU、数据集、真实硬件等），以便怀疑者自行补齐后复现。

prove.sh 的退出码语义是关键约束：

prove.sh exits 0 only if every non-gated claim passes. Gated claims never fail the run; they print the prerequisite (a GPU, a dataset, real hardware, a trained checkpoint) so you can reproduce them yourself.

在脚本实现里，这对应三种打点函数（见 scripts/prove.sh）：

• PASS()：计数并打印 [PASS]；
• FAIL()：计数并打印 [FAIL]；
• SKIP()：计数并打印 [CLAIMED — not reproduced here]——被门控的宣称走这一分支。

脚本末尾的裁决逻辑是：fail 计数为 0 即 RESULT: PASS 并 exit 0；否则打印 RESULT: FAIL 并 exit 1（可参考 scripts/prove.sh）。set -uo pipefail 保证了中途任何管道错误都不会被静默吞掉。

更重的复合门禁：根目录 verify（Trust Kill Switch）

PROOF.md 聚焦于 prove.sh，但仓库根目录的 verify 是它的"加强版"，两者共享同一套哲学。verify 分为 9 个阶段：

1. Python 信号处理管线（v1 原始证明，SHA-256 往返）；
2. 生产代码 mock 扫描（非测试路径中的 np.random.rand/randn 模式）；
3. Rust workspace 测试（cargo test --workspace --no-default-features）；
4. PyO3 BFLD 绑定编译（cargo check -p wifi-densepose-py）；
5. ADR-125 §2.1.d 不变量——identity_risk_score 永不允许跨 HAP/MCP 网关边界泄露（见 verify）；
6. 已发布 crates.io 包的版本可查性；
7. 已发布 npm 包（@ruvnet/rvagent）；
8. Docker Hub 多架构 manifest（amd64 + arm64）；
9. Docker 镜像内嵌 HOMECORE 二进制（homecore-server --help）。

verify 支持 --quick、--rust-only、--docker-only、--verbose、--audit、--generate-hash 等子开关，退出码 0 = 全部通过（可选依赖缺失可优雅 SKIP）、1 = 任一实际运行的阶段失败、2 = 阶段 1 因缺少期望哈希文件而被迫跳过。对于只想快速验证信号管线确定性的读者，README 中还有更轻量的入口：

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

证据分级体系：MEASURED / CLAIMED / DATA-GATED / HARDWARE-GATED

PROOF.md 的"分级"（Grading）设计是整个证明机制的骨架，值得逐条吃透：

• MEASURED（已实测）——在本仓库的硬件上完成复现，记录了精确命令，并被一条"在修复前代码上必然失败"的测试钉死。prove.sh 会重跑这些测试。
• CLAIMED（已声称）——源自某文献、或由文献作者实测，但未在本仓库的自动化 harness 中被复现。
• DATA-GATED / HARDWARE-GATED（数据/硬件门控）——代码路径是真实且有测试的，但准确率/吞吐率宣称需要仓库未随附的数据或硬件。规则是：绝不编造数字，代码改为携带类型化错误或 weights_trained/来源标记（provenance flag）。

第三类的实现细节非常具体：例如 OccWorld 的 predict() 在未加载训练权重前始终携带 weights_trained=false，直到加载到真实 checkpoint 前绝不静默伪装成已训练模型。

硬性门槛：任何装有 Rust + Python 的机器都能跑

PROOF.md 将"硬门槛"定义为不需要 GPU、不需要专有数据集的两条 MEASURED 宣称：

Claim	Grade	Reproduce
Rust workspace: 3,128 tests, 0 failed	MEASURED	cd v2 && cargo test --workspace --no-default-features
Deterministic CSI pipeline proof (bit-exact SHA-256)	MEASURED	python archive/v1/data/proof/verify.py → VERDICT: PASS

（注：这是 PROOF.md 记录的实测口径——测试总数随仓库演进而变，例如根 README 徽章记录过 1,463 的早期数字；以你 clone 的当前 commit 实际跑出的 result: ok. N passed 为准。）

门槛 1：Rust workspace 全量测试

cd v2 && cargo test --workspace --no-default-features 会在 v2 的整个 workspace 内运行不带默认特性的测试。--no-default-features 的意义在于剔除需要原生依赖（如 libtorch / ONNX Runtime）的路径，让纯 Rust + Python 环境也能通过门槛。prove.sh 会把这一阶段输出落到 /tmp/prove_ws.log，再从 result: ok. N passed 中汇总计数。

门槛 2：确定性 CSI 管线证明——深入 verify.py

python archive/v1/data/proof/verify.py 是仓库中历史最悠久的"反 mock"证明，核心思路值得展开（见 archive/v1/data/proof/verify.py）：

1. 加载已发布的参考信号：从 sample_csi_data.json 读取合成参考 CSI 信号（由 generate_reference_signal.py 生成）。PROOF.md 特别强调：参考信号是合成的，它只用于验证管线确定性，而非信号真实性——处理这段参考信号的代码与处理真实采集的代码是同一条路径。
2. 跑真实生产模块：脚本直接 import v1 的 src.hardware.csi_extractor.CSIData 与 src.core.csi_processor.CSIProcessor，并在运行开始阶段打印 SOURCE PROVENANCE——用 inspect.getfile() 打印出被导入模块的绝对路径，让任何人都能确认"这不是测试替身"。
3. 哈希比对：对前 100 帧（1 秒）依次执行 preprocess_csi_data() → extract_features()，把 5 类特征（amplitude_mean、amplitude_variance、phase_difference、correlation_matrix、power_spectral_density）量化为定长小端 float64 后喂给 SHA-256，与 expected_features.sha256 比对，输出 VERDICT: PASS。

为什么是 SHA-256 而不是直接比 float？ 注释（verify.py）记录了一个真实的工程教训：scipy.fft 的 pocketfft 内核在不同 SIMD 后端（Intel AVX2/AVX-512 vs ARM NEON）下会重排向量化浮点运算，导致同一份代码在不同 CPU 微架构上产生约 1e-14 级的原始差异，经管线放大后漂移可达 1e-7。因此脚本在打包前先把特征 np.round(..., 6)（6 位小数），由环境变量 PROOF_HASH_DECIMALS 可覆盖；doppler_shift 被有意排除——它做了峰值归一化，在近乎并列的峰值下 argmax 会因微架构差异翻转，属于无法用任何容差吸收的 O(1) 级分歧。

跨平台容差兜底：仅靠位精确哈希还不够跨微架构稳定。因此 verify.py 还维护第二道证明——对提交的参考向量 expected_features_reference.npz 做 np.allclose(rtol=1e-4, atol=1e-6) 相对容差比较。判定规则是"位精确匹配或容差匹配任一通过即 PASS"，容差约是实测微架构漂移的 100 倍、又是信号有意义变化（CSI 相位精度约 1e-3 rad）的约 1/10，因此真实管线回归依然会失败。v1 还保留了两个 CIR 相关证明：expected_cir_features.sha256 与 expected_calibration_features.sha256。

反"AI slop"断言测试：每一条都曾在修复前代码上失败

这是 prove.sh 的第 3 阶段，也是 PROOF.md 花费最多笔墨的部分。核心设计是：这些测试不是"通过即真"的摆设，而是从真实缺陷（bug/缺口/越权宣称）出发反写的回归测试——修复前的代码必然跑不过它们。

Claim	Grade	Test（cargo test -p <crate> <name>）
Fusion crafted-input DoS panics are closed（ADR-156 §2.2）	MEASURED	wifi-densepose-ruvector :: triangulation_out_of_range_index_returns_none_no_panic
Soul Signature 身份宣称被诚实界定：仅凭 WiFi 心电+呼吸通道无法区分两个人（gap ≈ 0.0005）	MEASURED	wifi-densepose-bfld :: cardiac_alone_cannot_separate_identity_matches_audit
OccWorld predict() 是真实的（输入相关），而非随机噪声	MEASURED	wifi-densepose-occworld-candle :: predict_is_deterministic_for_same_input
Pose 运行时在其自身默认配置下能产出帧（ADR-159 A1）	MEASURED	cog-pose-estimation :: default_config_emits_frames_with_real_model
Person-count 对未训练类别给出低置信度标记，不虚增人数（ADR-159 A2）	MEASURED	cog-person-count :: untrained_class_argmax_is_flagged_low_confidence
医疗边缘技能模块携带"非医疗器械"声明（ADR-160 A1）	MEASURED	wifi-densepose-wasm-edge :: a1_med_modules_have_clinical_disclaimer（--features std）
Survivor 去重 3→1，人数虚增被消除（ADR-158 §2）	MEASURED	wifi-densepose-mat :: test_identical_vitals_no_location_dedup_to_one（--features mat）

这些测试在 v2/crates 下均可找到真实源码。例如：

• 融合越界防护：wifi-densepose-ruvector 中的 triangulation_out_of_range_index_returns_none_no_panic 验证 crafted 输入不会触发 panic，实现位于 v2/crates/wifi-densepose-ruvector/src/mat/triangulation.rs。
• 身份不可分（负结果被"正名"）：v2/crates/wifi-densepose-bfld/tests/soul_match.rs 中的 cardiac_alone_cannot_separate_identity_matches_audit 是最具代表性的测试——它构造 A、B 两人的完整 enrolled 档案，却只让探针携带权重较低的心电（0.15）+ 呼吸（0.10）通道，有意剔除决定性高权重通道（AETHER 0.35、子载波 0.20）。实测结果 a_self=1.0000 vs a_cross=0.9995，gap=0.0005：健康成年人的心电/呼吸特征向量都是正值、幅度相近，余弦相似度天然趋近 1.0，与"是谁"无关。这等于用一条测试把"WiFi 能锁定个人身份"这个最容易夸大的宣称证伪在代码层面，并把它标记为 DATA-GATED——除非有真实 enrollment 喂入 AETHER/身体共振通道。
• 医学免责声明：wifi-densepose-wasm-edge 是被排除在 v2 workspace 之外的 crate，因此 prove.sh 专门提供了 claim_test_indir 变体（scripts/prove.sh），从 crate 目录内执行 cargo test --features std。其 a1_med_modules_have_clinical_disclaimer 位于 v2/crates/wifi-densepose-wasm-edge/tests/honest_labeling.rs。

prove.sh 对"测试根本没跑到"和"测试真的失败"做了区分（scripts/prove.sh）：若日志出现 0 passed/filtered out/error: no test target 且无 test result: FAILED，则判为 SKIP（特性门控/本构建缺该测试）；否则才判 FAIL。

实测性能（criterion）：在自己机器上复现

宣称"优化了 2 倍"却拿不出基准命令，是 slop 的常见特征。PROOF.md 把所有性能宣称都挂到可复现的 criterion 基准上，并明确标注复现环境边界：

Claim	Grade	Reproduce
PSD FFT-planner cache 2.0–3.1×、DTW band 2.4–4.1×（ADR-154）	MEASURED	cd v2 && cargo bench -p wifi-densepose-signal
fuse() 去除 double-clone 后约 2.17× marshalling（ADR-156）	MEASURED	cd v2 && cargo bench -p wifi-densepose-ruvector --bench fusion_bench
zero-copy ORT input 约 1.48×（ADR-155）	MEASURED	cd v2 && cargo bench -p wifi-densepose-nn --features onnx --bench onnx_bench
pointcloud splats 9→2 遍约 1.24×（ADR-160 research）	MEASURED	cd v2 && cargo bench -p wifi-densepose-pointcloud --bench splats_bench
原生 wlanapi 多 BSSID 扫描 9.74 Hz（对照 netsh 约 2 Hz）	MEASURED（Windows）	cd v2 && cargo test -p wifi-densepose-wifiscan -- --ignored measure_native_scan_rate
wasm-edge process_frame 热路径延迟（host proxy，ADR-163）	MEASURED-on-host（非 ESP32/WASM3 预算——需要硬件）	cd v2/crates/wifi-densepose-wasm-edge && cargo bench --features std
cog 稳态 CPU 推理延迟约 305 µs（ADR-163；非 manifest cold-start）	MEASURED-on-host	cd v2 && cargo bench -p cog-person-count -p cog-pose-estimation --no-default-features --bench infer_bench

表格中 MEASURED-on-host 这个分级值得单独解释。它是 benchmarks/edge-latency/RESULTS.md 引入的诚实口径：宿主 x86_64 笔记本上的原生中位数是算法工作量的上界估计，而 不是 ESP32/Xtensa + WASM3 解释器上的数字——WASM3 在约 240 MHz Xtensa 核心上的解释开销通常是原生 -O 代码的 1–2 个数量级。例如 exo_time_crystal 256×128 自相关热路径宿主中位数 17.3 µs，对应的是文档声称"ESP32-S3 WASM3 上 H（<10 ms）"的预算，而该 ESP32 数字明确标注为未复现、需要硬件。该文档同样区分了 cold-start（manifest 声明的 cold_start_ms_avg，含权重加载）与 steady-state infer（criterion 实测的暖帧推理）——两者是不同的测量。所有这类性能表的详细数据源可追溯至 benchmarks/wiflow-std/RESULTS.md 与 benchmarks/edge-latency/RESULTS.md。

诚实负面声明：整套证明里最有力的反造伪信号

PROOF.md 单独开辟一节 "What we do NOT claim"——主动把做不到、未测量、被证伪的事列出来，并给出原因与状态。作者的原话是："the strongest anti-slop signal"（最强的反造伪信号），因为"a faker hides failures; we commit them"（造假者隐藏失败，而我们把失败提交进仓库）。

Capability	Status
通过 WiFi 识别具名个人身份	未实现，且已实测其不可行的原因。§3.6 matcher 是真实的，但身份在仅凭 WiFi 通道上无法锁定（gap 0.0005）。DATA-GATED——需要真实 enrollment 喂入 AETHER/身体共振通道，从未做过。不做任何具名身份宣称。
WiFlow-STD 约 96% PCK@20	CLAIMED-reproduced——在本仓库 RTX 5080 上完成（benchmarks/wiflow-std/RESULTS.md）；对你而言是 HARDWARE-GATED（需要 NVIDIA GPU + MM-Fi 数据集）。上游随发布附带的 checkpoint 已被 REFUTED（0.08% PCK），该事实被如实公开。
OccWorld 轨迹准确率	DATA-GATED——需要已训练 checkpoint；predict() 在加载到权重前携带 weights_trained=false，绝不静默伪装。
边缘技能检测准确率（癫痫、武器、情绪等）	UNVALIDATED——每个此类模块都已加"实验/研究"免责门控；DSP 是真实的，准确率不被声称。
802.11bf-2025 OTA 一致性	截至 2026 年没有商业硅片提供一致接口；本项目是经仿真验证的前向兼容协议模型，而非认证实现。

其中 WiFlow-STD 一行的证据链尤其值得作为"如何公开一个负面结果"的范本。benchmarks/wiflow-std/RESULTS.md 详细记录了：上游发布的 best_pose_model.pth 经原代码、原数据集、原分割流程重跑，PCK@20 实测仅 0.08%（对比其宣称 97.25%），MPJPE 因数据集中含 NaN CSI 窗口而输出 NaN；随后通过修复数据集与代码后重新训练才把宣称还原到约 96%（PCK@20 96.09%–96.61%），得出"宣称可信且可近似复现——但必须先修复发布的代码与数据"的结论。同一文档还列出上游代码的 6 个可复现性缺陷（models/__init__.py 引用了未定义的 TemporalConvNet、run.py 硬编码 ../preprocessed_csi_data、数据集末尾 13 个文件损坏等）。这种"连竞品/上游论文都要实测打假"的姿态，正是 PROOF.md 想传达的取证文化。

Provenance（溯源）：每条宣称都能追到一条证据

PROOF.md 的溯源原则：

Every claim above traces to a committed ADR (docs/adr/ADR-154…ADR-163), a test, a criterion bench, benchmarks/wiflow-std/RESULTS.md, or benchmarks/edge-latency/RESULTS.md.

也就是说，宣称 → 证据是一对一可遍历的：性能宣称指向 ADR 154–156/160 与对应 criterion bench；延迟预算指向 ADR-163 及其 benchmarks/edge-latency/RESULTS.md；身份不可分指向 ADR-158/BFLD Soul Signature 测试；医疗器械免责与人数虚增宣称分别指向 ADR-160 A1、ADR-159 A1/A2、ADR-158 §2。相关 ADR 全部提交在仓库 docs/adr 目录（如 ADR-154-signal-dsp-beyond-sota.md、ADR-155-nn-training-beyond-sota.md、ADR-156-ruvector-fusion-beyond-sota.md、ADR-158-mat-worldmodel-beyond-sota.md、ADR-159-cognitum-appliance-beyond-sota.md、ADR-160-edge-skill-library-honest-labeling.md、ADR-163-edge-latency-measurement.md）。

PROOF.md 还特意强调仓库的 commit 历史中包含公开的撤回（retractions）记录：

• 92.9% PCK 数字的撤回；
• WiFlow-STD 随发布 checkpoint 的证伪（见上文）；
• NV-diamond BOM 的现实性核查。

这与根 README 中其他"诚实标签"一脉相承——例如旧的 "100% presence" 数字因在单类录制上测得而被撤回，改用 82.3% held-out temporal-triplet 精度；已提交的 pose_v1.safetensors 是"真实但弱"的首版模型（PCK@20=3.0%，低于 ADR-079 的 ≥35% 目标），其运行时路径仍是返回 confidence=0 的桩。在 PROOF.md 的语境下，这类记录的作用是：一个愿意把"自己曾错过的数字"写进历史文档的项目，比一个只会报喜的项目更可信。

把 PROOF 机制用起来：诊断、分级与持续门禁

综合上述，读者可以从三个层面复用这套机制：

1. 作为怀疑者：直接运行 bash scripts/prove.sh，观察每条宣称落在 PASS / FAIL / CLAIMED-not-reproduced 三档中的哪一档。若 FAIL，日志被精确写入 /tmp/prove_ws.log、/tmp/prove_py.log、/tmp/prove_claim.log，可据此定位具体失败阶段。
2. 作为复现者：对门控宣称（GPU/数据集/Windows 专属/需要硬件），PROOF.md 与对应 RESULTS 文档给出了精确的复现命令与前置条件清单，例如 WiFlow-STD 需要 NVIDIA GPU + MM-Fi 数据集并参考 benchmarks/wiflow-std/RESULTS.md；ESP32 延迟预算则需要真实硬件而非宿主代理数字。
3. 作为 CI 门禁：prove.sh 的退出码契约（非门控全过才 exit 0）与 verify 的 9 阶段多层检查，使其天然可接入持续集成——这正是"确定性证明 + 分级宣称"从单机脚本上升为工程文化的通道。

归根结底，PROOF.md 想确立的范式是："它不是 mock"不是一个观点，而是一条可以运行并失败的命令。在 WiFi 传感这类既涉及信号处理严谨性、又极易被夸大 AI 能力的领域，这套"宣称必带命令、数字必带分级、失败必进历史"的机制，比任何性能数字本身都更能回答"这个项目是不是真的"。