维护者确认: PR #1983 将飞书/企业微信通知迁移至 IM 机器人设置页

[MagicLizi]

背景

PR #1983 将飞书通知和企业微信群通知从原有位置迁移到 IM 机器人设置页，并新增了飞书任务完成通知开关。

需要维护者确认的点

• 通知设置的新归属位置（IM 机器人页）是否符合产品信息架构预期
• 新增的「飞书任务完成通知」开关的默认行为和触发条件是否合理
• 原有通知区块的精简是否会影响用户查找习惯

确认方式

维护者直接在 PR 上 Approve 即放行；如需修改请 Request Changes，作者改完后重新 Approve 即可。

---

关联 PR:#1983(作者 @Shinku-Chen);本 issue 由 review-pr 流程自动创建,用于先讨论该 PR 涉及的产品 / UI 变更,维护者确认后 PR 会恢复推进。

[dash-s-cindy]

判断

把渠道专属配置集中到「设置 → IM 机器人」各渠道卡片，能让机器人凭据、连接状态和对应通知能力在同一处管理，方向合理；但当前版本建议先修改再 Approve。

进一步检查发现，这次并没有新增一条飞书通知能力或改变底层触发逻辑。「飞书任务完成通知」是现有通用通知页开关的迁移和重新命名：继续复用原有 notifications.feishuEnabled 偏好，默认关闭，存量用户的值会保留。企业微信群通知也继续复用既有 webhook、总开关和调度发送服务。

当前需要先解决一个明确的交互回归，并补足迁移场景验证。

行动

建议对 #1983 先 Request Changes，完成以下两项后再 Approve：

1. 恢复飞书 Owner 未绑定时的真实禁用状态。

   • 当前 main 的 NotificationSection.tsx 在没有 ownerOpenId 时给飞书 Switch 传入 disabled={!feishuReady}。
   • PR 将开关迁到 FeishuBotNotificationSection.tsx 后，复用了 ImLifecycleAnnouncementSection，但该组件没有 disabled 参数。
   • 现在未绑定时只是在 onCheckedChange 内不写入值，控件仍表现为可操作；点击没有结果，也没有正确的 disabled 无障碍语义。
   • 建议给共享组件增加可选 disabled，由该飞书开关传入 !feishuReady，同时补一条聚焦组件测试。

2. 补一次 Electron 实机验收和迁移路径测试。 至少覆盖：

   • 升级前 notifications.feishuEnabled=true/false 在新位置正确展示，开关值不会被迁移丢失；
   • 已保存凭据但尚未绑定 Owner 时，开关明确禁用并展示对应提示；
   • 绑定后可以切换，解绑后仍自动复位为关闭；
   • 普通任务的完成、失败、待回复在窗口失焦时遵循该开关；
   • 定时任务的飞书单任务勾选不受这个普通任务开关影响；
   • 企微群通知继续要求“群通知总开关开启”且“该定时任务勾选企微群通知”；
   • 定时任务里的企微配置链接能定位到「IM 机器人 → 个人」中的企业微信卡片；
   • Light/Dark 下飞书和企微展开区块没有层级、分隔线或溢出问题。

已确认的行为边界

飞书普通任务通知

现有实现位于：

• apps/desktop/src/renderer/hooks/useFeishuNotificationSettings.ts
• apps/desktop/src/renderer/features/cc-agent/CCAgentSidebarUpper.tsx
• apps/desktop/src/main/notificationService.ts

其行为是：

• 偏好键仍为 notifications.feishuEnabled；
• 缺少存储值时默认 false；
• 只有已绑定的飞书/Lark Bot Owner 才能实际发送；
• 普通任务在窗口失焦时，对 done、error、needs-reply 三种事件发送通知；
• 解绑 Bot 会把该偏好复位为关闭；
• PR 没有修改上述底层链路，只是把 UI 从 NotificationSection 搬到 FeishuBotNotificationSection。

因此，公开文案最好把它描述为“迁移现有任务状态通知开关”，而不是新增通知能力。新文案使用“任务完成通知”作为区块标题可以接受，但 hint 应继续明确它还覆盖“执行失败”和“需要回复”，并且只在窗口失焦时发送，避免标题缩窄用户对触发条件的理解。

飞书定时任务通知

定时任务仍由：

• ScheduleFormDialog.tsx 中的 notifyFeishu 单任务选项；
• apps/desktop/src/main/scheduler-host/notifier.ts 中的 schedule.notify.feishu；

独立控制。它不读取 notifications.feishuEnabled，所以与本次迁移的普通任务开关不是总开关/子开关关系。PR 保持这一现状，没有改变已有用户行为。

企业微信群通知

现有实现位于：

• apps/desktop/src/main/wecomGroupNotification.ts
• apps/desktop/src/renderer/hooks/useWecomGroupNotificationSettings.ts
• apps/desktop/src/main/scheduler-host/notifier.ts

行为保持为：

• webhook 和总开关保存在 owner-scoped 安全存储中；
• 新保存并测试成功的 webhook 会启用总开关；
• 已有 webhook 在缺少历史总开关字段时继续按启用处理；
• 实际调度发送同时要求 schedule.notify.wecomGroup 和群通知服务处于启用状态；
• 普通个人任务不会发送到共享企微群。

PR 只把这组配置移入 WecomBotSection.tsx，并把定时任务中的配置入口从 /settings?tab=general&section=notifications 改到 /settings?tab=im-bot&imGroup=personal，底层行为没有变化。

企业微信群 webhook 与企业微信智能机器人凭据在技术上仍是两条独立能力；即使智能机器人没有连接，群 webhook 也可以配置。建议在实机验收时确认卡片内的布局和文案不会让用户误以为必须先连接企业微信智能机器人。

可发现性与迁移风险

PR 合并后，「通用 → 通知」只剩桌面通知，原来在这里管理飞书和企微的存量用户需要重新寻找入口。定时任务内的企微配置链接已经同步更新，降低了企微使用路径上的风险；飞书普通任务通知则没有等价的迁移入口。

是否在通用通知区保留一版轻量提示，例如“飞书和企业微信群通知已移至 IM 机器人设置”，属于产品决策。目前没有仓库记录证明这是必须项，因此不建议把它作为既定需求强加给本 PR；但维护者应在 Approve 前明确是否接受直接移除旧入口的可发现性变化。

相关记录

• feat(wecom): 新增企业微信 IM 与群通知 #1107：引入企业微信 IM 与群通知，并明确企微群通知只面向定时任务，采用“设置页总开关 + 单任务开关”的双层控制。本 PR 应保持该既有语义，当前底层实现也确实未改变。
• feat(discord): 增加上下线通知设置 #1770：已合并的 Discord 生命周期通知设置位于「IM 机器人 → 个人 → Discord」卡片，说明渠道专属通知设置归入对应 IM 卡片已有产品先例；它支持本次信息架构方向，但不消除上述飞书 disabled 回归和迁移验证要求。

[MagicLizi]

维护者确认已通过,讨论结束,PR 恢复正常推进。关联 PR:#1983(https://github.com/makecindy/cindy/pull/1983)。本 issue 由 review-pr 流程自动关闭。