← Commit history

1.35.0: delivered_to is an array; mocks built from your own assumption cannot falsify it; test sends use a no-op prompt

John Lauer ·c1f206be46 ·1mo ago ·parent dbf1158
2 files changed +24−2
package.json+1−1
@@ -1,6 +1,6 @@ {   "slug": "adom-ui-design",-  "version": "1.34.0",+  "version": "1.35.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+23−1
@@ -205,6 +205,25 @@ that then landed late and stacked orphan tabs.) A short client timeout turns a w into a spurious "could not reach the AI panel", which was half of the original bug. The copy-fallback covers genuine failure, so give the call room to succeed first. +**`delivered_to` IS AN ARRAY.** Parse it as one. fusion parsed it with `as_str()`, so a+delivery that SUCCEEDED reported `ok: false` — which is the most dangerous shape of wrong,+because the honest-looking retry it invites is a double-send into the user's editor. Accept+array, string and nested forms, and **put the panel's RAW RESPONSE in your failure path** so+the next person can diagnose the shape without sending a second prompt to find out.++**A MOCK BUILT FROM YOUR OWN ASSUMPTION CANNOT FALSIFY THAT ASSUMPTION.** fusion had five+green mock cases certifying a feature that failed every time live, because its mock returned+`current_version` at the top level for the same wrong reason its parser looked for it there+(it is nested under `updater`), and returned `delivered_to` as a string for the same reason+its parser called `as_str()`. Three bugs in one round, each verified against something the+author wrote from the belief being tested. **Build mocks from OBSERVED payloads**, captured+off the real API, not from your reading of the docs.++**WHEN TESTING A SEND, SEND A NO-OP PROMPT.** fusion used "no action needed, please ignore+and do nothing" rather than a real say-phrase. That judgement is why its double-send cost+John two ignored lines instead of driving Fusion twice. Real phrases are instructions; a test+send is not the moment to discover that.+ **⛔ A TIMED-OUT SEND MAY HAVE DELIVERED. NEVER RE-SEND TO FIND OUT.** nb double-submitted into John's thread on 2026-08-25 and the mechanism will catch anyone driving a send through a short-timeout transport: it sent through `hd_api /eval-in`, which ABANDONS AFTER 5 SECONDS@@ -216,7 +235,10 @@ Two rules fall out:  1. **After a timeout, the census can never clear you.** Only `delivered_to` or    `inject.delivered_in_conversation` can. A tag lookup is exactly the check that lies when a-   send adopts an existing tab, which is the common case.+   send adopts an existing tab, which is the common case. **If you must check the editor+   itself, check the TRANSCRIPT CONTENT for your prompt text** — never tags, never labels.+   Two apps double-sent on 2026-08-25 by trusting a tag lookup, the second one after being+   warned about the first. 2. **Do not drive the send through a transport with a shorter timeout than the send.**    `/eval-in` gives you 5s for a call that legitimately takes up to 120. Call your backend    directly with a real timeout (e.g. `wsl_exec curl -m 180` inside the user's container) so