nordisk/holger

04 — Code structure: traits and WASM plugins

Stinky lane 4, 2026-09-20, against main = 542e296. Sibling sections: 01 dataplane, 02 twin, 03, 05.

The owner's brief: "kodstrukturen på holger — den skall vara trait-baserad, och det finns wasm plugins." So the question this section answers is not "is the code nice". It is: where are holger's seams, are they traits, and can a third party extend holger without forking it?

Every claim is tagged. MEASURED = a number or a line produced by a command over the tree at 542e296 (the command is quoted where it is not obvious). READ = what the source or a commit says about itself. DESIGNED = my proposal; nothing under DESIGNED exists in the tree.

The constraint that shapes every recommendation: holger ships as an appliance with no OS and no shell, and "MVP is holger SLIMMED DOWN" — it is the only product with two suites (MVP 7 rows, ORIGINAL 6, MEASURED in .nornir/build-variants.toml). A refactor that adds surface to the MVP binary is a bad recommendation unless it removes more than it adds. Section 9 files every proposal under MVP or Pro.

1. The seam inventory

One row per place where holger could be extended. "Trait" means an object-safe or generic trait a second party could implement; "shape" means N copies of one struct/enum layout with a match.

MEASURED: 23 trait definitions in the tree outside generated code (grep -rn 'pub trait'); 8 of them are tonic-generated service traits in generated/holger.v1.rs, 15 are holger's own.

The short reading. holger has one first-class seam — the repository backend — and it is a good trait. Everything that varies per deployment (storage, gates, metering) is either a stub, an env-var struct, or absent. The wasm host is the one door open to a third party and no tier opens it.

2. Findings per seam

2.1 The backend trait is a seam; the wiring around it is not

READ: RepositoryBackendTrait (traits/src/lib.rs:323-463) demands name, format, is_writable, fetch, put, handle_http2_request; six more have safe defaults (archive_*, list, delete_artifact fails closed, coordinate_for_path + maps_paths_to_coordinates default to "cannot tell", which the quarantine gate refuses to boot over). That is a well-judged contract.

MEASURED: server/lib/src/repository.rs:281-520 is a match self.ron_repo_type.as_str() with 20 string arms (rust, rust-remote, nexus-remote|artifactory-remote|azure-remote|aws-remote, pip, npm, nuget, go, gem, deb, rpm, helm, docker, oci, raw, conda, composer, group, znippy-build-thing, znippy), and server/lib/Cargo.toml:42-77 names all 17 repository crates as unconditional path deps. ArtifactFormat/RepositoryType in traits are closed enums with their own as_str matches.

Consequence: adding a format = a new crate + a Cargo dep + a match arm + an enum variant + (for upstreams) a upstream_path arm. Five edits in three crates, all in the core. The ABI crate's own rustdoc admits it (plugin/abi/src/lib.rs:7-10: "the sixteen repository backends are unconditional path dependencies … adding a package handler meant editing server/lib/Cargo.toml and rebuilding").

