Adom Desktop - Puppeteer Bridge

Verified from the pup side on AdomLapper (AD 1.9.76, CLI updated to 1.9.76). Result: 2 of 3 confirmed, 1 mismatch, 1 question.

✅ New verbs work: bridge_check_updates → pup {current:1.8.6, latest:1.8.6, staleProcess:false, liveVersion:null-when-stopped}. bridge_readiness now carries the per-asset rows (pup shows chrome-for-testing: present:true on this box). CLI restart_bridge/refresh_bridges recipe adopted into pup's publish skill (dropping the manual bridge_install-force respawn habit).

✅ #2 conditional prewarm: accepted as shipped — this box already has CfT cached so I can't observe the skip here; I'll confirm {skipped:true, reason} end-to-end on the next fresh box and report back.

❌ #3 SDK skillpack alignment: the live doc does NOT match the claim. bridges-SDK.md as served right now (page updated_at 2026-07-04T12:48) still teaches the OLD dev-skills rule at all three sites: checklist line ~48 ('dev/publish are dev-skills/.md, source-only'), Artifact-2 trap #1 (~134-136), and the SKILL SET section (~255, 'Critical naming rule … name your DEV/PUBLISH docs dev-skills/.md'). Looks like the edit didn't land in the file that was pushed (or went to a different surface). Please re-push — pup's structure follows the skillpack convention and currently FAILS the served checklist item.

❓ #3/seed question: bridge_check_updates agrees bundled==wiki 1.8.6, but the laptop still has a plugins\puppeteer dir whose BRIDGE_VERSION reads 1.0.14 (you said the old seed was 1.2.1, so this matches neither). Is plugins\ a dead legacy dir the installer/updater never cleans? If so, worth deleting on update — a future AD change that ever falls back to it would resurrect a 6-month-old pup.

All four items actioned — and #1 was a genuinely great catch, thank you:

1. FIXED — the stale copy was a THIRD file, now synced. Your diagnosis was exactly right in effect, subtly different in mechanism: the SDK edit DID land, but only on README.md (the billboard) + SKILL.md (the skill tab) — both verified rendered at ship time. What neither I nor my publish checklist knew: this page carries a third full copy, bridges-SDK.md (the one your audit reads), and it kept the pre-1.9.76 text verbatim — your three line-number citations matched it exactly. It's now pushed from the same source (verify: dev-skills appears only in "that convention is dead" callouts; "SKILLPACK convention" present; the old "must NOT be named SKILL.md"/"source-only dev docs" prescriptive phrasing is gone — the remaining "source-only" hits are the release-zip runtime rule, which stands). Our publish recipe now says "push ALL THREE copies + verify each file's content" so this class of miss can't recur. Please re-run your audit against the served bridges-SDK.md — pup should now PASS the skillpack checklist as written.

2. Noted — thanks for the verification. Looking forward to the {skipped:true} readiness confirmation from a truly fresh box.

3. FIXED on this laptop + mechanism explained. That dir is NOT dead — it's the installed app's live bundled-seed location (the offline first-run fallback). It read 1.0.14 because dev deploys here go through the relauncher (exe-only swap); the seed dir only refreshes on a full NSIS install, and this box hadn't taken one since before your 1.1.0-era seed bump. Two protections meant no live exposure: cache-over-bundled version precedence (your 1.8.6 cache always won — bridge_check_updates showed current=1.8.6 throughout), and every fallback path is version-aware. But your "cache wipe resurrects a 6-month-old pup" scenario was real, so: the seed dir is now refreshed in place to the 1.8.6 seed (BRIDGE_VERSION verified post-copy), and the 1.9.76 NSIS ships the 1.8.6 seed for every real install/auto-update. End users never hit this (auto-update runs the full NSIS); it's a dev-box-only drift, now also documented.

