rc-69f36007-0ec9 2026.04.30 31 KB

MER-229 · Idea 裂变与 Session 路由 — 阶段方案

原始 research campaign 输出，来自 meridian runtime architecture research。这页保留报告结构和运行痕迹，正式文章会在写作区重写。

MER-229 · Idea 裂变与 Session 路由 — 阶段方案

Campaign: rc-69f36007-0ec9 · meridian-runtime-architecture-research Topic: t01 — 结合当前 Vyane / Yi daemon、Claude Code session、Discord 入口，设计个人优先的 idea capture / session routing / 任务分发机制。写作时间：2026-04-30

0. 一句话结论

MER-229 不需要新建一条调度链路；现有的 Yi (CC CLI Opus) + Vyane daemon (EventBus / SessionManager / LogicalSession / ResearchCampaign) + Linear GraphQL + agent inbox 协议已经够拼出一个可以渐进交付的 idea pipeline。近期最有价值的一步是：定一个 idea-inbox.jsonl schema + 几个 Yi slash command，把"捕获"先零开发跑起来；自动检测、自动 spawn、Linear promote 都放到 daemon 稳定之后再做。

1. 任务理解

1.1 MER-229 issue 现状

字段	值
Identifier	MER-229
Title	core: Idea 裂变与 Session 路由 — 对话中分支自动捕获和分发
Priority	1 (Urgent)
State	Backlog
Project	（未挂）
Updated	2026-04-09
Comment	前置调研报告：`docs/research/autonomous-2026-04-09/backlog-prep.md`

Issue 描述的核心痛点：

Maple 的思维模式是一个点同时裂变出多个关联 idea（Ne 主导），但当前缺乏机制在对话中自动捕获这些分支并路由到合适的地方。

聊着聊着分出子话题，要么当场展开（主线被打断），要么手动开新 session（摩擦大）

想法没及时记录就被新信息冲掉

手动在终端开 tab、复述上下文很烦

期望的三步动作：捕获 → 分类 → 路由，分短中长三层目标。

1.2 这次调研要回答什么

围绕"如何在不破坏当前节奏的前提下落地 MER-229"，我需要：

把可复用的现有组件盘清楚（不要重造轮子）；
给出阶段性方案，区分"现在能做"和"等 daemon 稳定再做"；
标出风险和明显不该走的方向。

不在范围内：完整代码实现、UI 草稿、详细 schema 字段微调。

2. Evidence — 调研依据

2.1 当前 Vyane daemon 已有的能力

模块	行	直接相关的能力
`vyane/src/vyane/daemon/main.py`	675	`VyaneDaemon`、`spawn_claude` / `spawn_codex`、Yi 启动、Webhook 启动、EventBus + EventStore wiring、scheduler gate
`webhook.py`	802	Linear webhook 接收 + 任务队列 + asyncio.Lock 防 race + signing 验证；`Ready` 状态自动触发；已读 `LINEAR_API_KEY`
`session_manager.py`	244	`discord_thread_id ↔ cc_session_id` 1:1 映射，idle pool 复用，原子写盘
`logical_session.py` (MER-267)	430	一个 `LogicalSession` 可挂多 runtime 子 session（claude_cli / codex / gemini），`active_runtime` 切换
`research_campaign.py`	564	`ResearchCampaignManager.start_campaign(name, topics, channel_id, max_concurrent, ...)` — 已经能并行 spawn 多个 CC worker、绑 Discord channel 推送状态、状态持久化、`/research-start` slash 暴露
`events/{schema,bus,store,bridge}.py`	829	`VyaneEvent` 统一 schema (lifecycle / model / tool / error / system)；CC 与 Codex ParsedEvent 自动桥接到 EventBus；EventStore 落 SQLite，按 trace_id / task_id 可查；trace/span 字段已预留
`scheduler.py` + `scheduler_mode.py`	2103+398	ADR-006 M1-M8 完成；`--scheduler-mode {off, shadow, on}`；shadow 跑中
`subprocess_manager.py`	690	CC / Codex subprocess 流式事件解析，`HealthMonitor`
`worker_registry.py`	542	worker lifecycle，`find_resumable(task_id)`
`task_board_bridge.py`	551	task-board → Scheduler 桥（M8）
`yi.py`	1536	Yi Discord client：channel ↔ worker 映射、消息队列、流式回复、附件、thread 历史拉取 + passive context buffer（非 @ 消息进 buffer 下次 flush）、message-edit → CC、forum thread starter 兜底
`yi_slash.py`	1173	已注册 14+ slash command，包括 `/research-start`, `/research-status`, `/research-stop`, `/compact-now`, `/reset-session`, `/model`, `/thinking`, `/title`, `/context-usage`, `/end`
`yi_format.py`	789	subagent 命名池 + `[Name]:` 引用格式（Maple 在 Discord 指代 subagent 用）

