feat(syva-core): become a syva-cp client

AGENT.md

@@ -21,6 +21,28 @@ copied to any other operation.
 
 ---
 
+## syva-core CP Mode vs Legacy Mode
+
+`syva-core` supports two zone ingestion paths that share the same in-process
+`ZoneRegistry` and `EnforceEbpf`:
+
+1. Local gRPC surface. Adapters push zones to `syva-core` directly. This is
+   the v0.2 architecture and remains the default.
+2. CP mode (`--cp-endpoint`). `syva-core` connects to a remote `syva-cp`,
+   registers as a node, and consumes assignments via server-streaming. The
+   reconcile loop lives in `syva-core/src/cp_reconcile/`.
+
+Both paths call the same in-process mutation helpers. CP mode is additive, not
+a replacement yet. Session 4b will migrate adapters to push to `syva-cp`
+instead of `syva-core`.
+
+The reconciler keeps in-memory state only (`AppliedState`). On restart, a fresh
+subscription receives a `FULL_SNAPSHOT` from `syva-cp` and reconstructs desired
+state. The only local persistence in CP mode is the `node-id` file used for
+re-registration.
+
+---
+
 ## Mental Model: How to Think About This Codebase
 
 Syvä is a kernel enforcement boundary. Every line of eBPF code runs in a

Cargo.toml

@@ -2,6 +2,7 @@
 resolver = "2"
 members = [
     "syva-proto",
+    "syva-cp-client",
     "syva-core",
     "syva-cp",
     "syva-adapter-file",

syva-core/Cargo.toml

@@ -9,6 +9,7 @@ path = "src/main.rs"
 
 [dependencies]
 syva-proto = { path = "../syva-proto" }
+syva-cp-client = { path = "../syva-cp-client" }
 syva-ebpf-common = { path = "../syva-ebpf-common", features = ["userspace"] }
 aya = { workspace = true }
 tonic = { workspace = true }
@@ -24,3 +25,4 @@ serde_json = { workspace = true }
 clap = { workspace = true }
 libc = "0.2"
 prost = { workspace = true }
+uuid = { version = "1", features = ["v4", "serde"] }

syva-core/README.md

@@ -0,0 +1,40 @@
+# syva-core
+
+Kernel enforcement engine for Syva. `syva-core` owns the in-process
+`ZoneRegistry` and `EnforceEbpf` state and exposes a local gRPC surface for
+adapters.
+
+## Operational Modes
+
+`syva-core` runs in one of two modes:
+
+### Legacy Mode
+
+Adapters (`syva-adapter-file`, `syva-adapter-k8s`, `syva-adapter-api`) connect
+to the local gRPC surface and push zones directly.
+
+Start:
+
+```bash
+syva-core --socket-path /run/syva/syva-core.sock
+```
+
+### CP Mode
+
+`syva-core` connects to a remote `syva-cp`, registers as a node, subscribes to
+assignment updates, and reconciles its BPF maps to match desired state. Legacy
+adapters can still push to the local gRPC surface in addition.
+
+Start:
+
+```bash
+syva-core \
+    --cp-endpoint http://syva-cp.cluster.local:50051 \
+    --node-name "$(hostname)" \
+    --node-labels "tier=prod,region=eu" \
+    --fingerprint-path /etc/machine-id \
+    --node-id-path /var/lib/syva/node-id
+```
+
+The node ID is persisted to `--node-id-path` so restarts appear as
+re-registration of the same node rather than fresh registration.