feat: Connect to specific board using --board-id

[Josen-B]

No description provided.

[mai-team-app]

总结

本 PR 为 ostool board connect 增加 --board-id，服务端按指定 ID 分配并报告更明确的错误，客户端在目标板卡忙时重试，同时更新了两个 crate 的版本和中英文文档。未指定 ID 的按类型分配路径以及 board run 的现有流程看起来保持不变；新增字段对旧客户端是兼容的，但客户端与服务端混合版本的契约仍有问题。

验证

• PR head 上的 GitHub Actions 有 2 个 check (stable, x86_64-unknown-linux-gnu)，均为 completed/success。
• 已运行辅助脚本的变更文件与 Rust 检查计划；本地 cargo fmt --check、两个 crate 的 clippy 和两个 crate 的测试均无法启动，实际错误为 /bin/sh: 1: cargo: not found。因此没有本地 Cargo 验证；现有 CI 未显示由本 PR 引起的失败。
• 当前 PR 没有既有 review、review comment 或 issue comment。按 board-id、specific board 和 ostool-server 检索也未发现需要合并或区分的重叠 PR。

未解决问题

新增的服务端/API 单测覆盖了指定板卡成功和不存在的情况，但没有覆盖旧服务端忽略未知 JSON 字段时的混合版本场景。请先处理内联指出的响应板卡 ID 校验问题；除此之外未发现当前改动范围内的其他阻塞问题。

Powered by gpt-5.6-luna

[mai-team-app]

总结

本 PR 为 ostool board connect 增加 --board-id，并将指定 ID 的分配、类型/不存在/占用错误、客户端占用重试和服务端分配结果校验串起来；未指定 ID 的按类型分配和 board run 路径仍传入 None，总体功能范围是局部的。

影响范围

服务器的 POST /api/v1/sessions、客户端公开 board API 以及版本契约受到影响；现有自动按类型分配流程本身没有发现行为回归。当前 head 的响应 ID 校验和尽力删除逻辑已覆盖此前 review 指出的旧服务端忽略未知字段时可能连错板卡的问题。

验证

• head 上 GitHub Actions 的两个 check (stable, x86_64-unknown-linux-gnu) 均为 completed/success，未见由本 PR 导致的 CI 失败。
• 辅助脚本 test、changed-files 和 Rust 检查计划均通过；git diff --check 通过。
• 本地 cargo fmt --check、两个 crate 的 clippy 和两个 crate 的测试均无法启动，实际错误为 /bin/sh: 1: cargo: not found，因此没有本地 Cargo 验证。
• 已阅读此前的 review/review comment：此前针对响应 board_id 校验的意见已由当前实现及回归测试处理；没有新的 issue comment。相似 PR 检索未发现重复的当前 PR；PR #67 和 #162 是历史上的远程 board/释放相关实现，不构成重叠变更。

未解决问题

1. 阻塞：公开 Rust API 发生不兼容变更。 BoardServerClient::create_session、BoardSession::acquire、board acquire/connect 函数、AppState::create_session 和 allocate_board 都增加了必填参数，公开请求结构新增字段，BoardAllocationStatus 新增枚举变体。它们位于公开模块/导出中，下游调用、结构体字面量和穷举匹配会在从 0.28.2/0.6.0 升级到本 PR 的 patch 版本 0.28.3/0.6.1 时直接编译失败。请保留旧 API 并增加带 ID 的新方法，或按 SemVer 提升破坏性版本并提供迁移说明。
2. 文档契约未同步。 基线 docs/api.md 的“创建会话”仍明确写着当前 ostool 不支持 board_id，也没有新错误和重试语义；请补充可选字段、指定分配、响应校验/清理及混合版本行为。
3. 输入规范化不一致。 服务端会 trim board_id，但客户端用未 trim 的原始 CLI 参数校验响应；详见 ostool/src/board/client.rs:288-289 的内联意见。

除上述问题和本地工具缺失外，未发现当前改动范围内的其他阻塞风险。

Powered by gpt-5.6-luna

[mai-team-app]

审查结论

阻塞：当前 PR head 的 GitHub Actions 单元测试失败。 两个 check (stable, x86_64-unknown-linux-gnu) 检查（check-runs 101948830161、101948821380）均在 Unit test 步骤以退出码 101 结束；同一 job 中的格式检查、Clippy 和 Build 已成功。请先定位并修复失败测试或其触发的实现回归，再合并。

变更范围与影响

本 PR 为 ostool board connect 增加 --board-id，让服务端按指定 ID 分配并返回更明确的错误，客户端在目标板卡忙时重试，同时更新 API 模型、两个 crate 的版本以及中英文文档。未指定 ID 的按类型分配路径和 board run 流程看起来保持不变；新增请求字段对旧客户端兼容，但客户端与服务端混合版本的指定板卡契约需要通过测试确认。

验证与历史意见

• 当前固定 head 4cba8f36cc836abda32fe385d222ba21edaa195c 的 CI 结果为上述两个失败检查；该失败发生在本次提交的 Unit test 阶段，当前提交不满足仓库的合并验证门槛。建议重新运行 cargo test --target x86_64-unknown-linux-gnu -- --nocapture 及受影响 crate 的聚焦测试。
• 本地无法执行 Cargo 验证：/bin/sh: 1: cargo: not found，因此无法在本地复现具体失败断言。
• 已复核此前两条针对 ostool/src/board/client.rs 的意见：旧服务端静默分配其他板卡的问题已由响应 board_id 校验及尽力释放会话处理；首尾空白不一致的问题已由客户端 trim() 处理。两条意见均合理，当前代码已体现修复。

除上述 CI 单元测试失败外，本次未记录其他活动代码问题；该阻塞项修复并由 CI 通过后再复审。

Powered by gpt-5.6-luna

[mai-team-app]

审查结论

本 PR 为 ostool board connect 增加可选的 --board-id：服务端按指定 ID、类型和可用状态分配开发板，客户端在目标板卡占用时重试，并校验响应中的 board_id；检测到旧服务端静默忽略字段时会尽力删除误分配的会话。未指定 ID 的自动按类型分配路径以及 board run 流程保持不变，中英文 README 和 API 文档已同步。

影响范围

主要影响 POST /api/v1/sessions 的可选请求字段、指定板卡的分配错误语义和 ostool 的公开 board 连接入口。旧 JSON 请求仍走原有自动分配路径，现有公开方法保留，整体变更范围看起来是隔离且向后兼容的。

验证

• 当前固定 head 06f0d9b87c8cbea19e3528712f17444efbeb95c6 的两个 GitHub Actions check (stable, x86_64-unknown-linux-gnu) 均 completed/success，未见由本 PR 导致的 CI 失败。
• 审查辅助脚本的测试、固定版本校验、变更文件识别和 Rust 检查计划均通过；git diff --check 通过。
• 本地按计划执行了 cargo fmt --check、两个 crate 的 Clippy 和两个 crate 的测试，但环境中没有 cargo（cargo: not found），因此本地 Cargo 验证无法完成；CI 结果提供了当前 head 的构建/测试通过证据。
• 已复核此前意见：旧服务端忽略 board_id 时的响应板卡校验与会话释放已实现并有回归测试；首尾空白规范化不一致已由客户端和服务端统一处理；此前 head 的单元测试失败已不再出现在当前 head。按 board-id、specific board 和 ostool-server 检索未发现重叠的活动 PR。

未解决问题

当前变更范围内未发现仍成立的阻塞问题、未解决的合理 review 意见或额外测试缺口；仅保留本地 Cargo 工具缺失这一环境限制。

Powered by gpt-5.6-luna