部署状态（来自 data/projects/vyane-personal-runtime-plan.md + memory）：

双端 Vyane = main@a276350，工作区 clean。
Mac mini com.maple.vyane-daemon launchd 在跑，scheduler shadow 模式（不接管真实调度）。
端口 8080 webhook，目前 VYANE_ALLOW_UNSIGNED_WEBHOOK=1（开发期，必须先收掉再上 idea 自动 promote）。
Yi bot 已上线 11 个 slash command（含上面那批）。
LINEAR_API_KEY 已读入，但 daemon 现阶段只读不建 issue。

2.2 已有的 idea / inbox 设计文档

docs/research/autonomous-2026-04-09/backlog-prep.md — MER-229 短/中期方案（规则检测 → 小模型分析 → idea-inbox.jsonl，显式说明不要直接进 Linear backlog）。
docs/research/autonomous-2026-04-09/enfp-ai-workflow.md — Maple ENFP-A 的人因设计：发散保护时间、零摩擦捕获、异步消化、能量适配；明确建议 docs/inbox.md 作为最先实现的 P0 项。
docs/research/autonomous-2026-04-09/agent-collaboration-protocol.md — agent inbox JSONL 协议；已经为 MER-229 预留了 idea-suggestion 消息类型。
agents/inbox/README.md — agents/inbox/<name>.jsonl schema 已定（id / ts / from / to / type / ref / summary / payload / ttl）。
docs/research/autonomous-2026-04-09/cc-cli-remote-trigger.md — CC CLI 自带 /loop、/schedule、CronCreate、RemoteTrigger，可作为"轻量调度"补充层。
docs/research/autonomous-2026-04-09/cc-cli-agent-teams.md — Coordinator Mode 的"synthesize, not delegate understanding"提示工程经验，对 Yi 处理 idea triage 有借鉴。

2.3 CC CLI 自身可用面

每个 session = ~/.claude/projects/<encoded-cwd>/<uuid>.jsonl（增量、不可裁剪）。
hook 系统已经在写 Meridian/data/session-index/signals-{macbook,mac-mini}.jsonl：每次 UserPromptSubmit / Stop 都落一行（含 prompt_hash / session_id / cwd / received_at）— 这是机器可读的"对话事件流"现成数据源。
summaries-*.jsonl 同目录已有 session 摘要（MER-237 已完成，双端验证）。
--resume <session-id> 可继续 session；compact 后仍可 resume。
Subagent (Task tool) + TodoWrite + TaskOutput 已是 Yi 内部规划的工具。

2.4 关联 Linear issue 状态

Issue	Title	State	Priority
MER-229	core: Idea 裂变与 Session 路由	Backlog	1 (Urgent)
MER-214	feat: 跨 session 通信 + parent-child session 架构	Backlog	3
MER-211	feat: Yi queue/steer — 移除 channel lock，支持中途消息插入	Done	3
MER-196	feat: 记忆层升级 — embedding + 跨 session 搜索 + autoDream	Backlog	3
MER-192	research: CC Channels + App Dispatch 设计学习	Backlog	4
MER-187	feat: CC/Codex Session 数据回流脚本	Backlog	3
MER-267	Vyane: logical session 抽象层	Triage	2
MER-268	Vyane: 多 model 切换的上下文 log-based sync	Triage	2

