nordisk/holger

holger — AI context (full API & source reference)

Read ai-context.md first. This is not normal prompt context — it is a lookup reference for exact public-API signatures, selected private APIs, complete rustdoc and file:line sources. Do not load it for every task.

Snapshot

⚠ Dirty working tree — this snapshot is NOT reproducible. It reflects uncommitted local changes, not commit a843b3260e01.

Navigation

Architecture, runtime wiring, security invariants, failure semantics, the trust lifecycle, the state inventory and the task map all live in ai-context.md:

• Runtime wiring map
• Non-negotiable invariants
• Failure semantics
• Task-to-file map
• Trust and lifecycle
• State and persistence

Crate and module map

The indexed count (42) is the 42 workspace members that expose a src/ tree plus 0 detached package(s) (own [workspace], indexed for their API but outside the dependency graph). Detached packages are in the API index; they are not in the workspace dependency graph.

Workspace dependency graph

Garmr workspace crates only (external deps excluded); edges deduplicated, kind + feature-gate marked.

Central external dependency hotspots

Only architecturally meaningful dependencies. Used by is derived from Cargo metadata.

High-coupling crates

Dependency validation:

• duplicate workspace edges after dedup: 0 (must be 0)
• external dependency present in workspace graph: false (must be false)
• workspace crates: 42, workspace edges: 99, external deps: 95
• dependency kind retained per edge; feature-gated edges marked

API reference

Every exported item (plus security-relevant private items), grouped by change-relevance, then crate → module. Each entry: signature, file:line, and its rustdoc.

Core contracts

(no crates in this group)

Runtime and CLI

(no crates in this group)

Ingest

(no crates in this group)

Storage, search, query

(no crates in this group)

Detection, policy, catalog, baselines

(no crates in this group)

Agent, LLM, tools

(no crates in this group)

Governance, audit, actions

(no crates in this group)

Retention, backup, HA

(no crates in this group)

API and UI

(no crates in this group)

Development tooling

Crate holger-agent-cli

Holger agent CLI: airgap and transfer artifacts between registries

Module holger_agent_cli

enum Source { World, Nexus, Artifactory, Holger, Znippy, TarZstd, Directory } · src/main.rs:11

enum Target { Znippy, TarZstd, Directory, Nexus, Artifactory, Holger } · src/main.rs:33

enum AuthMode { Oidc, Mtls } · src/main.rs:52

enum LockfileKind { Cargo, RequirementsTxt, UvLock } · src/main.rs:61

Package ecosystem lockfile format.

Crate holger-agent-lib

[agent-transfer] operations.rs: transfer/push/pull with bounded concurrency and partial-success tallies.

Agent crate: the airgap courier that moves artifacts across the network boundary. This is the public facade — the actual work lives in [operations], and every endpoint is a [ConnectorTrait] (Nexus, Artifactory, crates.io/PyPI world; holger/znippy/directory live server-side).

Flow: a Source connector's assets are pulled through operations into a carriable sink — a .znippy archive, a .tar.zst, or a loose directory — then, on the secure side, pushed from that sink back into a Target connector. Download/pack and read/upload are the two halves; the archive in between is the thing that crosses the airgap.

Gotcha: an upload failure is data, not an error — one bad asset is counted and skipped so a whole push does not abort, whereas a source read/decode error short-circuits. So a successful return can still hide failed assets; check the tallies. Untrusted .tar.zst input is per-entry size-capped against decompression bombs.

Module holger_agent_lib::operations

Agent transfer engine: the concrete Source→Target moves behind the CLI, one step above the ConnectorTrait seam. Pull side downloads a connector's assets and lands them as a .znippy archive (with ecosystem pkg_type tags so the compressor runs the right plugin and the archive is natively browsable), a plain .tar.zst, or a loose directory. Push side reverses it: a directory, .znippy, or .tar.zst becomes a stream of connector.upload_asset calls.

