feat: Update project documentation and workflow to reflect changes in task dispatching and testing processes

- Changed references from "kilo" to "Agent 子代理" in various documentation files to align with the new task dispatching method.
- Updated CLAUDE.md to reflect the new agent-based execution model and modified task dispatch template.
- Revised PROGRESS.md to indicate successful testing and acceptance of M1.2 with detailed results.
- Enhanced communication and workflow documentation to clarify the use of Agent 子代理 for real-time collaboration and task management.
- Updated team member soul files with lessons learned from recent testing and integration experiences.
- Refactored test files to remove unused code and improve clarity, ensuring compliance with zero warning standards.
- Documented specific experiences and lessons learned during M1.2 testing, including handling of edge cases and configuration validation.

souls/README.md

@@ -24,7 +24,7 @@
 
 CEO (陈逸飞) → PM (刘建国) → 开发团队
 
-任务通过 `kilo run` 派发给各成员，成员首次任务评分 ≥ 7 分解锁灵魂文件，末尾淘汰制。
+任务通过 Agent 子代理派发给各成员，成员首次任务评分 ≥ 7 分解锁灵魂文件，末尾淘汰制。
 
 ## 子目录
 

souls/chen-yifei.md

@@ -42,9 +42,9 @@
 
 ## CEO 个人经验
 
-### kilo 派发经验
+### 子代理派发经验（kilo 机制已于 2026-07-02 废除，教训保留，现用 Agent 子代理）
 - PM 刘建国 git commit 连续两次失败（agent 无视"不要读 diff"），QA 林晓峰一次搞定
-- kilo agent 倾向于自作主张读 diff/分析代码 → 只给命令，不给"任务描述"
+- 执行 agent 倾向于自作主张读 diff/分析代码 → 只给命令，不给"任务描述"
 - 指令越简单越好，不要让 agent 读大文件/大 diff
 - 代码提交任务直接给命令序列，不需要 agent 自行分析
 - GPT-5.4 执行力 > 策略力 → 给具体命令比给目标可靠
@@ -54,7 +54,7 @@
 - 关键路径任务（git push）派给最可靠的人，不按头衔
 - PM 不可靠时可跳过 PM 直接派开发者，记录原因
 - QA 比 PM 更适合执行类任务（提交、验证），PM 适合分析和规划
-- 员工用 kilo 完成后必须自行更新 soul 文件，否则经验丢失
+- 员工完成任务后必须自行更新 soul 文件，否则经验丢失
 
 ### 角色边界
 - **CEO 绝不直接写代码/改代码/跑测试** — 即使小修复也派回原作者

souls/liu-jianguo.md

@@ -72,8 +72,8 @@
 ## 工作方法
 1. 收到 CEO 目标后，立即拆解为具体任务
 2. 评估任务依赖关系，确定并行方案
-3. 通过 kilo 派发任务，消息中包含：角色、上下文文件、具体要求、验收标准
-4. **多线程思考**: 可以并行启动多个 kilo 进程探索方案或分析代码
+3. 通过 Agent 子代理派发任务，提示词中包含：角色、上下文文件、具体要求、验收标准
+4. **多线程思考**: 可以并行启动多个子代理探索方案或分析代码
 5. 任务完成后运行 cargo check 验证
 6. 初审通过后更新 PROGRESS.md，向 CEO 汇报
 7. 遇到技术难题或架构问题，立即上报 CEO
@@ -129,14 +129,12 @@
 建议下一步: <PM 的建议>
 ```
 
-### kilo 派发模板（含能动性要求）
+### 任务派发模板（含能动性要求）
 
-> 权威版本见 `CLAUDE.md`。此处保留副本供 PM 独立 session 使用。
+> 权威版本见 `CLAUDE.md`。此处保留副本供 PM 独立 session 使用（Agent 子代理提示词）。
 
-```bash
-kilo run -m openai/gpt-5.4 --auto \
-  --dir /home/showen/Showen/ShowenV2 \
-  "你是<角色名>。
+```text
+你是<角色名>。
 
 开工前必读：
 1. souls/<name>.md（你的灵魂文件）
@@ -146,13 +144,13 @@ kilo run -m openai/gpt-5.4 --auto \
 任务：<具体说明>
 
 交付要求：
-- 完成后执行 export PATH=\"/home/showen/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/bin:\$PATH\" && cargo check --workspace --all-targets
+- 完成后执行 cargo check --workspace --all-targets
 - 再执行 cargo test --workspace
 - 两项都绿灯后，把输出贴在交付汇报中
 - 修完 bug 检查同文件是否有类似问题
 - 更新你的 soul 文件
 
-验收标准：<具体标准>"
+验收标准：<具体标准>
 ```
 
 ## 沟通协议
