Style tooling surfaces within shared shell

docs/tables_frontend_overhaul_implementation_plan.md

@@ -30,7 +30,7 @@ It is intentionally implementation-focused:
 
 - Branch: `frontend/tables-overhaul`
 - Last updated: `2026-03-21`
-- Current focus: `Phase 1`
+- Current focus: `Phase 2`
 - Document mode: living plan and progress log
 
 ### Progress Log
@@ -45,6 +45,7 @@ It is intentionally implementation-focused:
 | 2026-03-21 | P1.5 | Completed | Replaced the permanent sidebar layout with a sticky top app shell and mobile bottom navigation backed by dedicated shell components. |
 | 2026-03-21 | P1.6 | Completed | Added explicit shell slots for nav, omnibox, shortcuts, and utilities; switched shell navigation to `Play`, `Tables`, `Curation`, and `Tools`; and wired the first live theme control into the shell. |
 | 2026-03-21 | P1.7 | Completed | Added a shell-level skip link and tightened the top-level header, navigation, and main landmarks around the new shell structure. |
+| 2026-03-21 | P1.8 | Completed | Introduced a cooler tooling emphasis for `Tools`, diagnostics, and API surfaces, and styled the `Tools` destination as distinct without splitting the shell. |
 
 ### Lessons Learned
 
@@ -59,6 +60,7 @@ It is intentionally implementation-focused:
 - Extracting shell markup into dedicated components is lower-risk than continuing to evolve `MainLayout.razor` directly. It isolates responsive frame work from page content and keeps later nav changes localized.
 - Once a Razor component exposes multiple named `RenderFragment` parameters, the page body must be passed explicitly through `<ChildContent>`. That pattern is now the baseline for shell composition here.
 - Accessibility work is cheaper when the shell owns the landmarks. Adding skip links and nav/main structure at the shell layer avoids repeating that work page by page.
+- Tooling can feel distinct through cooler surfaces and labeling alone. A separate app shell is unnecessary and would undermine the shared-product goal.
 
 ## Target Outcomes
 
@@ -254,7 +256,7 @@ Create the implementation foundation so the visual overhaul does not start with
 
 ### Status
 
-`In progress`
+`Completed`
 
 ### Task Progress
 
@@ -267,7 +269,7 @@ Create the implementation foundation so the visual overhaul does not start with
 | `P1.5` | Completed | The sidebar is gone; pages now render inside a sticky top-shell with a mobile bottom nav. |
 | `P1.6` | Completed | The shell now has explicit nav, omnibox, shortcut, and utility slots, plus a live theme selector and destination-model navigation. |
 | `P1.7` | Completed | The shell now exposes a skip link and explicit header/nav/main landmarks. |
-| `P1.8` | Pending | Tools-specific shell emphasis is final Phase 1 polish. |
+| `P1.8` | Completed | Tooling surfaces and the `Tools` nav item now use a cooler emphasis without leaving the shared shell system. |
 
 ### Goal
 
@@ -330,6 +332,12 @@ Establish the shared shell, tokens, typography, and theme system that every dest
 - primary navigation shows `Play`, `Tables`, `Curation`, and `Tools`
 - the app has a stable theme system and global spacing/typography rules
 
+### Phase 1 Exit Notes
+
+- The app now has a semantic token system, explicit typography roles, theme modes with persistence, and a responsive shell.
+- The shell already uses the destination model `Play`, `Tables`, `Curation`, and `Tools`, even though deeper route migration remains a Phase 2 concern.
+- The next implementation focus is Phase 2: shared route compatibility, recents, pins, omnibox foundations, and deep-link infrastructure.
+
 ## Phase 2: Shared Navigation, Search, And State Infrastructure
 
 ### Goal