@@ -10,10 +10,24 @@ Current release checkpoint (September 30, 2026): **1.0.0 is published and instal
 
 Checkpoint (September 30, 2026). Shadowfetch Linux 5.0 QA found two window defects in the installed 1.0.0 (KDE Plasma on Wayland, in a VM):
 
-- **The window grew on every launch**, by about 52 px in width and 99 px in height (1380 px wide at the first launch, 1484 px at the third, then pinned to the top of the screen). On Wayland tao gives the window a GTK header bar (client-side decorations). `tauri-plugin-window-state` 2.4.1 saved the inner size from GTK's configure event, which includes the header bar and the shadow margins, and restoring it through `gtk_window_resize` added them again. The plugin now keeps every flag but `SIZE` (`window_size::REMEMBERED`): position, maximized, visibility, decorations and full screen are still restored. A size saved by 1.0.0 is ignored, so a window that already grew recovers at the next launch.
-- **The default window (1380x920) was larger than a 1366x768 screen**, so the composer and status bar sat under the panel. The main window (`create: false`, built in code) now takes its first size from the screen it opens on: at most 90% of the screen, never more than its work area, less 48 px for the title bar (on Plasma the panel and the header bar are 46 px each). That gives 1229x643 on 1366x768 and leaves 1380x920 unchanged on 1920x1080. A screen that cannot hold the 520x640 minimum opens the window maximized. GTK on Wayland names no primary monitor (`gdk_display_get_primary_monitor` returned none on this host) and lets the compositor place the window, so there the smallest screen counts. The size is set before the window exists and the plugin restores a saved maximized state afterwards, so the fit never undoes it.
+- **The window grew on every launch**, by about 52 px in width and 99 px in height (1380 px wide at the first launch, 1484 px at the third, then pinned to the top of the screen). On Wayland tao gives the window a GTK header bar (client-side decorations). `tauri-plugin-window-state` 2.4.1 saved the inner size from GTK's configure event, which includes the header bar and the shadow margins, and restoring it through `gtk_window_resize` added them again. The plugin now keeps every flag but `SIZE` (`window_size::REMEMBERED`) on every desktop: maximized, full screen, visibility, decorations and position are still restored, the position only on X11 (GDK ignores `gtk_window_move` for a Wayland toplevel, so the compositor places the window). A size saved by 1.0.0 is ignored, so a window that already grew recovers at the next launch.
+- **The default window (1380x920) was larger than a 1366x768 screen**, so the composer and status bar sat under the panel. The main window (`create: false`, built in code) now takes its first size from the screens it opens on (`window_size::opening` and `fit_config`): at most 90% of the screen, never more than its work area. On X11 48 px are kept for the window manager's title bar, which is outside the inner size: 1229x643 on 1366x768 with a 46 px panel. On Wayland GTK's header bar is inside the size the window asks for (1.0.0's 1380x920 window measured 920 px with its 47 px header bar on Plasma; under Weston a 1380x920 window has 873 px of content), so nothing is taken off: 1229x691 on 1366x768, about 644 px of content. 1920x1080 keeps 1380x920. On X11 the screen is the one the window-state plugin moves the window back to (its saved record, read with the plugin's own rule), or else the primary monitor where Tauri centers it, and right after the plugin's move a window that would cross that screen's work area is moved inside it. On Wayland the compositor places the window, so it fits every screen and opens maximized only when none of them holds the 520x640 minimum. The size is set before the window exists and the plugin restores a saved maximized state afterwards, so the fit never undoes it.
 
