[huangruiteng]

打开原绑定会话时，历史某个后续页面断线会丢弃已核验页面，现有重试从第一页重新读取。现在同一读取器在浏览器内保留已核验分页进度，从失败游标继续；全文完整核验后才发布到会话或允许发送。

复用现有重试节奏和来源 owner；权限拒绝、来源或分页不一致会清除进度。刷新、重新加载仍发起新读取，不新增服务端状态、超时配置或业务重放。

验证：

• 原 HTTP/SQLite/Core 的 bound-conversation smoke，包括连续两次断线、不可变前序状态、撤权、403、来源与摘要冲突及完整正文一致性。
• 同一回归挑战不可变基线 reader：旧请求偏移为 0,200,0,200,400,0,200,400，修改后为 0,200,200,400,400。
• 现有 conversation-history 回归、TypeScript 检查及正式 Chat 构建通过。精确 head 的标准 premerge：5 项 direct、18 项选择检查均通过；3 项图片人工审阅已完成，原始 manual_review_required 保留。
• 打包界面 + 真实一次性 HTTP/SQLite/Core：464 行、19,000 字正文、两次自动恢复、草稿保留、恢复前禁止发送、窄屏无横向溢出；存储与模型请求读回相同。
• 目前仅证明打包浏览器行为，未宣称已安装原生 App 生效、实时 IM 或全部历史业务完成。来源/模型身份为合成 fixture，不连接个人会话。

界面证据（head 9b1e52458f479c9725797c11b69a7a676008ab09，现有样式与文案）：

验收边界及复现

[loopx-agent]

Reviewer: model_agent · Codex · OpenAI · self_reported

动机 / Motivation

打开已有绑定会话并阅读完整答复的 App 用户。
后续页面断线时，旧读取从第一页重来；新读取从失败游标自动继续，全文核验完成后恢复原对话。
464 条原记录及 19,000 字正文完整可读，草稿保留，恢复前发送保持禁用。
本 PR 不修复服务端全部慢读取、实时 IM 业务或安装中的 App 激活。
已证明打包浏览器行为；原生 App 安装生效与真实消息业务闭环仍需独立验收。

这个问题的实际成本随历史长度累积：用户已经有原对话和完整答复，却会在重试中反复等待此前已经读取过的页面。单纯增大超时并不能保存已完成的读取工作。审查把本次看作一个有独立用途、可回退的修复增量，而没有把浏览器恢复成功当成整个消息闭环已经完成。

改动思路 / Approach

分页进度属于现有浏览器读取器的派生状态；复用来源、游标和重试 owner，避免新增服务端账本或第二套重试。
本次只交付原会话历史断线恢复；不更改业务执行、会话身份或服务端持久化。

入口仍是 useConversationHistory → fetchChatHistory，权威来源仍是 Core 的绑定解析及原 HTTP 分页。浏览器只暂存已完整核验的页面；下一次恢复重新读取当前来源，并从原游标继续。全部页面成功后还会再次确认来源，随后才把完整快照交给页面。已核验页不是业务状态，也不能单独成为发送授权。

我比较了不修改、放宽请求超时和增加服务端恢复账本三种方案。不修改保留重复工作；放宽超时不能解决连续断线；服务端账本会引入新的持久化和回收责任。扩展现有读取器更贴合当前问题。公开独立读取函数保留原参数、取消和单 Turn 过滤语义，内部函数承担同一分页规则，没有第二套分页实现。

相同输入下的读取	不可变基线 reader	本次 reader
200、400 页各丢失一次传输	0,200,0,200,400,0,200,400	0,200,200,400,400
最终完整正文	完整，重复此前前缀	完整，只重试失败页

这是实际 HTTP/SQLite/Core 反例的观察，不是仅从代码推演的性能估计，也没有据此推断全部生产延迟的根因。

具体改动 / Changes

规范依据为 docs/development/frontend-delivery.md#task-first-delivery--从用户任务开始，以本次修改前的完整 revision 4a4fe1495b89eac3af9bd1f956183748c2944909 为准：任务交付合同。本 PR 增加的文档不是反向定义其验收标准。

• Task-first-step-3：implemented。 从重复断线构造反例；同一回归在不可变旧 reader 上因重复第零页而失败，在当前 reader 上通过。另查撤权、403、来源及摘要冲突，避免只验证顺利读取。
• Task-first-step-4：implemented。 实际构建 Chat，使用真实一次性 HTTP/SQLite/Core 绑定，经过页面和既有 hook 自动恢复，读回完整正文、草稿、发送状态及不变存储。
• Task-first-step-6：deferred。 本次已证明打包行为；安装采用与原生 App 读回仍沿原安全激活流程继续。这是既有安装采用验收的剩余工作，不能用截图或 PR 合并替代。

关键代码讲解

readChatSessionHistory 复用原来的范围、offset、total、digest、消息 ID 和游标前进校验。只有整个页面验证完才产生 checkpoint。返回仍是一份完整快照，前缀不会提前作为历史发布。原始独立函数调用不需要传入恢复状态。

fetchChatHistory 克隆先前的进度，避免后续重试修改已交给 React 的状态。当前索引不再包含的 Session、范围冲突以及非传输错误都会清理进度。只有明确的 chat_api_unavailable，且状态码缺失或为 5xx，才保留已验证前缀；403 不会借这个错误名称成为可恢复授权。

