Adom UI Design System

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

@@ -372,6 +372,16 @@ ever sees the case that motivated it is a check nobody has watched go red. | a wrapper adding 40px on top of a correct mount div | **red** | | no gutter anywhere | **red** | +**THE TABLE IS THE DELIVERABLE, NOT THE FIX.** pup's point, and it is why 2.5.0 held where+2.3.0 and 2.4.0 did not: anyone can write a check that passes the case that motivated it. What+makes a check trustworthy is the enumerated list of cases it was run against, including the+ones it must REJECT. Ship the matrix with the rule.++And note where two of those five cases came from: **the outer-container page and the app-shell+scroller were both written down only because an app pushed back instead of complying.** Nobody+here would have enumerated them a day earlier. A fleet that argues produces a better test+suite than a fleet that obeys.+ **⛔ WHEN A CHECK FAILS, ASK WHETHER IT IS FAILING THE CORRECT IMPLEMENTATIONS.** pup's framing, and it is the sharpest hazard on this page: a check that is wrong at random is noise, but a check that is systematically wrong about the WELL-BUILT cases actively teaches the fleet