Clarify future SDK repository boundary

Author: eldryoth

ROADMAP.md

@@ -150,6 +150,13 @@ placeholder crates; if names are claimed on crates.io, they should contain real
 project-owned packages with clear README text pointing to the correct binary
 and SDK roles.
 
+Keep the SDK code in a clearly split directory from the proxy implementation,
+for example `crates/fluxheim-sdk/`, with its own `Cargo.toml`, README, tests,
+and public API boundary. The initial workspace setup may live in this
+repository for shared CI and review, but the layout should make it possible to
+move `fluxheim-sdk` into its own GitHub project later without untangling proxy
+internals.
+
 Farther down the line, Fluxheim should also grow a dependency-reduction track:
 once the major web, cache, PHP, proxy, load-balancer, and extension surfaces are
 stable, move bounded Fluxheim-specific logic in-tree and keep large external

docs/versioning-plan.md

@@ -2210,6 +2210,16 @@ Crate naming and crates.io hygiene:
   project-owned packages with README text explaining the difference between the
   binary package and the SDK.
 
+Repository/layout rule:
+
+- place SDK code in a separate workspace directory such as
+  `crates/fluxheim-sdk/`, with its own `Cargo.toml`, README, tests, examples,
+  and public API boundary;
+- do not mix SDK code into the proxy binary's `src/` modules;
+- the initial workspace can live in the Fluxheim repository for shared CI, but
+  the directory and dependency boundary should let the SDK move to its own
+  GitHub project later without extracting proxy internals.
+
 ### 1.7 - Reserved
 
 Compression was pulled forward into the `1.4` production proxy parity line