feat(hololake): add signed dynamic capability routing

product-source/hololake-native-desktop/docs/adr/0001-dynamic-capability-routing.md

@@ -0,0 +1,22 @@
+# ADR 0001: Signed dynamic capability routing
+
+Status: Accepted locally; production trust provisioning pending.
+
+## Context
+
+Stage one must connect a changing fleet of team and user-owned nodes without hardcoded endpoints. SSH access, root access, a URL, or a health probe cannot establish Guanghu node identity or write authority. The client must also preserve the one-human-one-owned-root-node boundary and avoid becoming a hosted concurrency layer.
+
+## Decision
+
+Use a Rust-owned, file-backed dynamic registry whose complete canonical payload is verified with an independently embedded Ed25519 trust root. Each node carries a protocol public key and explicit human, persona, domain and capability bindings. Runtime eligibility additionally requires a fresh Ed25519 health receipt from that node with a strictly increasing sequence.
+
+Route resolution is available to external programming AI only through an authenticated active local HoloLake session. It returns a non-authorizing route receipt. Webview code cannot install registries or submit health receipts.
+
+The embedded trust file initially contains no signer. This makes production registry installation fail closed until the registered HoloLake/JD-controller signing identity is provisioned.
+
+## Consequences
+
+- The fleet can grow without client code changes or fixed server slots.
+- Stale, replayed, unsigned or incorrectly bound nodes are not routable.
+- Registry publication, health, route selection and write admission remain separate facts.
+- Production node enrollment and write execution still require their own source, signing, deployment and readback receipts.