skill
Adom UI Design System
Public Made by Adomby adom
How the AI builds and tests interfaces people love to use in Adom. Ships as one installable skill that bundles focused skills (tooltips, floating-windows, toasts, responsive-ui, app-shell, ai-driven-apps, clickable-paths).
← Commit history
2.18.0 (doc only): current is three separate claims; put a positive control on a clean result; two 3px and 11px margins at his width
2 files changed
+42−1
package.json+1−1@@ -1,6 +1,6 @@ { "slug": "adom-ui-design",- "version": "2.17.0",+ "version": "2.18.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": {},
skills/newbie-panel/SKILL.md+41@@ -1170,6 +1170,47 @@ actually holds: The general form, worth more than the panel: **on a shared resource, a handoff is not complete when the holder lets go. It is complete when the next holder has been told, by the holder.** +## ⛔ "CURRENT" IS THREE SEPARATE CLAIMS, AND ANY ONE OF THEM CAN LIE ALONE++parts-search hit all three in a single slot:++| claim | how it lies |+|---|---|+| **the INSTALLED version** | `pkg install` succeeded, so the binary on disk is new |+| **the RUNNING process version** | the old process is still serving: 2.0.7 installed, **2.0.3 running** |+| **the version the DOCUMENT has** | `open-or-refresh` reported success while the page **stayed on module 2.1.1** |++Only a reload from inside the page moved the third one. So verifying an install proves the+first, `/api/status` proves the second, and **only `AdomNewbiePanel.version` read out of the+live document proves the third.** Report all three or you are reporting one and implying the+others.++## Two margins at John's width, neither a defect today, both worth watching++parts-search measured these on his box and flagged them rather than reporting a clean pass:++- **THE PANEL IS 702px AGAINST A 699px COLLAPSE THRESHOLD. Three pixels.** Pane 744, scroller+ client box 734 (a 10px scrollbar), panel 702. **A 13px scrollbar instead of 10 collapses that+ dashboard to one column with nothing in its code changing.** The container query is measured+ on a box a platform detail contributes to, so the margin is not entirely ours.+- **The longest phrase is 332px in a 343px box: 11px of headroom**, on "check ESP32-S3-WROOM-1+ stock". The 0-of-6 is real and it is not comfortable.++At his width the two-column layout is close to its limit on BOTH axes. Nothing to change+today; something to check first if a dashboard ever renders one column unexpectedly.++## ⛔ PUT A POSITIVE CONTROL ON A CLEAN RESULT, NOT ONLY A NEGATIVE ONE ON A CHECK++parts-search has reported "0 of 6 truncating" on this exact question before, when the truth was+2 of 6, by measuring the cell instead of the clipping span. **All six spans returning an+identical 343 is what a dead instrument looks like.** So before believing the clean result it+lengthened one span in place and watched `scrollWidth` go 343 -> 823 -> 343. **It responds to+text, therefore the reading is real.**++The distinction is worth holding: a NEGATIVE control proves a check can fail. A POSITIVE+control proves a measurement is still connected to the thing it measures. **Its wrong version+of that number looked exactly like its right one**, and only the poke told them apart.+ ## FIRST: WHICH LIFECYCLE IS YOUR DASHBOARD ON? THEY ARE NOT THE SAME PROBLEM. **A container-served dashboard** runs as its own process. `pkg install` replaces the binary and