"from the wiki" can't work for a first hero — the hero is a publish prerequisite; read the local package instead - Hero Studio

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 bug report

"from the wiki" can't work for a first hero — the hero is a publish prerequisite; read the local package instead

adonis · 1mo ago ·closed by Colby Knox

The ordering is backwards

The hero image is a publish prerequisite: adom-wiki pkg publish of a component/hardware page is hard-gated server-side on screenshots/hero.png being in the tarball. So at the moment you need Hero Studio, the page does not exist on the wiki yet — that is the entire reason you are opening the studio.

But the subject picker's option is "from the wiki", which resolves against a published page. On a first-time hero that option can never work.

What this looks like in practice

Publishing a new board today:

Convert + assemble the package locally (package.json, <slug>.glb, sources).
Open Hero Studio to make the hero the publish gate requires.
"from the wiki" finds nothing — the page is unpublished.
Dead end. The workaround I had to use: publish with a provisional hero image just so the page exists, reopen the studio, pose the real hero, then republish.

That is two publishes and a junk version in the registry to produce one hero. It also means the browse-card thumbnail bakes off the provisional image on the first publish (molecule-publish § Page polish rules).

Ask

Add a local package subject source — read the working directory the studio was invoked from:

package.json → title, description, component.mpn, component.parts.model_3d
the <slug>.glb / docs/*.png / screenshots/*.png sitting right there

Everything the studio needs is already on disk at hero-time. pose <owner/slug> is invoked from the package dir, so the files are one readdir away.

Suggested precedence: local package → wiki page → generic mock, i.e. prefer what is about to be published over what is already published. Keep "from the wiki" for the re-hero case (refreshing the hero on an existing page), where it is the correct source.

Environment

hero-studio 0.20.4, Linux container, --surface webview. Hit while publishing adonis/nametag-blank-large-led.

1 Reply

Colby Knox · 1mo ago

Shipped in hero-studio 0.20.5. Your ordering analysis was exactly right, and your ask shipped as specced: pose now reads the INVOKING DIRECTORY. When ./package.json (or page.json) matches the posed slug: title, description->subtitle, and type seed the subject; local images stage as the showcase automatically (screenshots/ first with the old hero.png excluded since it is the thing being replaced, then docs/, then .png), with alternatives listed and swappable via hero-studio showcase --file. Precedence is your rule verbatim: local package -> wiki page -> generic mock, because the local files ARE what is about to be published; the live pull still runs for metadata the manifest lacks, explicit --title/--brief flags outrank everything, and --no-local opts out. Verified end to end on an unpublished slug with a local package: fields resolved from package.json, showcase staged from screenshots/board-top.png, no wiki round trip needed and no provisional publish. Your two-publish workaround (and the junk version it left) is retired.

One clarification for the record, since your premise slightly overstates the gate: the hero is required for every type, but hardware is NOT hard-gated on Hero Studio or on screenshots/hero.png specifically. A composed billboard also satisfies it: hero {headline, subhead} in package.json at publish, or page create --headline/--subhead before publishing. The studio is for when you want a real posed hero, which is exactly when this fix matters. Closing.