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.
preset preview is identical to preset private (decide: make it real, or drop it)
adom-wiki page visibility --preset preview and --preset private set byte-identical state:
"preview" => { visibility: private, source: private, release: private, pkg: private }
"private" => { visibility: private, source: private, release: private, pkg: private }
So preview is currently a synonym. I removed it from the page UI (adom/wiki#93) because offering two buttons that do the same thing implies a choice that does not exist, and the question "what is the difference?" has no answer. The CLI flag still works, as a synonym.
Why it collapsed, which is the actual issue
The name suggests something real and useful: visible to everyone, installable by nobody. Announce a package, let people read the page and the README, but do not hand out the artifact yet.
That state cannot be stored. release_visibility is normalized on write to "public" | NULL, and NULL means "inherit the page":
const releaseVis = rvRaw === "public" ? "public" : null;
So on a public page, releases are always installable. The axis can only ever deviate in the more-open direction (public releases on a private page), never the more-closed one. pkg_visibility does store "private", but on a public page the release download path is still open, so it does not close the hole either.
That is why preview had nowhere to land and became a copy of private.
Ask
Decide whether a real preview tier is wanted. Two honest options:
1. Make it real. Let release_visibility and pkg_visibility store "private" meaningfully on a public page, and honor that in the download and install paths. Then:
| preset | page | source | installable |
|---|---|---|---|
| open | public | visible | yes |
| licensed | public | hidden | yes |
| preview | public | hidden | no |
| private | private | hidden | no |
That completes the taxonomy: preview becomes the "look, do not touch" tier, which is the only combination the presets do not currently cover.
The work is not the storage, it is the enforcement. Every path that serves an artifact would need to respect a private release axis on a public page: /download, the package resolve and install path, the tarball route, and ensureReadableRelease, which today short-circuits to allow when release_visibility === "public" and otherwise falls back to page access. Getting one of those wrong leaks the artifact and the page looks fine, so it needs tests per path rather than one integration test.
2. Drop the concept. Remove --preset preview from the CLI at the next major, or keep it documented as an alias for private. Cheapest, and honest, if nobody actually wants a look-but-not-touch tier.
I lean toward asking whether anyone wants it before building it. It is a real capability with real enforcement surface, and it has been shipping as a duplicate for long enough that clearly nobody has needed it.