Fix Portfolio archive template, mobile menu, and header UI issues

assets/css/animations.css

@@ -1505,6 +1505,44 @@
   padding-top: var(--wp--preset--spacing--20);
 }
 
+/*
+ * Side padding: .mobile-menu used to get this for free via the Group block's own "constrained"
+ * layout (which adds .has-global-padding and self-applies the root padding vars). Switching that
+ * layout to "flow" — done to stop the accordion rows getting centered to the site's content-size
+ * at desktop editor widths, a mismatch the plain-paragraph link rows didn't share — dropped this
+ * along with it. Reapplying explicitly here, on the same spacing token the header already uses
+ * for its own padding, rather than depending on the layout-type side effect again.
+ */
+.mobile-menu {
+  padding-inline: var(--wp--preset--spacing--20);
+}
+
+/*
+ * The Navigation block has no backgroundColor of its own, so it never gets core's
+ * .has-background class — which means core's own fallback (wp-includes/blocks/navigation/style.css)
+ * hardcodes this overlay to a literal #fff in every mode. Overriding it here with the same
+ * adaptive token the rest of the page's background already uses (light/dark aware) instead of a
+ * fixed value.
+ *
+ * Selector must mirror core's own ".wp-block-navigation:not(.has-background) ..." ancestor
+ * (not just scope under .site-header) — core's rule has 5 class-level selectors, so anything
+ * with fewer loses regardless of stylesheet order. Matching that shape plus .site-header wins.
+ */
+.site-header .wp-block-navigation:not(.has-background) .wp-block-navigation__responsive-container.is-menu-open:not(.disable-default-overlay) {
+  background-color: var(--wp--custom--color--surface--canvas);
+}
+
+/*
+ * Same issue, text side: core has a mirror rule keyed off .has-text-color that hardcodes this
+ * wrapper to a literal #000 whenever the Navigation block has no textColor of its own. Elements
+ * inside the mobile-menu template part escape it because they each set their own explicit
+ * color — but core's own close button relies on `currentColor` inherited from this wrapper, so
+ * it was stuck on literal black. Same adaptive token, same specificity-matching shape.
+ */
+.site-header .wp-block-navigation:not(.has-text-color) .wp-block-navigation__responsive-container.is-menu-open:not(.disable-default-overlay) {
+  color: var(--wp--custom--color--text--default);
+}
+
 .site-header .wp-block-navigation__responsive-container-close {
   position: absolute;
   top: var(--wp--preset--spacing--20);
@@ -1611,7 +1649,13 @@
   display: flex;
   align-items: center;
   min-block-size: 3rem;
-  font-family: var(--wp--preset--font-family--heading);
+  /*
+   * No font-family override here — inherit the body default (Manrope) so this matches the
+   * accordion rows' <summary> and inner items, none of which set a font-family either. This
+   * previously hardcoded the heading font (Lexend) instead, which — sharing the same
+   * min-block-size box but with different font metrics — made these rows look inconsistently
+   * padded against the accordion rows even though the box model was identical.
+   */
   font-size: var(--wp--preset--font-size--200);
   font-weight: var(--wp--custom--typography--font-weight--semibold);
   color: var(--wp--custom--color--text--default);
@@ -1810,6 +1854,17 @@
   }
 }
 /********** Site Header **********/
+/*
+ * The header's own top/bottom padding (spacing token 20) is symmetric — 14px both sides. But
+ * the root layout's blockGap (spacing token 30, ~20px) applies as margin-top on whatever section
+ * follows the header, stacking with the header's own bottom padding (14px + 20px = 34px) against
+ * just the header's 14px above. Targeting "whatever follows .site-header" rather than any one
+ * section by name makes this apply everywhere the header appears, not just the homepage.
+ */
+.site-header + * {
+  margin-block-start: 0;
+}
+
 /*
  * Below core/navigation's own native overlay-menu breakpoint (core WP hardcodes this at
  * `min-width: 600px` in wp-includes/blocks/navigation/style.css — mirrored here as the
@@ -1825,6 +1880,20 @@
     display: none;
   }
 }
+/*
+ * Below the nav's own `mobileMenuBreakpoint` (1024, matching the "tablet-landscape" breakpoint),
+ * core/navigation collapses to a single hamburger toggle. With the header row's own
+ * `justifyContent:"space-between"` and 3 top-level items (logo, nav, actions), the hamburger
+ * — now much narrower than the full nav — lands wherever equal-gap math puts it, which is close
+ * to dead centre, not next to the actions group where it visually belongs. Scoping the fix to
+ * this breakpoint only (rather than restructuring the header's markup) keeps the desktop nav's
+ * spacing exactly as designed and only changes the collapsed state.
+ */
+@media (max-width: 1023.98px) {
+  .site-header .wp-block-navigation {
+    margin-inline-start: auto;
+  }
+}
 /*
  * Header icon buttons (search, light/dark toggle) and the gradient CTA. The base circular-button
  * shell (border/background/sizing) matches styles/blocks/groups/header-icon-button.json — kept

parts/mobile-menu.html

@@ -1,4 +1,4 @@
-<!-- wp:group {"className":"mobile-menu","layout":{"type":"constrained"}} -->
+<!-- wp:group {"className":"mobile-menu","layout":{"type":"flow"}} -->
 <div class="wp-block-group mobile-menu"><!-- wp:group {"className":"mobile-menu-brand","layout":{"type":"flex","flexWrap":"nowrap","verticalAlignment":"center"}} -->
 <div class="wp-block-group mobile-menu-brand"><!-- wp:site-logo /--></div>
 <!-- /wp:group -->

src/scss/animations/_header-motion.scss

@@ -3,6 +3,17 @@
 
 /********** Site Header **********/
 
