---
name: wiki-visibility
description: >-
  How visibility and licensing work on the Adom Wiki (wiki.adom.inc): a page can
  keep its git source PRIVATE while its releases / adompkg package stay PUBLIC, so
  people install the compiled app but can't read the code — the pattern for
  proprietary apps. Covers public vs private source, the private readme, and the
  open-source vs closed-source Page variants. Read this when deciding how much of
  a page to expose, or shipping a proprietary tool. Trigger words: private wiki
  source, public app private source, proprietary wiki page, closed source app,
  private readme, hide source code wiki, install compiled app no source, open
  source wiki repo, license a wiki repo, visibility settings wiki, who can see my
  source.
---

Parent skill: **adom-wiki-skillpack**

# Visibility & licensing: public app, private source

A wiki page is not all-or-nothing. The **git source**, the **release/adompkg
package**, and the **readme** each have their own exposure, which lets a single
repo serve both open-source and proprietary models.

## The independently-controllable parts

| Part | Public means | Private means |
|---|---|---|
| **Git source** (Files tab) | Anyone can read the code | Code hidden; only the owner sees the repo |
| **Releases / adompkg package** | Anyone can `adompkg install` / download the binary | Restricted install |
| **Readme** | Public README shown | A separate **private readme** can document a private-source page |

## The proprietary pattern (closed-source Page)

The combination that makes proprietary apps work on the wiki:

- **Git source: private** — the code isn't browsable.
- **Releases / adompkg: public** — anyone can install the compiled binary.
- **Readme: public** (or a private readme for internal docs).

So users install and run the app just fine, but never see the source. This is how
**hydrogen-desktop** and **adom-desktop** ship: the binary is a public release
asset, the Rust/Tauri source stays private. Contrast with **chip-fetcher** and
**adom-usb**, which are fully open source — source public, MIT-licensed,
contributions welcome.

This visibility split is exactly what distinguishes the **two Page sub-variants**
in the archetype taxonomy (see **wiki-repo-styles**):

- **Open-source Page** — public source + public install (chip-fetcher, adom-usb).
- **Closed-source Page** — private source + public install (hydrogen-desktop,
  adom-desktop).

## The private readme

When the source is private, the public still needs docs. The **private readme**
lets the page show a curated public-facing README (what it does, how to install,
how to use) while the actual source repo stays hidden. Use it so a closed-source
page still looks complete and trustworthy — don't leave a proprietary page with
an empty Overview tab.

## Mechanics

- Set source/package visibility in `page.json` `visibility` (e.g.
  `{"public": true}`) and via the page metadata API (`PUT /pages/:slug`).
- For a closed-source app, ship the binary as a **release asset**
  (`adompkg release upload <slug>@<ver> <file> --platform <os>`) so install pulls
  the compiled artifact, and keep the source repo out of the public files.
- Always state the license in the README so intent is unambiguous (MIT for open;
  a proprietary notice for closed).

When in doubt about exposure for a specific page, confirm with the owner — once
source is public and indexed it may be cached even after you flip it private.