nordisk/znippy

znippy-cli — crate card

Reverse-engineered (from source — verify, don't trust the name)

• One-line pitch: The znippy command-line tool — clap-based front end wiring compress/decompress/list/verify/handlers/run over the workspace crates.
• Does: lib.rs defines the clap Cli/Commands (compress with --format/--meta-format/--warehouse/--plugin, decompress, list, verify, handlers, run) and the run() entry point that main.rs calls. handlers.rs is the single plugin-registration point (builtin_handlers()) — the CLI autodiscovers handlers via each plugin's meta(), with find_handler resolving --format by name/alias. Optional iceberg and sign features gate the Iceberg meta backend and CMS provenance.
• Version stamp: znippy --version / -V prints znippy v<CARGO_PKG_VERSION> (<git hash>) and exits (clap's version flag; command name znippy + VERSION_LINE). The short SHA comes from build.rs, which reads it straight from the on-disk git metadata with pure std::fs — NO Command::new("git"), per the zero-shell law. build.rs walks up from the crate manifest to the workspace .git, handles a symbolic or detached HEAD, packed-refs, and linked worktrees (.git pointer file + commondir), and emits cargo:rustc-env=ZNIPPY_GIT_HASH=<7-char sha> (falling back to unknown off a checkout). lib.rs exposes it as pub const GIT_HASH / VERSION_LINE (built with env!, the ONE identity source) so the znippy bin in the parent crate inherits the same string via run().
• Introspection: every verb self-reports a functional_status row (compress→archive_written, verify→integrity_checksum, decompress→reconstruct_verify, sign→compress-sign/signer_loaded, verify-signed→provenance_chain, plus append/run) — GREEN on success, RED on failure — behind the optional testmatrix feature (an #[inline] no-op with no nornir dep in the default build). Red-when-broken tests: green_roundtrip_then_red_on_corruption and build_signer_missing_cert_emits_red_row. See .nornir/quality-matrix.md for the full surface table.
• Key deps: clap (derive), znippy-compress, znippy-decompress, znippy-common (host-decompressors + wasm-plugins), the three plugin crates (maven/python/media) plus the native handlers from common, optional znippy-iceberg, env_logger.
• Shape: both (lib + znippy bin via main.rs), ~600 LOC: lib.rs (516), handlers.rs (84), main.rs (3).
• Observed role in the workspace: Top of the stack — the top-level znippy crate is just a bin wrapper that calls znippy_cli::run(). This is where all handlers get registered and all verbs dispatch.

Fill in (one line each — only the human knows these)

• Primary consumer(s):
• Why it exists (vs the obvious alternative):
• Hard constraint (airgap / no-C-deps / no-FFI / pure-Rust / etc.):
• Release cadence & independence (rides a parent? own repo someday?):
• Status (production / prototype / experimental / stubbed):
• Must-NOT-change invariant:
• Biggest known gap or TODO:
• Anything a newcomer would get wrong about it: