diff --git a/AGENTS.md b/AGENTS.md
index 7087a75..45aab19 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -339,10 +339,15 @@ are no component-level AGENTS.md files.
   (`toolbar(removing: .title)`, gated: the `.title` kind is macOS 15, so 14 gets
   an empty `navigationTitle`) so the name is not drawn twice. The `Window` scene
   keeps its real name for the Window menu and the Dock, and that name lives
-  beside the version in `MonitorVersion`. **The trailing controls need
-  `.primaryAction`, not `.automatic`** — they used to be pushed right by the
+  beside the version in `MonitorVersion`. **The trailing controls need a
+  `ToolbarSpacer`, not just a placement** — they used to be pushed right by the
   title taking the slack in the middle, and removing it packed them up against
-  the stamp. The styling is deliberately not the panel's palette or the cards' monospaced face.
+  the stamp. A macOS toolbar packs its items left to right after the navigation
+  slot, so `.primaryAction` names where an item belongs without reserving any
+  room to push it there; naming the placement and calling it fixed was the first
+  attempt and it changed nothing on screen. `ToolbarSpacer` is macOS 26, so
+  below that a Spacer in the `.principal` slot stands in — untested, since the
+  machine this is developed on runs 26. The styling is deliberately not the panel's palette or the cards' monospaced face.
   It is the one thing in the window that is not a reading: everything else is a
   measurement styled to be scanned, and this is a label on the photograph, there
   to survive being screenshotted and read back later. macOS 26 wraps toolbar
diff --git a/Sources/MonitorUI/DashboardView.swift b/Sources/MonitorUI/DashboardView.swift
index 514d595..7759949 100644
--- a/Sources/MonitorUI/DashboardView.swift
+++ b/Sources/MonitorUI/DashboardView.swift
@@ -545,12 +545,22 @@ public struct DashboardView: View {
         } else {
             ToolbarItem(placement: .navigation) { buildStamp }
         }
-        // `.primaryAction` rather than the default `.automatic`. The controls
-        // used to be pushed to the trailing edge by the window's title taking
-        // the slack in the middle; with the title removed, `.automatic` packed
-        // them up against the stamp on the left. Anchoring them explicitly says
-        // what the layout actually depends on, instead of leaning on something
-        // that is no longer there.
+        // The controls used to be pushed to the trailing edge by the window's
+        // title taking the slack in the middle. Removing the title took that
+        // with it, and **placement alone does not bring it back**: a macOS
+        // toolbar packs its items left to right after the navigation slot, so
+        // `.primaryAction` names where an item belongs without reserving any
+        // room to push it there. It needs an actual space.
+        //
+        // `ToolbarSpacer` is that space and it is macOS 26. Below 26 a Spacer
+        // in the centre slot is the nearest equivalent — untested, since the
+        // only machine this is developed on runs 26, so it is deliberately the
+        // fallback rather than the path everything takes.
+        if #available(macOS 26.0, *) {
+            ToolbarSpacer(.flexible)
+        } else {
+            ToolbarItem(placement: .principal) { Spacer() }
+        }
         ToolbarItem(placement: .primaryAction) {
             Picker("History", selection: $window) {
                 Text("1 min").tag(TimeInterval(60))
diff --git a/docs/ui.md b/docs/ui.md
index 17ae875..4b0a88d 100644
--- a/docs/ui.md
+++ b/docs/ui.md
@@ -967,9 +967,18 @@ notices until a screenshot.
 Removing the title cost the toolbar something that was not obvious until it was
 gone: the title was taking the slack in the middle, and it was that, not the
 items' own placement, pushing the History picker and the size and rate controls
-to the trailing edge. Without it `.automatic` packed them up against the stamp.
-They are `.primaryAction` now, which says what the layout actually depends on
-rather than leaning on something that is no longer there.
+to the trailing edge. Without it they packed up against the stamp.
+
+**Placement alone does not bring it back.** Moving them to `.primaryAction` was
+the first attempt and it changed nothing on screen: a macOS toolbar packs its
+items left to right after the navigation slot, so a placement names where an
+item belongs without reserving any room to push it there. What was removed was
+a *space*, and only a space replaces it — `ToolbarSpacer(.flexible)` between the
+stamp and the controls.
+
+That is macOS 26, so below it a `Spacer` in the `.principal` slot stands in.
+Untested: the only machine this is developed on runs 26, which is why it is the
+fallback and not the path everything takes.
 
 It is in the title bar rather than in the About panel because of how the app gets
 used — a monitor is left running for days, and the