Remember the window's size and position

[vmillet-dev]

Closes #11.

tauri-plugin-window-state — the plugin, not a hand-rolled persistence through PreferencesService. It brought one crate with it and no transitive dependency, which is well under "more than it is worth"; and doing it in the front end would mean restoring the geometry after Angular boots, so the window would visibly jump on every launch.

The flags are the whole ticket

The plugin's default is StateFlags::all(), and all() includes VISIBLE. With closeToTray on — which is the default — quitting from the tray saves a window that is hidden, and the next launch restores it hidden: an application that starts with nothing on screen and only a tray icon to be found by. That is the trap the ticket warns about, and taking the plugin's default would have walked straight into it.

So WINDOW_STATE_FLAGS is SIZE | POSITION | MAXIMIZED, named and commented, with a unit test that holds VISIBLE out — a comment cannot fail a build. DECORATIONS and FULLSCREEN are left out for the opposite reason: nothing in DevBox changes either, so saving them stores noise.

The other half of the ticket's warning needs nothing from us. A minimized window on Windows reports itself at -32000, and the plugin already guards it: both its Moved and its Resized handlers skip a minimized window, and update_state skips size and position when minimized or maximized. Confirmed by reading the plugin rather than by hoping.

Worth knowing: the file is written on RunEvent::Exit, not on every move. The tray's "Quitter" is app.exit(0), so it goes through; a force-kill writes nothing and leaves the previous geometry standing, which is the right answer for a crash.

First launch

tauri.conf.json is now only a first launch. 800×600 was the ticket's own complaint — narrow for a grid of minmax(220px, 1fr) cards — so it is 1100×720, with minWidth/minHeight of 640×480. The floor is not decoration: it is what stops a saved geometry, or a drag, from bringing the window back at a size nothing fits in.

Verified on the assembled application

This is not reachable from the e2e suite — reopenSession() is explicitly not a restart, the process hosts the WebDriver server and must stay up, so "quit and launch again" cannot be expressed there. Same reason 15-preferences-on-disk reads its file from Node. So it was checked by hand, against the real binary:

step	result
fresh profile, first launch	1116×759 outer — the new 1100×720 client area
moved and resized to 980×640 at 240,130, then quit	.window-state.json written: 964×601 at 240,130 (client area)
launched again	980×640 at 240,130 — identical
closed to the tray, then launched again	980×640 at 240,130 — unchanged, one process, revealed by single-instance
"visible": false forced into the state file, then launched	window appears anyway — the flag is genuinely not consulted

That last row is the trap, demonstrated rather than argued.

Checked

• cargo test — 169 + 34 + 83 + 14 + 10 passing, including the new flag guard. cargo clippy --all-targets -- -D warnings, cargo fmt --check — clean.
• npm test — 937 passing. npm run lint — clean.
• Full e2e — 15/15 green. Run deliberately, because the default window size changed and every spec's viewport with it.

docs/architecture.md gains a "Window geometry" section next to the tray; CLAUDE.md gains the VISIBLE trap.