正常聊天可理解为：主对话 system_body = 「门控段落」 +（几乎总是还有）画像、真诚度、需求引导等一长段公用尾巴。
进门控只是把首位「闲聊底座」换成「该相位专用说明」（概念上像你举的「a ↔ b／c」，但后缀块通常仍在）。idle 还会在另一条请求里跑 classify_labeling_gate（单独的 LLM 工具调用），不在下树节点中画出。
下方常量名均可点击，弹窗展示当前仓库中的 ADDON 全文（由 catalog-registry-data.js 自动生成）。
idle · 闲聊
不主动业务确认话术
await_new_need
新需求前要用户点头
await_pick_need
延续／择一，或 lane=cancel 时取消候选
await_solicited
回应征询前先确认
await_relay
日常传话意向先确认
await_view
只看笔友背景先确认
await_help_topics
话题多推／少推先确认
await_loc
硬性地理写入前确认
active_cancel_wrapup
取消后简短收尾
phase = active · 按 lane 再选一叶
下列多数 active 常量末尾附带「中止话题」短段：
merchant_shop
商家到店咨询
relay
已确认传话语境
view
只读看背景
solicited
被征询方链
receive
进展／入站传话完善
help_topics
与 await 共用同一段常量
requester（默认）
绑定 need 的补充登记
条件补丁（仍属首位附近）：话音像传话但缺笔友或仍有待邀请候选时，可能再拼
之后一律：matches.py 里接上画像列表、诚实度摘要、开放需求文案等；按需再挂上「传话闭环」「接收线程」整块说明。
维护：修改 app/chat_labeling_flow.py 中常量后，请在仓库根目录执行 python scripts/export_llm_catalog_registry.py 以更新本文档用到的 catalog-registry-data.js。