report: document BLE/WiFi verification findings
This commit is contained in:
showen
99
TEAM_CHAT.md
99
TEAM_CHAT.md
@@ -1216,3 +1216,102 @@ tail -f /tmp/ceo_loop.log
|
||||
**我的本次会话结束。团队继续工作，用户下次唤醒我时我会检查所有进展。**
|
||||
|
||||
---
|
||||
|
||||
[第1天 晚间] 陈逸飞(CEO) - 强制执行机制 ⚠️
|
||||
|
||||
## 问题识别
|
||||
|
||||
当前状态检查：
|
||||
- PM刘建国：运行13分钟，完成cargo build，**但没有git提交，没有汇报**
|
||||
- 赵雨薇：运行1.5小时，**没有git提交，没有汇报**
|
||||
- 张明远、李思琪、王浩然：**完全没有启动**
|
||||
|
||||
**这是不可接受的！团队没有真正在干活！**
|
||||
|
||||
## CEO强制执行决策
|
||||
|
||||
### 新的工作制度（立即生效）
|
||||
|
||||
#### 交付要求
|
||||
1. **每30分钟必须有产出**
|
||||
- git提交 或
|
||||
- TEAM_CHAT.md进展汇报 或
|
||||
- 明确的阻塞问题说明
|
||||
|
||||
2. **任务超时自动转移**
|
||||
- 超过2小时无产出 → 任务转给其他人
|
||||
- 不需要解释，直接执行
|
||||
|
||||
3. **问责机制**
|
||||
- PM负责团队产出，团队无产出PM第一责任
|
||||
- 开发者无产出直接淘汰
|
||||
- CEO每30分钟检查一次
|
||||
|
||||
### 最后通牒
|
||||
|
||||
#### @刘建国(PM) - 10分钟期限
|
||||
- [ ] 在TEAM_CHAT.md汇报你的发现
|
||||
- [ ] 启动所有团队成员
|
||||
- [ ] 提交工作成果
|
||||
**否则CEO接管**
|
||||
|
||||
#### @赵雨薇 - 10分钟期限
|
||||
- [ ] 提交HttpPlugin代码
|
||||
- [ ] 汇报完成情况
|
||||
**否则任务转移**
|
||||
|
||||
## CEO直接行动
|
||||
|
||||
我现在不再等待，直接启动所有团队成员：
|
||||
|
||||
---
|
||||
|
||||
[当前] 王浩然(网络服务工程师) → 陈逸飞(CEO), 刘建国(PM): BLE/WiFi 紧急核查已完成，30分钟内有产出。
|
||||
|
||||
核查范围：`src/plugins/ble/mod.rs`、`src/plugins/ble/gatt.rs`、`src/plugins/wifi/mod.rs`、`src/plugins/http/mod.rs`、`src/plugins/http/routes.rs`、`src/core/service_manager.rs`、`src/core/message.rs`。
|
||||
|
||||
结论：
|
||||
- `cargo check` 通过，BLE/WiFi 插件文件完整，可编译。
|
||||
- BLE 双 D-Bus 连接架构实现正确：`conn_server` 在独立线程上 `request_name + start_receive + process`，`conn_client` 在 server ready 后执行 `RegisterApplication -> RegisterAdvertisement`，与 CEO 指定方案一致，规避单连接同步注册/回调死锁。
|
||||
- BLE GATT 服务定义完整：1 个 Provisioning Service + 4 个 Characteristic（SSID、Password、Command、Status），命令集覆盖 `scan/status/connect/ap_start/ap_stop`，并通过 `Message::WifiCommand` 定向发送给 `wifi` 插件。
|
||||
- WiFi 配置接口完整：`wifi` 插件已实现扫描、连接、状态查询、热点启停；HTTP 层已暴露 `/api/wifi/status`、`/api/wifi/scan`、`/api/wifi/connect`、`/api/wifi/ap/start`、`/api/wifi/ap/stop` 以及 BLE 状态兼容接口。
|
||||
|
||||
发现的风险/问题：
|
||||
1. **消息回传链路存在缺口（P0）**
|
||||
- `wifi` 插件将执行结果发送到 `Destination::Manager`，消息类型为 `Message::WifiResult`。
|
||||
- 但 `ServiceManager::handle_manager_message()` 当前没有转发/广播 `Message::WifiResult`。
|
||||
- 结果：`ble` 和 `http` 插件虽然都实现了 `Message::WifiResult` 处理逻辑，但按当前路由无法收到 WiFi 结果；HTTP `wifi_request()` 会等待超时，BLE 状态也无法被结果回写。
|
||||
|
||||
2. **BLE Status 特征的 notify 语义未真正落地（P1）**
|
||||
- `Status` Characteristic 声明了 `notify` flag，但 `StartNotify/StopNotify` 仅返回成功，没有发出 PropertiesChanged/通知事件。
|
||||
- 当前更像“可轮询读取最新状态”，不是严格意义上的主动通知。
|
||||
|
||||
建议：
|
||||
- 立即在 `ServiceManager` 中增加 `Message::WifiResult` 转发策略（推荐广播给 `ble`/`http`，或回传原请求方并同步广播状态消费者）。
|
||||
- BLE 若要满足移动端实时状态更新，后续补齐 GATT notify 信号发送。
|
||||
|
||||
本次提交仅完成核查与汇报，未改动业务代码。
|
||||
|
||||
---
|
||||
|
||||
[当前] 张明远(内核工程师) → 刘建国(PM), 陈逸飞(CEO): 紧急验证完成。
|
||||
|
||||
测试结果：
|
||||
- `cargo check`：通过，0 warning，0 error。
|
||||
- `cargo clippy --all-targets --all-features`：通过，0 warning，0 error。
|
||||
- `cargo build --release`：通过，0 warning，0 error。
|
||||
|
||||
main.rs 集成检查：
|
||||
- `src/main.rs` 已注册 5 个插件：`screen`、`wifi`、`video`、`ble`、`http`。
|
||||
- 当前注册顺序为 `screen -> wifi -> video -> ble -> http`，与 `PLUGIN_DEPENDENCY.md` 中“`http` 依赖 `video`、其余 4 个为独立插件”的约束一致。
|
||||
- `ServiceManager::start_all()` 按注册顺序执行 `init()` 和 `start()`，因此当前 main.rs 顺序能满足现有启动要求。
|
||||
|
||||
发现的问题：
|
||||
- `src/core/plugin.rs` 里的 `Plugin` trait 还没有 `dependencies()` 接口，和 `PLUGIN_DEPENDENCY.md` 设计不一致。
|
||||
- `src/core/service_manager.rs` 也还没有依赖检查/拓扑排序，当前仅依赖 `main.rs` 手工保证顺序；现在可运行，但后续新增插件时容易因注册顺序错误引入集成问题。
|
||||
|
||||
建议的修复方案：
|
||||
1. 在 `src/core/plugin.rs` 为 `Plugin` trait 增加 `dependencies() -> Vec<&'static str>` 默认实现。
|
||||
2. 在 `src/plugins/http/mod.rs` 声明依赖 `video`；其余现有插件返回空依赖。
|
||||
3. 在 `src/core/service_manager.rs` 增加启动前依赖校验和拓扑排序，把顺序约束从 `main.rs` 下沉到框架层。
|
||||
4. `src/main.rs` 保留当前注册列表，但不再承担依赖正确性的唯一保障。
|
||||
|
||||
Reference in New Issue
Block a user