Adom UI Design System

@@ -1,6 +1,6 @@ {   "slug": "adom-ui-design",-  "version": "1.16.0",+  "version": "1.17.0",   "type": "skill",   "description": "The Adom UI Design System plus a bundle of focused UI skills (tooltips, floating-windows, toasts, responsive-ui, app-shell, ai-driven-apps, clickable-paths, dark-default, input-feedback, settings-layout). One install drops the whole set of skill files onto your container, plus shared icon assets (the settings cog) so every Adom app draws the same glyph.",   "dependencies": {},

@@ -81,6 +81,27 @@ broken - is ALWAYS carried by the led tokens, never by a brand color alone. - **toasts** - bottom-center, success green / error red / info teal. - **pup-taskbar-progress** (bridge-side) - long AI work shows an indeterminate taskbar bar. +## Dashboards are FLUID: never hardcode a max-width on the page++A dock dashboard fills the surface it is given, at every width: a 700px webview pane, a+1400px pane, a maximised browser at 2500px. **No `max-width` on the page container, the app+shell, or the panel.** John's ruling, 2026-08-24, on a dashboard that left a dead band of+background on a wide browser: *"its like they hard coded their max width or something. that+goes against our ui design skills."*++A dashboard is an APP SURFACE, not an article. Native apps fill their window; a capped,+centered column with empty background either side reads as a broken page rather than a+considered one.++- Layout adapts with grid/flex, `minmax()`, and percentage or `fr` columns, so extra width+  becomes more room for the content that benefits (tables, results, viewers).+- If a block of PROSE needs a reading measure, cap that block (`max-width: 70ch`), never the+  layout around it.+- Fixed pixel widths belong only to things that are genuinely fixed: an icon, a 220px control+  column, a sidebar. Never to the page.+- Test at a very wide viewport, not just at pane width. The cap is invisible until someone+  maximises.+ ## Every layout change is tested in BOTH panel states  The newbie panel opens and closes, so your dashboard has TWO layouts, and the closed one is

@@ -54,7 +54,14 @@ instead of the boxes around them. - `background: var(--surface)`, `border: 1px solid var(--line)`,   `border-left: 3px solid var(--teal)`, `border-radius: 12px`. - `padding: 18px 20px 20px`. Outer margin `16px 0 20px`.-- Inner content `max-width: 1180px`, centered, so phrases stay scannable on a 32in monitor.+- **NO max-width on the panel or its inner container. It fills the width it is given, at+  every width.** (John's ruling, 2026-08-24, seeing a dashboard leave dead space on a wide+  browser: "its like they hard coded their max width or something. that goes against our ui+  design skills.") An earlier version of this skill said `max-width: 1180px` centered; that+  is RETIRED. A dashboard is an app surface, not an article: it fills its window the way a+  native app does, and a hard cap leaves a band of empty background that reads as broken.+- If a specific TEXT block needs a reading measure, cap THAT BLOCK (`max-width: 70ch` on the+  explainer paragraph), never the layout around it. Constrain prose, never the page.  **Panel heading and explainer** - Heading: the literal `Say it`, Familjen Grotesk 600, **15px**, `var(--text)`.@@ -188,7 +195,8 @@ panel must not shift anything except the panel's own footprint.  ## Ralph-test -At 1400px: panel spans the content width, two columns with the hairline between them, every+At 1400px AND at 2500px: panel spans the FULL width with no dead band on either side, two+columns with the hairline between them, every row exactly 40px, phrases truncating rather than wrapping, one filled button on the page. At 390px: one column, demo first, icons still in a 44px target. Hover both icons and read the tooltips; click each and watch for the toast. Press `✕`, confirm the panel is GONE with no stub and the app UI moves up, reload, confirm