From c68db64270b85024530f2b414767f52b36695f95 Mon Sep 17 00:00:00 2001 From: Meta Vens Date: Tue, 22 Sep 2026 12:32:03 +0200 Subject: [PATCH] Record Q-BP1 ruled A: chunks on the held session, named as Rust's explicit path Co-Authored-By: Claude Opus 5 --- notes/eureka-body-plane-cut.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/notes/eureka-body-plane-cut.md b/notes/eureka-body-plane-cut.md index bf9b34e5..f5bef510 100644 --- a/notes/eureka-body-plane-cut.md +++ b/notes/eureka-body-plane-cut.md @@ -771,7 +771,17 @@ Two real forks. Every other choice above (the content plane over the body plane per F2, the reference's manifest, the ephemeral store, the constants, the order) is a default with its reason stated. It is recorded, not asked. -**Q-BP1. Which physical path carries the body?** +**Q-BP1: RULED A by the operator, 2026-09-22 ("A is fine here").** +- Chunk requests and responses travel on the session the client already + holds, byte-identical on the wire to the reference's + `CultMeshLegacyRudpContentServer`. +- BP-1 amends `transport-planes.md` to name this as Rust's *explicit* content + path, never an implicit default. +- It lasts until Rust has an authenticated content connector, TCP+TLS or + QUIC. That later move sits behind the same `fetch_content` owner and needs + no change to the reference type. + +*History, the question as asked:* **Q-BP1. Which physical path carries the body?** CultMesh's own transport doctrine says "Schema messages must not carry bulk bodies" and that the RUDP content path is legacy, "compatibility and parity