Embedded device control plane

Embedded device control plane 表示设备把 ESP32-S3 作为正式控制面 MCU，并依赖其板载 USB 与 Wi‑Fi 同时承载本地与局域网控制入口。这里的主语不是“某一种传输协议”，而是 devd、CLI、Web App、可选 desktop/local agent、Web Serial 与 native USB 如何围绕同一设备事实、安全边界、发现机制、连接 ownership 和运行态协议协作。这个 Topic 关注的是“同一台设备为什么会同时暴露 USB、本地 bridge、Wi‑Fi HTTP/SSE、浏览器与命令行入口，以及这些入口怎样仍然保持一份可维护的控制面真相源”。

它不等于 ESP32 firmware。ESP32 firmware 解释的是芯片侧固件职责、toolchain、刷写与运行边界；本 Topic 解释的是固件之上那层正式控制面 contract。它也不等于 Embedded USB control plane：后者只关注 USB 本地控制面，而本 Topic 明确把 ESP32-S3 的板载 USB 与 Wi‑Fi 一起视为控制面基础设施。它同样不等于 Web demo 或 Embedded admin UI；前者解释安全演示面，后者解释 UI 是否随服务一体交付，本 Topic 则解释多入口设备控制面怎样对齐同一设备语义（projects/loadlynx.md、projects/isolappurr-usb-hub.md、projects/mains-aegis.md、skills/style-playbook/references/topics/embedded-usb-control-plane/TOPIC.md）。

本 Topic 当前固定以 ESP32-S3 为定义前提，因为三份主证据都明确依赖其板载 USB 与 Wi‑Fi 能力。其他 MCU 若要复用这套模式，通常需要额外适配 USB 设备能力、局域网接入能力、host bridge 形态与资源仲裁策略；因此它们只能视为相似模式，而不是本 Topic 的默认覆盖面（projects/loadlynx.md、projects/isolappurr-usb-hub.md、projects/mains-aegis.md）。

当设备仓库同时满足以下事实时，应命中 Embedded device control plane：

• ESP32-S3 是正式维护的控制面 MCU，而不是一次性 demo 板或附属模块。
• 设备至少同时暴露两类正式入口，例如 native USB / Web Serial 与 Wi‑Fi / HTTP / SSE / mDNS，或者 CLI / devd / Web App 与可选 desktop local agent 围绕同一设备 contract 协作。
• 设备发现、连接状态、能力探测、日志/状态流、风险分层写操作或资源 ownership 已经成为维护者必须审查的长期约束，而不是零散脚本细节。

如果仓库只是在 ESP32-S3 上跑一个普通 Web server、只有单一串口调试、只有一次性 HTTP API，或者只有 flash/monitor 脚本而没有正式控制面协作约束，就不应提升为本 Topic。此时更接近 ESP32 firmware、Embedded USB control plane、MCU flashing integration 或纯项目快照知识（projects/loadlynx.md、projects/isolappurr-usb-hub.md、projects/mains-aegis.md）。

如果主要问题只是“浏览器里怎么安全演示产品”，应回到 Web demo；如果主要问题只是“UI 是否随服务一起交付”，应回到 Embedded admin UI。只有当多入口共同构成真实设备控制面，且入口之间的 ownership、发现与协议一致性会直接影响维护风险时，才命中本 Topic（skills/style-playbook/references/topics/web-demo/TOPIC.md、skills/style-playbook/references/topics/embedded-admin-ui/TOPIC.md）。

• 默认把 GUI 与 CLI 视为近似对等的正式能力面，而不是“CLI 才算真入口、GUI 只是壳”。loadlynx 的 Web 控制台、isolappurr-usb-hub 的 Web/desktop 发现与设备页面、mains-aegis 的只读运维台都说明：控制面 contract 需要先回答不同入口共享什么设备语义，而不是先给某个入口降级（projects/loadlynx.md、projects/isolappurr-usb-hub.md、projects/mains-aegis.md）。
• 默认把 Web Serial 与 native USB / daemon bridge 视为能力近似对等的本地接入路径，但仍要明确 devd 或 native USB owner 通常更可控。更可控的含义不是“唯一允许入口”，而是它更适合承载 lease、busy state、flash/reset/monitor 协调、日志缓存与 selector 归属；浏览器直连则更适合 bootstrap、恢复、无安装诊断或 owner 明确需要的直连场景（projects/isolappurr-usb-hub.md、projects/mains-aegis.md、skills/style-playbook/references/topics/embedded-usb-control-plane/TOPIC.md）。
• Web App 默认是主 GUI，但 desktop shell / local agent 应被视为可选的一等入口，而不是测试辅助脚手架。isolappurr-usb-hub 的 desktop discovery、本地 agent bootstrap 与 IP scan 候选说明，desktop/local agent 会直接改变 mDNS、PNA/CORS、Native USB ownership 与本地鉴权策略，因此这些能力必须在 Topic 中作为正式控制面变体来审查（projects/isolappurr-usb-hub.md）。
• 浏览器写权限按设备风险分层，而不是预设“Web 一定只读”或“Web 一定主控”。mains-aegis 证明高风险电源设备可以先以只读运维台落地，loadlynx 与 isolappurr-usb-hub 则说明低风险或可回滚操作可以进入 Web/GUI。更稳的默认值是：先写清读写分层、可回滚性、错误 envelope、busy/bind 状态与设备能力探测，再决定某个动作是否进入浏览器（projects/mains-aegis.md、projects/loadlynx.md、projects/isolappurr-usb-hub.md）。
• 发现、连接与状态流是正式 control-plane contract，而不是 UI 辅助功能。mDNS / DNS-SD、LAN candidate、PNA/CORS、SSE/轮询回退、device registry、mock/simulation contract、hostname 与 device_id 规则都应被视为设备控制面的一部分，因为它们直接决定用户究竟在控制哪台设备、是否能安全复现连接状态，以及不同入口能否共享同一份设备身份（projects/isolappurr-usb-hub.md、projects/loadlynx.md、projects/mains-aegis.md）。
• 对 ESP32-S3 设备控制面，默认把 USB 与 Wi‑Fi 同时当作一等基础设施来设计，而不是“有网就忽略 USB”或“有 USB 就忽略 LAN”。三份证据共同说明：本地接入口和局域网入口各自承担 bring-up、恢复、演示、日常控制、发现与诊断职责，真正的风险来自两套入口说的是不是同一种设备事实（projects/loadlynx.md、projects/isolappurr-usb-hub.md、projects/mains-aegis.md）。

