IsolaPurr USB Hub
IsolaPurr USB Hub 是带 USB-C 上行、USB-C 下行和 USB-A 下行的有源 USB 集线器/供电模块。README.md 记录 CH334P、URB2405S、CH224Q、TPS55288、SW2303/IP6557、DC5025 输入和理想二极管 OR-ing 等硬件方案,说明这是硬件/固件/Web/文档一体的 device mono-repo。
- Device mono-repo
- Embedded Rust
- TypeScript web
- React app
- Progressive web app
- Application icon
- Storybook component QA
- Playwright e2e
- Web demo
- ESP32 firmware
- Display driver
- USB PD
- MCU flashing integration
- Embedded device control plane
- Quality gates
- GitHub Actions scheduling
目录
技术栈
运行与交付
- CI 工作流
- ci.yml
- dependency-review.yml
- desktop.yml
- firmware.yml
- lint-pr-title.yml
- pages.yml
- 能力标记
- bun_lock
- cargo_toml
- github_actions
- package_json
依赖与工具
- package.json
- 开发依赖
- @commitlint/cli
- @commitlint/config-conventional
- commitlint-plugin-function-rules
- 项目脚本
- commitlint
配置与质量
- 配置文件
- .gitignore
- Cargo.toml
- lefthook.yml
- package.json
- rust-toolchain.toml
其他信息
- Cargo
- Deps main
- allocator-api2
- critical-section
- defmt
- embassy-executor
{
"cargo": {
"deps_main": [
"allocator-api2",
"critical-section",
"defmt",
"embassy-executor",
"embassy-futures",
"embassy-net",
"embassy-sync",
"embassy-time",
"embedded-graphics-core",
"embedded-hal",
"embedded-hal-async",
"esp-alloc",
"esp-backtrace",
"esp-bootloader-esp-idf",
"esp-hal",
"esp-println",
"esp-radio",
"esp-rtos",
"gc9307-async",
"heapless"
]
},
"ci_workflows": [
"ci.yml",
"dependency-review.yml",
"desktop.yml",
"firmware.yml",
"lint-pr-title.yml",
"pages.yml"
],
"configs_root": [
".gitignore",
"Cargo.toml",
"lefthook.yml",
"package.json",
"rust-toolchain.toml"
],
"markers_present": [
"bun_lock",
"cargo_toml",
"github_actions",
"package_json"
],
"package_json": {
"deps_dev": [
"@commitlint/cli",
"@commitlint/config-conventional",
"commitlint-plugin-function-rules"
],
"scripts": [
"commitlint"
]
}
}Purpose
IsolaPurr USB Hub 是带 USB-C 上行、USB-C 下行和 USB-A 下行的有源 USB 集线器/供电模块。README.md 记录 CH334P、URB2405S、CH224Q、TPS55288、SW2303/IP6557、DC5025 输入和理想二极管 OR-ing 等硬件方案,说明这是硬件/固件/Web/文档一体的 device mono-repo。
Taxonomy
- Tags: Device mono-repo, Embedded Rust, TypeScript web, React app, Progressive web app, Application icon, Storybook component QA, Playwright e2e, Web demo, ESP32 firmware, Display driver, USB PD, MCU flashing integration, Embedded device control plane, Quality gates, GitHub Actions scheduling
- Why / evidence: 这些 tags 来自 checked-out repo 和 catalog record。主要证据包括
README.md、Cargo.toml、hardware/、docs/hardware-variants.md、web/package.json、web/.storybook/main.ts、.github/workflows/firmware.yml。Topic token 的大小写以对应技术/工作流的官方写法为准;slug 只作为稳定 ID,不直接充当项目标题。
Repository map
hardware/、docs/hardware-variants.md和vendor/保存硬件资料。src/是 ESP32-S3 firmware,Cargo.toml使用esp-hal、gc9307-async、ina226等 embedded/display/current-sense 依赖。web/是 React/Vite UI,包含 PWA manifest/service worker、Storybook、Playwright e2e 和 unit tests。
Runtime and delivery
固件通过 Cargo/espflash 构建烧录;web dev 默认 45173,preview 45175,Storybook 46006,test-storybook 静态服务 46106。.github/workflows/pages.yml、web/README.md 与 docs/web-ui-interaction-spec.md 还把 GitHub Pages、PNA/CORS、Base URL、installable PWA app shell、prompt 型 service worker 更新,以及 install icon 的内容哈希版本后缀写成正式运行 contract,说明这个前端不仅是本地工具,也承担 owner-facing / public-facing 的正式演示与安装 surface。这些端口属于项目脚本默认,不代表当前 Codex 预览可直接复用。
Architecture notes
架构由电源路径和 USB data path 决定:上行供电/数据、隔离 DC/DC、下行 PD 可调输出和双电源 OR-ing 必须保持文档/固件/UI 对齐。ESP32-S3 firmware 负责显示、测量、控制或状态上报,Web UI 是开发/展示辅助面。
证据锚点:README.md。
Workflow and quality gates
.github/workflows/ci.yml、dependency-review.yml、desktop.yml、firmware.yml、pages.yml、lint-pr-title.yml 拆分 firmware/web/docs/desktop/依赖审查。根 package.json 负责 commitlint,web 子项目负责前端质量。
.github/workflows/pages.yml 同时响应 PR、merge_group 和 workflow_dispatch,却使用全局 pages concurrency group 且允许取消在途运行;PR build、merge-queue gate 和手工 backfill 不应互相抢占。这个跨事件调度风险由 GitHub Actions scheduling 记录,Quality gates 负责保留可见的交付门禁。
Reusable decisions
- 硬件 variant 写进 docs,而不是只靠 README 列表。
- 硬件 target 与操作参数应和项目文档、构建脚本及验证记录保持一致,方便多 Agent 协作。
- Web UI 端口脚本明确,但预览必须遵守全局端口租约。
- Web demo 直接复用正式 dashboard/device routes,再通过 Pages 托管与 Base URL / PNA 接入保持真实产品体验,不把演示面退化成文档页或组件画廊。
- PWA install metadata 视为 runtime contract,而不是纯视觉资源:
manifest、theme-color、favicon、apple-touch-icon、offline app shell 与更新提示都需要和真实路由、真实部署入口一起维护;install icon 变更时必须让 URL 一起变化,避免 Chrome/macOS 已安装 surface 长期复用旧缓存。 - regular 与 maskable install icon 分别生成并拥有内容版本 URL;产品 mark 的视觉几何、maskable 安全区和 Apple 派生物由
Application iconTopic 约束,PWA 运行时只消费这些明确角色的资产。
Risks and open questions
- 硬件方案存在多 variant,Topic 不能只说“USB hub”。
- PD/PPS/AVS 能力由具体芯片侧控制,不能从标签自动推断实现完整。
- Storybook component QA 不等于硬件验证。
Evidence index
README.mdCargo.tomlhardware/docs/hardware-variants.mdweb/package.jsonweb/vite.config.tsweb/src/pwa/sw.tsweb/scripts/check-pwa-assets.pyweb/public/manifest.webmanifestweb/README.mddocs/web-ui-interaction-spec.mdweb/.storybook/main.ts.github/workflows/firmware.yml.github/workflows/pages.yml.github/workflows/ci.yml
相关内容
Application icon
主题Application icon 记录的是一个产品在安装、主屏、任务栏、Dock 或浏览器应用窗口里被识别时所使用的图标 contract。它区分产品的原始 mark、给普通上下文使用的 regular any icon、可被平台裁切的 maskable icon、Apple touch icon,以及原生 app bundle 图标;它不把这些角色混成一张“看起来像应用图标”的 PNG。
Device mono-repo
主题Device mono-repo 表示一个仓库同时承载硬件资料、固件、Web/desktop UI、docs/specs、测试工具或发布流程。它强调边界协调:硬件、firmware、UI 和文档互相影响,不应把仓库当作单一应用。 这个 Topic 的核心是设备级知识不能被某一个技术栈吞掉。
Display driver
主题Display driver 表示项目围绕显示控制器驱动建立了稳定的可复用模式,通常是面向 LCD/OLED/controller 的驱动 crate,或在产品固件中把显示驱动视为独立维护边界。这里的重点不是“有屏幕”,而是显示控制器交互本身已经成为长期维护契约。 这个 Topic 关注显示控制器层,而不是更高层的 UI/graphics 语义。
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 和运行态协议协作。
Embedded Rust
主题Embedded Rust 表示 Rust 代码运行在 MCU、driver、firmware 或硬件 bring-up 环境中,通常涉及 no_std、Embassy、esp-hal、STM32/ESP32、probe-rs、espflash 或 embedded-hal。它不是所有 Rust 项目的泛化标签。
ESP32 firmware
主题ESP32 firmware 表示项目把 ESP32 家族 MCU 作为正式固件目标来维护,并围绕 toolchain、烧录、板级职责、连接能力和与其他 MCU/上位机的分工建立了稳定约定。这里的重点不是“芯片型号”,而是 ESP32 在系统里承担什么角色。 这个 Topic 往往不只是单片机源码。
GitHub Actions scheduling
主题GitHub Actions scheduling 表示仓库把 workflow 触发事件、并发 namespace、cancel-in-progress 和 required check 可见性组织成可审计的运行调度合同。目标不是让每个事件只跑一次,而是让当前 PR head 获得正确且可观察的 gate,同时不让无关 PR、main、deploy 或手工任务被同一个并发键误取消。
MCU flashing integration
主题MCU flashing integration 表示项目通过 espflash 管理 ESP32 系列,通过 probe-rs 管理 STM32/其他 probe-supported MCU,并把这些 backend 接入项目配置或明确的本地操作入口。Topic token 使用可复用工程模式命名;espflash 与 probe-rs 作为具体工具名放在定义和证据里。 这个 Topic 关注的是“硬件操作入口可复现且可审计”。
Playwright e2e
主题Playwright e2e 指仓库把真实浏览器里的关键用户流程当成正式质量门禁,而不是“顺手写了几条页面脚本”。它强调的是产品行为验证:路由、认证、交互链路、浏览器 API、嵌入式控制台或多 runtime 页面组合,必须在接近真实使用路径的浏览器环境里被证明可用(projects/blog-26.md、projects/proxy-broker.md、projects/octo-rill.
Progressive web app
主题Progressive web app 在这套 playbook 里不是“网页顺手带个 manifest”的统称,而是“把一个 Web surface 当成可安装应用去维护”的工程模式。
Quality gates
主题Quality gates 表示仓库把“什么叫可以合并、什么叫可以发布”写成了显式、可审计的契约,并通过本地脚本、CI workflows、review/signature policy、GitHub required checks 或同类机制把它执行出来。它关注的是 gate contract,而不是某一门具体技术。 这个 Topic 用来回答“仓库怎样防止低质量或不完整的改动穿过默认分支”。
React app
主题React app 标记 React 是主要用户界面、管理台、控制台或嵌入式操作面 runtime。这里关心的是 route、component tree、client state、表单流、dashboard 交互和前端构建后的真实运行边界,而不是“项目依赖里有 React”。 这个 Topic 用来回答“用户实际操作的是不是一个 React runtime,以及它在系统里承担什么职责”。
Storybook component QA
主题Storybook component QA 表示仓库把 Storybook 当作组件级文档、状态枚举、视觉检查或 interaction smoke 的稳定入口。它不等同于 Storybook accessibility:只有项目明确引入 a11y addon 或等价 Axe sweep 时,才同时打 accessibility Topic。这个拆分用于避免“只要有 Storybook 就叫 a11y”的误判。
TypeScript web
主题TypeScript web 表示项目把 TypeScript 作为一个或多个 Web surface 的主语言,并围绕它建立 workspace scripts、typecheck、bundler、lint/format、env contract 和前端构建门禁。这里的主语不是“仓库里出现了 .ts 文件”,而是 TypeScript 已经决定了维护者怎样启动、构建、校验和交付实际 Web surface。
USB PD
主题USB PD 表示仓库围绕 USB Power Delivery 协议或 PD-aware 固件/驱动维护代码,并把协商档位、controller 行为、sink/source 语义、PPS/AVS 等供电协商边界当成长期知识。这里的主语是供电协商协议,不是 generic embedded I/O。
Web demo
主题Web demo 表示仓库刻意提供一个可直接给 owner、评审者或潜在用户体验的 Web 演示面,而且这个演示面复用正式产品前端与正式路由,而不是单独做一套只用于截图的 demo 页面。它允许用 mock backend、simulation device、read-only seed data 或等价安全输入来稳定复现产品行为,但默认不要求接入真实生产登录、真实后端写路径或真实硬件危险写操作。