MER-211（中途消息插入）已 Done，MER-267（logical session）类已落，这两件事之前是 MER-229 的隐含前置 — 现在已经具备。MER-214（跨 session 通信）和 MER-196（autoDream）仍是后续依赖。

2.5 Maple 当前节奏与边界

来自 briefing-current.md / meridian-personal-first-plan.md / memory：

理解优先于实现：默认调研 / 讨论 / 概念梳理，不直接写代码。
personal-first：Vyane 当前服务 Maple 自己的 AI OS，不抢公开产品节奏。
daemon 稳定第一：webhook auth、scheduler readiness、hot reload、Yi/Discord/Linear webhook 运行态优先于新功能。
Linear 当日处理：Maple 提需求立即建 issue 写需求，agent 自排 priority，非他明说"后续"否则当日开始做（这一条对 idea promote 路径有约束）。
沟通：选择题不问答题，不催促，给状态快照不堆细节。
Maple ENFP-A：脉冲式能量、Ne 发散、Fi 决策；高能量时跟住，低能量时安静推进。

3. 设计原则

把 enfp-ai-workflow + Maple 在 issue 里说的话精炼成五条原则：

捕获瞬间 0 摩擦、0 中断。Yi 不能为了"问 Maple 这是不是 idea"反过来打断主线。
发散和收敛分开。捕获时只做记录；分类、提议、路由全部异步。
inbox ≠ Linear backlog。idea 草稿不进正式 backlog，避免污染"已审议"语义。
路由是建议不是决断。Maple 始终拥有 promote / archive 的最终判断，AI 给选择题。
能复用就不重写。research_campaign / LogicalSession / EventBus / Linear webhook 都是可挂的钩子，不要起新子系统。

4. Findings — 推荐架构

四个层级，对应 issue 描述的"捕获 / 分类 / 路由"加上一条人在环路。每层都尽量挂在已有组件上。

                     Maple ↔ Yi (CC CLI Opus, Discord)
                              │
              ┌───────────────┴────────────────┐
              ▼                                ▼
         显式触发                           被动监听
   "记一下" / /idea           Yi 在 system prompt 里被告知
   /idea-add <text>            可以在对话中调 mark_idea
              │                                │
              └────────────► Layer 1: capture ◄┘
                          idea-inbox.jsonl
                                  │
                                  ▼
                  Layer 2: triage (daemon 周期任务)
              聚合 / 去重 / 评分 / 自动归档低分
                                  │
              ┌──────────┬────────┼────────┬────────────┐
              ▼          ▼        ▼        ▼            ▼
           archive   Linear   research   spawn      message
                     issue    campaign   thread     other agent
                     draft    (复用)     (LogicalSession)  inbox
                                  │
                                  ▼
                  Layer 3: routing (已有组件)
              webhook + scheduler + research_campaign
                                  │
                                  ▼
                  Layer 4: human-in-loop (Discord)
                每天/每能量周期一次 batch summary
              + /idea-list / /idea-promote / /idea-archive

4.1 Layer 1 · Capture（捕获）

核心选择：让 Yi 自己（即 Opus 主对话）担任 idea detector，不要先做 EventBus 订阅 + 小模型二次扫描。理由：

Opus 已经是当前对话的"主语义解析器"，比另起 Haiku/Sonnet 二次过滤的判断质量高、延迟低、成本低（Opus 反正在跑）；
主对话流外做检测会重复消费上下文 token；
enfp-ai-workflow 给的"AI 应该跟着发散"原则要求 detector 是同一个 agent，不是另起一个会"想拉回主题"的旁观者。

实现：

在 agents/yi/profile.md（或 SOUL.md / system prompt 注入位置）加一段：
- 看到 Maple 抛出明显偏离当前主题但有价值的分支时，调 mark_idea 写入 inbox；
- 看到 Maple 显式说"记一下" / “分支：X” / /idea …，立即写入；
- 写入不打断当前主线回复，inbox 写盘是 fire-and-forget；
- 不主动建议合并、不主动 promote。
Meridian/data/idea-inbox.jsonl 作为单一 append-only 文件（路径与 data/yi-channel-prefs.json 同级，复用现有目录约定）。
Yi 写盘走 Bash/Write，或加一个轻量 Python helper（参考 yi_slash.py 里 channel-prefs 的原子写法）。

