---
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 / wiki 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/`adom-wiki pkg`
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 / wiki package** | Anyone can `adom-wiki pkg 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 / `adom-wiki pkg`: 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**
  (`adom-wiki 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.