sameHistorySource 保留原 Session、Agent、Goal、channel、project、instance 和模式比较语义。它同时用于页验证和恢复状态的来源比较。新状态来自当前页数据，完成、拒绝及重新加载时退场，不需要用户维护额外记录。

其余改动是现有 bound fixture 的大历史场景、回归断言、已有前端文档和三张公开安全截图。没有改变 Core、listener、原业务队列或模型调用。公开的证据与边界保留完整说明。

对主干的风险 / Risks

最强反例是旧进度被带入已经撤权或换来源的会话，随后错误启用发送。当前实现保留了恢复前来源解析、逐页验证和完整后再次解析三道原边界；真实 HTTP 测试观察到拒绝或清理，错误进度未进入 snapshots/messages。打包页面在不完整状态确实禁用发送；恢复后原存储和模型请求的读回完全相同。

PASS：npm run smoke:bound-conversation（原项目绑定及 steward fallback）、npm run smoke:conversation-history、TypeScript 检查和正式 npm run build:chat；打包恢复场景 464 条记录、两次连接中断、原长正文唯一、草稿保留及窄屏检查均通过。标准 premerge 的选择检查及直接检查结果见当前验证记录；图片属于文本扫描以外的人工项，我已检查三个视口的像素、来源及 PNG metadata，没有个人数据或文字 metadata。不是把 manual_review_required 改称自动通过。

先前缺 manifest 的运行发生在只执行 Vite 构建而未走正式包构建时，正式构建后的原入口已通过；早先 slow 场景的两条断言仍比较扩充前的两行 fixture，修正为同一次完整历史后通过，没有删除慢读取、取消或来源检查。第一次 base oracle 运行的模块解析错误也保留，修正依赖解析后才取得重复前缀的有效失败。远端 CI 按本 Goal 的 wait_for_ci=false 未查询，未推断其状态。

语义与 CI 对齐

新增的是局部 browser-memory 派生进度，复用现有 message_page 和原来源合同，不创建共享 Core 状态或新权限词汇。独立 reader 的旧完整快照、取消及过滤行为继续通过现有回归。未新增 opt-in/default-off 开关，因而不把安装、模型可用或发现工具当作启用信号。内存复制成本随完整历史增长；本次消除了重复网络读取，没有声称解决无限历史的总内存成本。重新加载会从头读取，这是明示的现有边界。

我的整体评价 / Verdict

结论为 APPROVE，仅针对 9b1e52458f479c9725797c11b69a7a676008ab09。这是作者上下文中的模型自审，不构成独立人员复核，声明的产品系列也不是后端身份认证。

long_horizon：improved，连续断线后可以继续完成同一读取，而没有重放业务。user_experience：improved，同一次打开即可自动恢复，零额外授权、重填或恢复确认。原 owner 和现有调度已经足够，新增的局部派生状态与故障成本相称，不需要新 provider 或持久协议来完成这个切片。

核对了同一打包界面的失败、恢复和窄屏全视口：失败说明与重试在输入区上方，草稿始终可见；恢复后原消息占主体，没有增加解释面板。
没有据此认证原生 WebView 安装生效、实时 IM 或整篇长正文的人工逐字阅读体验。

剩余风险是服务端冷读取、结构化未知临时故障仍可能重新读取，以及原 App 安装采用尚待完成。它们应沿现有所有者和安全激活流程继续，不是扩大本 PR、代办原业务或取消已接收任务的理由。正式合并仍以当前 head 的合并准备检查及既有授权为准。

English verdict: APPROVE 9b1e524 — verified-prefix recovery passes the old-defect counterexample, real HTTP negatives and packaged automatic-recovery journey. Native installation and live business completion remain outside this review's proven boundary.

[huangruiteng]

合并决策：精确 head 9b1e52458f479c9725797c11b69a7a676008ab09 已有完整模型自审 5817118891，正文独立读回及结果检查通过。正式构建、原 HTTP 正反例、旧 reader 反例和打包恢复均已核验；精确 head premerge 的 5 项直接检查、18 项选择检查无失败，三张图片的原始人工门禁由本次像素、来源和 metadata 审阅补足。

合并准备检查保留 ready=false：唯一 blocker 为 GitHub 的 REVIEW_REQUIRED 策略状态；当前 head 仍 OPEN/MERGEABLE，review 结论有效、没有未解 review thread。本次按维护者已授权的修复自合并路径使用 admin bypass，仅跨过该审批策略门禁，不豁免精确审查、验证或权限。远端 CI 按 wait_for_ci=false 未查询。合并后走既有正常更新入口；原生 App 生效和真实业务补答仍保留为待验收。

[huangruiteng]

验收数值更正：公开 fixture 的 "Original full body. ".repeat(1000) 实际是 20,000 个原始字符，此前说明、README 和自审中的 19,000 是计数误记。测试断言的是整个 repeat(1000) 正文，未截断或减少比较；464 条记录、两次断线恢复、来源拒绝和无业务写入的观察均不变。正文长度应以 fixture 表达式为准；README 的数字笔误保留为原文档收尾项。已安装包与所审源码的历史读取文件已独立比对一致，原 Chat 的安全激活和真实业务补答验收仍未完成。