← The ledger
Receipt 004Developer tooling

A solo Rust tool that installs like a real product

The falsifiable questionCan one person ship a native developer tool with the full distribution surface — versioned releases, checksums, a Homebrew tap, a landing page — not just a repo?

ARunnable artifactearnedTap formula + 2MB binaries serving over HTTP
BMeaningful baselinewithheldNo measured comparison against existing monitors
MMeasured resultearned2,071,219-byte arm64 tarball, pinned SHA-256s
RReproducible methodearnedbrew install perf-pulse is the rerun
FDocumented failureearnedTap lagged source 1.3.1 vs 1.6.0; flaky test hardened
EExternal validationwithheldNo install counts or user reports yet

Baseline withheld (no measured comparison against existing monitors); external withheld until install counts or user reports exist.

Baseline

The default fate of side-project CLIs: a GitHub repo you must clone and compile yourself, with no releases, no checksums, and no upgrade path.

Method

PerfPulse: a Rust system-monitor for developers (23 modules, LTO release profile, CLI + TUI + web dashboard surfaces). Distribution: versioned tarballs for darwin-arm64 and x86_64 with pinned SHA-256 hashes, a public Homebrew tap with an install test, and a landing page with install instructions.

Measured result

brew install works against real binaries: the v1.5.4 darwin-arm64 tarball serves HTTP 200 at 2,071,219 bytes. The tap formula pins both architectures with SHA-256 hashes and runs a --version smoke test on install.

Where it broke

The tap lagged the source for a stretch — formula at 1.3.1 while the changelog reached 1.6.0 — meaning users could install stale builds. The changelog also documents a flaky iostat-dependent test that had to be deterministically hardened. Release automation is the open gap.

Updates

  • Published to the ledger.

Next test

Wire release automation so the tap can never lag source again, then publish install telemetry.