Adom UI Design System

@@ -1,6 +1,6 @@ {   "slug": "adom-ui-design",-  "version": "2.10.1",+  "version": "2.11.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": {},

@@ -1090,6 +1090,40 @@ actually holds: The general form, worth more than the panel: **on a shared resource, a handoff is not complete when the holder lets go. It is complete when the next holder has been told, by the holder.** +## ⛔ REHEARSE YOUR UPGRADE AGAINST YOUR REAL PREDECESSOR. THE INPUT IS THE OLD BUILD'S OUTPUT.++Since the dock installs without restarting (below), every app needs a `serve` that RETIRES the+running instance. Almost every app will have tested that against itself and therefore tested+only the idempotent branch.++**The retirement path's input is the OLD build's output**, so it cannot be tested by reading+the new build's source. It reads a pid out of a state file **the old binary wrote**, then+refuses to kill unless `/proc/<pid>/cmdline` matches the argv it expects. Two silent failures+are reachable only against a real predecessor: the old build might not publish a pid at all,+or might publish a different argv shape. Either way there is no kill, the port stays held, and+`ensure` returns "port is held by a server I could not stop" — **on John's machine, in a slot,+after the queue has waited for you.**++**Fetch your own predecessor from the registry and rehearse the real upgrade**, in a throwaway+`HOME` on a spare port. No shell, no quota, about two minutes:++```+<old> serve --port 89xx      -> OK: started (vOLD), pid N+<new> serve --port 89xx      -> WARN: running instance is OLD, this is NEW; restarting+/api/status                  -> NEW+pid N                        -> gone+<new> serve again            -> OK: already running (vNEW), same pid, NO restart+```++**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.++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+`~/.local/bin/<tool>`, and it still matched, because the comparison is on the argv[0] TAIL+with the rest exact. **So the tolerant part and the strict part were both exercised.**+ ## ⛔ THE DOCK INSTALLS A PACKAGE. IT DOES NOT RESTART THE RUNNING PROCESS.  **Publishing is not deploying, and installing is not running.** lbr found John's box serving