Adom UI Design System - Commit

Overview Files Skills Discover Packages Releases Dependencies Issues2 Breadcrumbs Pull Requests2 Activity

1.28.0: empty delivered_to is NOT failure (it is a diff that lags); accept delivered_in_conversation and add an opened-unconfirmed state

John Lauer ·48da328d54 ·1mo ago ·parent 4bcfea9

2 files changed +23−2

package.json+1−1 skills/say-strip/SKILL.md+22−1

package.json+1−1

@@ -1,6 +1,6 @@ {   "slug": "adom-ui-design",-  "version": "1.27.0",+  "version": "1.28.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/say-strip/SKILL.md+22−1

@@ -200,7 +200,28 @@ 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.** Both halves of this were+**Verify delivery by `delivered_to` OR `inject.delivered_in_conversation` — and NEVER treat+an empty `delivered_to` as failure.** (Corrected 2026-08-25 after it produced a false failure+on a live send.) `delivered_to` is a DIFF, not a guess: the API's own hint says it is "empty+if verification has not caught up", so a send that genuinely delivered can return it empty+for a moment. An app that reads `delivered_to` alone reports FAILURE on a working send and+then copy-fallbacks on top of a prompt the user already received.++Three states, not two:++| Signal | State | What the user sees |+|---|---|---|+| `delivered_to` non-empty, or `inject.delivered_in_conversation: true` | DELIVERED | success toast |+| Call succeeded (`ok: true`) but neither confirms yet | **OPENED, UNCONFIRMED** | a neutral "sent, still confirming" toast. NEVER an error, NEVER a copy-fallback |+| Call failed, or an explicit error | FAILED | error toast plus the copy fallback, surfacing the API's `_hints` verbatim |++The live case that forced this (kicad, 2026-08-25): first send returned `delivered_to: []`+and the app called it failure, while the raw body showed+`inject: {delivered_in_conversation: true, submitted: true, typed: "open the symbol in+kicad", targeting: "webview-identity"}`, `ok: true`, `adopted_empty_tab: true`. It had+worked.++**And 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: