Gate linting gaps: title-vitrine overlap missed, title-shrink not reprimanded, baked slug vs calm lower band, draggable dialogs lack grip glyph

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

Four gaps found while posing the adom/definitions hero at the gate today (2026-08-08), mostly about the linter/reprimand system protecting the wrong things. Filing as one issue since they share a fix surface.

1. The layout linter missed a title-vitrine overlap entirely

With layout bleed-bottom, fontSize.title 8, and a real 1116x1234 vitrine screenshot staged, the baked "Definitions" wordmark visibly spilled onto the vitrine card (the final "s" crossed the vitrine's left edge). state.lint stayed [] the whole time. The linter measures pill vs vitrine overlap (and auto-scrims it), but apparently not title vs vitrine. A headline crossing the vitrine edge is at least a warn, arguably a fail.

2. When there IS a collision, the resolution guidance must protect the TITLE, not the vitrine

The title is the most important element of a hero (the app NAME is the headline; that's the whole design system). Today, with no reprimand priority to stop it, the driving AI's first instinct was to shrink fontSize.title from 8 to 6 to clear the collision, which is exactly backwards. The human caught it; the tooling didn't. Proposal:

Any title-vitrine collision finding should carry explicit guidance: "resize or reposition the VITRINE (layout change, smaller slot); do not shrink the title below its default to resolve overlap."
Bonus: a reprimand when a pose session reduces fontSize.title below the default while a vitrine collision is (or was) present, so the lazy fix gets called out the way VITRINE_IS_GENERIC calls out mock content.

3. The baked wiki slug (bottom right) contradicts the keep-the-lower-band-calm rule, and duplicates the marquee URL

The studio hard-bakes the full wiki slug into the lower right of the export, while simultaneously teaching (stagebar copy, band scan, full-import reprimands) that the lower third must stay calm because the homepage marquee overlays its own dynamic info there. In the gate's own "With homepage overlay" preview the URL renders TWICE: the marquee's copy (lower left) and the baked slug (lower right). Same duplication family as the doubled title already annotated with adom/wiki#80. Proposals to evaluate:

Make the baked slug optional or reposition it out of the marquee band, or
Have the marquee suppress its URL line when the artwork carries a studio-baked slug (the studio knows, provenance stamp), or
At minimum, have the gate/linter explain the contract explicitly (authored pixels must keep the band calm; the studio's own pill+slug are the sanctioned exceptions) so humans and AIs stop reading it as a violation.

4. Draggable UI needs a drag affordance glyph

Tour dialogs are draggable by their header (great, since they land on top of the artwork, today one sat right on the wordmark), but nothing indicates that visually. The user never knows it's draggable unless told. Every draggable element should carry a standard grip glyph (six-dot / grab-handle) in the draggable region, plus a grab cursor on hover. Applies to the tour dialogs and any other floating panel the studio makes draggable now or later.

Repro context: hero-studio instance :8849, posed adom/definitions via pup on AdomLapper, vitrine from a real page screenshot, hero-studio set used for fontSize/layout changes.

3 Replies

John Lauer · 2mo ago

5. Title typography must be standardized ACROSS heroes: fixed height, fixed baseline, left third (from John, 2026-08-08)

The deeper fix behind findings 1 and 2. Today fontSize.title is width-relative (cqw), per-hero adjustable, and the studio happily bakes whatever size survives the pose. That optimizes each hero in isolation and destroys consistency across the collection, which is where heroes actually live: a user scrolling the app index, skills index, or hardware index sees a WALL of heroes, and their eye should never have to re-learn the title size from card to card.

What professional graphic design does, and what the studio should enforce:

Fixed title HEIGHT, not width-relative size. Normalize the title to a consistent visual cap height across every hero, so every card in an index grid reads with the same title scale.
Fixed baseline position. The title starts at the same x/y baseline in every hero. Consistency of form across the collection beats per-hero composition cleverness.
Left third. The title block lives in the left 1/3 of the hero (rule of thirds). The vitrine and art get the rest.
Overflow never shrinks the title. A long title word-wraps at the fixed height, and/or the VITRINE shrinks or repositions to make way. The title height and baseline are invariants; everything else negotiates around them.

Enforcement, not suggestion: these should be linter checks with reprimands (title-height deviation from the standard, baseline deviation, title escaping the left third), the same way VITRINE_IS_GENERIC enforces real content. The per-hero fontSize.title knob should probably become a constrained escape hatch (or go away), because every degree of freedom here is a way for the index grids to get visually noisy.

John Lauer · 2mo ago

Second thread, same gap #3 (and #2) from the pup hero today

Independent hit on this from the other half of today's session: the adom/adom-desktop-puppeteer-bridge (pup) hero, posed in a separate instance while you were on adom/definitions. Same afternoon, same studio, different page, and the baked bottom-right slug bit us the same way. Adding field detail so #3 (and #2) get weighted right.

#3, the baked slug reads as a bug, not a sanctioned element. On the pup hero the human asked "why is there a wiki url in the lower right of the hero?" THREE separate times across the session. Nothing at the gate labels it as the studio's own baked slug, so it reads as leaked or duplicated screenshot content, not a house element. It cost real back-and-forth before it was clear the fix was a toggle. Strongly seconds the proposals, in priority order for us: (a) make it optional with an obvious in-gate control, (b) at minimum label it in-context so it stops reading as a violation. The fix that worked was overlay.slug=false, but that is a state key you have to already KNOW; there is no gate affordance for it.

New angle: full-hero import makes #3 worse. The pup hero is a full-hero import (we needed it to get the vitrine to 90% height, since the layout presets cap the window shorter). In full mode the studio still stamps the slug and pill ON TOP of the authored image, so the URL drops into the lower band over authored pixels (our taskbar). When the author already controls the entire composition, a URL the studio injects that they did not place is especially surprising, and it collides directly with the "keep the lower band calm" rule that the same mode enforces via the full-import band scan.

#2 also hit us, via full-hero's missing title reference. In full-hero mode the studio hides its own layout ("vitrine slot hidden in this layout"), so it renders no title and the author must bake it. There is no reference for WHERE the canonical title belongs, so we placed "Pup" about 10% too low (baked at 0.30 * H, versus the studio's own --inset 4.5cqw wordmark + title stack, which lands the title top near y=188 on the 2000x1250 canvas). The human caught it by eye; the tooling did not. A canonical title-box guide overlay in full-hero mode, or a lint that flags an authored title sitting far from the inset, would have caught it, and it pairs naturally with #2's "protect and measure the title" theme.

Repro context: hero-studio on a dedicated port (we spun up our own instance specifically to avoid the #522 / #484 cross-thread stomping), full-hero import via hero-studio vitrine --file ... --full --chrome none, posed via pup on AdomLapper. Net: from a second thread and a second page, #3 is not an edge case, it is the default read of that element by both the human and the driving AI.

Colby Knox · 2mo ago

Shipped in 0.16.0/0.16.1 (live on the wiki now).

Title-vitrine overlap: the linter now warns on ANY image-zone text colliding with the vitrine, and the message carries the doctrine you asked for verbatim: "resize or move the VITRINE (layout picker, vitrine size), do not shrink the title to fit."
Title-shrink reprimand: a title under 6.5cqw draws its own warning naming the family floor and pointing at the vitrine as the thing to resize. The retrospective's four shrink-rounds motivated the wording.
Baked slug vs the calm lower band: the slug now defaults OFF entirely (closed as part of #29).

Verify: pose anything, drag the title size slider low or pick a layout where text hits the vitrine, and read state.lint (or the gate lintbox).