尧图网站建设 
RuView 公开基准评测基座ADR-291Widar3.0 接入、标准划分协议与结构性防泄漏审计【免费下载链接】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导读本文基于 ADR-291Public-benchmark evaluation harness系统讲解 RuView v2 Rust 工作区如何在wifi-densepose-traincrate 中落地“可与公开榜对齐的评测能力”一是解析并接入 Widar3.0 的 Intel 5300.datbfee原始 CSI 日志二是实现 cross-subject / cross-environment / cross-orientation 三类标准评测划分协议三是引入结构性的泄漏审计、均值姿态基线与证据分级报告。读完本文你将掌握该评测基座的整体设计动机、二进制格式细节、纯函数划分机制与类型系统级的防泄漏约束并能直接复现cargo test/cargo bench验证。背景为什么需要公开基准评测基座自采数据与自定义指标无法横向比较ADR-291 指出RuView 此前实现了该领域的关键技术CSI ratio、BVP 特征、MAE 预训练、快速适配等但结果仅在自采数据与自定义指标如 README 中的 temporal-triplet 留出准确率上报告。wifi-densepose-train已有MmFiDataset的 NPY 加载器与确定性的SyntheticCsiDataset见 dataset.rs但缺少三个关键能力Widar3.0 数据接入没有 Intel 5300.dat原始格式的解析器标准划分协议没有 cross-subject / cross-environment 等学术界公认的评测口径结构性防泄漏护栏没有在代码层强制 CLAUDE.md 提出的均值姿态基线与无泄漏留出划分要求。2024–2025 年领域性泄漏教训文献扫描发现领域内存在一次被充分记录的“泄漏大清算”对连续录制数据做window 级随机切分会显著虚高精度——某个数据集在 subject-disjoint 划分下 F1 从约 90% 崩塌到约 22%ADR-291 引述 Sensors 24(10):3159 与 Signals 6(4):59。根本原因是 stride-1 滑动窗口切出的相邻窗口近乎相同把它们分到 train/test 两侧约等于在测试集里“剧透”训练数据。正因如此MmFiDataset的源码注释里专门有一段防泄漏纪律说明见 dataset.rsMM-Fi 窗口以 stride 1 提取相邻窗口重叠window_frames − 1帧naive 索引级随机切分信息泄漏可达约 99%因此必须按 subject 级整体切分。ADR-291 把这一纪律从单一数据集的注释提升为通用的、loader 无关的协议与审计机制。备选方案对比方案结论什么都不做继续只报自采指标拒绝延续不可比缺口无法进入科学引用与 OEM 授权对话在 Rust 管线旁再移植一套 Python 评测栈如 SenseFi拒绝违反 v2 Rust 工作区方向并引入未经审查的依赖面在wifi-densepose-train内扩展原生 loader 协议机制采纳保持 Rust 单栈、复用既有CsiDatasettrait三大交付接入、划分、防泄漏ADR-291 的落点集中在 v2/crates/wifi-densepose-train代码结构对应三个模块src/dataset/widar.rs —— Widar3.0 接入§1src/protocols.rs —— 划分协议§2src/protocols/leakage.rs —— 泄漏审计 / 均值基线 / 证据分级§3三者通过 crate 根导出统一暴露见 lib.rs错误类型集中在 error.rsProtocolError分支。Widar3.0 接入bfee.dat解析器与WidarDataset二进制记录格式“bfee” 帧Widar3.0 原始发行版使用 Intel 5300 网卡 Linux 802.11n CSI Tool 采集存储为带帧结构的二进制.dat日志。ADR-291 与 widar.rs 给出了精确布局frame : u16 LE field_len | u8 code (code 0xBB bfee record) field_len 计入 code 字节与 payload因此下一帧起点 field_len 2 字节处 payload : 20 字节 bfee 头 [0..4) timestamp_low u32 LE [4..6) bfee_count u16 LE [6..8) reserved (2 字节忽略) [8] n_rx u8 (1..3) [9] n_tx u8 (1..3) [10..13) rssi_a/b/c u8 各 1 [13] noise i8 [14] agc u8 [15] antenna_sel u8 [16..18) len u16 LE (packed CSI 字节数) [18..20) rate u16 LE 之后是 len 字节 packed CSI csi : 10-bit 二进制补码分量LSB-first 无间隔填充打包顺序为 for sc in 0..30 { for rx in 0..n_rx { for tx in 0..n_tx { real; imag; } } } len 必须等于 ceil(30 * n_rx * n_tx * 2 * 10 / 8)关键源码常量见 widar.rs常量值含义BFEE_CODE0xBBbfee 记录标识BFEE_HEADER_LEN20固定头字节数WIDAR_SUBCARRIERS30Intel 5300 在 20/40 MHz 上报的载波组数CSI_COMPONENT_BITS10每个复分量位数MAX_ANTENNAS3天线数上限MAX_FIELD_LEN4096单帧长度上限防止无界分配MAX_DAT_FILE_BYTES512 MiB.dat文件大小上限packed_csi_len(n_rx, n_tx) ceil(30 × n_rx × n_tx × 2 × 10 / 8)实测 1×1 → 75、3×1 → 225、3×3 → 675 字节有单测packed_len_matches_formula佐证。BfeeRecord完整保留了timestamp_low、bfee_count、RSSI a/b/c、noise、agc、antenna_sel、rate与csi: Array3Complex32shape[n_tx, n_rx, 30]见 widar.rs。一个重要边界原始 CSI Tool 日志与 Widar 发行版的差异模块文档明确警告见 widar.rs原始 Linux CSI Tool 写入的是8-bit 分量 每组 shift 位 大端帧长若直接喂入未经转换的上游原始日志会因len一致性校验失败而被跳过warn 而非静默误码。这保证了解析器不会把错误格式悄悄解出“看起来合理”的错误数据。解析器的“永不 panic”设计.dat被视为不可信输入解析必须在边界处校验CLAUDE.md 非协商规则。parse_bfee_bytes的实现策略见 widar.rs无效或截断记录被跳过并 warn计入BfeeParse::skipped非 bfee 代码的完好记录被忽略计入BfeeParse::non_bfee真实日志会混入其它记录类型field_len超上限framing 不可恢复时停止解析剩余缓冲文件末尾残留不足帧头的悬挂字节视为截断并计数。位级解包使用流式BitReader每字节只加载一次、无分支符号扩展见 widar.rs。配套提供了确定性 fixture 编码器encode_bfee_frame见 widar.rs测试与 bench 的合成.dat字节全部由代码生成仓库永不检入任何二进制数据集文件。从路径解析领域元数据Widar 文件名约定构建环境无法访问 Widar 站点ADR-291 标注为依据论文/发布说明推断的假定约定解析器刻意宽容缺失字段解析为 0root/[room1/]date/user1/user1-3-1-1-2-r5.dat │ │ │ │ │ └ receiver id可选 │ │ │ │ └ repetition 次数 │ │ │ └ face orientation1..5 │ │ └ torso location1..5 │ └ gesture 类型 └ user idparse_widar_path返回WidarFileMetauser / gesture / location / orientation / repetition / receiver / room见 widar.rsroom id 取自最近的roomN祖先目录大小写不敏感目录树按采集日期分组而没有 room 目录时默认为 0——此时对这类目录树做 cross-environment 划分会在审计阶段失败而非静默放行。WidarDataset把.dat映射为窗口化CsiSampleWidarDataset实现既有CsiDatasettraitlen/get/name行为要点discover(root, window_frames, target_subcarriers)递归扫描.dat按文件名排序建立前缀和窗口索引不可读、超大、无有效记录的.dat文件被 warn 跳过根目录无任何可用记录时报错见 widar.rs每个.dat文件视为一条连续录制泄漏审计的recording_id就是它在排序扫描中的下标get()惰性重读文件并按 stride-1 切窗帧数不足窗口则报错每帧 CSI 从[n_tx, n_rx, 30]展开为幅度/相位四维张量[window_frames, n_tx, n_rx, 30]若目标载波数与 30 不同则经interpolate_subcarriers插值到target_subcarriers见 widar.rsWidar 是手势数据集、无姿态真值因此CsiSample::keypoints置零、visibility 为 0COCO not labelledsubject_id/action_id分别承载 user id 与 gesture id无网络访问loader 只读本地数据集根目录数据集下载是文档化的人工步骤。单元测试覆盖了 bfee 解析往返、负值符号扩展、确定性、空缓冲、截断/悬挂字节/零长帧/超大帧长/非 bfee 码/天线数越界/len 字段不符等场景以及端到端目录发现与元数据映射见 widar.rs 的 tests 模块。标准划分协议把“留出什么”表达为纯函数SplitProtocol与SplitSide协议定义见 protocols.rs枚举变体语义tag声称的不相交性claims()CrossSubject留出整批受试者MM-Fi 风格cross-subjectsubject-disjointCrossEnvironment留出整批环境/房间cross-environmentenvironment-disjointCrossOrientation留出整批朝向Widar 风格cross-orientationorientation-disjointRandomBaselinewindow 级随机切分显式标注为易泄漏基线仅供对比random-baseline-leaky不声称任何不相交性SampleMeta是 loader 无关的按窗元数据subject_id/environment_id/orientation_id/gesture_id/recording_id连续录制标识/window_index由例如WidarDataset::sample_meta生成见 protocols.rs。SplitPlan::assign无 RNG 状态的确定性哈希切分赋值是元数据 seed 的纯函数保证跨运行、跨平台、跨迭代顺序字节级一致按协议取出被留出的“单元”subject / environment / orientation 的 idRandomBaseline 则为recording_idwindow_index通过四个不同 domain tag 常量SUBJ/ENVR/ORNT/RNDM见 protocols.rs防止“subject 3 与 orientation 3 在同一个 seed 下共享哈希”这类碰撞用 splitmix64 混合单元哈希与 seed用整数阈值比较test_fraction × 2^64无浮点累积判定归属保证各平台一致。同一单元的所有窗口必然同侧唯一例外是RandomBaseline按窗哈希——这正是它被文档化的泄漏点。SplitPlan::new会拒绝非有限或不在(0,1)区间内的test_fractionProtocolError::InvalidTestFraction。相关测试覆盖坏分数拒绝、跨调用/跨顺序确定性、不同 seed 产生不同切分、cross-subject 保持 subject 完整、RandomBaseline 必然切穿同一录制见 protocols.rs。结构性泄漏护栏与证据分级LeakageAudit审计失败是Err不是警告审计器见 leakage.rs按顺序校验train / test 两侧均非空EmptyPartition无条件同一条连续录制的窗口不得横跨两侧RecordingCrossesSplit——即便协议本身不声称任何不相交性协议声称 subject 不相交时校验之SubjectOverlap协议声称 environment 不相交时校验之EnvironmentOverlap协议声称 orientation 不相交时校验之OrientationOverlap。审计通过时返回LeakageAuditPass携带两侧窗口数、subject 数、录制数等仅作报告用途的计数不声称超出结构校验范围的任何结论。失败返回描述首个违规的ProtocolError。对应错误变体统一定义在 error.rs。测试明确验证了“漏就拒绝”subject 重叠被拒、claimed environment/orientation 重叠被拒、RandomBaseline 端到端划分必然触发RecordingCrossesSplit见 leakage.rs。值得注意的设计取舍一个“clean”的同一对 split在声称 environment 不相交的协议下失败、在不声称的协议如CrossSubject下通过——审计只保证协议声称的属性。MeanPoseBaseline把 CLAUDE.md 规则固化进类型系统CLAUDE.md 规定“Pose PCK 必须带均值姿态基线与无泄漏留出划分”。MeanPoseBaseline见 leakage.rs把这一条从“约定”提升为“构造约束”fit(train_poses)只允许用train split的姿态拟合空集报EmptyTrainingPoses形状不一致报PoseShapeMismatchmpjpe(test_poses)计算测试关节到均值姿态关节的平均欧氏距离pck_at(test_poses, threshold)计算距离 threshold的关节占比。模型数字永远不能脱离基线单独存在报告结构把两者焊在一起。EvaluationReport与MEASURED证据门槛报告见 leakage.rs同时携带协议、指标名、模型指标、基线指标与EvidenceGrade等级tag构造约束MeasuredMEASURED必须有非空 reproducer 命令行否则报MissingReproducer指标须有限SyntheticSYNTHETIC合成/生成数据上计算ClaimedCLAIMED引自别处本仓库未复现measured(...)拒绝空 reproducer即“没有复现命令的数字不算测出来的”NonFiniteMetric拒绝 NaN/±inf。summary()输出单行带标签摘要例如[MEASURED] cross-subject pck0.2: model 0.6100 vs mean-pose baseline 0.4100。EvaluationReport可 serde 序列化往返便于以 JSON 落盘归档。验证方式测试与基准按 ADR-291 的 Validation 一节验证命令如下当前仓库中 crate 名与 bench 名见 Cargo.tomlcargo test -p wifi-densepose-trainbfee 解析器单测截断、损坏与合法合成 fixture 全覆盖划分确定性、泄漏审计拒绝用例、均值姿态基线数值。cargo bench -p wifi-densepose-trainbenchmark_harnessbenches/benchmark_harness.rs在代码生成的合成语料上测三件事widar_bfee_parse500 条 3×3 记录解析吞吐按字节测吞吐、split_assignment10k 窗口上四种协议的partition按元素测吞吐、leakage_audit10k 窗口 / 200 录制上跑通审计全部检查的耗时。ADR-291 特意声明本 ADR 不声称任何精度数字——它交付的是产出MEASURED数字所需的全部机制。配套的连续录制与 subject 级防泄漏纪律此前已以另一种形式出现在 dataset.rssubject_disjoint_split与assert_split_leak_freeADR-155 Tier-1.2ADR-291 在此基础上将其抽象为通用的协议 / 审计机制。后果与边界条件可比性RuView 首次可以在 Widar3.0 cross-domain gesture、MM-Fi cross-subject pose 等口径上与已发表数字同台比较诚实代价泄漏审计会让一些既有内部数字变差——这正是它的目的维护面解析遗留二进制格式增加维护成本通过“合成 fixture 单测 不重分发数据集”来缓解边界Widar 原始发行版是 Intel 5300 专属格式ESP32 采集的数据继续走既有 loader。协议 / 泄漏机制本身 loader 无关可复用于 MM-Fi 等其他接入。【免费下载链接】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 公开基准评测基座（ADR-291）：Widar3.0 接入、标准划分协议与结构性防泄漏审计
RuView 公开基准评测基座ADR-291Widar3.0 接入、标准划分协议与结构性防泄漏审计【免费下载链接】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导读本文基于 ADR-291Public-benchmark evaluation harness系统讲解 RuView v2 Rust 工作区如何在wifi-densepose-traincrate 中落地“可与公开榜对齐的评测能力”一是解析并接入 Widar3.0 的 Intel 5300.datbfee原始 CSI 日志二是实现 cross-subject / cross-environment / cross-orientation 三类标准评测划分协议三是引入结构性的泄漏审计、均值姿态基线与证据分级报告。读完本文你将掌握该评测基座的整体设计动机、二进制格式细节、纯函数划分机制与类型系统级的防泄漏约束并能直接复现cargo test/cargo bench验证。背景为什么需要公开基准评测基座自采数据与自定义指标无法横向比较ADR-291 指出RuView 此前实现了该领域的关键技术CSI ratio、BVP 特征、MAE 预训练、快速适配等但结果仅在自采数据与自定义指标如 README 中的 temporal-triplet 留出准确率上报告。wifi-densepose-train已有MmFiDataset的 NPY 加载器与确定性的SyntheticCsiDataset见 dataset.rs但缺少三个关键能力Widar3.0 数据接入没有 Intel 5300.dat原始格式的解析器标准划分协议没有 cross-subject / cross-environment 等学术界公认的评测口径结构性防泄漏护栏没有在代码层强制 CLAUDE.md 提出的均值姿态基线与无泄漏留出划分要求。2024–2025 年领域性泄漏教训文献扫描发现领域内存在一次被充分记录的“泄漏大清算”对连续录制数据做window 级随机切分会显著虚高精度——某个数据集在 subject-disjoint 划分下 F1 从约 90% 崩塌到约 22%ADR-291 引述 Sensors 24(10):3159 与 Signals 6(4):59。根本原因是 stride-1 滑动窗口切出的相邻窗口近乎相同把它们分到 train/test 两侧约等于在测试集里“剧透”训练数据。正因如此MmFiDataset的源码注释里专门有一段防泄漏纪律说明见 dataset.rsMM-Fi 窗口以 stride 1 提取相邻窗口重叠window_frames − 1帧naive 索引级随机切分信息泄漏可达约 99%因此必须按 subject 级整体切分。ADR-291 把这一纪律从单一数据集的注释提升为通用的、loader 无关的协议与审计机制。备选方案对比方案结论什么都不做继续只报自采指标拒绝延续不可比缺口无法进入科学引用与 OEM 授权对话在 Rust 管线旁再移植一套 Python 评测栈如 SenseFi拒绝违反 v2 Rust 工作区方向并引入未经审查的依赖面在wifi-densepose-train内扩展原生 loader 协议机制采纳保持 Rust 单栈、复用既有CsiDatasettrait三大交付接入、划分、防泄漏ADR-291 的落点集中在 v2/crates/wifi-densepose-train代码结构对应三个模块src/dataset/widar.rs —— Widar3.0 接入§1src/protocols.rs —— 划分协议§2src/protocols/leakage.rs —— 泄漏审计 / 均值基线 / 证据分级§3三者通过 crate 根导出统一暴露见 lib.rs错误类型集中在 error.rsProtocolError分支。Widar3.0 接入bfee.dat解析器与WidarDataset二进制记录格式“bfee” 帧Widar3.0 原始发行版使用 Intel 5300 网卡 Linux 802.11n CSI Tool 采集存储为带帧结构的二进制.dat日志。ADR-291 与 widar.rs 给出了精确布局frame : u16 LE field_len | u8 code (code 0xBB bfee record) field_len 计入 code 字节与 payload因此下一帧起点 field_len 2 字节处 payload : 20 字节 bfee 头 [0..4) timestamp_low u32 LE [4..6) bfee_count u16 LE [6..8) reserved (2 字节忽略) [8] n_rx u8 (1..3) [9] n_tx u8 (1..3) [10..13) rssi_a/b/c u8 各 1 [13] noise i8 [14] agc u8 [15] antenna_sel u8 [16..18) len u16 LE (packed CSI 字节数) [18..20) rate u16 LE 之后是 len 字节 packed CSI csi : 10-bit 二进制补码分量LSB-first 无间隔填充打包顺序为 for sc in 0..30 { for rx in 0..n_rx { for tx in 0..n_tx { real; imag; } } } len 必须等于 ceil(30 * n_rx * n_tx * 2 * 10 / 8)关键源码常量见 widar.rs常量值含义BFEE_CODE0xBBbfee 记录标识BFEE_HEADER_LEN20固定头字节数WIDAR_SUBCARRIERS30Intel 5300 在 20/40 MHz 上报的载波组数CSI_COMPONENT_BITS10每个复分量位数MAX_ANTENNAS3天线数上限MAX_FIELD_LEN4096单帧长度上限防止无界分配MAX_DAT_FILE_BYTES512 MiB.dat文件大小上限packed_csi_len(n_rx, n_tx) ceil(30 × n_rx × n_tx × 2 × 10 / 8)实测 1×1 → 75、3×1 → 225、3×3 → 675 字节有单测packed_len_matches_formula佐证。BfeeRecord完整保留了timestamp_low、bfee_count、RSSI a/b/c、noise、agc、antenna_sel、rate与csi: Array3Complex32shape[n_tx, n_rx, 30]见 widar.rs。一个重要边界原始 CSI Tool 日志与 Widar 发行版的差异模块文档明确警告见 widar.rs原始 Linux CSI Tool 写入的是8-bit 分量 每组 shift 位 大端帧长若直接喂入未经转换的上游原始日志会因len一致性校验失败而被跳过warn 而非静默误码。这保证了解析器不会把错误格式悄悄解出“看起来合理”的错误数据。解析器的“永不 panic”设计.dat被视为不可信输入解析必须在边界处校验CLAUDE.md 非协商规则。parse_bfee_bytes的实现策略见 widar.rs无效或截断记录被跳过并 warn计入BfeeParse::skipped非 bfee 代码的完好记录被忽略计入BfeeParse::non_bfee真实日志会混入其它记录类型field_len超上限framing 不可恢复时停止解析剩余缓冲文件末尾残留不足帧头的悬挂字节视为截断并计数。位级解包使用流式BitReader每字节只加载一次、无分支符号扩展见 widar.rs。配套提供了确定性 fixture 编码器encode_bfee_frame见 widar.rs测试与 bench 的合成.dat字节全部由代码生成仓库永不检入任何二进制数据集文件。从路径解析领域元数据Widar 文件名约定构建环境无法访问 Widar 站点ADR-291 标注为依据论文/发布说明推断的假定约定解析器刻意宽容缺失字段解析为 0root/[room1/]date/user1/user1-3-1-1-2-r5.dat │ │ │ │ │ └ receiver id可选 │ │ │ │ └ repetition 次数 │ │ │ └ face orientation1..5 │ │ └ torso location1..5 │ └ gesture 类型 └ user idparse_widar_path返回WidarFileMetauser / gesture / location / orientation / repetition / receiver / room见 widar.rsroom id 取自最近的roomN祖先目录大小写不敏感目录树按采集日期分组而没有 room 目录时默认为 0——此时对这类目录树做 cross-environment 划分会在审计阶段失败而非静默放行。WidarDataset把.dat映射为窗口化CsiSampleWidarDataset实现既有CsiDatasettraitlen/get/name行为要点discover(root, window_frames, target_subcarriers)递归扫描.dat按文件名排序建立前缀和窗口索引不可读、超大、无有效记录的.dat文件被 warn 跳过根目录无任何可用记录时报错见 widar.rs每个.dat文件视为一条连续录制泄漏审计的recording_id就是它在排序扫描中的下标get()惰性重读文件并按 stride-1 切窗帧数不足窗口则报错每帧 CSI 从[n_tx, n_rx, 30]展开为幅度/相位四维张量[window_frames, n_tx, n_rx, 30]若目标载波数与 30 不同则经interpolate_subcarriers插值到target_subcarriers见 widar.rsWidar 是手势数据集、无姿态真值因此CsiSample::keypoints置零、visibility 为 0COCO not labelledsubject_id/action_id分别承载 user id 与 gesture id无网络访问loader 只读本地数据集根目录数据集下载是文档化的人工步骤。单元测试覆盖了 bfee 解析往返、负值符号扩展、确定性、空缓冲、截断/悬挂字节/零长帧/超大帧长/非 bfee 码/天线数越界/len 字段不符等场景以及端到端目录发现与元数据映射见 widar.rs 的 tests 模块。标准划分协议把“留出什么”表达为纯函数SplitProtocol与SplitSide协议定义见 protocols.rs枚举变体语义tag声称的不相交性claims()CrossSubject留出整批受试者MM-Fi 风格cross-subjectsubject-disjointCrossEnvironment留出整批环境/房间cross-environmentenvironment-disjointCrossOrientation留出整批朝向Widar 风格cross-orientationorientation-disjointRandomBaselinewindow 级随机切分显式标注为易泄漏基线仅供对比random-baseline-leaky不声称任何不相交性SampleMeta是 loader 无关的按窗元数据subject_id/environment_id/orientation_id/gesture_id/recording_id连续录制标识/window_index由例如WidarDataset::sample_meta生成见 protocols.rs。SplitPlan::assign无 RNG 状态的确定性哈希切分赋值是元数据 seed 的纯函数保证跨运行、跨平台、跨迭代顺序字节级一致按协议取出被留出的“单元”subject / environment / orientation 的 idRandomBaseline 则为recording_idwindow_index通过四个不同 domain tag 常量SUBJ/ENVR/ORNT/RNDM见 protocols.rs防止“subject 3 与 orientation 3 在同一个 seed 下共享哈希”这类碰撞用 splitmix64 混合单元哈希与 seed用整数阈值比较test_fraction × 2^64无浮点累积判定归属保证各平台一致。同一单元的所有窗口必然同侧唯一例外是RandomBaseline按窗哈希——这正是它被文档化的泄漏点。SplitPlan::new会拒绝非有限或不在(0,1)区间内的test_fractionProtocolError::InvalidTestFraction。相关测试覆盖坏分数拒绝、跨调用/跨顺序确定性、不同 seed 产生不同切分、cross-subject 保持 subject 完整、RandomBaseline 必然切穿同一录制见 protocols.rs。结构性泄漏护栏与证据分级LeakageAudit审计失败是Err不是警告审计器见 leakage.rs按顺序校验train / test 两侧均非空EmptyPartition无条件同一条连续录制的窗口不得横跨两侧RecordingCrossesSplit——即便协议本身不声称任何不相交性协议声称 subject 不相交时校验之SubjectOverlap协议声称 environment 不相交时校验之EnvironmentOverlap协议声称 orientation 不相交时校验之OrientationOverlap。审计通过时返回LeakageAuditPass携带两侧窗口数、subject 数、录制数等仅作报告用途的计数不声称超出结构校验范围的任何结论。失败返回描述首个违规的ProtocolError。对应错误变体统一定义在 error.rs。测试明确验证了“漏就拒绝”subject 重叠被拒、claimed environment/orientation 重叠被拒、RandomBaseline 端到端划分必然触发RecordingCrossesSplit见 leakage.rs。值得注意的设计取舍一个“clean”的同一对 split在声称 environment 不相交的协议下失败、在不声称的协议如CrossSubject下通过——审计只保证协议声称的属性。MeanPoseBaseline把 CLAUDE.md 规则固化进类型系统CLAUDE.md 规定“Pose PCK 必须带均值姿态基线与无泄漏留出划分”。MeanPoseBaseline见 leakage.rs把这一条从“约定”提升为“构造约束”fit(train_poses)只允许用train split的姿态拟合空集报EmptyTrainingPoses形状不一致报PoseShapeMismatchmpjpe(test_poses)计算测试关节到均值姿态关节的平均欧氏距离pck_at(test_poses, threshold)计算距离 threshold的关节占比。模型数字永远不能脱离基线单独存在报告结构把两者焊在一起。EvaluationReport与MEASURED证据门槛报告见 leakage.rs同时携带协议、指标名、模型指标、基线指标与EvidenceGrade等级tag构造约束MeasuredMEASURED必须有非空 reproducer 命令行否则报MissingReproducer指标须有限SyntheticSYNTHETIC合成/生成数据上计算ClaimedCLAIMED引自别处本仓库未复现measured(...)拒绝空 reproducer即“没有复现命令的数字不算测出来的”NonFiniteMetric拒绝 NaN/±inf。summary()输出单行带标签摘要例如[MEASURED] cross-subject pck0.2: model 0.6100 vs mean-pose baseline 0.4100。EvaluationReport可 serde 序列化往返便于以 JSON 落盘归档。验证方式测试与基准按 ADR-291 的 Validation 一节验证命令如下当前仓库中 crate 名与 bench 名见 Cargo.tomlcargo test -p wifi-densepose-trainbfee 解析器单测截断、损坏与合法合成 fixture 全覆盖划分确定性、泄漏审计拒绝用例、均值姿态基线数值。cargo bench -p wifi-densepose-trainbenchmark_harnessbenches/benchmark_harness.rs在代码生成的合成语料上测三件事widar_bfee_parse500 条 3×3 记录解析吞吐按字节测吞吐、split_assignment10k 窗口上四种协议的partition按元素测吞吐、leakage_audit10k 窗口 / 200 录制上跑通审计全部检查的耗时。ADR-291 特意声明本 ADR 不声称任何精度数字——它交付的是产出MEASURED数字所需的全部机制。配套的连续录制与 subject 级防泄漏纪律此前已以另一种形式出现在 dataset.rssubject_disjoint_split与assert_split_leak_freeADR-155 Tier-1.2ADR-291 在此基础上将其抽象为通用的协议 / 审计机制。后果与边界条件可比性RuView 首次可以在 Widar3.0 cross-domain gesture、MM-Fi cross-subject pose 等口径上与已发表数字同台比较诚实代价泄漏审计会让一些既有内部数字变差——这正是它的目的维护面解析遗留二进制格式增加维护成本通过“合成 fixture 单测 不重分发数据集”来缓解边界Widar 原始发行版是 Intel 5300 专属格式ESP32 采集的数据继续走既有 loader。协议 / 泄漏机制本身 loader 无关可复用于 MM-Fi 等其他接入。【免费下载链接】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），仅供参考