DevFlow/docs/05-代码审查/定时走查-2026-06-15-第5轮.md

定时代码走查 — 第 5 轮（2026-06-15）

触发：定时走查 cron（每 30 分钟）。范围 = api 层垂直切片（9 文件，此前从未深查，IPC 契约边界）。无新提交（自第4轮起 src/ 干净）。 方法：2 路后台代理（A：api invoke 契约层 / B：types 类型对齐层）+ 主代理地面核对 + WebSearch 权威裁决。 性质：核对记录，不改产品代码（本会话 session-role-diagnose-only）。todo 待修项见 docs/todo.md。 关联：第1-4轮。

---

🚨 核心发现：Tauri v2 camelCase 行为权威裁决（代理矛盾 → 纠正假阳性）

矛盾

• 代理 A：Tauri v2 不转 camelCase，6 处 IPC 参数遗漏（ai_approve/ai_save_provider/knowledge_events/ai_set_concurrency_config/ai_set_provider/ai_pending_tool_calls）真 P0（B-34 同类）
• 代理 B：Tauri v2 默认转 camelCase（宏生成别名），6 处全误判

权威裁决（WebSearch Tauri v2 官方文档 + StackOverflow）

Tauri v2 默认自动转换 snake_case（Rust）↔ camelCase（JavaScript）。 Rust #[tauri::command] fn greet(tool_call_id: String) ↔ JS invoke('greet', { toolCallId }) 自动匹配。 除非 #[tauri::command(rename_all = "snake_case")] 才需 JS 传 snake_case。

项目地面核对：grep rename_all src-tauri/ 仅 state.rs:30（KnowledgeConfig 的 serde，非 command 参数），无任何 #[tauri::command] 用 rename_all → 全部走默认（camelCase 转换）。

结论

代理 B 对，代理 A 6 处全误判（假阳性）：

• api/ai.ts:15 { toolCallId } → 后端 tool_call_id ✅ 自动转换，工作
• api/ai.ts:20 { convId } / :47-54 { providerType/baseUrl/apiKey/defaultModel } / :59/64 { providerId } / :69 { globalLimit/perConvLimit } → 全 ✅
• api/knowledge.ts:80 { knowledgeId/eventType } → ✅

camelCase 和 snake_case 都工作（项目混用：ai.ts 用 camelCase，workflow.ts 用 snake_case，均正常）。

---

🔑 根因：B-34 错误注释传播误导

src/stores/project.ts:273 B-34 注释「Tauri 2 IPC 不转 camelCase,须 snake_case 对齐后端 workflow.rs:211」与权威矛盾（实际转）。

• 代理 A 据此错误注释判 6 处假阳性 P0（认为 camelCase 失效）
• B-34 实际「修复」（selectType→select_type）是 no-op：camelCase 本工作，snake_case 也工作，两种都接受。改了无害，但注释错误传播误导
• 若「多选审批静默失效」曾为真症状，根因非 selectType 命名，需复核（camelCase 转换正常）

本轮最高价值：揭露 B-34 技术债（错误注释），避免后续维护者/走查代理据此做无用「修复」（代理 A 已踩坑）。

---

代理 B 发现（types 对齐）— 良好，4 项低风险

字段名/可选/枚举/响应包装全对齐（无 P0 undefined 风险）：7 Record struct（Idea/Project/Task/Workflow/AiProvider/Knowledge/KnowledgeEvent）字段名全 snake_case 对齐，Option↔可选对齐，AiChatEvent/WorkflowEvent union 变体对齐。

4 项低风险（CR-260615-22）：

1. TaskRecord.status（types.ts:88）注释 review_ready/merged/abandoned 错，后端 TaskStatus（types.rs:165）= todo/in_progress/in_review/testing/done/blocked/cancelled
2. IdeaRecord.status（:11）注释漏 archived（IdeaStatus 6 变体）
3. ProjectRecord.status（:39）注释漏 testing/releasing（ProjectStatus 7 变体）
4. AiConversationSummary.models（:233）冗余（后端返但前端无消费点）

status 字段类型是 string（非 literal union），注释不阻断运行时，仅误导维护者。

---

✅ 亮点

• api/types.ts 类型对齐质量高：7 Record struct + union 类型全对齐，无字段漂移
• IPC 命令名零漂移（代理 A 核 60+ 命令注册）：无拼写错/未注册/已删残留
• 越层下沉治理：store 不直碰 invoke（workflow.ts:7-8 注释），api 是唯一 IPC 边界
• workflow.ts 契约自觉：虽「不转 camelCase」判断有误，但 snake_case 风格统一 + options 透传注释（R-PD-5）是好的防回归实践

---

📊 本轮摘要

类别	数	代表
权威裁决	1	Tauri v2 默认转 camelCase（代理 B 对）
假阳性纠正	6	代理 A IPC camelCase 遗漏全误判
根因澄清	1	B-34 错误注释传播误导（CR-23）
低风险新发现	4	types 枚举注释错/漏 + 冗余字段（CR-22）

本轮价值：多代理交叉验证暴露矛盾 → WebSearch 权威裁决 → 纠正 6 处假阳性（避免后续基于错误注释的无用修复）+ 揭露 B-34 注释技术债。

方法论：

1. 走查须以权威行为为准（官方文档/实际运行），非代码注释 — 注释可能错误（如 B-34），代理 A 据错误注释判 6 处假阳性
2. 多代理交叉验证有效 — 代理 A/B 结论矛盾触发权威裁决，单代理走查无此纠错机制
3. api 层垂直切片证实类型对齐质量高（与前几轮横切互补）

todo 映射：不记代理 A 6 处（假阳性）+ CR-260615-22（types 注释/冗余 P3）+ CR-260615-23（B-34 注释修正 P2）。

---

Sources

• Calling Rust from the Frontend | Tauri v2
• Why does Tauri modify the parameter names of invoked functions? — Stack Overflow
• Tauri Command Fundamentals — Tauri Tutorials