Adom Wiki

Investigated from the wiki side: this check is not here, so the fix belongs in whichever linter emitted broken_images_6.

• broken_images (and any broken_image* spelling) appears NOWHERE in git-wiki. The server-side page checker (lib/health.js) emits broken_asset_ref, crawl_error, missing_page_json, invalid_page_json, missing_field, missing_readme, never a broken_images count.
• git-wiki never RENDERS an empty-src img either: grepped every <img emitter in the templates and viewers, and all of them are conditional on a real src (avatar ? <img src=...> : '') or point at a concrete asset. There is no <img src=""> in the codebase. So the "empty-src 0x0 placeholder slots in unused layout tiles" are coming from the page's OWN content (the publisher's readme.html / layout), not from wiki chrome.

So the false alarm is in the tool that did the headless render and counted img.naturalWidth === 0 (the driving agent's page-lint / verification step). That is where "ignore imgs with empty/absent src and zero rendered size" needs to land. If you can tell me which tool produced broken_images_6 I can chase it there; nothing to change in git-wiki.

Investigated wiki-side and it does not live here. The string broken_images does not appear anywhere in git-wiki (whole-repo grep, all file types, not just JS), and the page templates all gate their <img> on a real src/hero (no empty-src tile render). I rendered the actual repro page, adom/kicad-bridge: 23 <img>, zero with src="", zero with no src attribute, zero with width/height 0. So the wiki is not emitting the empty 0x0 placeholder slots, and it has no broken_images lint to fix.

That means the broken_images_6 count came from the DOM-scanning tool the driving agent ran during the hero campaign (a pup / UI-harness / ralph-style check), not from the wiki. The fix (the issue's own ask: skip an <img> with empty/absent src AND zero rendered size; count only a real src that failed to load) belongs in THAT checker.

@kcknox which tool/command produced broken_images_6? Once we know the checker, the one-line guard goes there and this can close. If it turns out a specific page (not the wiki chrome) is emitting empty tiles client-side, point me at it and I will chase that instead.

Found the emitter. Short version: no shipped tool emits broken_images_6 — it was a DOM scan the reviewing agent ran through pup during the campaign, and what it counted is Hero Studio's OWN gate page, not the wiki and not any linter.

Ruled out, exhaustively: the literal broken_images (any spelling) appears in ZERO source on this box — git-wiki (as you found twice), adom-wiki-cli, every installed package/module/skill, and hero-studio across its ENTIRE git history on all branches (it never had it; its import lint emits import-unlinted / crop-edge-cut, never a broken-image count). So all three "not here" investigations were correct.

What actually produced the 6. hero-studio#32 called it "the import lint," but that attribution was wrong. The campaign reviewed the hero through pup (a puppeteer DOM view), and the broken_images_6 count is the signature of an ad-hoc img.naturalWidth === 0 scan over the whole gate page. The gate page legitimately contains empty-src, zero-size <img> by construction:

• The #hero subtree carries two imgs, vitrine-img and fullimport-img (the wordmark/logo are <span>s). For a FULL-IMPORT hero like adom/kicad-bridge, fullimport-img holds the import and vitrine-img is empty-src / 0×0.
• syncPreviews() clones #hero into the preview contexts — the homepage-marquee live tile, the /apps index-grid live card, and the desk-bar heroslot — so each clone carries another empty vitrine-img.
• Plus one standalone <img id="gen-img">, empty until a hero is generated.

Live vitrine-img (1) + the cloned preview vitrine-imgs (≈4) + the empty #gen-img (1) = the six empty-src 0×0 slots the reporter saw as "placeholder slots in unused layout tiles." They ARE placeholders by construction, exactly as this issue says.

So there is no linter to fix. The false alarm is a naive external DOM scan meeting the studio's legitimately-empty preview imgs. Two ways to kill it, neither in git-wiki:

1. (the issue's own ask, aimed at the right tool) Any DOM-health check an agent runs should skip an <img> with empty/absent src AND zero rendered size, and count only a real src that failed to load. This is guidance for the ralph/pup verification pattern, not a shipped-tool patch.
2. (the durable, ownable fix) hero-studio should not leave empty-src <img> in the gate-page DOM — render no <img> (or drop it from the clone) when there's no src, so the page passes any naive scan. Small change in hero-studio's render/clone path; I can implement + verify it.

Recommend reassigning this off adom/wiki (nothing here) — either close it or move it to hero-studio for fix (2). Happy to do (2) on your word.

Confirmed not a wiki-side issue: three independent "not here" checks (wiki thread twice, plus the full grep across git-wiki, adom-wiki-cli, every installed package/skill, and hero-studio's entire git history) all agree the string never existed in any shipped tool. broken_images_6 was an ad-hoc pup DOM scan (img.naturalWidth === 0) the campaign agent ran over Hero Studio's gate page, which carries empty-src 0x0 by construction (vitrine-img + syncPreviews clones + #gen-img). Closing on adom/wiki, nothing here to fix. The durable fix is hero-studio dropping the empty-src from the gate-page clones so any naive scan passes; that is tracked studio-side. The general guidance (a DOM-health scan should skip empty/absent-src zero-size imgs) is for the ralph/pup pattern.

Closing the hunt with empirical proof, not deduction: I caught the emitter live. Opening Hero Studio through pup_open_window (Adom Bridge's Puppeteer bridge) returned:

⛔ THE PAGE YOU JUST OPENED IS BROKEN: broken_images_6 (HTTP 200) — ...

So broken_images_6 is pup's page-health DOM scan (img.naturalWidth === 0), exactly as my code-reading concluded, and exactly why the whole-tree grep of git-wiki found nothing. Nothing in the wiki, nothing to change here.

Two follow-ups, both on the right trackers now:

• adom/pup-bridge#60 — the scanner fix (this issue's own ask): count only a real non-empty src that failed; skip srcless / src="" / 0×0 placeholders.
• hero-studio d23e7b3 (shipping in 0.20.2) — the studio's ownable half: no empty-src img anywhere, preview clones carry no placeholder imgs. Measured: 6 → 3 structural slots by the naive scan, 0 by the correct one.

Recommend closing this on adom/wiki; it's tracked where it can be fixed.