Studio title is a stale pose-time snapshot AND doubles as the hero headline - the gate shows the wrong page title and Apply can rename the real page - 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

Studio title is a stale pose-time snapshot AND doubles as the hero headline - the gate shows the wrong page title and Apply can rename the real page

John Lauer · 2mo ago ·closed by Colby Knox

The studio's "title" is two different things wearing one field, and neither is guaranteed to be the actual wiki title.

Found posing adom/nb-bridge today (2026-08-09), and John hit it repeatedly from the reviewing side: he asked "what is your wiki page title" several times because the studio header, the package dropdown, and PAGE FIELDS all said "Native Browser" while the live wiki page is titled "NB - Native Browser Bridge". The studio looked authoritative and was wrong.

Two mechanisms combine into this:

The local page record is a pose-time snapshot. It is seeded once and never re-fetched, and POST /api/pages overrides it silently. Republishing the page, retitling it, or fixing its brief on the wiki changes nothing in an open studio. Earlier today a studio was still showing a brief with the retired word "abe" in the marquee preview, three publishes after the live page had lost it.
There is no separate hero-headline field. The family convention (pup, kicad, fusion, now nb) is: page title "Pup - Puppeteer Bridge", hero headline "Pup". The only way to get the short headline is to overwrite the studio's local "title", at which point the gate no longer reflects the real page, and the human's "Apply changes to wiki" button becomes a loaded gun: clicking it renames the real wiki page to the headline. I have had to tell John "do not click Apply" at every single gate today, which is backwards - the button a human is invited to press must not be the dangerous one.

Proposal:

title (read-only in the gate, always the LIVE wiki title, re-fetched on open and on an SSE nudge) and headline (what bakes into the image, editable, defaults to the wiki title) as separate fields.
"Apply changes to wiki" never writes headline; retitling the page stays an explicit wiki-side act.
Show both in the gate header: NB - Native Browser Bridge (page) / headline "Native Browser", so the human sees the pair instead of asking the AI what the real title is.

1 Reply

Colby Knox · 2mo ago

Shipped in 0.16.0/0.16.1, both halves:

Stale title: the gate now shows the LIVE page. pose re-fetches title/brief/type from the wiki after seeding, and the dropdown re-fetches on every selection (#30). John's "what is your wiki page title" question now has one answer.
Title vs headline split: the baked hero text is now a separate state.headline (pose --headline, a Headline field at the gate, or set headline=...). Empty means "use the page title." Punching up hero copy therefore NEVER mutates page metadata, which defuses Apply: the change ledger only carries title edits the human made to the actual page fields on purpose.

The headline also rides the export provenance and the pose-return changes payload like every other pose field.