Adom Core

Colby — adom/[email protected]'s published tarball is 1.6 MB, and essentially ALL of it is the hero image:

[email protected]: tarball 1.6M | 5 files package.json 1.0 KB page.json 939 B README.md 364 B screenshots/hero.png 1,632,820 B <-- 99.9% of the tarball

So every install/update downloads ~1.6 MB to deliver ~2.3 KB of actual payload. core is the most-installed package in the ecosystem (every workstation, every golden-image bake, and every adom-wiki pkg update across the fleet pulls it), so this is the single highest-leverage place to fix it. The hero is already served independently for the page/gallery via page.json — it does not need to be inside the INSTALL tarball at all.

It is not just core — same pattern elsewhere: [email protected]: tarball 761K, hero.png 780,995 B (~100%) [email protected]: tarball 4.0M, hero.png 988,677 B (~24%) [email protected]: tarball 140K, 43 files, 0 media <-- what "right" looks like

FROM JOHN: he hits this constantly too — in almost every tarball he has to explicitly tell the AI NOT to include hero images, other decorative PNGs, and sometimes even mp4/webm demo videos. Telling each AI each time does not scale, and the AIs keep regressing to including them.

ASK: enforce it in the tooling instead of in prose — add a publish-time lint via the adom-wiki APIs so the AI is forced to behave:

1. At adom-wiki pkg publish, WARN (then reject) when the packed set contains image/video assets: *.png, *.jpg/.jpeg, *.gif, *.mp4, *.webm, *.mov — especially anything under screenshots/ or a file referenced as the page hero.
2. Better: auto-EXCLUDE hero/screenshots from the install tarball by default (they stay on the page as page assets), with an explicit opt-in override for the rare package that genuinely ships an image at runtime.
3. Consider a hard size gate: fail publish if the tarball exceeds N MB with >X% of bytes in media, with a clear error naming the offending files.

The error message is what actually changes AI behavior — something like "screenshots/hero.png is a page asset, not install payload; remove it from files[] (heroes are served from page.json)" will get every AI to self-correct at publish time instead of relying on a human to catch it.

Filed from the golden-image thread (we noticed it while inspecting tarballs during the v19 bake). Related tooling issue: adom/adom-wiki-cli#9.

Server half shipped, and the incident package is fixed:

1. adom/core 4.13.3 is live: 955 bytes, down from 1.6 MB (about 1700x). The page hero survived the slim republish, verified: repo materialization is ADDITIVE, so when a new tarball stops shipping a file the page repo keeps its existing copy, and the hero field itself is merge-protected from earlier work (#28/#29). Every install and every 30-minute fleet update tick now moves ~1 KB instead of ~1.6 MB. The fleet converges on the slim tarball within the hour.

2. MEDIA_IN_TARBALL publish warning is live (phase 1: warn), with your teaching line almost verbatim: it names each offending file with its size, states the media percentage of the tarball, and says "page asset(s), not install payload -- heroes and screenshots are served from the page repo". Scope is deliberate so it stays signal: the DECLARED hero file, anything under screenshots/, and video anywhere -- not blanket images, because web-app tarballs legitimately ship runtime UI assets (adom-wiki-hero-image's bundled fonts/wordmark are runtime payload, for example).

3. Escalation to reject is staged but gated on the CLI's pack-time auto-exclusion, for one structural reason found while verifying: a BRAND-NEW page's first publish must ship the hero once (that is how it materializes into the page repo at all). Until the CLI handles that case, a hard reject would leave new tarball-only pages no compliant path to a hero. Same phased pattern as the hero and discovery gates.

Remaining offenders are their publishers' to slim on next release (the warning now meets them at publish): adom-wiki-cli's CI pack (~781 KB hero) and adom-cli (~989 KB). Handing the pack-time half to the CLI thread now, referencing your ask 2 and adom/adom-wiki-cli#9.

CLI half is live. adom-wiki-cli 1.0.47 auto-excludes page-asset media from the tarball at pack time (John's ask 2), default-on:

• drops the manifest-declared hero (hero.path or billboard hero.screenshot), everything under screenshots/, and video files (.mp4/.webm/.mov);
• keeps runtime UI assets -- NOT a blanket image exclude (fonts, wordmarks, icons ship, since apps need them);
• --include-media ships everything for the rare runtime case;
• FIRST publish keeps the declared hero (that first tarball is how it materializes onto the page); a republish drops it, and the page keeps its existing hero (additive materialization). Reuses the first_publish signal publish already computes -- no extra round-trip;
• runs on the shipped set inside build_tarball, so lint still scans every file;
• a MEDIA_EXCLUDED hint reports what was dropped, with byte accounting + the --include-media escape.

One honest correction on my own dogfooding, because your server-side MEDIA_IN_TARBALL warning caught it: 1.0.47 shipped the FEATURE but its OWN tarball stayed fat (764 KB), because release.sh published via the adom-wiki on PATH -- the PREVIOUS version (1.0.46), without the fix. A release tool has to cut its release with the code it is releasing. Fixed in 1.0.48: release.sh now publishes with the freshly-built binary.

Verified on 1.0.48's own published tarball: 764 KB -> 8 KB, contents are exactly the five payload files (README, SKILL.md, install.sh, package.json, uninstall.sh), zero hero/screenshots, and the release log shows the client-side MEDIA_EXCLUDED firing instead of your server MEDIA_IN_TARBALL. (1.0.47's tarball stays fat -- immutable -- but that is cosmetic: the fix works for every other package published by 1.0.47+.)

This pairs with the component skill-delivery reconciliation (adom/adom-wiki-cli#9): both keep the tarball honest as the wire format. pkg install adom/core is now a ~1 KB capability transfer. Once the fleet drains onto 1.0.47+, escalate MEDIA_IN_TARBALL from warn to reject whenever you like -- same phased pattern as the others.

Closing — fixed end to end.

• Lint at publish: done both halves. Server warns MEDIA_IN_TARBALL; CLI (adom-wiki-cli 1.0.47) auto-excludes the declared hero, screenshots/, and videos from the tarball by default, keeps runtime assets, --include-media to override, first-publish keeps the hero.
• Incident package: adom/core 4.13.3 republished at 955 bytes (was 1.6 MB), page hero intact.
• CLI dogfood: 1.0.48 publishes its own tarball at 8 KB (was 764 KB), verified on the published artifact.

Only remaining step is the phased escalation of MEDIA_IN_TARBALL from warn to hard-reject once the fleet drains onto 1.0.47+. That is a one-line server flip on a drain condition, tracked alongside the valid-alias drain check rather than holding this issue open. Reopen if that escalation needs its own thread.