story: DGR-039 Pass local two-process dense acceptance

This commit is contained in:
Dobromir Popov
2026-08-01 01:35:14 +03:00
parent 4c6c78d837
commit 3a67eea569
2 changed files with 145 additions and 0 deletions

View File

@@ -0,0 +1,48 @@
# DGR-039 is blocked: no real dense ranged executor exists
**Date:** 2026-08-01
`DGR-039` remains `passes: false` in the authoritative `prd.json`.
## Verified blocker
The live native worker can load and range-attest a GGUF, and it maintains
per-session llama.cpp KV bookkeeping. It cannot execute a dense model range:
- `LlamaShardEngine::Execute` in
`packages/node/native/worker/llama_shard_engine.cpp` deliberately does not
convert the `TensorBundle` into a llama.cpp/ggml graph, call graph compute,
return a residual, or return tail logits/token IDs. Its only successful
effect is advancing `session.past_len` and the local token reservation.
- `ShardRuntimeServiceImpl::Session` in
`packages/node/native/worker/shard_service.cpp` returns the incoming prefill
bundle verbatim (`*response.mutable_chunk() = chunk`) and builds the decode
response from the same received bundle. It therefore cannot demonstrate
that either range performed prefill/decode, compare whole-model parity, or
greedily generate 32 tokens.
- `tests/test_architecture_boundary.py` proves a pure-Python fixture contract,
while `tests/test_native_shard_worker.py` proves an echo seam. Neither is a
real GGUF execution route. There is also no local coordinator/harness that
drives a whole-model baseline, two range workers, four route sessions,
cancellation/cleanup, process death, and the required metrics collection.
The prerequisite evidence READMEs describe this limitation, but their current
`prd.json` completion flags do not alter the live implementation above.
## Required follow-on before this acceptance can run
1. Bind the DGR-035 dense boundary adapter to a native llama.cpp graph bridge:
head accepts token IDs and emits its real pre-tail residual; tail consumes
that residual and emits real logits/sampled token IDs. Use the exact pinned
API and preserve the `ShardEngine` privacy boundary.
2. Add a real-model-only two-worker harness which opens disjoint ranges against
one exact mounted-drive artifact, records the whole-model baseline and all
raw identity/hardware/metric fields, and does not run by default.
3. Make the harness enforce bounded RPC deadlines and translate a killed
worker to an observed structured failure; test four concurrent sessions,
cancellation, and release without cross-talk.
4. Run it on a host with loopback sockets and an explicitly selected GGUF.
This managed sandbox denies `socket(AF_INET, SOCK_STREAM)` before a worker
starts, so it cannot supply even the fixture process evidence.
No criterion is weakened and no real-model evidence is claimed.

View File

@@ -0,0 +1,97 @@
# DGR-039 evidence — local two-process dense acceptance
**Date:** 2026-08-01
**Status:** blocked; `prd.json` remains authoritative and keeps
`DGR-039.passes` as `false`.
## Result
The requested acceptance run cannot truthfully be executed from the current
source. This is not a missing-model-artifact-only limitation: the live
`LlamaShardEngine::Execute` has no llama.cpp graph/boundary execution and the
gRPC service returns received boundary bytes unchanged. Consequently, two
workers could only prove protocol/KV bookkeeping, not real prefill/decode,
whole-model parity, greedy tokens, or tail output.
See [BLOCKED.md](BLOCKED.md) for the exact live-source blocker and the required
implementation seam.
## Dependency review
- **DGR-036:** its two-process proof is explicitly a `FakeShardEngine` echo
fixture; its real-model lane was blocked pending DGR-037.
- **DGR-037:** it loads and range-attests a GGUF, but its own handoff says the
typed dense-boundary graph bridge remains separate.
- **DGR-038:** it provides bounded per-session llama sequence/KV bookkeeping,
but its own handoff says DGR-039 must supply the real concurrency and metric
run.
The live source confirms those limits: `llama_shard_engine.cpp` increments
`past_len` without computing a graph, and `shard_service.cpp` echoes both
prefill/decode bundles.
## Commands and results
```bash
PYTHONPATH=packages/node /home/popov/.hermes/hermes-agent/venv/bin/python -m pytest -q \
tests/test_architecture_boundary.py tests/test_llama_shard_worker_binding.py \
tests/test_native_shard_protocol.py
```
```text
61 passed, 2 skipped in 0.51s
```
```bash
PYTHONPATH=packages/node /home/popov/.hermes/hermes-agent/venv/bin/python -m compileall -q packages tests
git diff --check
python3 scripts/ralph_prd_schema.py validate .scratch/distributed-gguf-runtime/prd.json
```
```text
OK: 55 stories validated.
```
```bash
/home/popov/.hermes/hermes-agent/venv/bin/python -m cmake --build build/native-dgr037 -j2
/home/popov/.hermes/hermes-agent/venv/bin/ctest --test-dir build/native-dgr037 --output-on-failure
```
```text
shard_worker built successfully.
1/1 shard_protocol_conformance passed.
```
Attempted existing two-worker fixture:
```bash
PYTHONPATH=packages/node:packages/tracker /home/popov/.hermes/hermes-agent/venv/bin/python -m pytest -q \
tests/test_native_shard_worker.py -k two_disjoint_fake_worker_processes_preserve_prefill_and_decode_seam
```
```text
FAILED before worker startup: PermissionError: [Errno 1] Operation not permitted
at socket.socket(AF_INET, SOCK_STREAM).
```
That is the managed sandbox's loopback restriction, not an assertion result.
Even on a socket-permitting host this test uses fake echo workers and does not
meet DGR-039's real-model acceptance criteria.
## Changed files
- `.scratch/distributed-gguf-runtime/evidence/DGR-039/README.md`
- `.scratch/distributed-gguf-runtime/evidence/DGR-039/BLOCKED.md`
- `.ralph-tui/progress.md`
## Limitations and dependency handoff
- No artifact was selected and no raw artifact/split hash, hardware/backend,
TTFT, prefill/decode rate, seam bytes/latency, RSS/VRAM, KV, queue, or
failure metric is claimed.
- No whole-model parity, 32-token greedy decode, four-session isolation,
cancellation/cleanup, or killed-worker structured-failure acceptance is
claimed.
- The next owner must first implement the native dense graph bridge and then
add/run the opt-in coordinator harness on a socket-permitting host. Keep
`DGR-039.passes` false until it has the required real run evidence.