ElyOffice/tasks/reviews/R4.12-r1.md

FAIL

1. `crates/ely-platform/src/instance/door.rs:131`：鉴权尚未完成就发送所有 `PATH` 和 `DONE`，而接收端遇到错误令牌立即返回并关闭仍有未读数据的连接。连接重置会先于 `REFUSED` 被客户端读到，`hand` 第 90 行的 `?` 随即退出，旧门文件的重试失效。Windows 原有 `a_wrong_token_hands_nothing_over` 测试实跑失败，单独重复 12 次失败 5 次；探针把旧令牌在 100 毫秒后恢复为正确值，Windows 5/5、Linux 4/5 次交接仍提前失败，远未到 10 秒期限。修复方向：发送路径前完成明确的鉴权确认，让鉴权阶段的断连可以安全重试，保留路径发送后不重试的约束。证据：`.work/R4.12-r1/token-repeat.log`、`protocol-windows.log`、`protocol-linux.log`。

2. `crates/ely-ui/src/opening.rs:92`：剩下的第一个窗口未必是文档主窗口，接收文件的回调也可能仍指向已关闭的主窗口。Windows 真窗口复现：打开 ElyMark 设置，关闭文档主窗口，保留设置窗口，再启动第二份打开 `third.md`；第二份退出 0，第一份只显示设置窗口，文件未开成标签，日志报 `ely-office::open: window not found`。修复方向：主窗口关闭后不能继续把交接确认为成功并派给失效窗口；交接时重建有效主窗口及其打开回调，或让主窗口关闭时结束残留进程，使下一次启动能正常打开文件。证据：`.work/R4.12-r1/main-closed-results.log`。

3. `crates/ely-ui/src/opening.rs:78`：`Ask::Raise` 的唯一消费者依赖应用调用 `on_open`，但 ElyMail、ElyAgent 使用的 `ely_ui::blank` 从不调用它；这两个应用收到交接后只将请求积在队列中，却仍回复成功。Windows 真窗口分别将 ElyMail、ElyAgent 最小化，再无参数启动第二份：两次都退出 0，但原窗口仍最小化且未到前台。修复方向：在每个应用必经的启动路径安装前台请求的消费者，不让窗口激活依赖文件打开订阅。证据：`.work/R4.12-r1/window-results.log`。

4. `crates/ely-platform/src/instance/door.rs:57`：五秒 `read_timeout` 限制单次阻塞读取，不限制整个鉴权请求；第 47–48 行又在唯一接收线程上串行处理连接。没有令牌的本地进程可以发送一个未完成的 TOKEN 帧并持续少量补字节，长期占住接收线程，使正常实例交接超时。Windows、Linux 探针均在未鉴权连接每 500 毫秒发送一个字节、已占用超过六秒后发起正常交接，正常客户端再等约五秒即失败；关闭该连接后交接立即恢复。修复方向：给未鉴权请求设置不可被零星输入续期的整体截止时间，确保它不能持续阻塞后续合法交接，并加入对应回归。证据：`.work/R4.12-r1/protocol-windows.log`、`protocol-linux.log`。