广播回复只存首屏，边界留在原始档案

Issue #26 提醒我们：广播列表里的“回应”数量并不等于回复正文已经备份。 实测详情 HTML 中的评论容器也是空的，回复由独立接口加载。 因此，保存详情页和保存回复是两项不同的工作。

只保存一页上下文

这次 main 分支新增“保存广播回复首屏”，默认不勾选，仅对当前登录者自己的账号开放。 只有本人广播根卡片明确显示有回复，才会分别保存详情 HTML 和一个回复 API 首屏。 转发来源的回应数不会触发请求，句尾省略号也不会触发。

首屏可能包含楼中楼预览，但不会继续翻页、展开楼中楼，也不会请求回复者的主页、头像或附件。 已根据正常样本支持本人 personal topic 动态；它复用 group/topic 评论接口， 但不会扩展到小组讨论。没有增加短链域名权限。 登录其他账号来备份某人的公开内容，以及匿名备份，均维持原有范围。

三种模式各做什么

第一次开启时，会从同账号、同视角的历史广播列表离线找出候选，包括水位线以前的广播。 无需为此重读所有历史列表。开始任务之后，开关随身份和模式固化到断点； 继续抓取不会采用面板后来改过的选择。登录状态变化会暂停，需要确认原账号后才能继续。

原始证据和个人内容分开

第三方回复只留在 WARC 原始响应里。解析器报告捕获编号、结果和首屏范围， 不把它们生成个人 Canonical 记录，也不加入网站、搜索或 NeoDB 等平台导出。 详情 HTML 暂时同样只保留原始证据，没有直接套用列表抽取器来制造新的广播版本。

首屏成功不代表整段讨论完整，空首屏也不表示历史回复已删除。 原始备份可能含第三方发言与登录视角信息，并不是已经过滤好的公开网站产物。 这次没有新增讨论状态文件、回复实体或“包含讨论”发布开关。

实际抓取暴露的两个问题

首次开启后，历史列表里有 51 条符合条件的广播，因此补抓了 51 个回复首屏。 第一轮全部返回 HTTP 400：桌面详情页本身会从 m.douban.com 的 API 读取回复， 接口需要 Referer，而原来的请求头规则只覆盖图片。补上规则后，同一任务的 51 次重试 全部得到正常 JSON，共保存 77 条顶层回复。失败与成功响应都留在原始档案里。

这份导出还暴露了重复请求：同一条广播有数字 UID 和用户名两种链接， 51 条广播被抓成了 102 个详情页。现在调度按已核验账号 UID 与广播 SID 去重， 同时识别历史成功捕获和旧断点中的别名，原始链接仍如实存档。 离线复算确认：普通增量不会再请求这 51 组成功快照，刷新模式只重抓回复首屏。

同一个未支持入口只在每条路线记一个缺口，恢复任务不再重复累加。 随后收到正常登录下的个人 topic 页面及评论响应，才补上这类入口：其回复按 nested 首屏保存，内嵌作者回复随原 JSON 留存，不继续展开。页面明确显示“已编辑”， 因此刷新模式也重新保存个人 topic 正文。 用当前档案离线复算，普通增量只需为遗漏的那条个人动态新增一张详情和一个回复首屏。

验证与交付状态

自动化测试核对了实际请求集合、三种模式与访问视角、独立的 HTML/API 成败、 历史补抓、会话变化及断点恢复。WARC 导出再导入后回复字节保持一致， 加入这些捕获前后的页面、搜索和平台导出相同。

另有两个崩溃窗口测试：列表落盘而子任务尚未写入断点时仍能补齐； 回复首屏已落盘而断点尚未更新时不会重复请求。 Firefox 无头渲染检查了开关布局，Chrome 与 Firefox 安装包均已通过本地打包。

推送后的 CI 还发现一处测试边界问题：旧的账号测试借用 Canonical 的轻量校验器检查 Bundle 抓取范围，无法执行新加入的条件约束。现将范围测试移到完整 JSON Schema 校验器，并把旧档案兼容性及回复首屏 opt-in 的视角约束一起纳入 CI。

实现与文档已分步提交并推送到 main，尚未发布新扩展版本。本次 Chrome 实际导出已经验证首屏重试成功； 身份去重和缺口修正通过真实档案离线复算及自动化测试。后续实际导出已验证 topic HTML 和 nested 首屏均成功，且 52 个根各只有一张详情和一个首屏。 这次运行也重新抓了此前的 51 个 status；它使用较旧的增量基准，不能据此声称已验证跨轮跳过。 将本次成功档案保留在扩展库中后，离线复算下一次增量快照队列为零。 Firefox 的真实登录抓取仍待验证， 不能用打包或模拟接口测试代替。

实现与依据： 设计与模式矩阵、 原始快照规范、 抓取核心、 面板与运行范围、 解析隔离。