pose --surface pup broken by the Adom Bridge rename: raw relay POST gets _adom_use_cli_instead; use adom-bridge-cli + pup_* prefix

by adom

The hero-image lab with a human gate: `hero-studio pose <owner/slug>` opens the studio in front of the human, posed for their package, and blocks until they click Generate, producing the provenance-stamped 2000x1250 PNG the registry's hero gate requires. The image carries the title and artwork; the exported image also bakes the type pill (top right) and full wiki slug (bottom right); the page shows the hero bare, and only the homepage marquee overlays its own dynamic info. Every hero wears its P

Overview Files Skills Discover Packages Releases Dependencies Issues3 Breadcrumbs Pull Requests Activity

Closed general

John Lauer · 2mo ago ·closed by Colby Knox

pose --surface pup is broken by the Adom Bridge rename (raw relay POST refused)

hero-studio pose <ref> --surface pup --target <name> fails at the surface step. What pose's own stderr printed:

browser_open_window: exit 1; { "_adom_use_cli_instead": "You're POSTing to the Adom Bridge relay
HTTP API (http://127.0.0.1:8766/) directly. This endpoint is internal plumbing - the supported
surface is the `adom-bridge` CLI binary, which handles approval polling, deferred results,
response unwrapping, the WS request-id dance ..." }

Since the v2.0.0 rename (adom/definitions, and issue-blast #537 to bridge pages), the relay refuses raw HTTP posts and the CLI is adom-bridge-cli. The studio's pup leg needs to shell adom-bridge-cli <verb> '<json>' (per-call --ai-thread supported) instead of posting to 8766. Note the pup bridge's verbs currently answer on the pup_* prefix (pup_open_window, pup_navigate, pup_screenshot); browser_* names return bridge_not_installed on my box even though pup's manifest claims that prefix, so resolve the prefix from bridge_list rather than hardcoding.

Worked around tonight by opening the studio proxy URL in a pup session myself and re-arming the gate wait by polling GET /state, but every pose on a pup-preference user hits this until the leg is updated.

hero-studio doctor's pup-fallback check has the same problem: it reports "Adom Desktop did not answer browser_status (no host relay from this container)" even when the relay is up, because it asks the old way.

1 Reply

Colby Knox · 2mo ago

Shipped in 0.16.0/0.16.1: a dedicated bridge adapter (bridge.mjs) that is now the ONE place the studio knows about desktop bridges.

Prefers adom-bridge-cli when present, falls back to legacy adom-desktop.
Verb names are resolved from live bridge_list output by suffix (open_window, navigate, screenshot, eval, status, alert_window), never hardcoded, because manifests have claimed prefixes boxes do not answer. Unresolved suffixes default to pup_* on renamed boxes and browser_* on legacy.
A _adom_use_cli_instead refusal is detected and treated as "this leg is down," not as output.
pose, the pup renderer, and doctor all route through it; doctor prints which generation answered and on which verb (verified on this legacy box: "adom-desktop (legacy), browser_status").
ADOM_TARGET rides every call for multi-desktop relays.

Verify: hero-studio doctor on a renamed box should now report the pup fallback via adom-bridge-cli with pup_* verbs.