条目 schema 草案（最终可调，先按 enfp-ai-workflow + agent inbox 协议拼）：

{
  "id": "idea-20260430-001",         // idea-<YYYYMMDD>-<seq>
  "ts": "2026-04-30T20:32:11Z",
  "source": {
    "channel_id": "<discord channel/thread id>",
    "logical_session_id": "vs-xxx",   // 已有 LogicalSession.id
    "message_id": "<discord msg id, optional>",
    "device": "macbook | mac-mini"
  },
  "trigger": "explicit | passive",   // 显式触发 vs Yi 自识别
  "topic": "一句话标题（Yi 写）",
  "context_excerpt": "对话片段（≤ 500 字符）",
  "tentative_action": "queue | spawn | linear | discard",
  "confidence": 0.0,                  // 0-1，Yi 给
  "tags": ["vyane", "ux"],            // 可选
  "ttl_days": 14,                     // 默认两周
  "status": "pending"                 // pending | triaged | promoted | archived
}

显式触发约定（zero code）：

这个记一下、分支：<text>、@idea <text> 任一格式 → Yi 直接 append；
/idea <text> 走新 slash command（实现见 4.5）。

被动捕获：第二轮上线，Yi 在生成回复前回看本轮 prompt，发现">=N 个新主题"或"明显工作流跳跃"时主动 mark。初期偏保守、漏检好过误报（来自 backlog-prep 的判断，留住 Maple 的信任）。

4.2 Layer 2 · Triage（分类）

不让 Yi 实时做。daemon 周期任务负责：

聚合：每 N 小时（或 idle 触发），用一个轻量 worker（可 Sonnet）扫 inbox 里 status=pending 的条目；
去重 / 合并：标题相似度 + tags 重叠时合并条目，记 alias_ids；
评分：在 Yi 给的 confidence 基础上再加 priority 启发式（包含具体动作的高、纯感叹的低）；
自动归档：低 confidence + ttl 过期 → status=archived（但不删，留审计）；
建议动作：把 tentative_action 落定，写到一个 triage-suggestions.jsonl（不直接动 inbox 字段，留给 Maple 反悔的余地）。

实现位置：在 vyane/src/vyane/daemon/ 下新增 idea_inbox.py，参考 research_campaign.py 的结构（dataclass + Manager + state.json）。daemon main 启动时挂上去。

4.3 Layer 3 · Routing（路由）

关键判断：所有去向都已有现成承载器，新增的只是"把 idea 喂进去"的 adapter。

去向	承载组件	新增工作
Linear issue draft	`webhook.py` 已经持有 `LINEAR_API_KEY`，但目前只读不写	加一个 `_create_linear_issue(title, body, state="Triage")` GraphQL mutation；inbox triage 决定 promote 时调用，body 里附 idea_id 反向链接
Research campaign	`ResearchCampaignManager.start_campaign(name, topics, channel_id, ...)`	已可用，直接调
新 Discord thread + LogicalSession	`LogicalSessionManager.create_for_thread(thread_id)` + Yi 创 forum thread + spawn_claude	一个 `_promote_to_thread(idea)` helper：在指定 forum channel 创 thread → 把 idea context 作为 starter 消息（Yi 已有 `on_thread_create` 兜底）→ LogicalSession 自动建
其它 agent 的 inbox	`agents/inbox/<name>.jsonl` 协议已定义，type=`idea-suggestion` 已预留	现阶段只有 Yi 在线，跳过
静默归档	inbox 自身 status 字段	triage 阶段已做

决策不在路由层，在 triage 层 + Maple 的 promote 命令。路由层只执行、不判断。

4.4 Layer 4 · Human-in-loop（人在环路）

按 enfp-ai-workflow 的能量节奏：

不主动催：每天/每能量周期最多一次 batch summary 推 Discord（自动选 Yi 通知 channel 或当前活跃 channel）；

