name: adom-shotlog-publishing description: "How to publish adom-shotlog (and apps like it) to wiki.adom.inc with adompkg - org ownership, OSS source, MIT license, hero, and the wiki traps that waste hours (visibility re-privatization, hero caching, binary overwrite, title vs slug). Use when: publishing/republishing adom-shotlog, cutting a release, fixing an unlisted/privatized page, a stale hero, or bundling sub-skills. Trigger words: publish shotlog, adompkg publish, republish, wiki release, hero not updating, page went private, visibility trap, bundle sub-skills, org owned, publish rules."

Publishing adom-shotlog to wiki.adom.inc

The whole app - CLI binary, source, README, main skill, AND sub-skills - ships as one package: adom/adom-shotlog. Do NOT create separate wiki pages/repos for the skills; they live in THIS repo and ride along.

The publish command

cd <staging-dir>          # holds package.json, bin/, src/, skills/, SKILL.md, README.md, LICENSE, screenshots/
adompkg publish --org adom --public --version <next> --yes
  • --org adom → the page is org-owned (/adom/adom-shotlog), not user-owned. (The author_name sidebar shows the publishing employee and is immutable via the API - that's attribution, not ownership.)
  • --public → anyone can install/view.
  • Version must bump every publish - you cannot republish the same version. Keep Cargo.toml, VERSION, and package.json version in lockstep, and rebuild so the binary's --version matches what the page advertises.

package.json essentials

  • slug: "adom-shotlog" (install name) vs title: "Adom Shotlog" (display heading). They're different on purpose - slug stays kebab, title is human.
  • license: "MIT" + ship a real LICENSE file (© Adom Industries) + set license/authors in Cargo.toml. Metadata alone isn't enough for OSS.
  • hero: { path: "screenshots/hero.png" } - REQUIRED; publish refuses without it.
  • bundled: true, a tags array, and files must whitelist everything that should be browseable/installed, including source + sub-skills: ["SKILL.md","skills/**","README.md","package.json","install.sh","uninstall.sh","bin/**","screenshots/**","src/**","Cargo.toml","Cargo.lock","build.sh","VERSION","LICENSE"] (Only what's in files reaches the git repo / Files tab - omit src/** and the source is NOT browseable.)
  • install.sh deploys the binary AND loops skills/*/ to install every sub-skill.

The traps (learned the hard way)

  1. Visibility re-privatization. A POST /files or a metadata PUT on a public org page silently flips visibility back to private. Fix: don't poke files piecemeal - do a bumped adompkg publish --org adom --public, which re-publicizes. After publishing, verify anonymously:
    curl -s -o /dev/null -w "%{http_code}\n" https://wiki.adom.inc/adom/adom-shotlog
    curl -s -o /dev/null -w "%{http_code}\n" https://wiki.adom.inc/api/packages/adom/adom-shotlog/<ver>/manifest
    
    Both must be 200.
  2. Hero caching by URL. The hero blob URL (/blob/app/adom-shotlog/screenshots/hero.png) is cached by browser + CDN; overwriting the SAME path serves the stale image. You should NOT have to rename the file - the platform should cache-bust by content hash. Until it does, if a hero looks stale, confirm the served bytes (curl … | md5sum) match your new file; it's a cache, not a regression. (Logged for Colby - don't normalize the rename-the-file workaround.)
  3. Binary overwrite. Overwriting a binary at the same repo path can no-op (commit:null). A version bump + republish sidesteps it.
  4. Overview vs Files lag. The Overview tab renders a readme DB field set from the tarball README at publish time - a bare git push of README updates the Files tab but not the Overview. Republish to refresh Overview.

After EVERY publish

  • Verify anon 200 (above).
  • Show it in pup (public page → pup): open/refresh the page, screenshot, look. A 200 proves nothing about what the human sees.
  • Retiring an old slug (e.g. the pre-rename adom/shotlog)? adompkg delete <owner>/<slug> --confirm is a soft, reversible delete (adompkg undelete). It breaks adompkg install <old>, so mention the migration.