The command-line tool

vlb is a small command-line program that works over the same loadbook the desktop and Apple apps use. It doesn’t replace them — it’s a second, scriptable view, for terminal users and automation. It shares the app’s live data file safely, so you can vlb log a string from a terminal while the desktop app is open, and each sees the other’s writes.

What it’s for

• Automation and CI. Every machine-readable (--json) output is a stable, frozen shape, so scripts can depend on it — pipe it straight to jq.
• Fast keyboard-driven work. The reverse candidate explorer, one command away, no UI.
• A power user’s second view of the same loadbook the apps keep.

The read verbs

• reverse — survey the powder-and-charge candidates for a target velocity (the candidate explorer).
• predict — forward-predict one load: muzzle velocity with its interval, %MAP, case fill, and grade.
• cartridges / bullets / powders — list the embedded component catalog (the exact names the other verbs expect).
• loads — list your logged loads (recipes).
• ammo — list your ammo and their load counts, each with its target velocity.
• strings — list a load’s shot strings with their measured per-string statistics.

Add --json to any of them for machine-readable output. A quick taste:

vlb reverse --cartridge "6.5 Creedmoor" \
  --bullet "Hornady 6.5mm 140 gr BTHP Match" --target-fps 2700

The one write verb

log appends one immutable chronograph string to a load — typed, pasted, or from a chronograph CSV (ShotView, LabRadar, Garmin Xero, generic). It stores your raw velocities exactly as measured — append-only, never transformed, never deleted (exclude a flyer with a flag, never an edit) — and echoes back the measured mean, SD, and ES with their intervals.

The same honesty stance

vlb carries the identical referee framing as the apps — it never softens it for the command line:

• reverse surveys candidates, it never recommends. Results are labelled modeled hypotheses to verify, sorted by model confidence — “not by quality.” There is no accuracy, node, or “best” field anywhere. When a survey comes back empty it says why — bullet or cartridge not matched, target too high (over MAP) or too low (under the fill floor), or filters too strict — and --json carries that as an additive empty_reason plus a per-reason diagnostics tally.
• Pressure is shown only as a percentage of SAAMI maximum — never green, never “safe”; an over-MAP caution appears when the modeled high end crosses the limit.
• Every prediction carries an interval and a calibration grade (Estimated → Provisional → Calibrated to your rifle).
• Nothing silently no-ops. An unresolved load, an uncatalogued combination, or unparseable input exits with an honest message and writes nothing.

Where it reads and writes

By default vlb uses the app’s data file — the same one the desktop and Apple apps read and write — so it’s a first-class second view of your data. Point it elsewhere with --db <path> or the $LOADBOOK_DB environment variable, handy for scratch or CI runs. Concurrent use is safe: a terminal and the desktop app each see the other’s committed writes.

Run vlb --help (and vlb <command> --help) for terse, example-carrying built-in help.