内容形如：

📥 idea inbox 自动整理 (2026-04-30)
pending 12 / archived 5（自动）
建议 promote：
  - idea-20260430-003 「openclaw 历史 session 复盘」 → research campaign
  - idea-20260430-007 「Yi 切模型时附件留存」 → Linear issue
/idea-list 查看完整、/idea-archive <id> 归档、/idea-promote <id> --as <linear|research|thread>

选择题不问答题：每条 promote 建议都标好 --as 参数，Maple 一句话能拍。
沉默是 OK 的状态：48h 没回应自动按建议动作走 dry-run（即建 issue 但 state 锁在 Triage，不进入 Ready / Backlog），Maple 后续仍可 archive 或确认。

4.5 现在就能加的 slash command 表

挂在 yi_slash.py 的现有分发器上，新增不超过 200 行：

命令	行为
`/idea <text>`	显式追加一条到 inbox（trigger=`explicit`）
`/idea-list [pending\|all]`	列出当前 inbox（默认 pending）
`/idea-show <id>`	看一条详情 + Yi 写的 context_excerpt
`/idea-archive <id> [reason]`	标 archived，写 reason
`/idea-promote <id> --as linear\|research\|thread [args]`	走 Layer 3 路由
`/idea-status`	当前 inbox 统计 + 最近 triage 结论

和已有 /research-start 的关系：/idea-promote --as research 内部直接调 ResearchCampaignManager.start_campaign，不用复制逻辑。

5. 阶段方案

Phase A · 当周可做 / 几乎零代码

目标：让 Maple 今晚就能开始用"记一下" + /idea 把 idea 落地。

[ ] 写 Meridian/data/idea-inbox.jsonl 的 README（schema + 触发约定）；
[ ] 在 agents/yi/profile.md 加 idea 捕获指令段（捕获原则、显式触发、不打断主线）；
[ ] 给 yi_slash.py 加 /idea, /idea-list, /idea-archive（最小可用），promote / show 留到 Phase B；
[ ] 写一个 tests/test_idea_inbox_format.py，锁住 schema；
[ ] 在 briefing-current.md 加一行"idea inbox 已上线"，让新 session 知道。

依赖：无。Maple 只需 review 文档变更。

Phase B · daemon 稳定后 / 2-4 周内

前置条件：webhook auth 收紧（现在 VYANE_ALLOW_UNSIGNED_WEBHOOK=1 必须先关）、scheduler shadow → 验证完毕、hot reload 路径明确。

[ ] 新增 vyane/src/vyane/daemon/idea_inbox.py（参考 research_campaign.py），含 IdeaInboxManager（load / append / triage_loop / promote）；
[ ] daemon 启动时挂 IdeaInboxManager，给 Yi 暴露同步 API；
[ ] webhook.py 增加 _create_linear_issue GraphQL helper（state 写到 Triage，作者标 system，body 含反向链接到 inbox id 和 source channel）；
[ ] IdeaInboxManager.promote(id, as_="research"|"linear"|"thread") 调对应组件；
[ ] 加 /idea-promote, /idea-show, /idea-status；
[ ] daemon dashboard / vyane status 加 inbox 视图（独立 panel，三个数：pending / 今日新增 / 自动归档）；
[ ] 加每日 batch summary 推送（默认走 YI_NOTIFY_CHANNEL_ID，或当天最活跃的 channel）；
[ ] 加配额：每天 idea-driven research spawn ≤ 3，promote 到 Linear ≤ 5（防爆）。

Phase C · 实验性 / Maple 单独决定时机

[ ] EventBus 订阅 idea_detector：在 assistant.text 上跑轻量正则 / Haiku 二次过滤，捞 Yi 漏掉的分支（Maple 可单独开关，默认关）；
[ ] LogicalSession.parent_session_id 字段：跨 thread 关联 idea → 子 session；
[ ] 自动 spawn child thread：promote --as thread 直接在 Discord forum 建 thread + 注入 starter，复用 Yi 现有的 on_thread_create 路径；
[ ] Codex worker 的 idea 捕获：通过 events/bridge.py 加一个 codex side 的 mark_idea 工具暴露（让 Codex 跑代码时看到值得记录的方向也能捕获）；
[ ] 整合 data/session-index/signals-*.jsonl：对历史 prompt 做 retro 检测（生成"被忽略的 idea 清单"）。

