documentation revision

docs/issues/01-monorepo-scaffold.md

@@ -1,4 +1,4 @@
-Status: ready-for-agent
+Status: done
 
 # 01 — Monorepo scaffold + single-node smoke test
 

docs/issues/02-two-node-shard-pipeline.md

@@ -1,4 +1,4 @@
-Status: ready-for-agent
+Status: done
 
 # 02 — Two-node shard pipeline
 

docs/issues/03-tracker-registration-and-routing.md

@@ -1,4 +1,4 @@
-Status: ready-for-agent
+Status: done
 
 # 03 — Tracker: node registration + route selection
 

docs/issues/04-node-client-startup.md

@@ -1,4 +1,4 @@
-Status: ready-for-agent
+Status: done
 
 # 04 — Node client startup flow (`meshnet-node start`)
 

docs/issues/05-openai-compatible-gateway.md

@@ -1,4 +1,4 @@
-Status: ready-for-agent
+Status: done
 
 # 05 — OpenAI-compatible gateway
 

docs/issues/08-probationary-period-and-bans.md

@@ -1,4 +1,4 @@
-Status: ready-for-agent
+Status: done (on-chain registry mechanics superseded — probation/ban enforcement uses tracker registry + ADR-0015/0018)
 
 # 08 — Node probationary period + ban enforcement
 

docs/issues/09-p2p-shard-swarm.md

@@ -1,4 +1,4 @@
-Status: ready-for-agent
+Status: done
 
 # 09 — P2P shard swarm
 

docs/issues/10-meshnet-sdk.md

@@ -1,4 +1,4 @@
-Status: ready-for-agent
+Status: done
 
 # 10 — `meshnet` Python SDK
 

docs/issues/19-binary-data-plane-and-peer-weight-transfer.md

@@ -1,8 +1,6 @@
 # US-019 — Binary data plane and optional peer weight transfer
 
-Status: needs-triage
-Priority: Low
-Stage: Design parking lot
+Status: done (design parking lot; binary activation path shipped in US-011/US-019)
 
 ## Context
 

docs/issues/36-relay-streamed-chat.md

@@ -1,8 +1,6 @@
 # US-036 — Streamed chat completions over the relay RPC path
 
-Status: planned
-Priority: Critical (blocks public friends-test deployment)
-Stage: Designed
+Status: done (implemented — `_stream_relayed_frames` in `server.py`; verify on public NAT relay before friends-test)
 
 ## Context
 

docs/issues/42-gguf-llamacpp-node-backend.md

@@ -1,7 +1,7 @@
 # US-042 — GGUF/llama.cpp node backend
 
 Status: planned
-Priority: High (unlocks big MoE models on volunteer hardware — the pool's core value)
+Priority: High (whole-model GGUF shortcut; distributed path in [ADR-0024](../adr/0024-distributed-gguf-runtime.md))
 Stage: Draft design
 
 ## Context

docs/issues/48-memory-budget-shard-slots-and-dropout-relocation.md

@@ -1,6 +1,8 @@
-Status: ready-for-agent
+Status: planned
 
-# US-020 - Memory budget, shard slots, and dropout relocation hardening
+# US-048 — Memory budget, shard slots, and dropout relocation hardening
+
+> Renumbered from duplicate slot `20` (which belongs to tracker-node-hardening / US-020 in `docs/prd.json`).
 
 ## Goal
 
@@ -64,3 +66,4 @@ The current runtime still effectively has one active backend shard per node. A n
 
 - 2026-06-30: Created after implementing the initial registration plumbing in commit `f1e4ed6` (`--memory`, `--max-shards`, tracker validation). This issue captures the remaining end-to-end behavior so it does not conflict with US-013.
 - 2026-06-30: Implementation decision: `max_loaded_shards` is currently a validated and exposed capacity field, but multi-range assignment remains reserved because `TorchNodeServer` serves one active backend shard. The tracker therefore emits at most one active range per node while exposing `vram_bytes`, `ram_bytes`, `max_loaded_shards`, quantization, throughput, and computed `max_assignable_layers` in inspection endpoints.
+- 2026-07-13: Renumbered from `docs/issues/20-memory-budget-…` to resolve duplicate issue slot 20.