FUSB302 Rust PHY Driver

fusb302 是面向 FUSB302B/FUSB302BMPX 的 no_std Rust USB Type-C 和 USB Power Delivery BMC PHY driver。它提供寄存器级控制、Type-C 电气控制、VBUS comparator、interrupt/FIFO 和 PD packet transport；README.md 明确把 PD policy、contract negotiation 和电源管理决策留给上层应用。这个项目是 library crate，不是 Rust application，也不负责完整 USB-PD 协议栈。

• Tags: embedded-hal driver, I2C, Rust crate release

• src/ 包含 driver、error、registers 和 types；tests/driver.rs 覆盖 host-side driver 行为。
• Cargo.toml 定义 crate 名 fusb302、版本 0.2.2、Rust 1.85 MSRV、MIT/Apache-2.0 license、embedded-hal 依赖和 async/defmt features；发布包排除 .github 与 docs。
• scripts/ 中的 check_release_contract.py、release_surfaces.py、registry_state.py、wait_for_registry.py 和 release_receipt.py 负责 release unit 的检查、公开面协调、registry 查询和回执。
• .github/workflows/ci.yml、release-verify.yml、release.yml、label-gate.yml 与 notify-release-failure.yml 分别承载 CI、发布后校验、发布、PR intent 和失败通知；它们的编排仍由相邻 Topic 负责。

默认构建使用同步 embedded_hal::i2c::I2c，启用 async 后切换到 embedded_hal_async，defmt 只为公开状态和错误类型增加格式化支持。库本身不需要操作系统或 heap；验证应覆盖 cargo test、all-features docs 和 feature combinations，而不是把 host test 当成硬件行为证明。

发布 workflow 从确定的 source SHA checkout，先用 cargo metadata 校对 manifest version，再运行 cargo package --locked 和新版本的 cargo publish --locked --dry-run。发布后通过 crates.io 查询确认版本可见；GitHub 侧使用 release/<version> tag 和同 tag Release。首发 0.1.0 是 owner 手工 bootstrap，后续 0.2.0、0.2.1 已使用 Trusted Publisher/OIDC；当前 0.2.2 的 crate、tag 和 Release 均已公开。

当前 release/0.2.2 tag 解析到 source SHA 0130089a79fac4ac8f6c7000324fbe1b493340cd，GitHub Release 为正式、非 draft、非 prerelease 状态；该 SHA 是 recovery receipt 用来重建公开面的固定锚点。

driver 把 I2C bus 能力交给 embedded-hal trait，自己只拥有 FUSB302 PHY 的寄存器和数据路径。HostCurrent、VbusThreshold、PdPacket 等 typed API 表达硬件语义，但 PD policy、协商时序、重试和 power-path 决策属于调用方。async 是 compile-time API 选择，不是运行时调度器；Extended Message reassembly 也留在协议层。

Rust CI 的 fmt、clippy、test、docs、msrv、package jobs 是当前仓库的质量证据；label-gate.yml 和 .github/quality-gates.json 是 PR/合并编排证据，应由 PR label release 与 Quality gates 解释。notify-release-failure.yml 只负责失败上下文和通知，应由 Release failure notification 解释。

release.yml 的发布相关事实是：先检查 registry version 是否存在，再准备和校验 release/<version> tag/Release，只有不存在的版本才走 rust-lang/crates-io-auth-action@v1 与 cargo publish。Trusted Publisher 不能用于 crate 的第一个版本，所以 0.1.0 由 owner 使用最小权限、短生命周期 token 完成一次 bootstrap；确认 registry 可见后撤销 token，再配置 crates.io Trusted Publisher 并做 OIDC smoke check。0.2.2 曾遇到 GitHub Release 列表的短暂可见性缺陷，修复为按精确 tag 查询并做 bounded retry；这是该版本的 recovery 证据，不是默认发布策略。

• 把 crate version、不可变 release/<version> tag 和同 tag GitHub Release 绑定到同一个 source SHA，作为可验证的 release unit。
• 首发只允许 owner 从已验证、干净的源码提交用最小权限短期 token 发布一次；registry 可见后立即撤销，再迁移到 Trusted Publisher/OIDC。后续版本不保留 token fallback。
• 每次发布前检查 manifest、package 内容和 dry-run，发布后确认 crates.io registry 可见；已有版本不得再次 cargo publish。
• SemVer 必须能被 Cargo 接受并与 Cargo.toml 一致；允许 prerelease，但 crates.io 版本、Git tag 和 GitHub Release 必须共享同一 prerelease 语义，不能引入 label/channel 编排。
• recovery 先查询 crate、tag 和 Release 的现状，只补齐缺失公开面；发现同版本绑定到不同 source SHA 或已有 crate 版本时必须停止，不以重发解决冲突。

• crates.io 已发布版本不可覆盖或删除；yank 只改变可解析状态，不能成为重新发布同一版本的理由。cargo package 的 VCS 信息只是 best effort，不能替代 source SHA、tag 和 registry 三面校验。
• GitHub Release 的短暂不可见性只在 0.2.2 recovery 中被观察到；精确 tag 查询和有限重试属于项目脚本的局部修复，不应升格为所有仓库的固定等待时长。
• cargo test 和 docs 构建主要是 host-side 证据；FUSB302 实机的 electrical、USB-PD interoperability 和 BMPX 兼容性仍需板级验证记录。

• README.md
• Cargo.toml
• src/
• tests/
• scripts/check_release_contract.py
• scripts/release_surfaces.py
• scripts/registry_state.py
• scripts/wait_for_registry.py
• scripts/release_receipt.py
• .github/workflows/ci.yml
• .github/workflows/release.yml
• .github/workflows/release-verify.yml
• .github/workflows/label-gate.yml
• .github/workflows/notify-release-failure.yml
• https://github.com/IvanLi-CN/fusb302-rs/releases/tag/release/0.2.2
• https://crates.io/crates/fusb302/0.2.2
• https://doc.rust-lang.org/cargo/reference/publishing.html
• https://blog.rust-lang.org/2025/07/11/crates-io-development-update-2025-07/