adom-cli-design

@@ -176,7 +176,7 @@ adom-bridge extensions search "python"  ### Port Registration -**Before picking a port**, check `/home/adom/gallia/PORT-REGISTRY.md`. Add your service to the registry before writing code. Port ranges are pre-allocated by category (8820–8829 for Adom tools, 8850–8899 for user/ephemeral, etc.).+**Before picking a port**, check the fleet port conventions (8820–8829 for Adom tools, 8850–8899 for user/ephemeral, 8900–8999 reserved for third-party bridges) and prefer an OS-assigned dynamic port with a discovery file when nothing needs a fixed number.  ### Health Check @@ -234,13 +234,13 @@ Add a row to `~/.claude/skills/adom/SKILL.md`:  ## Distribution -### Own GitHub repo (recommended)+### Its own wiki page (canonical) + optional source repo -Every shared CLI should live in its own `adom-inc/<tool-name>` repo. This keeps the tool self-contained, gives it its own release cycle, and avoids bloating gallia with build artifacts. Examples: `adom-inc/adom-cli`, `adom-inc/adom-vscode`.+Every shared CLI ships from its own wiki page (`adom/<tool-name>`): the package carries the skills + install scripts, releases carry the per-platform binaries, and the page repo hosts the source. GitHub repos are source-backup only — the wiki is the canonical home and distribution channel.  ### The `install` command pattern -**The binary owns its own install.** One command — `my-tool install` — sets up everything: the skill, shell completions, companion pieces (VSIX, config files, etc.). `gallia/install.mjs` just downloads the binary and runs it.+**The binary owns its own install.** One command — `my-tool install` — sets up everything: the skill, shell completions, companion pieces (VSIX, config files, etc.). The wiki package's install script just downloads the binary and runs it.  #### DO NOT embed SKILL.md / BUILD-SKILL.md in the binary (hard rule) @@ -248,9 +248,9 @@ Skills are prose, and we edit them *a lot* more often than we rebuild the Rust c  **The rule:** -- SKILL.md and BUILD-SKILL.md ship as **independent assets on the wiki page**. Publish them alongside the binary with `adompkg publish`.+- SKILL.md ships in the tool's **wiki package** (`adom-wiki pkg publish`), so a prose fix is a pkg republish, not a binary rebuild. - The binary's `install` subcommand **fetches the latest SKILL.md from the wiki** at install time (and falls back to a bundled copy if the wiki is unreachable). The fallback is a safety net, not the primary path.-- Bumping a skill becomes: edit `SKILL.md` in the repo → `adompkg publish` → done. No binary rebuild, no version bump. The next user to run `my-tool install` (or re-run gallia's Tier A refresh) picks up the new prose.+- Bumping a skill becomes: edit `SKILL.md` → bump the pkg version → `adom-wiki pkg publish` → done. No binary rebuild. The fleet's auto-update hook picks up the new prose within ~30 minutes.  Same rule applies to any other rapidly-changing prose asset (policy docs, prompt templates, wiki `body.md`). Binary-side data that is *strictly coupled* to the binary's own structure (e.g., a `VSIX` whose API matches the current binary's RPC schema, or baked-in default config schemas used by the Rust types) can still be embedded via `include_bytes!` — couple-to-code, not couple-to-prose. @@ -298,15 +298,11 @@ Same rule applies to any other rapidly-changing prose asset (policy docs, prompt    }    ``` -3. **Attach binary to GitHub Releases** — no Rust toolchain needed on user containers+3. **Upload the binary as a wiki release asset** (`adom-wiki release upload adom/my-tool <ver> my-tool --platform linux`) — no Rust toolchain needed on user containers. -4. **`gallia/install.mjs` is just two lines:**-   ```javascript-   execSync('gh release download --repo adom-inc/my-tool --pattern "my-tool" --output /usr/local/bin/my-tool --clobber');-   execSync('sudo chmod +x /usr/local/bin/my-tool && my-tool install');-   ```+4. **The wiki package's install.sh is just two lines:** download the release binary to `~/.local/bin/`, chmod +x, run `my-tool install`. -The binary is the primary artifact for *code*. The wiki is the primary artifact for *prose*. `gallia/install.mjs` never needs to know the internals — it just downloads the binary and runs `install`, which then reaches back to the wiki for the skills.+The binary is the primary artifact for *code*. The wiki package is the primary artifact for *prose*. The install script never needs to know the internals — it downloads the binary and runs `install`.  ### build.sh (for local development) 

@@ -1,6 +1,6 @@ {   "slug": "adom-cli-design",-  "version": "1.0.1",+  "version": "1.0.2",   "type": "skill",   "description": "Design conventions for every Rust CLI in the Adom ecosystem. Output formats (OK:/ERROR: + JSON companion), no-color-when-piped, --json for machines and pretty for humans, exit codes, subcommand layout",   "dependencies": {},@@ -8,4 +8,4 @@     "install": "./install.sh",     "uninstall": "./uninstall.sh"   }-}+}\ No newline at end of file

@@ -1,6 +1,6 @@ {   "slug": "adom-cli-design",-  "version": "1.0.1",+  "version": "1.0.2",   "type": "skill",   "description": "Design conventions for every Rust CLI in the Adom ecosystem. Output formats (OK:/ERROR: + JSON companion), no-color-when-piped, --json for machines and pretty for humans, exit codes, subcommand layout",   "dependencies": {},