• projects/loadlynx.md：最适合说明 ESP32-S3 如何把 Wi‑Fi、HTTP API、Web control、mock backend、simulation device 与 shared protocol 组织成正式控制面。它同时提醒维护者，不要把双 MCU 样本误写成默认架构；在本 Topic 里，真正可复用的是“控制面 contract 由 ESP32-S3 承担，执行面可以另有边界”，而不是“必须双 MCU”。
• projects/isolappurr-usb-hub.md：最适合说明 desktop/local agent、Native USB、mDNS、PNA/CORS、GitHub Pages 演示面与 Web UI 如何围绕同一设备控制面协作。它代表的是“控制面入口多样，但仍需要统一设备身份、发现路径与连接边界”的那一面。
• projects/mains-aegis.md：最适合说明 docs-first、SSE/device registry、风险分层 UI 与 USB 本地控制面边界如何共同定义一台高风险设备的控制面 contract。它提供了最强的“先定义控制面边界，再开放写操作”样本，也说明 Embedded device control plane 不等于“默认浏览器可写”。
• skills/style-playbook/references/topics/embedded-usb-control-plane/TOPIC.md：作为相邻 Topic，适合说明本地 USB 路径的 owner、trace、协议 framing 与 Web Serial / daemon bridge 风险；它不是本 Topic 的替代品，而是其中“本地接入口”这一层的更窄参考实现。

• 把 ESP32-S3 设备控制面泛化成“任何 MCU 控制面”，会掩盖板载 USB 与 Wi‑Fi 同时存在这一前提，后续维护者就容易把不具备同等硬件能力的芯片误套进来。
• 把本 Topic 简化成“USB + LAN 协议栈”，会把核心问题从控制面协作误降成传输层清单，结果 GUI/CLI 对等、设备发现、lease/busy、风险写路径等长期约束都丢失。
• 把 devd 的更高可控性误写成“唯一 owner”，会与 Web Serial、native USB 与 GUI/CLI 近似对等的产品事实冲突；反过来，如果完全不写 owner/lease/busy 约束，又会让多入口资源争用变成不可审计的隐性故障源（projects/isolappurr-usb-hub.md、projects/mains-aegis.md）。
• 把 desktop/local agent 当成实现细节而不是正式入口，会漏掉 PNA/CORS、LAN candidate、bootstrap token、本地鉴权与 Native USB bridge 这些只在桌面路径上才会暴露的控制面边界。
• 把 Web demo、Storybook 或 docs-site 当作控制面本身，会让演示 contract 与真实设备控制 contract 混淆。演示路径可以复用控制面，但它不自动证明写操作边界、USB ownership 或 LAN 发现逻辑已经正确。
• 只看 web/ 或 firmware/ 单侧，就宣称已经理解 Topic，也很危险。这个模式最容易出错的地方恰恰是入口之间共享什么设备事实、哪些风险动作在哪个入口暴露、断网/抢口/设备离线时各入口是否还能给出一致的状态解释（projects/loadlynx.md、projects/isolappurr-usb-hub.md、projects/mains-aegis.md）。

• projects/loadlynx.md
• projects/isolappurr-usb-hub.md
• projects/mains-aegis.md
• skills/style-playbook/references/topics/esp32-firmware/TOPIC.md
• skills/style-playbook/references/topics/embedded-usb-control-plane/TOPIC.md
• skills/style-playbook/references/topics/web-demo/TOPIC.md
• skills/style-playbook/references/topics/embedded-admin-ui/TOPIC.md
• skills/style-playbook/references/topics/mcu-flashing-integration/TOPIC.md