chore: release

[github-actions]

🤖 New release

• httpboot-protocol: 0.4.0 -> 0.4.1 (✓ API compatible changes)
• ostool: 0.30.1 -> 0.30.2 (✓ API compatible changes)

Changelog

httpboot-protocol

0.4.1 - 2026-09-30

Other

• release (#199)

ostool

0.30.2 - 2026-09-30

Fixed

• (ostool) drop inherited initrd addresses from FIT device trees (#201)

---

This PR was generated with release-plz.

[mai-team-app]

审查结论：APPROVE（release-plz 自动发布 PR，无阻塞问题）

本 PR 做了什么

仅修改 3 个文件（+8/-2），全部是版本发布产物，没有任何 Rust 源码变更：

• httpboot-protocol/Cargo.toml：0.4.0 → 0.4.1
• Cargo.lock：httpboot-protocol 包版本同步为 0.4.1
• httpboot-protocol/CHANGELOG.md：新增 ## [0.4.1] ... - 2026-09-29 段落，内容为 ### Other - release ([#199])

一致性核对（人工，均已通过）

1. 版本三处一致：httpboot-protocol/Cargo.toml = 0.4.1，Cargo.lock 第 1638-1643 行 name = "httpboot-protocol" / version = "0.4.1"，无遗留 0.4.0 记录。
2. 依赖约束兼容：workspace Cargo.toml 中 httpboot-protocol = { version = "0.4", path = "./httpboot-protocol" }，ostool/ostool-server 通过 workspace = true 引用；0.4.1 满足 ^0.4，因此无需改动其他 manifest，发布不会破坏 workspace 解析或 cargo publish --workspace --dry-run --locked。
3. CHANGELOG 链接与结构正确：compare 链接为 httpboot-protocol-v0.4.0...httpboot-protocol-v0.4.1，仓库地址正确；## [Unreleased] 之后插入新段落的写法与 base 中既有条目（如 0.2.1、0.4.0）完全一致。

影响面

• 与 base 对比 httpboot-protocol/src 无任何差异，公开 API、序列化格式、协议常量均未变化，属于「仅版本号」变更，影响面是隔离的。
• 仓库内没有其他硬编码该 crate 版本的位置（docs/axloader-network-control.md 中提到的 httpboot-protocol 0.3.0 指外部 TGOS 已发布依赖，不是本仓库 crate 版本）。
• 无法运行的行为回归风险不存在：本 PR 不触碰串口/TFTP/QEMU/U-Boot/电源等操作敏感路径。

CI 与本地验证

• 远端：head 322b28d464c46aa312c75a3630995df631b97a1c 的 check runs 查询返回 total_count: 0，即当前没有可引用的 CI 结果；mergeable_state: "unstable" 不作为通过依据。未发现由本 PR 引起的失败检查。
• 本地：该审查环境未安装 Rust 工具链（rustc、cargo 均不存在），因此 cargo fmt --all -- --check、cargo clippy --manifest-path httpboot-protocol/Cargo.toml --all-features -- -D warnings、cargo test --manifest-path httpboot-protocol/Cargo.toml --all-features 均未能运行；按 AGENTS.md 要求记录缺失工具与未执行的检查。由于变更仅涉及版本字符串、CHANGELOG 与 lock 版本，编译/格式/测试结果不受影响，故以人工一致性核对替代。

历史评审意见

• PR reviews 与 comments 均为空，没有需要跟踪的既有意见。
• 仓库搜索 repo:drivercraft/ostool type:pr is:open release 仅命中本 PR，无重复的发布 PR。

剩余风险与非阻塞观察项（不影响合并）

1. 0.4.1 的 changelog 只有「release (#199)」一条，说明该 patch 版本相对 0.4.0 没有任何功能性变更，会向 crates.io 发布一个与 0.4.0 代码完全相同的版本。这是 release-plz 默认 commit 分类的既有行为（仓库已有先例：0.2.1 = ### Other - release (#180)），不是本 PR 引入的缺陷，也不构成阻塞；若维护者希望减少此类补丁发布，可另开变更添加 release-plz.toml 或忽略 chore 提交。
2. docs/axloader-network-control.md:183 仍写着「TGOS 当前依赖已发布 httpboot-protocol 0.3.0」，与当前版本（base 的 0.4.0、本 PR 的 0.4.1）不一致。该行在 base 快照中即已存在，是 #198 升版时未同步的既有文档陈旧问题，本 PR 无需处理，建议后续文档整理时一并更新。

以上两项均为说明性备注，已确认不改变 APPROVE 结论；本 PR 未提交行内评论。

Powered by deepseek-flash

[mai-team-app]

审查结论：APPROVE（release-plz 自动发布 PR，无阻塞问题）

本 PR 做了什么

仅 5 个文件、+16/-4，全部是发布产物，没有任何 Rust 源码变更：

• httpboot-protocol/Cargo.toml：0.4.0 → 0.4.1
• ostool/Cargo.toml：0.30.1 → 0.30.2
• Cargo.lock：同步两个包的版本行
• httpboot-protocol/CHANGELOG.md、ostool/CHANGELOG.md：各新增一个版本段落

与上一轮评审（head 322b28d，job 24771fe8）相比，head 已在 #201 合并后重建，因此本版本额外包含 ostool 0.30.2。

版本与一致性核对（人工，均已通过）

1. 版本三处一致：各 manifest 与 Cargo.lock 对应包版本匹配（httpboot-protocol 0.4.1 @ Cargo.lock:1691-1692，ostool 0.30.2 @ Cargo.lock:2762-2763）；grep 0.4.0/0.30.1 只命中 CHANGELOG 中用于 compare 链接的历史文本，无残留旧版本记录。
2. 依赖约束兼容：workspace Cargo.toml:26 为 httpboot-protocol = { version = "0.4", path = "./httpboot-protocol" }，0.4.1 满足 ^0.4，无需改动；ostool/ostool-server 通过 workspace = true 引用。仓库内没有其它 manifest 硬编码 ostool 或 httpboot-protocol 版本，ostool-server 也不依赖 ostool crate。
3. 版本幅度与变更内容匹配：相对 tag ostool-v0.30.1，ostool/src/boot/fit.rs 有 113 行变更（#201 的修复），patch bump 到 0.30.2 正确；changelog 归类为 ### Fixed 与 #201 一致，compare 链接 ostool-v0.30.1...ostool-v0.30.2 与既有 tag 命名一致。
4. 未漏发其它 crate：逐个对比 manifest 版本与最新 tag —— fitimage 0.1.7 = fitimage-v0.1.7、jkconfig 0.2.5 = jkconfig-v0.2.5、uboot-shell 0.2.8 = uboot-shell-v0.2.8、ostool-server 0.8.1 = ostool-server-v0.8.1，且这些目录在其 tag 之后没有代码变更，无需出现在本 PR。
5. 本 PR 基于当前 main 顶端（base == origin/main == 2983bdfc），已包含 #201。

影响面

仅版本号、CHANGELOG 与 lock 版本行变更，公开 API、serde 结构、协议常量均无变化，不触碰串口、TFTP、QEMU、U-Boot、电源等操作敏感路径，影响面是隔离的。合并后会触发 ostool-v0.30.2、httpboot-protocol-v0.4.1 的 tag/GitHub release 创建与 crates.io 发布；ostool/Cargo.toml 的 binstall 元数据 { repo }/releases/download/{ name }-v{ version } 与 release-plz 的 tag 命名约定一致。

CI 与本地验证

• 远端：head 8c1f584 的 check-runs 为 total_count: 0，combined status 为 pending 且 0 个 status（这也是 mergeable_state: unstable 的原因），因此没有可引用的 CI 结论，也不存在由本 PR 引起的失败检查。
• 本地：本审查环境没有 Rust 工具链（cargo、rustc、rustup 均不存在），cargo fmt --all -- --check、cargo clippy --target x86_64-unknown-linux-gnu --all-features -- -D warnings、cargo test 以及 CI 的 cargo publish --workspace --dry-run --locked 均未能运行；按 AGENTS.md 要求记录缺失工具与未执行的检查。由于改动只涉及版本字符串、CHANGELOG 与 lock 中的版本行，编译/格式/测试结果不受影响，故以人工一致性核对替代。

历史评审与重复 PR

• 已有 1 条评审：mai-team-app[bot] 在 head 322b28d 给出 APPROVED（job 24771fe8），其「仅版本变更、无阻塞」的结论在技术上合理，但针对的是旧 head，不能替代本次对 8c1f584（含 ostool 0.30.2）的复审。PR 无 issue 评论。
• 仓库搜索 repo:drivercraft/ostool type:pr is:open release 仅命中本 PR，无重复或冲突的发布 PR。

剩余风险与非阻塞观察项

1. 行内评论：httpboot-protocol 0.4.1 是「空发布」，会把与 0.4.0 完全相同的代码再发布一次。属 release-plz 既有行为（先例 0.2.1 = release (#180)），不阻塞。
2. 备注（既有问题，非本 PR 引入）：docs/axloader-network-control.md:183 仍写「TGOS 当前依赖已发布 httpboot-protocol 0.3.0」，与当前 0.4.x 不一致。该行在 base 快照中即已存在，本 PR 未触碰该文件，建议后续文档整理时一并更正。
3. 两个 crate 的真实发布结果只能在合并后由 release workflow 验证（本地无 Rust 工具链无法复现 cargo publish --workspace --dry-run --locked）。

以上均为说明性备注，未发现阻塞问题，故 APPROVE。

Powered by deepseek-flash

[mai-team-app]

httpboot-protocol 的 0.4.1 是一个空发布：自 tag httpboot-protocol-v0.4.0（b8065a5）以来，httpboot-protocol/ 下只有 CHANGELOG.md 与 Cargo.toml 发生变化，src/ 无任何差异（git diff --stat httpboot-protocol-v0.4.0 HEAD -- httpboot-protocol/），0.4.1 段落的唯一条目也是上一轮 release PR 自身（release (#199)）。也就是说这次会把与 0.4.0 完全相同的代码再发布为 0.4.1，下游只会看到一个无内容变化的补丁版本。

这与仓库既有先例一致（0.2.1 = ### Other - release (#180)），属 release-plz 按提交分类的既有行为，不是本 PR 引入的缺陷，因此不阻塞合并。若维护者希望减少此类补丁发布，建议另开独立变更引入 release-plz.toml（例如忽略仅修改 CHANGELOG 的 chore: release 提交），而不是在本 PR 中调整发布逻辑。