Adom UI Design System

@@ -1,6 +1,6 @@ {   "slug": "adom-ui-design",-  "version": "1.35.0",+  "version": "1.36.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,9 +81,24 @@ instead of the boxes around them.   **760px → 620px → 700px.** The first correction fixed the wrong quantity measured the wrong   way; the second came from measuring the thing CSS actually sees. -  **PANE WIDTH IS NOT VIEWPORT WIDTH.** A 744px dock pane contains a **632px viewport**, so-  620 cleared the real number by 12px rather than the 124 I thought. Measure-  `window.innerWidth` from INSIDE your own page, never the pane.+  **THERE IS NO SINGLE PANE WIDTH.** Measured across all five dashboards open in one user's+  ah at the same moment, every one of them a direct child frame:++  | App | `innerWidth` |+  |---|---|+  | project-manager | **632** |+  | fusion | 744 |+  | nb | 744 |+  | parts-search | **851** |+  | pup | 851 |++  Users split panes, drag dividers and rearrange, so the "dock pane width" is a RANGE that+  changes during a session, not a constant to design against. Two apps reported 744 and 632+  for what they each called "the dock pane" and both were right; they were in different panes.++  So **the breakpoint has to serve the whole range**, and 700 does: the 632 pane collapses to+  one readable column, while 744 and 851 get two. Measure `window.innerWidth` from INSIDE+  your own page to know where YOU are, but never assume your reading is the fleet's.    And at 632 the two-column layout loses the thing the strip exists for. Measured on nb's   live page in a real browser at forced viewports, reading `scrollWidth` vs `clientWidth` per