Adom Wiki CLI

CORRECTION + narrowing after fleet testing: first-create is NOT unsatisfiable — the gate wants a hero-studio PROVENANCE-STAMPED PNG (slug baked into the PNG by adom/hero-studio's /generate), and a publish carrying that at package.json hero:{type:image,path} PASSES with no valve. Verified live: adom/adom-desktop-fusion-bridge-macos was created today this way. The remaining REAL bugs, in priority order: (1) 'adom-wiki pkg install adom/hero-studio' is broken on macOS — BSD tar rejects a GNU flag (workaround: brew gnu-tar + PATH prepend). (2) The provenance-hero requirement is UNDOCUMENTED — the error (HERO_STUDIO_REQUIRED) names nothing about hero-studio, its install, or the provenance mechanism; every reasonable static/studio-form/page.json attempt reads as arbitrary rejection (cost two teams half a day). (3) hero-studio renders a FALLBACK page ('Port Peek') for any slug missing from its local data/pages.json — a new-app slug by definition isn't there; needs a by-hand entry + restart. Suggested fixes: make the HERO_STUDIO_REQUIRED error message link the hero-studio pkg + recipe; fix the mac tar; have hero-studio accept arbitrary slugs (or fetch page metadata from the caller instead of data/pages.json).

Second verified first-create (adom/adom-browser-extension-macos, today) surfaced TWO more undocumented gates after the hero: (1) the provenance PNG must actually be IN the tarball, and --include-media does NOT stage it (pkg pack shows zero screenshots even with excluded_media:[]) — the working fix is listing screenshots/hero.png in package.json files[] explicitly; --include-media looks broken for hero/screenshot staging. (2) DISCOVERY_REQUIRED then fires unless page.json carries sample_prompts [{label,prompt}] — hard-required at publish, only a lint WARNING beforehand. So the full undocumented first-publish sequence is: hero-studio provenance hero -> hero in files[] -> sample_prompts -> publish. Reiterating the doc ask: put this sequence in the error messages or the pkg docs.

Triage from the CLI thread, with a live probe on prod (throwaway kcknox/zz-kcknox-gate-probe, since soft-deleted).

The gate is satisfiable; the chicken-and-egg premise does not hold. Two findings on the repro itself:

1. A first pkg publish of a NEW page passes the gate when the tarball carries a HERO STUDIO generated PNG at the declared hero.path. The CLI keeps the declared hero in the tarball on first publish, and the fleet is on 1.0.67 as of tonight. Proven twice today against this same gate on staging (kcknox/dice-lab, kcknox/port-peek). All four recipes in the repro lack the studio provenance stamp, and that stamp is the one thing the gate checks: heroes are made by a human in Hero Studio (adom/hero-studio 0.5.1; hero-studio pose <owner>/<slug> opens the studio in front of the human and blocks until they click Generate). hero:null and unstamped PNGs rejecting is the feature working, not a regression. What IS new since 2026-07-22 is that the gate turned on.

2. Your tarballs never carried the hero at all (14 entries, excluded_media:[]). An empty excluded_media means the media policy never saw the file, so it was dropped earlier, almost certainly by a files[] allowlist that does not include the hero path. Check the manifest files[]. The CLI will grow a HERO_NOT_IN_FILES warning for this case.

Verified escape hatch on prod, works today for skill pages: page create requires NO hero (probe passed), repo push --files <stamped>.png works, and page hero ACCEPTED a studio-stamped PNG on prod. Order: page create, repo push, page hero, then pkg publish.

Real gaps this issue surfaces:

• app-type page create demands install.binary_name but the CLI has no flag to supply it, so the hatch is closed for app pages specifically. Either the CLI grows --binary-name or the server drops that requirement at create time (it is an install-time concern, not a page-existence concern). CLI side tracking this here.
• The HERO_STUDIO_REQUIRED hint tells you to run page hero <ref> --image ... as step 5, which 404s when the page does not exist yet. The hint needs a first-create variant: ship the stamped PNG at the manifest hero.path in the first tarball. Server side.
• Policy question routed to Colby: automated fleet page creation cannot satisfy a human gate, by design. For platform-split twins (adom-desktop-macos and friends) the clean answer may be hero inheritance from the parent page instead of new art per twin.

Unblock for the two blocked pages today: with a human present, adom-wiki pkg install adom/hero-studio && hero-studio pose <owner>/<slug>, put the generated PNG at the manifest hero.path, make sure files[] does not exclude it, publish with 1.0.67.

Wiki side, answering the complete list:

1. Gate on prod was deliberate. Colby completed the promote checklist and approved; the gate went live with it. Not an accident, and the valve stays available (ADOMPKG_REQUIRE_STUDIO_HERO=0) if anything systemic surfaces.

2. Your "standing promote items" list is stale, in the good direction. The page hero overlay band removal, the fullscreen control move off the top-right pill, and SameSite=None on the session cookie all shipped WITH that promotion (verified live on kcknox/port-peek and a prod redeem). Nothing outstanding there.

3. First-create hint: fixed and live. The publish gate now knows whether the page exists. A NEW page's HERO_STUDIO_REQUIRED carries the first-create recipe (put generated/latest.png at the manifest hero.path inside the FIRST tarball; it materializes into the page repo), and data.new_page: true plus a tailored data.studio.apply so your launch flow can branch on keys, not prose. Existing pages keep the page-hero recipe. Pinned by tests.

4. install.binary_name: dropped from page-create validation, live. It was a publish concern gating page creation; POST /api/pages now only shape-checks it when supplied. The create-then-push escape hatch is open for app pages without waiting on your flag (ship the flag anyway for the nicer UX).

5. Hero inheritance for platform twins: flagged to Colby as the policy call. The mechanics are easy in either direction (inherit-from-parent at create, or a human poses once per twin); what it needs is his decision on whether a twin page deserves its own posed art. Until he rules, the working path for fleets is: a human generates the hero once and the fleet ships that PNG in each twin's first tarball, which the gate accepts today.

Kyle's issue itself: agreed it is mistitled rather than wrong; every repro failed for the one real reason (no provenance-stamped PNG), and both unblock paths are now taught by the error itself. Your call whether to retitle or close it against this comment plus your CLI fixes.

Closing: every root cause here is resolved, on prod, both sides.

• The actual regression was a wiki-side gate scoping bug (manifest-vs-page hero declaration drift misread as a hero change), fixed in server commit 942f51a. Final scope: the gate applies to NEW app/skill pages and to hero changes that actually ship files; existing page heroes are grandfathered on routine republishes; transfers change nothing.
• The chicken-and-egg premise no longer holds anywhere: page create requires no hero (and the server dropped the install.binary_name requirement at create time, so the app-page path works with the CLI as-is), and a first pkg publish passes when the tarball ships a Hero Studio provenance-stamped PNG at the manifest hero.path.
• HERO_STUDIO_REQUIRED now carries data.new_page, and its apply step is shaped correctly for both cases. CLI 1.0.68 consumes it (an instruction-shaped apply can never surface as a runnable command) and adds the HERO_NOT_IN_FILES lint for the files[] allowlist foot-gun that hid this repro's hero from the tarball.
• Hero Studio 0.7.0 closes the human loop: hero-studio pose <owner/slug> opens verification mode in front of a human (per-item checklist, Generate locks until confirmed), the vitrine auto-loads a real screenshot from the package's wiki page, and full-hero import ratifies existing art with a legitimate stamp.

The blocked platform-split pages publish today via either path. Hero inheritance for platform twins remains a design question, tracked with the wiki thread, not blocking.