[Systemofdumb]

Implements #29. Seven commits on main.

Each tab owns an EditorStore for as long as it is open — created when the tab opens, dropped when it closes, never on a switch. Switching remounts the view over the other tab's existing store via the store prop, so it is an attach rather than a re-parse, and undo history, selection and scroll survive it.

The registry is a plain Map on the tab store rather than part of its state: that state goes through immer, which freezes, and a frozen EditorStore is an inert one. Nothing renders from the map, so it does not need to be reactive.

It removed more than it added — the markdown-serialising bridge, the docEpoch generation counter, the flush-save on switch, the manual scroll save/restore, and the save-handle threading are all gone. Tab is down to id, meta, dirty and two disk-staleness fields.

Your list

Tab bar renders nothing at all with a single tab — not hidden, absent, so the flex column never allots the row. A one-document window is identical to before tabs existed.

Per-tab dirty and untitled state reported to Rust. update_tabs carries path, dirty, and content — the last only for tabs that are dirty AND never saved, since those are the only ones the sheet could be asked to review. One helper answers "does this window hold work no autosave will ever write?", and all three gates consult it: CloseRequested, the queue dirty_untitled_labels builds, and the per-window recheck inside the quit review. A window can no longer close over unsaved work in a tab you cannot see.

Close flow. ⌘W with two or more tabs closes the active tab; on the last tab it goes through the ordinary window close, so the native sheet stays the single authority — and it now sees every tab.

Shortcuts and menus. ⌘N opens a tab, ⇧⌘N a new window, both as menu entries with en/zh/ja labels. Navigation is ⌘⇧[ / ⌘⇧] only, matched on code as you asked; ⌘1–⌘9 are gone and nothing claims ⌘T.

The close prompt, per your spec: an in-app modal with Don't Save / Cancel / Save, Escape cancelling and Enter defaulting to Save, with the sheet's grouping. Window close and quit still go through the native sheet.

Readiness, as you asked

Both activate-tab emit sites now clear WindowReady, and the frontend asserts readiness once the document is in place — through one markReady helper used by every route into the window.

The part that makes clearing safe on that route is asserting it even when nothing changed. Rust cannot tell "switch to a background tab" from "re-activate the tab already showing"; previously clearing on the second case would have left the CLI waiting for a mark no remount would produce, which is why the route cleared nothing at all. The host now marks ready unconditionally, so the ambiguity stops mattering.

Measured that specific risk rather than assuming it: re-opening the already-active tab and inserting immediately completes in 0.05s with the text landing correctly — not the ~5s a stranded readiness wait would cost.

Being straight about what I could not show: I could not get the underlying race to reproduce on either build. Two domd-cli invocations are slower than the tab switch, so open followed by insert lands correctly with and without this change. The fix is therefore correct by construction and verified not to strand, rather than demonstrated against a failing baseline. If you have a tighter way to drive the socket, that gap is worth closing.

Background sync stays out, as agreed — additive once the registry exposes the per-tab stores.

Verification

Harnesses: verify-block-format 188, verify-ai-blocks 100, verify-scroll-store 14, verify-tab-runtime 5 — all passing. tsc clean for app and kernel, cargo check clean, and eslint output byte-identical to main (59 files, same counts).

The close modal has its own suite driven in both WebKit and Chromium — 18 assertions covering Don't Save closing the tab, Cancel keeping it and returning focus to the editor, Escape cancelling, and repeated prompt/cancel cycles leaving exactly one editor shell.

That last assertion exists because of a bug worth flagging for the file rather than the diff: I first keyed the modal by the tab being closed, which is the same value that keys DOMDProvider (version is the active tab id). Closing the active tab put two siblings under one key, and React mounted a second editor shell without removing the first — two stacked documents, no error, since the duplicate-key warning is development-only. The modal is unkeyed now, with a comment saying why.

Re-ran your Backspace harness against this branch after rebasing: alive on both engines, in the plain web build and with the tabbed desktop path booted.

Still macOS-only testing — no Windows or Linux machine here, so those paths remain unexercised.

[vercel]

@Systemofdumb is attempting to deploy a commit to the do-md's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Systemofdumb]

Pushed a fix for a regression this branch introduced, caught in daily use rather than by any of my tests.

Double-clicking a .md while the app was closed opened an empty Untitled document instead of the file. Every other route was fine — opening one while the app was already running, domd-cli open, and passing the path as an argument all worked, which is exactly why it survived this long.

A cold Finder open is the only route where nothing is listening yet: setup creates an empty window, RunEvent::Opened lands while the webview is still booting, and the open-file-in-tab emit arrives before the frontend has registered for it.

main survives that because its reuse path writes the window's assigned document into WindowFiles before emitting, and the frontend's first act is to ask get_my_path what it is meant to show. I kept the emit and dropped the write, so the answer was null and the window blanked itself. The event was never the durable half of that handshake — the entry was.

Restored, before the emit. The two converge rather than compete: addTab dedupes on path, so a window that both hears the event and reads the entry activates one tab, not two.

Verified on a built app across every route — cold Finder open loads the file, warm Finder open adds a tab, re-opening a file already in a background tab activates it with the right content, domd-cli open unchanged, and a plain launch with no file still opens blank.

Worth saying plainly: none of my harnesses would have caught this. They drive the frontend directly and never exercise a cold launch, so the window where the emit can be missed does not exist for them. Worth a look at whether that gap is worth closing more generally, since it is the same shape as the readiness race we discussed — state that only exists as an in-flight event is state a slow boot can lose.