Adom UI Design System

@@ -1,6 +1,6 @@ {   "slug": "adom-ui-design",-  "version": "1.36.0",+  "version": "1.36.1",   "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": {},

@@ -86,15 +86,20 @@ instead of the boxes around them.    | App | `innerWidth` |   |---|---|-  | project-manager | **632** |+  | project-manager | 632 |   | fusion | 744 |   | nb | 744 |-  | parts-search | **851** |+  | 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.+  ⚠ **THAT TABLE WAS AN ARTIFACT AND IS RETRACTED.** Those readings were taken from tabs that+  were NOT foregrounded, which return zero heights and unresolved specified values rather+  than errors. Re-measured with each tab activated first, **every dashboard reports 744**:+  there is ONE pane, not three. The lesson is the one directly above (activate, then measure),+  and the table is kept only as the evidence of how convincing bad readings look.++  Users can still split panes, so treat pane width as something to MEASURE per session rather+  than a constant — just do not cite this table as proof that they do.    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