Module drivers 

SRD-109 driver manifests (driver=<name> → adapter + library

• defaults). SRD-109 Part 2 — driver manifests.

A driver manifest gives an SRD-108 implementation library the ergonomics of a built-in adapter: driver=<name> resolves the manifest, which names the backing adapter, the implementation library workload, and default params (lowest precedence). The manifest maps NAMES to templates and defaults — it never defines op fields; the op surface remains exactly the backing adapter’s, so every request stays literal and operator-visible.

# drivers/<name>/driver.yaml
driver: vendorx
adapter: http
library: vector_impl        # sibling workload (stem or file)
description: VendorX REST vector client (native HTTP op forms)
defaults:
  params:
    base_url: "http://localhost:8099"

Discovery is local-first then bundled, mirroring workload resolution: ./drivers/<name>/driver.yaml under the invoking cwd wins; otherwise the bundled catalog entry drivers/<name>/driver. Resolution policy lives with the runner: nearest-first — a name resolving both ways favors the local manifest with a logged warning naming both (shadowing is allowed but never silent).

Structs

DriverManifest

A parsed driver manifest.

Functions

parse_driver_manifest

Parse a driver manifest from its yaml source. Unknown top-level keys and malformed sections are errors — never silently ignored.