966aa10854
DGR-019 Lock alpha/beta performance contracts (evidence + contract framework) DGR-020 Run controlled whole-model GGUF baseline (benchmark results & contracts) DGR-024 Real generated-gRPC protocol harness (shard_runtime_server.py + tests) DGR-026 split-GGUF provisioning outside /home (provision script + manifest + tests) DGR-028 Numbered patch-stack apply & verify (llama_cpp_dependency.py + UPSTREAM_LOCK.json) DGR-029 Native CMake skeleton + deterministic CPU lane (UPSTREAM_LOCK.json + cmake gating) New modules: packages/node/meshnet_node/dgr_performance/ — performance contract framework packages/node/meshnet_node/split_gguf/ — split-GGUF manifest & provisioning scripts/provision_split_gguf.py — artifact provisioning CLI tests/test_dgr_performance_contract.py — contract validation tests tests/test_split_gguf_manifest.py — manifest tests tests/test_split_gguf_provision.py — provisioning tests tests/test_shard_runtime_harness.py — gRPC harness tests
Native Shard protocol
proto/shard_runtime.proto is the semantic contract between a Meshnet node and
a Shard worker: Protocol Buffers over gRPC/HTTP2 (ADR-0020). It is the source of
truth. The Python and C++ types are generated from it; neither is the contract.
What lives here
| Path | Purpose |
|---|---|
proto/shard_runtime.proto |
The schema: capability, health, session stream, release, cancel |
testdata/*.binpb |
Committed conformance vectors both languages assert against |
tests/test_shard_protocol_conformance.cpp |
C++ conformance test |
CMakeLists.txt |
C++ generation, build wiring, and ctest registration |
The Python stubs are generated into
packages/node/meshnet_node/native_protocol/generated/ and are committed, so
installing a node needs no protoc. The C++ stubs are generated into the build
tree and are never committed — a C++ consumer already has a toolchain, and a
committed copy could only rot.
Regenerating
pip install grpcio-tools==1.82.1 # bundles protoc; no system protoc needed
python scripts/generate_native_protocol.py # rewrite the Python stubs
python scripts/generate_native_protocol.py --check # fail if they drifted
python scripts/generate_protocol_goldens.py --check # fail if the vectors drifted
Both --check modes run in CI via tests/test_native_shard_protocol.py, so a
schema edit that is not accompanied by regenerated output fails the suite rather
than shipping stubs that disagree with the schema they claim to implement.
DGR-006 decode and tail compatibility
DecodeStep.bundle is the versioned TensorBundle fast-path boundary. It is
authoritative whenever present and supports architecture sidebands. The original
DecodeStep.tensor remains readable as the compact one-tensor encoding for
certified boundaries that need only one tensor; new readers wrap it into a
one-member bundle. Tail completions use TailResult, which binds logits or a
sampled token to request/recipe identity and sampling/template/reasoning inputs.
Building and running the C++ conformance test
If the machine has no protobuf C++ toolchain:
bash scripts/bootstrap_native_toolchain.sh build/native-toolchain
Then:
cmake -S packages/node/native -B build/native \
-DCMAKE_PREFIX_PATH="$PWD/build/native-toolchain"
cmake --build build/native -j
ctest --test-dir build/native --output-on-failure
The bootstrap pins and builds Protobuf 33.1, gRPC C++ 1.82.1, and the
matching grpc_cpp_plugin into one ignored prefix. CMake requires those exact
package versions and always generates both message and service stubs; it does
not fall back to an arbitrary system plugin.
How the cross-language check actually proves something
Two codecs that each round-trip their own output prove only that each is self-consistent. Instead:
- Python builds the canonical message and commits its bytes to
testdata/. - The C++ test parses those bytes, asserts every field, independently
recomputes the CRC32C from the polynomial, and re-serializes to
cpp_roundtrip.binpbin the build tree. test_cpp_and_python_agree_byte_for_bytecompares that file to the golden.
Byte equality across the two implementations is the claim; anything less is two parallel test suites that can drift apart.