Adom UI Design System

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

@@ -1148,6 +1148,15 @@ Verifying inside ah means driving John's laptop, and two threads driving it at o crashed it. So the shell is handed out one thread at a time. The handoff protocol that actually holds: +- **THE COORDINATOR IS THE REGISTRY, AND A RELEASE IS NOT COMPLETE UNTIL IT SAYS SO.** Telling+  the next holder fixed the telling, not the TRACKING: two threads later, both had released+  and each believed the other held it, and the coordinator was reconstructing the state from+  two messages that disagreed. **Reconstructing who holds a shared machine is the same class+  of error as inferring it.** A thread that has released should say so in the same words every+  time; the coordinator confirms the machine is genuinely idle before handing it on, and the+  next holder starts only on an explicit handover naming it. nb's position is the correct one+  to copy: *"hand it to me explicitly and I will treat that message as the handover; I will not+  start on an inference that it is free."* - **The coordinator must publish the next holder's ADDRESS, not just its position.** The rule   below assumes the holder can address its successor, and in this fleet it could not: peers   appear as opaque handles with nothing mapping a handle to an app. fusion released correctly@@ -1215,6 +1224,11 @@ That is the fact worth more than the retraction, because it is not one person's |---|---|---| | `span.clientWidth - span.scrollWidth` | `scrollWidth` is `max(clientWidth, content)`, so it saturates | **yes** — retains some value | | `cell.rect.width - span.rect.width` | a BLOCK span fills its containing block, so the rects are equal for ANY text | **no** — no diagnostic value at all |++**They are one bug with two spellings**, which is nb's sharper statement of it: **both measure a+BLOCK element's width against its container, and that IS the container's width by definition.**+Neither can detect overflow in either direction for the reason that they are not measuring the+text at all. Only a probe that lays the text out unconstrained can. | the offscreen `nowrap` probe | (correct) | reports true slack, 141–180px here |  The second is strictly worse than the first and **agreed with it for an entirely unrelated