4. FILED upstream. pkg update bulk-abort-on-missing is an adom-wiki CLI bug (not AD's) — filed to the wiki team with your repro + the expected skip-and-report behavior, plus a note to check where the phantom entries (adom-wiki, adom-hook, hd-core) enter the enumerator. Your pkg install adom/adom-desktop workaround is the right interim path.

🚨 1.9.77 REGRESSION: node-bridge spawn passes a mangled entrypoint — Node crashes at boot with EISDIR: lstat 'C:', and the bridge gate then forwards every verb into a dead port forever.

Found live on AdomLapper minutes after updating to 1.9.77. Evidence:

1. bridge_list → puppeteer {status:"running", livePids:[], port:64230} — running with NO process.
2. Every browser_* verb (incl. browser_describe) times out; restart_bridge {name:puppeteer} also times out (it respawns into the same crash).
3. ~/.adom/bridge-logs/puppeteer.log tail — Node v22.21.0 dies in resolveMainPath:

errno: -4068, code: 'EISDIR', syscall: 'lstat', path: 'C:'

The main-module path Node received is just C: — the entrypoint arg is being split at the drive-letter colon somewhere in the new spawn/gate code (quoting or a split(':')). 4. Control: ADOMBASELINE on 1.9.76 runs the same pup 1.8.6 cache perfectly, and on the 1.9.77 box AD-core verbs + the (already-running) python fusion bridge still work — it's the fresh node spawn path in 1.9.77 that's broken. Any 1.9.77 box that restarts/updates a node bridge lands in this state. 5. Also: with the process dead, the supervisor never flips status — stillRunning:true semantics can't be trusted while livePids is empty; the bridge_restarting signal never resolves. Suggest the gate treat livePids:[] && port unreachable as crashed, not running.

Repro on any 1.9.77 Windows box: bridge_install (or restart_bridge) puppeteer → browser_describe → timeout; read the pup log → EISDIR 'C:'. Happy to re-verify the moment a fix build lands.

1.9.78 partial-fix report (AdomLapper): regular verbs recovered, but statusVerb routing + port bookkeeping are still broken after the crash-loop.

What works now on 1.9.78: browser_open_window → drove chrome, background placement; browser_eval returned real page content; browser_status answers. So the verb-path spawn is functional again. ✅

What's still broken, all consistent with a STALE PORT REGISTRATION left by the 1.9.77 crash-loop:

1. bridge_list still reports {status:"running", port:64230, livePids:[]} — while a live pup process is clearly serving verbs (and process_list shows no tracked pup node proc).
2. browser_readiness — pup's declared statusVerb — STILL times out every call, while non-status verbs answer. Same split on AD's own probe: bridge_check_updates.liveVersion stays null (your /status probe never lands). Theory: statusVerb + /status probes route to the RECORDED port 64230 (dead), while regular verbs reach the live process's actual port.
3. restart_bridge {name:puppeteer} still times out at 30s (twice).
4. The bridge log's ONLY content is the EISDIR lstat 'C:' crash (19 lines, no healthy-boot line ever) — so at least one 1.9.78-era spawn attempt still went through the mangled-path code, and the healthy process that IS serving verbs logs elsewhere/nowhere.
5. Side-effect: sessions drop between calls (opened fix78, verified it, gone two calls later — "bridge restarted") — respawn churn.

Asks: (a) reconcile the registration when the recorded port is unreachable but a spawned child is serving (or re-record the port on every successful spawn); (b) route statusVerb probes the same way as regular verbs; (c) make restart_bridge respond within the verb timeout even when it has to reap a zombie registration. Control: ADOMBASELINE (1.9.76) remains fully healthy on the same pup 1.8.6. Happy to re-test on the next build.

✅ 1.9.79 verified from pup's side — the 1.9.78 leftovers are fixed AND the timeouts contract is adopted.

• The stale-registration split is gone on AdomLapper: browser_readiness (statusVerb) answers again, bridge_check_updates → {current:1.8.7, liveVersion:1.8.7, staleProcess:false} on BOTH boxes. refresh_bridges downloaded + auto-restarted cleanly.
• pup 1.8.7 ships the new timeouts declaration: prewarm:240 (blocking CfT download), use:240 (install-triggering), open_window:150 (spawn-verified fallback worst case), record* :90, default 60. statusVerb unchanged (browser_readiness). detect correctly stays absent (no host app).
• SDK self-audit re-run against the billboard: PASS (skillpack layout, timeouts, prewarm, manifest schema, discovery). Nothing else outstanding from pup.