sn-fetch PoC: range probe, weighted planner, parallel segments, reassembly + sha256

documentation/ideen/roadmap.md

@@ -15,10 +15,13 @@ endet mit etwas, das man benutzen kann.
 
 Ziel: Beweis, dass Pooling über zwei Anschlüsse real funktioniert.
 
+- [x] `sn-fetch` PoC (lokal): Range-Probe, gewichteter Planner, parallele
+      Segment-Downloads, Reassembly + SHA-256 — verifiziert gegen einen
+      echten Server (Debian-Mirror); Multi-Exit-Routing folgt mit dem Mesh
 - [ ] SpiderNet-Node auf Mini-PC (Raspberry Pi / N100-Box), Yggdrasil-Overlay
       zwischen 2 Haushalten (Kabel oder Kurzstrecke WLAN/60-GHz)
-- [ ] `sn-fetch` PoC: segmentierter Download (HTTP-Range-Splitting) über
-      2 Exits, plus Baseline-Messung (1-Exit vs. 2-Exit, gleiche Datei)
+- [ ] `sn-fetch` PoC über 2 echte Exits, plus Baseline-Messung
+      (1-Exit vs. 2-Exit, gleiche Datei)
 - [ ] Fair-Share-Scheduler v0: zwei gleichzeitige Downloads, faire Aufteilung
 - [ ] Doku: Messwerte, Erkenntnisse, Stolpersteine → hier in das Repo
 

documentation/ideen/splitting.md

@@ -55,8 +55,10 @@ die Verbindung kaputt machen würde (IP-Wechsel beendet die Session):
 | VPNs (WireGuard etc.) | UDP-Flow mit State |
 
 **Policy-Vorschlag (Default):** realzeitkritischer Traffic geht in den
-**Direct-Modus** — ohne Umweg, normal über den eigenen Router/Uplink, als
-wäre SpiderNet nicht da. Optional "best single exit" (wenn die eigene
+**Direct-Modus** — und zwar als echter **Pass-Through**: SpiderNet gibt
+diese Verbindungen unverändert weiter, sie nehmen den normalen Weg durch
+den eigenen Router und den eigenen Uplink, als wäre SpiderNet nicht da
+(kein Tunnel, kein MITM). Optional "best single exit" (wenn die eigene
 Leitung gestört/überlastet ist, kann man den Call bewusst über einen
 Nachbarschafts-Exit pinnen — aber dann sticky für die Dauer der Session).