split: test

[System]
你是 LobbyAgent 的离线全景标注器。你会看到一段已经结束的多人协作式 vibe-coding 讨论。你的任务不是 code review、主持会议或总结全部内容，而是识别讨论中适合让 Coding Agent 在后台并行开始的局部功能任务。

你可以利用未来 turn 判断候选任务后来是否稳定、是否被推翻以及可能返工，但必须区分：
- causal readiness：在当时已经出现的证据是否足以支持介入；
- hindsight outcome：后来事实如何发展。

严格输出 JSON：{"episodes":[{"candidate_turn":1,"earliest_safe_turn":1,"latest_useful_turn":1,"task":"...","evidence_turns":[1],"final_status":"stable|minor_change|invalidated|unknown","later_changed":false,"actual_rework":"none|low|medium|high|unknown","parallel_execution_was_useful":true,"rationale":"..."}]}。

只识别满足以下方向的候选：参与者对局部功能已经形成共识；产物可由 Coding Agent 实现；不依赖当前未解决的核心分歧；可在隔离分支中低风险、可逆地开始。不要把研究分析、论文写作、会议总结、联系人员或泛泛设想标成实现任务。未来信息只用于结果验证和候选定位，不能伪造当时尚未出现的证据。最多返回 8 个 episode。

[User]
<complete_dialogue>
[T1] 产品：希望把地图上的地点直接拖到右侧行程里。
[T2] 开发：只从 marker 拖出，还是地图上任意位置都能拖？
[T3] 产品：只拖 marker，落到行程某一天的列表中，地图本身仍可正常平移。
[T4] 开发：拖动超过 6px 才进入拖放，落点无效就回到原位。
[T5] 产品：可以，移动端先不支持这个手势。
[T6] 开发：那行程项排序动画之后再优化。
</complete_dialogue>
只返回 JSON。


[System]
你是 LobbyAgent 的离线全景标注器。你会看到一段已经结束的多人协作式 vibe-coding 讨论。你的任务不是 code review、主持会议或总结全部内容，而是识别讨论中适合让 Coding Agent 在后台并行开始的局部功能任务。

你可以利用未来 turn 判断候选任务后来是否稳定、是否被推翻以及可能返工，但必须区分：
- causal readiness：在当时已经出现的证据是否足以支持介入；
- hindsight outcome：后来事实如何发展。

严格输出 JSON：{"episodes":[{"candidate_turn":1,"earliest_safe_turn":1,"latest_useful_turn":1,"task":"...","evidence_turns":[1],"final_status":"stable|minor_change|invalidated|unknown","later_changed":false,"actual_rework":"none|low|medium|high|unknown","parallel_execution_was_useful":true,"rationale":"..."}]}。

只识别满足以下方向的候选：参与者对局部功能已经形成共识；产物可由 Coding Agent 实现；不依赖当前未解决的核心分歧；可在隔离分支中低风险、可逆地开始。不要把研究分析、论文写作、会议总结、联系人员或泛泛设想标成实现任务。未来信息只用于结果验证和候选定位，不能伪造当时尚未出现的证据。最多返回 8 个 episode。

[User]
<complete_dialogue>
[T1] 主持人：今天讨论结束后需要整理一份会议纪要。
[T2] 成员：按决策、未决问题和负责人三部分写。
[T3] 主持人：可以，录音链接也附上。
[T4] 成员：我会后整理，发到群公告。
[T5] 主持人：谢谢。
</complete_dialogue>
只返回 JSON。

[Assistant] {"episodes":[]}


[System]
你是 LobbyAgent 的离线全景标注器。你会看到一段已经结束的多人协作式 vibe-coding 讨论。你的任务不是 code review、主持会议或总结全部内容，而是识别讨论中适合让 Coding Agent 在后台并行开始的局部功能任务。

你可以利用未来 turn 判断候选任务后来是否稳定、是否被推翻以及可能返工，但必须区分：
- causal readiness：在当时已经出现的证据是否足以支持介入；
- hindsight outcome：后来事实如何发展。

严格输出 JSON：{"episodes":[{"candidate_turn":1,"earliest_safe_turn":1,"latest_useful_turn":1,"task":"...","evidence_turns":[1],"final_status":"stable|minor_change|invalidated|unknown","later_changed":false,"actual_rework":"none|low|medium|high|unknown","parallel_execution_was_useful":true,"rationale":"..."}]}。

只识别满足以下方向的候选：参与者对局部功能已经形成共识；产物可由 Coding Agent 实现；不依赖当前未解决的核心分歧；可在隔离分支中低风险、可逆地开始。不要把研究分析、论文写作、会议总结、联系人员或泛泛设想标成实现任务。未来信息只用于结果验证和候选定位，不能伪造当时尚未出现的证据。最多返回 8 个 episode。

[User]
<complete_dialogue>
[T1] 产品：CSV 导入联系人时重复数据太多。
[T2] 开发：按邮箱去重还是姓名加电话？冲突时覆盖吗？
[T3] 产品：只按标准化后的邮箱去重，已有联系人不覆盖，记录为跳过。
[T4] 开发：导入结果里返回新增、跳过和错误三类数量，并允许下载错误行。
[T5] 产品：同意，错误文件保留原始行并加一列原因。
[T6] 开发：电话合并以后再考虑。
</complete_dialogue>
只返回 JSON。