+/*
+ * The header's own top/bottom padding (spacing token 20) is symmetric — 14px both sides. But
+ * the root layout's blockGap (spacing token 30, ~20px) applies as margin-top on whatever section
+ * follows the header, stacking with the header's own bottom padding (14px + 20px = 34px) against
+ * just the header's 14px above. Targeting "whatever follows .site-header" rather than any one
+ * section by name makes this apply everywhere the header appears, not just the homepage.
+ */
+.site-header + * {
+  margin-block-start: 0;
+}
+
 /*
  * Below core/navigation's own native overlay-menu breakpoint (core WP hardcodes this at
  * `min-width: 600px` in wp-includes/blocks/navigation/style.css — mirrored here as the
@@ -19,6 +30,21 @@
   }
 }
 
+/*
+ * Below the nav's own `mobileMenuBreakpoint` (1024, matching the "tablet-landscape" breakpoint),
+ * core/navigation collapses to a single hamburger toggle. With the header row's own
+ * `justifyContent:"space-between"` and 3 top-level items (logo, nav, actions), the hamburger
+ * — now much narrower than the full nav — lands wherever equal-gap math puts it, which is close
+ * to dead centre, not next to the actions group where it visually belongs. Scoping the fix to
+ * this breakpoint only (rather than restructuring the header's markup) keeps the desktop nav's
+ * spacing exactly as designed and only changes the collapsed state.
+ */
+@include mq.mq($until: "tablet-landscape") {
+  .site-header .wp-block-navigation {
+    margin-inline-start: auto;
+  }
+}
+
 /*
  * Header icon buttons (search, light/dark toggle) and the gradient CTA. The base circular-button
  * shell (border/background/sizing) matches styles/blocks/groups/header-icon-button.json — kept

src/scss/animations/_mobile-menu-motion.scss

@@ -22,6 +22,46 @@
   padding-top: var(--wp--preset--spacing--20);
 }
 
+/*
+ * Side padding: .mobile-menu used to get this for free via the Group block's own "constrained"
+ * layout (which adds .has-global-padding and self-applies the root padding vars). Switching that
+ * layout to "flow" — done to stop the accordion rows getting centered to the site's content-size
+ * at desktop editor widths, a mismatch the plain-paragraph link rows didn't share — dropped this
+ * along with it. Reapplying explicitly here, on the same spacing token the header already uses
+ * for its own padding, rather than depending on the layout-type side effect again.
+ */
+.mobile-menu {
+  padding-inline: var(--wp--preset--spacing--20);
+}
+
+/*
+ * The Navigation block has no backgroundColor of its own, so it never gets core's
+ * .has-background class — which means core's own fallback (wp-includes/blocks/navigation/style.css)
+ * hardcodes this overlay to a literal #fff in every mode. Overriding it here with the same
+ * adaptive token the rest of the page's background already uses (light/dark aware) instead of a
+ * fixed value.
+ *
+ * Selector must mirror core's own ".wp-block-navigation:not(.has-background) ..." ancestor
+ * (not just scope under .site-header) — core's rule has 5 class-level selectors, so anything
+ * with fewer loses regardless of stylesheet order. Matching that shape plus .site-header wins.
+ */
+.site-header .wp-block-navigation:not(.has-background)
+  .wp-block-navigation__responsive-container.is-menu-open:not(.disable-default-overlay) {
+  background-color: var(--wp--custom--color--surface--canvas);
+}
+
+/*
+ * Same issue, text side: core has a mirror rule keyed off .has-text-color that hardcodes this
+ * wrapper to a literal #000 whenever the Navigation block has no textColor of its own. Elements
+ * inside the mobile-menu template part escape it because they each set their own explicit
+ * color — but core's own close button relies on `currentColor` inherited from this wrapper, so
+ * it was stuck on literal black. Same adaptive token, same specificity-matching shape.
+ */
+.site-header .wp-block-navigation:not(.has-text-color)
+  .wp-block-navigation__responsive-container.is-menu-open:not(.disable-default-overlay) {
+  color: var(--wp--custom--color--text--default);
+}
+
 .site-header .wp-block-navigation__responsive-container-close {
   position: absolute;
   top: var(--wp--preset--spacing--20);
@@ -138,7 +178,13 @@
     display: flex;
     align-items: center;
     min-block-size: 3rem;
-    font-family: var(--wp--preset--font-family--heading);
+    /*
+     * No font-family override here — inherit the body default (Manrope) so this matches the
+     * accordion rows' <summary> and inner items, none of which set a font-family either. This
+     * previously hardcoded the heading font (Lexend) instead, which — sharing the same
+     * min-block-size box but with different font metrics — made these rows look inconsistently
+     * padded against the accordion rows even though the box model was identical.
+     */
     font-size: var(--wp--preset--font-size--200);
     font-weight: var(--wp--custom--typography--font-weight--semibold);
     color: var(--wp--custom--color--text--default);

theme.json

@@ -731,13 +731,6 @@
             "postTypes": [
                 "page"
             ]
-        },
-        {
-            "name": "page-work-archive",
-            "title": "Work Archive",
-            "postTypes": [
-                "page"
-            ]
         }
     ]
 }