Skip to content

[Product][#689-P8] Codex app-server carrier 产品投影：Feishu notice/status/goal 后置设计 #698

Open
Open
[Product][#689-P8] Codex app-server carrier 产品投影：Feishu notice/status/goal 后置设计#698
Labels
area:codexCodex protocol translation and wrapper integrationarea:daemonDaemon server, admin API, and runtime controlarea:feishuFeishu/Lark integration, gateway, projector, or previewenhancementNew feature or requeststatus:needs-planTechnical investigation is sufficient, but the staged plan is not yet execution-ready

Description

@kxn
kxn
opened on Jul 12, 2026

父 issue

背景

#689 的核心原则是：底层协议 carrier 先行，产品展示分阶段承接。P1-P7 会补齐 notice、model adjunct、delta suppression、thread state、capability/account/MCP status、server request policy、headless opt-out 等底层能力。

这些能力不应该在还没有 carrier 和频控策略前直接变成 Feishu 卡片。本单作为后置产品投影规划单，等底层结果稳定后再决定哪些值得展示、怎样展示、展示频率和降级策略。

目标

  • 基于 P1-P7 的真实 carrier 结果，设计 Feishu 侧最小有价值投影。
  • 明确哪些只留在状态/诊断页，哪些进入 chat 主链，哪些永不产品化。
  • 对所有可能触及卡片 patch / streaming 的方案写出频控预算和降级路径。

范围

按本单 建议范围 执行；范围边界以 非目标 和 完成标准 为准，不向相邻 P 项扩展。

非目标

  • 不在 P1-P7 完成前实现产品展示。
  • 不做 typewriter / live token UI。
  • 不把所有 state-only carrier 都默认发成 Feishu 消息。
  • 不绕过 Feishu card constraints。

完成标准

  • P1-P7 结果已回卷并可作为产品输入。
  • 每个候选展示面都有明确分类：
    • chat 主链
    • status/diagnostic page
    • on-demand command
    • hidden/internal only
    • not supported
  • 对 Feishu 卡片/消息更新方案给出：
    • size budget
    • update cadence
    • overflow/degradation path
    • callback/interaction constraints
  • 如触及 Feishu card state machine，已运行对应 guardrail 并同步 docs。
  • 输出可执行子 issue，而不是在本产品规划单里一次实现全部。

依赖

建议范围

本单只做 P1-P7 之后的产品投影规划与继续拆分：决定哪些 carrier 进入 Feishu chat、status/diagnostic、on-demand command、hidden/internal 或 not-supported。P1-P7 已稳定；当前按 B 收窄版推进，先拆出 P0/P1 主动短 notice，status/diagnostic 展示后置。

相关文档

涉及文件

  • 后续具体产品子 issue 决定
  • 预计涉及 internal/adapter/feishu/**、internal/core/orchestrator/**、docs/general/**

信息索引

实现参考

后续产品候选方向：

  1. [Work][#698-P1] Feishu 主链 P0/P1 app-server notice 主动短推送 #701 最小主动 notice：只展示 P0/P1 白名单状态，包括 guardianWarning、严重 configWarning、MCP startup failed/reauth、可定位 surface 的登录/OAuth 失败。
  2. 后续 status/diagnostic page：展示 MCP startup status、skills invalidation、account/rate limits、model verification/safety buffering latest state。
  3. Thread goal/settings：先做只读状态，不急于聊天主链交互。
  4. MCP OAuth：优先承接 [Follow-up] MCP OAuth login lifecycle：mcpServer/oauth/login -> oauthLogin/completed #670 的 dedicated lifecycle，而不是从 P5 passive event 推断；[Work][#698-P1] Feishu 主链 P0/P1 app-server notice 主动短推送 #701 只处理无 pending flow 且可定位 surface 的失败短 notice。
  5. Realtime/audio/live output：默认不产品化，除非另有明确产品需求和频控预算。

检查参考

  • 必查 docs/general/feishu-card-api-constraints.md。
  • 若新增/改卡片 payload，运行 feishu-ui-state-machine-guardrail。
  • 若影响 remote routing/selection，运行 remote-state-machine-guardrail。
  • 对具体子 issue 再设定 targeted Go tests。

收尾参考

执行决策

拆分结构

单元 类型 状态 依赖 闭包等级 下一步 备注
#701 P0/P1 主动短 notice 执行子 issue status:implementable-now #691、#695、#697、#698 决议 执行闭包 可以 prepare 后开工 只做白名单主动短 notice，不做 status center
P2 status/diagnostic 投影 后续待拆 未创建 #701 可先行 计划待补 #701 后再拆或另行拍板 展示 MCP/account/model/thread latest state；需要产品展示面设计

推荐顺序

  1. [Work][#698-P1] Feishu 主链 P0/P1 app-server notice 主动短推送 #701：先落 P0/P1 主动短 notice，覆盖会影响后续可用性的风险提示。
  2. P2 status/diagnostic 投影：等 [Work][#698-P1] Feishu 主链 P0/P1 app-server notice 主动短推送 #701 完成或实现中确认共享基础后，再决定是否拆出 Feishu /status、/debug 或 admin/status page 子单。
  3. P3 hidden/native-only：仅写回结论，不主动创建执行单，除非后续有明确产品需求。

可并行组

当前风险

总调度表

单元 类型 当前状态 依赖 可并行组 当前闭包等级 下一步建议 备注 结果回卷 verifier 状态 当前结论
#698 母 issue status:needs-plan #691-#697 - 计划闭包 调度 #701，等待回卷后决定 P2 是否拆单 本单不直接编码 未完成 parent close 前需要 调度中心
#701 P0/P1 主动短 notice 子 issue close-out #691、#695、#697、#698 决议 A 执行闭包 等待 commit/push/finish close 已实现白名单 append-only 短 notice 已完成并待关闭 pass 第一阶段完成
P2 status/diagnostic 投影 后续待拆 未创建 #701 可先行 B 计划待补 #701 后再判断展示面 /status、/debug、admin/status page 三种形态需另行计划 未开始 待定 后置

当前开工判断

当前执行点

恢复步骤

  1. 读取 [Product][#689-P8] Codex app-server carrier 产品投影：Feishu notice/status/goal 后置设计 #698 的 总调度表 和 当前执行点。
  2. 完成 [Work][#698-P1] Feishu 主链 P0/P1 app-server notice 主动短推送 #701 close-out。
  3. 再判断是否拆 P2 status/diagnostic 子单。

产品待拍板

  • 触发原因：P1-P7 已把 notice、model adjunct、thread lifecycle/goal/settings、capability/account/app/MCP status 等底层 state-only carrier 补齐；继续推进 [Product][#689-P8] Codex app-server carrier 产品投影：Feishu notice/status/goal 后置设计 #698 必须决定哪些状态进入 Feishu 用户可见层。
  • 当前约束：飞书卡片/消息有 30 KB、200 elements、单消息 patch 5 QPS、同用户/群发送 5 QPS、回调 3 秒等硬约束；仓库原则是不做 typewriter，不把 state-only carrier 默认刷成聊天消息。
  • 用户当前倾向：B。原因是 guardianWarning 这类消息如果用户不处理，后续可能影响使用；但主动推送必须是白名单式、低频、可去重，不应把 state-only carrier 默认刷成聊天消息。
  • 备选方案 A：第一阶段只做按需 status/diagnostic 投影。
    • 内容：在 /status 或后续 /debug/诊断页里展示 latest notice、MCP startup status、account/rate limit、model verification/safety buffering、thread goal/settings 摘要。
    • 主链策略：不新增主动聊天推送；guardianWarning / severe configWarning 也先只进入诊断页，避免打扰和误报。
    • 影响：最稳、频控风险最低、实现边界清楚；但用户不会被主动提醒，需要主动查看。
  • 备选方案 B：最小主动 notice + 诊断页。
    • 内容：除 A 外，把 guardianWarning 和严重 configWarning 作为短 notice 主动发到当前 surface；其它状态仍只进诊断页。
    • 影响：安全/配置问题更可见，但需要定义“严重”判定、去重/节流、目标 surface 选择和旧卡/多群策略，容易变成产品噪音。
  • 备选方案 C：做完整状态中心/连接器页。
  • 推荐方案：B 的收窄版，只推 P0/P1，P2/P3 不主动推送。理由是这能覆盖会影响后续可用性的风险，同时仍然遵守飞书频控和“非流式、不刷屏”的产品原则。
  • 建议主动推送分级：
    • P0 必须主动推送：guardianWarning。这是安全/策略/守护类警告，不处理可能导致后续任务失败、被阻断或产生用户无法理解的行为变化。默认首条必推；按 surface + instance + thread + normalized summary 去重；同 key 10 分钟冷却；长 details 只进诊断页。
    • P0 条件主动推送：严重 configWarning。当前 carrier 没有可靠 severity，因此第一阶段建议只在能明确判断会影响运行时推送，例如 summary/details/path 命中 invalid、failed、error、permission、auth、denied、missing、unreadable、parse 等运行失败语义，或带 path/range 且和当前实例配置加载相关。默认同 key 30 分钟冷却；无法判严重时只进诊断页。
    • P1 建议主动推送：mcpServer/startupStatus/updated 的 failed 或 reauthenticationRequired。尤其 reauthenticationRequired 需要用户重新授权，不应只藏在状态页。默认按 server + failureReason + surface 30 分钟冷却；恢复成功可选推一条“已恢复”，并重置失败冷却。
    • P1 条件主动推送：account/login/completed 或 mcpServer/oauthLogin/completed 的失败结果。若有用户刚触发的 pending flow，应走该 flow 的既有完成/失败提示；无 pending flow 时只在能定位 affected surface 时推一条短 notice，否则只进诊断页，避免广播到无关群。
    • P2 只进 /status / 诊断页：普通 warning、deprecationNotice、非严重 configWarning、skills/changed、app/list/updated、account/updated、普通 account/rateLimits/updated、model/verification、model/safetyBuffering/updated、thread/goal/updated、thread/settings/updated。这些状态有排查价值，但不要求用户立即处理。
    • P3 不产品化或隐藏：delta / realtime / audio / live output、typewriter 类中间态、native-only/pass-through-only remote control/window 状态。它们要么高频，要么不适合飞书消息面，不应消耗推送预算。
  • 推送形态建议：第一阶段只 append 一条短 notice，不 patch 工作中卡，不做 live card；每条控制在一张短卡或纯文本 notice 内；details、历史和聚合视图进入 /status / 诊断页。
  • 目标 surface 规则：只推给当前 attached/affected surface；无法可靠定位 affected surface 时只记录诊断，不主动发群消息。
  • 决策结果：已确认按上述 B 收窄版作为 [Product][#689-P8] Codex app-server carrier 产品投影：Feishu notice/status/goal 后置设计 #698 第一阶段边界，并已拆出 [Work][#698-P1] Feishu 主链 P0/P1 app-server notice 主动短推送 #701。
  • 受影响单元：[Product][#689-P8] Codex app-server carrier 产品投影：Feishu notice/status/goal 后置设计 #698 后续拆分、[Track] Codex app-server 协议支持追平：底层 carrier 先行，产品展示分阶段承接 #689 parent close 视图、可能的 /status / /debug / admin/status page 子 issue；[Follow-up] MCP OAuth login lifecycle：mcpServer/oauth/login -> oauthLogin/completed #670 仍独立负责主动 MCP OAuth lifecycle。

执行快照

子 issue 回卷：#701

  • 结果：P0/P1 主动短 notice 已完成并通过 verifier。
  • 交付物：orchestrator 层 active notice projection gate；guardianWarning、严重 configWarning、MCP startup failed/reauth、passive MCP OAuth failure、account login failure 的短 notice 投影；运行期 cooldown 和 surface fail-closed。
  • 明确未做：未实现 status/diagnostic 页面；未做 typewriter/live delta；未 patch 工作中卡；未改 Feishu callback 或 old-card 状态机。
  • 验证：go test ./internal/core/orchestrator -run 'TestProtocolNotice|TestCapabilityState'、go test ./internal/core/orchestrator、go test ./internal/adapter/codex ./internal/app/wrapper、go test ./internal/adapter/feishu ./internal/app/daemon ./internal/core/control ./internal/core/orchestrator、git diff --check、bash scripts/check/go-file-length.sh。
  • verifier：pass；verifier 发现的 MCP startup cooldown key / recovery reset 缺口已修复并补测试。

close gate 回卷：#701

子 issue #701 已完成并关闭，结果回卷如下：

  • 结果：P0/P1 主动短 notice 已完成并通过 verifier。
  • 交付物：orchestrator 层 active notice projection gate；guardianWarning、严重 configWarning、MCP startup failed/reauth、passive MCP OAuth failure、account login failure 的短 notice 投影；运行期 cooldown 和 surface fail-closed。
  • 明确未做：未实现 status/diagnostic 页面；未做 typewriter/live delta；未 patch 工作中卡；未改 Feishu callback 或 old-card 状态机。
  • 验证：go test ./internal/core/orchestrator -run 'TestProtocolNotice|TestCapabilityState'、go test ./internal/core/orchestrator、go test ./internal/adapter/codex ./internal/app/wrapper、go test ./internal/adapter/feishu ./internal/app/daemon ./internal/core/control ./internal/core/orchestrator、git diff --check、bash scripts/check/go-file-length.sh。
  • 独立 verifier 结果：pass；verifier 发现的 MCP startup cooldown key / recovery reset 缺口已修复并补测试。

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:codexCodex protocol translation and wrapper integrationarea:daemonDaemon server, admin API, and runtime controlarea:feishuFeishu/Lark integration, gateway, projector, or previewenhancementNew feature or requeststatus:needs-planTechnical investigation is sufficient, but the staged plan is not yet execution-ready

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions