Adom Wiki
Public Made by Adomby 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.
Hero gate scope: page create + repo push yields a live, browsable, heroless app page (gate never engages)
Reported by Ray (relayed by Colby), verified on staging today by the CLI thread. Ray's own description is exactly accurate:
HERO_STUDIO_REQUIRED fires when you publish a release (pkg publish) or set a hero on a new app/skill page. What I did was page create + repo push: that commits the README + widget assets to the page's git repo and makes it browsable, but it's not a published release, so the gate never engaged. The page is real and viewable; it's just heroless and unreleased.
Verified sequence (staging, app-type page): page create succeeds with no hero demanded -> repo push succeeds -> the page is live and browsable with hero_path: null and no release. The hero gate engages only at pkg publish (tarball provenance check) or a hero write. So the wiki can accumulate live, listed, heroless app/skill pages through the create+push path, indefinitely, by design or by accident.
This is a GATE-SCOPE POLICY question, not a bug in either implementation, so it needs an owner decision:
Option A: accept and make it official. Heroless unreleased pages are legitimate (docs pages, works in progress, widget asset hosts like Ray's). Document it as the sanctioned path; optionally have hero-bearing surfaces (marquee, index cards) style heroless pages deliberately rather than as broken-looking gaps, and maybe a low-key nudge hint on create/push ("this page is heroless; the gate engages at first publish; pose one when ready").
Option B: extend the gate. Require a hero (or explicitly exclude the page from promotional surfaces) once an app/skill page is public and browsable, not just at publish. Costs: breaks the create-then-pose flow ordering (the studio's vitrine auto-pull wants the page to exist first), and turns legitimate WIP pages into gate friction.
The CLI thread leans A with the surface-styling touch: the gate's purpose is that no PROMOTED hero exists without a human making it, and a heroless page promotes nothing. But this is Colby's contract (the baked-hero rules are his call), so filing rather than deciding. No CLI-side change needed under A beyond a hint; under B the CLI mirrors whatever the gate becomes.