Zenofex · Sep 26, 2026 · Sep 26, 2026
diff --git a/.github/workflows/cli-release.yml b/.github/workflows/cli-release.yml
@@ -364,7 +364,7 @@ jobs:
           echo "::error::bootintel-detectors ${{ inputs.version }} never appeared on the index."
           exit 1
 
-      - name: Publish bootintel-cli
+      - name: Publish bootintel
         env:
           CARGO_REGISTRY_TOKEN: ${{ secrets.CARGO_REGISTRY_TOKEN }}
-        run: cargo publish -p bootintel-cli
+        run: cargo publish -p bootintel
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -8,6 +8,22 @@ All notable changes to bootintel-cli are documented here. Format follows [Keep a
 
 ## [Unreleased]
 
+## [0.4.2] — 2026-09-26 — published as `bootintel`
+
+### Changed
+- **The crate is now published as `bootintel`, not `bootintel-cli`.**
+  `cargo install bootintel` installs a command called `bootintel`, which
+  is what the binary has always been named. The `-cli` suffix made every
+  user type one name and get another. crates.io cannot rename a crate, so
+  this is a new crate; `bootintel-cli` 0.4.1 is yanked. It had 0 downloads,
+  so nothing breaks, and the old name stays reserved under the same account.
+  The package directory stays `crates/cli`, since renaming it would churn
+  paths for no user-visible gain.
+- Numbered 0.4.2 rather than republishing 0.4.1 under the new name: `main`
+  was exactly tag `cli-v0.4.1`, so reusing that version would have put a
+  crate on crates.io whose contents differed from the tag and the release
+  archives. A crates.io version can be yanked but never reused.
+
 ## [0.4.1] — 2026-09-26 — publishable to crates.io
 
 No user-visible behaviour change, so PATCH per the policy above.
@@ -329,7 +345,8 @@ Initial release. All six subcommands live; five branch-based milestones (M1-M5)
 - PDF report download subcommand — server-side endpoint exists but no client-side wrapper yet.
 - Windows support — the Rust code compiles for Windows and the release workflow builds it, but install.sh doesn't handle Windows yet (`.ps1` installer is a follow-up).
 
-[Unreleased]: https://github.com/bootintel/cli/compare/cli-v0.4.1...HEAD
+[Unreleased]: https://github.com/bootintel/cli/compare/cli-v0.4.2...HEAD
+[0.4.2]: https://github.com/bootintel/cli/releases/tag/cli-v0.4.2
 [0.4.1]: https://github.com/bootintel/cli/releases/tag/cli-v0.4.1
 [0.4.0]: https://github.com/bootintel/cli/releases/tag/cli-v0.4.0
 [0.3.1]: https://github.com/bootintel/cli/releases/tag/cli-v0.3.1

diff --git a/Cargo.lock b/Cargo.lock
diff --git a/Cargo.toml b/Cargo.toml
@@ -19,7 +19,7 @@ members = ["crates/detectors", "crates/cli"]
 resolver = "2"
 
 [workspace.package]
-version = "0.4.1"
+version = "0.4.2"
 edition = "2021"
 rust-version = "1.90"
 license = "Apache-2.0"

diff --git a/README.md b/README.md
@@ -92,7 +92,10 @@ docker run --rm -i ghcr.io/bootintel/cli:latest scan - < boot.log
 # Nix flake (in-repo):
 nix run github:bootintel/cli -- version
 
-# Cargo (from source):
+# Cargo (from crates.io):
+cargo install bootintel
+
+# Cargo (from a source checkout):
 cargo install --path crates/cli --features tui
 ```
 
@@ -112,7 +115,7 @@ Pin to a release tag (`@cli-v0.4.0`) or a commit SHA — **never `@main`** (a co
 
 **Homebrew:** the formula template lives at `packaging/homebrew/bootintel.rb`. A public `bootintel/homebrew-tap` for `brew install bootintel` is planned.
 
-**crates.io:** `cargo install bootintel-cli` is not available yet. The crates are publishable and the release workflow has the job wired, pending a registry token. See [docs/releasing.md](docs/releasing.md).
+**crates.io:** `cargo install bootintel` installs the latest published release. It builds from source, so it needs a Rust toolchain and takes a few minutes; the one-liner above drops a prebuilt binary in seconds. See [docs/releasing.md](docs/releasing.md) for how releases are cut.
 
 **Windows:** the one-liner above downloads + SHA256-verifies the latest release, extracts `bootintel.exe` into `$env:USERPROFILE\.local\bin`, and prints a `setx PATH` line if that dir isn't already on your PATH. Override with `$env:BOOTINTEL_VERSION` / `$env:BOOTINTEL_INSTALL_DIR`, or use `$env:BOOTINTEL_TARBALL` for offline installs. Currently x86_64 only — ARM64 users need `cargo install --path crates/cli --features tui`.
 

diff --git a/crates/cli/Cargo.toml b/crates/cli/Cargo.toml
@@ -1,5 +1,10 @@
 [package]
-name = "bootintel-cli"
+# Published as "bootintel", matching the binary it installs. It was
+# "bootintel-cli" for exactly one release (0.4.1, 0 downloads, since
+# yanked): cargo install bootintel-cli producing a command called
+# bootintel is a papercut every user hits. The directory stays
+# crates/cli because renaming it would churn paths for no gain.
+name = "bootintel"
 description = "Interactive UART capture + streaming boot-log analysis. Free scan + share; server-side CVE matching + exploit paths via bootintel.com API."
 version.workspace = true
 edition.workspace = true
@@ -19,7 +24,7 @@ path = "src/main.rs"
 # version when packaging for crates.io, which rejects a bare path dep.
 # This is what publish = false was working around; publishing
 # bootintel-detectors first makes the workaround unnecessary.
-bootintel-detectors = { path = "../detectors", version = "0.4.1" }
+bootintel-detectors = { path = "../detectors", version = "0.4.2" }
 clap = { version = "4.5", features = ["derive", "wrap_help", "env"] }
 # Shell-completion emitters for `bootintel completions <shell>`. Version
 # tracks the clap major/minor (4.5). No default features — we only use

diff --git a/docs/releasing.md b/docs/releasing.md
@@ -65,9 +65,9 @@ having no brew line at all.
 
 ## Publishing to crates.io
 
-Order is not optional. `bootintel-cli` declares `bootintel-detectors` with
+Order is not optional. `bootintel` declares `bootintel-detectors` with
 both a path and a version, so the library must be on the index before the
-binary crate can be packaged. `cargo package -p bootintel-cli` fails with
+binary crate can be packaged. `cargo package -p bootintel` fails with
 `no matching package named bootintel-detectors` otherwise.
 
 The `publish-crates` job does this in order, waits for the index to become
@@ -77,9 +77,15 @@ consistent, and then publishes the binary crate. Dispatch the workflow with
 ```sh
 cargo publish -p bootintel-detectors
 # wait for the index
-cargo publish -p bootintel-cli
+cargo publish -p bootintel
 ```
 
-After the first successful publish, update the Install section of `README.md`
-to offer `cargo install bootintel-cli` instead of the from-source line. Do not
-add it before then.
+The README's Install section offers `cargo install bootintel` as of 0.4.2,
+the first release published under that name. Keep the caveat that it builds
+from source: the install one-liner is faster for anyone who just wants the
+binary.
+
+The crate was `bootintel-cli` for exactly one release, 0.4.1, which has been
+yanked. crates.io cannot rename a crate, so the move was to publish under
+the new name and yank the old. The old name stays reserved under this
+account either way, so nobody else can claim it.