Hero Studio
Public Made by Adomby 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
Support multiple concurrent studios: per-pose sessions or per-instance ports (one thread's pose must not clobber another's)
Direct question from John, mid pose war (#12): "why can't I run multiple hero studios so that another AI thread's attempt to use hero studio doesn't mess with mine?"
Why it is impossible today, concretely:
- The server binds a fixed :8846 and a second instance dies with a raw EADDRINUSE (#9).
- Every CLI subcommand (pose, set, vitrine, state, toast) is hardwired to localhost:8846; there is no --port or instance targeting. Even
hero-studio --helprefuses to print while a server is running. - All state is ONE global blob (page, vitrine, fontSize, confirm, approved) with one SSE channel and one gate, so whoever poses last owns everything, including another thread's half-reviewed checklist.
Ask, either shape works:
A. Per-pose sessions in one server (preferred): every pose mints a session id; state, vitrine, checklist, SSE, and the gate are keyed by it; the studio URL carries ?session=; the CLI takes --session (defaulting to the poser's own). Two threads then pose in parallel and the human reviews each on its own page, no leases needed.
B. Per-instance ports: serve --port, CLI --port/HERO_STUDIO_PORT everywhere, and pose prints the chosen port. Cheaper to build, but pushes multiplexing onto humans and window management.
Either one dissolves the pose war in #12 at the root instead of arbitrating it.