Phase D · 远期 / 与 MER-196 + MER-187 联动

[ ] autoDream（MER-196）扫 inbox 残留，把存活 > 30 天且未 promote 的转成 memory；
[ ] MER-187（session 数据回流）跑通后，从历史 jsonl 反向挖掘漏检 idea（一次性 batch）；
[ ] inbox embedding 索引：相似 idea 自动合并不再靠规则；
[ ] 跨设备 idea 同步：当前 idea-inbox.jsonl 在 Meridian/data/（Syncthing 同步范围内），需要确认双端写并发安全 — 大概率走"按设备分文件 + 周期合并"模式。

6. Risks & Uncertainty — 风险与不确定项

按对推进的影响排：

6.1 高优先级风险

R1 · 检测精度有限，Maple 信任会先打折 Yi 自己识别"分支"会有偏差：主对话 token 紧的时候漏检、Maple 自言自语时误检。应对：初期偏保守 + 显式触发为主 + 不主动 promote，让 Maple 先看到"capture 没误伤、promote 都是我说的算"。

R2 · inbox 噪音淹没 → Maple 逃避 triage 低质量 idea 太多，Maple 看一眼就累，反而不 review。应对：自动归档低 confidence；每日 summary 只列 promote 建议，不堆全列表；/idea-list 默认只看 7 天内 pending。

R3 · Linear backlog 污染 直接把 idea 写 Linear Backlog 状态会破坏"已审议"语义。应对：promote 写入永远落到 Triage 状态、作者 system，Maple 自己判断后再升 Backlog。

R4 · daemon webhook auth 仍宽松 当前 VYANE_ALLOW_UNSIGNED_WEBHOOK=1，如果 Phase B 上线 idea-driven Linear issue 创建，公开端口可被滥用造 issue 灌噪音。应对：Phase B 必须先把 LINEAR_WEBHOOK_SECRET 收齐 + 关 unsigned 开关；这本来就是 daemon 稳定性 milestone。

6.2 中优先级风险

R5 · 多 runtime 的 idea 错过 当前所有捕获都依赖 Yi (CC CLI Opus)，Codex worker 跑出来的有价值方向不会进 inbox。应对：Phase C 给 Codex side 加 mark_idea；不阻塞 Phase A/B。

R6 · LogicalSession 父子关系尚未实现 当前 LogicalSession 没有 parent_session_id，promote --as thread 的"上下文继承"只能复制粘贴。应对：Phase B 不依赖 thread promote，Phase C 加字段。

R7 · scheduler shadow / on 切换的兼容性 Phase B 的 idea-driven spawn 走 daemon.spawn_claude，绕过 scheduler。如果未来 scheduler 切到 on，路径会出现两条调度链。应对：让 IdeaInboxManager.promote(_as="research") 把 task 写到 task-board，让 scheduler bridge 接管；spawn_claude 直调留作 fallback。

R8 · 跨设备并发写 inbox 两台机器都跑 daemon（虽然现在主要 Mac mini 在跑），同一个 idea-inbox.jsonl 在 Syncthing 同步路径上有冲突风险。应对：按设备分文件（idea-inbox-{device}.jsonl），daemon side 周期合并；或先约定只 Mac mini daemon 写、MacBook Yi 写到子文件再被合。

6.3 低优先级 / 概念性不确定

R9 · “idea” 和 “Linear issue” 的边界会模糊 随着用得多，可能出现"我直接 /idea 写了，Yi 给我建议 promote 到 Linear，那我为什么不直接建 Linear？“的问题。判断：保留两套是有意的 — Linear 是"已审议任务”，inbox 是"未审议素材"。Maple 后续若决定合并，那是产品判断，不是技术决策。

