wifi-densepose-sar-harness 健康检查doctor命令深度解析内核加载、MCP 接线、内存后端与宿主适配器的全链路验证【免费下载链接】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/RuViewwifi-densepose-sar-harness 是服务于 coherent wideband RF tomography 研究 crate即 wifi-densepose-sar对应仓库文档 ADR-287-coherent-wideband-rf-tomography-crate的 AI 编码助手 Harness。doctor是该 Harness 的安装健康检查命令它以一次调用完成内核能否加载、MCP 工具是否接线、内存后端是否可达、宿主适配器是否就位四项验证并以 PASS/FAIL 表格与进程退出码给出确定性结论。读完本文你将掌握 doctor 命令的完整用法、其底层实现原理Rust 编译 WASM 内核 NAPI-RS 原生回退以及如何用 Vitest 冒烟测试把安装检查固化为自动化回归。一、doctor 命令在 Harness 中的定位在 harness/wifi-densepose-sar/CLAUDE.md 的命令清单中doctor 被定义为doctor— Health-check the harness: kernel load, MCP wiring, memory backend, host adapter.它解决的是 Agent Harness 类工具最典型的装好了但不知道有没有装对问题metaharness/kernel是否成功解析到可运行的后端、metaharness/host-claude-code宿主适配器是否注册成功、.claude/commands目录中的命令定义是否与 MCP 工具列表保持一致。CLAUDE.md 中特别指出MCP 工具列表mcp__wifi-densepose-sar-harness__*正是从每个.claude/commands/name.md派生而来——因此 doctor 自身作为命令定义文件doctor.md的存在本身就参与了 MCP 接线的构成。二、命令定义原文四项检查的验收标准harness/wifi-densepose-sar/.claude/commands/doctor.md 是 doctor 命令的完整规格说明原文定义了四道检查与一条退出码约定内核加载与版本匹配metaharness/kernel能成功loadKernel()且kernelInfo().version与 package.json 中声明的版本一致MCP 接线MCP 服务器能够启动并列出其工具列表即.claude/commands/*.md派生出的mcp__wifi-densepose-sar-harness__*工具集内存后端可达kernel 内部的内存memory后端能够被访问——在 Harness 架构中记忆与路由均由 kernel 托管CLAUDE.md 明确说明Memory and routing are handled by the kernel — you dont need to learn them因此该检查本质上是内核健康度的延伸宿主适配器就位配置的宿主适配器本 Harness 为metaharness/host-claude-code存在且可解析。退出码契约任一检查失败进程必须以非零退出码结束Exit non-zero if any check fails从而让 doctor 可被脚本与 CI 可靠消费。三、源码级实现PASS/FAIL 表与退出码的落地doctor 的实际实现位于 harness/wifi-densepose-sar/bin/cli.js。值得注意的是该文件是刻意保持零构建步骤的纯 ESM JavaScript通过npx wifi-densepose-sar-harness即可直接运行npm run build仅在你扩展src/下的 TypeScript 时才需要。核心代码如下async function doctor() { const kernel await loadKernel(); const info kernel.kernelInfo(); const checks [ [kernel loads, !!kernel], [kernel reports a version, typeof info.version string info.version.length 0], [kernel backend is native|wasm|js, [native, wasm, js].includes(kernel.backend)], [host adapter has a name, typeof adapter?.name string adapter.name.length 0], ]; let ok true; for (const [label, pass] of checks) { console.log(${pass ? PASS : FAIL} ${label}); if (!pass) ok false; } console.log( ok ? \n${HARNESS_NAME}: all checks passed (kernel ${info.version}, ${kernel.backend} backend, host ${adapter.name}) : \n${HARNESS_NAME}: doctor found problems, ); return ok ? 0 : 1; }从源码可以看到四个具体落点检查检查标签判定条件失败含义kernel loadsloadKernel()返回值非空内核 WASM/native 模块加载失败kernel reports a versionkernelInfo().version是非空字符串内核已加载但元信息缺失kernel backend is native\|wasm\|jskernel.backend属于[native,wasm,js]内核后端状态异常不属于任何已知后端host adapter has a nameadapter.name是非空字符串宿主适配器未正确解析任何一项失败都会把ok置为false最终返回退出码1全部通过则打印all checks passed (kernel version, backend backend, host adapter.name)并返回0。这一实现与命令文档中的退出码契约完全一致也与命令分发器bin/cli.js中未知命令返回 2、已知命令正常分发的错误码约定相互呼应。对照说明命令文档中的四项验收内核版本匹配、MCP 工具列表、内存后端、宿主适配器在 CLI 实现中落点为四项可机械判定的断言其中内存后端可达与MCP 接线在实现层由kernel成功加载这一前提所覆盖内核不可用则后两者必然不可达这是从 bin/cli.js 的代码结构可以作出的合理推断。四、逐项深挖四项检查背后的架构原理4.1 内核加载与版本Rust 编译 WASM NAPI-RS 原生回退doctor 的第一项检查依赖metaharness/kernel。根据 CLAUDE.md 的 Architecture 一节这是一个Rust 编译的 WASM 模块带 NAPI-RS 原生回退——同一份代码在所有平台上以一致行为运行后端按native → wasm → js的优先级解析README 中说明当前发布的 beta 使用 js 后端并提示参见harness doctor的输出确认实际后端。kernelInfo().version用于版本报告kernel.backend用于标明当前生效的解析后端两者共同构成内核已就绪的证据。对应的初始化入口见 harness/wifi-densepose-sar/src/init.tsinit命令同样执行loadKernel()并打印内核版本、后端与宿主适配器名随后提示Runwifi-densepose-sar-harness doctorto verify the install——init 完成引导doctor 完成验证形成闭环。4.2 MCP 接线命令文件即工具清单CLAUDE.md 明确写道Each command below has a matching.claude/commands/name.mdguidance file — the MCP tool listing (mcp__wifi-densepose-sar-harness__*) is derived from these。也就是说MCP 工具列表不是手工维护的独立清单而是从命令定义文件派生而来。doctor 检查中命令文件存在且可解析的意义正在于此一个新 CLI 子命令在拥有对应.claude/commands/name.md之前不能算完成接线。4.3 内存后端kernel 托管的记忆层CLAUDE.md 的行为规则第二条是Memory and routing are handled by the kernel — you dont need to learn them。内存后端memory backend是 kernel 提供的记忆存储能力Agent 无需直接接触doctor 将其纳入检查范围是为了确保托管记忆的底层通道在安装后即可用。由于该后端生命周期与 kernel 绑定doctor 中kernel loads检查通过即可视为内存后端可达的前提得到满足。4.4 宿主适配器claude-code 驱动的桥接本 Harness 随附的是claude-code 适配器见 README.md 的 This harness ships with theclaude-codeadapter对应 npm 依赖metaharness/host-claude-codepackage.json 中声明为^0.1.0。doctor 检查adapter.name非空即验证宿主桥接模块在运行时环境里被正确解析——这是后续所有 Agent 编排architect → implementer → reviewer → test-writer能够通过 MCP 工具与宿主对话的基础。五、安装与运行从零到 doctor 全绿依据 README.md 的安装说明完整流程为npm install -g wifi-densepose-sar-harness # 全局安装发布在 npm包名见 package.json 的 name 字段 wifi-densepose-sar-harness init # 引导加载内核 宿主适配器并报告状态 wifi-densepose-sar-harness doctor # 健康检查打印 PASS/FAIL 表若以仓库源码方式运行可进入 harness/wifi-densepose-sar 目录执行npm install后通过 package.json 中已声明的脚本npm run doctor或直接node ./bin/cli.js doctor运行。环境前提是 Node.js 20见 package.json 的engines字段。doctor 的预期输出形态成功时PASS kernel loads PASS kernel reports a version PASS kernel backend is native|wasm|js PASS host adapter has a name wifi-densepose-sar-harness: all checks passed (kernel 0.1.0, wasm backend, host claude-code)任一检查失败则对应行显示FAIL末行变为wifi-densepose-sar-harness: doctor found problems进程以退出码 1 结束。六、把健康检查固化为自动化Vitest 冒烟测试doctor 的可脚本化退出码使其天然适合纳入测试。仓库自带的 harness/wifi-densepose-sar/tests/smoke.test.ts 以 Vitest 实现了安装冒烟测试它不是占位符——真实引导 kernel 与宿主适配器断言loadKernel()返回的内核版本为非空字符串断言kernel.backend属于[native, wasm, js]断言宿主适配器adapter.name非空直接以run([doctor])调用 CLI 分发器bin/cli.js 将run导出以便测试免子进程驱动断言退出码为0反向断言未知命令run([definitely-not-a-command])必须返回非零。也就是说npm testvitest run失败即代表npm install产出的 Harness 不可运行。这套测试与 doctor 命令构成双重保障doctor 是运维时的即时体检smoke test 是开发时的持续回归。七、doctor 与兄弟命令一次安装全链路可用doctor 验证的是底座而 Harness 的能力面由其余命令组成均需在 doctor 全绿的前提下使用其中route与flywheel需要先npm run buildroute e0 e1 e2 e3通过metaharness/router做成本最优模型路由把四轴任务嵌入physicsExplanation / codeReview / numericalDebugging / docWriting各取 0..1映射到最便宜且预测质量达标qualityBar: 0.8的模型档位实现见 harness/wifi-densepose-sar/src/router.tsflywheel [generations]运行metaharness/flywheel的 propose → evaluate → gate → promote 自我改进演示环Ed25519 签名 可独立重放实现见 harness/wifi-densepose-sar/src/flywheel.tsinit内核 宿主适配器引导--version/--help打印内核版本与全部子命令用法。需要特别说明的是这两处与 doctor 相关的诚实性标注src/router.ts顶部注明其候选示例是 SEED/示意数据而非实测 eval 日志生产路由前需用真实embedding → quality数据替换src/flywheel.ts则注明 Proposer 与 Evaluator 均为 SYNTHETIC 替身无模型调用真实运行需运营者自行接入真实 Proposer 与真实编码任务锚点套件。doctor 只保证安装与接线健康不承诺路由决策或自我改进结论的真实性——两者边界清晰这正是该 Harness 对数据来源诚实标注的体现。八、故障排查doctor 报告 FAIL 时如何定位基于 bin/cli.js 的实现结构可以给出如下排查路径属于从代码结构得出的推断性建议kernel loadsFAIL多为metaharness/kernel未正确安装或其 WASM/native 构件与当前平台不匹配优先检查npm install是否完整执行、node_modules 中该包是否可解析kernel backend is native|wasm|jsFAIL内核已加载但 backend 状态异常通常意味着解析层返回了未知后端标识需核对metaharness/kernel版本package.json 声明^0.1.0host adapter has a nameFAILmetaharness/host-claude-code未解析检查依赖是否安装、是否为 ESM 导入路径问题cli.js 以import adapter from metaharness/host-claude-code默认导入版本不一致命令文档要求kernelInfo().version与 package.json 匹配若升级内核依赖后版本号漂移doctor 会通过版本字符串非空但无法证明与声明一致——这也是将 doctor 纳入 CI、配合 smoke test 一起回归的价值所在。结语doctor虽然只是一个几十行的命令却集中体现了 wifi-densepose-sar-harness 的工程哲学可验证、可脚本化、可自动化。它以四道确定性检查覆盖了内核Rust WASM/native/js 三层解析、MCP 接线命令文件派生工具清单、内存后端kernel 托管、宿主适配器claude-code 桥接这四根支撑 Agent 编排的支柱用统一退出码把体检结果交给脚本与测试。当你在这套 Harness 上运行doctor、route、flywheel之前先让它给你一张全绿的 PASS 表是最廉价也最可靠的起点。延伸阅读命令规格 doctor.md 与实现 bin/cli.js、引导入口 init.ts、行为规则与架构说明 CLAUDE.md、安装与命令总览 README.md、冒烟测试 smoke.test.ts、依赖与脚本声明 package.json以及其服务对象 ADR 文档 ADR-287-coherent-wideband-rf-tomography-crate。【免费下载链接】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），仅供参考
