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.10.1 (doc only): parse for what you decide, never for what you hand back; prove the per-request read by booting against a dead URL
2 files changed
+35−1
package.json+1−1@@ -1,6 +1,6 @@ { "slug": "adom-ui-design",- "version": "2.10.0",+ "version": "2.10.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": {},
skills/newbie-panel/SKILL.md+34@@ -131,6 +131,22 @@ already-running app, but prefer `--app-cmd`: the `--base` mode works only becaus URL is read at REQUEST time, so **an app that caches the URL at startup silently tests nothing.** Exits non-zero on any RED. +**TO PROVE THE PER-REQUEST READ RATHER THAN ASSERT IT** (parts-search's method, and stronger+than either mode alone): start your app with `~/.adom/hydrogen-control-url` pointing at a port+with **nothing listening on it**, then let the harness repoint the file at its stub while the+process keeps running.++```+app up against the dead URL -> 200+harness repoints the file -> PASS / PASS / PASS+file restored afterwards+```++**A startup-pinned URL cannot pass that**: it would still be talking to a closed port.+`--app-cmd` alone cannot distinguish per-request from pinned-at-startup, because the file is+already correct when the app boots. This is the difference between "I read the code and it+looks per-request" and a falsifiable result.+ **It cannot create a thread in John's list.** The POST assertion sends `submit:false` and only ever to its own stub, never to a real control API. @@ -142,6 +158,24 @@ It checks three things, and all three are failures a 200-probe sails past: | a non-200 status survives (upstream 207 returned as 207) | a hand-built `200 {ok:true}` wrapper | | an unproxied path under the same prefix returns YOUR 404 | blanket-proxying the control API | +**PARSE FOR WHAT YOU DECIDE. NEVER PARSE FOR WHAT YOU HAND BACK.** parts-search's rule, from+fixing its own route: it still parses the upstream JSON for its own decisions, and forwards+the response bytes untouched with the `Content-Type` carried through. Those are two different+jobs and only one of them is allowed to re-serialise.++**The harness caught the app that INVENTED this pattern**, which is the strongest thing that+can be said for it. parts-search wrote the first same-origin proxy in the fleet and was RED on+assertion 1, with damage worse than the negative control's: its route parsed into a serde+`Value` and re-emitted, and serde's map is ordered, so the round trip **alphabetised the+keys** at both levels. `updater` moved to the end and `build` moved ahead of `current_version`+inside it. Same JSON, different bytes, different reading order for anything that streams or+diffs it.++**And the asymmetry in which route failed is the usual distribution:** its POST already+returned the upstream status, because it had written that one deliberately while hunting+phantom send failures. The GET was the one with a hand-written `200` beside it. **The route+someone thought about carefully was fine; the one-liner next to it was not.**+ Run this before spending a slot. A round trip through his box tells you less and costs more. **Run `--self-test` first, every time.** Its negative control is a proxy whose only sin is one