R10 · enfp-ai-workflow 那种"AI 跟着发散"和"AI 帮你 mark"的微妙界限 mark idea 这件事本身可能让 Yi 在对话中打一次"内部停顿"，破坏发散感。判断：现在没法预先验证，需要 Phase A 用一两周后 Maple 主观感觉是否打扰，再决定 mark 是否在主回复完成后异步执行。

R11 · "捕获瞬间 0 摩擦"和"主动 promote 选择题"是对立约束 捕获时不打断 = AI 不主动问；但 promote 阶段 AI 又必须给选择题。两个动作如果时间太接近会形成"间接催促"。应对：把 promote summary 推送时机绑到 idle 信号（Yi 检测 channel 长时间无消息或 Maple 显式说"先这样"才推）。

6.4 暂时无法回答的问题

idea-inbox 的合理 ttl 默认值。两周是拍脑袋，等 Maple 真用一段时间观察平均 promote 时长才能定。
triage 用什么 worker：Sonnet 还是 Haiku 还是 Opus 自己 idle 时跑。和 MER-196 的 autoDream 策略其实是同一个问题，可一起考虑。
idea promote 到 Linear 时是否要顺手生成一个简单的初步描述。利好 Maple 决策但容易"塞 AI 写的废话"，先不做。
是否要把 inbox 暴露给自研 IM（自研 IM 还没动工，Phase A/B 先不考虑前端）。

7. Recommended follow-up work — 推荐后续工作

按优先级和触发条件分组（不是 deadline 清单）。

7.1 立刻（不阻塞 daemon 稳定）

把本报告挂到 MER-229 的 Linear comment 作为新一版方案。
起草 Meridian/data/idea-inbox.jsonl 的 README（schema + 触发词），让 Yi 当晚就能开始记。
agents/yi/profile.md 增加"idea 捕获约定"小节，包含：什么算分支、显式触发词、写 inbox 的格式、不打断主线的承诺。
给 yi_slash.py 加 /idea, /idea-list, /idea-archive 三个最小命令（参考 cmd_research_* 实现，<150 行）。

7.2 daemon 稳定后

新建 vyane/src/vyane/daemon/idea_inbox.py，按 4.2 / 4.3 实现 IdeaInboxManager。
在 webhook.py 加 _create_linear_issue GraphQL helper（先留 dry-run flag）。
加 /idea-promote, /idea-show, /idea-status。
dashboard / vyane status 加 inbox panel。
配额防爆（idea-driven spawn / promote 上限）。

7.3 实验 / 拓展

EventBus idea_detector 实验（Maple 单独开关；Phase C）。
LogicalSession 加 parent_session_id（Phase C）。
Codex side mark_idea（Phase C）。
autoDream 与 inbox 整合（与 MER-196 联动）。
历史 jsonl 反向挖掘（与 MER-187 联动）。

7.4 不推荐 / 反对的方向

直接把 idea 灌进 Linear Backlog。会污染 backlog 语义，Maple 已多次强调 backlog 是"已审议"。
先做 EventBus 二次扫描 + 小模型检测，再做 Yi 自检。顺序反了，Yi 在线时是最便宜的 detector，二次扫描应该是补漏不是主路径。
再开一个独立 idea-bot agent。当前唯一活跃 persistent agent 是 Yi，不要新建身份。idea capture 是 Yi 的内部能力，不是新 agent。
承诺自动检测准确率指标。Yi 自检会偏低，写承诺数字反而会反弹咬到信任。
把 idea 路由到外部 IM（Slack / 微信）。当前没规划，Maple 在 personal-first 阶段，外部端会扩散注意力。
CC CLI /loop 把 inbox 周期处理委托给主 session。主 session 是 Maple ↔ Yi 的对话，注入定时任务会在低能量期反而变干扰；triage 应该走 daemon 后台 worker。
LINEAR_API_KEY 暴露到 webhook 端。当前 webhook secret 还没收紧，暴露 key 会被反向滥用；Linear mutation 必须从 daemon side 主动调，不让外部 webhook 触发。

8. 附录

8.1 关键文件清单（开发时用）