pkg_type is derived, never literal — [pkg_type_from_format] delegates to [traits::ArtifactFormat] (znippy's own registry), and [pkg_type_for_file] is a deliberately CURATED extension table that tags only unambiguous packaging (.crate, .jar, .whl, …) and leaves ambiguous ones (.tar.gz sdist vs npm tgz) untyped for an explicit --format override; a drift-guard test pins it as a subset of znippy.

Uploads fan out through a bounded in-flight pool (znippy_zoomies::gatling, UPLOAD_CONCURRENCY): a per-asset upload failure is counted, not fatal, while a source-read/decode error short-circuits the whole push. The one gotcha: archive members are UNTRUSTED airgap input — read_capped/MAX_TAR_ENTRY_BYTES bound per-entry expansion (decompression bombs) and is_safe_member_path/safe_join reject absolute or .. paths, since a connector only trims a leading / and a stray .. could otherwise write outside the repo (or drop an RCE file on the host).

fn pkg_type_from_format(format: &str) -> i8 · src/operations.rs:91

Map a Nexus/Artifactory/CLI format string → znippy pkg_type discriminant.

znippy is the single source of truth for these numbers: this delegates to [ArtifactFormat], which derives them from znippy's own handler registry. Unknown formats map to 0 (raw / unknown).

pub(crate) fn is_safe_member_path(rel: &str) -> bool · src/operations.rs:131

true iff rel is a safe relative member path to PUSH to a connector: no absolute/root/prefix and no .. component. Archive member paths come from an untrusted airgap-carried .znippy/.tar.zst, and connector.upload_asset only trims a leading /, so a .. member could place an artifact outside the intended repo path on the target. Mirrors the safe_join component policy; shared by both push paths so an offending member is skipped+counted, never uploaded.

async fn feed_repo_to_sender(connector: Arc<dyn ConnectorTrait>, assets: Vec<RemoteAsset>, sender: crossbeam_channel::Sender<ArchiveEntry>, pkg_type: i8, repo_name: String,) -> Result<(usize, usize)> · src/operations.rs:140

Feed assets from one repo into an already-open compressor sender. Returns (downloaded, failed) counts.

async fn dump_all_repos_to_znippy(connector: Arc<dyn ConnectorTrait>, repos: Vec<traits::RemoteRepository>, output: PathBuf, sequential: bool,) -> Result<()> · src/operations.rs:179

Dump all repos from a connector into one znippy archive.

Parallel mode (default): all repos downloaded concurrently — tokio tasks share cloned senders. The compressor's bounded channel provides backpressure so memory stays bounded. Sequential mode: one repo at a time — lower peak memory and network usage.

async fn transfer_to_znippy(connector: &dyn ConnectorTrait, assets: Vec<RemoteAsset>, output: PathBuf,) -> Result<()> · src/operations.rs:248

Transfer assets from a connector to a znippy archive (single repo, no pkg_type tagging).

async fn pack_directory_to_znippy(directory: PathBuf, output: PathBuf, format: Option<& str>,) -> Result<()> · src/operations.rs:333

Build a .znippy archive from every file under directory (recursively), preserving each file's path relative to directory as its archive member path.

This is the offline inverse of [push_znippy_to_connector]: stage a tree of real artifacts (.crate, .jar+.pom, .whl, …) and pack it into one immutable, content-addressed archive carriable across an airgap. Each member is tagged with its ecosystem pkg_type (by extension, or forced by format when given) so the znippy compressor runs that ecosystem's plugin and writes the typed index columns — the archive is then natively browsable by holger (as_maven()/as_python()/…), not just a raw file bag. A format override (e.g. "python") tags every file with that ecosystem, which is how ambiguous extensions (.tar.gz sdists) get indexed.

async fn transfer_to_tar_zstd(connector: &dyn ConnectorTrait, assets: Vec<RemoteAsset>, output: PathBuf,) -> Result<()> · src/operations.rs:402

Transfer assets from a connector to a zstd-compressed tar archive (.tar.zst)

async fn transfer_to_directory(connector: &dyn ConnectorTrait, assets: Vec<RemoteAsset>, output: PathBuf,) -> Result<()> · src/operations.rs:450

Transfer assets from a connector to a directory

async fn push_directory_to_connector(connector: &dyn ConnectorTrait, directory: PathBuf, repository: &str,) -> Result<()> · src/operations.rs:497

Push assets from a directory to a connector

async fn push_znippy_to_connector(connector: &dyn ConnectorTrait, archive: PathBuf, repository: &str,) -> Result<()> · src/operations.rs:542

Push assets from a znippy archive to a connector

async fn push_tar_zstd_to_connector(connector: &dyn ConnectorTrait, archive: PathBuf, repository: &str,) -> Result<()> · src/operations.rs:589

Push assets from a tar.zst archive to a connector

async fn unpack_znippy_to_directory(archive: PathBuf, output: PathBuf) -> Result<()> · src/operations.rs:674

Unpack a znippy archive to a directory — the inverse of [pack_directory_to_znippy]. Each member is extracted and written under output at its (path-safe) relative path. Members with hostile paths (absolute or containing ..) are skipped, never written outside output.

async fn unpack_tar_zstd_to_directory(archive: PathBuf, output: PathBuf) -> Result<()> · src/operations.rs:722

Unpack a .tar.zst archive to a directory. Each regular entry is extracted (bounded by [MAX_TAR_ENTRY_BYTES] — the stream is untrusted airgap input) and written under output at its (path-safe) relative path.

async fn pack_directory_to_tar_zstd(directory: PathBuf, output: PathBuf) -> Result<()> · src/operations.rs:771

Pack a directory into a .tar.zst archive — the inverse of [unpack_tar_zstd_to_directory], and the on-disk twin of [transfer_to_tar_zstd] (which packs from a connector). Every regular file under directory is appended at its path relative to directory.

async fn convert_znippy_to_tar_zstd(input: PathBuf, output: PathBuf) -> Result<()> · src/operations.rs:819

Convert a znippy archive to a .tar.zst archive by staging through a temp directory (unpack → repack). The direct archive↔archive conversions compose the directory primitives rather than duplicating format logic.

async fn convert_tar_zstd_to_znippy(input: PathBuf, output: PathBuf, format: Option<& str>,) -> Result<()> · src/operations.rs:827

Convert a .tar.zst archive to a znippy archive by staging through a temp directory (unpack → repack). format optionally forces the znippy pkg_type.

Module holger_agent_lib::strict

Strict transfer mode + provenance receipts.

The existing transfer functions in [crate::operations] intentionally treat a per-asset failure as a tally and return Ok(()) with failures counted (the documented airgap-dump compatibility contract). This module adds an opt-in strict mode alongside that behavior — it does not change the existing functions, so best-effort semantics are preserved by construction.

In [TransferMode::Strict], any failed download, hostile asset path, size mismatch, or missing asset makes the whole operation fail (a non-zero result), a partial archive never appears under the final filename (temp + atomic rename), and a [TransferReceipt] — suitable for embedding in a signed update bundle — records every asset's dual digest with credentials stripped from all endpoints.

const DEFAULT_MAX_ASSET_BYTES: u64 · src/strict.rs:26

8 GiB per-asset cap (matches the connector download cap).

enum TransferMode { BestEffort, Strict } · src/strict.rs:30

Transfer failure policy.

struct TransferOptions { mode: TransferMode, max_asset_bytes: u64, source_type: String, source_endpoint: String, receipt_path: Option<PathBuf> } · src/strict.rs:38

Options for a strict-capable transfer.

struct TransferFailure { asset_path: String, reason: String } · src/strict.rs:66

A safe, credential-free description of one failed asset.

struct AssetRecord { source_path: String, size: u64, sha256: String, blake3: String, source_uri: Option<String> } · src/strict.rs:73

Per-asset provenance record.

struct TransferReport { requested_assets: usize, successful_assets: usize, failed_assets: usize, failures: Vec<TransferFailure>, bytes_transferred: u64, complete: bool } · src/strict.rs:84

Structured outcome of a transfer.

struct TransferReceipt { operation_id: String, mode: String, started_at: DateTime<Utc>, completed_at: DateTime<Utc>, source_type: String, source_endpoint: String, source_repository: String, destination_type: String, requested_assets: usize, successful_assets: usize, failed_assets: usize, bytes_transferred: u64, assets: Vec<AssetRecord>, failures: Vec<TransferFailure>, final_archive_digest: Option<String>, complete: bool } · src/strict.rs:95

A provenance receipt, suitable for embedding as bundle evidence.

fn strip_credentials(url: &str) -> String · src/strict.rs:134

Remove user:pass@ userinfo from the authority of a URL, if present.

async fn transfer_repo_to_znippy_with_options(connector: &dyn ConnectorTrait, repository: &str, output: &Path, opts: &TransferOptions,) -> Result<TransferReport> · src/strict.rs:170

Transfer every asset in repository from connector into a .znippy archive at output, honoring [TransferOptions::mode]. Lists assets from the connector, then delegates to [transfer_assets_to_znippy_with_options].

async fn transfer_assets_to_znippy_with_options(connector: &dyn ConnectorTrait, repository: &str, assets: &[RemoteAsset], output: &Path, opts: &TransferOptions,) -> Result<TransferReport> · src/strict.rs:186

Transfer a pre-fetched assets list from connector into a .znippy archive at output, honoring [TransferOptions::mode]. Returns a structured report. In strict mode an incomplete transfer returns Err (after writing the receipt when possible) and leaves no archive at output. Used by the CLI, where the asset list comes from a lockfile (world) or a listing (nexus/artifactory/holger).

Module holger_agent_lib::strict::TransferOptions

fn new(mode: TransferMode, source_type: impl Into<String>, source_endpoint: impl Into<String>,) -> Self · src/strict.rs:49

Crate holger-airgap

[airgap] Pure-Rust plan/argv; one shell-out to distribution/airgap/populate.

A typed Rust front-end to distribution/airgap/populate (the documented POSIX-sh build→carry→push driver). The UI Tools#5 pane and the holger-server airgap CLI verb both drive this crate, which:

• models the populate interface ([Stack], [Scale], [Target], [Auth], [PopulateArgs]) as types;
• plans an invocation in pure Rust — [PopulateArgs::validate], [PopulateArgs::stacks] (scale→stack expansion), [PopulateArgs::argv], [PopulateArgs::plan] — all unit-tested, no shell, no I/O;
• executes by delegating to the driver script (the inherently-external build/push half — docker pull, pip download, the agent's gRPC push) via [execute]. The pure-Rust core is the testable seam; only the actual carry-the-bytes work shells out, to the one sanctioned driver.

All three targets — holger / nexus / artifactory — are wired (the agent gained an --to artifactory path via agent/connector/artifactory, and lib/push.sh routes it). Artifactory pushes need ARTIFACTORY_URL in the driver's environment.

Module holger_airgap

enum Stack { Airflow, Cargo, Npm, Maven, Docker, All } · src/lib.rs:32

Which software stack(s) to populate. All expands to every stack; otherwise a single ecosystem. With no explicit stack the [Scale] preset decides.

enum Scale { Micro, Small, Large } · src/lib.rs:73

Dataset scale preset. Drives both the per-stack closure size and (when no explicit [Stack] is given) which stacks run — mirroring stacks.toml.

enum Target { Holger, Nexus, Artifactory } · src/lib.rs:118

Where to populate. All three targets push through the agent: Holger (default), Nexus, and Artifactory (routed by lib/push.sh via the agent/connector/artifactory path; needs ARTIFACTORY_URL in the driver's environment). [PopulateArgs::validate] accepts every variant (guarded by the validate_allows_artifactory_now_that_agent_is_wired test).

enum Auth { Mtls, Oidc } · src/lib.rs:149

Auth the push half uses against the target.

const DEFAULT_ENDPOINT: & str · src/lib.rs:175

The dev-pair default gRPC control door.

const DEFAULT_GATEWAY: & str · src/lib.rs:178

The dev-pair default HTTP/native + OCI gateway (holger-server dev-pair --http 127.0.0.1:18444, matching stacks.toml).

struct PopulateArgs { stack: Option<Stack>, scale: Scale, target: Target, endpoint: String, gateway: String, auth: Auth, repository: Option<String>, staging: Option<PathBuf>, build_only: bool, push_only: bool, dry_run: bool, client_cert: Option<PathBuf>, client_key: Option<PathBuf>, token_url: Option<String>, client_id: Option<String> } · src/lib.rs:185

A fully-specified populate run — the typed mirror of the populate CLI. Built by the UI Tools#5 pane / the CLI verb from the connected server's live endpoint + session auth, then validated, planned, and (optionally) [execute]d.

fn driver_in(repo_root: &Path) -> Option<PathBuf> · src/lib.rs:367

The default driver location: distribution/airgap/populate resolved against a repo root. None if it isn't there (e.g. an installed binary with no repo).

struct Report { log: String, exit_code: i32, success: bool } · src/lib.rs:374

One stack's outcome line from a populate run.

fn execute(args: &PopulateArgs, driver: &Path) -> Result<Report> · src/lib.rs:390

Execute the populate run by delegating to the driver script. The inherently-external build/push (docker/pip/agent-gRPC) lives in the driver; this captures its stdout+stderr and exit status into a [Report]. Validates first, so a not-yet-wired target / bad combo fails fast with a clear message.

NOTE: this is the one place holger shells out, and only to the documented driver (README wiring point #1). The pure-Rust planning surface above is the testable core; this is the thin execution seam.

Module holger_airgap::Auth

fn as_arg(self) -> &'static str · src/lib.rs:155

Module holger_airgap::PopulateArgs

fn validate(&self) -> Result<()> · src/lib.rs:242

Reject impossible combinations before any work:

• --build-only and --push-only together;
• mTLS without a cert+key, or OIDC without a token-url+client-id (only when actually pushing — build-only and dry-run need no creds).

All three targets (holger / nexus / artifactory) are now wired in the agent + lib/push.sh; artifactory pushes need ARTIFACTORY_URL in the driver's environment.

fn stacks(&self) -> Vec<Stack> · src/lib.rs:266

The concrete stacks this run touches: the explicit stack (with All expanded), else the scale preset's stacks.

fn argv(&self, driver: &Path) -> Vec<String> · src/lib.rs:278

Build the argv for invoking the populate driver at driver. Mirrors the flags documented in distribution/airgap/README.md exactly.

fn plan(&self) -> String · src/lib.rs:324

A human-readable, multi-line plan of what would run — the dry-run surface the UI Tools#5 pane shows before the operator commits. Pure; no I/O.

fn state_json(&self) -> serde_json::Value · src/lib.rs:350

Observable state for headless/robot tests.

Module holger_airgap::Scale

fn as_arg(self) -> &'static str · src/lib.rs:80

fn preset_stacks(self) -> &'static [Stack] · src/lib.rs:90

The stacks a bare --scale expands to (the [scales.*] table in stacks.toml): micro = airflow; small = airflow+cargo+npm; large = all.

Module holger_airgap::Stack

fn as_arg(self) -> &'static str · src/lib.rs:42

Module holger_airgap::Target

fn as_arg(self) -> &'static str · src/lib.rs:125

Crate holger-artifactory-connector

Holger connector for JFrog Artifactory (REST + AQL, basic/bearer/mTLS auth)

JFrog Artifactory connector for the holger agent — the Artifactory twin of connector_nexus, implementing the same [ConnectorTrait] so the agent's migrate / suck / push operations work against Artifactory unchanged.

API surface used (Artifactory REST + AQL):

• list repositories — GET /artifactory/api/repositories ({key, type, packageType, url}).
• list assets — AQL POST /artifactory/api/search/aql, items.find({"repo":"<repo>"}).include("repo","path","name","size"). Builds each asset's download URL from the base + repo/path/name.
• download — GET /artifactory/<repo>/<path>/<name>.
• upload (deploy) — PUT /artifactory/<repo>/<path>.

Auth mirrors the Nexus connector: HTTP Basic, OIDC/access-token Bearer, mTLS, or None. The same SSRF / credential-exfiltration guard applies on download (only same-origin URLs get credentials).

Module holger_artifactory_connector

enum ConnectorAuth { None, Basic, OidcToken, Mtls } · src/lib.rs:47

How the connector authenticates with Artifactory.

struct ArtifactoryConnector { url: String, auth: ConnectorAuth } · src/lib.rs:59

A holger-agent connector for a JFrog Artifactory instance.

Module holger_artifactory_connector::ArtifactoryConnector

fn new(url: String, username: Option<String>, password: Option<String>) -> Result<Self> · src/lib.rs:68

Build a connector with optional Basic credentials.

fn with_oidc_token(url: String, token: String) -> Result<Self> · src/lib.rs:84

Build a connector with a Bearer access token (Artifactory access token / OIDC bearer).

fn with_mtls(url: String, cert_pem: &[u8], key_pem: &[u8]) -> Result<Self> · src/lib.rs:99

Build a connector with an mTLS client cert.

Crate holger-bench-scenarios

[benchmarks] No [[bench]] targets exist; real path is nornir bench run holger / xtask examples.

Shared bench scenarios for the holger constellation.

Two consumers call into this lib:

1. repository-znippy-rust/tests/... — correctness-flavoured integration tests (#[test]), exercise the same code paths with assertions.
2. holger/xtask/examples/nornir-bench.rs — Bencher impls that nornir bench run holger drives, results land in the iceberg bench_runs table at <workspace>/.nornir/warehouse.

Keep this crate nornir-free. Persistence is nornir's job; the contract here is "build a workload, return numbers". See workspace_holger/WORKSPACE.md (Bench pattern section).

Three artifact types: Rust crates, Java jars, Python wheels.

• Location — under the home directory, never /tmp (it is tmpfs/RAM here, ~31 GiB) and never the T9 external drive. Override with HOLGER_BENCH_DIR; default $HOME/holger-bench-data.
• Size — driven by a target byte budget (Scale::target_bytes), so a huge run builds ~100 GiB of served data per type for real throughput stress. quick/full keep the old entry-count workloads.
• Freshness — fixtures are keyed by (FIXTURE_VERSION, real?, size) and a sidecar .count; a param/version change regenerates, otherwise an existing archive is reused (you do NOT want to rewrite 100 GiB every run).
• Real vs synthetic — heavy implies real. On the heavy tiers (full/huge) the fixtures default to real packages downloaded once into the cache (crates.io / Maven Central / PyPI), then replicated (re-id'd) to reach the byte budget — real bytes/compression at scale without pulling 100 GiB of distinct artifacts off public registries. The light tiers (quick/sane) stay fast synthetic (make_fake_*). HOLGER_BENCH_REAL=0 forces synthetic even when heavy; =1 forces real even on the light tiers.

Module holger_bench_scenarios

fn boot_timeout_secs(default: u64) -> u64 · src/lib.rs:105

Container boot/readiness timeout (seconds) for the JVM competitor servers (Nexus, Artifactory). JVMs are slow to start on a loaded bench host, so the per-server default is overridable with HOLGER_BENCH_BOOT_SECS.

fn ensure_container_host() · src/lib.rs:128

Make a container runtime discoverable to testcontainers before the first image.start().

testcontainers talks to a Docker-compatible socket. When DOCKER_HOST is unset it defaults to unix:///var/run/docker.sock, which does not exist on a rootless-Podman box (the socket lives at $XDG_RUNTIME_DIR/podman/podman.sock). That mismatch is the first reason the Nexus/Artifactory containers "couldn't be brought up": the bench skipped with an opaque container start failed before any image was even pulled.

This probes — only when DOCKER_HOST is unset and no docker socket is present — for the rootless Podman API socket and exports DOCKER_HOST so the existing Podman service answers testcontainers. A pre-set DOCKER_HOST (or a real docker socket) is always respected. No-op on success of either; safe to call repeatedly. Pure Rust, no shelling.

fn bench_root() -> PathBuf · src/lib.rs:166

Root dir for all bench fixtures — home directory, never /tmp (tmpfs) and never the T9 external drive. HOLGER_BENCH_DIR overrides; default $HOME/holger-bench-data.

fn real_enabled(scale: &Scale) -> bool · src/lib.rs:183

Whether to seed from real downloaded packages (crates.io / Maven Central / PyPI), fetched once into the cache then replicated to size.

Heavy implies real. On the heavy tiers (full/huge) real artifacts are the default — "heavy" means real jars/crates/wheels without having to say so. HOLGER_BENCH_REAL=0 is the explicit opt-out (force synthetic even when heavy); HOLGER_BENCH_REAL=1 forces real even on the light tiers.

struct Scale { entries: usize, bench_secs: u64, threads_mt: usize, target_bytes: Option<u64> } · src/lib.rs:194

Tunable workload knobs. entries-driven (quick/full) or target_bytes- driven (huge). Both produce metrics under the same names, so regressions are comparable as long as the scale stays constant within a series.

fn cores() -> usize · src/lib.rs:206

Available hardware parallelism — the thread count every *_mt scenario and Scale::{sane,quick,full,huge} scales to. Public so consumers (e.g. the holger_multicore_sanity matrix cell) report the same number the workload ran on.

fn total_ram_bytes() -> Option<u64> · src/lib.rs:214

Total system RAM in bytes, read purely in Rust from /proc/meminfo (MemTotal:) — never by shelling free. Returns None off Linux or if the file is missing/unparseable, so callers can fall back conservatively.

struct FairResources { cores: usize, container_mem_bytes: u64, heap_mb: u64, direct_mb: u64 } · src/lib.rs:248

Fair-resourcing knobs for the JVM competitor containers (Nexus, Artifactory).

The release-gate bench bombards Holger in-process on the full machine, so letting the Nexus / Artifactory containers fall back to their default JVM heap (~512 MB – 1 GB) — or, worse, pinning Nexus to a deliberate -Xmx512m (see [nexus::latency_tail]'s old config) — made the competitors look artificially slow. That is the core unfairness the audit flagged.

[FairResources::detect] reads THIS machine at runtime (pure Rust: [cores] = available_parallelism, [total_ram_bytes] = /proc/meminfo; never shelling nproc/free) and hands each container:

• --cpus = every logical core (matches Holger's threads_mt = cores());
• --memory = 75 % of total RAM (host + Holger keep the rest);
• a JVM max heap (-Xmx) = 50 % of the container memory + a direct- memory slice — a genuinely fair heap, which is the whole point of the comparison. The remaining ~37 % inside the cap feeds metaspace, code cache, thread stacks and OS page cache so the JVM is well-fed, not OOM-killed.

struct Throughput { ops: u64, elapsed: Duration, bytes: u64, ops_sec: f64, mb_per_sec: f64 } · src/lib.rs:372

Result of one throughput scenario. ops_sec is the headline number both no_regression and nexus_floor gates compare on.

fn build_crate_archive(n: usize) -> Result<PathBuf> · src/lib.rs:725

fn build_jar_archive(n: usize) -> Result<PathBuf> · src/lib.rs:728

fn build_pip_archive(n: usize) -> Result<PathBuf> · src/lib.rs:731

fn build_crate_corpus(dir: &Path, target_bytes: u64) -> Result<(PathBuf, usize)> · src/lib.rs:747

Build (or reuse) a synthetic crate corpus of at least target_bytes of artifact data as a znippy archive under dir, returning (archive_path, crate_count). Reuses an existing archive of the same budget.

fn build_pip_corpus(dir: &Path, target_bytes: u64) -> Result<(PathBuf, usize)> · src/lib.rs:767

Build (or reuse) a synthetic wheel corpus of at least target_bytes under dir, returning (archive_path, package_count). The Python sibling of [build_crate_corpus]: lays each wheel at packages/{name}/{file} exactly as [crate::served::run_pip_index_fetch] / [PipRepoZnippy] expect, so the served PEP 503 index resolves. Reuses an existing archive of the same budget.

fn pip_corpus(scale: &Scale) -> Result<(PathBuf, usize)> · src/lib.rs:791

The wheel corpus for a bench scale (byte-budgeted on the heavy tiers, entry-budgeted otherwise) — the same fixture the in-process pip_wheel_* arms use, so the served holger.pip_index_serve arm and the in-proc arms share one archive. real mode seeds real PyPI wheels; see [real_enabled].

fn free_disk_bytes(path: &Path) -> Option<u64> · src/lib.rs:800

Free (available-to-unprivileged) disk space in bytes on the filesystem holding path, read purely in Rust via statvfs(3) (libc) — never by shelling df. Mirrors [total_ram_bytes]'s pure-Rust RAM detection. Returns None if the syscall fails, so callers fall back conservatively.

fn free_disk_bytes(_path: &Path) -> Option<u64> · src/lib.rs:814

Non-Unix fallback: no pure-Rust free-disk probe available.

fn propose_dataset_bytes(scale: u64, free_bytes: Option<u64>) -> u64 · src/lib.rs:823

Propose a crate-corpus byte budget for scale given free_bytes available on the data filesystem: scale × 1 GiB of artifact data, clamped to ≤ 25 % of free space (headroom for the OS, the compressed archive and the page cache), and floored at 16 MiB so a tiny smoke run still has data. None free space (detection failed) leaves the want unclamped.

fn rust_crate_st(scale: &Scale) -> Result<Throughput> · src/lib.rs:898

fn rust_crate_mt(scale: &Scale) -> Result<Throughput> · src/lib.rs:911

fn java_jar_st(scale: &Scale) -> Result<Throughput> · src/lib.rs:929

fn java_jar_mt(scale: &Scale) -> Result<Throughput> · src/lib.rs:949

fn pip_wheel_st(scale: &Scale) -> Result<Throughput> · src/lib.rs:974

fn pip_wheel_mt(scale: &Scale) -> Result<Throughput> · src/lib.rs:992

Module holger_bench_scenarios::FairResources

fn detect() -> Self · src/lib.rs:263

Detect from the live machine. Falls back to a modest 8 GiB RAM assumption if /proc/meminfo is unreadable, so we never over-promise memory.

fn jvm_args(&self, extra: &str) -> String · src/lib.rs:275

JVM parameters for a fair heap, shared by Nexus (INSTALL4J_ADD_VM_PARAMS) and Artifactory (EXTRA_JAVA_OPTIONS). extra appends scenario-specific flags (e.g. GC-pause targets / logging); later flags win in the JVM.

Module holger_bench_scenarios::Scale

fn sane() -> Self · src/lib.rs:292

Sane-speed workload for the test matrix — a sub-2s multicore sanity probe, not a measurement. Small entry count + a 1s loop per phase so the holger_multicore_sanity matrix cell runs inside a normal cargo test while still exercising the lock-free read path on every core (threads_mt = available_parallelism()).

fn quick() -> Self · src/lib.rs:297

Fast workload for CI / smoke runs (~seconds total).

fn full() -> Self · src/lib.rs:302

Production-grade workload (~minutes per scenario).

fn huge() -> Self · src/lib.rs:308

~100 GiB of served data per type — large-scale ("drift") throughput stress. Needs a disk-backed bench_root() with room for 3×100 GiB.

fn is_heavy(&self) -> bool · src/lib.rs:316

Heavy = production-grade or byte-budget scale (full/huge) — the tier where [real_enabled] defaults to real downloaded artifacts. quick/sane stay synthetic. A HOLGER_BENCH_BYTES override (which sets target_bytes on any scale) also counts as heavy.

fn from_env() -> Self · src/lib.rs:324

Resolve from env: HOLGER_BENCH_SCALE = quick | full | huge (default quick); HOLGER_BENCH_BYTES overrides the byte budget (any scale becomes byte-driven). NORNIR_BENCH_QUICK=0 is honoured as full for back-compat.

Module holger_bench_scenarios::artifactory

Artifactory-vs-Holger comparison scenario — the heavy, fixture-gated sibling of [crate::nexus].

Mirrors nexus::nexus_load: it pushes the same cached corpus (crate / jar / wheel znippy archives) through a real JFrog Artifactory OSS container, then drives a served-FETCH-over-HTTP head-to-head — the SAME pure-Rust parallel GET pool ([crate::served::bombard_http_get]) against both a real Holger HTTP server and Artifactory — producing the paired holger_served_mbs + artifactory_served_mbs (+ ops_per_sec) metrics the README benches mashup bolds head-to-head. The competitor upload throughput is kept as a separate artifactory_upload_mbs publish-phase number, and the old in-process get_file() figure as holger_inprocess_read_ceiling_mbs (an internal Holger-vs-Holger regression ceiling, never beside the competitor).

Fixture gate (NOT --heavy)

Exactly like the Nexus scenario, the Artifactory testcontainer is a fixture gate: any failure to reach a container runtime / boot the server becomes an is_skip error which the bench harness records as a SKIP row, so this runs in the normal (non---heavy) pass and no-ops gracefully on a box with no Docker/Podman or where the (heavy) image cannot boot in time.

Compiled only under the artifactory cargo feature so the heavy deps (testcontainers, tokio, reqwest, agent-lib) never reach the light default build of holger-bench-scenarios.

fn is_skip(e: &anyhow::Error) -> bool · src/artifactory.rs:61

True iff e is one of our graceful skips (vs a genuine workload failure).

struct LoadOutcome { concurrency: usize, holger_served_mbs: f64, artifactory_served_mbs: f64, ops_per_sec: f64, artifactory_ops_per_sec: f64, holger_p50_ms: f64, holger_p99_ms: f64, holger_p999_ms: f64, holger_mean_ms: f64, artifactory_p50_ms: f64, artifactory_p99_ms: f64, artifactory_p999_ms: f64, artifactory_mean_ms: f64, artifactory_ok_ops: u64, artifactory_repo: String, artifactory_upload_mbs: f64, holger_inprocess_read_ceiling_mbs: f64, elapsed_ms: f64, holger_files: usize } · src/artifactory.rs:79

Outcome of [artifactory_load]: the honest, like-for-like Holger-vs-Artifactory throughput. Same shape + semantics as [crate::nexus::LoadOutcome].

HEAD-TO-HEAD (both measured the SAME way — concurrent GETs over HTTP):

• holger_served_mbs — fetched from a real Holger HTTP server.
• artifactory_served_mbs — fetched from the Artifactory HTTP server.

artifactory_upload_mbs is the publish phase (separate, not the head-to-head); holger_inprocess_read_ceiling_mbs is the internal in-process regression ceiling — NEVER placed beside the competitor.

async fn artifactory_load(scale: &Scale) -> Result<LoadOutcome> · src/artifactory.rs:352

Honest, like-for-like Holger-vs-Artifactory throughput — the sibling of [crate::nexus::nexus_load]. Upload the corpus to Artifactory (publish phase), stand up a real Holger HTTP server over the same corpus ([crate::served::start_holger_gateway]), then drive the SAME pure-Rust parallel GET pool at each over HTTP (the download-heavy head-to-head).

Returns holger_served_mbs + artifactory_served_mbs (head-to-head), artifactory_upload_mbs (publish phase, separate) and the in-process holger_inprocess_read_ceiling_mbs (internal ceiling only). Fixture-gated.

Module holger_bench_scenarios::audit

Audit-log append throughput scenario.

Drives holger's REAL [server_lib::audit::ArrowIpcAuditLog::record] — the durable audit write that fires on the hot path of every fetch / put / delete / list — in a tight serial loop, exactly how the live server drives it (one shared Arc<dyn AuditLog> across all request handlers, record taking &self and internally Mutex-synchronised). It reports the append throughput: records/sec (ops_sec) + on-disk MB/s (mb_per_sec).

Each record encodes a one-row Arrow RecordBatch, writes it to the IPC stream, and flushes the underlying BufWriter → File to the OS — the full per-request audit cost. Every event carries distinct variable-length fields (identity / repo / artifact / source-ip / detail) so no accidental constant folding hides work.

This is a single-writer measurement (the server serialises audit writes behind one mutex), NOT a fan-out — no parallelism primitive is used here.

Twin correctness coverage lives in server/lib/src/audit/* unit tests (the round-trip decode); this module is the numbers. After the burst the segment is finalized (drop writes the IPC end-of-stream marker) and re-read from disk; the row count is asserted so a broken writer fails the bench instead of silently reporting a hollow number.

fn audit_append_throughput(scale: &Scale) -> Result<Throughput> · src/audit.rs:71

Append [event_count] events through a real [ArrowIpcAuditLog], returning the throughput (records/sec = ops_sec, on-disk bytes/sec = mb_per_sec). The segment is finalized and re-read; the round-tripped row count is asserted so a broken append path fails the bench rather than reporting a hollow number.

Module holger_bench_scenarios::nexus

Nexus-vs-Holger comparison scenarios — the heavy, fixture-gated benches.

These port the two #[ignore]'d integration tests

• agent/cli/tests/integration_nexus_load.rs::test_nexus_load_with_real_artifacts
• agent/cli/tests/integration_latency_tail.rs::test_tail_latency_gc_pressure into reusable workload functions that both the nornir Bencher harness (xtask/examples/nornir-bench.rs) and downscaled correctness twins (agent/cli/tests/integration_nexus_bench_twin.rs) call.

Fixture gate (NOT --heavy)

"heavy" means large scale, not needs infra. The Sonatype Nexus 3 testcontainer is a fixture gate: each scenario tries to start/connect to it and, if Docker/Podman or the image is unavailable, returns Err(NexusUnavailable) which callers map to a recorded skip, not a failure. So these run in the normal (non---heavy) bench pass; they just no-op gracefully wherever there is no container runtime.

This module is compiled only under the nexus cargo feature so the heavy deps (testcontainers, tokio, reqwest, agent-lib) never reach the light default build of holger-bench-scenarios.

fn is_skip(e: &anyhow::Error) -> bool · src/nexus.rs:48

True iff e is one of our graceful skips (vs a genuine workload failure).

struct LoadOutcome { concurrency: usize, holger_served_mbs: f64, nexus_served_mbs: f64, ops_per_sec: f64, nexus_ops_per_sec: f64, holger_p50_ms: f64, holger_p99_ms: f64, holger_p999_ms: f64, holger_mean_ms: f64, nexus_p50_ms: f64, nexus_p99_ms: f64, nexus_p999_ms: f64, nexus_mean_ms: f64, nexus_upload_mbs: f64, holger_inprocess_read_ceiling_mbs: f64, elapsed_ms: f64, holger_files: usize } · src/nexus.rs:71

Outcome of [nexus_load]: the honest, like-for-like Holger-vs-Nexus throughput.

HEAD-TO-HEAD (both measured the SAME way — concurrent GETs over HTTP):

• holger_served_mbs — fetched from a real Holger HTTP server ([crate::served::start_holger_gateway], the native HTTP door).
• nexus_served_mbs — fetched from the Nexus HTTP server.

PUBLISH PHASE (separate, NOT the head-to-head): nexus_upload_mbs is Nexus's upload throughput while the corpus is pushed in. Kept for context; Holger's symmetric publish-over-HTTP is the next step (see module docs / holger-ds).

INTERNAL CEILING (NOT a competitor comparison): holger_inprocess_read_ceiling_mbs is the old in-process get_file() figure — a Holger-vs-Holger release-regression ceiling only. Deliberately kept apart from the served head-to-head so a demo can never show it beside Nexus.

struct TailOutcome { p50_ms: f64, p99_ms: f64, throughput_mbs: f64, samples: usize, heap_mb: u64 } · src/nexus.rs:102

Outcome of [latency_tail]: tail-latency percentiles under GC pressure.

async fn nexus_load(scale: &Scale) -> Result<LoadOutcome> · src/nexus.rs:278

Honest, like-for-like Holger-vs-Nexus throughput. The realistic registry workload is download-heavy, so the core number is a served-FETCH phase run identically against both: upload the corpus into Nexus, stand up a real Holger HTTP server ([crate::served::start_holger_gateway]) over the same corpus, then drive the SAME pure-Rust parallel GET pool ([crate::served::bombard_http_get]) at each — HTTP fetch vs HTTP fetch.

Returns holger_served_mbs + nexus_served_mbs (the head-to-head), Nexus's nexus_upload_mbs (publish phase, separate), and the in-process holger_inprocess_read_ceiling_mbs (internal regression ceiling only). Fixture-gated: returns an is_skip error if no container.

async fn latency_tail(scale: &Scale) -> Result<TailOutcome> · src/nexus.rs:415

Start Nexus with a fair heap (detected from this machine — ~50 % of the container memory, all cores, ~75 % RAM), upload archives, then record per-request latencies and compute p50/p99 plus throughput. Fixture-gated.

FAIRNESS (årsstädning 2026-06-28): this scenario previously pinned Nexus to a deliberate -Xms512m -Xmx512m to "force GC pressure" — i.e. it handicapped the competitor to a tiny heap while Holger ran on the whole box. That made the p99 comparison dishonest, so we now give Nexus the same fair heap as [nexus_load]. The MaxGCPauseMillis=50 target + GC logging are kept as the only scenario-specific tuning. heap_mb reports the fair heap actually used.

Module holger_bench_scenarios::promote

Promotion-through-jera throughput scenario.

Seals a burst of distinct artifacts through the REAL [server_lib::promote::PromotionEngine] with a durable [jera::jobs::JobStore] ledger attached, then reports the throughput of the whole hot path a live promotion runs:

1. blake3 content-address the bytes,
2. write the content-addressed blob (atomic tmp+rename),
3. create the exclusive ref (the immutability seal),
4. write the running → done job row into the redb ledger.

Distinct bytes per artifact defeat content-address dedup, so every seal does the full blob write + a fresh ledger row — the realistic per-promotion cost. The ledger is a single-writer redb file (exactly how the server drives it), so this is a serial writer measurement, not a fan-out.

Twin correctness coverage lives in server/lib/src/promote/mod.rs unit tests (seal_records_a_done_job_in_the_ledger et al.); this module is the numbers.

fn promote_ledger_throughput(scale: &Scale) -> Result<Throughput> · src/promote.rs:60

Seal [seal_count] distinct artifacts through a real [PromotionEngine] with a jera job ledger attached, returning the throughput (seals/sec = ops_sec, bytes/sec = mb_per_sec). Every seal is a durable done job in the ledger; the count is asserted at the end so a broken ledger fails the bench instead of silently reporting a hollow number.

Module holger_bench_scenarios::retention

Retention/GC planner throughput scenario.

Runs holger's real, grouped [server_lib::retention::plan_retention] over a synthetic corpus of artifact records and pits it head-to-head against a naive baseline — the O(n²) full-scan an ad-hoc "keep last N versions" script writes when it doesn't group first (for each record, scan every other record to count newer same-name versions). Both compute the same keep/delete verdict (asserted equal), so the numbers are an honest "holger's planner is faster at the identical result" comparison.

Wide, contested, system-prefixed metrics so the README mashup auto-discovers holger_* vs naive_* per suffix: records_per_sec, plans_per_sec, mean_ms, p50_ms, p99_ms, metadata_mbs. holger wins every column at scale (grouped-once vs scan-per-record).

Twin correctness coverage lives in server/lib/src/retention.rs unit tests + server/lib/tests/retention_adapter.rs; this module is the numbers.

struct RetentionThroughput { records: usize, names: usize, holger_iters: usize, naive_iters: usize, delete_count: usize, holger: SystemNums, naive: SystemNums, large_records: usize, large_records_per_sec: f64, large_plans_per_sec: f64, large_mean_ms: f64, large_delete_count: usize } · src/retention.rs:139

The full head-to-head result: both systems' numbers + the shared correctness witness (identical delete count) and corpus shape, plus holger's throughput at a much larger, holger-only corpus (the heavy absolute number).

struct SystemNums { records_per_sec: f64, plans_per_sec: f64, mean_ms: f64, p50_ms: f64, p99_ms: f64, metadata_mbs: f64 } · src/retention.rs:157

One system's public numbers (flat, so the bench runner can splat them into the metric map with the right prefix).

fn retention_planner_throughput(scale: &Scale) -> Result<RetentionThroughput> · src/retention.rs:183

Run the retention planner head-to-head. holger's grouped planner and the naive O(n²) baseline each run iters plans over the same corpus with the same keep_last_n; both delete counts must agree. Returns both systems' throughput

• latency numbers.

struct RetentionExecutorNums { records: usize, names: usize, delete_count: usize, deleted: usize, reclaimed_bytes: u64, reclaim_per_sec: f64, reclaim_mbs: f64, reclaim_ms: f64, dryrun_per_sec: f64, dryrun_mbs: f64, dryrun_iters: usize } · src/retention.rs:286

The executor's public numbers.

fn retention_executor_throughput(scale: &Scale) -> Result<RetentionExecutorNums> · src/retention.rs:349

Run the retention executor throughput bench: preview (dry-run) then real reclaim over a live file-backed repo. Returns both throughput numbers plus the correctness witness (deleted == planned delete_count).

Module holger_bench_scenarios::secure_update

Secure Update Gateway bundle-path throughput scenario.

This is holger's unique capability: the network-free signed holger.update-bundle/v1 format with a two-person approval + release-signature trust model and a fully offline verifier. Artifactory and Nexus have no equivalent, so — unlike the nexus/artifactory head-to-heads — this bench measures holger against itself: it drives the REAL [holger_update_bundle] lifecycle and reports the throughput of each stage.

Lifecycle (the live tooling path — holger-bundle / holger-verify / the offline server import):

prepare  → approve ×2 (distinct signers) → finalize (release signature)
         → [cross airgap] → verify (offline) → anti-rollback → import (atomic)

Four arms, each a serial measurement (one bundle is an inherently sequential unit of work — no rayon/thread::spawn pool is used, exactly like the single-writer audit bench):

• [bundle_prepare_throughput] — MB/s of artifact bytes packed into a candidate bundle. This is the znippy path.
• [bundle_sign_finalize_throughput] — bundles/sec through approve×2 + finalize (ed25519 detached approval signatures + the ed25519 release signature over the manifest, signer identity = X.509).
• [bundle_verify_throughput] — MB/s of the offline verifier, the protected-side gate that runs before anything touches the data root.
• [bundle_import_throughput] — MB/s of atomic import (verify-before-extract into a fresh tree via staging-dir + rename) into the protected data root, plus the anti-rollback accept.

Delta vs whole-payload (the znippy question)

bundle_prepare packs the whole payload — it does NOT delta/patch against a prior bundle. prepare::Preparation::build inserts each payload's full bytes as a member (update-bundle/src/prepare.rs:82), and container::pack_bundle stages every member and calls znippy_compress::compress_dir(&staging, …) (`update-bundle/src/container.rs …

fn bundle_prepare_throughput(scale: &Scale) -> Result<Throughput> · src/secure_update.rs:271

bundle_prepare — MB/s of artifact bytes packed into a candidate bundle (the znippy path). Each iteration builds a candidate from a fresh firmware image and packs it to a .holger.znippy archive on disk. mb_per_sec is source artifact MB/s; ops_sec is candidates/sec.

ANSWER floor: the packed archive round-trips through load_bundle, the payload member's SHA-256 matches the source bytes, and it is stored whole (the packed member's uncompressed size equals the source size — proof this is a whole-pack, not a delta).

fn bundle_sign_finalize_throughput(scale: &Scale) -> Result<Throughput> · src/secure_update.rs:344

bundle_sign_finalize — bundles/sec through approve×2 (two distinct ed25519 signers) + finalize (the ed25519 release signature over the release manifest, signer identity X.509). A small artifact isolates the signing cost from payload hashing. ops_sec is finalized-bundles/sec.

ANSWER floor: finalize returns a VerifyReport with exactly the two required approvals and a release signer distinct from both approvers (finalize also self-verifies, so a bundle that would not verify is never emitted).

fn bundle_verify_throughput(scale: &Scale) -> Result<Throughput> · src/secure_update.rs:450

bundle_verify — MB/s of the offline verifier (the protected-side gate). Builds one finalized bundle, then loops verify_bundle_file (fully offline: digest re-check of every covered member + the ed25519 release signature). mb_per_sec is artifact MB/s verified; ops_sec is verifications/sec.

ANSWER floor: every verification accepts the honest bundle with exactly 2 approvals, AND a single-byte-tampered copy is rejected.

fn bundle_import_throughput(scale: &Scale) -> Result<Throughput> · src/secure_update.rs:509

bundle_import — MB/s of atomic import into the protected data root. Each iteration verifies-then-extracts the bundle into a fresh tree (staging dir + atomic rename — no partial tree ever visible) and records the accepted sequence in the anti-rollback store. mb_per_sec is artifact MB/s imported; ops_sec is imports/sec.

ANSWER floor: the extracted payload/firmware.bin bytes equal the source, AND the anti-rollback state rejects a replay (same sequence, different bytes) and a downgrade (lower sequence) while accepting an exact idempotent re-import.

Module holger_bench_scenarios::served

Served-over-HTTP driver — the honest comparison foundation.

Why this module exists (årsstädning 2026-06-28 fairness fix, part 2)

The Nexus / Artifactory comparison scenarios used to measure Holger in-process (repo.get_file() — no syscall, no HTTP framing, no TLS) while the JVM competitors were measured over HTTP. That is not a comparison. The rule from the audit: when you measure Holger's package delivery you MUST go via the package protocol — Holger's real native HTTP door ([RepositoryBackendTrait::handle_http2_request], the very path stock cargo/pip/npm hit, served by [start_http_gateway]).

This module stands up a real Holger HTTP server (the same [start_http_gateway] the production holger serve / dev-pair path uses), then drives a pure-Rust, gatling-style parallel GET pool ([bombard_http_get]) against it — the exact same over-the-wire workload the competitors get. The result (holger_served_mbs) is the like-for-like head-to-head number; the old in-process figure is kept only as an internal "Holger-vs-Holger regression ceiling" ([inprocess_read_ceiling]), never placed beside the competitor.

Reuse note — this is the holger-ds foundation

The publish + fetch-over-protocol pieces here are deliberately standalone, callable functions (not buried in one scenario): the upcoming holger-ds tool drives Holger's served protocol the same way. Keep [start_holger_gateway] / [bombard_http_get] / [crate_download_urls] generic and reusable.

fn capture_container_logs(container: &ContainerAsync<GenericImage>, label: &str) · src/served.rs:54

Perfect instrumentation for the JVM competitor containers (Nexus, Artifactory): stream the container's combined stdout+stderr to a host log file in real time, so startup/crash detail (e.g. Artifactory's master.key / join.key / Access bootstrap) is fully visible instead of an opaque "skipped". Best-effort — capture failures never affect the bench. Writes $HOLGER_BENCH_DIR/<label>-container.log (falls back to /tmp). Call right after image.start().

struct HttpFetchOutcome { ops: u64, bytes: u64, mbs: f64, ops_per_sec: f64, ok_ops: u64, p50_ms: f64, p99_ms: f64, p999_ms: f64, mean_ms: f64 } · src/served.rs:79

Aggregate outcome of one over-the-wire GET bombardment.

async fn start_holger_gateway(repos: Vec<(String, Arc<dyn RepositoryBackendTrait>)>,) -> Result<SocketAddr> · src/served.rs:128

Stand up a real Holger native-HTTP server for repos and return the bound loopback address (e.g. 127.0.0.1:54321). This is the same [start_http_gateway] the production serve / dev-pair path uses — cleartext loopback (the competitors also run cleartext HTTP on loopback, so the transport is symmetric), open auth, no-op audit, 1 GiB body cap.

Must be called from within a Tokio runtime (the gateway tokio::spawns its accept loop). Polls GET /healthz until the listener answers (or a short timeout elapses) so callers can fetch immediately on return.

repos is (route_name, backend): the gateway routes /{route_name}/… to that backend's handle_http2_request, exactly as cargo/pip/npm reach it.

IMPORTANT: drive this from a multi-thread Tokio runtime (e.g. Builder::new_multi_thread). The companion [bombard_http_get] pool blocks OS threads; on a single-thread runtime that blocking would starve this gateway's accept loop and no request would ever be served.

fn crate_download_urls(base: &str, repo: &str, files: &[String]) -> Vec<String> · src/served.rs:167

Build the cargo crate-download URLs (/{repo}/crates/{name}/{ver}/download, the real sparse-protocol fetch path) for every {name}-{ver}.crate file in files. Files that don't parse as name-version.crate are skipped.

fn pip_download_urls(base: &str, repo: &str, files: &[String]) -> Vec<String> · src/served.rs:185

Build the wheel/sdist download URLs (/{repo}/packages/{name}/{filename}, the real PEP 503 fetch path pip/uv hit after resolving the index) for every packages/{name}/{filename} entry in files. Non-packages/ entries are skipped. Mirrors [crate_download_urls] for the Python journey.

fn pip_index_urls(base: &str, repo: &str, files: &[String]) -> Vec<String> · src/served.rs:196

Build the PEP 503 simple detail-page URLs (/{repo}/simple/{name}/, one per unique package) from packages/{name}/… entries — the index-resolve step pip/uv do before downloading. Deduplicated, insertion order irrelevant.

fn bombard_http_get(urls: &[String], concurrency: usize, dur: Duration) -> HttpFetchOutcome · src/served.rs:223

Pure-Rust, gatling-style parallel GET pool (no curl/wrk shelling): spawn concurrency worker threads, each holding a keep-alive reqwest::blocking client and looping random GETs over urls until dur elapses, summing bytes actually read off the wire. This is the symmetric over-the-wire workload used against all three systems (Holger, Nexus, Artifactory).

Unauthenticated variant — for targets (Holger open-auth loopback, Nexus anonymous-read raw repos) that serve GETs without credentials. When a target requires auth on read (Artifactory OSS returns 401 to anonymous GETs), use [bombard_http_get_auth] so the head-to-head transport actually reaches the bytes instead of measuring a wall of 401s as ~0 MB/s.

fn bombard_http_get_auth(urls: &[String], auth: Option<(& str, &str)>, concurrency: usize, dur: Duration,) -> HttpFetchOutcome · src/served.rs:233

As [bombard_http_get], but each GET carries HTTP Basic credentials when auth is Some((user, pass)). Artifactory OSS rejects anonymous reads (401), so its leg of the head-to-head must authenticate; Holger (open auth on the loopback bench) and Nexus (anonymous raw read) pass None. Basic auth is a constant per-request header — the like-for-like transport (concurrent HTTP GET over loopback) is unchanged.

async fn run_crate_fetch(archive: &Path, repo: &str, target: Option<& str>, concurrency: usize, dur: Duration,) -> Result<(usize, HttpFetchOutcome)> · src/served.rs:348

The holger-ds artifact-delivery run: open a synthetic crate archive, expose it over Holger's native HTTP door under route repo (or, when target is Some(base_url), drive an already-running Holger at that base instead of standing one up), then bombard the crate-download path with the gatling pool — measured over the package protocol, never in-process. Returns (file_count, outcome).

Pure reuse: [start_holger_gateway] + [crate_download_urls] + [bombard_http_get] — the exact same over-the-wire path as the competitor head-to-head. A target is expected to serve the matching /{repo} corpus.

Must run inside a multi-thread Tokio runtime (see [start_holger_gateway]).

struct PipServeOutcome { files: usize, packages: usize, wheel: HttpFetchOutcome, index: HttpFetchOutcome, inprocess_ceiling_mbs: f64 } · src/served.rs:394

Aggregate outcome of the holger-ds Python-index journey: the wheel download head-to-head (headline MB/s + ops/s), the PEP 503 index-resolve arm (ops/s — the /simple/{name}/ step, which also computes+caches the SHA-256 pip/uv verify), and the internal in-process read ceiling.

async fn run_pip_index_fetch(archive: &Path, repo: &str, target: Option<& str>, concurrency: usize, dur: Duration,) -> Result<PipServeOutcome> · src/served.rs:415

The holger-ds Python journey run: expose a synthetic wheel corpus over Holger's PEP 503 / PEP 691 simple index (the very door uv/pip hit), then bombard both the wheel-download path and the index-resolve path with the gatling pool — measured over the package protocol, never in-process. The Python sibling of [run_crate_fetch]: same [start_holger_gateway] + [bombard_http_get], a [PipRepoZnippy] backend instead of a crate one.

When target is Some(base_url) an already-running Holger is driven instead of standing one up (it must serve the matching /{repo} corpus). Must run inside a multi-thread Tokio runtime (see [start_holger_gateway]).

fn inprocess_read_ceiling<F>(concurrency: usize, dur: Duration, get: F) -> f64 where F: Fn(u64, usize) -> usize + Send + Sync, · src/served.rs:487

Internal "Holger-vs-Holger regression ceiling" only — NOT a competitor comparison. Concurrent in-process get_file() over files, no HTTP/TLS, returning MB/s. This is the theoretical read ceiling of the znippy archive path; it is reported as holger_inprocess_read_ceiling_mbs, kept apart from the over-the-wire holger_served_mbs head-to-head so a demo can never show it beside the competitor numbers.

Crate holger-build

Holger's MVP/dev/micro build-thing: the 3 tiers × 3 roles (agent · UI · server) matrix as a VIEW over holger's declared build-space, a comparison matrix a UI can render, and the invertible feature↔crate dependency view (the Galois connection: features_pulling / drop_crate). A build-thing CONSUMER, like knut-build — it path-deps nornir-build-thing for the reusable core and reuses holger-build-space's declared BuildVariantSet rather than re-declaring it.

Holger's build-space, viewed as three tiers × three roles (Rickard's matrix, refined 2026-07-23). Same base packages per role — holger, holger-server-ui on gui-core, holger-agent — the tiers differ ONLY by cargo features. Nothing is forked, nothing deleted.

Modelled on knut/crates/knut-build: it path-deps [nornir_build_thing] for the reusable core (BuildVariant / BuildVariantSet / Role / ServiceShape) and it reuses holger's ALREADY-declared build-space ([holger_build_space::build_variant_set], the 8 buildable variants with their drift / shape / airgap tests). The matrix here is a regroup of those into the 3×3, not a second manifest — so the live cells can never drift from what actually builds, and there is no parallel BuildVariant type invented alongside the real one.

• signature / integrity — znippy verify_threshold (M-of-N detached-CMS, integrity + provenance, no modgunn, no online). A * …

Module holger_build

enum Tier { Micro, Mvp, Dev } · src/lib.rs:151

The tier axis — the deployment ambition, expressed only in cargo features.

enum MatrixRole { Agent, Ui, Server } · src/lib.rs:180

The role axis of the matrix — a REFINEMENT of [nornir_build_thing::plugin::Role], not a duplicate of it. holger's coarse role axis is server / client; the matrix splits client into the two things a human and a script drive: the egui browser (Ui) and the transfer CLI (Agent). [MatrixRole::of_variant] derives it from the reused declaration so the split cannot drift.

enum Liveness { Live } · src/lib.rs:230

Whether a cell can build on main today.

enum Gatekeeper { None, Signature, ContentVerdict } · src/lib.rs:242

The two gatekeeper LAYERS, kept distinct on purpose.

enum SizeClass { Small, Medium, Large } · src/lib.rs:268

Approximate size class — the "keep the size lessons" axis. Grounded in the release-binary bytes measured in build-variants.toml where a variant is a UI tier, qualitative otherwise.

struct Cell { tier: Tier, role: MatrixRole, variant: Option<String>, package: Option<String>, features: Vec<String>, crates_total: usize, crates_pulled: Vec<String>, size_class: SizeClass, gatekeeper: Gatekeeper, liveness: Liveness, capability: String, pending_note: Option<String> } · src/lib.rs:294

One cell of the 3×3 matrix: what building this (tier, role) produces, derived FROM the declaration so a UI can render it and it cannot drift from the manifests.

struct VariantMatrix { cells: Vec<Cell> } · src/lib.rs:336

The whole 3×3 comparison matrix.

struct HolgerBuild · src/lib.rs:405

holger's MVP/dev/micro build-thing.

fn capability_of(feature: &str) -> &'static str · src/lib.rs:743

One line on what capability a feature buys — what [HolgerDropPlan] reports as lost. Hand-written prose, deliberately: the resolver knows that turning off signin drops 90 crates, and cannot know that what the user loses is the OIDC device-code tab.

Every key is held to the manifests by capability_lines_name_real_features, so a feature that is renamed or removed breaks the build instead of quietly describing nothing.

struct HolgerDropPlan { crate_name: String, removable_from: Vec<RootDropPlan>, unconditional_in: Vec<String>, absent_from: Vec<String> } · src/lib.rs:776

The drop plan across every matrix root. One crate can be unconditional for one root, conditional for another and absent from a third — modgunn is exactly that — so a single global verdict would be wrong for two of the three.

struct RootDropPlan { package: String, crate_id: String, features_to_disable: BTreeSet<String>, capability_lost: Vec<String>, alternatives: Vec<BTreeSet<String>>, causes_complete: bool, and_group_causes: Vec<FeatureCause>, verified: bool, note: String } · src/lib.rs:849

A drop plan for one crate version as seen from one root package.

fn matrix_root_packages(set: &BuildVariantSet) -> BTreeSet<String> · src/lib.rs:872

The root packages the declared build-space actually builds — derived from the reused declaration, so MATRIX_ROOTS can never quietly go stale.

fn declared_cell_features(set: &BuildVariantSet) -> BTreeSet<String> · src/lib.rs:883

Every feature any declared matrix cell enables — the set capability_of is gated against, plus the composite features a cell names.

Module holger_build::Cell

fn coord(&self) -> String · src/lib.rs:329

micro/server, dev/ui, … — the cell's coordinate as a stable label.

Module holger_build::Gatekeeper

fn as_str(self) -> &'static str · src/lib.rs:254

Module holger_build::HolgerBuild

fn declared(&self) -> anyhow::Result<BuildVariantSet> · src/lib.rs:409

The reused declaration — holger's 8 buildable variants, NOT re-declared here.

fn compare(&self) -> anyhow::Result<VariantMatrix> · src/lib.rs:422

Produce the 3×3 comparison matrix FROM the declaration. Live cells pull their features verbatim from the reused [BuildVariantSet]; pending cells are marked honestly. A UI renders this; it can never drift from the manifests because the live half is read straight out of holger-build-space and the crate columns are RESOLVED from the manifests rather than looked up in a table.

Errors if the feature axis cannot be derived — a matrix with silently empty crate columns is worse than no matrix (LAW 2).

fn features_pulling(&self, crate_name: &str) -> anyhow::Result<Vec<CrateOnRoot>> · src/lib.rs:463

Adjoint 1 — the preimage, DERIVED. Every minimal conjunction of root features that brings crate_name into the build, per matrix root package.

This replaced a FEATURE_PULLS lookup that returned one flat list of feature names for every package at once. The answer genuinely differs by root — reqwest is pulled by eight holger-server-ui features and four holger ones — so the root is now part of the answer.

A name no locked package carries is an [AxisError::UnknownCrate], never an empty list.

fn drop_crate(&self, crate_name: &str) -> anyhow::Result<HolgerDropPlan> · src/lib.rs:475

Adjoint 2 — the drop plan, DERIVED and VERIFIED. The smallest set of features to turn off so crate_name leaves each root's build, with the capability each disabled feature costs.

The plan is a minimum-cardinality hitting set of the minimal causes, and verified is true only when c ∉ F(Φ \ R) was actually re-resolved. Where the crate is Unconditional or Never for a root, that is said plainly instead of promising a saving.

fn feature_axis(&self) -> anyhow::Result<& 'static FeatureAxis> · src/lib.rs:483

The derived feature axis itself, for a caller that wants to ask a question this crate does not wrap.

Module holger_build::HolgerDropPlan

fn removable(&self) -> bool · src/lib.rs:788

Whether ANY root can lose this crate by turning features off.

fn all_verified(&self) -> bool · src/lib.rs:792

Whether every plan on offer was confirmed by re-resolving.

Module holger_build::MatrixRole

fn as_str(self) -> &'static str · src/lib.rs:191

fn of_variant(v: &nornir_build_thing::variant::BuildVariant) -> Option<MatrixRole> · src/lib.rs:205

Derive the matrix role of a declared build-space variant from its coarse [Role] + package. Server → server; a Client is Agent iff its package is holger-agent-cli, else Ui. Returns None for a role the matrix does not model (library / tool). This is the ONE place the coarse→fine mapping lives, and matrix_cells_reference_declared_live_variants holds it to the declaration.

Module holger_build::SizeClass

fn as_str(self) -> &'static str · src/lib.rs:278

Module holger_build::Tier

fn as_str(self) -> &'static str · src/lib.rs:163

Module holger_build::VariantMatrix

fn cell(&self, tier: Tier, role: MatrixRole) -> &Cell · src/lib.rs:342

The cell at (tier, role). Every coordinate is present (9 cells).

fn live(&self) -> Vec<& Cell> · src/lib.rs:349

fn pending(&self) -> Vec<& Cell> · src/lib.rs:353

fn state_json(&self) -> serde_json::Value · src/lib.rs:358

The whole surface as JSON a viz pane / MCP tool reads.

fn to_markdown(&self) -> String · src/lib.rs:371

A Markdown table a docs page or a UI can render directly.

Module holger_build::feature_axis

The feature→crate graph, DERIVED from holger's real manifests.

This module is what replaced the hand-written FEATURE_PULLS / FEATURE_EXPANDS / UNCONDITIONAL tables. Those were deleted, not softened. Measured against cargo tree -p <pkg> -e no-dev --target all, 2026-08-01, the hand table was wrong in five independent ways at once, and one of them was unfixable by editing it:

the table said	the manifests say
facett-model3d is linked unconditionally	no package of that name exists anywhere in the lock
facett-helix / image are unconditional	both are Conditional — dropping the UI features removes them
signin pulls base64	base64 0.22.1 is Unconditional in holger-server-ui; dropping signin cannot remove it
warehouse-scan pulls iceberg	iceberg is not in holger-server-ui's closure at all, under any feature
server-lib, agent-lib, bench-scenarios, world-connector, znippy-rust-repo	none are package names (holger-server-lib, holger-agent-lib, …)

and the structural one: the table had no package axis. reqwest is pulled by {bench, demo, gui, gui-embedded, robot-remote, signin, tools, warehouse-scan} in holger-server-ui and by {bench, default, full, online} in holger. One flat list cannot be right for both, so it was right for neither. Every answer here is stated against a named root package.

What is derived and what is not

Everything about the graph is derived. The only hand-written thing left is [crate::capability_of] — one line of English per feature, which no resolver can produce — and it is GATED: capability_lines_name_real_features fails if a key is not a feature some matrix root actually declares.

Failing loudly

A query that resolves nothing must never look like "nothing pulls this". Every entry point returns [anyhow::Result] and refuses:

• no workspace root / no Cargo.lock → [AxisError::NoWorkspace]
• a lock …

const MATRIX_ROOTS: & [& str] · src/feature_axis.rs:57

The root packages every derived answer is stated against — the packages the 3×3 matrix's cells actually build. Derived from the reused build-space declaration by [crate::matrix_root_packages]; this const is the fallback the gate matrix_roots_are_the_declared_packages holds it to.

enum AxisError { NoWorkspace, EmptyUniverse, NoRootsLoaded, NoSuchRoot, AmbiguousRoot, UnknownCrate, TruncatedClosure, UndeclaredFeature, Parse } · src/feature_axis.rs:63

Everything this module refuses to answer, and why. Each variant exists because the alternative was a confident empty set.

struct FeatureCause { package: String, features: BTreeSet<String> } · src/feature_axis.rs:147

One minimal reason a crate is in the build: a conjunction of root features of one root package. A features set of size 1 is the ordinary case; size ≥ 2 is an AND-group (a weak pkg?/feat edge) — measured 0 of 728 for holger, see the module doc of [crate].

enum RootVerdict { Unconditional, Never, Conditional } · src/feature_axis.rs:163

What one root package can say about one crate.

struct FeatureAxis · src/feature_axis.rs:187

The derived world. Built once from Cargo.lock plus every manifest the lock's local packages live in, and shared by every query so two answers can never come from two parses (LAW 5).

struct CrateOnRoot { package: String, crate_name: String, versions: Vec<CrateVersionVerdict> } · src/feature_axis.rs:459

One crate, seen from one root package: one entry per locked version.

struct CrateVersionVerdict { id: String, verdict: RootVerdict, causes: Vec<FeatureCause>, causes_complete: bool, removable: bool, features_to_disable: BTreeSet<String>, alternatives: Vec<BTreeSet<String>>, verified: bool, note: String } · src/feature_axis.rs:482

The verdict for one exact locked version.

fn discriminating(subject: &BTreeSet<String>, siblings: &[BTreeSet<String>]) -> Vec<String> · src/feature_axis.rs:607

The crates that are in subject but not in EVERY set of siblings — what this build links that its peers do not. Used to give a cell a small, DERIVED signature set instead of the 359-crate full closure or a hand-written list.

fn shared() -> Result<& 'static FeatureAxis, AxisError> · src/feature_axis.rs:623

A shared axis, so the nine cells of one compare() are nine views of ONE parse. Rebuilt on failure — a failed discovery is never cached as "empty".

Module holger_build::feature_axis::CrateOnRoot

fn present_anywhere(&self) -> bool · src/feature_axis.rs:467

Whether any locked version of this crate is in this root's build at all.

fn causes(&self) -> Vec<& FeatureCause> · src/feature_axis.rs:471

Every cause across every version — the flat preimage a UI lists.

fn and_groups(&self) -> Vec<& FeatureCause> · src/feature_axis.rs:475

The causes that are conjunctions — what a naive UI would lie about.

Module holger_build::feature_axis::FeatureAxis

fn for_root(root: &Path) -> Result<Self, AxisError> · src/feature_axis.rs:198

Build the axis for a specific holger checkout.

fn discover() -> Result<Self, AxisError> · src/feature_axis.rs:240

Find holger's checkout and build the axis.

HOLGER_REPO_ROOT wins; otherwise walk up from this crate's source directory (baked in at compile time) and then from the current directory, looking for a Cargo.lock. Failing to find one is an ERROR, never a silently empty graph.

fn root(&self) -> &Path · src/feature_axis.rs:260

The checkout this axis was derived from.

fn scanned_repos(&self) -> &[PathBuf] · src/feature_axis.rs:264

Every repo root scanned for first-party manifests.

fn package_count(&self) -> usize · src/feature_axis.rs:268

How many packages the derived world holds.

fn features_of(&self, package: &str) -> Result<BTreeSet<String>, AxisError> · src/feature_axis.rs:285

Every feature package declares, plus the implicit optional-dep ones — the real [features] table, which is what the deleted FEATURE_EXPANDS was a stale copy of.

fn crates_pulled_by(&self, package: &str, features: &[String], default_features: bool,) -> Result<BTreeSet<String>, AxisError> · src/feature_axis.rs:294

F(S) — the packages package links when built with exactly these root features. Mirrors cargo tree -p <package> -e no-dev --target all --no-default-features [--features …].

Errors rather than truncating: an unresolvable closure is not a small one.

fn crate_ids_pulled_by(&self, package: &str, features: &[String], default_features: bool,) -> Result<BTreeSet<String>, AxisError> · src/feature_axis.rs:331

The same closure as [Self::crates_pulled_by] but as "name version" IDS.

A caller checking that a specific crate LEFT the build must compare ids: reqwest is locked at 0.12.28 and 0.13.4 in holger-server-ui, so "the name reqwest is still present" and "this reqwest is still present" are different questions, and only the second one is the drop plan's claim.

fn analyse(&self, package: &str, crate_name: &str,) -> Result<CrateOnRoot, AxisError> · src/feature_axis.rs:377

The upper adjoint, derived. Every minimal conjunction of root features that brings crate_name into package's build.

An empty causes with verdict Unconditional means "always there"; with Never it means "never there". The two are never collapsed into a bare empty list, which is what the old table did.

fn analyse_all_roots(&self, crate_name: &str) -> Result<Vec<CrateOnRoot>, AxisError> · src/feature_axis.rs:416

The verdicts for crate_name across every matrix root, because the answer genuinely differs per package and a single flat answer is the bug the deleted table had.

fn matrix_roots(&self) -> Result<Vec<String>, AxisError> · src/feature_axis.rs:426

The matrix root packages present in this universe, in a stable order.

fn crates_lost_by_disabling(&self, package: &str, feature: &str,) -> Result<BTreeSet<String>, AxisError> · src/feature_axis.rs:438

The other direction of the same F: the crates that leave package's build when feature is turned off and everything else stays on. Computed from the same resolver, not from a second table that has to agree.

Module holger_build::feature_axis::FeatureCause

fn is_and_group(&self) -> bool · src/feature_axis.rs:155

Crate holger-build-space

[dev-tooling] build-variants.toml + tier link-audits (auth_ship_small: webauthn/openssl must NOT link).

Holger's build-space, declared as data — the first consumer of nornir's build-thing (task #36). Holger ships ONE source tree built three ways, each producing its OWN distinctly-named EXECUTABLE (the deployment tiers in .nornir/holger-tiers.md):

• embedded — the tiniest airgap/edge executable, bin holger-embedded: the in-process engine driven as a standalone binary (embedded mode, no federation), provenance-verify on via the real sign feature.
• mini — the stripped, read-only standalone server for airgap/red-zone, bin holger-mikro (mini mode: minimal serve core, no federation, no Skidbladnir/cloud client linked).
• full — the writable everything-on server, bin holger-full (full mode: the ONLY tier that compiles in the upstream-registry federation — the Skidbladnir ship — plus proxy / import + the full RON config graph).

All three build the real holger crate; the mode features are mutually exclusive (exclusive) and each bin declares its required-features, so a wrong combo rejects up front. Each tier is a typed, reflectable (package × bin × features × profile × target) point in a [BuildVariantSet], grounded in holger's ACTUAL workspace crates and Cargo features (embedded, mini, full, sign, testmatrix, served, gui) — no hardcoded UI, no invented features. The SAME data ships on disk as .nornir/build-variants.toml (which nornir build discovers to drive the Build tab / CLI); a byte-for-byte crate-local mirror (build-variants.toml) is embedded here via include_str! so the bytes travel inside the published crate, with a drift-guard test keeping the two copies identical in-workspace.

The SAME file ALSO carries the two CLIENT variants — what a human and a script drive AGAINST a holger:

• ui — the egui registry/artifact browser (server/ui), bin holger-server-ui. Its bin is required-features = ["gui"], which `cargo build --all-target …

Module holger_build_space

const REPO: & str · src/lib.rs:61

The repo label stamped into the surface + provenance records.

const BUILD_VARIANTS_TOML: & str · src/lib.rs:70

Holger's build-space as data — embedded from the crate-local build-variants.toml so the bytes ship INSIDE the published .crate tarball (an include_str! of the repo's ../../.nornir/build-variants.toml would read OUTSIDE the package dir and break the isolated publish/verify build). The crate-local copy is a byte-for-byte mirror of the on-disk .nornir/build-variants.toml that nornir build discovers; the embedded_matches_on_disk_nornir_copy test guards against drift in-workspace.

fn build_variant_set() -> Result<BuildVariantSet> · src/lib.rs:76

Parse holger's declared build-space into a typed [BuildVariantSet].

This is the descriptor a consumer (the nornir Build tab, nornir build) reflects into choosable rows.

fn build_surface() -> Result<BuildSurface> · src/lib.rs:83

Project holger's build-space onto the data-driven [BuildSurface] a UI renders (one row per tier, each with its materialized cargo command, validity, and a Build action).

fn press_tier(name: &str, repo_root: &Path, outcome: Outcome, artifacts: &[PathBuf],) -> Result<Attestation> · src/lib.rs:111

Press the build-thing button for one declared tier: validate the tier against holger's build-space, then capture a content-addressed build-provenance [Attestation] describing what building it produced.

This is holger consuming nornir-build-thing's provenance path. It is the dep-light describe/attest half — it does not itself shell out to cargo; the caller passes the artifacts a build already emitted (their paths under repo_root) and whether that build succeeded. The record binds the exact tier descriptor (verbatim), the materialized cargo argv + resolved feature/ profile/target axes, the VCS rev + working-tree freshness of repo_root, the detected [Toolchain], the [HostInfo] (cores + memory), the outcome, and the SHA-256 of every artifact — then folds it to a stable digest.

The heavy end-to-end path (dispatch on the tier's kind, spawn cargo build, hash the produced executables, attest + emit build-info lineage in one shot) is [assemble_tier] / [build_tier] over [nornir_build_thing::assemble], which the nornir Build tab and nornir build --variant <tier> also drive. press_tier is the seam a test or an offline tool uses to attest an artifact built out of band.

The returned attestation is unsealed — is_sealed() is false. holger never fabricates a signature; the real seal is znippy's detached-CMS signer, applied via [Attestation::seal_with] behind nornir's build-provenance feature.

fn assemble_tier(name: &str, repo_root: &Path, exec_dir: &Path, info: &dyn BuildInfoSink, builders: &dyn Assemble,) -> Result<Assembled> · src/lib.rs:159

Press the build-thing button END TO END through the unified assemble() seam (nornir-build-thing design §f7) for one declared tier.

This REPLACES the former hand-rolled build_and_press (which shelled the per-tier cargo argv itself via build_variant). A chosen tier now flows through nornir's ONE polymorphic entry point, [nornir_build_thing::assemble]: it validates the tier, dispatches on its ArtifactKind — embedded is an exe, mini/full are service kinds, and both lower to the SAME cargo builder — actually builds it, content-hashes the produced artifact(s), and emits the per-tier build-info lineage (provenance / dep / artifact rows, each artifact row carrying its content_id) to info. It returns ONE content-addressed [Assembled] receipt binding the produced output, the proof, and that lineage. So holger's three deployment tiers ride the exact same dispatch (and future container / vm kinds) as every other suite member — no bespoke per-tier build loop.

Where [press_tier] attests a PRE-BUILT artifact the caller supplies (the dep-light describe/attest seam), assemble_tier is the real "press the button": build THEN attest, in one shot. builders is the injected builder seam — the production [Builders::new] for the real cargo-only path, or a fake in tests; exec_dir is where the built binary / service lands (the BinaryArtifact / ServiceSpec install path). Unknown tiers reject UP FRONT (via [BuildVariantSet::require]) before any build, with the same tier-listing message [press_tier] gives.

The receipt's proof is unsealed — holger never fabricates a signature.

fn build_tier(name: &str, repo_root: &Path) -> Result<(Assembled, Vec<BuildInfoRow>)> · src/lib.rs:183

The real cargo-only [assemble_tier]: build the tier through [nornir_build_thing::assemble] with the production [Builders] (the cargo builder; no image / vm), landing binaries under <repo_root>/target/release, and collect the per-tier build-info lineage in-process. Returns the [Assembled] receipt AND the captured [BuildInfoRow] lineage.

This is what cargo run -p xtask build --variant <tier> drives — holger's first-party equivalent of nornir build --variant <tier>. It is heavy and opt-in: assemble spawns cargo, so a release tier build can take minutes.

Crate holger-embed

The <guest>-embed adapter for holger: hosts holger's registry-browser panel (facett-holger) inside ANOTHER app as a native Box<dyn Facet> (backend (2) — native, no wasm), fed either in-process through holger's functional read API or from a caller-supplied model (the thin-gRPC insertion point). The reusable generalization of nornir's bespoke in-process holger tab.

holger-embed — the reusable <guest>-embed adapter that hosts holger's registry-browser panel inside another app.

This is the first concrete instance of the constellation-wide embed adapter shape (consolidation design §2, native panels; wasm-ui design §3, backend (2)):

a <guest>-embed adapter crate — links the guest's facett-<guest> component crate + a data source, and exposes fn panel(source) -> Box<dyn Panel>: the host app drops the returned panel into a tab. No wasm — the guest's ui runs natively in the host's egui frame at full perf.

It generalizes nornir's bespoke in-process holger tab (nornir/src/holger_embed.rs's read_registry → its own render) into a reusable crate any host links:

• [read_model] reads holger's on-disk dev-pair registry through holger's functional (in-process) API — no server, no socket — into a backend-agnostic [RegistryModel];
• [panel] returns [facett_holger::RegistryBrowser] as a Box<dyn Facet> fed from a [Source] (in-process read, a caller-supplied model, or the sample fixture). facett_core::Facet (title/ui/state_json) is the constellation's current Panel contract; when the design's dedicated Panel trait lands the return type upgrades with no call-site change.

• want holger's PANE (Case A) → link facett-holger + feed it data. That is exactly what [panel] does; the data rides either the in-process read ([Source::InProcess], fat mode) or a caller-supplied [Source::Model] assembled from a thin gRPC read (the gRPC insertion point — the adapter stays transport-agnostic so a host with only a socket to holger still uses the same panel).
• want holger's CAPABILITY only (Case B) → call holger's API directly and render your own pane; this crate is not needed.

Module holger_embed

enum Source { InProcess, Model, Fixture } · src/lib.rs:45

Where the panel's data comes from. The adapter is transport-agnostic: the same [RegistryBrowser] renders whether the model was read in-process, over a thin gRPC wire (assembled by the caller into [Source::Model]), or is the fixture.

fn read_model(data_dir: &Path, grpc: &str, http: &str, per_repo_limit: usize) -> Result<RegistryModel> · src/lib.rs:75

Read holger's dev-pair registry under data_dir through its functional (in-process) API into a backend-agnostic [RegistryModel]: write/read the dev-pair RON, instantiate_backends, then enumerate each repo's backing archive via list. No server is started and no socket is bound. The first repo that actually holds artifacts becomes the selected_repo (so the panel opens on non-empty data); its listing populates artifacts.

This is the canonical generalization of nornir/src/holger_embed.rs's read_registry — same functional-API walk, but it yields the reusable component's model instead of a bespoke summary struct.

fn panel(source: Source) -> Result<Box<dyn Facet>> · src/lib.rs:137

The <guest>-embed entry point: build holger's registry-browser panel and return it as a Box<dyn Facet> a host app drops into a tab. The panel's ui runs natively in the host's egui frame — no wasm, full perf.

Crate holger-errcode

holger's FROZEN, append-only holger-<subsystem>-<n> application error codes

Every non-UI error holger emits carries two channels:

1. a visible human string (what went wrong, in words), and
2. a stable machine code holger-<subsystem>-<n>.

Both ride in the SAME message, so a code survives every transport holger has — an HTTP error body, a log line, a CLI stderr line, an audit row — without needing a side channel.

The Secure Update Gateway core (update-bundle) is deliberately network-free and self-contained. The registry has to be reachable from there and from server/lib while remaining the ONE place codes are allocated — otherwise "unique globally within the app" cannot be enforced by a single test. So this is a leaf crate with no dependencies at all. Keep it that way.

• FROZEN. A code, once published, never changes meaning. Fix the wording of a [ErrCode::summary] freely; never re-point a code at a different failure.
• APPEND-ONLY. Retire a code by leaving it in [ALL] and ceasing to emit it. NEVER reuse the number — a retired code in an old audit row must stay unambiguous.
• UNIQUE within its subsystem and globally across the app. Enforced by [tests::codes_are_unique], which FAILS on a repeat.
• Consumers may prepend a mount prefix; [parse] finds the bracketed code anywhere in the string.
• Every row declares whether it is [Wiring::Wired] (raised at a real error site in [ErrCode::src_file] TODAY) or [Wiring::Reserved] (the number is claimed and frozen, the site is not coded yet). That claim is guarded by errcode/tests/wiring_guard.rs, which reads the real holger source tree: a wired row nothing raises FAILS, and a reserved row that IS raised FAILS.

A registry that merely LISTS codes will happily claim coverage it does not have. holger shipped exactly that: for four sessions t …

Module holger_errcode

struct ErrCode { code: & 'static str, subsystem: & 'static str, n: u16, summary: & 'static str, src_file: & 'static str, wiring: Wiring } · src/lib.rs:61

One frozen entry in holger's error-code registry.

code is the wire identity (holger-<subsystem>-<n>); summary is the human half of the dual channel — a short description of the failure CLASS (the operand goes in the per-site detail passed to [ErrCode::tag]).

enum Wiring { Wired, Reserved } · src/lib.rs:85

Whether a registered code is actually RAISED in holger today, or merely reserved.

The distinction is guarded (errcode/tests/wiring_guard.rs): a Wired row whose [ErrCode::src_file] does not reference it FAILS, and a Reserved row that IS referenced from production code FAILS too. Without that second direction the split would be decoration — a registry can always claim to be wired.

macro_rules! wiring_kind · src/lib.rs:128

wired / reserved as the leading keyword of a [codes!] row → a [Wiring]. Separate macro so the keyword is a plain token in the registry table and a typo (wried) is a compile error naming the row.

macro_rules! codes · src/lib.rs:143

Declare a frozen code AND enrol it in [ALL] in one place, so a code can never be added to the app without also being added to the uniqueness gate.

Each row reads <wired|reserved> IDENT = (subsystem, n, summary, src_file);. The leading keyword is the WIRING CLAIM and src_file is where that claim is checked — both are data the wiring guard reads, not prose.

fn parse(msg: &str) -> Option<& 'static ErrCode> · src/lib.rs:363

Recover the [ErrCode] from any message [ErrCode::tag] produced — a log line, an HTTP body, an audit row, or one of those with a mount prefix prepended.

Matching is on the bracketed form [holger-sub-n], so holger-update-1 can never be mistaken for holger-update-10.

This is what tests assert on — never a substring of the human prose.

fn by_code(code: &str) -> Option<& 'static ErrCode> · src/lib.rs:368

Look a code up by its exact wire string ("holger-update-22").

const WIRE_CODE_KEY: & str · src/lib.rs:374

The HTTP header / gRPC metadata key the code rides in, in ADDITION to being inside the message.

fn wired_count() -> usize · src/lib.rs:381

How many rows claim [Wiring::Wired] — codes holger raises TODAY.

This is the honest coverage numerator. It is a CLAIM until errcode/tests/wiring_guard.rs checks each row against the real source tree; read the two numbers together, never this one alone.

fn reserved_count() -> usize · src/lib.rs:386

How many rows are [Wiring::Reserved] — numbers claimed and frozen, sites not coded.

Module holger_errcode::ErrCode

fn tag(&self, detail: impl Display) -> String · src/lib.rs:109

Render both channels into one message: [code] detail.

The detail is normally the typed error's own Display (holger's error enums already carry carefully-worded, path-free human strings — this prepends the machine channel without disturbing them).

fn bare(&self) -> String · src/lib.rs:114

The dual-channel message using the registry's own summary as the human half.

Module holger_errcode::Wiring

fn label(&self) -> &'static str · src/lib.rs:95

The label the registry doc uses (wired / reserved).

Crate holger-file-oci-repository

OCI registry backend for holger, disk-backed and WRITABLE — full Distribution Spec v2 push and pull (content-addressed sha256), and holger's target for the modern helm push oci://… flow that replaces the bespoke ChartMuseum API.

Disk-backed, writable OCI registry (Distribution Spec v2).

This is holger's push target for the modern Helm flow (helm push chart.tgz oci://host/{repo} and helm pull oci://…) as well as any OCI artifact. Unlike the bespoke ChartMuseum HTTP API it replaces, the OCI protocol is standardized, content-addressed (sha256, integrity built in), and treats every blob as opaque bytes — so the registry never decompresses or parses an uploaded chart, removing that attack surface entirely.

Routes (all under the endpoint's repository name; the gateway routes /v2/{repo}/… to this backend by the first name segment):

GET /v2/ version probe GET|HEAD /v2/{name}/manifests/{ref} manifest by tag or digest GET|HEAD /v2/{name}/blobs/{digest} blob by digest GET /v2/{name}/tags/list tag listing POST /v2/{name}/blobs/uploads/[?digest=] begin (or monolithic) upload PATCH /v2/{name}/blobs/uploads/{uuid} append a chunk PUT /v2/{name}/blobs/uploads/{uuid}?digest=… finalize a blob PUT /v2/{name}/manifests/{ref} store a manifest

Disk layout (content-addressed; blobs shared across images): {base_dir}/blobs/sha256/{hex} {base_dir}/uploads/{id} {base_dir}/manifests/{image}/tags/{tag} {base_dir}/manifests/{image}/sha256/{hex}

Module holger_file_oci_repository

struct OciRepoFile { name: String, base_dir: PathBuf } · src/lib.rs:39

Module holger_file_oci_repository::OciRepoFile

fn new(name: String, base_dir: PathBuf) -> Result<Self> · src/lib.rs:48

Crate holger-handler-bundle-core

The sealed-.znippy bundle repository machinery shared by holger's airgap package handlers

The sealed-bundle repository machinery, written once.

holger's two airgap handlers — Skidbladnir deploy bundles and Rust-toolchain dev bundles — are the same repository: one sealed .znippy per (name, version), served whole, with a classifier that can say what any path inside it is. Only three things differ between them, so only those three are a [BundleKind]:

• the handler's name,
• whether a filename looks like one of its bundles,
• the member classifier.

Everything else — the store key, the coordinate parse, the HTTP routes, fetch/put/list — lives here and is reached by both. Writing it twice would have been ~90% duplication across two crates (LAW 5), and the two copies would then need a guard to watch them agree; one writer needs none.

This crate is dependency-free apart from [holger_plugin_abi], so it compiles for wasm32-unknown-unknown unchanged and each handler's wasm shim reaches exactly the same code the native backend does.

GET  /{repo}/                                   → newline list of bundle files
GET  /{repo}/{name}/{version}                   → the sealed bundle bytes
GET  /{repo}/{name}/{version}/classify/{path…}  → what that member IS
PUT  /{repo}/{name}/{version}                   → store a bundle

classify is the route that puts the shared classifier on the wire: it is pure path logic, it needs no index read, and it is what the native/wasm agreement guard compares field by field. A /members route that enumerated a bundle's contents would need to parse the znippy Arrow index — storage, which a sandboxed module has no business doing and which would have had to answer with an empty list on the wasm side. An endpoint that can only ever answer "nothing" is the NOT RUN → true shape; it is deliberately absent.

Module holger_handler_bundle_core

const BUNDLE_EXT: & str · src/lib.rs:47

Extension of a sealed bundle.

const BUNDLE_CONTENT_TYPE: & str · src/lib.rs:50

Content type a sealed bundle is served with.

struct MemberDescription { kind: String, component: String, encrypted: bool } · src/lib.rs:57

What one entry inside a bundle is. Owned strings because the two classifiers disagree on lifetime — Skidbladnir's components are a fixed set (&'static str), a Rust-toolchain bundle's are derived from the path (a crate name, a target triple), so only an owned form covers both.

trait BundleKind · src/lib.rs:76

The three things that differ between one bundle handler and another.

struct BundleHandler · src/lib.rs:96

A bundle repository handler, parameterised by which bundle kind it serves.

fn store_key(id: &WireArtifactId) -> String · src/lib.rs:123

Store key for a coordinate: {name}-{version}.znippy — the sealed name znippy itself writes (tillsynia-20260706.znippy, rust-dev-rhel8-1.97.1.znippy).

The namespace is deliberately ignored: a sealed bundle has no group coordinate, and folding one into the key would silently collide two different ids onto one blob.

fn coordinate_from_key(key: &str) -> Option<WireArtifactId> · src/lib.rs:133

The inverse of [store_key].

Splits at the last -, so a hyphenated bundle name survives: rust-dev-rhel8-1.97.1.znippy → ("rust-dev-rhel8", "1.97.1"), not ("rust", "dev-rhel8-1.97.1"). Returns None for a name with no - or no .znippy rather than inventing a coordinate.

Module holger_handler_bundle_core::BundleHandler

const fn new() -> Self · src/lib.rs:99

Module holger_handler_bundle_core::BundleKind

fn describe_member(path: &str) -> Option<MemberDescription> · src/lib.rs:88

Classify one bundle-relative path. None = not a member of this kind of bundle, which the handler reports as a 404 rather than guessing.

fn is_bundle_name(file_name: &str) -> bool · src/lib.rs:92

Does this bare filename look like one of this kind's sealed bundles? Used to filter a store listing that may hold other files.

Module holger_handler_bundle_core::MemberDescription

fn to_line(&self) -> String · src/lib.rs:70

The single serialization of a member, used by the HTTP route and by the agreement guard. One writer, so the native and wasm surfaces cannot render the same member differently.

Crate holger-handler-rust-toolchain

holger package handler for airgapped Rust-toolchain bundles — the whole logic, shared by the native backend and the wasm module

The airgapped Rust-toolchain bundle package handler for holger.

A rust-dev-rhel8-<ver>.znippy holds a standalone rustup-dist toolchain, a cargo vendor crate set, a .cargo/config and a pinned integrity manifest — everything a disconnected box needs to cargo build offline. holger serves those bundles; znippy builds and indexes them.

holger-handler-rust-toolchain-wasm depends on this crate and exports only the eight ABI symbols, and tests/native_wasm_agree.rs there asserts the two surfaces answer identically field by field.

The two are the same repository — one sealed .znippy per (name, version) — differing only in the member classifier, the bundle-name predicate and the handler name. Those three are this file; the store key, coordinate parse, HTTP routes and fetch/put/list come from [holger_handler_bundle_core], written once (LAW 5).

The classifier is znippy_plugin_rust_toolchain::member, taken default-features = false so the ArchiveTypePlugin impl and its znippy-common dependency (arrow · io_uring · gatling) are compiled out and the pure path → MemberKind function crosses to wasm32-unknown-unknown unchanged.

Module holger_handler_rust_toolchain

const HANDLER_NAME: & str · src/lib.rs:36

The handler's stable name.

const HANDLER_FORMAT: & str · src/lib.rs:47

The holger_traits::ArtifactFormat this handler reports.

Same finding as the Skidbladnir handler, and it lands the same way: holger has no RustToolchain variant, and ArtifactFormat::Rust would be wrong — that is the crates.io/registry format served by holger-rust-znippy-repository, not a sealed toolchain bundle. A client asking for Rust expects a .crate and a registry index. znippy is the truthful answer for a .znippy served as the artifact itself; the manifest's handler = "rust-toolchain" carries the real identity. Adding a variant is Rickard's call — see the report.

const BUNDLE_PREFIX: & str · src/lib.rs:50

The prefix every rust-dev bundle carries.

struct RustToolchain · src/lib.rs:53

The rust-toolchain [BundleKind].

type RustToolchainHandler · src/lib.rs:85

The handler instance holger loads.

fn describe_member(path: &str) -> Option<MemberDescription> · src/lib.rs:88

Classify one bundle-relative path — the shared ownership rule, re-exported.

Crate holger-handler-rust-toolchain-wasm

The Rust-toolchain bundle handler compiled to wasm32 — ABI shim only, all logic in holger-handler-rust-toolchain

The Rust-toolchain package handler compiled to wasm32-unknown-unknown.

cargo xtask build-wasm-plugins
# → target/wasm32-unknown-unknown/release/holger_handler_rust_toolchain_wasm.wasm

Holds no bundle logic — see holger-handler-rust-toolchain, which owns all of it and shares the repository machinery with the Skidbladnir handler. The eight ABI exports and the host-backed BlobStore come from export_package_handler!, so this crate is one line of glue over one line of declaration.

tests/native_wasm_agree.rs loads the real module and asserts it agrees with the linked handler field by field; it fails, never skips, on a missing or stale module.

Crate holger-handler-skidbladnir

holger package handler for Skidbladnir airgap bundles — the whole logic, shared by the native backend and the wasm module

The Skidbladnir airgap-bundle package handler for holger.

A Skidbladnir bundle is the Tillsynia/Njord deploy payload: one sealed .znippy holding a pg_dump, S3 document blobs, container images, infra operators, a Talos ISO, declarative config and age-encrypted secrets. holger's job is to serve those bundles; znippy's job is to build and index them.

holger-handler-skidbladnir-wasm depends on this crate and exports only the eight ABI symbols. Everything a request is answered with comes from here and from [holger_handler_bundle_core], so the two surfaces cannot diverge — tests/native_wasm_agree.rs in the wasm crate asserts field-by-field that they do not.

That second row is the seam. It is the same one znippy-plugin-maven uses for its wasm build (host-decompressors off ⇒ the threaded ljar fan-out is compiled out, the single-threaded linflate both sides share remains). Unlike maven there is no threading to compile out here — a bundle coordinate scheme was never parallel — so what the feature removes is the Arrow index writer, which this handler does not use either way. Measured 2026-08-05: cargo check -p znippy-plugin-skidbladnir --no-default-features --target wasm32-unknown-unknown builds the crate alone, …

Module holger_handler_skidbladnir

const HANDLER_NAME: & str · src/lib.rs:42

The handler's stable name — what a .wasm reports in its manifest and what an operator writes in a repository config.

const HANDLER_FORMAT: & str · src/lib.rs:60

The holger_traits::ArtifactFormat this handler reports, as its serde-lowercase spelling.

This is a finding, not a preference. holger has no Skidbladnir variant: ALL_ARTIFACT_FORMATS (traits/src/lib.rs:326) is Maven3, Pip, Rust, Go, Nuget, Npm, Gem, Deb, Rpm, Helm, Docker, Conda, Composer, Znippy, Raw. Adding one touches ArtifactFormat, RepositoryType, endpoint_name, znippy_type_id and every exhaustive match over the enum across sixteen backend crates — Rickard's call, so it is reported rather than smuggled in.

znippy is meanwhile the honest answer and not a placeholder: a Skidbladnir bundle is a sealed .znippy served as the artifact itself, which is exactly what ArtifactFormat::Znippy documents itself to mean. What is lost is only telling a bundle from any other .znippy by format alone — the handler's own identity survives, because the plugin manifest carries handler = "skidbladnir" independently of format.

struct Skidbladnir · src/lib.rs:63

Skidbladnir's [BundleKind]: the three things that are not shared.

type SkidbladnirHandler · src/lib.rs:90

The handler instance holger loads.

fn describe_member(path: &str) -> Option<MemberDescription> · src/lib.rs:94

Classify one bundle-relative path — the shared ownership rule, re-exported so a caller need not name the znippy crate.

Crate holger-handler-skidbladnir-wasm

The Skidbladnir airgap-bundle handler compiled to wasm32 — ABI shim only, all logic in holger-handler-skidbladnir

The Skidbladnir package handler compiled to wasm32-unknown-unknown.

cargo xtask build-wasm-plugins
# → target/wasm32-unknown-unknown/release/holger_handler_skidbladnir_wasm.wasm

It holds no bundle logic. Every coordinate parse, store key, HTTP route, listing rule and member classification comes from holger-handler-skidbladnir — the same crate the linked backend is built from — which in turn shares its repository machinery with the rust-toolchain handler (holger-handler-bundle-core) and its classifier with znippy (znippy-plugin-skidbladnir, --no-default-features).

The ABI glue is not written here either: export_package_handler! emits all eight exports and the host-backed BlobStore, so the same pointer protocol serves every handler and cannot drift between two of them.

tests/native_wasm_agree.rs loads the real module through the real host and asserts, field by field, that it answers as the linked handler does. It fails — never skips — when the module is missing or stale.

Unlike znippy's maven pair there is no threading seam to find: a bundle coordinate scheme was never parallel, so nothing had to be compiled out for wasm beyond the Arrow index writer this handler does not use either way.

Crate holger-mannequin

[test-infra] Mock PKI+OIDC+Nexus in one process. Test/dev only — never production.

Module holger_mannequin::auth::users

enum AuthMethod { Oidc, Mtls } · src/auth/users.rs:9

How a user authenticated.

struct Identity { subject: String, method: AuthMethod, roles: Vec<String> } · src/auth/users.rs:16

A resolved identity after successful auth.

struct AuthService · src/auth/users.rs:24

Fake user database + auth validation for testing. Ties together OIDC tokens and client certs to identities.

struct UserCredentials { username: String, access_token: String, client_cert_pem: String, client_key_pem: String } · src/auth/users.rs:109

Credentials bundle for a test user.

Module holger_mannequin::auth::users::AuthService

fn new() -> Self · src/auth/users.rs:40

fn validate_oidc_token(&self, token: &str, oidc: &OidcService) -> Option<Identity> · src/auth/users.rs:52

Validate a Bearer token via OIDC service, return identity.

fn validate_client_cert(&self, cn: &str) -> Option<Identity> · src/auth/users.rs:67

Validate a client certificate CN, return identity.

fn issue_credentials(&self, username: &str, oidc: &OidcService, pki: &PkiService,) -> anyhow::Result<UserCredentials> · src/auth/users.rs:81

Issue credentials for a test user (token + client cert).

fn list_users(&self) -> Vec<String> · src/auth/users.rs:98

fn add_user(&self, name: &str, roles: Vec<String>) · src/auth/users.rs:102

Module holger_mannequin::config

struct MannequinConfig { port: u16, ca_cert: Option<CertSource>, ca_key: Option<CertSource>, server_cert: Option<CertSource>, server_key: Option<CertSource> } · src/config.rs:8

Configuration for holger-mannequin. If cert fields are empty/None, fresh certs are generated at startup. Otherwise, the supplied certs (inline PEM or file paths) are used.

enum CertSource { Inline, File } · src/config.rs:32

A certificate/key can be supplied inline (base64/PEM) or as a file path.

Module holger_mannequin::config::CertSource

fn resolve(&self) -> anyhow::Result<String> · src/config.rs:38

Module holger_mannequin::config::MannequinConfig

fn load(path: &std::path::Path) -> anyhow::Result<Self> · src/config.rs:55

Load from a RON file, or return default (generate everything).

fn has_ca(&self) -> bool · src/config.rs:63

Returns true if CA certs are supplied (don't generate).

Module holger_mannequin::event_log

struct LogEntry { timestamp: DateTime<Utc>, system: SystemKind, direction: Direction, summary: String, detail: Option<String> } · src/event_log.rs:5

enum SystemKind { Pki, Oidc, Nexus } · src/event_log.rs:14

enum Direction { Inbound, Outbound } · src/event_log.rs:31

struct EventLog · src/event_log.rs:38

Shared event log accessible from both server handlers and GUI.

Module holger_mannequin::event_log::EventLog

fn new() -> Self · src/event_log.rs:49

fn log(&self, system: SystemKind, direction: Direction, summary: impl Into<String>, detail: Option<String>) · src/event_log.rs:55

fn entries_for(&self, system: &SystemKind) -> Vec<LogEntry> · src/event_log.rs:65

fn all_entries(&self) -> Vec<LogEntry> · src/event_log.rs:75

fn count_for(&self, system: &SystemKind) -> usize · src/event_log.rs:79

Module holger_mannequin::event_log::SystemKind

fn label(&self) -> &'static str · src/event_log.rs:21

Module holger_mannequin::facet_react

holger's REACTION to a facett UI error code (facett error-codes, Phase 2).

facett panes raise a stable, unique UI error code — facet-<component>-<n> ([facett_core::errcode]) — carrying BOTH the human message and the code, so a consumer reacts to the CODE, not a matched string. This module is holger's half.

How this COMPOSES with holger-<subsystem>-<n>

holger owns a frozen registry of its OWN application error codes (holger-errcode, holger-<subsystem>-<n>, exhaustively matched so an un-coded variant is a COMPILE error). The two vocabularies compose, they never collide:

• a facett UI failure surfaced through a holger mount keeps facett's frozen code plus holger's mount prefix — holger/mannequin:facet-syschart-1;
• holger's OWN backend failure keeps holger-<subsystem>-<n>.

The mount

holger embeds facett_syschart::SystemChart as the mannequin PKI/OIDC/Nexus system map (holger/mannequin). It is declared in facett's shared registry, so the reaction obligations below are generated, not hand-authored.

const APP: & str · src/facet_react.rs:26

holger's application key in the shared reaction matrix.

const MANNEQUIN: ConsumerMount · src/facet_react.rs:31

The mannequin mount — holger's PKI / OIDC / Nexus system map. site is the ANTI-FICTION anchor: the guard test asserts this file exists and really mounts the component whose codes it claims.

const MOUNTS: & [ConsumerMount] · src/facet_react.rs:35

Every holger mount.

fn matrix() -> Vec<(String, &'static str, &'static str, Reaction)> · src/facet_react.rs:39

The reaction-matrix rows holger is contracted to satisfy — sliced from facett's shared table.

fn react(rec: &mut FacetRecorder, mount: ConsumerMount, err: &FacetError) -> Reaction · src/facet_react.rs:47

React to a facett UI error raised at a holger mount. Namespaces the code with the mount, records the MOUNTED code into rec (folded into the GUI's state_json), and returns the canonical [Reaction]. An unregistered code is [Reaction::Diagnose] — never a silent pass.

fn react_to_state(rec: &mut FacetRecorder, mount: ConsumerMount, state: &serde_json::Value,) -> Option<Reaction> · src/facet_react.rs:54

React to whatever a driven facett pane PUBLISHED — the pane writes state_json.error_code when it is in its error state, so holger branches on the CODE in the data rather than scanning a rendered string.

fn state_json(rec: &FacetRecorder) -> serde_json::Value · src/facet_react.rs:70

The observable Phase-2 surface for holger's state_json.

fn reaction_of(code: &str) -> Option<Reaction> · src/facet_react.rs:93

Resolve the canonical reaction for a (possibly mounted) facett code.

Module holger_mannequin::gui

Mannequin GUI — the holger test-dummy system map, drawn through facett components (the nordisk house pattern) instead of raw egui:

• the PKI / OIDC / Nexus system map → a facett_syschart::SystemChart (clickable peer nodes + edges, a per-node event-count badge, and a click-select → inline detail panel — the component invented for this GUI);
• the selected system's event log → a facett_table::Table (timestamp / direction / summary rows);
• the PKI issued-cert list → a small tree/list, with the Regenerate action kept as a live button.

Everything stays live: each frame we re-read the shared [EventLog] + [PkiService] and refresh the chart badges + the table rows, so the map updates as the daemon serves requests.

The shell is a [Scene] — because this pane really is master/detail

The map and the log were two things stacked in one ScrollArea with a ui.separator() between them: the operator could not resize either, could not collapse the map to read a long log, and could not blow the log up to read it. But the relationship was master/detail all along — you pick a system ON the map and the panel below is the detail OF that pick.

So the shell is declared as one [facett_app::scene::Scene] (L5 — the same shared pane host holger-server-ui's shell adopted) and rendered by [scene::render]:

mannequin-shell ── Split(V, 0.55, DRAGGABLE)
├─ map_pane    (Foldable 🗺) slot:map    — the SystemChart (the MASTER)
└─ detail_pane (Foldable 📜) slot:detail — the selection's log + PKI controls

That buys a real draggable divider and — via facett-app's Chrome::Auto — a window title bar on each pane carrying fold · minimise · maximise. Nothing about the two bodies changed: the same SystemChart and the same Table are drawn, through a [SceneHost] instead of inline.

const SHELL_PANE: & str · src/gui.rs:53

The root pane's unique name — the DRAGGABLE vertical master/detail split. The Router reports it as the scene route and a robot drags its divider by the rect the render publishes under separators.

const MAP_PANE: & str · src/gui.rs:56

The MASTER pane: the PKI / OIDC / Nexus system map.

const DETAIL_PANE: & str · src/gui.rs:59

The DETAIL pane: the selected system's event log (+ the PKI controls).

fn mannequin_scene() -> Scene · src/gui.rs:68

Build the mannequin shell as a declarative [Scene]: a draggable vertical master/detail split of the system map over the selection's detail. Both panes are foldable, and both wear facett-app's default window chrome (fold · minimise · maximise) — the root stays bare, as it must.

Pure and window-free, so a test can build the exact shipped shell and assert its shape without a display.

fn node_a11y_label(kind: &SystemKind, badge: u64) -> String · src/gui.rs:105

The EXACT AccessKit label facett_syschart::SystemChart registers on a node's clickable button — "{label} · {badge} events" (see facett-syschart FC-4). The robot addresses the REAL on-map node by this string, and state_json publishes it per node, so the drive target and the emit stay one truth.

struct MannequinGui · src/gui.rs:109

fn default_look_preset() -> usize · src/gui.rs:135

The default look preset for the mannequin GUI: the running-OS-matched preset's index into [LookTheme::PRESETS]. Linux/unknown → windows-dark (facett's documented default). Pure → unit-testable with no window.

fn build_system_chart(badges: [(SystemKind, u64); 3]) -> SystemChart · src/gui.rs:146

Build the mannequin system map as a bare facett [SystemChart] — the three mock systems (PKI / OIDC / Nexus) as peer nodes, fully wired with edges. This is the single source of truth for the chart's topology: the live GUI ([MannequinGui::new]) builds from it AND the headless robot-UI matrix cell renders this exact chart offscreen to assert its state_json. Badges start at the supplied counts so a test can inject real numbers and read them back.

Module holger_mannequin::gui::MannequinGui

fn new(event_log: EventLog, pki: Arc<PkiService>) -> Self · src/gui.rs:165

fn look_theme(&self) -> LookTheme · src/gui.rs:186

The active look preset's [LookTheme].

fn set_look_preset(&mut self, idx: usize) -> String · src/gui.rs:192

Switch the active look preset (clamped); returns the new preset name.

fn state_json(&self) -> serde_json::Value · src/gui.rs:215

Remote-observable state (LAW 6): every on-screen VALUE an operator sees, as data, so a robot asserts the value — never the pixels. The drivable half exists too (set_look_preset / select_system / regenerate_pki / toggle_fold …), so a robot can drive each primary function and assert the result IN CODE.

The roster, matched 1:1 against what the shipped shell paints:

• look_preset / look_name — the chrome bar's look switcher's active pick;
• selected_system — the map's one selection (drives the detail pane);
• events.{pki,oidc,nexus} — the per-node badge numbers on the map;
• pki_issued — the PKI issued-cert count;
• chart_nodes[] — every map node's {id,label,badge,selected} PLUS the exact AccessKit label (a11y_label) the facett SystemChart registers for it, so a robot can click the REAL on-map node (no proxy);
• detail{} — what the detail pane renders for the current selection, and its EMPTY / ERROR states as booleans (empty, pki_certs_empty, activity_*), so an empty pane is an asserted value, never an eyeball (LAW 2 / 4);
• scene{} — the pane-chrome geometry + fold/minimise/maximise/split state.

fn toggle_fold(&mut self, pane: &str) -> bool · src/gui.rs:312

Robot/test hook: fold or unfold a scene pane by name (the same toggle the chrome bar's ⏷ control runs). Returns the new folded state.

fn toggle_minimize(&mut self, pane: &str) -> bool · src/gui.rs:318

Robot/test hook: minimise a pane — collapse it to its chrome title bar and hand its space back to its sibling. Returns the new minimised state.

fn toggle_maximize(&mut self, pane: &str) -> bool · src/gui.rs:324

Robot/test hook: maximise a pane — give it the whole shell, shrinking its sibling to zero area. At most one pane holds it. Returns the new state.

fn restore_pane(&mut self, pane: &str) -> bool · src/gui.rs:330

Robot/test hook: restore a pane (drop its minimise AND its maximise). The split ratio was never overwritten, so the layout returns exactly as it was.

fn split_ratio(&self) -> Option<& Vec<f32>> · src/gui.rs:336

Robot/test hook: the live first-child (map) fraction of the master/detail split — what a divider drag moves.

fn select_system(&mut self, id: &str) -> Option<String> · src/gui.rs:343

Robot/test hook: select a system on the map (the headless analogue of clicking a chart node) — the ONE selection the detail pane renders. Re-selecting the same node deselects, per the chart's documented toggle. Returns the new selection.

fn selected_system(&self) -> Option<String> · src/gui.rs:350

Robot/test hook: the ONE selected system id ("pki"/"oidc"/"nexus"), or None when the map has nothing selected. The read half of [select_system].

fn regenerate_pki(&mut self) -> bool · src/gui.rs:358

Robot/test hook: regenerate the PKI CA (the headless analogue of clicking the detail pane's 🔄 Regenerate button). On success it logs the same outbound PKI event the live button does, so the event count a robot asserts moves. Returns whether the regenerate succeeded.

fn issued_certs(&self) -> Vec<String> · src/gui.rs:378

Robot/test hook: the PKI issued-cert common-names (what the detail pane's cert list renders).

fn event_count(&self, kind: &SystemKind) -> usize · src/gui.rs:383

Robot/test hook: the live event count for one system (the badge number).

fn apply_look(&self, ctx: &egui::Context) · src/gui.rs:390

Apply the active preset to ctx — installs the full egui Style and publishes the derived legacy palette so the facett SystemChart + Table follow (COH-1).

fn run(self) -> anyhow::Result<()> · src/gui.rs:394

Module holger_mannequin::nexus

struct NexusRepository { name: String, format: String, repo_type: String, url: Option<String> } · src/nexus/mod.rs:12

struct NexusAsset { path: String, download_url: String, content_type: Option<String>, size: Option<u64> } · src/nexus/mod.rs:21

struct AssetPage { items: Vec<NexusAsset>, continuation_token: Option<String> } · src/nexus/mod.rs:32

struct MockNexusService { proxy: ProxyRepo, prod: ProdRepo, upload: UploadRepo } · src/nexus/mod.rs:39

Aggregates all three Nexus repo types.

Module holger_mannequin::nexus::MockNexusService

fn new(base_url: &str) -> Self · src/nexus/mod.rs:46

fn list_repositories(&self) -> Vec<NexusRepository> · src/nexus/mod.rs:56

fn list_assets(&self, repo: &str) -> Vec<NexusAsset> · src/nexus/mod.rs:79

async fn download(&self, repo: &str, path: &str) -> Option<Vec<u8>> · src/nexus/mod.rs:88

fn upload(&self, repo: &str, path: &str, data: Vec<u8>) -> bool · src/nexus/mod.rs:97

Module holger_mannequin::nexus::prod

struct ProdRepo · src/nexus/prod.rs:6

Prod repo: pre-loaded with a few well-known crates. Read-only.

Module holger_mannequin::nexus::prod::ProdRepo

fn new(base_url: &str) -> Self · src/nexus/prod.rs:25

fn seed_defaults(&mut self) · src/nexus/prod.rs:34

Seed the 4 default crates (fetched lazily on first download).

fn seeded_paths() -> Vec<String> · src/nexus/prod.rs:39

fn list_assets(&self) -> Vec<NexusAsset> · src/nexus/prod.rs:45

async fn download(&self, path: &str) -> Option<Vec<u8>> · src/nexus/prod.rs:66

Async (M1): previously this used block_in_place + Handle::block_on, which panics on a current-thread runtime (in-process integration tests) and otherwise parks a worker thread for the whole fetch. Awaiting the fetch directly — like ProxyRepo::download — is correct on any runtime flavor.

Module holger_mannequin::nexus::proxy

struct ProxyRepo · src/nexus/proxy.rs:6

Proxy-only repo: fetches crates from crates.io on demand, caches in memory.

Module holger_mannequin::nexus::proxy::ProxyRepo

fn new(base_url: &str) -> Self · src/nexus/proxy.rs:13

fn list_assets(&self) -> Vec<NexusAsset> · src/nexus/proxy.rs:21

async fn download(&self, path: &str) -> Option<Vec<u8>> · src/nexus/proxy.rs:30

Module holger_mannequin::nexus::upload

struct UploadRepo · src/nexus/upload.rs:6

Upload repo: starts empty, accepts PUT uploads.

Module holger_mannequin::nexus::upload::UploadRepo

fn new(base_url: &str) -> Self · src/nexus/upload.rs:12

fn list_assets(&self) -> Vec<NexusAsset> · src/nexus/upload.rs:19

fn download(&self, path: &str) -> Option<Vec<u8>> · src/nexus/upload.rs:28

fn upload(&self, path: &str, data: Vec<u8>) · src/nexus/upload.rs:32

Module holger_mannequin::oidc

struct OidcService · src/oidc/mod.rs:7

Mock OIDC provider for testing authentication flows.

struct TokenRecord { access_token: String, subject: String, issued_at: i64, expires_at: i64 } · src/oidc/mod.rs:13

struct OidcDiscovery { issuer: String, authorization_endpoint: String, token_endpoint: String, userinfo_endpoint: String, jwks_uri: String } · src/oidc/mod.rs:21

struct TokenRequest { grant_type: Option<String>, username: Option<String>, password: Option<String>, client_id: Option<String> } · src/oidc/mod.rs:30

struct TokenResponse { access_token: String, token_type: String, expires_in: i64, sub: String } · src/oidc/mod.rs:38

Module holger_mannequin::oidc::OidcService

fn new(issuer: String) -> Self · src/oidc/mod.rs:46

fn discovery(&self) -> OidcDiscovery · src/oidc/mod.rs:53

fn issue_token(&self, subject: &str) -> TokenResponse · src/oidc/mod.rs:64

Issue a token (accepts any credentials — it's a test dummy).

fn validate_token(&self, token: &str) -> Option<String> · src/oidc/mod.rs:85

Validate a token (returns subject if valid).

Module holger_mannequin::pki

struct PkiService · src/pki/mod.rs:6

PKI service: manages a test CA and issues certificates on demand.

struct IssuedCert { common_name: String, cert_pem: String, key_pem: String } · src/pki/mod.rs:11

Module holger_mannequin::pki::PkiService

fn new() -> anyhow::Result<Self> · src/pki/mod.rs:48

Create with a freshly generated CA.

fn from_config(config: &MannequinConfig) -> anyhow::Result<Self> · src/pki/mod.rs:57

Create from config: use supplied certs if present, otherwise generate.

fn regenerate(&self) -> anyhow::Result<()> · src/pki/mod.rs:70

Regenerate the CA and clear all issued certs.

fn ca_cert_pem(&self) -> String · src/pki/mod.rs:78

Get CA certificate in PEM format.

fn issue_server_cert(&self, cn: &str, sans: Vec<& str>) -> anyhow::Result<IssuedCert> · src/pki/mod.rs:84

Issue a server certificate signed by the CA.

fn issue_client_cert(&self, cn: &str) -> anyhow::Result<IssuedCert> · src/pki/mod.rs:113

Issue a client certificate signed by the CA.

fn list_issued(&self) -> Vec<String> · src/pki/mod.rs:141

List all issued certificates.

Module holger_mannequin::robot

Robot-UI wiring for the mannequin GUI — ONE scenario, BOTH modes, REAL shell

This is the mannequin's adoption of the shared nornir-robotui framework (edda leaf, 0.2.6 — Watch resolves clicks via AccessKit), following its demo.rs reference:

• ONE [Observable] — the mannequin GUI exposes EVERY on-screen value as JSON so a robot asserts the value, not the pixels (delegates to [MannequinGui::state_json]);

• ONE draw(ui, app, targets) closure — [mannequin_draw] — that renders the REAL shipped shell ([eframe::App::ui]) into the robot frame. The primary controls a robot drives are therefore the ACTUAL widgets a user touches:

  • the facett SystemChart's map nodes (PKI / OIDC / Nexus) — each a real AccessKit button the component registers (facett-syschart FC-4), labelled "{system} · {badge} events", so the robot clicks the REAL on-map node;
  • the detail pane's 🔄 Regenerate button;
  • the chrome bar's look-preset switcher (selectable_label per preset);
  • each pane's window-chrome fold control ("fold <pane>").

• ONE [Scenario] — [mannequin_scenario] — the exact steps CI runs headless and holger-mannequin robot --watch replays visibly.

Why the REAL shell, not a proxy control rail

An earlier pass drew a bespoke button rail because the map nodes were believed to be canvas-drawn and thus not click-addressable. That is no longer true: facett's SystemChart paints each node AND registers an AccessKit button over it (facett_core::a11y::node, label "{label} · {badge} events"). Driving a proxy would have tested a surface the user never touches (LAW 1 — SHIPPED ≠ TESTED), so the robot now drives the shipped shell directly and asserts values off its state_json. state_json["chart_nodes"][*]["a11y_label"] publishes each node's exact click label, keeping the drive target and the emit one truth.

The choosable entry point lives in [run]: pass [RunMode::Headless] for the CI matrix or [ …

const ROBOT_LOOK: & str · src/robot.rs:53

The stable look preset a robot switches TO first — not the running-OS default (windows-dark on Linux), so the click provably CHANGES the observed look name.

const ROBOT_LOOK_2: & str · src/robot.rs:57

A SECOND preset the scenario switches to, to prove the switcher maps EACH preset to its own name (LAW 3 — sweep, not one value).

fn mannequin_draw(ui: &mut egui::Ui, app: &mut MannequinGui, _t: &mut Targets) · src/robot.rs:72

Draw ONE frame of the mannequin robot surface — the real shipped shell. The robot frame hands us a &mut egui::Ui; we render the exact eframe::App::ui a user runs into it (a throwaway kittest Frame, which the shell ignores). Every primary control — the map's AccessKit node buttons, the Regenerate button, the look switcher, the pane fold chrome — is therefore the ACTUAL widget, addressable by its real label in both the headless AccessKit path and the watch cursor.

Targets is unused: the shell's controls all carry AccessKit labels (facett's FC-4 contract), so both modes resolve them from the live tree — no proxy rect to record.

fn mannequin_scenario() -> Scenario · src/robot.rs:86

The mannequin robot [Scenario], driving the REAL shell. Every step that changes state asserts the VALUE changed (not merely that something drew / a selection moved): a Regenerate increments /events/pki, a look switch lands the exact /look_name, a fold flips /scene/folded/<pane>. Primary functions are SWEPT (LAW 3): Regenerate is proven to increment on EACH press (0→1→2, not a 0→1 flip), the look switcher is proven to map TWO distinct presets to their own names, the three map nodes are each selected, and the fold is exercised in BOTH directions. Empty/error states are asserted as values (LAW 2 / 4): the detail placeholder, the empty issued-cert list, and per-system "No activity yet".

fn run(mode: RunMode, cfg: WatchConfig) -> anyhow::Result<RunOutcome> · src/robot.rs:226

The choosable entry point. Run the mannequin robot scenario in mode: [RunMode::Headless] fills the CI matrix (off-screen egui_kittest), [RunMode::Watch] opens a REAL eframe window and replays it visibly. cfg paces the watch run.

Headless builds its own sized [Harness] (rather than run_scenario_mode's default-size one) so the whole shipped map canvas is on-screen and every on-map node is a reachable click target; Watch delegates to the shared runner, which owns the real eframe window.

Module holger_mannequin::server

struct MannequinServer { pki: Arc<PkiService>, oidc: Arc<OidcService>, auth: Arc<AuthService>, nexus: Arc<MockNexusService>, event_log: EventLog, port: u16 } · src/server.rs:19

Module holger_mannequin::server::MannequinServer

fn new(port: u16) -> anyhow::Result<Self> · src/server.rs:38

fn from_config(config: MannequinConfig) -> anyhow::Result<Self> · src/server.rs:42

fn router(&self) -> Router · src/server.rs:54

async fn serve(self) -> anyhow::Result<()> · src/server.rs:87

Crate holger-nexus-connector

Sonatype Nexus connector for the holger agent — a ConnectorTrait Source/Target that lists repositories and assets and moves artifact bytes over Nexus's REST API (basic / bearer / mTLS), so an existing Nexus can be mirrored into holger or fed from it.

Nexus ConnectorTrait — Sonatype Nexus 3 as an agent Source/Target.

Talks the REST v1 API (/service/rest/v1/repositories, /assets) to enumerate repos and continuation-token-paginated assets, downloads via each asset's downloadUrl, and uploads with a raw PUT to /repository/{r}/{p}. Auth is a ConnectorAuth (None/Basic/OidcToken/Mtls) attached per request; with_oidc_token/with_mtls/fetch_oidc_token cover the non-Basic paths.

Two invariants the code exists to hold: the downloadUrl is untrusted, so download_asset rejects any URL that is not same_origin_as_base before a request is sent — this stops SSRF / credential exfiltration to cloud-metadata or internal hosts. That guard only sees the initial URL, hence the client is built redirect-none (a 3xx would otherwise smuggle creds past it). All bodies flow through read_capped (8 GiB artifacts / 256 MiB JSON) so a lying or absent Content-Length can't OOM the agent under parallelism.

Module holger_nexus_connector

enum ConnectorAuth { None, Basic, OidcToken, Mtls } · src/lib.rs:51

How the connector authenticates with the registry.

struct NexusConnector { url: String, auth: ConnectorAuth } · src/lib.rs:62

async fn fetch_oidc_token(token_url: &str, username: &str, _password: &str) -> Result<String> · src/lib.rs:146

Fetch an OIDC access token from a token endpoint.

Module holger_nexus_connector::NexusConnector

fn new(url: String, username: Option<String>, password: Option<String>) -> Result<Self> · src/lib.rs:69

fn with_oidc_token(url: String, token: String) -> Result<Self> · src/lib.rs:88

Create a connector with OIDC token auth.

fn with_mtls(url: String, cert_pem: &[u8], key_pem: &[u8]) -> Result<Self> · src/lib.rs:103

Create a connector with mTLS client cert.

Crate holger-plugin-abi

holger package-handler plugin ABI: the wire contract a handler speaks whether it is linked in or loaded from a .wasm

holger's package-handler plugin contract — the one wire format a handler speaks whether it is linked into the server or loaded from a .wasm at startup.

Rickard's ask was that every package handler should be writable as native or WASM. Before this crate holger had no wasm path at all: the sixteen repository backends are unconditional path dependencies of server/lib, so adding a package handler meant editing server/lib/Cargo.toml and rebuilding the server.

A RepositoryBackendTrait is a Rust trait object and cannot cross a wasm boundary, so this crate splits a handler in two along the line that actually matters:

• [PackageHandler] — the format logic: coordinate parsing, the HTTP path scheme, listing, content types. This is what varies per ecosystem and what a plugin author writes. It is pure and target-independent, so the one implementation compiles for the host and for wasm32-unknown-unknown.
• [BlobStore] — the bytes. A wasm module has no filesystem and no socket. The host owns storage and hands it in.

That split is what makes "the wasm crate is ABI glue only" true rather than aspirational: the native backend implements BlobStore over the filesystem, the wasm shim implements it over four host imports, and both call the same PackageHandler. It is the same shape as znippy's maven pair, where host-decompressors compiles the threaded ljar fan-out out of the wasm build and leaves the single-threaded linflate both sides share — same logic, different plumbing underneath.

RepositoryBackendTrait (traits/src/lib.rs:404) has twelve methods. Six cross:

Module holger_plugin_abi

trait BlobStore · src/lib.rs:129

The bytes behind a handler. Implemented natively over a directory and in wasm over the [imports] host functions — the handler logic above it never learns which.

Keys are handler-chosen store paths (bundles/tillsynia-1.4.znippy), not filesystem paths: the host is free to place them wherever it likes and a module never sees an absolute path.

trait PackageHandler · src/lib.rs:152

The format logic of one package handler. Everything here is pure over a [BlobStore], so the single implementation compiles for the host and for wasm32-unknown-unknown unchanged. A handler crate implements this once; the wasm crate beside it adds no logic, only the ABI shim.

Module holger_plugin_abi::BlobStore

fn get(&self, key: &str) -> Result<Option<Vec<u8>>, String> · src/lib.rs:133

The stored bytes, or None if the key is absent. An Err is a store failure (unreadable, permission denied) and must not be flattened into None — a missing artifact and a broken disk are different answers.

fn put(&self, key: &str, data: &[u8]) -> Result<(), String> · src/lib.rs:136

Store bytes under key, overwriting.

fn list(&self, prefix: &str) -> Result<Vec<(String, u64)>, String> · src/lib.rs:139

(key, size_bytes) for every key starting with prefix.

fn size(&self, key: &str) -> Result<Option<u64>, String> · src/lib.rs:143

Size of one key without reading it. Defaults to reading and measuring — correct everywhere, and a store with a cheaper stat overrides it.

Module holger_plugin_abi::PackageHandler

fn manifest(&self) -> WireManifest · src/lib.rs:154

Identity, reported to the host at load.

fn fetch(&self, store: &dyn BlobStore, id: &WireArtifactId,) -> Result<Option<Vec<u8>>, String> · src/lib.rs:157

Fetch one coordinate's bytes.

fn put(&self, store: &dyn BlobStore, id: &WireArtifactId, data: &[u8]) -> Result<(), String> · src/lib.rs:164

Store one coordinate's bytes.

fn list(&self, store: &dyn BlobStore, name_filter: Option<& str>, limit: usize,) -> Result<Vec<WireArtifactEntry>, String> · src/lib.rs:168

Enumerate held artifacts, filtered by a substring of the name.

fn coordinate_for_path(&self, suburl: &str) -> Option<WireArtifactId> · src/lib.rs:178

Map a raw HTTP suburl back to a coordinate — the inverse of the path this handler serves from. Pure: it must not touch the store, because the serve-time quarantine gate calls it on every request.

fn http(&self, store: &dyn BlobStore, req: &WireHttpRequest,) -> Result<WireHttpResponse, String> · src/lib.rs:181

Answer one HTTP request against this handler's own path scheme.

Module holger_plugin_abi::codec

The byte codec both surfaces share. One writer, one reader — the host links these functions and so does every guest, so a field cannot be encoded one way and decoded another (LAW 5, by construction rather than by a guard watching two copies agree).

Why not JSON

znippy's wasm_loader::parse_json_to_row splits on , and : before stripping quotes, so a value containing either separator silently corrupts the row, and it has no null representation at all — an absent column and an empty one are the same bytes on the wire. Both are properties of the ad-hoc format, not bugs that can be patched out of the parser.

This codec is length-prefixed, so a value is copied by length and its contents are never scanned for structure: ,, :, ", a NUL and an arbitrary UTF-8 sequence all survive a round trip. Option carries an explicit 1-byte tag, so None and Some("") are distinct on the wire. codec_tests.rs asserts exactly those two properties.

Layout

type	bytes
u32 / u16 / u64 / i64	little-endian, fixed width
bool	1 byte, 0 or 1
bytes / String	u32 length, then that many bytes
Option<T>	0u8, or 1u8 then T
Vec<T>	u32 count, then that many T
Result<T, String>	0u8 then T, or 1u8 then the message

enum DecodeError { Truncated, LengthOverflow, BadTag, NotUtf8, TrailingBytes } · src/codec.rs:37

Why a byte string could not be decoded. Every variant names the field being read, because a decode failure on the host side is otherwise indistinguishable from a plugin that returned nothing.

struct Writer · src/codec.rs:77

Append-only byte writer.

struct Reader · src/codec.rs:149

Cursor over a byte string.

fn write_result<T>(w: &mut Writer, v: &Result<T, String>, ok: impl FnOnce(& mut Writer, &T)) · src/codec.rs:266

Encode a Result<T, String>: tag 0 = ok, tag 1 = the error message.

fn read_result<T>(r: &mut Reader<'_>, field: &'static str, ok: impl FnOnce(& mut Reader<'_>) -> Result<T, DecodeError>,) -> Result<Result<T, String>, DecodeError> · src/codec.rs:280

Decode a Result<T, String> written by [write_result].

Module holger_plugin_abi::codec::DecodeError

fn message(&self) -> String · src/codec.rs:294

Render for a Result<_, String> boundary (the ABI carries messages, not types).

Module holger_plugin_abi::codec::Reader

fn new(buf: &'a [u8]) -> Self · src/codec.rs:155

fn remaining(&self) -> usize · src/codec.rs:159

fn expect_end(&self, field: &'static str) -> Result<(), DecodeError> · src/codec.rs:167

Assert the value consumed the whole buffer. Called at the end of every top-level decode: a decoder that stops early is reading a different shape than the encoder wrote, and silently ignoring the tail is how an ABI skew turns into wrong values instead of an error.

fn u8(&mut self, field: &'static str) -> Result<u8, DecodeError> · src/codec.rs:184

fn u16(&mut self, field: &'static str) -> Result<u16, DecodeError> · src/codec.rs:188

fn u32(&mut self, field: &'static str) -> Result<u32, DecodeError> · src/codec.rs:193

fn u64(&mut self, field: &'static str) -> Result<u64, DecodeError> · src/codec.rs:198

fn i64(&mut self, field: &'static str) -> Result<i64, DecodeError> · src/codec.rs:205

fn bool(&mut self, field: &'static str) -> Result<bool, DecodeError> · src/codec.rs:209

fn bytes(&mut self, field: &'static str) -> Result<Vec<u8>, DecodeError> · src/codec.rs:217

fn str(&mut self, field: &'static str) -> Result<String, DecodeError> · src/codec.rs:229

fn opt_str(&mut self, field: &'static str) -> Result<Option<String>, DecodeError> · src/codec.rs:234

fn opt_bytes(&mut self, field: &'static str) -> Result<Option<Vec<u8>>, DecodeError> · src/codec.rs:242

fn count(&mut self, field: &'static str) -> Result<usize, DecodeError> · src/codec.rs:252

Read a u32 count and check it against the bytes actually left, so a corrupt count cannot make the caller pre-allocate an absurd Vec.

Module holger_plugin_abi::codec::Writer

fn new() -> Self · src/codec.rs:82

fn finish(self) -> Vec<u8> · src/codec.rs:86

fn u8(&mut self, v: u8) -> &mut Self · src/codec.rs:90

fn u16(&mut self, v: u16) -> &mut Self · src/codec.rs:95

fn u32(&mut self, v: u32) -> &mut Self · src/codec.rs:100

fn u64(&mut self, v: u64) -> &mut Self · src/codec.rs:105

fn i64(&mut self, v: i64) -> &mut Self · src/codec.rs:110

fn bool(&mut self, v: bool) -> &mut Self · src/codec.rs:115

fn bytes(&mut self, v: &[u8]) -> &mut Self · src/codec.rs:122

Length-prefixed bytes. The payload is copied verbatim — no escaping, no separator scan, so any byte sequence survives.

fn str(&mut self, v: &str) -> &mut Self · src/codec.rs:128

fn opt_str(&mut self, v: Option<& str>) -> &mut Self · src/codec.rs:133

None and Some("") differ by the tag byte, not by length.

fn opt_bytes(&mut self, v: Option<& [u8]>) -> &mut Self · src/codec.rs:140

Module holger_plugin_abi::exports

Exports a .wasm package handler must provide. The host names the missing one when a module falls short, so a half-built module is a loud load failure rather than a backend that answers None to everything.

const ALLOC: & str · src/lib.rs:77

alloc(size: u32) -> u32 — reserve linear memory the host writes into.

const RESULT_LEN: & str · src/lib.rs:79

result_len() -> u32 — byte length of the last returned value.

const MANIFEST: & str · src/lib.rs:81

plugin_manifest() -> u32

const FETCH: & str · src/lib.rs:83

plugin_fetch(ptr, len) -> u32

const PUT: & str · src/lib.rs:85

plugin_put(ptr, len) -> u32

const LIST: & str · src/lib.rs:87

plugin_list(ptr, len) -> u32

const COORDINATE_FOR_PATH: & str · src/lib.rs:89

plugin_coordinate_for_path(ptr, len) -> u32

const HTTP: & str · src/lib.rs:91

plugin_http(ptr, len) -> u32

const ALL: & [& str] · src/lib.rs:94

Every export, in load-check order.

Module holger_plugin_abi::guest

The guest side of the ABI, written once and generated per module.

A wasm module has to export #[no_mangle] extern "C" symbols, and those cannot come from a generic — so without this macro every -wasm crate would carry its own copy of the same ~130 lines of pointer juggling, and two copies of an ABI is exactly how one half drifts from the other. [export_package_handler!] emits all eight exports plus the host-backed [crate::BlobStore] from one line, so a handler's wasm crate really is glue and nothing else (LAW 5).

Everything it emits is #[cfg(target_arch = "wasm32")]. On any other target the crate compiles to an empty library — which is what lets a -wasm crate be an ordinary workspace member that cargo check --workspace covers, without a native build trying to link env::host_store_get.

macro_rules! export_package_handler · src/guest.rs:26

Generate the eight ABI exports for a [crate::PackageHandler].

holger_plugin_abi::export_package_handler!(holger_handler_skidbladnir::SkidbladnirHandler);

The type must implement PackageHandler and be constructible with Default::default(). Nothing else is required of the calling crate, and nothing about the handler's logic passes through here — this macro moves bytes and calls the handler.

Module holger_plugin_abi::imports

Host functions a module imports from env to reach storage. The host owns every byte; the module owns only the format logic.

All four return a packed u64: ptr << 32 | len, and 0 means the host call itself failed — never "absent". Absence is carried inside the payload as an encoded Option, so a stored empty blob and a missing key stay distinguishable (the exact distinction znippy's JSON row format cannot make).

const STORE_GET: & str · src/lib.rs:107

host_store_get(key_ptr, key_len) -> u64 → encoded Option<Vec<u8>>.

const STORE_PUT: & str · src/lib.rs:109

host_store_put(key_ptr, key_len, data_ptr, data_len) -> u64 → encoded Result<(), String>.

const STORE_LIST: & str · src/lib.rs:111

host_store_list(prefix_ptr, prefix_len) -> u64 → encoded Vec<(String, u64)>.

const STORE_SIZE: & str · src/lib.rs:114

host_store_size(key_ptr, key_len) -> u64 → encoded Option<Vec<u8>> holding an 8-byte little-endian size, so "absent" and "zero bytes" stay distinct.

const MODULE: & str · src/lib.rs:119

The module namespace all of the above are imported from.

Module holger_plugin_abi::wire

The values that cross the boundary, and their encoders.

These deliberately mirror holger_traits::{ArtifactId, ArtifactEntry} rather than reusing them: holger-traits depends on znippy-common, which carries arrow, io_uring and the gatling engine, so it cannot be compiled for wasm32-unknown-unknown. The mapping between the two lives in exactly one place — holger_plugin_host::convert — so a guest and a linked backend are projected into the router through the same code.

const ABI_VERSION: u32 · src/wire.rs:15

Bumped when the layout of anything in this module changes. The host refuses a module that reports a different number: a silently mismatched ABI decodes garbage into real fields, which is worse than not loading at all.

struct WireArtifactId { namespace: Option<String>, name: String, version: String } · src/wire.rs:19

A package coordinate. Mirror of holger_traits::ArtifactId.

struct WireArtifactEntry { id: WireArtifactId, size_bytes: i64, content_type: String } · src/wire.rs:54

One listed artifact. Mirror of holger_traits::ArtifactEntry.

struct WireManifest { abi_version: u32, handler: String, format: String, writable: bool } · src/wire.rs:79

What a module says about itself at load time, read once from plugin_manifest. This is why registration can read a directory rather than a config file: the module names itself.

struct WireHttpResponse { status: u16, headers: Vec<(String, String)>, body: Vec<u8> } · src/wire.rs:123

(status, headers, body) — the established HTTP-door contract across holger's backends, carried as one value.

struct WireHttpRequest { method: String, suburl: String, body: Vec<u8> } · src/wire.rs:155

The request half of the HTTP door.

struct WirePutRequest { id: WireArtifactId, data: Vec<u8> } · src/wire.rs:181

Arguments to plugin_put.

struct WireListRequest { name_filter: Option<String>, limit: u32 } · src/wire.rs:203

Arguments to plugin_list.

fn encode_fetch_response(v: &Result<Option<Vec<u8>>, String>) -> Vec<u8> · src/wire.rs:232

fn decode_fetch_response(b: &[u8]) -> Result<Result<Option<Vec<u8>>, String>, DecodeError> · src/wire.rs:240

fn encode_unit_response(v: &Result<(), String>) -> Vec<u8> · src/wire.rs:247

fn decode_unit_response(b: &[u8]) -> Result<Result<(), String>, DecodeError> · src/wire.rs:253

fn encode_list_response(v: &Result<Vec<WireArtifactEntry>, String>) -> Vec<u8> · src/wire.rs:260

fn decode_list_response(b: &[u8]) -> Result<Result<Vec<WireArtifactEntry>, String>, DecodeError> · src/wire.rs:271

fn encode_coordinate_response(v: &Option<WireArtifactId>) -> Vec<u8> · src/wire.rs:286

fn decode_coordinate_response(b: &[u8]) -> Result<Option<WireArtifactId>, DecodeError> · src/wire.rs:300

fn encode_http_response(v: &Result<WireHttpResponse, String>) -> Vec<u8> · src/wire.rs:311

fn decode_http_response(b: &[u8]) -> Result<Result<WireHttpResponse, String>, DecodeError> · src/wire.rs:317

fn encode_store_listing(rows: &[(String, u64)]) -> Vec<u8> · src/wire.rs:325

A (key, size) listing row from [crate::BlobStore::list].

fn decode_store_listing(b: &[u8]) -> Result<Vec<(String, u64)>, DecodeError> · src/wire.rs:334

fn encode_store_get(v: &Option<Vec<u8>>) -> Vec<u8> · src/wire.rs:346

fn decode_store_get(b: &[u8]) -> Result<Option<Vec<u8>>, DecodeError> · src/wire.rs:352

Module holger_plugin_abi::wire::WireArtifactEntry

fn encode(&self, w: &mut Writer) · src/wire.rs:61

fn decode(r: &mut Reader<'_>) -> Result<Self, DecodeError> · src/wire.rs:66

Module holger_plugin_abi::wire::WireArtifactId

fn encode(&self, w: &mut Writer) · src/wire.rs:26

fn decode(r: &mut Reader<'_>) -> Result<Self, DecodeError> · src/wire.rs:30

fn to_bytes(&self) -> Vec<u8> · src/wire.rs:38

fn from_bytes(b: &[u8]) -> Result<Self, DecodeError> · src/wire.rs:44

Module holger_plugin_abi::wire::WireHttpRequest

fn to_bytes(&self) -> Vec<u8> · src/wire.rs:162

fn from_bytes(b: &[u8]) -> Result<Self, DecodeError> · src/wire.rs:168

Module holger_plugin_abi::wire::WireHttpResponse

fn encode(&self, w: &mut Writer) · src/wire.rs:130

fn decode(r: &mut Reader<'_>) -> Result<Self, DecodeError> · src/wire.rs:138

Module holger_plugin_abi::wire::WireListRequest

fn to_bytes(&self) -> Vec<u8> · src/wire.rs:209

fn from_bytes(b: &[u8]) -> Result<Self, DecodeError> · src/wire.rs:215

Module holger_plugin_abi::wire::WireManifest

fn encode(&self, w: &mut Writer) · src/wire.rs:93

fn decode(r: &mut Reader<'_>) -> Result<Self, DecodeError> · src/wire.rs:97

fn to_bytes(&self) -> Vec<u8> · src/wire.rs:106

fn from_bytes(b: &[u8]) -> Result<Self, DecodeError> · src/wire.rs:112

Module holger_plugin_abi::wire::WirePutRequest

fn to_bytes(&self) -> Vec<u8> · src/wire.rs:187

fn from_bytes(b: &[u8]) -> Result<Self, DecodeError> · src/wire.rs:194

Crate holger-plugin-host

Loads holger package handlers — linked or from a directory of .wasm — and wraps each in one RepositoryBackendTrait

holger's package-handler plugin host.

Loads .wasm package handlers from a directory at startup and wraps each one in a RepositoryBackendTrait, so server/lib/src/exposed/fast_routes.rs cannot tell a linked handler from a loaded one — the route table holds Arc<dyn RepositoryBackendTrait> and both kinds arrive as the same concrete [HandlerBackend].

 linked handler ──┐                                    ┌── plugin_fetch
                  ├─► HandlerRuntime ─► HandlerBackend ─┤
 loaded .wasm  ───┘        (one impl of RepositoryBackendTrait)

wasm-plugins (naming mirrors znippy-common's) gates dep:wasmtime. With the feature off this crate still builds and still hosts linked handlers — so a server tier that wants the two bundle handlers compiled in, and no wasmtime in its dependency graph, gets exactly that.

holger does not reach znippy-common for any of this. The loader's shape is borrowed from znippy_common::plugins::wasm_loader — a fresh Store per call, alloc/result_len, host functions on a Linker — but no dependency edge is added, because Rickard was explicit that holger touches znippy for the storage surface only.

Two things about that loader were deliberately not copied:

• its parse_json_to_row splits on , and : before stripping quotes and has no null representation, so a value containing a separator corrupts the row silently. The ABI here is length-prefixed instead, and holger-plugin-abi/tests/codec_survives_what_json_did_not.rs asserts the two properties that fixes.
• it is written in .ok()?, so a trap, a missing export and a genuinely absent value are all None. Here every failure is a named Err: a repository backend that reported a trapped module as "no such artifact" would be a silent 404 over bytes that exist.

Module holger_plugin_host

fn mount_linked<H: PackageHandler + Send + Sync + 'static>(repo_name: impl Into<String>, handler: H, data_dir: impl AsRef<Path>,) -> Result<HandlerBackend, String> · src/lib.rs:74

Mount a handler that is compiled into the server over a directory store.

The native half of "every package handler can be written native or WASM": the same [PackageHandler] a .wasm is built from, called directly.

fn mount_linked_with<H: PackageHandler + Send + Sync + 'static>(repo_name: impl Into<String>, handler: H, store: SharedStore,) -> Result<HandlerBackend, String> · src/lib.rs:85

Mount a handler over a caller-supplied store (an in-memory one in tests, a directory in production).

fn shared_store(store: impl BlobStore + Send + Sync + 'static) -> SharedStore · src/lib.rs:94

Wrap any BlobStore for use by a mounted handler.

Module holger_plugin_host::agreement

The native-vs-wasm agreement harness, written once.

Every handler ships a pair — a native crate that owns the logic and a wasm crate that is ABI glue — and the claim "they are the same code" is only worth anything if something checks it over real bytes. Each -wasm crate's tests/native_wasm_agree.rs calls in here, so the assertions themselves are one implementation: two hand-written guards would be two things that can drift, and one of them would rot silently.

What it refuses to do

• It never skips. A missing or stale .wasm panics with the build command. A test that skipped when the module was absent would be a permanent green — the exact shape that let znippy's wasm example sit "documented but never built" from the day its loader landed.
• It never asserts a bare equality. assert_eq!(native, wasm) passes when both are empty, so every comparison first asserts the content of the native side, then asserts the two match, and names the field that differs.

Both surfaces share one store

The native backend and the loaded module are handed the same [DirStore], so a disagreement is a disagreement about logic, never about which bytes each one could see.

const BUILD_CMD: & str · src/agreement.rs:39

The command that builds every module. Quoted verbatim in each failure so a red test carries its own fix.

fn locate_module(wasm_file_name: &str, source_dirs: &[PathBuf]) -> PathBuf · src/agreement.rs:47

Locate a built module, or panic with everything needed to fix it.

Checks every place it can legitimately land, most specific first, and then asserts it is not older than the sources it is built from — a stale module would let a changed handler pass a guard that compared it against the new native code.

struct Surfaces { native: HandlerBackend, wasm: HandlerBackend, dir: PathBuf } · src/agreement.rs:112

The two surfaces of one handler, over one shared store.

Module holger_plugin_host::agreement::Surfaces

fn build<H: PackageHandler + Send + Sync + 'static>(repo_name: &str, handler: H, wasm_file_name: &str, source_dirs: &[PathBuf],) -> Self · src/agreement.rs:126

Build both surfaces of handler over a fresh temp directory.

source_dirs are the src/ directories whose mtimes decide staleness — the wasm crate's own and every crate whose logic ends up inside the module, because the whole point of the design is that the logic is shared.

fn seed(&self, key: &str, data: &[u8]) · src/agreement.rs:154

Write a blob both surfaces will see.

fn assert_identity(&self, handler: &str, format: traits::ArtifactFormat, writable: bool) · src/agreement.rs:160

Identity must match, and must be the value asked for — not merely equal on both sides.

fn assert_fetch(&self, id: &ArtifactId, expect: Option<& [u8]>) · src/agreement.rs:172

fetch must return the same bytes. The expected body is asserted first, so two identically-broken surfaces returning None cannot pass.

fn assert_coordinate(&self, suburl: &str, expect: Option<(& str, &str)>) · src/agreement.rs:194

coordinate_for_path must resolve identically — the quarantine gate's lookup, and pure path logic, so any difference is a real ABI defect.

fn assert_http(&self, method: &str, suburl: &str, body: &[u8], expect_status: u16, expect_body: Option<& [u8]>,) -> (Vec<(String, String)>, Vec<u8>) · src/agreement.rs:211

The HTTP door must answer with the same status, headers and body.

Every part is compared separately so a failure names which part differs — a single assert_eq! on the tuple would only say "they differ".

fn assert_list(&self, filter: Option<& str>, limit: usize, expect: &[(& str, &str, i64)]) · src/agreement.rs:237

list must return the same rows in the same order.

fn assert_put_crosses(&self, id: &ArtifactId, data: &[u8]) · src/agreement.rs:259

A write through one surface must be readable through the other — the strongest form of "same store, same key scheme".

fn assert_put_refused(&self, id: &ArtifactId, why: &str) · src/agreement.rs:286

A coordinate both surfaces must REFUSE to store. Asserted on both, because a put that silently succeeded would write a blob whose key coordinate_from_key can never read back.

Module holger_plugin_host::backend

The one RepositoryBackendTrait implementation.

There is exactly one in this crate, and both a linked handler and a loaded .wasm reach the router through it. That is not a convention that has to be checked — fast_routes.rs receives an Arc<dyn RepositoryBackendTrait> whose concrete type is [HandlerBackend] in both cases, so there is no second code path for it to take. If the router ever needed to know which kind it had, the design would be wrong.

The split that makes this possible is [HandlerRuntime]: how a verb is executed (a direct call, or an ABI round trip through wasmtime) versus what the router asks for. Storage is bound into the runtime at construction, so by the time the trait is implemented the two are the same shape.

type SharedStore · src/backend.rs:26

A [BlobStore] usable from the server's request path.

trait HandlerRuntime · src/backend.rs:33

One handler, with its storage already bound — however it is executed.

The verbs mirror [PackageHandler] minus the store argument: a runtime owns its store, because a wasm module's store has to live in the wasmtime Store data and cannot be handed in per call.

struct LinkedHandler · src/backend.rs:45

A handler compiled into the server, bound to a store. The native half of "every package handler can be written native or WASM".

struct HandlerBackend · src/backend.rs:93

A package handler as holger's router sees it.

Debug prints the repository name, the format and the handler name — never the runtime, because the whole point is that a caller cannot tell a linked handler from a loaded module by looking at one.

Module holger_plugin_host::backend::HandlerBackend

fn new(repo_name: impl Into<String>, runtime: Box<dyn HandlerRuntime>) -> Result<Self, String> · src/backend.rs:106

Wrap a runtime. Fails if the handler declared a format holger does not know — never falling back to Raw, because a mis-declared format that registered anyway would serve real bytes under the wrong protocol.

fn handler_name(&self) -> &str · src/backend.rs:113

The handler's own name (skidbladnir), as distinct from the repository name this backend is mounted at.

fn into_backend(self) -> Arc<dyn RepositoryBackendTrait> · src/backend.rs:117

Module holger_plugin_host::backend::HandlerRuntime

fn manifest(&self) -> &WireManifest · src/backend.rs:34

fn fetch(&self, id: &WireArtifactId) -> Result<Option<Vec<u8>>, String> · src/backend.rs:35

fn put(&self, id: &WireArtifactId, data: &[u8]) -> Result<(), String> · src/backend.rs:36

fn list(&self, name_filter: Option<& str>, limit: usize) -> Result<Vec<WireArtifactEntry>, String> · src/backend.rs:37

fn coordinate_for_path(&self, suburl: &str) -> Option<WireArtifactId> · src/backend.rs:39

fn http(&self, req: &WireHttpRequest) -> Result<WireHttpResponse, String> · src/backend.rs:40

Module holger_plugin_host::backend::LinkedHandler

fn new(handler: H, store: SharedStore) -> Self · src/backend.rs:52

Module holger_plugin_host::catalog

Which handler READS the container.

A repository config already names the container:

ron_upstream_format = "znippy"     the container

and server/lib/src/repository.rs maps that string onto ArtifactFormat::Znippy. Two handlers that both land on Znippy — a Skidbladnir deploy bundle and a Rust-toolchain bundle are both sealed .znippy files — cannot be told apart from there. znippy is a container: compressed files in a directory, sometimes with an extra index and extra functionality. What the config could not say is who reads the extra index.

ron_handler         = "skidbladnir"   the reader; empty = generic znippy

This catalog is the lookup behind that string, and its whole job is that the string does not care which kind of handler answers it:

  register_linked(SkidbladnirHandler::new) ──┐
                                             ├─► "skidbladnir" ─► HandlerBackend
  load_dir("/var/lib/holger/plugins") ───────┘

A linked handler names itself from its own [PackageHandler::manifest]; a loaded .wasm names itself from the manifest it reports over the ABI. Neither name is invented by the registrar, which is what makes the two interchangeable under one config string — and is why a new handler is a string in the config plus a .wasm in the directory, with no holger rebuild.

An unknown name is a boot error

The precedent is ron_upstream_format in the same config file: a value that is present but unparseable hard-fails, because collapsing it with .unwrap_or(default) meant a typo silently built a repository with the wrong shape and every coordinate 404'd with no warning at boot. Same here. The error lists what is accepted — including every handler found in the plugin directory, which is the half an operator cannot read off the source.

enum Origin { Linked, Loaded } · src/catalog.rs:67

Where a catalog entry came from. Carried only so an operator-facing listing can say linked or name the file — never consulted when mounting, because a caller that branched on it would be re-introducing the distinction this design exists to remove.

struct RejectedModule { path: PathBuf, reason: String } · src/catalog.rs:111

One module in a plugin directory that could not join the catalog. Reported, never dropped: a broken or duplicate module is an operator error that must be visible, and the modules beside it still register.

enum HandlerError { Unknown, Unmountable } · src/catalog.rs:124

Why a configured ron_handler could not be honoured.

struct HandlerCatalog · src/catalog.rs:180

Every package handler this holger can put behind a ron_handler string.

Built once at startup and consulted per repository, so the plugin directory is read — and each module compiled — exactly once no matter how many repositories name a handler.

Module holger_plugin_host::catalog::HandlerCatalog

fn new() -> Self · src/catalog.rs:186

fn register_linked<H, F>(&mut self, make: F) -> Result<String, String> where H: PackageHandler + Send + Sync + 'static, F: Fn() -> H + Send + Sync + 'static, · src/catalog.rs:200

Register a handler compiled into this holger.

make is called once immediately to read the handler's own manifest — the name is the handler's, not the caller's. A registrar that passed a name in could mount SkidbladnirHandler under "rust-toolchain", and the config string would then mean two different things depending on whether it resolved to a linked handler or a module.

Returns the registered name. A second handler claiming a name already held is an Err rather than a silent replacement.

fn load_dir(&mut self, dir: impl AsRef<Path>) -> Result<Vec<RejectedModule>, ScanError> · src/catalog.rs:235

Read a plugin directory and register every .wasm in it under the name its own manifest declares.

A directory that is missing, unreadable or a file is a [ScanError] — never an empty catalog. A directory that exists and holds no module is Ok(vec![]), which is a different answer, and the caller can tell them apart because only one of them is an Err.

The returned rejections are modules that were present and did not register. They are not an error (the modules beside them still serve) and they must not be discarded — they are the only report a broken module makes.

fn load_dir(&mut self, dir: impl AsRef<Path>) -> Result<Vec<RejectedModule>, ScanError> · src/catalog.rs:273

Fail-closed stand-in for a build without the wasm host. A configured plugin directory that cannot be read is louder than a catalog that quietly holds only the linked handlers.

fn accepted(&self) -> Vec<String> · src/catalog.rs:278

Every accepted ron_handler value, sorted.

fn origin(&self, handler: &str) -> Option<Origin> · src/catalog.rs:283

Where a handler came from, or None if the name is not registered.

fn is_empty(&self) -> bool · src/catalog.rs:287

fn mount(&self, handler: &str, repo_name: &str, store: SharedStore,) -> Result<HandlerBackend, HandlerError> · src/catalog.rs:295

Mount handler at repository repo_name over store.

The repository name and the storage are the operator's; a handler never picks where it is served from or where it writes.

fn mount_dir(&self, handler: &str, repo_name: &str, data_dir: impl AsRef<Path>,) -> Result<HandlerBackend, HandlerError> · src/catalog.rs:313

[HandlerCatalog::mount] over a directory store — what a repository config's data directory resolves to.

Module holger_plugin_host::convert

The one mapping between the ABI's wire types and holger's own.

holger-plugin-abi cannot use holger_traits::{ArtifactId, ArtifactEntry} directly — holger-traits depends on znippy-common, which carries arrow, io_uring and the gatling engine, none of which links for wasm32-unknown-unknown. So the ABI mirrors those two types, and everything that projects a handler into the router passes through the four functions here.

Both the linked-handler backend and the wasm backend use them, which is what makes the two indistinguishable to fast_routes.rs by construction rather than by inspection.

fn id_to_wire(id: &ArtifactId) -> WireArtifactId · src/convert.rs:17

fn id_from_wire(id: WireArtifactId) -> ArtifactId · src/convert.rs:25

fn entry_from_wire(e: WireArtifactEntry) -> ArtifactEntry · src/convert.rs:29

fn format_from_wire(s: &str) -> Result<ArtifactFormat, String> · src/convert.rs:47

Parse the manifest's format string into a real [ArtifactFormat].

Delegates to ArtifactFormat::from_format_str, holger's own parser, so a plugin and a RON config spell a format the same way — there is no second table here to drift.

An unrecognised spelling is an error naming the string and every accepted alternative, never a fallback to Raw. A module that mis-declared its format and was silently registered as raw would serve real bytes under a format the router did not mean, which is worse than refusing to load.

Module holger_plugin_host::registry

Registration reads a directory, not server/lib/Cargo.toml.

That is the whole point of the lane. Today holger's sixteen repository backends are unconditional path dependencies of server/lib (server/lib/Cargo.toml:21-51) — none optional, none feature-gated — so adding a package handler means editing a manifest and rebuilding the server. A module dropped into the plugin directory is registered on the next start with no rebuild at all.

Absence is loud

A plugin directory that is missing, unreadable, or a file rather than a directory is a named [ScanError], never an empty list. This tree's disease is the check that returns true because it never ran; a plugin loader that answered "no plugins" to a typo'd path would be the same shape, and would be discovered as a 404 in production rather than as an error at boot.

A directory that exists and genuinely holds no .wasm is a different answer — an empty registry with scanned pointing at the real path — and the caller can tell the two apart because only one of them is an Err.

const MODULE_EXT: & str · src/registry.rs:29

Extension a package-handler module must carry.

enum ScanError { Missing, NotADirectory, Unreadable, NoWasmHost } · src/registry.rs:34

Why a plugin directory could not be scanned at all. Distinct from a single module failing to load, which leaves the other modules usable.

struct LoadFailure { path: PathBuf, reason: String } · src/registry.rs:82

One module that was found but could not be used. Kept rather than dropped: a broken module in the directory is an operator error that must be visible, and the modules beside it still load.

struct Registry { scanned: PathBuf, backends: Vec<HandlerBackend>, failures: Vec<LoadFailure> } · src/registry.rs:95

The result of scanning one plugin directory.

trait Mounts · src/registry.rs:129

How a module's repository name and store are chosen.

A module names its handler (skidbladnir); the repository it is mounted at and the directory it stores into are the operator's, so the host supplies them rather than letting a plugin pick where it writes.

struct FileStemMounts { data_root: PathBuf } · src/registry.rs:143

The default mount policy: the repository is named after the module file's stem, and its store is <data_root>/<stem>.

Naming the repository after the file rather than the handler is deliberate — two copies of the same handler serving two different bundle stores is an ordinary deployment, and keying on the handler name would make the second one silently replace the first in the route table.

fn module_paths(dir: impl AsRef<Path>) -> Result<Vec<PathBuf>, ScanError> · src/registry.rs:167

Every .wasm in dir, sorted — the one directory walk both [scan] and [crate::catalog::HandlerCatalog::load_dir] read a plugin directory through, so "what counts as a module here" is decided once.

The three ways a directory can be unusable are three distinct errors; read_dir alone reports "not found" for all of them.

fn scan(dir: impl AsRef<Path>, mounts: &dyn Mounts) -> Result<Registry, ScanError> · src/registry.rs:200

Scan dir for .wasm package handlers and load each one.

Module holger_plugin_host::registry::Mounts

fn repo_name(&self, path: &Path, handler: &str) -> String · src/registry.rs:131

Repository name for a module found at path with handler name handler.

fn store(&self, path: &Path, handler: &str) -> SharedStore · src/registry.rs:133

The store that module gets.

Module holger_plugin_host::registry::Registry

fn is_empty(&self) -> bool · src/registry.rs:109

True when the directory held no .wasm at all — as distinct from a directory that could not be read, which is a [ScanError].

fn summary(&self) -> String · src/registry.rs:114

A one-line summary for a startup log.

Module holger_plugin_host::store

The host's own [BlobStore]: a directory of files.

This is the storage a linked handler runs on, and it is also what the wasm host hands to a loaded module through the four host_store_* imports — so both surfaces read and write the same bytes in the same place, which is what lets the agreement guard compare them at all.

struct DirStore · src/store.rs:16

A directory-backed blob store. Keys are handler-chosen store paths (tillsynia-20260706.znippy), never absolute paths — a module never learns where the root is.

Module holger_plugin_host::store::DirStore

fn new(root: impl Into<PathBuf>) -> Self · src/store.rs:21

fn root(&self) -> &Path · src/store.rs:25

Module holger_plugin_host::wasm

The wasmtime host: load a .wasm, and answer holger's verbs through it.

Shape borrowed from znippy_common::plugins::wasm_loader — a fresh Store per call, alloc/result_len for the buffer protocol, host functions registered on a Linker. What is deliberately not borrowed is its error handling: that loader is written in .ok()?, so every failure — a missing export, a trap, a bad UTF-8 result — collapses into None, which its caller reads as "this plugin found no metadata". Here a failure is a named Err all the way out, because a repository backend that answers "no such artifact" to a trapped module would be a silent 404 over real bytes.

holger does not reach znippy for any of this. The pattern is copied; no dependency edge is added.

struct WasmHandler · src/wasm.rs:41

A .wasm package handler, loaded and ready to answer.

Engine and Module are Send + Sync; a Store is not, so one is created per call. That also means a call cannot observe another call's linear memory, which is what makes a &self verb sound on a shared backend.

Module holger_plugin_host::wasm::WasmHandler

fn load(path: impl AsRef<Path>, store: SharedStore) -> Result<Self, String> · src/wasm.rs:56

Load a module and read its manifest.

Every failure names the module path and what was wrong with it. In particular a missing export is named individually: a module that is half-built is otherwise indistinguishable from one that simply answers nothing.

fn manifest(&self) -> &WireManifest · src/wasm.rs:120

fn path(&self) -> &Path · src/wasm.rs:124

fn into_runtime(self) -> Box<dyn HandlerRuntime> · src/wasm.rs:445

fn with_store(&self, store: SharedStore) -> Self · src/wasm.rs:457

The same compiled module, bound to a different store.

Compiling the Module is the expensive part of [WasmHandler::load]; binding a store is free. A catalog reads a plugin directory ONCE at boot and then mounts the same handler under however many repositories name it, each with its own storage — so this must not recompile, and it must not re-read the manifest either (a module whose manifest answered differently on a second read would be registered under one name and serve as another).

Crate holger-rust-file-repository

Rust / Cargo repository backend for holger, disk-backed and WRITABLE — speaks the same Cargo sparse protocol as holger-rust-znippy-repository but over a live loose-file tree, so it can accept cargo publish.

Disk-backed (loose-file) Rust/Cargo repository backend — the writable sibling of znippy-rust, which serves the same sparse index synthesized from a read-only znippy archive instead of a live directory tree.

[RustRepoFile] stores each crate as one file at base_dir/{ns}/{name}/{ver} (namespace: None maps to the literal _ dir) and speaks Cargo's sparse protocol over [RepositoryBackendTrait::handle_http2_request]: /index/config.json advertises the dl template, /index/{p1}/{p2}/{name} returns one NDJSON line per stored version, and /crates/{name}/{ver}/download streams the bytes. The sparse index re-hashes every version on each request, so real SHA-256 digests are memoized by a (len, mtime) [FileStamp] under a Mutex — sound only because stored artifacts are immutable (atomic write-then-rename, never overwritten).

THE GOTCHA: namespace/name/version arrive verbatim from the network and are each joined as a single path component, so every one MUST pass [check_component] before any join — a .., separator, or absolute component would otherwise let PathBuf::join traverse (or replace) base_dir into arbitrary host file read/write. Mirrors file-oci's guard.

Module holger_rust_file_repository

struct RustRepoFile { name: String } · src/lib.rs:81

Disk-backed, writable Rust repository backend.

struct RepoPath { p1: & 'a str, p2: & 'a str, name: & 'a str } · src/lib.rs:97

Module holger_rust_file_repository::RustRepoFile

fn new(name: String, base_dir: PathBuf, base_url: String) -> Self · src/lib.rs:110

fn sparse_path<'a>(crate_name: &'a str) -> RepoPath<'a> · src/lib.rs:136

Convert crate name to Cargo sparse 3-part path (p1, p2, name)

fn sparse_crate_from_parts<'a>(parts: &'a [& 'a str]) -> Option<& 'a str> · src/lib.rs:163

Reverse matcher: takes a sparse path slice ["xx","yy","name"] -> crate name

fn crate_sha256_hex(data: &[u8]) -> String · src/lib.rs:171

Crate holger-rust-znippy-repository

[storage-backends] Only backend that consumes the FormatGate reader pin and overrides has_archive; only one with a writable dev-mode archive.

Rust-crate repository backend: serves a Cargo sparse index synthesized on the fly from the .crate files inside a read-only znippy archive — the Rust sibling of the maven/python/npm znippy backends, all implementing [RepositoryBackendTrait]. handle_http2_request speaks the sparse protocol cargo expects: index/config.json (advertises dl, and api only when writable), index/{p1}/{p2}/{crate} (per-version ndjson with real SHA-256 cksums computed from the archived bytes), and crates/{c}/{v}/download. fetch resolves via the typed rust view ([ZnippyArchive::as_rust]) so hyphenated names and pre-release versions come from the index columns the cargo plugin wrote, not a {name}-{version}.crate filename guess — the generic-reader and writable paths fall back to that filename convention.

Two modes: static "drift" archives (read-only, served from reader) and writable dev-mode (with_writable_archive, the /sparring and /cache primary) where put/cargo publish append into an on-disk .znippy and reads re-open it live. Gotcha: put is a read-modify-write of one shared archive, so the write_lock must serialize the contains-check + create/append — without it two concurrent puts (e.g. pull-through cache-miss fetches) both see "absent" and both append, corrupting the archive.

Module holger_rust_znippy_repository

struct RustRepoZnippy { name: String } · src/lib.rs:33

Znippy-backed Rust crate repository.

Serves crates directly from any ZnippyReader backend using random-access extraction — no need to decompress the full archive.

Module holger_rust_znippy_repository::RustRepoZnippy

fn new(name: String) -> Self · src/lib.rs:71

fn with_writable_archive(name: String, archive_path: PathBuf) -> Self · src/lib.rs:88

Create a writable dev-mode repo backed by a .znippy at archive_path (created on the first put). Unlike with_archive, which serves a frozen archive read-only, this serves a live archive that put grows via znippy_common::meta_sink_append — the /sparring and /cache-primary backend. Reboot-safe: each put durably re-seals.

fn with_archive(name: String, archive_path: PathBuf) -> Result<Self> · src/lib.rs:107

Create a repo backed by a specific znippy archive file.

The archive's recorded znippy format version is gated before a single row of it is parsed: one written by a newer znippy than this build reads is refused with a [traits::ArchiveFormatError], so the repo is disabled (instantiate_backends keeps every other repo live) instead of an unknown layout reaching the reader.

fn with_archive_and_url(name: String, archive_path: PathBuf, base_url: String) -> Result<Self> · src/lib.rs:123

Create a repo backed by a specific znippy archive file with a configured base URL. Format-version gated exactly like with_archive.

fn with_reader(name: String, reader: Arc<dyn ZnippyReader>) -> Self · src/lib.rs:138

Create a repo backed by any ZnippyReader implementation.

fn with_base_url(mut self, url: String) -> Self · src/lib.rs:151

Override the public base URL used in sparse index config.json.

fn list_files(&self) -> Vec<String> · src/lib.rs:189

fn get_file(&self, relative_path: &str) -> Result<Vec<u8>> · src/lib.rs:196

fn contains(&self, relative_path: &str) -> bool · src/lib.rs:203

Crate holger

[server-core] The holger-server binary; tier compile_error! guard lives here. default-features=false on server-lib (the airgap keystone).

Module holger_server_cli::appliance

The appliance identity ceremony, holger-side — a thin caller of edda's wg-appliance-core::ceremony (the ONE implementation holger, gunnar and korp share; nothing ceremony-shaped is implemented here).

The gate lives in the declaration, not in folklore

The ceremony runs iff env [GATE_ENV]=1. The [[build.container]] appliance cell in .nornir/build-variants.toml DECLARES that env into the image, and the ISO shape will declare it on the kernel cmdline's environment — so "this binary is an appliance" is a property of the packed artifact, never of a hand-typed flag. A plain holger-mvp start on a dev box prints nothing and serves normally.

Fixed paths, fixed forever

<root>/wg/hub.conf, <root>/wg/identity.key, <root>/wg/identity.pub, where <root> is [DATA_ENV] or /data — the SAME names the ISO shape uses on P3 and the container shape uses on its volume (one dialect, both shapes; the filenames are constants in the shared crate). Deliberately NOT $HOLGER_DATA: that is the registry data root, movable per install; the ceremony's directory is the durable identity root the volume/partition mounts, and overloading one env with both meanings would let a config change silently relocate the identity.

Fail loud, never half-up

• Corrupt/missing-permission identity → refuse BY NAME (the shared crate's error), nonzero exit — the appliance never invents an identity.
• hub.conf present but the tunnel cannot come up (no /dev/net/tun, no CAP_NET_ADMIN) → wg-appliance tunnel: FAILED — … naming the missing precondition, nonzero exit. A declared hub that is not reachable is a broken appliance, not a warning.
• No hub.conf → identity-only ceremony (print the key, serve). That is first-boot reality: the operator needs the public key OUT before the hub can be configured at all.

Named remainder (recorded, not invented): no interface-address writer. The shared crate deliberately carries none (see its crate doc) and holger …

const PRODUCT: & str · src/appliance.rs:51

The product name in the canonical identity line.

const GATE_ENV: & str · src/appliance.rs:53

The gate: the ceremony runs iff this env is 1.

const DATA_ENV: & str · src/appliance.rs:55

Overrides the durable root (default [DEFAULT_ROOT]) — the test seam.

const DEFAULT_ROOT: & str · src/appliance.rs:58

The durable identity root: P3's mountpoint on metal, the volume in a container. wg/ under it holds the ceremony files.

const INTERFACE: & str · src/appliance.rs:60

The tun interface name, same on every shape.

struct Appliance { public_b64: String, minted: bool, tunnel: Option<TunnelHandle> } · src/appliance.rs:64

What the ceremony did — the caller emits testmatrix rows from this and holds the guard for the life of the serve loop.

fn gate_enabled() -> bool · src/appliance.rs:77

Is the appliance gate on? (Exact 1, nothing fuzzy: HOLGER_APPLIANCE=true is a config typo, and a typo that half-enables an identity ceremony is worse than one that visibly does nothing.)

fn run_ceremony() -> Result<Appliance, String> · src/appliance.rs:92

Run the ceremony (the gate is the CALLER's check, so a gated-off run prints nothing at all). Prints the MINTED line (first boot only), then the ONE canonical identity line, then either brings the declared tunnel up or says exactly why it cannot. Every error string names the thing to go look at.

Module holger_server_cli::secure_update

Secure Update Gateway offline operations: verified bundle import (with anti-rollback), integrity scrub, backup/restore, and audit-segment verify.

All of these reuse the network-free holger-update-bundle crate. Import and scrub key off the target RON config + a raw repository name (whose ron_data_dir is the served bundle store); backup packages that store into a single verifiable znippy archive.

struct BundleArgs { op: BundleOp } · src/secure_update.rs:26

enum BundleOp { Import } · src/secure_update.rs:32

struct ImportArgs { config: PathBuf, repo: String, bundle: PathBuf, policy: PathBuf, target_product: Option<String>, target_model: Option<String>, target_revision: Option<String> } · src/secure_update.rs:39

struct ScrubArgs { config: PathBuf, repo: String, policy: PathBuf } · src/secure_update.rs:61

struct BackupArgs { op: BackupOp } · src/secure_update.rs:72

enum BackupOp { Create, Verify, Restore } · src/secure_update.rs:78

struct BackupCreateArgs { config: PathBuf, repo: String, output: PathBuf } · src/secure_update.rs:90

struct BackupVerifyArgs { input: PathBuf } · src/secure_update.rs:100

struct BackupRestoreArgs { input: PathBuf, data_root: PathBuf } · src/secure_update.rs:106

struct AuditVerifyArgs { op: AuditOp } · src/secure_update.rs:115

enum AuditOp { Verify } · src/secure_update.rs:121

struct AuditVerifyInner { config: PathBuf } · src/secure_update.rs:127

fn run_bundle(a: BundleArgs) -> Result<()> · src/secure_update.rs:185

fn run_import(a: ImportArgs) -> Result<()> · src/secure_update.rs:191

fn run_scrub(a: ScrubArgs) -> Result<()> · src/secure_update.rs:356

fn run_backup(a: BackupArgs) -> Result<()> · src/secure_update.rs:420

fn run_audit(a: AuditVerifyArgs) -> Result<()> · src/secure_update.rs:570

Crate holger-server-lib

[server-core] Wiring engine, 8 gRPC services, HTTP door, auth, audit, promote, retention, replication, raw. Central high-coupling crate.

The holger server crate: turns a RON config into a running artifact server.

Config is a directed graph of three node kinds — [Repository] (a backend plus its upstreams), [ExposedEndpoint] (a gRPC + optional HTTP/OCI gateway), and [StorageEndpoint] (disk or a znippy archive). [wire_holger] resolves that graph in passes: index every node by ron_name, wire forward refs (repo→storage, repo→exposed) and reverse links (exposed→repos), then build a per-endpoint [FastRoutes] table. Any repo with configured upstreams is wrapped in a ProxyBackend at this stage so a 404 in the local archive falls through to the upstream pull-through automatically.

Two entry modes share the same wired graph: call [Holger::fetch]/[Holger::put] in-process, or [Holger::start] to spin up the tonic gRPC services (and HTTP gateways) fronted by shared auth ([auth]) and one append-only audit sink ([audit]). Boot is deliberately fault-tolerant — a single bad archive is disabled and logged (see [Holger::instantiate_backends]) rather than sinking the whole server; only an all-repos failure hard-fails.

Gotcha: the wiring uses raw *const pointers between nodes, so the graph is valid only while the owning Vecs stay put — never mutate or reallocate repositories/exposed_endpoints/storage_endpoints after wire_holger. Related seams: ron_url/ron_http_url parse as bare SocketAddrs, so any scheme'd URL must go through bare_socket_addr first (see [dev_pair_ron]).

Module holger_server_lib

const GIT_HASH: & str · src/lib.rs:104

Short git commit hash of the build tree, stamped by build.rs (pure-Rust, no shelling — reads .git/HEAD directly). "unknown" when built without git metadata (e.g. a source tarball).

const VERSION_LINE: & str · src/lib.rs:110

The single-source holger version identity: holger v<CARGO_PKG_VERSION> (<git-hash>). Every version surface — the server bins' --version/-V, the gRPC + in-process health.version, and any About/identity readout — prints THIS exact string so they can never drift. Built at compile time (concat!).

fn wire_holger(holger: &mut Holger) -> Result<()> · src/lib.rs:134

enum SecurityProfile { Standard, Critical } · src/lib.rs:280

Server security posture. Standard keeps the existing availability-oriented semantics (open reads, best-effort audit). Critical is opt-in and fail-closed: startup refuses any configuration that cannot enforce the profile (see [Holger::validate_profile]).

enum OperationMode { ReadWrite, ReadOnly } · src/lib.rs:291

Whether the node accepts network mutations at all. ReadWrite is the existing behavior; ReadOnly rejects every network PUT/POST/PATCH/DELETE and every mutating gRPC call before the request body is collected, at the auth choke points, in addition to the existing write-gate.

struct Holger { repositories: Vec<Repository>, exposed_endpoints: Vec<ExposedEndpoint>, storage_endpoints: Vec<StorageEndpoint>, auth: Option<auth::AuthConfig>, audit: AuditSettings, security_profile: SecurityProfile, operation_mode: OperationMode, ron_plugin_dir: Option<String> } · src/lib.rs:298

struct AuditSettings { dir: String, enabled: bool } · src/lib.rs:340

Audit-log configuration. On by default; the default backend is the append-only Arrow IPC log ([audit::ArrowIpcAuditLog]).

fn read_ron_config<P: AsRef<Path>>(path: P) -> Result<Holger> · src/lib.rs:476

fn dev_pair_ron(data_dir: &Path, grpc_url: &str, http_addr: &str) -> String · src/lib.rs:514

Autogenerate the RON config for the dev release pair that nornir embeds:

• /cache — a writable-znippy primary with a crates-io (rust-remote) upstream → a transparent caching crates.io mirror (write-through fills it).
• /sparring — a writable-znippy registry → the release rehearsal target; seal freezes it into a static drift snapshot.

nornir writes this to a file and launches holger start --config <file> as a subprocess (no library linking, no version coupling). cargo speaks the HTTP SPARSE protocol, so it talks to http_addr (the FastRoutes gateway), e.g. sparse+http://<http_addr>/cache/index/; grpc_url is the control plane. Archives live under data_dir. Render the dev release pair config — the registry nornir embeds:

• /cache — a writable-znippy primary with a crates-io (rust-remote) upstream → a transparent caching crates.io mirror (write-through fills it).
• /sparring — a writable-znippy registry → the release rehearsal target; seal freezes it into a static drift snapshot.

nornir writes this to a file and launches holger start --config <file> as a subprocess (no library linking, no version coupling). cargo speaks the HTTP SPARSE protocol, so it talks to http_addr (the FastRoutes gateway), e.g. sparse+http://<http_addr>/cache/index/; grpc_url is the control plane. Archives live under data_dir.

This pair was the FIRST instance of "provision a repo set", spelled out as a hand-formatted string. It is now [provision::Manifest::dev_pair] rendered through the ONE provisioning renderer (L5), so the pair cannot drift from the general path. The output is asserted byte-identical to what it produced before — nornir launches holger start --config <that file>, which makes it a shipped contract, not an internal detail.

Module holger_server_lib::Holger

fn fetch(&self, repository: &str, id: &traits::ArtifactId) -> Result<Option<Vec<u8>>> · src/lib.rs:522

Fetch an artifact by ID from a named repository

fn put(&self, repository: &str, id: &traits::ArtifactId, data: &[u8]) -> Result<()> · src/lib.rs:527

Store an artifact (write-enabled repos only)

fn list_repositories(&self) -> Vec<& str> · src/lib.rs:535

List all configured repository names

fn search_all(&self, query: &search::SearchQuery) -> search::SearchResults · src/lib.rs:545

Cross-repo artifact SEARCH (parity §H, .nornir/search-design.md) — the in-process entry the CLI's search verb drives. Collects every configured repository's live backend and runs the pure [search::search_repos] engine against query. Repos with no materialized backend (a virtual group, or one disabled on init) are skipped — their members are searched directly. Read-only: it never mutates a backend.

fn replicate_into(&self, dest: &Holger, only: Option<& str>, opts: &replication::ReplicationOptions,) -> replication::ReplicationReport · src/lib.rs:578

Replicate this store's artifacts INTO another holger store (parity §I, .nornir/replication-design.md) — the in-process entry the CLI's replicate --from --to verb drives. Reads only from self (the source) and writes only into dest (the destination); content-id idempotent, so a re-run over an unchanged source is a no-op.

Repos are paired by NAME: a source repo foo replicates into the destination repo foo. A source repo with no same-named writable destination is reported (its artifacts fail closed), never silently dropped. only restricts the run to a single source repo name; None replicates every repo that has a destination match. See [replication::replicate_pairs].

fn resolved_audit_dir(&self) -> std::path::PathBuf · src/lib.rs:621

The configured audit dir, anchored. An ABSOLUTE audit.dir is honoured verbatim (explicit config always wins). A RELATIVE one — including the holger-audit default — resolves against $HOLGER_DATA when set, and only against the process CWD when it is not.

$HOLGER_DATA is the data root the installer already establishes (~/.holger user scope, ~/.holger system scope — see holger-server install, which also sets WorkingDirectory=). An installed server therefore resolves identically either way. What this fixes is the EMBEDDED/uninstalled case: holger running in-process inside dwarves or nornir inherits their CWD, so a CWD-relative default scattered a fresh audit log, job ledger, PROD store, SBOM and property store into whatever directory the host happened to start in.

fn sbom_store(&self) -> sbom::SharedSbomStore · src/lib.rs:641

The hosted-SBOM store (<data_root>/holger-sboms). Derived once from the config so every surface — the SbomService gRPC RPCs, the GET /-/sbom HTTP door, and the holger-server sbom CLI verb — reads and writes the same on-disk store. See [sbom::SbomStore], .nornir/sbom-hosting-design.md.

fn property_store(&self) -> properties::SharedPropertyStore · src/lib.rs:650

The custom-property store (<data_root>/holger-props). Derived once from the config so every surface — the gRPC Search property axis, the GET/PUT /-/properties HTTP door, and the holger-server properties CLI verb — reads and writes the same on-disk store. See [properties::PropertyStore], .nornir/properties-design.md.

fn promotion_engine(&self) -> Result<promote::PromotionEngine> · src/lib.rs:672

The promotion engine (<data_root>/holger-prod-store), gates and all. Derived once from the config so every surface — the gRPC PromotionService.PromoteArtifact RPC and the holger-server promote CLI verb — seals into the SAME immutable PROD store under the SAME policy.

The gates are read from the environment, exactly as serve has always read them, so a local promotion cannot be a way to walk around the boundary the served path enforces:

• Policy gate ([promote::PolicyGate::from_env]) — OFF unless HOLGER_PROMOTE_ENFORCE is set. A configured-but-unreadable advisory feed is an Err here (fail-closed): serve refuses to start and the CLI refuses to promote, rather than waving the artifact through unscanned.
• Property requirement (HOLGER_PROMOTE_REQUIRE_PROPERTY=key=value, or a bare key) — OFF unless set.

No job ledger is attached here: that is serve-side observability which the server layers on with [promote::PromotionEngine::with_job_ledger].

fn set_artifact_property(&self, repo: &str, id: &traits::ArtifactId, key: &str, values: Vec<String>,) -> std::io::Result<properties::PropertyMap> · src/lib.rs:696

Set (or, with empty values, remove) one custom-property key on the artifact coordinate (repo, id) — the write side the HTTP door + CLI drive. Returns the resulting full property map. Last-wins per key; other keys are untouched.

fn get_artifact_properties(&self, repo: &str, id: &traits::ArtifactId,) -> properties::PropertyMap · src/lib.rs:708

All custom properties attached to (repo, id) (empty when none) — the read side the HTTP door + CLI drive.

fn plan_repo_retention(&self, repository: &str, policy: &retention::RetentionPolicy, now: i64,) -> Result<retention::RetentionPlan> · src/lib.rs:728

Plan retention/GC for one repository: gather its listing (backend.list()) as [retention::ArtifactRecord]s and run the pure [retention::plan_retention] planner against policy at now (unix seconds).

This is a planner only — it computes which artifacts a retention policy would keep vs reclaim; it deletes nothing (holger's znippy archives are immutable, so carrying a plan out is an archive-set drop delegated to a jera job). Backends that can't enumerate return an empty listing, so the plan is empty rather than an error. created_at is left None (the listing carries no per-artifact ingest time today), so keep_last_n / max_total_bytes apply by version + size while max_age_secs no-ops — see .nornir/retention-design.md.

fn execute_repo_retention(&self, repository: &str, plan: &retention::RetentionPlan, opts: &retention::GcOptions, audit: &dyn audit::AuditLog, jobs: Option<& Arc<jera::jobs::JobStore>>,) -> Result<retention::GcReport> · src/lib.rs:783

Carry out a [retention::RetentionPlan] against one repository — the executor to plan_repo_retention's planner. The planner decided what to reclaim; this acts on that decision and historizes the outcome.

Gated + safe:

• opts.dry_run defaults to true — a preview reclaims nothing. An actual drop only happens when the caller passes [retention::GcOptions::execute].
• A record the plan kept is never touched (only decision.delete rows are considered), and — defense in depth against a hand-built or corrupted plan — any delete row still carrying a ProtectedLatest/MinPerNameFloor reason is refused (skipped), so a protected/latest generation can never be dropped through this path.
• Every delete is content-id verified: the executor reads the stored bytes, computes their SHA-256, and hands it to the backend, which re-verifies against what is on disk before it unlinks — a store that changed under the plan is refused, never deleted blind.

Historized: each actual reclaim is appended to audit as an [audit::AuditAction::Delete] event (identity holger-retention-gc, the reclaimed byte count, the plan's reasons as detail) — the append-only Arrow warehouse record of what the GC took. When a jera job ledger is attached (jobs), the whole run is wrapped in one tracked retention-gc job (running → done|failed + a reclaim summary), reusing the same durable job seam promotion uses.

fn run_repo_retention(&self, repository: &str, policy: &retention::RetentionPolicy, now: i64, opts: &retention::GcOptions, audit: &dyn audit::AuditLog, jobs: Option<& Arc<jera::jobs::JobStore>>,) -> Result<retention::GcReport> · src/lib.rs:986

Plan and execute retention for one repository in a single call — a convenience over plan_repo_retention + execute_repo_retention. Still gated: opts.dry_run decides whether anything is actually reclaimed.

fn audit_log(&self) -> Result<Arc<dyn audit::AuditLog>> · src/lib.rs:1003

Build the shared audit sink from this config (append-only Arrow IPC, or a no-op when audit is disabled) — the same sink the server installs at boot. Public so one-shot tools (the retention GC executor CLI) can historize into the very same warehouse the running server writes.

fn get_repo(&self, name: &str) -> Result<& Arc<dyn RepositoryBackendTrait>> · src/lib.rs:1012

Get a repository backend by name.

Public so one-shot tools drive the very same backends the server serves — the holger-server promote CLI verb resolves its SOURCE repo through this, exactly as the gRPC PromoteArtifact handler does.

fn start(&self) -> Result<()> · src/lib.rs:1026

Start gRPC servers (and optional HTTP gateways) for all configured exposed_endpoints

fn validate_profile(&self) -> Result<()> · src/lib.rs:1309

Validate that the configuration can enforce the requested security profile. Pure (no I/O, no backend state) and fail-closed: in Critical any missing requirement is a hard error; Standard always passes. Never rewrites the operator's config — it only refuses.

fn handler_catalog(&self) -> Result<handlers::HandlerCatalog> · src/lib.rs:1367

The handlers any repository's ron_handler may name: the linked ones, plus every .wasm in ron_plugin_dir when one is configured.

Built ONCE per config, so the directory is read and each module compiled a single time however many repositories name a handler.

fn instantiate_backends(&mut self) -> Result<()> · src/lib.rs:1390

Module holger_server_lib::audit

Append-only audit log.

Records who did what to which artifact from where. The default backend ([ArrowIpcAuditLog]) persists events as append-only Arrow IPC stream segments on disk — columnar, never rewritten, and directly loadable by any Arrow/Parquet tool for offline review.

The [AuditLog] trait is the swap point: the backend can be replaced with a Parquet writer, a database sink, an in-memory buffer ([MemoryAuditLog], used in tests), or disabled entirely ([NoopAuditLog]) without touching the request path. The server holds an Arc<dyn AuditLog> and the default wiring installs ArrowIpcAuditLog.

enum AuditAction { Download, Upload, Delete, List, Promote, Other } · src/audit/mod.rs:24

The operation an audit record describes.

struct AuditEvent { ts_nanos: i64, ident: String, action: AuditAction, repo: String, artifact: String, source_ip: String, status: u16, bytes: u64, detail: String } · src/audit/mod.rs:72

One immutable audit record.

The fields are the security-relevant 5 W's: time, identity, action, the artifact + repo it touched, and the client source address — plus the result status and transferred byte count.

fn now_nanos() -> i64 · src/audit/mod.rs:131

Current wall-clock time in nanoseconds since the Unix epoch (0 if the clock is before the epoch, which cannot happen on a sane host).

trait AuditLog · src/audit/mod.rs:141

Pluggable audit sink. Implementations MUST be append-only and thread-safe; the server shares a single Arc<dyn AuditLog> across all request handlers, so record takes &self and is expected to be internally synchronised.

fn default_audit_log(dir: impl AsRef<Path>) -> Result<Arc<dyn AuditLog>, AuditError> · src/audit/mod.rs:154

Construct the default audit backend ([ArrowIpcAuditLog]) writing append-only Arrow IPC segments under dir, as a ready-to-share trait object.

struct NoopAuditLog · src/audit/mod.rs:161

A disabled audit log — records nothing. The default the server falls back to when no audit directory is configured.

struct MemoryAuditLog · src/audit/mod.rs:172

In-memory audit log — keeps every event in a Vec. For tests and for callers that want to inspect/route events themselves.

enum AuditError { Io, Arrow, Other } · src/audit/mod.rs:197

Errors from an audit backend.

Module holger_server_lib::audit::AuditAction

fn as_str(&self) -> &'static str · src/audit/mod.rs:41

Stable lowercase wire string (what gets written to the log column).

fn from_wire(s: &str) -> Self · src/audit/mod.rs:54

Inverse of [AuditAction::as_str]; unknown strings map to Other so a reader never fails on a value written by a newer server.

Module holger_server_lib::audit::AuditError

fn code(&self) -> &'static holger_errcode::ErrCode · src/audit/mod.rs:212

The FROZEN holger-audit-<n> code — the machine half of the dual channel.

Exhaustive on purpose: a new variant without a code is a COMPILE error. An audit-log write failure is the one error class that must never be swallowed silently, so it carries a code an operator can alert on.

fn tagged(&self) -> String · src/audit/mod.rs:221

BOTH channels in one string.

Module holger_server_lib::audit::AuditEvent

fn new(ident: impl Into<String>, action: AuditAction, repo: impl Into<String>, artifact: impl Into<String>, source_ip: impl Into<String>, status: u16, bytes: u64,) -> Self · src/audit/mod.rs:100

Build an event stamped with the current wall-clock time and no detail.

fn with_detail(mut self, detail: impl Into<String>) -> Self · src/audit/mod.rs:123

Attach a detail string (builder style).

Module holger_server_lib::audit::AuditLog

fn record(&self, event: AuditEvent) -> Result<(), AuditError> · src/audit/mod.rs:144

Append one event. Should be durable by the time it returns (the default backend flushes per call).

fn flush(&self) -> Result<(), AuditError> · src/audit/mod.rs:147

Flush any buffered state to durable storage. Default: no-op.

Module holger_server_lib::audit::MemoryAuditLog

fn new() -> Self · src/audit/mod.rs:178

Empty log.

fn events(&self) -> Vec<AuditEvent> · src/audit/mod.rs:183

Snapshot of every recorded event, in insertion order.

Module holger_server_lib::audit::arrow_ipc

Default audit backend: append-only Arrow IPC stream segments.

Each [ArrowIpcAuditLog] instance opens one fresh segment file under the configured directory and only ever appends record batches to it — the file is never rewritten or truncated, so the log is append-only by construction. A process restart opens a new segment; nothing existing is touched. Reading back ([ArrowIpcAuditLog::read_dir]) replays every segment in the directory.

One event = one single-row batch, flushed to the OS on each record, so a crash loses at most the in-flight call. Audit volume is low relative to artifact serving, so the per-row batch overhead is irrelevant here.

fn audit_schema() -> SchemaRef · src/audit/arrow_ipc.rs:36

The columnar schema for audit records. Field order is the canonical column order used by both the writer and [ArrowIpcAuditLog::read_dir].

struct ArrowIpcAuditLog · src/audit/arrow_ipc.rs:52

Append-only Arrow IPC audit log. Cloneable handles are not provided directly; share via Arc<dyn AuditLog> (see [super::default_audit_log]).

Module holger_server_lib::audit::arrow_ipc::ArrowIpcAuditLog

fn new(dir: impl AsRef<Path>) -> Result<Self, AuditError> · src/audit/arrow_ipc.rs:62

Open a new append-only segment under dir (created if missing).

fn segment_path(&self) -> &Path · src/audit/arrow_ipc.rs:104

Path of the segment this instance is appending to.

fn read_dir(dir: impl AsRef<Path>) -> Result<Vec<AuditEvent>, AuditError> · src/audit/arrow_ipc.rs:126

Replay every audit-*.arrows segment in dir, oldest-named first, returning all events in file then in-file order. Missing dir = empty.

fn read_segment(path: impl AsRef<Path>) -> Result<usize, AuditError> · src/audit/arrow_ipc.rs:201

Strictly read ONE segment file, returning the event count. Unlike read_dir (which tolerates a crash-truncated segment for availability), this errors on an unreadable header or a corrupt/truncated batch — so an offline audit verify flags the bad segment instead of silently skipping it.

Module holger_server_lib::auth

Authentication and authorization for holger-server.

The general auth POLICY / composition layer this module used to own — the RBAC role model ([Role], [AuthConfig] + its role_for / role_for_repo / rbac_enabled / authorize_read / the warn_* boot checks), the declarative [AuthMethodConfig] (OIDC / OAuth2 / mTLS / static-token), [AuthIdentity] / [AuthError], and [validate_request] (which builds the enabled, feature-gated nornir_service::AuthProvider set from the config and dispatches a bearer + client-cert CN through it) — was promoted verbatim into the shared nornir-auth-policy edda leaf (suite auth-unify) so korp / dwarves / nornir adopt the SAME login + authorization model. holger is now the reference CONSUMER, not the owner.

This module re-exports that public API UNCHANGED, so every holger call site (grpc.rs, exposed/http.rs) keeps using crate::auth::{…} exactly as before — the promotion is zero-behavior-change. The provider feature set is still pinned per tier by holger's own auth-{bearer,oidc,oauth2,mtls} features, which forward 1:1 into the leaf.

Module holger_server_lib::exposed

Exposed endpoints: the listener side of the wiring graph.

An [ExposedEndpoint] is a RON-configured serving surface — a gRPC address, optionally a twin HTTP/OCI address (ron_http_url) fronting the same repos for ecosystem clients (helm/pip/cargo, OCI registry) plus /healthz+/readyz. One ron_tls covers BOTH ports; absent = cleartext, dev/loopback only. Submodules: http (the gateway), tls (settings/loading), fast_routes (per-endpoint aggregated repo lookup, attached last in the wiring pass).

Gotcha: wired_{in,out}_repositories hold raw *const Repository back-refs and are #[serde(skip)] — they are populated by the wiring engine after the graph is indexed, so they are dangling/empty on a freshly deserialized config and must never outlive the Repository arena that backs them.

struct ExposedEndpoint { ron_name: String, ron_url: String, ron_http_url: Option<String>, ron_tls: Option<crate::exposed::tls::TlsSettings>, ron_max_body_bytes: Option<usize>, aggregated_routes: Option<FastRoutes>, wired_in_repositories: Vec<* const Repository>, wired_out_repositories: Vec<* const Repository> } · src/exposed/mod.rs:25

An exposed gRPC endpoint configured in RON

Module holger_server_lib::exposed::fast_routes

Repo-name → backend dispatch table on the gRPC/HTTP hot path.

An ExposedEndpoint fans out to many repos; every request must resolve the repo name to its RepositoryBackendTrait before fetch()/put(). Rather than a HashMap this uses a first-byte bucketed table: routes are sorted by initial byte (then length), and first_byte_index/first_byte_len give the [start, len) slice for a byte in O(1), so lookup scans only same-first-byte names with exact == compare — no hashing, cache-friendly for the small, fixed route sets the wiring engine attaches.

Built once and immutable: FastRoutes::new is called after the graph is wired, and the struct is Clone (cheap — Arc backends) but never mutated. Gotcha: bucketing is purely on the first byte, and empty names fold into byte 0 (unwrap_or(0)), so an empty-string route collides with anything else keyed at index 0 — names are assumed non-empty and unique.

struct FastRoute { name: String, backend: Arc<dyn RepositoryBackendTrait> } · src/exposed/fast_routes.rs:22

struct FastRoutes { routes: Vec<FastRoute>, first_byte_index: [usize; 256], first_byte_len: [usize; 256] } · src/exposed/fast_routes.rs:29

Module holger_server_lib::exposed::fast_routes::FastRoutes

fn new(routes: Vec<(String, Arc<dyn RepositoryBackendTrait>)>) -> Self · src/exposed/fast_routes.rs:36

fn lookup(&self, name: &str) -> Option<& Arc<dyn RepositoryBackendTrait>> · src/exposed/fast_routes.rs:73

fn all_repos(&self) -> Vec<(String, Arc<dyn RepositoryBackendTrait>)> · src/exposed/fast_routes.rs:92

Module holger_server_lib::exposed::http

HTTP/OCI gateway: the one non-gRPC ingress, letting HTTP-only clients (helm, pip, cargo, OCI registry pushes via oci://…) reach the same repository backends the tonic service in grpc.rs serves — each request is routed to a backend and dispatched through its handle_http2_request. [GatewaySettings] carries the shared [FastRoutes], auth config, optional TLS, body cap, and the audit sink into every connection.

Security-app rules, deliberately kept in lockstep with the gRPC path: TLS terminates here and mTLS CN is lifted from the handshake once per connection; reads (GET/HEAD) stay open and audit as anonymous, while writes must pass auth::validate_request then authorize_http_write (RBAC mirror of grpc::authorize_write, DELETE = admin, other writes = writer-or-admin, fail-closed under a configured policy). Only /healthz, /readyz, and the /v2 OCI version probe are unauthenticated and unaudited. Routing keys off the first path segment (/v2/{name}/… for OCI, else /{repo}/…) via [route_key]; backends strip their own prefix from the passed-through path.

Gotcha: the read-only write-gate (backend.is_writable()) and the body-size cap both fire BEFORE the body is collected, so a rejected write never buffers the upload — this is intentional, closing the DoS surface the pre-gate HTTP path left open (it used to hand writes to a read-only backend that silently swallowed them).

struct GatewaySettings { routes: FastRoutes, auth_config: Arc<AuthConfig>, tls: Option<Arc<ServerConfig>>, max_body_bytes: usize, audit: Arc<dyn AuditLog>, operation_mode: crate::OperationMode, security_profile: crate::SecurityProfile, sboms: Option<crate::sbom::SharedSbomStore>, properties: Option<crate::properties::SharedPropertyStore>, quarantine: Option<(String, String)> } · src/exposed/http.rs:65

Everything a gateway connection needs, shared behind an Arc.

fn start_http_gateway(addr: std::net::SocketAddr, settings: Arc<GatewaySettings>,) -> anyhow::Result<()> · src/exposed/http.rs:109

Bind the HTTP/OCI gateway and start its accept loop.

The bind happens synchronously, in the caller's context, so a failure (EADDRINUSE from a second holger or any other process on the port, EACCES on a privileged port under a non-root unit) is returned as an Err and reaches Holger::start() → holger-server start, which exits non-zero.

It used to bind inside the spawned task, where the only way to report failure was an eprintln! and a bare return while this function returned Ok(()) regardless. The process then reported full success — exit status 0, server_started=true, systemd active (running) — and blocked on Ctrl+C while serving nothing. Every client got connection-refused and no automated check ever fired. Only the accept LOOP belongs in the background; readiness is a caller-visible fact.

pub(crate) struct SbomCoordQuery { repository: String, id: traits::ArtifactId } · src/exposed/http.rs:923

The parsed coordinate for the GET /-/sbom door: which repository + artifact (namespace/name/version) an SBOM is requested for. Missing pieces are empty strings (the handler rejects a query lacking repo/name/version).

pub(crate) fn serve_sbom_door(sboms: Option<& crate::sbom::SharedSbomStore>, raw_query: &str,) -> (u16, &'static str, Vec<u8>, String, String) · src/exposed/http.rs:968

Serve the read-only GET /-/sbom door: resolve the coordinate from raw_query, fetch the hosted SBOM from sboms, and return (status, content_type, body, repository, label). Pure over the store it is given, so the HTTP handler and its test share exactly one code path — the byte-identical serving is asserted directly, not through a live socket.

• 400 when repo/name/version are not all present.
• 200 + the byte-identical CycloneDX document when an SBOM is attached.
• 404 when no SBOM is attached (or hosting is not configured on this server).
• 500 on a store read error.

pub(crate) fn serve_properties_door(props: Option<& crate::properties::SharedPropertyStore>, raw_query: &str,) -> (u16, Vec<u8>, String, String) · src/exposed/http.rs:1005

Serve the read-only GET /-/properties door: resolve the coordinate from raw_query (reusing the SBOM coordinate parser), read its property map from props, and return (status, json_body, repository, label). Pure over the store it is given, so the handler and its test share one code path.

• 400 when repo/name/version are not all present.
• 200 + the coordinate's { key: [values] } JSON ({} when none, or when the store is not configured — an unset coordinate has no properties either way).

pub(crate) fn serve_properties_write(props: Option<& crate::properties::SharedPropertyStore>, method: &str, raw_query: &str,) -> (u16, Vec<u8>, String, String) · src/exposed/http.rs:1042

Serve a PUT/POST/DELETE /-/properties WRITE: parse the coordinate + key (+ repeatable value= for a set) from raw_query, apply it to props, and return (status, json_body, repository, label). Pure over the store, so the handler and its test share one code path (the auth gate runs in the handler, before this).

• 400 when repo/name/version/key are not all present.
• DELETE, or PUT/POST with no value=, removes the key.
• PUT/POST with values sets them (last-wins, deduped).
• 200 + the coordinate's resulting { key: [values] } JSON.
• 503 when no property store is configured on this server.

Module holger_server_lib::exposed::tls

Shared TLS material for an exposed endpoint.

One [TlsSettings] (loaded from RON) drives both transports of an endpoint: the gRPC server (tonic) and the HTTP/OCI gateway (hyper + rustls). rustls is already in the dependency tree via reqwest, so this adds no OpenSSL surface — consistent with the airgap posture.

Client-auth semantics differ by transport on purpose:

• gRPC: when client_ca is set, mTLS is required (clients are the agent / CI, which can always present a cert).
• HTTP gateway: client certs are requested but optional, so anonymous pulls and Kubernetes /healthz probes still work; write requests are rejected at the application layer unless a valid identity is present.

struct TlsSettings { cert: String, key: String, client_ca: Option<String> } · src/exposed/tls.rs:24

fn ensure_crypto_provider() · src/exposed/tls.rs:68

Install the ring crypto provider as the process default, once.

Both ring and aws-lc-rs end up in the dependency tree (via reqwest), so rustls cannot pick a default on its own and panics on first use. Pinning ring makes every rustls consumer in-process (our servers, reqwest) deterministic.

fn leaf_common_name(chain: &[CertificateDer<'_>]) -> Option<String> · src/exposed/tls.rs:135

Extract the subject Common Name from the leaf of a DER client-cert chain. Used to map an mTLS peer to an identity for [crate::auth::validate_request].

Module holger_server_lib::exposed::tls::TlsSettings

fn mtls_enabled(&self) -> bool · src/exposed/tls.rs:36

fn rustls_gateway_config(&self) -> Result<Arc<ServerConfig>> · src/exposed/tls.rs:81

Build a rustls ServerConfig for the HTTP/OCI gateway. Client certs are requested but not required when client_ca is set; the app layer enforces identity on writes.

fn tonic_config(&self) -> Result<tonic::transport::ServerTlsConfig> · src/exposed/tls.rs:119

Build a tonic ServerTlsConfig for the gRPC server. When client_ca is set, mTLS is required.

Module holger_server_lib::generated::holger.v1

struct ArtifactId { namespace: ::prost::alloc::string::String, name: ::prost::alloc::string::String, version: ::prost::alloc::string::String } · src/generated/holger.v1.rs:6

struct FetchArtifactRequest { repository: ::prost::alloc::string::String, id: ::core::option::Option<ArtifactId> } · src/generated/holger.v1.rs:16

struct FetchArtifactResponse { data: ::prost::alloc::vec::Vec<u8>, content_type: ::prost::alloc::string::String, size_bytes: i64 } · src/generated/holger.v1.rs:23

struct ArtifactChunk { data: ::prost::bytes::Bytes } · src/generated/holger.v1.rs:32

struct ListArtifactsRequest { repository: ::prost::alloc::string::String, name_filter: ::prost::alloc::string::String, limit: i32, page_token: ::prost::alloc::string::String } · src/generated/holger.v1.rs:37

struct ArtifactEntry { id: ::core::option::Option<ArtifactId>, size_bytes: i64, content_type: ::prost::alloc::string::String } · src/generated/holger.v1.rs:49

struct ListArtifactsResponse { artifacts: ::prost::alloc::vec::Vec<ArtifactEntry>, next_page_token: ::prost::alloc::string::String } · src/generated/holger.v1.rs:58

struct PutArtifactRequest { repository: ::prost::alloc::string::String, id: ::core::option::Option<ArtifactId>, data: ::prost::alloc::vec::Vec<u8> } · src/generated/holger.v1.rs:65

struct PutArtifactResponse { success: bool, message: ::prost::alloc::string::String } · src/generated/holger.v1.rs:74

struct ListArchiveFilesRequest { repository: ::prost::alloc::string::String, prefix: ::prost::alloc::string::String } · src/generated/holger.v1.rs:81

struct ListArchiveFilesResponse { paths: ::prost::alloc::vec::Vec <::prost::alloc::string::String>, total_files: i64 } · src/generated/holger.v1.rs:89

struct ArchiveInfoRequest { repository: ::prost::alloc::string::String } · src/generated/holger.v1.rs:96

struct ArchiveInfoResponse { file_count: i64, total_uncompressed_bytes: i64, archive_path: ::prost::alloc::string::String } · src/generated/holger.v1.rs:101

struct HealthRequest · src/generated/holger.v1.rs:110

struct HealthResponse { status: ::prost::alloc::string::String, version: ::prost::alloc::string::String, uptime_seconds: i64 } · src/generated/holger.v1.rs:112

struct ListRepositoriesRequest · src/generated/holger.v1.rs:122

struct RepositoryInfo { name: ::prost::alloc::string::String, repo_type: ::prost::alloc::string::String, writable: bool, has_archive: bool } · src/generated/holger.v1.rs:124

struct ListRepositoriesResponse { repositories: ::prost::alloc::vec::Vec<RepositoryInfo> } · src/generated/holger.v1.rs:136

struct ServerProfileRequest · src/generated/holger.v1.rs:141

struct PromoteArtifactRequest { from_repo: ::prost::alloc::string::String, to_repo: ::prost::alloc::string::String, artifact: ::core::option::Option<ArtifactId> } · src/generated/holger.v1.rs:143

struct PromoteArtifactResponse { success: bool, message: ::prost::alloc::string::String, content_address: ::prost::alloc::string::String, promoted_by: ::prost::alloc::string::String } · src/generated/holger.v1.rs:154

struct SearchRequest { name: ::prost::alloc::string::String, namespace: ::prost::alloc::string::String, version: ::prost::alloc::string::String, checksum: ::prost::alloc::string::String, path: ::prost::alloc::string::String, repositories: ::prost::alloc::vec::Vec <::prost::alloc::string::String>, limit: i32, properties: ::prost::alloc::vec::Vec<PropertyMatch> } · src/generated/holger.v1.rs:167

struct PropertyMatch { key: ::prost::alloc::string::String, value: ::prost::alloc::string::String } · src/generated/holger.v1.rs:205

One custom-property filter: the artifact must carry key, and — when value is non-empty — that exact value among the key's values (empty value = "the key is present, any value").

struct ArtifactHit { repository: ::prost::alloc::string::String, id: ::core::option::Option<ArtifactId>, size_bytes: i64, content_type: ::prost::alloc::string::String, checksum: ::prost::alloc::string::String } · src/generated/holger.v1.rs:214

One artifact matched by name / coordinate / checksum, tagged with the repo it was found in.

struct PathHit { repository: ::prost::alloc::string::String, path: ::prost::alloc::string::String } · src/generated/holger.v1.rs:230

One raw archive path matched by the path axis, tagged with its repo.

struct SearchResponse { artifacts: ::prost::alloc::vec::Vec<ArtifactHit>, paths: ::prost::alloc::vec::Vec<PathHit>, truncated: bool } · src/generated/holger.v1.rs:237

struct AttachSbomRequest { repository: ::prost::alloc::string::String, artifact: ::core::option::Option<ArtifactId>, document: ::prost::alloc::vec::Vec<u8> } · src/generated/holger.v1.rs:247

struct AttachSbomResponse { success: bool, message: ::prost::alloc::string::String, content_address: ::prost::alloc::string::String } · src/generated/holger.v1.rs:260

struct FetchSbomRequest { repository: ::prost::alloc::string::String, artifact: ::core::option::Option<ArtifactId> } · src/generated/holger.v1.rs:270

struct FetchSbomResponse { document: ::prost::alloc::vec::Vec<u8>, size_bytes: i64, content_address: ::prost::alloc::string::String } · src/generated/holger.v1.rs:277

struct PropertyEntry { key: ::prost::alloc::string::String, values: ::prost::alloc::vec::Vec <::prost::alloc::string::String> } · src/generated/holger.v1.rs:290

One property: a key with its ordered set of values (the map's entry form on the wire, since proto has no first-class ordered multimap here).

struct SetPropertyRequest { repository: ::prost::alloc::string::String, artifact: ::core::option::Option<ArtifactId>, key: ::prost::alloc::string::String, values: ::prost::alloc::vec::Vec <::prost::alloc::string::String> } · src/generated/holger.v1.rs:297

struct SetPropertyResponse { success: bool, message: ::prost::alloc::string::String, properties: ::prost::alloc::vec::Vec<PropertyEntry> } · src/generated/holger.v1.rs:310

struct GetPropertiesRequest { repository: ::prost::alloc::string::String, artifact: ::core::option::Option<ArtifactId> } · src/generated/holger.v1.rs:320

struct GetPropertiesResponse { properties: ::prost::alloc::vec::Vec<PropertyEntry> } · src/generated/holger.v1.rs:327

struct ReplicateRequest { from_repo: ::prost::alloc::string::String, to_repo: ::prost::alloc::string::String, execute: bool, limit: i32 } · src/generated/holger.v1.rs:333

struct ReplicateResponse { examined: i64, copied: i64, skipped: i64, would_copy: i64, failed: i64, copied_bytes: i64, truncated: bool, complete: bool, message: ::prost::alloc::string::String } · src/generated/holger.v1.rs:349

struct WhoAmIRequest · src/generated/holger.v1.rs:378

struct WhoAmIResponse { authenticated: bool, subject: ::prost::alloc::string::String, method: ::prost::alloc::string::String, global_role: ::prost::alloc::string::String, read_gate: bool } · src/generated/holger.v1.rs:380

struct ServerProfileResponse { profile: ::prost::alloc::string::String, read_only: bool, label: ::prost::alloc::string::String, writable_repo_count: i32 } · src/generated/holger.v1.rs:403

Module holger_server_lib::generated::holger.v1::admin_service_client

Generated client implementations.

struct AdminServiceClient · src/generated/holger.v1.rs:771

Health / admin

Module holger_server_lib::generated::holger.v1::admin_service_client::AdminServiceClient

async fn connect<D>(dst: D) -> Result<Self, tonic::transport::Error> where D: TryInto<tonic::transport::Endpoint>, D::Error: Into<StdError>, · src/generated/holger.v1.rs:776

Attempt to create a new client by connecting to a given endpoint.

fn new(inner: T) -> Self · src/generated/holger.v1.rs:792

fn with_origin(inner: T, origin: Uri) -> Self · src/generated/holger.v1.rs:796

fn with_interceptor<F>(inner: T, interceptor: F,) -> AdminServiceClient<InterceptedService<T, F>> where F: tonic::service::Interceptor, T::ResponseBody: Default, T: tonic::codegen::Service<http::Request<tonic::body::Body>, Response = http::Response<<T as tonic::client::GrpcService<tonic::body::Body>>::ResponseBody,>,>,<T as tonic::codegen::Service<http::Request<tonic::body::Body>,>>::Error: Into<StdError> + std::marker::Send + std::marker::Sync, · src/generated/holger.v1.rs:800

fn send_compressed(mut self, encoding: CompressionEncoding) -> Self · src/generated/holger.v1.rs:824

Compress requests with the given encoding.

This requires the server to support it otherwise it might respond with an error.

fn accept_compressed(mut self, encoding: CompressionEncoding) -> Self · src/generated/holger.v1.rs:830

Enable decompressing responses.

fn max_decoding_message_size(mut self, limit: usize) -> Self · src/generated/holger.v1.rs:838

Limits the maximum size of a decoded message.

Default: 4MB

fn max_encoding_message_size(mut self, limit: usize) -> Self · src/generated/holger.v1.rs:846

Limits the maximum size of an encoded message.

Default: usize::MAX

async fn health(&mut self, request: impl tonic::IntoRequest<super::HealthRequest>,) -> std::result::Result<tonic::Response<super::HealthResponse>, tonic::Status> · src/generated/holger.v1.rs:851

Server health check

async fn list_repositories(&mut self, request: impl tonic::IntoRequest<super::ListRepositoriesRequest>,) -> std::result::Result<tonic::Response<super::ListRepositoriesResponse>, tonic::Status,> · src/generated/holger.v1.rs:873

List configured repositories

async fn server_profile(&mut self, request: impl tonic::IntoRequest<super::ServerProfileRequest>,) -> std::result::Result<tonic::Response<super::ServerProfileResponse>, tonic::Status,> · src/generated/holger.v1.rs:900

Report the server's operating profile — static (sealed, read-only, "rigged for silent running") vs dynamic (writable / proxy). Server-reported truth so the operator UI reflects the server, not a local toggle.

async fn who_am_i(&mut self, request: impl tonic::IntoRequest<super::WhoAmIRequest>,) -> std::result::Result<tonic::Response<super::WhoAmIResponse>, tonic::Status> · src/generated/holger.v1.rs:930

Who does the SERVER think the caller is? Resolves the presented credential (Bearer / mTLS CN) through the same validation every gated call uses and reports the resulting identity + effective GLOBAL role — introspection only, no secrets, and NOT an authorization decision: every operation is still checked by its own gate. Anonymous callers get an answer too (the default role), so a UI can explain what "not logged in" means here.

Module holger_server_lib::generated::holger.v1::admin_service_server

Generated server implementations.

trait AdminService · src/generated/holger.v1.rs:2229

Generated trait containing gRPC methods that should be implemented for use with AdminServiceServer.

struct AdminServiceServer · src/generated/holger.v1.rs:2266

Health / admin

const SERVICE_NAME: & str · src/generated/holger.v1.rs:2557

Generated gRPC service name

Module holger_server_lib::generated::holger.v1::admin_service_server::AdminService

async fn health(&self, request: tonic::Request<super::HealthRequest>,) -> std::result::Result<tonic::Response<super::HealthResponse>, tonic::Status> · src/generated/holger.v1.rs:2231

Server health check

async fn list_repositories(&self, request: tonic::Request<super::ListRepositoriesRequest>,) -> std::result::Result<tonic::Response<super::ListRepositoriesResponse>, tonic::Status,> · src/generated/holger.v1.rs:2236

List configured repositories

async fn server_profile(&self, request: tonic::Request<super::ServerProfileRequest>,) -> std::result::Result<tonic::Response<super::ServerProfileResponse>, tonic::Status,> · src/generated/holger.v1.rs:2246

Report the server's operating profile — static (sealed, read-only, "rigged for silent running") vs dynamic (writable / proxy). Server-reported truth so the operator UI reflects the server, not a local toggle.

async fn who_am_i(&self, request: tonic::Request<super::WhoAmIRequest>,) -> std::result::Result<tonic::Response<super::WhoAmIResponse>, tonic::Status> · src/generated/holger.v1.rs:2259

Who does the SERVER think the caller is? Resolves the presented credential (Bearer / mTLS CN) through the same validation every gated call uses and reports the resulting identity + effective GLOBAL role — introspection only, no secrets, and NOT an authorization decision: every operation is still checked by its own gate. Anonymous callers get an answer too (the default role), so a UI can explain what "not logged in" means here.

Module holger_server_lib::generated::holger.v1::admin_service_server::AdminServiceServer

fn new(inner: T) -> Self · src/generated/holger.v1.rs:2274

fn from_arc(inner: Arc<T>) -> Self · src/generated/holger.v1.rs:2277

fn with_interceptor<F>(inner: T, interceptor: F,) -> InterceptedService<Self, F> where F: tonic::service::Interceptor, · src/generated/holger.v1.rs:2286

fn accept_compressed(mut self, encoding: CompressionEncoding) -> Self · src/generated/holger.v1.rs:2297

Enable decompressing requests with the given encoding.

fn send_compressed(mut self, encoding: CompressionEncoding) -> Self · src/generated/holger.v1.rs:2303

Compress responses with the given encoding, if the client supports it.

fn max_decoding_message_size(mut self, limit: usize) -> Self · src/generated/holger.v1.rs:2311

Limits the maximum size of a decoded message.

Default: 4MB

fn max_encoding_message_size(mut self, limit: usize) -> Self · src/generated/holger.v1.rs:2319

Limits the maximum size of an encoded message.

Default: usize::MAX

Module holger_server_lib::generated::holger.v1::archive_service_client

Generated client implementations.

struct ArchiveServiceClient · src/generated/holger.v1.rs:627

Archive service — znippy archive operations

Module holger_server_lib::generated::holger.v1::archive_service_client::ArchiveServiceClient

async fn connect<D>(dst: D) -> Result<Self, tonic::transport::Error> where D: TryInto<tonic::transport::Endpoint>, D::Error: Into<StdError>, · src/generated/holger.v1.rs:632

Attempt to create a new client by connecting to a given endpoint.

fn new(inner: T) -> Self · src/generated/holger.v1.rs:648

fn with_origin(inner: T, origin: Uri) -> Self · src/generated/holger.v1.rs:652

fn with_interceptor<F>(inner: T, interceptor: F,) -> ArchiveServiceClient<InterceptedService<T, F>> where F: tonic::service::Interceptor, T::ResponseBody: Default, T: tonic::codegen::Service<http::Request<tonic::body::Body>, Response = http::Response<<T as tonic::client::GrpcService<tonic::body::Body>>::ResponseBody,>,>,<T as tonic::codegen::Service<http::Request<tonic::body::Body>,>>::Error: Into<StdError> + std::marker::Send + std::marker::Sync, · src/generated/holger.v1.rs:656

fn send_compressed(mut self, encoding: CompressionEncoding) -> Self · src/generated/holger.v1.rs:680

Compress requests with the given encoding.

This requires the server to support it otherwise it might respond with an error.

fn accept_compressed(mut self, encoding: CompressionEncoding) -> Self · src/generated/holger.v1.rs:686

Enable decompressing responses.

fn max_decoding_message_size(mut self, limit: usize) -> Self · src/generated/holger.v1.rs:694

Limits the maximum size of a decoded message.

Default: 4MB

fn max_encoding_message_size(mut self, limit: usize) -> Self · src/generated/holger.v1.rs:702

Limits the maximum size of an encoded message.

Default: usize::MAX

async fn list_archive_files(&mut self, request: impl tonic::IntoRequest<super::ListArchiveFilesRequest>,) -> std::result::Result<tonic::Response<super::ListArchiveFilesResponse>, tonic::Status,> · src/generated/holger.v1.rs:707

List files in a znippy archive backing a repository

async fn archive_info(&mut self, request: impl tonic::IntoRequest<super::ArchiveInfoRequest>,) -> std::result::Result<tonic::Response<super::ArchiveInfoResponse>, tonic::Status,> · src/generated/holger.v1.rs:732

Get archive metadata (file count, total size, compression ratio)

Module holger_server_lib::generated::holger.v1::archive_service_server

Generated server implementations.

trait ArchiveService · src/generated/holger.v1.rs:1991

Generated trait containing gRPC methods that should be implemented for use with ArchiveServiceServer.

struct ArchiveServiceServer · src/generated/holger.v1.rs:2011

Archive service — znippy archive operations

const SERVICE_NAME: & str · src/generated/holger.v1.rs:2212

Generated gRPC service name

Module holger_server_lib::generated::holger.v1::archive_service_server::ArchiveService

async fn list_archive_files(&self, request: tonic::Request<super::ListArchiveFilesRequest>,) -> std::result::Result<tonic::Response<super::ListArchiveFilesResponse>, tonic::Status,> · src/generated/holger.v1.rs:1993

List files in a znippy archive backing a repository

async fn archive_info(&self, request: tonic::Request<super::ArchiveInfoRequest>,) -> std::result::Result<tonic::Response<super::ArchiveInfoResponse>, tonic::Status,> · src/generated/holger.v1.rs:2001

Get archive metadata (file count, total size, compression ratio)

Module holger_server_lib::generated::holger.v1::archive_service_server::ArchiveServiceServer

fn new(inner: T) -> Self · src/generated/holger.v1.rs:2019

fn from_arc(inner: Arc<T>) -> Self · src/generated/holger.v1.rs:2022

fn with_interceptor<F>(inner: T, interceptor: F,) -> InterceptedService<Self, F> where F: tonic::service::Interceptor, · src/generated/holger.v1.rs:2031

fn accept_compressed(mut self, encoding: CompressionEncoding) -> Self · src/generated/holger.v1.rs:2042

Enable decompressing requests with the given encoding.

fn send_compressed(mut self, encoding: CompressionEncoding) -> Self · src/generated/holger.v1.rs:2048

Compress responses with the given encoding, if the client supports it.

fn max_decoding_message_size(mut self, limit: usize) -> Self · src/generated/holger.v1.rs:2056

Limits the maximum size of a decoded message.

Default: 4MB

fn max_encoding_message_size(mut self, limit: usize) -> Self · src/generated/holger.v1.rs:2064

Limits the maximum size of an encoded message.

Default: usize::MAX

Module holger_server_lib::generated::holger.v1::promotion_service_client

Generated client implementations.

struct PromotionServiceClient · src/generated/holger.v1.rs:969

Promotion service — the DEV → PROD transition (.nornir/promotion-design.md). Promotion moves an artifact from a mutable DEV repository into an immutable, content-addressed, sealed PROD store: the promoted artifact is immutable (re-promote refused) and blake3 content-addressed. Admin-gated, fail-closed.

Module holger_server_lib::generated::holger.v1::promotion_service_client::PromotionServiceClient

async fn connect<D>(dst: D) -> Result<Self, tonic::transport::Error> where D: TryInto<tonic::transport::Endpoint>, D::Error: Into<StdError>, · src/generated/holger.v1.rs:974

Attempt to create a new client by connecting to a given endpoint.

fn new(inner: T) -> Self · src/generated/holger.v1.rs:990

fn with_origin(inner: T, origin: Uri) -> Self · src/generated/holger.v1.rs:994

fn with_interceptor<F>(inner: T, interceptor: F,) -> PromotionServiceClient<InterceptedService<T, F>> where F: tonic::service::Interceptor, T::ResponseBody: Default, T: tonic::codegen::Service<http::Request<tonic::body::Body>, Response = http::Response<<T as tonic::client::GrpcService<tonic::body::Body>>::ResponseBody,>,>,<T as tonic::codegen::Service<http::Request<tonic::body::Body>,>>::Error: Into<StdError> + std::marker::Send + std::marker::Sync, · src/generated/holger.v1.rs:998

fn send_compressed(mut self, encoding: CompressionEncoding) -> Self · src/generated/holger.v1.rs:1022

Compress requests with the given encoding.

This requires the server to support it otherwise it might respond with an error.

fn accept_compressed(mut self, encoding: CompressionEncoding) -> Self · src/generated/holger.v1.rs:1028

Enable decompressing responses.

fn max_decoding_message_size(mut self, limit: usize) -> Self · src/generated/holger.v1.rs:1036

Limits the maximum size of a decoded message.

Default: 4MB

fn max_encoding_message_size(mut self, limit: usize) -> Self · src/generated/holger.v1.rs:1044

Limits the maximum size of an encoded message.

Default: usize::MAX

async fn promote_artifact(&mut self, request: impl tonic::IntoRequest<super::PromoteArtifactRequest>,) -> std::result::Result<tonic::Response<super::PromoteArtifactResponse>, tonic::Status,> · src/generated/holger.v1.rs:1049

Promote (seal) one artifact from a DEV repo into an immutable PROD store.

Module holger_server_lib::generated::holger.v1::promotion_service_server

Generated server implementations.

trait PromotionService · src/generated/holger.v1.rs:2574

Generated trait containing gRPC methods that should be implemented for use with PromotionServiceServer.

struct PromotionServiceServer · src/generated/holger.v1.rs:2589

Promotion service — the DEV → PROD transition (.nornir/promotion-design.md). Promotion moves an artifact from a mutable DEV repository into an immutable, content-addressed, sealed PROD store: the promoted artifact is immutable (re-promote refused) and blake3 content-addressed. Admin-gated, fail-closed.

const SERVICE_NAME: & str · src/generated/holger.v1.rs:2745

Generated gRPC service name

Module holger_server_lib::generated::holger.v1::promotion_service_server::PromotionService

async fn promote_artifact(&self, request: tonic::Request<super::PromoteArtifactRequest>,) -> std::result::Result<tonic::Response<super::PromoteArtifactResponse>, tonic::Status,> · src/generated/holger.v1.rs:2576

Promote (seal) one artifact from a DEV repo into an immutable PROD store.

Module holger_server_lib::generated::holger.v1::promotion_service_server::PromotionServiceServer

fn new(inner: T) -> Self · src/generated/holger.v1.rs:2597

fn from_arc(inner: Arc<T>) -> Self · src/generated/holger.v1.rs:2600

fn with_interceptor<F>(inner: T, interceptor: F,) -> InterceptedService<Self, F> where F: tonic::service::Interceptor, · src/generated/holger.v1.rs:2609