-Verification before tagging 1.0.1: `cargo test --workspace --locked` (as the `native-source` gate runs it) 1469 passed / 0 failed / 14 ignored, including 10 new `window_size` tests; clippy clean except vendored glib; UI 715 unit and 111 Playwright tests; release, publisher, signing, release-auth, installer and packaging script suites 300 tests (299 passed; one packaging-environment test skipped: no cached linuxdeploy) plus `test-install-appimage.sh`; `appstreamcli validate --strict` passes, and the widened trust policy parses with the verifier's own parser (same key and epoch, range 0.33.0–1.0.1). The debug binary under Xvfb, with private home, XDG directories and D-Bus so the window-state plugin was active, opened at 1229x643 centered on a 1366x768 screen in three launches in a row, with the position kept and no size saved; on 1920x1080 it opened at 1380x920 although a saved 1.0.0 state said 1484x1019. Not checked here: a Wayland launch (this host has no Weston or WebKitWebDriver), so the growth fix itself is to be confirmed on KDE Plasma (Wayland) in the Shadowfetch Linux 5.0 VM with the packaged 1.0.1.
+Verification before tagging 1.0.1 (first round, on `45b0d53`): `cargo test --workspace --locked` (as the `native-source` gate runs it) 1469 passed / 0 failed / 14 ignored, including 10 new `window_size` tests; clippy clean except vendored glib; UI 715 unit and 111 Playwright tests; release, publisher, signing, release-auth, installer and packaging script suites 300 tests (299 passed; one packaging-environment test skipped: no cached linuxdeploy) plus `test-install-appimage.sh`; `appstreamcli validate --strict` passes, and the widened trust policy parses with the verifier's own parser (same key and epoch, range 0.33.0–1.0.1). The debug binary under Xvfb, with private home, XDG directories and D-Bus so the window-state plugin was active, opened at 1229x643 centered on a 1366x768 screen in three launches in a row, with the position kept and no size saved; on 1920x1080 it opened at 1380x920 although a saved 1.0.0 state said 1484x1019. That round ran no Wayland launch; the review round below did.
+
+### 1.0.1 review round
+
+A review of `45b0d53` raised ten findings, all confirmed against the code and fixed:
+
+- **The X11 fit used the primary monitor** (two findings), while the plugin then restores the window onto the screen it was closed on, which can be a smaller one (a docked laptop's 1366x768 panel). Fixed as described above, with the move inside the work area.
+- **The smallest Wayland screen forced a maximized window everywhere**, which the user could not undo (the plugin only ever maximizes). Now only when no screen holds the minimum.
+- **The title bar room was taken twice on Wayland** (header bar inside the size). Fixed; the old `a_1366x768_screen_fits_above_its_panel` test had built in the wrong model.
+- **Wording**: the changelog and release notes promised position memory on Wayland and the notes' heading said the window keeps its size; NATIVE_DESKTOP said window geometry is retained. Reworded: no size on any desktop, maximized and full screen everywhere, the place on X11 only.
+- **No 1.0.0 upgrade fixture** although 1.0.0 is published. Generated by the 1.0.0 engine (`node scripts/generate-upgrade-fixtures.mjs v1.0.0`, schema 27, the same as 1.0.1); `upgrade_fixtures` 3 passed. Generator snippets for 1.0-era data (spending limits, the rulebook) are not added yet.
+- **Nothing tested that the app wires the plugin and the fit**: unit tests passed with 1.0.0's plugin registration. `test-native-desktop.mjs` now plants the state a grown 1.0.0 window left (1536x1170, placed low), checks the fitted first window (and the X11 place, moved inside the screen), and after the quit relaunches and expects the same size although the window was left at 1360x860. Against a build that restores `SIZE` again it fails at its first check under both Xvfb and Weston (1536x1170).
+- **The ledger said this host has no Weston or WebKitWebDriver.** Wrong: unpacked Weston 13 and WebKitWebDriver 2.52.6 (matching the system WebKit) work through `SHADOW_WESTON`, `SHADOW_WESTON_LIBRARY_PATH`, `SHADOW_WESTON_MODULE_MAP` and `SHADOW_WEBKIT_DRIVER`.
+
+Verification after the review (fixes on `077930b`; no VM running and load below 8 before every build and gate; Node 22.23.2, because the default `node` here is 22.11, older than the 22.12 the scripts need, and `test-native-cli.mjs` then stops at `node:sqlite`; window and Node gates with a private `HOME` and `PATH` reduced to that Node and the system directories): `cargo fmt --check` and `clippy --workspace --all-targets -D warnings` clean; `cargo test --workspace --locked` (the `native-source` run) 1475 passed / 0 failed / 14 ignored, with 16 `window_size` tests (run with the real home: a private home on a long path makes `sandbox_isolation`'s socket path too long for a Unix socket); `native-behavior` (`test-native-cli.mjs` 21 scenario groups, `test-native-stress.mjs` 100/100, `test-native-tui.mjs`, the MCP server over stdio and HTTP); `glib-backport` 9/9 and 6/6; `release-tests` 176 + 2 and `release-auth` 59 with no secrets found; `built-project-cleanup` 1/1 (15,504 entries); `native-window` under `run-native-x11.mjs`: `test-native-desktop.mjs` 31 checks (first window 1296x920 on the 1440x1100 Xvfb screen at the saved place moved inside, 132 px from the top; the same after the relaunch) and `test-native-markdown.mjs`; `native-endurance` 100/100 with 32 checks; and `run-native-wayland.mjs node scripts/test-native-desktop.mjs` 31 checks on a private Weston (1380x873 content on 1600x1100, the same after the relaunch). Probes of three launches each from a planted 1536x1170 state (resized to 1000x700 before the second quit): a private Weston at 1600x1100 gives 1380x873 content every time, one at 1366x768 gives 1229x644 (a 1229x691 window), and Xvfb gives 1296x920 at the same place each time. Not run here: `managed-runtime`, `packages`, `clean-host-packages` and `packaged-behavior` (they need the Vulkan llama.cpp build and Docker; left to CI). The one remaining physical-desktop check is KDE Plasma (Wayland) in the Shadowfetch Linux 5.0 VM with the packaged 1.0.1.
 
 ## 1.0 program