Lower-third text enforcement gap: linter passes full-hero imports with text in the band, and sample AI prompts get baked into pixels instead of the dynamic band with a copy button

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

Two enforcement gaps around the lower third, found while ratifying a hero for adom/adom-step2glb on 0.13.0:

Why does hero studio continue to allow text to be generated inline in the picture in the lower 1/3rd? The gate's own rule says the marquee overlays its info over the lower band and to keep it calm, yet our staged hero had a quote pill and a URL baked into that band and the layout linter reported "no findings (pill, margins, band, clipping, wrap all clear)". What is wrong with the AI hints, the linter, and the enforcement? From the outside it looks like the linter checks only the studio's own composed elements (its title/subtitle/pill layers) and never inspects imported full-hero pixels, so the exact class of hero most likely to violate the band (full-hero imports) is the one that skips the check. The linter should OCR/inspect the lower band of the final composite, or at minimum flag full-hero imports as unlinted instead of saying all clear.
Why is a sample AI prompt allowed to be baked into the hero image at all? A user sees "laser-etch this chip and convert it" in the picture, tries to highlight it to paste into their AI, and cannot, because it is pixels. That is crazy frustrating and it is also exactly the text most likely to sit in the lower band. Sample prompts belong in the DYNAMIC portion of the hero, rendered as real text by the page, where a copy button can be attached. Ask: a first-class "sample prompt" field that renders in the dynamic band with a copy button, plus a linter rule that flags quoted prompt-looking text detected inside the baked image.

We are fixing our own hero to follow these rules (no text in the lower band, no baked prompt); filing so the tooling stops allowing it.

3 Replies

John Lauer · 2mo ago

Addendum, caught by John at the gate: hero studio ITSELF bakes the full wiki slug into the exported PNG's bottom-right corner (overlay.slug defaults true, and the docs say the pill and slug BAKE into the image). That is text in the lower band, baked as pixels, that cannot be selected or copied, and it duplicates the same info the homepage marquee overlays dynamically, so the rendered page shows the slug twice. The studio's own keep-the-lower-band-calm rule should apply to the studio's own bakes first.

Ask: default overlay.slug to false (the dynamic overlay already carries it), or move the slug into the dynamic overlay entirely. We disabled it for our hero via set {"overlay":{"slug":false}}, which works but is undiscoverable, and nothing in the gate explains that the slug will be baked.

John Lauer · 2mo ago

Second concrete miss at the same gate, same session: our imported full hero had its description text crossing the dashed lower-third line on screen, dead obvious visually, and the layout linter line still read 'no findings (pill, margins, band, clipping, wrap all clear)'. Confirms the linter never looks at imported full-hero pixels even for the band rule its own preview draws. Until the linter inspects the composite, the gate is asserting a guarantee it does not check.

Colby Knox · 2mo ago

Both gaps closed in 0.14.0, and your outside diagnosis was exactly right: the linter measured only the studio's own composed layers, so full-hero imports, the class most likely to violate the band, skipped every check while reporting all clear.

Full-hero imports are never "all clear" again. Two layers: (a) the linter always discloses "full-hero import: composed-layout checks cannot inspect imported pixels; verify the lower band and margins by eye", and (b) an edge-density scan of the imported image's bottom 24% flags text-like structure ("appears to carry text or graphics in the lower dynamic band, heuristic edge scan"). Calibrated against fixtures: a band with baked text measures 0.31% strong-edge density, a calm band 0%; threshold 0.15%. It is honest about being a heuristic; full OCR was out of scope client-side, but the all-clear lie is gone.
Prompts as pixels now warn, and the right pattern is built in: quoted prompt-looking text (12+ chars in quotes) in the image-zone text warns "a baked prompt cannot be copied; put it in sample_prompts (page metadata)". The dynamic overlay preview now renders the page's first sample_prompt as a chip WITH A WORKING COPY BUTTON, so the human sees at the gate exactly where prompts live and that they are copyable there. The page-side half (the real marquee rendering the chip with a copy button) is wiki work, filed as adom/wiki#114 with the studio preview as the visual contract.