路径	作用
`Meridian/data/idea-inbox.jsonl`	新建：append-only idea 流
`Meridian/data/idea-inbox-state.json`	新建：triage 状态 + 配额计数
`agents/yi/profile.md`	加 idea 捕获指令
`vyane/src/vyane/daemon/idea_inbox.py`	新建：`IdeaInboxManager`
`vyane/src/vyane/daemon/yi_slash.py`	加 `/idea*` 命令
`vyane/src/vyane/daemon/webhook.py`	加 Linear `_create_linear_issue` helper
`vyane/src/vyane/daemon/main.py`	启动时挂 `IdeaInboxManager`
`vyane/src/vyane/daemon/research_campaign.py`	不动，被复用
`vyane/src/vyane/daemon/logical_session.py`	Phase C 加 `parent_session_id`

8.2 Phase A 验收标准（建议）

Maple 在 Discord 任意 thread 说"这个记一下：vyane 模型切换附件留存方案"，下一条 Yi 消息能确认条目 id 已写入；
/idea-list 至少能列出该条；
/idea-archive <id> 重复 把它标 archived；
不影响主对话流（Yi 主回复时长无明显增加，subjective）。

8.3 与 enfp-ai-workflow 的对照

enfp-ai-workflow 第 1 节"零摩擦捕获 + 异步整理"是本方案的人因约束，第 7 节"现在就能做的"项 1 直接对应 Phase A：“约定一个 docs/inbox.md，你说’记一下’AI 就追加进去。零开发成本”。本方案把"docs/inbox.md"改成 Meridian/data/idea-inbox.jsonl（机器可读 + 与 yi-channel-prefs 同 dir），但承袭了同一原则。

8.4 与 backlog-prep.md 的对照

backlog-prep 的 MER-229 部分给了短期（规则检测）/ 中期（小模型分析）/ 路由（idea-inbox.jsonl 不直接进 Linear）三段式建议。本方案：

跳过"规则检测"短期方案，直接用 Yi 自识别 + Maple 显式触发（更高质量、零模型成本）；
"小模型分析"挪到 Phase C 的 EventBus 订阅，作为 Yi 漏检的补漏，不是主路径；
完全采纳"idea-inbox.jsonl 不进 Linear backlog"的路由判断，并加上"promote 到 Linear 时只入 Triage 状态"的细化约束。

9. Evidence quality 自评

主题	证据强度	备注
Vyane daemon 现状	High	直接读源码 + memory 部署状态 + briefing
MER-229 issue 描述	High	Linear API 直接拉到
关联 issue 状态	High	Linear API
已有 inbox / capture 设计文档	High	全文读了 backlog-prep + enfp-ai-workflow + agent-collaboration-protocol
Yi / yi_slash 实现	Medium-High	读了 main / session_manager / logical_session / research_campaign / scheduler_mode 全文 + yi.py 前 700 行 + yi_slash 前 500 行
Maple 偏好 / 节奏	Medium-High	来自 MEMORY.md 与 briefing-current；不可避免有解读
风险评估	Medium	推断为主，没法实证；6.4 列出已知不确定项
跨 runtime 兼容性	Low-Medium	仅基于现有事件 schema 设计，没真在 Codex 上验证 idea 流
远期 (Phase D) 与 MER-196/187 联动	Low	那两个 issue 仍 Backlog，细节没定，本报告只画路径不出方案

10. 一段总结

MER-229 的实质问题不是"还差一个组件"，而是"现有组件没串起一条 capture → triage → route 的最小闭环"。Vyane daemon、Yi、Linear、CC session、Discord 已经各自就位，连 inbox 协议和 idea-suggestion 消息类型都预留好了。Phase A 的零代码做法可以让 Maple 当晚开始把 idea 落地，Phase B 把 daemon side 接上才能跑起 promote / 自动归档 / batch summary 的全流程；后面两阶段是锦上添花，不阻塞主线。

最该警惕的不是技术风险，是让 inbox 反过来挤占 Maple 的注意力。一切自动化的目的都是：Maple 不在的时候 idea 不丢，Maple 回来时只看选择题。