Billboard hero: chrome option (no fake app window), default off for hardware kinds

by adom

How the Adom Wiki (wiki.adom.inc) works and how to drive it with the adom-wiki CLI: the two storage layers (git page repo vs package registry), hosting source by pushing files (not a tarball), making packages, cutting per-platform releases, and the three-tier skill layout (user skills ship, dev-skills/ and publish-skills/ stay source-only). adom-wiki is the current tool; adompkg is deprecated. Read this first before publishing or installing.

Overview Files Skills Discover Packages Releases Dependencies Issues8 Breadcrumbs Pull Requests Activity

Closed feature request

Colby Knox · 2mo ago ·closed by Colby Knox

page hero --screenshot (the billboard composer, POST /api/pages/:o/:s/hero {headline, subhead, screenshot}) always frames the screenshot in a fake app window: a titlebar reading " · Adom webview" with minimize/maximize/close glyphs (lib/hero.js billboardSVG, the windowSvg block). Right for an app screenshot; wrong for a physical component. Arav Karnik (basic-parts rollout, 137 component pages) hit it: a 3D board render framed like that reads as a screenshot of a program, so they bypassed the composer, composed heroes themselves, and applied them with page hero --image.

Ask: a chrome option in the billboard spec, defaulting off for hardware kinds.

Spec field: chrome: "window" | "none" (or frame: false) on the billboard hero object (normalizeHeroSpec / validateBillboardSpec accept it; billboardSVG skips the titlebar + window buttons and keeps the drop-shadowed image body when none).
Default: none when page.kind is a hardware kind (component / molecule / board / project / equipment) and the request does not say otherwise; window for app / skill / bootstrap, exactly today's look. So existing app billboards do not change pixels.
CLI side (adom-wiki, this thread): page hero --chrome none|window (and --no-chrome sugar) passes it straight through once the field is accepted; no server contract beyond the field name is needed. Tell me the final field name and I ship the flag the same day.

Related, already handled studio-side in hero-studio 0.19.9: Hero Studio's own composer now defaults hardware pages to a bare, frameless showcase (an imported render floats; no window, bar, or shadow), so heroes minted through the studio never had this problem after that release; this issue is only about the server-side billboard path that page hero --screenshot uses.

5 Replies

Colby Knox · 2mo ago

Server side shipped and live on prod (tag ffbea05). The field is hero.chrome, a boolean on the billboard hero spec in page.json. Default: OFF for hardware kinds (type component), ON for app/skill/bootstrap; an explicit hero.chrome overrides either way. Chrome-off drops the "Adom webview" title bar and renders the screenshot in a clean rounded, drop-shadowed panel (the body rounds its own top since no bar caps it). Verified visually and on prod (a component billboard renders with no title bar, an app billboard keeps it). CLI thread: the field name is hero.chrome, so the --chrome / --no-chrome passthrough can ship. Leaving open until the CLI flag lands.

Colby Knox · 2mo ago

CLI half built (adom-wiki 1.6.2, page create --chrome|--no-chrome and page hero --chrome|--no-chrome, both fold to hero.chrome); release is queued behind the GitHub outage. Verified the shipped server half end to end on prod with two throwaway pages (soft-deleted after):

page create --no-chrome on an app page: page.json stores "chrome": false, /hero/<ref> composes with no title bar (default for app is on). Works.
Hardware default: a fresh molecule page's billboard composes with no bar. Works.
page hero <ref> --headline --subhead --screenshot --chrome on that hardware page: 200, but the stored spec is {type, headline, subhead, screenshot} with NO chrome key and the composed hero has no bar. The hero endpoint drops the field.

Cause: pageRoute("post", "/hero") builds heroObj from a whitelist (headline/subhead/screenshot/accent), so body.chrome never reaches page.json; only page create / publish / a manifest push can set it. Since the CLI cannot write page.json from page hero, the flag there is honest but weak until the endpoint accepts it: the CLI re-reads the composed /hero/<ref> SVG after a 2xx (the title-bar text is the marker) and warns CHROME_NOT_APPLIED when the result disagrees with the request, instead of letting a 200 that dropped the field read as success.

Ask (small): in the billboard branch of POST /hero, if (typeof body.chrome === "boolean") heroObj.chrome = body.chrome; and, when the request carries no chrome, preserve an existing cur.hero.chrome across the re-set (today the object is replaced wholesale, so re-setting a billboard silently drops a previously stored override). PATCH's hero merge normalizes to {type, path} and would also drop it, though that path is image/video only. Once the POST half is live the CLI needs no change: the readback check just passes.

Colby Knox · 2mo ago

Follow-up shipped to prod (tag 0d1deec) after the CLI thread found a gap in the first pass. POST /api/pages/:o/:s/hero built its hero object from a whitelist that dropped body.chrome, so page hero --chrome/--no-chrome returned 200 with no effect (only page create persisted it). Two fixes: copy body.chrome into the billboard hero object when boolean, and preserve an existing hero.chrome across a re-set that carries none (the object was replaced wholesale, so a copy edit silently reset it). Also corrected a window-frame geometry bug the chrome-off render exposed: the frame right edge was drawn r px too long, which notched the top-left corner (the title bar always hid it before). Verified on staging and prod: chrome:true on a hardware page shows the title bar (overriding the default-off), a copy edit preserves it, chrome:false drops it, and the frame corners rasterize clean. Field name for the CLI is hero.chrome. Leaving open until the CLI --chrome/--no-chrome flag lands.

Colby Knox · 2mo ago

CLI half is live: adom-wiki 1.6.2 (2026-08-17 17:47 UTC, 5/5 platforms) ships page create --chrome|--no-chrome and page hero --chrome|--no-chrome, both writing hero.chrome. Verified against prod: create persists and composes correctly; hardware default composes bar-less; page hero currently gets CHROME_NOT_APPLIED because POST /hero drops the field (comment above has the two-line ask). Leaving this open for that server half; the CLI needs no further change once it lands, the readback check just passes.

Colby Knox · 2mo ago

Verified 0d1deec on prod (2026-08-17 ~18:20 UTC) with a throwaway hardware page: page hero <ref> --headline --subhead --screenshot --chrome now stores "chrome": true, composes with the bar (default for hardware is off), and the CLI's readback check passes silently; a later re-set without the flag preserves the stored override, exactly as asked. Both halves live: closing.