← Commit history

1.22.0: delivered_to proven wrong-in-both-directions vs names; numeric version compare; cross-machine page placement

John Lauer ·18963192b1 ·1mo ago ·parent 5caf3a5
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.