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
1.22.0: delivered_to proven wrong-in-both-directions vs names; numeric version compare; cross-machine page placement
3 files changed
+37−3
package.json+1−1@@ -1,6 +1,6 @@ { "slug": "adom-ui-design",- "version": "1.21.0",+ "version": "1.22.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/dock-dashboard/SKILL.md+23@@ -94,6 +94,29 @@ So: **Ralph-test:** list every HTTP surface your app serves. If more than one of them renders something a user would call "the dashboard", you have this bug. +### Which MACHINE serves the page is a design decision, and only one direction works++If your app's real UI runs on the DESKTOP (a bridge, a native helper) rather than in the+container, merging is a cross-machine job, not a "move the regions" job. Measured on pup,+2026-08-24, and the asymmetry decides it for you:++- The container **CAN** reach a desktop port (`curl 127.0.0.1:8851/health` → 200 under+ mirrored WSL2 networking).+- The desktop **CANNOT** reach a container port (a browser window opened on one comes up+ empty).++So **serve the merged dashboard from the DESKTOP**: one URL then works for both the webview+and the dock's health poll. Any design that puts the page in the container and calls out to+the bridge fails the moment the webview tries to load it. The container-side helper's whole+job becomes resolving and printing that desktop URL.++**Consequence to plan for:** anything that lived in the container helper cannot be called by+a desktop-served page. On pup that was the scripted demo runner, so its demo now hands the+demo script to a fresh AI thread through the send path instead. For an app whose whole point+is that you ASK rather than click, that is arguably the more honest demo; for an app whose+demo drives its own UI, keep the scripted runner and serve it from the same machine as the+page. Decide deliberately rather than discovering it.+ ### And verify on the instance the DOCK runs, not the one you develop against There are usually TWO INSTALLS of your app: the copy you develop against (your cloud
skills/say-strip/SKILL.md+13−2@@ -112,7 +112,9 @@ released build that contains it**. Everything before that, including the widely- So the send path checks the shell's version first: - **Read the version from `GET /updater/status` → `updater.current_version`** and require- `>= 1.0.142`. That is the ONLY endpoint that exposes a release version; `/health` and+ `>= 1.0.142`, **comparing NUMERICALLY, never lexically** (a string compare passes+ `1.0.99`, which is older and still carries the crash). That is the ONLY endpoint that+ exposes a release version; `/health` and `/buildinfo` carry only `build_sha` / `build_epoch` / `build_local` / `build_stamp`, `/version` returns an endpoint list, and the shell page has no version global. (Verified live on 2026-08-24 after one app concluded no version was readable and removed its gate,@@ -198,7 +200,16 @@ copy-fallback covers genuine failure, so give the call room to succeed first. **Surface the `_hints` text directly in your failure toast** rather than inventing your own wording; it is written to tell the user what actually happened. -**Verify delivery by `delivered_to`, never by the thread's name.** Staged names can lag or+**Verify delivery by `delivered_to`, never by the thread's name.** Both halves of this were+observed on 2026-08-24, an hour apart, which is why it is a correctness rule and not a+preference:++| What you saw | What was true |+|---|---|+| A perfectly NAMED tab ("Pup - say it"), `delivered_to` null | Nothing was typed into it. The send FAILED. |+| An UNNAMED tab, no `dock:` tag anywhere in the census, `delivered_to` truthy | The prompt was delivered. The send SUCCEEDED. |++A name-based check reports the wrong verdict in both directions. Staged names can lag or miss entirely when the composite ADOPTS an existing idle empty tab rather than opening a fresh one (fresh opens attach fine). The name is cosmetic; `delivered_to` is the proof.