System overview

zev is three separately-built, separately-deployed services that communicate over HTTP. ## The client — `zev` A single native binary, written in Zig. Owns a local, on-disk object store under `.zev/`, manages staging and commits entirely offline, and speaks to a remote server only when explicitly asked to (`zev push`, `zev pull`, `zev clone`). Nothing about local commit history requires network access. ## The server — `zev-api` A hand-written HTTP server in Zig, backed by PostgreSQL for metadata (users, repositories, refs, access control) and a content-addressed object store on disk for blob data. Exposes a JSON API covering authentication, repository and object management, chunk-aware synchronization, semantic search, and provenance pinning. Authentication is PAT-based for the CLI, with an initial challenge/response handshake using public-key signatures to establish trust without ever transmitting a private key. ## The CI service — `zev-ci` A separate service that listens for webhook events from `zev-api` and runs pipeline steps in isolated, hardened Docker containers — no network access by default, read-only root filesystem, dropped capabilities, resource limits. A companion tool, `zev-ci-local`, runs the exact same pipeline definition on a developer's own machine, in the same kind of sandbox, so a step that passes locally behaves identically in production CI. ## How they fit together A typical flow: a developer commits locally with `zev` (no network involved), pushes to `zev-api` (objects and chunks synchronized over HTTP), which triggers a webhook to `zev-ci`, which runs the repository's pipeline in a container and reports results back to `zev-api`. Each of these three services was built, and its core claims verified, independently before being connected — the object model was proven correct before chunking was layered on top of it, and chunking was proven correct on its own before the CI memoization layer was built on top of that.