RuView QE 修复计划全解读从 ADR-080 看 305K 行代码库的质量治理与安全边界验证【免费下载链接】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本文以 RuViewWiFi-DensePose 传感项目的 ADR-080: QE Analysis Remediation Plan 为核心档案逐条剖析一次 8 智能体 QE质量工程群评打出的 15 项问题清单及其三波次修复方案并深入 Rust 传感服务器sensing-server源码与测试用例验证三个 P0 级安全问题的真实处置边界与回归测试防线。读者读完可以掌握一次大规模代码库质量体检的完整产出结构P0/P1/P2 分级与修复节奏、CWE-209/CWE-598 等安全缺陷的验证式修复方法论以及 RuView 从 55/100 质量分走向 75 目标分的具体落点。一、背景55/100 分背后的 305K 行代码体检2026-04-05一个由 8 个专职智能体组成的 QE 群fleet-02558e91对 RuView 约305K 行代码进行了全谱系质量评估范围覆盖 Rust153K、Python39K、C 固件9K与 TypeScript/JavaScript33K。结论被记录为 ADR-080其中最重要的量化结果是总体质量分 55/100C——Quality Gate质量门禁判定失败代码质量与复杂度55–82/100有条件通过安全68/100有条件通过性能临界风险实测 37–54ms逼近 50ms 帧预算测试套件质量混合共清点 3,353 个测试但重复严重覆盖率文件级 77%但Python 仅 30%、固件仅 19%产品因素SFDIPOT时间因素判定 CRITICAL。该档案对应的完整 QE 报告已归档于仓库 docs/qe-reports共 9 个文件、4,914 行详见下文报告族谱一节。ADR-080 将体检发现的 15 项优先问题组织成三个修复波次P0立即修复、P1本 sprint、P2本季度并逐一给出了修复动作与目标分预测——P0P1 完成后期望从 55 分提升到75。二、先厘清修复边界Python v1 已归档验证落在 Rust 主边界阅读本档案前必须先理解一个关键背景档案 Status 行与 2026-06-13 补充说明均有明确记载体检打出的三个 P0 安全问题XFF 绕过、异常泄露、URL 中的 JWT最初是针对 Python v1 APIarchive/v1/src 目录树记录的定位点如archive/v1/src/middleware/rate_limit.py:200-206、archive/v1/src/api/routers/pose.py:140等但 v1 已归档不是对外交付面。因此 ADR-164 的 G11 项把这三项重新定位到真正上线的边界Rust 传感服务器wifi-densepose-sensing-server位于 v2/crates/wifi-densepose-sensing-server2026-06-13 在fix/adr-080-sensing-server-security分支上完成了验证与收口每项修复或本就不存在该漏洞面的确认都由一个在旧行为上必然失败的回归测试钉死Python v1 路径保持原样不动——该收口只管辖线上的 Rust 服务器。这一重定界re-scope思路是质量治理中非常实用的取舍不为一套已归档、不再交付的代码继续支付修复成本而是把资源对准当前真实受攻击面。三、P0 安全项深度拆解三项 HIGH 的验证式修复3.1 #1 Rate Limiter Bypass / XFF 欺骗Security HIGH——已解决Rust 边界验证为不存在该漏洞面v1 原始问题archive/v1/src/middleware/rate_limit.py:200-206无条件信任X-Forwarded-For头任何客户端都能通过伪造该头绕过限流。Rust 边界验证结论2026-06-13Rust sensing-server根本没有可被 XFF 绕过的控制面——不存在基于 IP 的限流器也不存在 IP 白名单两个安全中间件都不读取转发头bearer_auth.rs 中的require_bearer只检查AUTHORIZATION头做鉴权host_validation.rs 只依据真正的Host头做 DNS-rebinding 白名单判定详见 3.4对wifi-densepose-sensing-server全 crate 以x-forwarded-for|forwarded|peer_addr|client_ip|real-ip做仓库级 grep零命中整个 crate 里唯一的限流器是 MQTT 的采样率门控mqtt/state.rs按实体entity做发布节流不接收 IP/头输入。因此无需改代码。回归测试从两个方向钉死免疫性bearer_auth.rs 的xff_header_never_affects_auth_decision伪造的 XFF 永远无法把 401↔200 的鉴权结论翻转——错误/缺失 token 加伪造X-Forwarded-For: 127.0.0.1仍是 401正确 token 即便带X-Forwarded-For: evil-proxy也仍是 200host_validation.rs 的forwarded_headers_never_bypass_host_allowlist用X-Forwarded-Host: localhost 真实Host: evil.com组合发送请求仍返回421 Misdirected Request伪造转发头无法放行白名单之外的主机。残留指引文档明确要求未来若真要加 IP 级控制对端身份必须取自 socketConnectInfoSocketAddr且只在显式配置--trusted-proxyCIDR 时才信任 XFF——这段约束被写进了上述测试的 docstring作为对后续开发者的强制性提醒。3.2 #2 异常细节泄露进响应体Security HIGHCWE-209——已解决v1 原始问题archive/v1/src/api/routers/pose.py:140、stream.py:297及另外 5 个端点把内部错误/堆栈细节直接序列化进客户端响应。Rust 边界发现sensing-server 的 main.rs 中有6 个 handler曾把内部错误的Display直接写进 JSON 响应体edge_registry_endpoint把 panic 的spawn_blocking任务返回的JoinError形如task … panicked放进 500 响应上游原始错误则进了 503 响应delete_model/delete_recording/start_recording返回std::io::Error的字符串带 OS 错误细节与文件路径calibration_start/calibration_stop返回FieldModel的错误链。修复方案新增独立模块 error_response.rs定义三个带泄漏防护契约的辅助函数internal_error(context, detail)返回 HTTP 500 通用体internal_error_json(context, detail)给那些类型为Jsonserde_json::Value、靠success: false表达失败的历史 handler 使用upstream_unavailable(context, detail)503 上游不可用专用变体避免泄露可携带内部 URL/连接串的原始上游错误。其核心机制是细节只留在服务端完整 detail 以error/warn级别写入服务端日志并打上 16 位十六进制小写关联 IDcorrelation id返回给客户端的统一只有{ error: internal_error, correlation_id: a1b2c3d4e5f60718, success: false }该 body刻意不包含底层错误的Display/Debug、不包含文件路径、永不出现panicked字样。关联 ID 由纳秒时间戳异或单调计数器生成error_response.rs足以让运维把客户端报障 ID 与服务端日志行精确对上。回归测试防线同一文件的tests模块internal_error_body_does_not_leak_detail用一条携带文件路径、OS 错误与panicked字样的泄漏样串LEAKY_DETAIL做泄漏子串守卫——递归收集 JSON 全部字符串值断言不出现panicked、secret、os error、.rvf中的任何一项文档明确记载该测试在回退到旧响应体时必然失败。另有 4 个兄弟测试分别验证通用体带合法关联 IDinternal_error_body_is_generic_with_correlation_id、internal_error_json变体同享泄漏保证、503 上游路径不泄露内部主机/连接细节upstream_unavailable_does_not_leak_detail、快速连续调用下关联 ID 不重复correlation_ids_are_unique。3.3 #3 WebSocket JWT 放进 URLSecurity HIGHCWE-598——已解决Rust 边界验证为不存在该路径v1 原始问题archive/v1/src/api/routers/stream.py:74与archive/v1/src/middleware/auth.py:243允许令牌出现在查询字符串中——令牌会随之进入日志、代理记录与浏览器历史。Rust 边界验证Rust sensing-server从不从 URL 读取令牌require_bearer只检查Authorization头WebSocket handlerws_sensing_handler/ws_introspection_handler/ws_pose_handler只接收裸的WebSocketUpgrade没有Query提取器全 crate 中唯一的Query提取是EdgeRegistryParams其内容是非敏感的refresh标志位。结论同样是无需改代码。回归测试query_string_token_is_never_acceptedbearer_auth.rs证明了即使把正确的 token 放在?token或?access_token里请求仍然 401而同一 token 放进Authorization头则返回 200。文档记录该测试在query-token 路径被重新引入时会失败起到行为锁的作用。3.4 补充说明P0 安全验证所依托的另外两道防线虽然 #1、#3 在 Rust 边界的结论是无需修改但要理解为什么这两项能干净关闭还需看到 host/bearer 两层中间件本身的当代设计——它们正是 ADR-080 之后的产物相关演进见 ADR-272: WebSocket Authentication TicketsHost 头白名单防 DNS rebinding默认绑定回环地址时恶意网页可把 DNS 指向127.0.0.1冒充同源请求从而偷读实时姿态/呼吸/心率流或触发状态变更 POST。host_validation.rs 对不在白名单内的Host一律回421 Misdirected Request默认白名单覆盖localhost/127.0.0.1/[::1]带或不带:PORT对外绑定时--bind-addr 0.0.0.0或局域网 IP用--allowed-host或SENSING_ALLOWED_HOSTS环境变量扩展且决定信号只有真实Host头任何客户端转发头一律无视。Bearer 鉴权的 deny-by-default 与作用域门require_bearer在设置了RUVIEW_API_TOKEN时保护/api/v1/*树未设置时保持默认的仅局域网无鉴权姿态WebSocket 升级路径/ws/sensing、/ws/introspection、/api/v1/stream/pose则接受 bearer 或单次使用票据。required_scope_for采用读开放、写默认关闭的作用域极性——凡变更类方法默认要求sensing:admin只有进入显式READ_SAFE_MUTATIONS白名单的路径才降到sensing:read从设计上杜绝新增一条破坏性路由却意外落在读作用域的漏洞。四、P0 其余两项CI 与移动端 WebSocket4.1 #4 Rust 测试从未进 CI最大代码库153K 行 Rust里躺着2,618 个测试却零个在任何 GitHub Actions 工作流中运行——回归可以无感上线。修复动作极简在 CI 中加入cargo test --workspace --no-default-features预估工作量 1–2 小时。4.2 #5 WebSocket 路径不一致Bug移动端 ws.service.ts 构造的是/ws/sensing而常量文件constants/websocket.ts定义的WS_PATH /api/v1/stream/pose。后果是移动端 WebSocket 静默失败。修复方向是统一路径并核实服务器真正服务的端点。值得注意的是后续演进中/ws/sensing与/api/v1/stream/pose都成为了受保护/可发的升级端点见上节及 bearer_auth.rs 的WS_PATHS印证了文档中Verify which endpoint the server actually serves的务实提醒。五、P1本 sprint与 P2本季度清单P1 五项性能与代码健康#问题定位影响6God 文件4,846 行、圈复杂度 CC121sensing-server/src/main.rs对应现仓库 v2/crates/wifi-densepose-sensing-server/src/main.rs不可测试的单体7每帧 O(L×V) 体素扫描ruvsense/tomography.rs:345-383每帧浪费约 10ms应改用 DDA 光线步进8串行神经网络推理wifi-densepose-nn inference.rs:334-3362–4 倍 GPU 延迟惩罚9全工作区 720 处.unwrap()工作区每个都可能成为实时路径上的 panic10Python 每帧 112KB 分配csi_processor.py:412-414每帧 Deque→list→numpy 转换P2 五项覆盖缺口与生产加固#问题影响1112 个 Python 模块中 11 个零单元测试12,280 LOC服务、中间件、DB 均未测试12固件覆盖率仅 19%WASM 运行时、OTA、swarm安全关键代码未测试13MAT 屏自动回退到模拟数据救灾人员可能监控到假数据14认证期间从不查询 token 黑名单已吊销 token 仍有效1550ms 帧预算从未基准化实时性要求未被验证六、档案背面值得保留的 Bright Spots一次质量体检如果只报问题是不完整的。ADR-080 同时明确记录了该项目的六项亮点可与前文中的修复细节相互印证79 份 ADR出众的治理记录——本档案正是其一Witness bundle 系统ADR-028 体系带 SHA-256 证明2,618 个数学严谨度高的 Rust 测试数量与质量并存的证据也解释了为何 #4测试不进 CI是重大痛点每日安全扫描Bandit、Semgrep、Safety固件上的 Ed25519 WASM 签名验证干净、测试覆盖良好的移动端状态管理。七、完整 QE 报告族谱9 文件 / 4,914 行ADR-080 只是索引卡体检全量产出保留在 docs/qe-reports每一份报告解决一类体检视角可对应 P0–P2 各项来源报告覆盖内容EXECUTIVE-SUMMARY.md顶层综合全部分数与优先级矩阵00-qe-queen-summary.md总协调、质量姿态、测试金字塔01-code-quality-complexity.md圈复杂度、代码坏味、Top 20 热点02-security-review.md15 项安全发现3 HIGH、7 MEDIUM、OWASP 覆盖03-performance-analysis.md23 项性能发现4 CRITICAL、帧预算分析04-test-analysis.md3,353 个测试清点、重复度、质量分级05-quality-experience.mdAPI/CLI/Mobile/DX 用户体验评估06-product-assessment-sfdipot.mdSFDIPOT 分析、57 个测试构想、14 个 session charter07-coverage-gaps.md覆盖率矩阵、Top 20 风险缺口、8 周路线图八、结论与预期收益ADR-080 在 Consequences 中给出明确的修复收益账P0 修复消除 3 个安全漏洞与 2 个功能 BugP1 修复改善性能、可靠性与可维护性P2 修复补上覆盖缺口、为生产环境加固系统目标分P0P1 完成后从 55 → 75。截至本档案 Status 行标注2026-06-13三个 P0 安全项已在 Rust sensing-server 边界收口其中两项#1 XFF、#3 URL 令牌的结论是无此漏洞面、回归测试钉死免疫一项#2 异常泄露以 error_response.rs 的通用错误体 服务端日志 关联 ID 机制落地并同步关闭了 ADR-164 的 G11 项。该 crate 的安全边界整体说明可在 SECURITY.md 查阅。对读者而言这份档案最有借鉴价值的不是修了什么而是一套可复用的质量治理方法多智能体体检的量化打分与分级定责P0/P1/P2 对应时间刻度、对已归档代码的重定界不背债决策、以及修复即测试的验证纪律——每一个安全结论哪怕是本就不存在都要有回归测试作证而测试必须设计成在旧行为上会失败才能真正锁死历史漏洞的重现路径。【免费下载链接】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 QE 修复计划全解读：从 ADR-080 看 305K 行代码库的质量治理与安全边界验证
RuView QE 修复计划全解读从 ADR-080 看 305K 行代码库的质量治理与安全边界验证【免费下载链接】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本文以 RuViewWiFi-DensePose 传感项目的 ADR-080: QE Analysis Remediation Plan 为核心档案逐条剖析一次 8 智能体 QE质量工程群评打出的 15 项问题清单及其三波次修复方案并深入 Rust 传感服务器sensing-server源码与测试用例验证三个 P0 级安全问题的真实处置边界与回归测试防线。读者读完可以掌握一次大规模代码库质量体检的完整产出结构P0/P1/P2 分级与修复节奏、CWE-209/CWE-598 等安全缺陷的验证式修复方法论以及 RuView 从 55/100 质量分走向 75 目标分的具体落点。一、背景55/100 分背后的 305K 行代码体检2026-04-05一个由 8 个专职智能体组成的 QE 群fleet-02558e91对 RuView 约305K 行代码进行了全谱系质量评估范围覆盖 Rust153K、Python39K、C 固件9K与 TypeScript/JavaScript33K。结论被记录为 ADR-080其中最重要的量化结果是总体质量分 55/100C——Quality Gate质量门禁判定失败代码质量与复杂度55–82/100有条件通过安全68/100有条件通过性能临界风险实测 37–54ms逼近 50ms 帧预算测试套件质量混合共清点 3,353 个测试但重复严重覆盖率文件级 77%但Python 仅 30%、固件仅 19%产品因素SFDIPOT时间因素判定 CRITICAL。该档案对应的完整 QE 报告已归档于仓库 docs/qe-reports共 9 个文件、4,914 行详见下文报告族谱一节。ADR-080 将体检发现的 15 项优先问题组织成三个修复波次P0立即修复、P1本 sprint、P2本季度并逐一给出了修复动作与目标分预测——P0P1 完成后期望从 55 分提升到75。二、先厘清修复边界Python v1 已归档验证落在 Rust 主边界阅读本档案前必须先理解一个关键背景档案 Status 行与 2026-06-13 补充说明均有明确记载体检打出的三个 P0 安全问题XFF 绕过、异常泄露、URL 中的 JWT最初是针对 Python v1 APIarchive/v1/src 目录树记录的定位点如archive/v1/src/middleware/rate_limit.py:200-206、archive/v1/src/api/routers/pose.py:140等但 v1 已归档不是对外交付面。因此 ADR-164 的 G11 项把这三项重新定位到真正上线的边界Rust 传感服务器wifi-densepose-sensing-server位于 v2/crates/wifi-densepose-sensing-server2026-06-13 在fix/adr-080-sensing-server-security分支上完成了验证与收口每项修复或本就不存在该漏洞面的确认都由一个在旧行为上必然失败的回归测试钉死Python v1 路径保持原样不动——该收口只管辖线上的 Rust 服务器。这一重定界re-scope思路是质量治理中非常实用的取舍不为一套已归档、不再交付的代码继续支付修复成本而是把资源对准当前真实受攻击面。三、P0 安全项深度拆解三项 HIGH 的验证式修复3.1 #1 Rate Limiter Bypass / XFF 欺骗Security HIGH——已解决Rust 边界验证为不存在该漏洞面v1 原始问题archive/v1/src/middleware/rate_limit.py:200-206无条件信任X-Forwarded-For头任何客户端都能通过伪造该头绕过限流。Rust 边界验证结论2026-06-13Rust sensing-server根本没有可被 XFF 绕过的控制面——不存在基于 IP 的限流器也不存在 IP 白名单两个安全中间件都不读取转发头bearer_auth.rs 中的require_bearer只检查AUTHORIZATION头做鉴权host_validation.rs 只依据真正的Host头做 DNS-rebinding 白名单判定详见 3.4对wifi-densepose-sensing-server全 crate 以x-forwarded-for|forwarded|peer_addr|client_ip|real-ip做仓库级 grep零命中整个 crate 里唯一的限流器是 MQTT 的采样率门控mqtt/state.rs按实体entity做发布节流不接收 IP/头输入。因此无需改代码。回归测试从两个方向钉死免疫性bearer_auth.rs 的xff_header_never_affects_auth_decision伪造的 XFF 永远无法把 401↔200 的鉴权结论翻转——错误/缺失 token 加伪造X-Forwarded-For: 127.0.0.1仍是 401正确 token 即便带X-Forwarded-For: evil-proxy也仍是 200host_validation.rs 的forwarded_headers_never_bypass_host_allowlist用X-Forwarded-Host: localhost 真实Host: evil.com组合发送请求仍返回421 Misdirected Request伪造转发头无法放行白名单之外的主机。残留指引文档明确要求未来若真要加 IP 级控制对端身份必须取自 socketConnectInfoSocketAddr且只在显式配置--trusted-proxyCIDR 时才信任 XFF——这段约束被写进了上述测试的 docstring作为对后续开发者的强制性提醒。3.2 #2 异常细节泄露进响应体Security HIGHCWE-209——已解决v1 原始问题archive/v1/src/api/routers/pose.py:140、stream.py:297及另外 5 个端点把内部错误/堆栈细节直接序列化进客户端响应。Rust 边界发现sensing-server 的 main.rs 中有6 个 handler曾把内部错误的Display直接写进 JSON 响应体edge_registry_endpoint把 panic 的spawn_blocking任务返回的JoinError形如task … panicked放进 500 响应上游原始错误则进了 503 响应delete_model/delete_recording/start_recording返回std::io::Error的字符串带 OS 错误细节与文件路径calibration_start/calibration_stop返回FieldModel的错误链。修复方案新增独立模块 error_response.rs定义三个带泄漏防护契约的辅助函数internal_error(context, detail)返回 HTTP 500 通用体internal_error_json(context, detail)给那些类型为Jsonserde_json::Value、靠success: false表达失败的历史 handler 使用upstream_unavailable(context, detail)503 上游不可用专用变体避免泄露可携带内部 URL/连接串的原始上游错误。其核心机制是细节只留在服务端完整 detail 以error/warn级别写入服务端日志并打上 16 位十六进制小写关联 IDcorrelation id返回给客户端的统一只有{ error: internal_error, correlation_id: a1b2c3d4e5f60718, success: false }该 body刻意不包含底层错误的Display/Debug、不包含文件路径、永不出现panicked字样。关联 ID 由纳秒时间戳异或单调计数器生成error_response.rs足以让运维把客户端报障 ID 与服务端日志行精确对上。回归测试防线同一文件的tests模块internal_error_body_does_not_leak_detail用一条携带文件路径、OS 错误与panicked字样的泄漏样串LEAKY_DETAIL做泄漏子串守卫——递归收集 JSON 全部字符串值断言不出现panicked、secret、os error、.rvf中的任何一项文档明确记载该测试在回退到旧响应体时必然失败。另有 4 个兄弟测试分别验证通用体带合法关联 IDinternal_error_body_is_generic_with_correlation_id、internal_error_json变体同享泄漏保证、503 上游路径不泄露内部主机/连接细节upstream_unavailable_does_not_leak_detail、快速连续调用下关联 ID 不重复correlation_ids_are_unique。3.3 #3 WebSocket JWT 放进 URLSecurity HIGHCWE-598——已解决Rust 边界验证为不存在该路径v1 原始问题archive/v1/src/api/routers/stream.py:74与archive/v1/src/middleware/auth.py:243允许令牌出现在查询字符串中——令牌会随之进入日志、代理记录与浏览器历史。Rust 边界验证Rust sensing-server从不从 URL 读取令牌require_bearer只检查Authorization头WebSocket handlerws_sensing_handler/ws_introspection_handler/ws_pose_handler只接收裸的WebSocketUpgrade没有Query提取器全 crate 中唯一的Query提取是EdgeRegistryParams其内容是非敏感的refresh标志位。结论同样是无需改代码。回归测试query_string_token_is_never_acceptedbearer_auth.rs证明了即使把正确的 token 放在?token或?access_token里请求仍然 401而同一 token 放进Authorization头则返回 200。文档记录该测试在query-token 路径被重新引入时会失败起到行为锁的作用。3.4 补充说明P0 安全验证所依托的另外两道防线虽然 #1、#3 在 Rust 边界的结论是无需修改但要理解为什么这两项能干净关闭还需看到 host/bearer 两层中间件本身的当代设计——它们正是 ADR-080 之后的产物相关演进见 ADR-272: WebSocket Authentication TicketsHost 头白名单防 DNS rebinding默认绑定回环地址时恶意网页可把 DNS 指向127.0.0.1冒充同源请求从而偷读实时姿态/呼吸/心率流或触发状态变更 POST。host_validation.rs 对不在白名单内的Host一律回421 Misdirected Request默认白名单覆盖localhost/127.0.0.1/[::1]带或不带:PORT对外绑定时--bind-addr 0.0.0.0或局域网 IP用--allowed-host或SENSING_ALLOWED_HOSTS环境变量扩展且决定信号只有真实Host头任何客户端转发头一律无视。Bearer 鉴权的 deny-by-default 与作用域门require_bearer在设置了RUVIEW_API_TOKEN时保护/api/v1/*树未设置时保持默认的仅局域网无鉴权姿态WebSocket 升级路径/ws/sensing、/ws/introspection、/api/v1/stream/pose则接受 bearer 或单次使用票据。required_scope_for采用读开放、写默认关闭的作用域极性——凡变更类方法默认要求sensing:admin只有进入显式READ_SAFE_MUTATIONS白名单的路径才降到sensing:read从设计上杜绝新增一条破坏性路由却意外落在读作用域的漏洞。四、P0 其余两项CI 与移动端 WebSocket4.1 #4 Rust 测试从未进 CI最大代码库153K 行 Rust里躺着2,618 个测试却零个在任何 GitHub Actions 工作流中运行——回归可以无感上线。修复动作极简在 CI 中加入cargo test --workspace --no-default-features预估工作量 1–2 小时。4.2 #5 WebSocket 路径不一致Bug移动端 ws.service.ts 构造的是/ws/sensing而常量文件constants/websocket.ts定义的WS_PATH /api/v1/stream/pose。后果是移动端 WebSocket 静默失败。修复方向是统一路径并核实服务器真正服务的端点。值得注意的是后续演进中/ws/sensing与/api/v1/stream/pose都成为了受保护/可发的升级端点见上节及 bearer_auth.rs 的WS_PATHS印证了文档中Verify which endpoint the server actually serves的务实提醒。五、P1本 sprint与 P2本季度清单P1 五项性能与代码健康#问题定位影响6God 文件4,846 行、圈复杂度 CC121sensing-server/src/main.rs对应现仓库 v2/crates/wifi-densepose-sensing-server/src/main.rs不可测试的单体7每帧 O(L×V) 体素扫描ruvsense/tomography.rs:345-383每帧浪费约 10ms应改用 DDA 光线步进8串行神经网络推理wifi-densepose-nn inference.rs:334-3362–4 倍 GPU 延迟惩罚9全工作区 720 处.unwrap()工作区每个都可能成为实时路径上的 panic10Python 每帧 112KB 分配csi_processor.py:412-414每帧 Deque→list→numpy 转换P2 五项覆盖缺口与生产加固#问题影响1112 个 Python 模块中 11 个零单元测试12,280 LOC服务、中间件、DB 均未测试12固件覆盖率仅 19%WASM 运行时、OTA、swarm安全关键代码未测试13MAT 屏自动回退到模拟数据救灾人员可能监控到假数据14认证期间从不查询 token 黑名单已吊销 token 仍有效1550ms 帧预算从未基准化实时性要求未被验证六、档案背面值得保留的 Bright Spots一次质量体检如果只报问题是不完整的。ADR-080 同时明确记录了该项目的六项亮点可与前文中的修复细节相互印证79 份 ADR出众的治理记录——本档案正是其一Witness bundle 系统ADR-028 体系带 SHA-256 证明2,618 个数学严谨度高的 Rust 测试数量与质量并存的证据也解释了为何 #4测试不进 CI是重大痛点每日安全扫描Bandit、Semgrep、Safety固件上的 Ed25519 WASM 签名验证干净、测试覆盖良好的移动端状态管理。七、完整 QE 报告族谱9 文件 / 4,914 行ADR-080 只是索引卡体检全量产出保留在 docs/qe-reports每一份报告解决一类体检视角可对应 P0–P2 各项来源报告覆盖内容EXECUTIVE-SUMMARY.md顶层综合全部分数与优先级矩阵00-qe-queen-summary.md总协调、质量姿态、测试金字塔01-code-quality-complexity.md圈复杂度、代码坏味、Top 20 热点02-security-review.md15 项安全发现3 HIGH、7 MEDIUM、OWASP 覆盖03-performance-analysis.md23 项性能发现4 CRITICAL、帧预算分析04-test-analysis.md3,353 个测试清点、重复度、质量分级05-quality-experience.mdAPI/CLI/Mobile/DX 用户体验评估06-product-assessment-sfdipot.mdSFDIPOT 分析、57 个测试构想、14 个 session charter07-coverage-gaps.md覆盖率矩阵、Top 20 风险缺口、8 周路线图八、结论与预期收益ADR-080 在 Consequences 中给出明确的修复收益账P0 修复消除 3 个安全漏洞与 2 个功能 BugP1 修复改善性能、可靠性与可维护性P2 修复补上覆盖缺口、为生产环境加固系统目标分P0P1 完成后从 55 → 75。截至本档案 Status 行标注2026-06-13三个 P0 安全项已在 Rust sensing-server 边界收口其中两项#1 XFF、#3 URL 令牌的结论是无此漏洞面、回归测试钉死免疫一项#2 异常泄露以 error_response.rs 的通用错误体 服务端日志 关联 ID 机制落地并同步关闭了 ADR-164 的 G11 项。该 crate 的安全边界整体说明可在 SECURITY.md 查阅。对读者而言这份档案最有借鉴价值的不是修了什么而是一套可复用的质量治理方法多智能体体检的量化打分与分级定责P0/P1/P2 对应时间刻度、对已归档代码的重定界不背债决策、以及修复即测试的验证纪律——每一个安全结论哪怕是本就不存在都要有回归测试作证而测试必须设计成在旧行为上会失败才能真正锁死历史漏洞的重现路径。【免费下载链接】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），仅供参考