nordisk/holger

holger-znippy-gem-repository — crate card

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

• One-line pitch: znippy-archive-backed RubyGems repository — the subset of the RubyGems API needed for bundler/gem install.
• Does: GemRepoZnippy implements RepositoryBackendTrait serving the gem bytes (/gems/{name}-{ver}[-{platform}].gem), the compact-index info/{name} file, and the versions file. Backed by a concrete ZnippyArchive it uses the typed gem view (as_gem): name/version/platform come from index columns the plugin parsed out of the gem's metadata.gz, so a platform-suffixed native gem (foo-1.2.3-java.gem) resolves by real coords instead of folding the platform into the version. R1 fix: info/versions serve a REAL compact-index built from authoritative coords (not the old ---\n YAML stub).
• Key deps: traits, znippy-common (typed gem view), anyhow.
• Shape: lib, single lib.rs. Shared znippy-backend pattern.
• Observed role in the workspace: Registered in server-lib as repository-znippy-gem. Per CLAUDE.md "real RubyGems compact-index".

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: