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.14.0 (doc only): publish the successor's address not just its position; a predecessor that predates the feature cannot test the feature
2 files changed
+16−1
package.json+1−1@@ -1,6 +1,6 @@ { "slug": "adom-ui-design",- "version": "2.13.0",+ "version": "2.14.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+15@@ -1082,6 +1082,13 @@ Verifying inside ah means driving John's laptop, and two threads driving it at o crashed it. So the shell is handed out one thread at a time. The handoff protocol that actually holds: +- **The coordinator must publish the next holder's ADDRESS, not just its position.** The rule+ below assumes the holder can address its successor, and in this fleet it could not: peers+ appear as opaque handles with nothing mapping a handle to an app. fusion released correctly+ and then could not complete the direct half, and it refused to guess, because messaging the+ wrong thread "the shell is yours" is worse than messaging none: it hands a shared machine to+ someone who was not waiting for it. **A protocol step nobody can execute degrades silently+ to the thing it replaced.** - **The releasing thread messages the coordinator AND the next thread directly.** fusion started a pass on the coordinator's word alone, because project-manager released to the coordinator and never messaged fusion. That works until one message is delayed, and then two@@ -1151,6 +1158,14 @@ pid N -> gone **Both halves matter.** The mismatch must restart AND the match must not: an upgrade step that restarts every time is a different bug wearing the same green tick. +**⛔ A PREDECESSOR THAT PREDATES THE FEATURE CANNOT TEST THE FEATURE.** fusion retired two real+predecessors in one pass and then declined to call its retirement proven, correctly: the older+one predates the supersession-retirement code, so it could never have stood down on its own+and had to be retired by hand. **The path that matters — a current build retiring ITSELF+unattended — is still untested until a build that HAS the code is the one being replaced.**+Killing an old process proves your killer works; it does not prove the thing you shipped+works. Record which half you actually exercised.+ parts-search rehearsed exactly this before its slot and found its predecessor does publish the pid in the expected shape. An accident made its test harder than the real case, which is worth copying: its old and new binaries sat at DIFFERENT paths while on John's box both are