← Commit history

2.10.1 (doc only): parse for what you decide, never for what you hand back; prove the per-request read by booting against a dead URL

John Lauer ·0a29e94664 ·1mo ago ·parent 0b3b935
2 files changed +35−1
package.json+1−1
@@ -1,6 +1,6 @@ {   "slug": "adom-ui-design",-  "version": "2.10.0",+  "version": "2.10.1",   "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+34
@@ -131,6 +131,22 @@ already-running app, but prefer `--app-cmd`: the `--base` mode works only becaus URL is read at REQUEST time, so **an app that caches the URL at startup silently tests nothing.** Exits non-zero on any RED. +**TO PROVE THE PER-REQUEST READ RATHER THAN ASSERT IT** (parts-search's method, and stronger+than either mode alone): start your app with `~/.adom/hydrogen-control-url` pointing at a port+with **nothing listening on it**, then let the harness repoint the file at its stub while the+process keeps running.++```+app up against the dead URL   -> 200+harness repoints the file     -> PASS / PASS / PASS+file restored afterwards+```++**A startup-pinned URL cannot pass that**: it would still be talking to a closed port.+`--app-cmd` alone cannot distinguish per-request from pinned-at-startup, because the file is+already correct when the app boots. This is the difference between "I read the code and it+looks per-request" and a falsifiable result.+ **It cannot create a thread in John's list.** The POST assertion sends `submit:false` and only ever to its own stub, never to a real control API. @@ -142,6 +158,24 @@ It checks three things, and all three are failures a 200-probe sails past: | a non-200 status survives (upstream 207 returned as 207) | a hand-built `200 {ok:true}` wrapper | | an unproxied path under the same prefix returns YOUR 404 | blanket-proxying the control API | +**PARSE FOR WHAT YOU DECIDE. NEVER PARSE FOR WHAT YOU HAND BACK.** parts-search's rule, from+fixing its own route: it still parses the upstream JSON for its own decisions, and forwards+the response bytes untouched with the `Content-Type` carried through. Those are two different+jobs and only one of them is allowed to re-serialise.++**The harness caught the app that INVENTED this pattern**, which is the strongest thing that+can be said for it. parts-search wrote the first same-origin proxy in the fleet and was RED on+assertion 1, with damage worse than the negative control's: its route parsed into a serde+`Value` and re-emitted, and serde's map is ordered, so the round trip **alphabetised the+keys** at both levels. `updater` moved to the end and `build` moved ahead of `current_version`+inside it. Same JSON, different bytes, different reading order for anything that streams or+diffs it.++**And the asymmetry in which route failed is the usual distribution:** its POST already+returned the upstream status, because it had written that one deliberately while hunting+phantom send failures. The GET was the one with a hand-written `200` beside it. **The route+someone thought about carefully was fine; the one-liner next to it was not.**+ Run this before spending a slot. A round trip through his box tells you less and costs more.  **Run `--self-test` first, every time.** Its negative control is a proxy whose only sin is one