docs(web/guides): replace nonexistent install.sh URL with working .deb/.rpm install (#2604)

bpamiri · claude · web-flow · commit c6f6cc64c922 · 2026-05-11T22:30:58.000-07:00
* docs(web/guides): replace nonexistent install.sh URL with working .deb/.rpm install The Linux tabs on the start-here installing guide and the upgrade flow pointed at `https://get.wheels.dev/install.sh` — a URL that was planned for the Phase 2 universal installer but doesn't exist yet. Users on Linux hit a 404 and a confusing `bash: command not found` chain. Rewrite all three install-related guides to use the .deb/.rpm packages that release.yml already produces (verified on snapshot v4.0.0-snapshot.1825). The new snippets resolve the latest version dynamically via the GitHub API, so they keep working as releases roll over. - start-here/installing.mdx: Linux install + upgrade tabs; troubleshooting no longer references the never-existed `~/.wheels/env` file. - command-line-tools/installation.mdx: split the "macOS and Linux (Homebrew)" section — Linux now has its own `.deb`/`.rpm` section with the package layout and an Aside flagging native apt/yum repos as a v4.0.x follow-up. - start-here/release-channels.mdx: replace literal `<version>` placeholders with the API-driven version resolution; extend the "Switching channels" section beyond Homebrew (Linux uses Conflicts:/Replaces: metadata, Scoop refuses dual install). Phase 2 (native apt.wheels.dev / yum.wheels.dev repositories) is planned as a follow-up — see tools/distribution-drafts/linux-packages/README.md for the full plan. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Peter Amiri <peter@alurium.com> * docs(web/guides): fix bot-flagged issues on Linux install/upgrade/switch docs Wheels-bot's Reviewer A + Reviewer B caught five issues with the previous revision of #2604. All five address the same root tension: the docs read as if the BE channel mirrors the stable channel filename-for-filename and API-call-for-API-call, but the underlying release pipeline (release.yml hardcoding CHANNEL=stable, GitHub /releases/latest excluding pre-releases) makes the asymmetry user-visible. 1. installing.mdx Aside (bot finding 1) — the "substitute repo name in the URLs above" prose pointed at /releases/latest, which returns nothing against the pre-release-only snapshots repo. WHEELS_VERSION would be empty and the download URL would 404 silently. Replaced with two self-contained snippets (Debian/Ubuntu + Fedora/RHEL) using /releases + head -1, matching the pattern already used in release-channels.mdx. 2. release-channels.mdx Linux switch block (bot finding 2) — the previous block was comments-only with no executable command, and referenced "wheels-be" as a filename component that doesn't exist (release.yml hardcodes CHANNEL=stable, so both stable and snapshot publish a single package literally named `wheels`). Replaced with concrete stable → bleeding-edge and bleeding-edge → stable command blocks. Noted the --allow-downgrades requirement for BE → stable on apt (4.0.0 sorts below 4.0.1~snapshot.500 per dpkg). 3. release-channels.mdx comment on the version substitution (bot finding 3) — the inline comment said "GitHub Releases rewrites ~ to ." but the shell substitution is /-/. The reader had to chain three concepts themselves (tag uses hyphen → internal package version uses tilde → GitHub mangles tilde to dot at upload). Expanded the comment to spell the chain out explicitly. 4. installing.mdx step 1 (bot finding 4) — the manual `sudo apt install openjdk-21-jre-headless` step contradicted both the intro paragraph ("depends on OpenJDK 21") and installation.mdx ("apt/dnf pulls it in alongside wheels"). Dropped step 1 entirely; reworded the intro to spell out the auto-pull behavior explicitly. Step 2 (install) and step 3 (verify) renumber to 1 and 2. 5. installation.mdx BE prose (Reviewer B's missed-issue finding) — same root cause as #1, in the deeper reference doc. Same fix: replace the "substitute the repo name" prose with two self-contained BE snippets using /releases + head -1. Also added a brief BE pointer to the Linux upgrade tab, mirroring the "# or, for the bleeding-edge channel:" line in the Windows upgrade tab. Verified the BE snippet end-to-end: SNAP_TAG=$(curl ... /repos/wheels-dev/wheels-snapshots/releases | ... | head -1) → 4.0.0-snapshot.1826 → URL: .../v4.0.0-snapshot.1826/wheels_4.0.0.snapshot.1826_amd64.deb → HTTP 302 (redirect to release-assets.githubusercontent.com) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Peter Amiri <peter@alurium.com> * docs(web/guides): fill remaining gaps on Linux switch and Scoop reverse paths Round-2 bot findings: 1. release-channels.mdx Switching channels — the Linux blocks named dnf in their comments but only showed apt commands, leaving Fedora/RHEL users without a usable command. Split each direction into a Debian/Ubuntu block and a Fedora/RHEL block. For the BE → stable direction, dnf gets `dnf downgrade <url>` (the rpm-native way to handle an older-version transition); apt keeps its --allow-downgrades trick. 2. release-channels.mdx Switching channels — Scoop only had stable → BE; added the symmetric bleeding-edge → stable block to match the macOS pair. 3. Trust-model documentation — Phase 1 ships .deb/.rpm without detached GPG signatures, so download integrity depends solely on GitHub's HTTPS transport. Added a `<Aside type="caution">` on both installing.mdx (the onboarding guide) and installation.mdx (the deeper reference) noting this explicitly and pointing forward to the Phase 2 signed repos at apt.wheels.dev / yum.wheels.dev. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Peter Amiri <peter@alurium.com> * docs(web/guides): fill diagonal gap in Installing each channel Linux tab Round-3 bot finding: the "Installing each channel" Linux tab in release-channels.mdx showed only two of four distro × channel combinations — Debian/Ubuntu (stable) with apt, and Fedora/RHEL (bleeding-edge) with dnf. The diagonal pairing left a Fedora user looking for the stable rpm install or a Debian user looking for the bleeding-edge .deb install with no command they could copy out of this section. Added the two missing snippets to make the full 2×2 (apt/dnf × stable/bleeding-edge) explicit, mirroring the structure already established in the round-2 "Switching channels" section. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Peter Amiri <peter@alurium.com> --------- Signed-off-by: Peter Amiri <peter@alurium.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
diff --git a/web/sites/guides/src/content/docs/v4-0-0-snapshot/command-line-tools/installation.mdx b/web/sites/guides/src/content/docs/v4-0-0-snapshot/command-line-tools/installation.mdx
@@ -1,14 +1,14 @@
 ---
 title: Installation
-description: Install the wheels binary via Homebrew, Scoop (Windows), or a manual JAR download, and verify your setup.
+description: Install the wheels binary via Homebrew (macOS), .deb/.rpm (Linux), Scoop (Windows), or a manual JAR download, and verify your setup.
 type: reference
 sidebar:
   order: 2
 ---
 
 import { Aside, CardGrid, LinkCard } from '@astrojs/starlight/components';
 
-The `wheels` binary is distributed through three channels: Homebrew for macOS and Linux, Scoop for Windows, and a direct JAR download for anyone who wants to wire it up by hand. Each channel installs the same two artifacts — the LuCLI launcher and the Wheels Module that ships the framework commands.
+The `wheels` binary is distributed through four channels: Homebrew for macOS, `.deb`/`.rpm` packages for Linux, Scoop for Windows, and a direct JAR download for anyone who wants to wire it up by hand. Each channel installs the same two artifacts — the LuCLI launcher and the Wheels Module that ships the framework commands.
 
 **You'll use this for:**
 
@@ -19,7 +19,7 @@ The `wheels` binary is distributed through three channels: Homebrew for macOS an
 
 ## Requirements
 
-The CLI runs on Java 21. On macOS and Linux, the Homebrew formula installs `openjdk@21` for you and sets `JAVA_HOME` inside the `wheels` wrapper, so you don't have to wire up a system JDK. If you're installing manually — or on Windows without Scoop — grab a JDK 21 build from [Adoptium](https://adoptium.net/) or Homebrew:
+The CLI runs on Java 21. On macOS the Homebrew formula installs `openjdk@21` for you and sets `JAVA_HOME` inside the `wheels` wrapper. On Linux the `.deb`/`.rpm` package declares OpenJDK 21 as a runtime dependency, so `apt`/`dnf` pulls it in alongside `wheels`. The wrapper probes `/usr/lib/jvm/` for a Java 21 install and exports `JAVA_HOME` itself. If you're installing manually — or on Windows without Scoop — grab a JDK 21 build from [Adoptium](https://adoptium.net/) or Homebrew:
 
 ```bash title="illustrative — system JDK setup"
 brew install openjdk@21
@@ -28,7 +28,7 @@ java -version
 
 You should see `openjdk version "21.0.x"` in the output. On Apple Silicon macOS, Homebrew's `openjdk@21` isn't symlinked into `/usr/bin/java` by default — the wheels formula handles this by exporting `JAVA_HOME` itself, but if you call `java` directly you'll need to set it manually.
 
-## macOS and Linux (Homebrew)
+## macOS (Homebrew)
 
 Tap the formula repository and install:
 
@@ -49,6 +49,54 @@ The first time you invoke `wheels`, the wrapper:
 
 On upgrades (`brew upgrade wheels`), the staged module version bumps; the next `wheels` invocation notices the mismatch and refreshes `~/.wheels/modules/wheels/` in place.
 
+## Linux (`.deb` / `.rpm`)
+
+Wheels ships native packages for x86_64 Debian/Ubuntu (`.deb`) and Fedora/RHEL (`.rpm`) hosts on every release. Both are built by `nfpm` on the release workflow and uploaded to the GitHub Release alongside the zip/tar artifacts. The package declares an OpenJDK 21 runtime dependency so `apt`/`dnf` pulls a JDK in automatically when needed.
+
+Install the latest stable release:
+
+```bash title="illustrative — Debian / Ubuntu"
+WHEELS_VERSION=$(curl -fsSL https://api.github.com/repos/wheels-dev/wheels/releases/latest \
+  | sed -nE 's/.*"tag_name": *"v([^"]+)".*/\1/p')
+curl -fsSLO "https://github.com/wheels-dev/wheels/releases/download/v${WHEELS_VERSION}/wheels_${WHEELS_VERSION}_amd64.deb"
+sudo apt install "./wheels_${WHEELS_VERSION}_amd64.deb"
+```
+
+```bash title="illustrative — Fedora / RHEL"
+WHEELS_VERSION=$(curl -fsSL https://api.github.com/repos/wheels-dev/wheels/releases/latest \
+  | sed -nE 's/.*"tag_name": *"v([^"]+)".*/\1/p')
+sudo dnf install "https://github.com/wheels-dev/wheels/releases/download/v${WHEELS_VERSION}/wheels-${WHEELS_VERSION}.x86_64.rpm"
+```
+
+The package lays down `/usr/bin/wheels` (a shell wrapper), `/opt/wheels/lucli` (the LuCLI launcher), `/opt/wheels/module/` (the staged Wheels Module), and `/opt/wheels/sqlite-jdbc.jar` (auto-staged into Lucee Express on first run). The wrapper mirrors the Homebrew flow: probes `/usr/lib/jvm/` for OpenJDK 21, exports `LUCLI_HOME=$HOME/.wheels`, syncs the staged module into `~/.wheels/modules/wheels/` on first run or version mismatch, then execs LuCLI.
+
+The bleeding-edge channel publishes `.deb`/`.rpm` to [`wheels-dev/wheels-snapshots`](https://github.com/wheels-dev/wheels-snapshots/releases) on every merge to `develop`. Every release there is a GitHub *pre-release*, so `api.github.com/.../releases/latest` returns nothing — use `/releases` and take the first entry. The asset filename also differs: snapshot tags use a SemVer hyphen (`v4.0.0-snapshot.1825`) but the on-disk asset name uses a dot (`wheels_4.0.0.snapshot.1825_amd64.deb`) because GitHub Releases rewrites the package's internal `~snapshot.N` form to `.` at upload time. The substitution converts the tag's hyphen-form to the URL's dot-form:
+
+```bash title="illustrative — Debian / Ubuntu (bleeding-edge)"
+SNAP_TAG=$(curl -fsSL https://api.github.com/repos/wheels-dev/wheels-snapshots/releases \
+  | sed -nE 's/.*"tag_name": *"v([^"]+)".*/\1/p' | head -1)
+SNAP_FILENAME_VER="${SNAP_TAG//-/.}"
+curl -fsSLO "https://github.com/wheels-dev/wheels-snapshots/releases/download/v${SNAP_TAG}/wheels_${SNAP_FILENAME_VER}_amd64.deb"
+sudo apt install "./wheels_${SNAP_FILENAME_VER}_amd64.deb"
+```
+
+```bash title="illustrative — Fedora / RHEL (bleeding-edge)"
+SNAP_TAG=$(curl -fsSL https://api.github.com/repos/wheels-dev/wheels-snapshots/releases \
+  | sed -nE 's/.*"tag_name": *"v([^"]+)".*/\1/p' | head -1)
+SNAP_FILENAME_VER="${SNAP_TAG//-/.}"
+sudo dnf install "https://github.com/wheels-dev/wheels-snapshots/releases/download/v${SNAP_TAG}/wheels-${SNAP_FILENAME_VER}.x86_64.rpm"
+```
+
+The version metadata *inside* the `.deb`/`.rpm` preserves the canonical `~snapshot.N` form, so `dpkg --compare-versions` and `rpmvercmp` order pre-releases below the next GA correctly.
+
+<Aside type="note" title="Native apt/yum repositories">
+The download-and-install flow above is the v4.0 GA story. Native `apt`/`yum` repositories at `apt.wheels.dev` and `yum.wheels.dev` are on the v4.0.x roadmap — once they're live, you'll be able to add a sources list once and `sudo apt install wheels` / `sudo dnf install wheels` will pull new versions automatically via `apt update`. The package format on disk doesn't change.
+</Aside>
+
+<Aside type="caution" title="Trust model during Phase 1">
+Until the native repos are live, download integrity relies on GitHub's HTTPS transport — the `.deb`/`.rpm` artifacts ship without detached GPG signatures, so neither `apt-key` nor `rpm --checksig` has anything to verify against. Phase 2 introduces a GPG-signed apt/yum repository (the signing key will live in 1Password and be published at `apt.wheels.dev/wheels.gpg`), which will add cryptographic provenance on top of TLS. For now, treat `wheels-dev/wheels/releases` as the trust root.
+</Aside>
+
 ## Windows (Scoop)
 
 Wheels ships on Windows through [Scoop](https://scoop.sh) — a portable, sandboxed package manager that fits the project's release cadence (hourly autoupdate for both stable and bleeding-edge channels). The legacy Chocolatey path is no longer supported; the old v1.x `wheels` package at `community.chocolatey.org/packages/wheels` is the CommandBox-based release and won't drive a v4 tutorial.
@@ -102,7 +150,7 @@ Pick LuCLI and Wheels Module versions that are known to be paired — the Homebr
 
 ## Verifying installation
 
-After any of the three paths, confirm the binary resolves and reports a version:
+After any of the four paths, confirm the binary resolves and reports a version:
 
 ```bash {test:cli cmd="wheels --version" asserts-output="Wheels"}
 wheels --version
@@ -126,9 +174,11 @@ Once the version check passes, `wheels info` inside a Wheels project gives you a
 
 The Homebrew wrapper sets `JAVA_HOME` inside its own process, so a missing or wrong `JAVA_HOME` in your shell doesn't break `wheels`. But if you're calling `java` directly — or running a manual install — the CLI fails fast with a "Java 21 required" message when `JAVA_HOME` isn't pointed at a JDK 21 install. On Apple Silicon macOS, Homebrew stages `openjdk@21` at `/opt/homebrew/Cellar/openjdk@21/<version>/libexec/openjdk.jdk/Contents/Home`; export that path and re-run.
 
-### `wheels: command not found` after `brew install wheels`
+### `wheels: command not found` after install
+
+On macOS, Homebrew's shim directory has to be on your `PATH` — `/opt/homebrew/bin` on Apple Silicon, `/usr/local/bin` on Intel. Run `brew --prefix` to confirm, check your `PATH`, and add the shim directory if it's missing. A fresh shell (`exec $SHELL -l`) often fixes this without any config change.
 
-Homebrew's shim directory has to be on your `PATH`. On Apple Silicon macOS that's `/opt/homebrew/bin`; on Intel macOS and Linux it's `/usr/local/bin`. Run `brew --prefix` to confirm, check your `PATH`, and add the shim directory if it's missing. A fresh shell (`exec $SHELL -l`) often fixes this without any config change.
+On Linux, the `.deb`/`.rpm` package installs `/usr/bin/wheels`, which should be on every user's default `PATH`. If it isn't, run `dpkg -L wheels` (Debian/Ubuntu) or `rpm -ql wheels` (Fedora/RHEL) to confirm the package landed and the binary is at the expected path. A reopened shell (`exec $SHELL -l`) clears any stale `PATH` cache from the previous session.
 
 ### Conflict with a standalone LuCLI install sharing `~/.lucli/`
 
diff --git a/web/sites/guides/src/content/docs/v4-0-0-snapshot/start-here/installing.mdx b/web/sites/guides/src/content/docs/v4-0-0-snapshot/start-here/installing.mdx
@@ -157,23 +157,51 @@ Pick LuCLI and Wheels Module versions that are known to be paired — see [CLI I
 
 <TabItem label="Linux" icon="linux">
 
+Wheels ships `.deb` and `.rpm` packages for x86_64 hosts. A native apt/yum repository at `apt.wheels.dev` / `yum.wheels.dev` is on the v4.0.x roadmap — until then, install the package directly from a GitHub Release. The package installs `/usr/bin/wheels`, declares OpenJDK 21 as a runtime dependency (so `apt`/`dnf` pulls a JDK in automatically), and on first run syncs the framework module into `~/.wheels/`.
+
+<Aside type="caution" title="Trust model during Phase 1">
+During Phase 1 (before `apt.wheels.dev` / `yum.wheels.dev` are live), download integrity relies on GitHub's HTTPS transport — the `.deb`/`.rpm` artifacts ship without detached GPG signatures, so there's nothing for `apt-key` / `rpm --checksig` to verify against. Phase 2 adds GPG-signed apt/yum repositories. For now, `wheels-dev/wheels/releases` is the trust root.
+</Aside>
+
 <Steps>
 
-1. Install via the official installer script:
+1. Download and install the latest Wheels release:
 
-   ```bash title="your shell"
-   curl -fsSL https://get.wheels.dev/install.sh | bash
+   ```bash title="Debian / Ubuntu — stable"
+   WHEELS_VERSION=$(curl -fsSL https://api.github.com/repos/wheels-dev/wheels/releases/latest \
+     | sed -nE 's/.*"tag_name": *"v([^"]+)".*/\1/p')
+   curl -fsSLO "https://github.com/wheels-dev/wheels/releases/download/v${WHEELS_VERSION}/wheels_${WHEELS_VERSION}_amd64.deb"
+   sudo apt install "./wheels_${WHEELS_VERSION}_amd64.deb"
    ```
 
-   The script downloads the latest release into `~/.wheels/bin/` and adds it to your `PATH`.
+   ```bash title="Fedora / RHEL — stable"
+   WHEELS_VERSION=$(curl -fsSL https://api.github.com/repos/wheels-dev/wheels/releases/latest \
+     | sed -nE 's/.*"tag_name": *"v([^"]+)".*/\1/p')
+   sudo dnf install "https://github.com/wheels-dev/wheels/releases/download/v${WHEELS_VERSION}/wheels-${WHEELS_VERSION}.x86_64.rpm"
+   ```
 
-2. Reload your shell or source the updated profile:
+   <Aside type="note" title="Want bleeding-edge?">
+   The bleeding-edge channel publishes a fresh `.deb`/`.rpm` on every merge to `develop`, in the [`wheels-dev/wheels-snapshots`](https://github.com/wheels-dev/wheels-snapshots/releases) repo. Because every release there is a GitHub *pre-release*, `api.github.com/.../releases/latest` returns nothing — use `/releases` and pick the first entry. Snapshot tags use a SemVer hyphen (`v4.0.0-snapshot.1825`); the on-disk asset filename uses a dot in the same slot (`wheels_4.0.0.snapshot.1825_amd64.deb`) because GitHub Releases rewrites the package's internal `~snapshot.N` form to `.` at upload time. Self-contained snippets:
 
-   ```bash title="your shell"
-   exec "$SHELL"
+   ```bash title="Debian / Ubuntu — bleeding-edge"
+   SNAP_TAG=$(curl -fsSL https://api.github.com/repos/wheels-dev/wheels-snapshots/releases \
+     | sed -nE 's/.*"tag_name": *"v([^"]+)".*/\1/p' | head -1)
+   SNAP_FILENAME_VER="${SNAP_TAG//-/.}"
+   curl -fsSLO "https://github.com/wheels-dev/wheels-snapshots/releases/download/v${SNAP_TAG}/wheels_${SNAP_FILENAME_VER}_amd64.deb"
+   sudo apt install "./wheels_${SNAP_FILENAME_VER}_amd64.deb"
    ```
 
-3. Verify:
+   ```bash title="Fedora / RHEL — bleeding-edge"
+   SNAP_TAG=$(curl -fsSL https://api.github.com/repos/wheels-dev/wheels-snapshots/releases \
+     | sed -nE 's/.*"tag_name": *"v([^"]+)".*/\1/p' | head -1)
+   SNAP_FILENAME_VER="${SNAP_TAG//-/.}"
+   sudo dnf install "https://github.com/wheels-dev/wheels-snapshots/releases/download/v${SNAP_TAG}/wheels-${SNAP_FILENAME_VER}.x86_64.rpm"
+   ```
+
+   The metadata inside the package keeps the canonical `~snapshot.N` form so `apt`/`dnf` order the version correctly relative to GA. See [Release Channels](/v4-0-0-snapshot/start-here/release-channels/).
+   </Aside>
+
+2. Verify:
 
    ```bash title="your shell"
    wheels --version
@@ -218,12 +246,25 @@ scoop update wheels-be
 
 <TabItem label="Linux" icon="linux">
 
-Re-run the installer script — it detects existing installs and upgrades in place:
+Re-run the install command for your distro — `apt`/`dnf` upgrades the package in place when it sees a newer version:
 
-```bash title="your shell"
-curl -fsSL https://get.wheels.dev/install.sh | bash
+```bash title="Debian / Ubuntu"
+WHEELS_VERSION=$(curl -fsSL https://api.github.com/repos/wheels-dev/wheels/releases/latest \
+  | sed -nE 's/.*"tag_name": *"v([^"]+)".*/\1/p')
+curl -fsSLO "https://github.com/wheels-dev/wheels/releases/download/v${WHEELS_VERSION}/wheels_${WHEELS_VERSION}_amd64.deb"
+sudo apt install "./wheels_${WHEELS_VERSION}_amd64.deb"
 ```
 
+```bash title="Fedora / RHEL"
+WHEELS_VERSION=$(curl -fsSL https://api.github.com/repos/wheels-dev/wheels/releases/latest \
+  | sed -nE 's/.*"tag_name": *"v([^"]+)".*/\1/p')
+sudo dnf upgrade "https://github.com/wheels-dev/wheels/releases/download/v${WHEELS_VERSION}/wheels-${WHEELS_VERSION}.x86_64.rpm"
+```
+
+For the bleeding-edge channel, run the install snippet from the [bleeding-edge Aside](#install-the-cli) — it points at `wheels-dev/wheels-snapshots` and `apt`/`dnf` will treat each new snapshot as an upgrade.
+
+The first `wheels` invocation after upgrade syncs the new framework module into `~/.wheels/modules/wheels/` automatically.
+
 </TabItem>
 
 </Tabs>
@@ -232,7 +273,7 @@ curl -fsSL https://get.wheels.dev/install.sh | bash
 
 **`wheels: command not found`**
 
-Your shell's `PATH` doesn't include the CLI. Restart your shell, or on Linux source `~/.wheels/env` manually. On macOS, confirm Homebrew's bin path is in `PATH`: `echo $PATH | tr ':' '\n' | grep brew`.
+Your shell's `PATH` doesn't include the CLI. Restart your shell first — most installs only put the binary on `PATH` for new shell sessions. On macOS, confirm Homebrew's bin path is in `PATH`: `echo $PATH | tr ':' '\n' | grep brew`. On Linux, the `.deb`/`.rpm` package installs `/usr/bin/wheels`, which should be on every user's default `PATH`; if it's not, check `dpkg -L wheels` (Debian) or `rpm -ql wheels` (RHEL) to confirm the package installed and the binary is where expected.
 
 **`Error: unable to find Java runtime`**
 
diff --git a/web/sites/guides/src/content/docs/v4-0-0-snapshot/start-here/release-channels.mdx b/web/sites/guides/src/content/docs/v4-0-0-snapshot/start-here/release-channels.mdx
