CLI baseline: no version at all, --help exits 1, and the kiln release ships a binary named kilnd

[avrabe]

Part of an org-wide CLI survey across the verified varve layer 2026.08.2 plus the v0.4.4 release — matrix and baseline in pulseengine.eu#167.

What is good here

The flag surface is well-chosen and reads like someone actually ran embedded workloads: --fuel, --memory, --no-std, --memory-profile, --no-platform-opt are the knobs that matter for a bounded runtime, and the WASI group (--wasi-fs, --wasi-env, --wasi-arg) is complete rather than partial. --wasi-fs even documents its own alias inline — (alias: --dir) — which is more courtesy than most tools manage.

--component [<path>] + --invoke <export> is the right shape for a Component Model runtime: run a component and print an export's result in one line.

Three problems

1. No version, by any means.

$ kilnd --version
WebAssembly Runtime Daemon (kilnd)      (exit 1)
$ kilnd -V
WebAssembly Runtime Daemon (kilnd)      (exit 1)

It prints the banner and exits 1. Nothing in --help carries a version either. kiln is the runtime that executes other tools' artifacts — e.g. witness' --harness cross-check path runs modules under kilnd — so "which runtime produced this run" is precisely the question a coverage or timing result needs to answer, and it currently cannot.

2. --help exits 1. Asking for help is not an error; it should exit 0. Unknown flags should be the ones exiting non-zero (2, per the baseline).

3. The release ships a binary whose name is not the project's.

$ tar tzf kiln-v0.4.4-aarch64-apple-darwin.tar.gz
./kilnd

Repo kiln, tarball kiln-v0.4.4-…, binary kilnd. The varve layer therefore exposes kilnd, so a user reading the roster for "kiln" finds no such command. Worth deciding deliberately: either rename the binary to kiln, or state that kilnd is the binary everywhere the project is named.

Related, and maybe the root of it: the name says daemon, the CLI is a one-shot runner — kilnd [OPTIONS] <module.wasm> executes a module and exits. If it is not a resident process, kiln is the more honest name.

Ask

1. --version/-V print <binary-name> <semver>, exit 0.
2. --help exits 0; unknown flag exits 2.
3. Decide the binary name and make repo, tarball, layer entry and roster agree.

Enforce (1) with a release step that runs the freshly built binary and asserts --version == the tag — varve added this after pulseengine/varve#38 and it would have caught all three of the version failures we found this week.

🤖 Generated with Claude Code

[avrabe]

Version half fixed and shipping in v0.4.5 (PR #495, merged as 07d19726; release PR #498). Tracked as rivet SR-55.

Ask 1 — done. --version and -V now print kilnd <semver> and exit 0:

$ kilnd --version
kilnd 0.4.5          (exit 0)

Ask 2 — done, with a correction. Unknown flags now exit 2 with usage on stderr (stdout empty). But your report says --help exits 1 — measured on main it already exited 0 (that arm ends in process::exit(0)), so nothing needed changing there. It's now pinned by a test either way.

Worse than you found. The root cause was _ => {}, // Ignore unknown flags in the parser, which didn't just ignore the flag — it ate the following operand:

kilnd --memroy 65536 mod.wasm     # typo of --memory

dropped the cap and mis-consumed the module path, so the module could run unbounded. Same "configured control that never takes effect" class as SR-44/SR-45. Also, -V was falling through a !starts_with("--") positional guard and being treated as the module path — hence "failed to read module".

Your enforcement ask is in as kilnd/tests/cli_baseline_tests.rs (6 tests), including reported_version_is_the_crate_version, which asserts the reported version equals CARGO_PKG_VERSION — the version the tag is cut from. It passed across the 0.4.4→0.4.5 bump, so it demonstrably tracks a real version change rather than a frozen string.

Ask 3 — deliberately not taken; leaving this issue open for it. Renaming the shipped binary to kiln breaks every existing invocation, and "document kilnd everywhere" is equally a project-identity call. That's yours, not mine to make unilaterally. Happy to implement either once you decide — including the varve roster/layer entry updates if it's the rename.

Also worth flagging from this work: the security gate had been red on main since July (6 RUSTSEC advisories disclosed after the v0.4.4 tag, and nothing re-ran Rust CI in between). Cleared in #496 / SR-56, also shipping in v0.4.5.