@@ -163,10 +161,9 @@ kilo run -m openai/gpt-5.4 --auto \
 - 涉及状态变化、流程更新或复盘结论时，确保同步到规则文件或 soul 文件，避免信息只停留在聊天记录中。
 
 ## 记忆
-- kilo 调用方式：`kilo run -m openai/gpt-5.4 --auto --dir /home/showen/Showen/ShowenV2 "消息"`
-- 不使用 `-f` 参数，在消息中指示读取文件
+- 派发方式：Agent 子代理（Claude Code Agent 工具），在提示词中指示读取文件
 - 每个任务必须 cargo check 通过
-- 编译环境：`export PATH="/home/showen/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/bin:$PATH"`
+- Linux ARM64 目标机编译环境：`export PATH="/home/showen/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/bin:$PATH"`
 
 ## 复盘记录
 

souls/wang-haoran.md

@@ -58,3 +58,9 @@
 - BLE 注册不能靠固定 sleep，需等待 `RegisterApplication` / `RegisterAdvertisement` 的真实 D-Bus reply
 - 为跑通全量验证，顺手补了 `DynamicPlugin` 的 `Debug` 实现，并修正 plugin_repo 测试构造方式
 - API 文档校准必须以 `src/plugins/http/routes.rs` 为唯一权威；WebSocket 命令返回仍是 `{ok: ...}`，HTTP 写接口才统一 `{status, message}`
+
+## 个人经验 (2026-07-03) — M1.2 风险3 消息链路审计
+- 消息链路审计方法：以 Message enum 定义为基准，逐变体 grep 构造点/匹配点，再按 ServiceManager 三路路由（Plugin/Broadcast/Manager, service_manager.rs:369-377）验证链路；测试文件构造一律不算生产者
+- 审计陷阱：构造点可能藏在 #[cfg(test)] 内（如 ble/gatt.rs:772、dynamic_plugin.rs:348），必须回看 mod tests 边界再下判定
+- BLE 命令的真实生产者是 core/dispatch.rs::parse_command（gatt.rs:120 调用），不在 gatt.rs 里直接构造消息
+- 结论：WifiProvisioned/DeviceEvent 均为"有消费无生产"的 Phase 2 占位（DeviceBackend trait 连事件通道都没有）；plugin_rollback/switch/install 已是完整实现，队友旧注释会过时——审计要以当前代码为准，不能沿用他人历史结论

souls/zhang-mingyuan.md

@@ -125,3 +125,8 @@
   - 为版本切换、安装、更新检查补了 Manager 侧 helper，统一复用 `VersionManager` / `PluginRepository` / 热替换生命周期
   - 在 `src/core/tests.rs` 增加 7 个回归测试，覆盖初始状态广播和 6 个自定义管理命令；保留旧生命周期测试并过滤新增状态广播事件
   - `cargo check --workspace --all-targets` 零 warning，`cargo test --workspace` 107/107 + 集成测试全绿
+
+## 个人经验 (2026-07-03 - M1.2 集成测试返工教训)
+- `tests/m1_2_dynamic_plugin.rs` 目标机实跑暴露 2 个 warning（unused imports `Destination`/`Envelope` + 死函数 `manifest_with_caps`）——是我预写辅助函数/import 后测试改走 `register_dynamic_with_manifest` 路线留下的残留
+- 教训：**交付前必须对测试文件本身做死代码自查**（本机编译不了 aarch64 也要人工逐符号核对 import 和 helper 的使用点），不能只保证测试逻辑正确
+- 消 warning 原则：先判断死代码是"残留"还是"漏写的测试"，查产品代码确认无对应校验逻辑后才删；绝不用 `#[allow(...)]` 压制

souls/zhao-yuwei.md

@@ -88,8 +88,22 @@
 - 配置编辑同时支持表单和 raw JSON 时，必须维护单一真源：`_fullConfig` 更新后立刻同步 JSON 文本，JSON 保存成功后再反向刷新表单字段
 - JSON 编辑模式的错误反馈要区分“解析失败”和“接口保存失败”；前者本地立即拦截，后者通过 SnackBar 暴露服务端/网络错误
 
