加工管线

加工（baking）是 Context Infra 真正产出价值的那一段：一份原始材料被一步步抬到更高的层级，每一步都留着来源边，所以最后那条 issue 能一路点回它在逐字稿里的出处。

为什么还要自己加工一层

开完会手上其实有两份东西，问题是两份都不够用：

L1 会议梳理补的就是中间这一层：比纪要全，比逐字稿干净。

L1 会议梳理

读逐字稿加智能纪要，写一份完整、可回溯的梳理文档。

它的目标是不丢认知，不是「短」——所以它不是摘要，长会的梳理能到上万字。要快速扫一眼结论，看它的原子议题；要核对某句话是谁说的，点回逐字稿。

加工什么时候发生：命中规则的会，飞书纪要一生成就自动触发（见放进来）；没命中的会，在图谱页点「＋ L1」手动跑。

产出的写回方式有两条纪律：

• 作者是 bot（应用身份），留痕写「Context Infra 应用」，不是触发加工的那个人
• 梳理文档会挂回原纪要的「相关链接」，优先用 bot 挂；bot 不是纪要协作者挂不上时，退回用户身份兜底，不阻塞入库

幂等键是 dream:meeting:<L0 幂等键>：加工前先按键查一次，已经有了就跳过——不重复生成，也不重复往纪要里塞链接。

宁可没有 L1，也不发残废 L1

拦的只有三条：

1. 子进程退出码
2. 正文长度与输入材料不相称
3. 正文里留着模型自己的未完成标记

「深度认知与见解」这类小节不拦——它来自 prompt 的质量要求，不是「这份产出完不完整」的判据。模型不照写、或者在那一节里自己发挥结构，都算正常产出，缺了只记一条 warning，内容照发。

原子议题

梳理生成后链式触发拆解：模型读 L1 正文，输出一个议题数组，每个议题成一个独立节点，边回指这场会。

「涉及的人」取自逐字稿的发言人，口径是谁提的 / 谁负责 / 谁被影响——会上被提到但本人不在场也算。查询时按 people_involved 含你的 open_id 过滤，就得到「跟我有关的议题」。

议题的稳定短链

每个议题有一个固定地址：

/t/{会议码}/{x}

这条链接的意义是议题成了一个可被外部引用的实体：可以发给别人、可以贴进文档、可以被 agent 读取，也可以被挂到 issue 上。议题页展示讨论与结论、决策、待办、涉及的人、来源会议与会议梳理文档，以及已经从这条议题建出来的 issue。

会议时间按北京时间展示。

候选 issue

议题拆完再链式触发一次：读议题的 action_items，清洗成候选 issue。

• 清洗：去掉模糊归属
• 去重：先查 Multica 已有 issue（标题模糊匹配），再查本地已生成的候选，所以同一场会重跑不会刷出一堆重复
• 每个候选是一个节点，边回指它来自哪个议题

去重结论分三档，都只是提示、不替你决定：

归属纪律

候选 issue 的「指派给谁」按固定规则留白，而不是硬猜一个人：

审核并建到 multica

候选默认 review_status = pending，停在待审。在溯源泳道页点「✓ 建到 multica…」弹出一个文档式的创建窗：左边是 issue 正文（所见即所得的 markdown，预填自候选），右边是属性栏——项目、指派、挂载。

• 疑重的候选会先给「⚠️ 疑似重复」提示，确认无妨可以选「仍要创建（允许重复）」
• 不想建的点「✕ 弃」，候选转 rejected，不会再出现在待审里
• 创建成功后把 issue_id 和 issue_identifier 回填到候选节点上，议题页的「已挂载的 issue」随即出现这一条

溯源泳道页

/pipeline/{node_id} 是审查视角：一场会的四道泳道并排放着——

逐字稿（原文） → L1 会议梳理 → 议题（拆解） → 候选 issue → multica issue

设计目标是让人一眼看清一份原文档是怎么一步步被加工上去的、哪里抽成了什么、最终发成了哪条 issue。跨泳道的对应关系靠两样东西表达：同一个颜色 + 同一个 #N 编号。鼠标停在 L1 的某个小节上，对应的议题卡和候选分组会一起亮起来。

议题卡上直接显示它的稳定短链，可点可复制。没挂到任何议题的候选单独分一组摆在最后，不混进来。