← Commit history

1.18.0: the release version IS readable at /updater/status (never build_sha or build_epoch); prompt actions track the phrase, not the window edge

John Lauer ·4da18cb6d0 ·1mo ago ·parent 12be9c3
3 files changed +18−7
package.json+1−1
@@ -1,6 +1,6 @@ {   "slug": "adom-ui-design",-  "version": "1.17.0",+  "version": "1.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+7−1
@@ -94,7 +94,13 @@ instead of the boxes around them. - Phrase cell: **14px** body face, `var(--text)`, in curly quotes, the noun in `var(--teal)`,   `white-space: nowrap; overflow: hidden; text-overflow: ellipsis;` so a long phrase   truncates rather than wrapping and breaking the row rhythm. Full text in its `title`.-- Action cell: fixed **72px**, right-aligned, holding the two icon buttons with `gap: 6px`.+- Action cell: fixed **72px**, holding the two icon buttons with `gap: 6px`. **The actions+  track the PHRASE, not the far edge of the window.** Lay the row out as+  `grid-template-columns: max-content 72px` (or `auto 72px` with the row's content+  left-packed) so the buttons sit just after the text they act on. Filling the width is+  right; a row whose Copy button ends up 2000px from its phrase on a wide monitor is not+  (spotted by pup at a 2500px viewport, 2026-08-24). The TABLE still spans the full width:+  it is the row's internal packing that keeps label and action together. - 3 to 6 rows. More than six is a menu, not an invitation.  **The two icon buttons**
skills/say-strip/SKILL.md+10−5
@@ -111,11 +111,16 @@ released build that contains it**. Everything before that, including the widely-  So the send path checks the shell's version first: -- **Compare the release VERSION (>= 1.0.142). Never `/buildinfo`'s `build_sha` field**, which-  lies on incremental builds: `build.rs` caches `HD_BUILD_SHA`, so a freshly compiled exe can-  report an older commit. (This cost a false conclusion on 2026-08-24; the honest fallback is-  a code-marker string search in the installed binary, which is not something a dashboard can-  do at runtime, hence: use the version.)+- **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+  `/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,+  and another found this endpoint and shipped the gate correctly. Do not re-derive this.)+- **NEVER gate on `build_sha`**, which lies on incremental builds (`build.rs` caches+  `HD_BUILD_SHA`, so a fresh exe can report an older commit), and **never on `build_epoch`**,+  which is actively harmful: it pins the feature to one machine's incremental build clock, so+  every user on a stock signed release, whose epoch is older, is refused forever. - On a pre-1.0.142 shell, refuse honestly and fall back to copy: error toast reading   something like *"Send to AI needs Hydrogen 1.0.142 or newer. Copied the phrase instead."*   Never attempt the send on an unfixed shell; a crash costs the user their whole session.