维护者确认：飞书 /project 切换频道

[MagicLizi]

这次改动把飞书侧 /project 接到频道切换，用户在飞书里发这条命令会换到对应项目频道。

请维护者确认：

• /project 作为切换频道入口是否符合 IM 产品口径
• 群聊 / 话题车道守卫是否足够，避免跨群误切

确认方式：直接在 PR 上 Approve；需要修改就 Request Changes，作者改完后再 Approve 即放行。

---

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

[dash-s-cindy]

判断：飞书 /project 具备明确用户价值，建议继续推进；产品行为应沿用现有 Telegram 语义，在当前飞书会话 lane 内切换项目并重开上下文，而不是修改 bot 级默认目录或迁移旧上下文。PR #3708 的接线方向正确，但在当前依赖状态下还不宜直接批准合并。

已确认的产品与实现事实

• 共享 /project 能力已经存在于 IM 共享层，入口要求渠道声明 projectSwitching、提供富卡输出以及 ui.cards.project 文案；当前 main 的飞书 adapter 尚未开启该能力，也尚未提供项目卡文案，因此现状是“飞书入口未接线”，不是共享切换逻辑不存在。
• handleProjectSwitch() 的既有语义是：从 Desktop 工作区项目清单选择目录，重新检查目标是有效目录，更新当前会话行的 workingDir 与 workspaceKind='project'，清空 sdkSessionId、预览和旧运行态，再释放 live session；模型、effort、provider、权限等路由设置保留。切回“对话”则使用渠道托管目录并写入 workspaceKind='dialogue'。这与硬切、上下文不跨目录迁移的语义一致。
• 飞书 session ID 由 botAppId + userId 构成；群和话题分别使用 g/{chatId}、g/{chatId}/{threadId} lane。因此按当前 lane 切换，能保持一个话题一个独立 session 的边界。已合入的 PR feat(feishu): 群主流 @ 自动开话题 — 每话题独立 session, 回复不再刷屏群主流 #2621 已确立群主流 @ 自动开话题、每话题上下文互不串的产品模型。
• 项目列表复用 listProjectsForControl() / buildProjectPickerCard()，不是聊天侧自由输入任意路径；回调还会重新检查目录存在且为目录。这是比自由路径入口更合适的安全和可用性边界。
• /project 与 /ctr 的职责不同：前者切换飞书自有 lane，会重开该 lane 上下文；后者接管 Desktop session。现有代码在接管期间拒绝 /project，避免 binding 目标与飞书自有 session 分叉。控制命令仍受 owner-only 入口约束，访客不会因此获得项目切换能力。

群聊/话题车道守卫

PR #3708 针对一个真实且可复现的错误路径补上了保护：飞书群卡片回调在应用重启、重新绑定或 lane 缓存丢失后，可能只剩操作者的 open_id。若继续按该身份处理，会把项目切换错误落到操作者私聊，而不是原群/话题。PR 在 cardActionHandler.ts 的项目切换路径加入与既有 /ctr 相同的 isGroupCardWithLostLane fail-closed 判断，并增加了群卡 lane 丢失、正常话题 lane、DM 卡片三类回归测试。对当前已识别的跨群/跨 lane 误切风险，这个守卫方向正确；PR 的自动化 IM 测试和 Desktop typecheck 已通过。

但 PR 尚未完成真实飞书 E2E，仍应在合并前或合并后测试群验证：私聊、群主流、两个独立话题分别切项目；应用重启后点击旧群/话题卡；重复点击、失效目录、/ctr 接管期间点击旧 /project 卡。这里是发布验证缺口，不足以单独否定实现方向。

当前阻塞：默认工作目录与项目归属冲突

PR #2624 仍处于 open、未合入状态。它为飞书/Lark 增加 owner 级默认工作目录，并规定已有会话保留旧目录、显式 /new 使用新默认目录。这会改变现有 sessionRepo.ts 的一个关键假设：启用 /project 的渠道目前把“工作目录不是 ensureWorkingDir() 返回的托管目录”推断为项目。

一旦飞书允许用户把默认对话目录改成自定义路径，以下情况会产生归属歧义：

1. project:dialogue 切回自定义默认目录后，按路径比较可能被读成 workspaceKind='project'；
2. 应用重启、会话复活或 upsert 时，路径推断可能覆盖用户显式选择的归属；
3. 默认目录变更可能影响新会话，但不应静默移动或重分类已有项目会话。

因此，#3708 不能只依赖“打开 projectSwitching + 补卡片文案”就直接发布。应先让 #2624 与 /project 收敛到明确归属契约，优先采用显式持久化并尊重 workspaceKind：项目选择写 project，切回渠道对话写 dialogue；复活、重启和默认目录变化不得改写显式项目归属；旧版托管目录迁移只能处理 legacy managed path。

建议行动

1. 对 PR feat(im): wire Feishu /project channel switching #3708 暂不 Approve，提出 Request Changes 或保持产品确认门关闭，明确要求与 feat(desktop): support Feishu bot working directories #2624 的目录归属契约对齐。
2. 先合入/收敛 feat(desktop): support Feishu bot working directories #2624 的最终行为；随后更新 feat(im): wire Feishu /project channel switching #3708，使项目卡片和 cardActionHandler 消费显式 workspaceKind，不要在飞书 adapter 里复制路径推断逻辑。
3. 将 feat(im): wire Feishu /project channel switching #3708 rebase 到最新 main，复跑 apps/desktop/src/main/im 定向测试、Desktop typecheck、DCO，以及项目切换与 feat(desktop): support Feishu bot working directories #2624 的组合回归。
4. 在测试飞书 bot 上补私聊、群、双话题、重启旧卡、失效目录、重复点击和 /ctr 互斥的 Live E2E；通过后再在 PR feat(im): wire Feishu /project channel switching #3708 上 Approve。

相关记录

• #3704：直接讨论飞书 /project；后续讨论已确认硬切语义、lane 级作用域和 Desktop 项目清单复用，并确认 feat(desktop): support Feishu bot working directories #2624 是前置依赖。
• #2624：飞书/Lark 默认工作目录配置，尚未合入；它会直接影响 /project 的 dialogue/project 归属判断。
• #2621：已合入的飞书群主流自动开话题实现，确立每个话题独立 session、上下文互不串，是 lane 级项目切换的直接产品依据。