DESIGNED (Pro; MVP-neutral): the ron_handler path already IS the answer — backend_from_config_with tries the catalog first (repository.rs:251-258) and only then falls into the match. Move the 17 built-ins into HandlerCatalog::register_linked (they would each implement PackageHandler over a BlobStore, exactly as skidbladnir/rust-toolchain do), and the match shrinks to the three shapes that are not handlers: group, raw, and the remote upstreams. Then a format is one crate that registers itself, and the MVP could drop the formats it does not ship (today holger-mvp links all 17 — the MVP row's "znippy only, no package plugins" claim in SUITES.md is about the archive client, not the server). That is a refactor that removes from MVP.

2.2 Storage is a stub, and every backend re-implements the bytes

READ: storage/mod.rs is 36 lines; backend_from_config returns Ok(()). Each znippy-backed repo opens its own archive; each file-backed repo owns its own dir; DirStore in plugin/host/src/store.rs is a third filesystem-bytes implementation (the BlobStore one). MEASURED: impl BlobStore has 3 impls (DirStore, HostStore guest shim, ProbeStore), and none of the 17 format crates use it.

The house has the storage engine: znippy (O(1) arrow-IPC archives, the law's "reuse the nordisk repos"). A BlobStore over a znippy archive (read) + a writable-archive BlobStore would let every handler run over the appliance's real store. Today a wasm handler can only ever write loose files under <data_root>/<stem>, which on a no-shell appliance is a directory nobody can inspect or seal.

DESIGNED (Pro first, MVP later): one BlobStore impl over znippy (read) and one over the writable-archive path RustRepoZnippy::with_writable_archive already uses. Delete StorageEndpoint or make it the thing that constructs those two. No new trait — BlobStore exists.

2.3 Auth: the edda seam is right, holger's enum is the cost

READ: edda's AuthProvider (bearer / client-cert / SAML verbs, "not mine" vs authoritative reject) is the correct shape and holger consumes it. holger's AuthMethodConfig enum + provider_pinned (auth.rs:46) + the kind() match (auth.rs:81) + 18 cfg(feature = "auth-oidc") sites (§6) are the price of pinning providers per tier. For MVP (bearer + mTLS + passkey) this is fine; it is closed on purpose so an airgap build links no IdP client. No change recommended.

2.4 Replication needs no trait

READ: replicate_pairs(&[RepoPair], &ReplicationOptions) is pure over two Arc<dyn Backend>. A "peer" is just a backend that happens to be remote. This is the model the rest of holger should copy: the seam is the backend trait; features compose over it.

2.5 Audit is the model seam

READ: AuditLog — two verbs, three impls, chosen by config, Critical profile refuses to boot without a writable sink (lib.rs:654-696 tests). Nothing to fix. Note for §4: a plugin cannot write to it.

3. The gate seam — what gunnar has and holger does not

3.1 gunnar's Gate, read properly

READ, /home/rickard/git/gunnar/crates/gunnar-policy/src/lib.rs:173:

pub trait Gate: Send + Sync {
    fn name(&self) -> &str;
    fn check(&self, ctx: &PushContext<'_>) -> Result<Verdict>;
}

Five properties, each load-bearing:

1. Live on the hot path. It runs between the pack landing and the refs moving (pre-receive). It cannot write and cannot decide half a push (rustdoc :168-171).
2. Bytes are a required constructor argument. PushContext (context.rs:266) carries principal, repo, updates: &[RefUpdate], new_objects: &[ObjectId], push_options. A gate sees the objects, not a name.
3. Whole-set judgement. PolicyEngine::evaluate runs every gate, even after one refuses, and returns a Decision { rejections: Vec<GateRejection> } with undecided: bool per rejection — "your push violates a rule" and "gunnar is broken" are distinguishable to the operator (:245-260).
4. Gates are declared in config. PolicyEngine::from_config(&PolicyConfig) → config.gates() builds Vec<Box<dyn Gate>>; gate_names() is exposed as Policy.ListGates because "a repository whose protection rules failed to load would look exactly like one that has none".
5. GUN-007: an unreadable policy REFUSES EVERYTHING. transport.rs:2570-2620: Err from load_policy is a refusal of every reference, never PolicyConfig::default(). Until 2026-09-11 a typo silently switched branch protection off; the fix is a test (gunnar-cli/tests/policy_fails_closed.rs) that also proves a clone of the same repo still works, so the refusal costs pushes and nothing else.

Err from a gate = undecided = refused. Ok(Verdict::Allow) is the only way through.

3.2 holger's equivalent today

READ, server/lib/src/promote/mod.rs:

• PolicyGate { scanner: OsvScanner, enforcement } (:66) — one concrete scanner, not a trait.
• Built by PolicyGate::from_env() (:88) from three environment variables; unset ⇒ Ok(None) ⇒ gate_check returns Ok(()) (:522-525, "unconfigured ⇒ unconditional"). On an appliance with no shell, "env var" is a config surface nobody can reach, and None is silent pass-through.
• evaluate(ecosystem, id) (:122) calls security::artifact_from_coords(ecosystem, name, version, false) — the coordinate-only seam. fa9f5e6 measured what that does: modgunn's Verdict::cache_key() is (blob_sha256, policy_version, advisory_db_rev) and holger passed blob_sha256: String::new(), so every artifact in a promotion collapses onto ("", policy, db). The digest-carrying seam artifact_from_coords_with_digest now exists (security.rs:227) — but PolicyGate::evaluate still calls the coordinate-only one (MEASURED: promote/mod.rs:123). The fix landed one layer down and the gate does not use it.
• Per-artifact only. gate_check_hop runs per rung (:470); there is no "the promoted set as a whole" call, which SUITES.md §"MVP gains the chain" explicitly requires ("analyses per package AND over the promoted set as a whole").
• Not declared in config: Stage::gated is a bool, not a list of gate names.
• No GUN-007. An unreadable advisory DB is an Err at boot (good, :101), but no configured gate is Ok(None), and there is no way to say "this rung must be gated" and have the absence of a working gate refuse the hop.

The attest plane (attest.rs) already does the right thing on its side: digest-keyed, many attestations per digest, -3 refuses a statement whose subject names different bytes. So the evidence store is gate-ready; the gate is not evidence-ready.

3.3 What holger's gate should look like

DESIGNED (MVP — SUITES.md rules the promote→attest→sync→verify chain into MVP, so this is MVP surface that replaces the env-var struct rather than adding beside it):

// server/lib/src/promote/gate.rs — or edda if gunnar's Verdict/Decision shapes are reused, which they should be
pub struct PromotionContext<'a> {
    pub principal: &'a AuthIdentity,
    pub hop: &'a Hop,                        // from-rung, to-rung, ladder name
    pub set: &'a [PromotedArtifact<'a>],     // EVERY member of this promotion
}
pub struct PromotedArtifact<'a> {
    pub id: &'a ArtifactId,
    pub ecosystem: &'a str,
    pub digest: ArtifactDigest,              // attest.rs's type — REQUIRED, not Option
    pub bytes: &'a [u8],                     // or a reader; the point is the gate CAN see them
    pub attestations: &'a [Statement],       // what the evidence plane already holds for this digest
}
pub trait Gate: Send + Sync {
    fn name(&self) -> &str;
    /// Err = undecided = refused. Judges the SET; a per-artifact gate iterates inside.
    fn check(&self, ctx: &PromotionContext<'_>) -> anyhow::Result<Verdict>;
}

• Stage { gates: Vec<String> } in the RON ladder replaces gated: bool. A rung naming a gate this build does not carry is a boot error (the same rule ron_handler already applies for handlers: "an unknown name is a boot error … lists what is accepted").
• PolicyGate::from_env is deleted; the OSV scanner becomes impl Gate for OsvGate built from the RON promotion block (which 6de216f already made reach the engine).
• HOL-GUN-007: a rung whose gate list cannot be resolved, or whose gate returns Err, refuses the hop. The hop is the pre-receive equivalent — refusing it costs promotions and nothing else; reads, fetches, serving are untouched. Test it the way gunnar does: the same fixture, gate config broken, hop refused, fetch still works.
• Emit ONE summary attestation per promotion from Decision (the set-scope DSSE statement attest.rs already files under every member — a_set_scope_statement_is_keyable_from_every_member).

Cost to MVP: - env-var parsing, - Option<PolicyGate>; + one trait, one struct, one Vec<String> in config. Net smaller and no new deps. Verdict/Decision/GateRejection should be lifted from gunnar-policy into edda rather than copied (reuse law); gunnar-policy is an "S" crate (no OS, no fs) so it is already appliance-shaped.

4. The wasm plugin host: the host-guest contract

4.1 What is there (READ, b594965, 2552ceb)

• Host: wasmtime 48.0.2, Engine/Module/Store/Linker/Caller/Memory/Val only, no WASI linked (2552ceb). Fuel 1_000_000_000, memory 256 MiB, tables 100 000, 30 s epoch deadline, all PluginLimits fields refuse 0 (limits.rs:51-94). Module verified (detached CMS over blake3, via znippy_common::sign) before Module::from_binary; from_file rejected because it also accepts WAT (b594965). Refusals named holger-plugin-1..9. A failed verification is a boot error; a failed load is a RejectedModule beside working ones.
• Guest ABI (plugin/abi/src/lib.rs): 8 exports (alloc, result_len, plugin_manifest, plugin_fetch, plugin_put, plugin_list, plugin_coordinate_for_path, plugin_http); 4 imports from env (host_store_get/put/list/size), packed u64 returns, length-prefixed codec, never JSON.
• ABI_VERSION: u32 = 1 in the manifest; host refuses a mismatch by name (wasm.rs:156-165).
• Agreement harness (agreement.rs): every -wasm crate must prove native == wasm over real bytes, never skips, and refuses a stale .wasm.
• MEASURED: wasm-plugins appears in no variant's feature list (grep wasm-plugins .nornir/build-variants.toml = 0 hits) and server/lib/Cargo.toml says "OFF in every tier, including full". With it off, ron_plugin_dir set is ScanError::NoWasmHost (loud, good).

This is a well-built, well-bounded host. It is also, today, a host for exactly one kind of guest.

4.2 What a plugin can DO (the capability audit)

The guest sees: its own key-value blob store, keyed by strings it chooses, rooted where Mounts says. That is the entire world. It cannot:

So the capability model is: one implicit capability (own blob store), unannounced, ungrantable. There is no requires: [...] in the manifest and no per-import gating in register_host_functions (wasm.rs:483, all four func_wraps unconditional). That is fine while the only guest kind is a format handler; it means the next guest kind cannot be written without changing the host and the ABI version and every existing module's agreement test.

4.3 Versioning and what happens when the host changes

READ: ABI_VERSION is one u32; a mismatch is refused. There is no range (a host that speaks 1 and 2), no per-verb versioning, no feature-negotiation. Consequence: the first ABI bump orphans every signed .wasm in the field until the operator gets a re-signed module. On an airgap appliance that is a bundle import per plugin per host upgrade. Acceptable for v1; must not stay a single integer once a third party ships anything. WireManifest::decode also has no trailing-field tolerance — a v2 manifest with one more field fails expect_end("Manifest") even if the host is v2-capable, so the manifest itself cannot be the negotiation channel as written.

4.4 The first three real plugins, and whether ABI v1 carries them

1. monetize meter reader (the owner's named one). READ, monetize products/holger/src/lib.rs:195-220: four meters — artifacts, artifact_bytes, archive_bytes, archive_files — and today the product answers Unavailable("holger: not wired") (:8). On feat/metering-doors (f6ff7ec, not on main) holger grows UsageService.ReadUsage + Entitlement.Set as gRPC services plus an in-process metering.rs. So the metering plane, when it lands, is a door for an external client, not a plugin point. Can ABI v1 host it? No. A wasm guest has no read of any repository's listing, archive info, or counters, no clock, and no way to export a reading. It lacks: (a) a host_usage_read import or, better, a second guest kind MeterSource with an export plugin_meters() -> Vec<(name, value, scope)>; (b) read access to the Holger roster; (c) a way to be called periodically rather than per HTTP request. The honest answer is that monetize does not want a plugin here — it wants the gRPC door f6ff7ec already wrote, and the plugin lives on monetize's side (it already does: products/holger). A holger-side "plugin for monetize" is only needed for enforcement (refuse a put over cap), and that is a gate — which needs the §3 trait, not the wasm ABI. Verdict: land f6ff7ec's doors (MVP-metered atom, already declared as a separate variant), don't build a metering plugin ABI.
2. A gate plugin (OSV/licence/custom policy as .wasm). Needs the §3 Gate trait first, then a guest kind plugin_check(PromotionContext) -> Verdict, which needs bytes or digest + attestations in — none of which the v1 wire types carry (WireArtifactId has no digest field). Not carriable.
3. A third format handler (e.g. conda-as-plugin, or a customer's in-house bundle format). This ABI v1 carries it today — it is exactly what it was built for, and the agreement harness proves native==wasm. The only blockers are (a) wasm-plugins off everywhere, (b) the guest's store is a loose directory, not the appliance's znippy store (§2.2), (c) no #[cfg]-free way to ship the host without cranelift: MEASURED wasmtime + cranelift in a musl appliance is the size argument the Cargo.toml note makes, and it is real.

Plugin ABI verdict: v1 is a correct, bounded, signed format-handler ABI with zero capability model and single-integer versioning, shipped in no build. It can carry plugin #3 today and neither #1 nor #2. A plugin system nobody can write a plugin for is not a finding yet — a third format handler could be written this afternoon — but a plugin system that cannot grow a second guest kind without an ABI break is.

DESIGNED (Pro): (a) WireManifest { …, requires: Vec<String> } and the host registers only the imports a module names, refusing unknown ones by name (holger-plugin-10); (b) a guest kind in the manifest (handler today; gate and meter-source later), each kind = its own export set; (c) ABI_VERSION → abi_min..=abi_max on the host; (d) a host_audit_record import so a refusal inside a module reaches the append-only log. None of this is MVP: MVP's wasm-plugins stays off, and the MVP's extension story is linked handlers registered in builtin_catalog().

5. Trait discipline

5.1 dyn vs generics — MEASURED

server/lib/src + plugin + traits, generated code excluded: Arc<dyn 108, Box<dyn 8, &dyn 23, impl Trait in argument position 0. Of the 108 Arc<dyn, 80 are RepositoryBackendTrait, 14 AuditLog, 3 FulfilmentApi, 4 AdvertisedDigest, 1 HolgerObject.

Verdict: the dyn is where it belongs. Backends are heterogeneous per repository and chosen at boot from config; a route table of Arc<dyn Backend> is the right shape and a generic FastRoutes<B> would be wrong. HandlerBackend boxes dyn HandlerRuntime (backend.rs:98) — also right, that is the whole point of the linked/loaded erasure. The one place generics are used is LinkedHandler<H: PackageHandler> — right again, monomorphised per linked handler and erased once at into_runtime.

No dyn-where-generic-belongs found. No generic-where-dyn-belongs found. The trait-object hot path (handle_http2_request per request through a vtable) is one indirect call per request; not a performance concern next to the bytes.

5.2 Traits with one implementation

MEASURED: Mounts (1), AdvertisedDigest (1 prod), PropertyLookup (0 prod, 1 mock — search.rs:95), PypiIndex (1), BundleKind (2), FulfilmentApi (1 + fake). PropertyLookup exists only so search tests can mock the property store; that is a test seam wearing a pub trait. Harmless, but it is not "trait-based" in the owner's sense — nobody plugs a property lookup.

5.3 The god-object: GatewaySettings

READ exposed/http.rs:92-155: 13 fields — routes, auth, TLS, body cap, audit, operation mode, security profile, sboms, properties, passkeys (cfg), quarantine, reserved properties, promotion property, marketplace. It is built once in Holger::start_grpc_endpoint and read in handle. MEASURED: it is named in exactly 2 files (lib.rs, http.rs). So it is not threaded everywhere — it is a constructor bag for one 1 000-line function. The smell is not the struct; it is that handle is the only consumer, because handle does everything (§7).

5.4 cfg(feature) doing architectural work

See §6. The pattern to name: auth.rs:46-52 provider_pinned is a match over the enum returning cfg!(feature = …) per arm — five features answering one question that the edda AuthProvider list already answers at runtime (is there a provider with this name?). That is a cfg standing in for "ask the registry". It is load-bearing for the boot warning warn_unpinned_providers, and correct, but it is the shape a sixth method has to copy.

6. #[cfg(feature …)] census — server/lib/src

MEASURED: 78 sites, 7 distinct features:

Legitimate whole-subsystem absences: front, federation, online, auth-passkey, the prod auth-oidc sites. Missing abstraction: none of the 78 — the auth enum (§5.4) is the closest, and it is a deliberate ship-small choice. What is NOT gated and should be: pub mod marketplace (lib.rs:68) — 2 371 + 5 files of cloud-marketplace fulfilment (Microsoft landing/webhook/Entra sign-in, tenant ledger, provisioning) compiled into holger-mvp on the airgap ISO with no feature at all. Only its HTTP client is behind online; the doors, the state machine and getrandom are in every build.

The two accidents, both MEASURED and both fixed by naming the feature on the row:

• 6f02ddf: front leaked into --no-default-features --features mini,bench because bench-scenarios asked for server-lib's defaults and cargo unifies per graph.
• server/cli/Cargo.toml:150-160 (2026-09-20): auth-passkey reached the plain holger-server only through the bench edge; drop bench and the login door vanished.

Reading: cfg is doing load-bearing work it can do, but the guard is a cargo tree measurement (holger-recipe/src/rules.rs), not the type system. That is the correct guard for "is an HTTP client linked"; it is the wrong guard for "is the marketplace in the appliance", which should simply be a feature that MVP does not name.

DESIGNED (MVP, removes surface): marketplace = ["dep:…"] feature, on for full/server-local rows, off for every MVP row; pub mod marketplace and GatewaySettings.marketplace behind it, same shape as front. This is the one cfg addition in this document, and it takes ~2 400 lines out of the MVP.

7. Size and shape

MEASURED (wc -l over src/ per crate, tests included):

Biggest files (prod lines = up to the first #[cfg(test)]):

Module depth: max 4 (server/lib/src/exposed/http.rs). No deep nesting; the problem is width, not depth.

7.1 What should come out of http.rs, and what the seam is

READ: the route dispatch in handle is a sequence of if path == "/-/…" blocks (MEASURED via grep at :167, 278, 281, 295, 431, 482, 529, 587-669). Each block re-does: parse query, run the read/write gate, call a store off GatewaySettings, shape a JSON/text response. The seam that already exists and is not used here is the same one the marketplace module did use for itself: marketplace/door.rs has Door::{Landing, Webhook} and http.rs:618 dispatches to it.

DESIGNED (MVP-neutral to MVP-negative; pure motion of code, no new deps):

/// A meta door under `/-/`. Sees the already-authenticated identity and the settings; never a backend.
pub(crate) trait MetaDoor: Send + Sync {
    fn prefix(&self) -> &'static str;                        // "/-/search", "/-/auth/passkey", …
    fn serve(&self, req: &MetaRequest<'_>, s: &GatewaySettings) -> Response<Full<Bytes>>;
}

with one impl per file: doors/search.rs, doors/sbom.rs, doors/properties.rs, doors/passkey.rs (cfg(auth-passkey)), doors/front.rs (cfg(front)), doors/marketplace.rs (cfg(marketplace)), doors/metrics.rs. handle() becomes: accept → authenticate → is it a meta door? dispatch → else repository route. GatewaySettings shrinks to routes, auth, tls, audit, mode, profile + a Vec<Box<dyn MetaDoor>> built in lib.rs from whichever stores are configured — the Option<Store> fields (sboms, properties, passkeys, marketplace) move into the door that owns them, so "None ⇒ 404" becomes "door not mounted ⇒ falls through", which is what front already does. The read gate (gate_meta_read, :388) and the write floor (authorize_http_write, :1811) stay in http.rs, run before dispatch, once. the_reserved_meta_namespace_never_routes_into_a_repository (:2762) is the test that must stay green through the move.

The accept loop / backoff / TLS deadline (:157-352) is a second job and goes to exposed/accept.rs; it has its own three tests already (:3285-3384).

Everything else in the table is one job per file and is merely long; grpc/services.rs could be one file per service to match the proto, but nothing forces it.

8. The five worst findings

1. The gate is not a seam — PolicyGate is one struct over one scanner, configured from environment variables on a box with no shell, Ok(None) when unset, per-artifact by name, and still calling the coordinate-only seam that fa9f5e6 measured collapsing every artifact onto one cache key (promote/mod.rs:66, 88, 123, 522). gunnar's Gate + GUN-007 is the model; §3.3 is the shape. MVP (SUITES.md rules the chain in).
2. wasm-plugins is off in every tier and the ABI cannot grow a second guest kind — v1 is a correct format-handler ABI with no capability field, four unconditional imports and a single-integer version (wire.rs:15, wasm.rs:483). The owner's named plugin (monetize) needs a door, which f6ff7ec wrote and is not on main, and enforcement, which is a gate (#1). Pro for the ABI; MVP-metered for landing f6ff7ec.
3. The marketplace is compiled into the airgap appliance — pub mod marketplace has no feature; ~2 400 lines of Microsoft fulfilment + tenant provisioning + getrandom ride in holger-mvp on the ISO (lib.rs:68, §6). One cfg, shaped like front, removes it. MVP.
4. Storage is a stub and every backend owns its own bytes — StorageEndpoint::backend_from_config is Ok(()) (storage/mod.rs:31); the wasm BlobStore is a loose directory; none of the 17 format crates share a store, and the house's storage engine (znippy) is opened 17 different ways. A BlobStore over znippy is the missing piece that makes the plugin lane run over the real store. Pro.
5. http.rs::handle is 1 018 lines doing eleven doors' worth of parse-gate-serve — the seam (MetaDoor) already exists in spirit as marketplace::Door; every Option<Store> field of GatewaySettings is a door that should own its own None ⇒ 404. Pure motion, tests exist. MVP (neutral to negative on surface; it makes the cfg(front)/cfg(marketplace) cut a file boundary instead of an if).

Honourable mention: the backend match in repository.rs:281 with 17 unconditional format deps — the ABI crate's own rustdoc calls this out, and the fix (§2.1) is to register the built-ins through the catalog the plugin lane already built. Pro, but it is what would let MVP stop linking formats it does not ship.

9. MVP or Pro — every proposal in this document

What is not proposed: any new runtime dependency; any generic-ification of the route table; a storage trait (one exists — BlobStore); a metering plugin ABI (monetize wants a door, and has one on a branch).