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作用域执行内容判定标准testsRust 工作区全量测试1,400 通过、0 失败proofPython 确定性证明哈希重放输出VERDICT: PASSbundle生成并自校验 ADR-028 见证包自校验脚本全项 PASSall按 1→2→3 顺序全部执行三项全部达标该提示词是 Codex 侧的 operator 命令仓库中同一能力的其他镜像实现还包括 Claude Code 插件命令 与 ruview-verify 技能定义由plugins/ruview/scripts/smoke.sh保证二者逐字对齐。本文以下各节即按tests → proof → bundle → all的顺序逐一展开。二、testsRust 工作区全量测试2.1 标准命令与判定阈值cd v2 cargo test --workspace --no-default-features执行结果必须满足1,400 passed、0 failed常规耗时约 2 分钟。注意两点关键约束--no-default-featuresRuView 各 crate 默认不启用额外特性集这一开关确保测试的是最基础、可移植的代码路径--workspace覆盖 v2 工作区 下的全部 cratesignal、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 域泛化与确定性复现。三、proofPython 确定性证明Trust Kill Switch3.1 运行方式与判定标准cd .. python archive/v1/data/proof/verify.py该命令必须打印VERDICT: PASS。它的原理是把一份已发布的参考 CSI 信号送入生产代码非测试替身的完整特征提取流水线对输出做规范化序列化后计算 SHA-256再与仓库中提交的期望哈希比对——任何行为漂移都会改变哈希从而立刻暴露回归。可选的补充步骤是运行 v1 Python 测试套件cd archive/v1 python -m pytest tests/ -x -q3.2 源码级原理哈希如何做到跨平台确定阅读 verify.py 可以还原整个证明链路加载参考信号读取archive/v1/data/proof/sample_csi_data.json1,000 帧合成 CSIseed42由generate_reference_signal.py生成仅取前 100 帧约 1 秒参与哈希既保证速度又覆盖时序动态Doppler 需要历史帧。运行生产流水线使用与生产一致的PROCESSOR_CONFIGsampling_rate100、window_size56、overlap0.5、noise_threshold-60dB、human_detection_threshold0.8、smoothing_factor0.9、max_history_size500逐帧调用CSIProcessor.preprocess_csi_data()与extract_features()。规范化序列化将 5 个特征数组amplitude_mean、amplitude_variance、phase_difference、correlation_matrix、power_spectral_density量化为 6 位小数后按小端 float64 打包。doppler_shift被刻意排除——它是峰值归一化的在跨微架构的浮点重排下argmax可能翻转导致 O(1) 量级的不稳定见源码注释属已知的可复现性边界。哈希比对与容差回退位精确的 SHA-256 只在同一 CPU 微架构内成立scipy pocketfft/BLAS 内核在 AVX2/AVX-512/NEON 下对浮点归约的重排不同因此当哈希不匹配时脚本会回退到与提交的参考向量expected_features_reference.npz做rtol1e-4 / atol1e-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并同时输出参考向量第二条命令重新验证。注意这一操作只应在确认代码未变、仅依赖数值环境变化时执行真实回归必须排查而不是重新生成哈希。四、bundleADR-028 见证包生成与自校验4.1 生成见证包bash scripts/generate-witness-bundle.sh脚本generate-witness-bundle.sh基于当前提交生成dist/witness-bundle-ADR028-sha8.tar.gz内容编排如下步骤内容1. 见证文档docs/WITNESS-LOG-028.mddocs/adr/ADR-028-esp32-capability-audit.md2. 证明系统verify.py、expected_features.sha256、generate_reference_signal.py以及参考信号的元数据摘要帧数、首帧字段、文件大小原始信号约 10 MB 只存元数据3. Rust 测试日志完整cargo test --workspace --no-default-features输出 汇总的通过/失败计数4. Python 证明日志verify.py输出经 redact-secrets.py 脱敏防止 Pydantic 校验失败时泄露.env中的 Docker/API 凭据4b. CIR 证明verify-cir-proof.sh 的 ADR-134 确定性证明日志5. 固件清单firmware/esp32-csi-node/main/下所有 C/H 源码的 SHA-256、行数统计、预编译固件二进制的哈希、支持目标清单esp32s3 生产 / esp32c6 研究6. crate 清单v2/crates/*/Cargo.toml的 crate 名与版本号6b. npm 清单ruvnet/rvagenttarball 的 SHA-256ADR-1247. 自校验脚本为接收方生成的VERIFY.sh外加MANIFEST.sha2564.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 项Rust 测试通过1,4000 失败Python 证明通过VERDICT: PASSREADME.md在作用域变化时更新平台 / crate / 硬件表格、功能摘要CLAUDE.md在作用域变化时更新crate 表、ADR 列表、模块表、版本CHANGELOG.md在[Unreleased]下新增条目docs/user-guide.md 在新增数据源 / CLI 参数 / 安装步骤时更新新增 ADR 时在 README 的文档表中递增 ADR 计数测试或证明哈希变化时重新生成见证包仅在 Dockerfile / 依赖 / 运行时行为变化时才重建 Docker 镜像仅当已发布 crate 的公共 API 变化时才发布 crate且按依赖顺序发布见 CLAUDE.md.gitignore覆盖新增的构建产物 / 二进制对触及硬件 / 网络边界的新模块进行安全评审。七、安全扫描与固件 CI对安全相关的变更额外执行npx claude-flow/clilatest security scan此外ADR-061 定义了 QEMU 固件 CIFirmware 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.shQEMU 烧录需要esptool merge_bin --fill-flash-size 8MBCI 中无真实 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
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作用域执行内容判定标准testsRust 工作区全量测试1,400 通过、0 失败proofPython 确定性证明哈希重放输出VERDICT: PASSbundle生成并自校验 ADR-028 见证包自校验脚本全项 PASSall按 1→2→3 顺序全部执行三项全部达标该提示词是 Codex 侧的 operator 命令仓库中同一能力的其他镜像实现还包括 Claude Code 插件命令 与 ruview-verify 技能定义由plugins/ruview/scripts/smoke.sh保证二者逐字对齐。本文以下各节即按tests → proof → bundle → all的顺序逐一展开。二、testsRust 工作区全量测试2.1 标准命令与判定阈值cd v2 cargo test --workspace --no-default-features执行结果必须满足1,400 passed、0 failed常规耗时约 2 分钟。注意两点关键约束--no-default-featuresRuView 各 crate 默认不启用额外特性集这一开关确保测试的是最基础、可移植的代码路径--workspace覆盖 v2 工作区 下的全部 cratesignal、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 域泛化与确定性复现。三、proofPython 确定性证明Trust Kill Switch3.1 运行方式与判定标准cd .. python archive/v1/data/proof/verify.py该命令必须打印VERDICT: PASS。它的原理是把一份已发布的参考 CSI 信号送入生产代码非测试替身的完整特征提取流水线对输出做规范化序列化后计算 SHA-256再与仓库中提交的期望哈希比对——任何行为漂移都会改变哈希从而立刻暴露回归。可选的补充步骤是运行 v1 Python 测试套件cd archive/v1 python -m pytest tests/ -x -q3.2 源码级原理哈希如何做到跨平台确定阅读 verify.py 可以还原整个证明链路加载参考信号读取archive/v1/data/proof/sample_csi_data.json1,000 帧合成 CSIseed42由generate_reference_signal.py生成仅取前 100 帧约 1 秒参与哈希既保证速度又覆盖时序动态Doppler 需要历史帧。运行生产流水线使用与生产一致的PROCESSOR_CONFIGsampling_rate100、window_size56、overlap0.5、noise_threshold-60dB、human_detection_threshold0.8、smoothing_factor0.9、max_history_size500逐帧调用CSIProcessor.preprocess_csi_data()与extract_features()。规范化序列化将 5 个特征数组amplitude_mean、amplitude_variance、phase_difference、correlation_matrix、power_spectral_density量化为 6 位小数后按小端 float64 打包。doppler_shift被刻意排除——它是峰值归一化的在跨微架构的浮点重排下argmax可能翻转导致 O(1) 量级的不稳定见源码注释属已知的可复现性边界。哈希比对与容差回退位精确的 SHA-256 只在同一 CPU 微架构内成立scipy pocketfft/BLAS 内核在 AVX2/AVX-512/NEON 下对浮点归约的重排不同因此当哈希不匹配时脚本会回退到与提交的参考向量expected_features_reference.npz做rtol1e-4 / atol1e-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并同时输出参考向量第二条命令重新验证。注意这一操作只应在确认代码未变、仅依赖数值环境变化时执行真实回归必须排查而不是重新生成哈希。四、bundleADR-028 见证包生成与自校验4.1 生成见证包bash scripts/generate-witness-bundle.sh脚本generate-witness-bundle.sh基于当前提交生成dist/witness-bundle-ADR028-sha8.tar.gz内容编排如下步骤内容1. 见证文档docs/WITNESS-LOG-028.mddocs/adr/ADR-028-esp32-capability-audit.md2. 证明系统verify.py、expected_features.sha256、generate_reference_signal.py以及参考信号的元数据摘要帧数、首帧字段、文件大小原始信号约 10 MB 只存元数据3. Rust 测试日志完整cargo test --workspace --no-default-features输出 汇总的通过/失败计数4. Python 证明日志verify.py输出经 redact-secrets.py 脱敏防止 Pydantic 校验失败时泄露.env中的 Docker/API 凭据4b. CIR 证明verify-cir-proof.sh 的 ADR-134 确定性证明日志5. 固件清单firmware/esp32-csi-node/main/下所有 C/H 源码的 SHA-256、行数统计、预编译固件二进制的哈希、支持目标清单esp32s3 生产 / esp32c6 研究6. crate 清单v2/crates/*/Cargo.toml的 crate 名与版本号6b. npm 清单ruvnet/rvagenttarball 的 SHA-256ADR-1247. 自校验脚本为接收方生成的VERIFY.sh外加MANIFEST.sha2564.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 项Rust 测试通过1,4000 失败Python 证明通过VERDICT: PASSREADME.md在作用域变化时更新平台 / crate / 硬件表格、功能摘要CLAUDE.md在作用域变化时更新crate 表、ADR 列表、模块表、版本CHANGELOG.md在[Unreleased]下新增条目docs/user-guide.md 在新增数据源 / CLI 参数 / 安装步骤时更新新增 ADR 时在 README 的文档表中递增 ADR 计数测试或证明哈希变化时重新生成见证包仅在 Dockerfile / 依赖 / 运行时行为变化时才重建 Docker 镜像仅当已发布 crate 的公共 API 变化时才发布 crate且按依赖顺序发布见 CLAUDE.md.gitignore覆盖新增的构建产物 / 二进制对触及硬件 / 网络边界的新模块进行安全评审。七、安全扫描与固件 CI对安全相关的变更额外执行npx claude-flow/clilatest security scan此外ADR-061 定义了 QEMU 固件 CIFirmware 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.shQEMU 烧录需要esptool merge_bin --fill-flash-size 8MBCI 中无真实 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考