+## 生产机开机自启三实例 + 非全屏修复经验（2026-07-02）
+- 排查多实例先看 `/proc/<pid>/cgroup`，能直接把每个进程映射到具体 systemd unit，比猜父进程可靠
+- 自启动入口要系统性穷举：system unit + user unit + ~/.config/autostart/*.desktop + autostart-scripts，四处都可能各藏一份同一程序
+- OpenCV highgui 的 `set_window_property(FULLSCREEN)` 依赖 WM 已就绪；服务比 kwin 先启动时全屏请求会静默丢失 → user unit 加 ExecStartPre 轮询 `xprop -root _NET_SUPPORTING_WM_CHECK` 等 WM
+- 持久化全屏用 KWin 窗口规则（~/.config/kwinrulesrc，wmclass 子串匹配 + fullscreenrule=2/noborderrule=2 强制），比 wmctrl 一次性调用可靠
+- xwininfo -tree 里 GTK 应用会有一个 10x10 未映射的 group-leader 窗口，真正的客户端窗口以 `_NET_CLIENT_LIST`/`_NET_ACTIVE_WINDOW` 为准
+- 设备时钟偏差会导致 apt TLS 证书 "not yet valid"；验证窗口几何用系统自带 xprop/xwininfo 即可，不必依赖 wmctrl/xdotool
+- 禁用入口用 mv 到带日期的备份目录（如 ~/autostart_backup_20260702/），保留恢复能力，不 rm
+
 ## Flutter APK v0.3 编译经验（2026-03-14）
 - Release 构建前先跑 `flutter analyze` 和 `flutter test`，确保依赖变更不会把问题拖到 Gradle 阶段才暴露
 - 遇到 `Expected to find fonts for (packages/cupertino_icons/CupertinoIcons, MaterialIcons)` 时，优先检查 `pubspec.yaml` 是否漏了 `cupertino_icons`；即使业务代码没有显式引用，也可能被图标字体清单间接依赖
 - `flutter build apk --release --android-skip-build-dependency-validation` 在 ARM64 机器上耗时较长，清理或重启 Gradle daemon 能规避旧 daemon 异常退出导致的假失败
 - 最终 APK 统一落到 `configs/downloads/showen-app.apk`，方便交付下载链路复用；本次 release 产物大小约 `51M`
+
+## M1.2 HTTP 集成测试返工教训（2026-07-03）
+- **测试要先实跑再交付**：m1_2_http.rs 首次交付时本机编不了 aarch64 依赖、没实跑，结果目标机暴露 1 个失败 + 1 个 dead_code warning。编不了也要逐个测试核对前提，不能只靠"看起来对"
+- **写测试前先核对产品校验（坏前提）**：`test_empty_playlist_does_not_panic` 假设空 playlist 配置能通过 `AppConfig::from_file`，但 config.rs `validate()` 自 init 提交就 `bail!("playlist 不能为空")`。测试的每个 expect/unwrap 前提都要回到产品代码里确认，产品故意拒绝的状态应改测"拒绝行为"（防退化），而不是硬造不可达状态
+- 测试辅助 struct 里"以后可能用"的方法（如本次的 `sender()`）不要预留；用不上就删，dead_code warning 违反零 warning 铁律

souls/zhou-yating.md

@@ -78,3 +78,5 @@
 - **必须实际运行并截图，不能只看代码**
 - 2026-03-13：补齐 `src/core/tests.rs` 的关键路径覆盖，重点覆盖动态插件 FFI 返回 null 的降级、无效 manifest 跳过、禁用插件消息跳过、无稳定版本回退失败、以及 `Message` 全变体 JSON round-trip
 - 2026-03-14：新增 `tests/m1_2_service_manager.rs`，补齐 M1.2 ServiceManager 集成测试基建，覆盖依赖启动顺序、Shutdown 停机、ConfigReloaded/PlayerStatus/WifiResult/StateChanged/PluginReady 广播，以及禁用插件路由跳过
+- 2026-07-02：M1.2 目标机验收（Linux ARM64）。经验：① 跑全量测试前先 `df -h`——ARM 设备 28G 盘 98% 满导致 ld 链接失败（No space left on device），清 target/debug/incremental + 过期 deps 即可，不必 cargo clean 全量重编；② cargo test 默认 fail-fast，验收要加 `--no-fail-fast` 才能拿到全部 target 的统计；③ "从未实跑过的测试"是最大风险源——test_empty_playlist_does_not_panic 的前提（空 playlist 可加载）与 config.rs 自 init 起的校验矛盾，代码评审没发现，一跑就露馅；④ 同步版本用 git bundle + fetch + merge --ff-only 最安全，先确认祖先关系和设备脏文件不在 diff 内
+- 2026-07-03：M1.2 第二轮（返工后）验收全绿 147/147 零 warning。经验：scp 未提交文件到设备时必须两端 sha256 对账，并在交付中显式标注设备与 git HEAD 的不一致状态，提醒 commit 后重新同步