nordisk/znippy-zoomies

lzip-parallel — crate card

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

• One-line pitch: A pure-Rust parallel ZIP (.zip) decompressor that scans the Central Directory and DEFLATE-decodes entries across cores.
• Does: Parses the ZIP Central Directory at the file tail into Vec<EntryLocation>, dispatches each entry to a rayon worker for independent DEFLATE decode, reassembles in Central-Directory order. In-memory slices < 10 MB decode in one parallel pass; larger/streaming (Read + Seek) inputs use tail-seek parsing + parallel batches of 64 without loading the whole file into RAM. Public API: ZipEntry/ZipError, StreamingZipRead, thread_pool(). Modules: batch, central_dir, chunk, deflate_scan, entry, parallel, reader.
• Key deps: rayon (dedicated pool, LZIP_THREADS override), intra-workspace linflate (DEFLATE core). Optional: flate2 zlib-ng (zlib-ng feature), zip (gen feature for fixtures). Dev: zip, tempfile, miniz_oxide, criterion.
• Shape: lib + bin lzip (667 LoC); ~2.6k LoC. doctest = false. Bench inflate_bench. NB: package name is lzip-parallel but crate/bin/doc name is lzip.
• Observed role in the workspace: Standalone parallel ZIP decoder; near-identical twin of ljar (generic .zip vs JAR) sharing the linflate core. No in-workspace dependents observed.

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: