docs(architecture): untangle TLS identity use cases, remove phase framing, add ADR-013 Rust canonical + agent crate

- Rewrite OQ-12: separate two distinct TLS identity use cases (RFC 7250
  raw keys as default for P2P, X.509 for domain-hosted/browsers) instead
  of conflating them as 'file paths now, ACME later'. ACME is a proven
  pattern from the reverse-proxy project, not speculative future work.

- Resolve OQ-13 and OQ-14: remove 'Phase 1' framing from core crate
  specs. /{service}/{op} is the correct design for alknet-call, not a
  simplification. Batch as correlated call.requested events is the correct
  protocol design. Core crates need to be done right from the start.

- Add ADR-013: Rust as canonical implementation language. TypeScript
  @alkdev/operations is a reference that informed the design, not a
  parallel implementation. The only JS use case is browser SDK adaptation.
  Five reasons: memory safety, LLM competence, supply chain attacks,
  performance, browser-only JS.

- Add alknet-agent crate to the crate graph (depends on alknet-call, not
  alknet-core). Agent service uses call protocol client for tool dispatch
  and vault/derive for provider keys — no env vars for secrets. ALPN
  alknet/agent added to the registry.

- Add OQ-15: call protocol client and adapter contract. alknet-call needs
  both server (CallAdapter) and client (remote invocation over QUIC), plus
  the adapter traits (from_*, to_*) that enable composition.

- Clarify alknet-napi as thin NAPI projection layer, not business logic.

- Fix bugs: ProtocolController → ProtocolHandler typo, OperationEnv
  invoke() path format inconsistency, RateLimitConfig comment confusion.

- Update endpoint.md TLS section: comprehensive identity model comparison
  table, RFC 7250 as default mode, ACME as proven pattern.

docs/architecture/decisions/003-crate-decomposition.md

@@ -14,8 +14,9 @@ Key constraints:
 - Protocol crates must depend on alknet-core for auth/identity/config — but not on each other
 - alknet-vault is already standalone (no alknet-core dependency) and must remain so (see ADR-008)
 - The CLI binary assembles everything — it's the only crate that depends on all handler crates
-- Some handlers (SFTP, call protocol) need to compile to WASM for browser/client use
-- irpc is the foundation for the call protocol — it provides the operation registry, framing, and pub/sub patterns
+- Handlers with protocol-agnostic cores (SFTP, call protocol) preserve the WASM door — browser clients can implement the wire format over WebTransport (see ADR-009, ADR-013)
+- alknet-call includes the call protocol client and adapter traits, not just the server side — this enables alknet-agent and alknet-napi to use it for remote invocation
+- Rust is the canonical implementation language. TypeScript is a reference/browser adaptation, not a parallel implementation (see ADR-013)
 
 ## Decision
 
@@ -26,24 +27,30 @@ The workspace decomposes into the following crates:
 | `alknet-core` | ProtocolHandler trait, ALPN router, endpoint, BiStream, AuthContext, IdentityProvider, config, ArcSwap dynamic config | tokio, quinn, rustls, irpc |
 | `alknet-vault` | Local key vault: BIP39/SLIP-0010/AES-GCM key derivation, encryption, VaultProtocol dispatch | (standalone, no alknet-core) |
 | `alknet-ssh` | SshAdapter (russh, SOCKS5, port forwarding) | alknet-core, russh |
-| `alknet-call` | CallAdapter (JSON-RPC via irpc, operation registry, pub/sub, access control) | alknet-core, irpc |
+| `alknet-call` | CallAdapter (JSON-RPC via irpc, operation registry, pub/sub, access control, call protocol client, adapter traits) | alknet-core, irpc |
+| `alknet-agent` | Agent service: LLM execution loop (forked aisdk), tool dispatch via call protocol, provider key retrieval via vault | alknet-call |
 | `alknet-git` | GitAdapter (gix, pkt-line protocol) | alknet-core, gix |
 | `alknet-sftp` | SftpAdapter (russh-sftp protocol core) | alknet-core, russh-sftp |
 | `alknet-msg` | MessageAdapter (E2E encryption, mixnet) | alknet-core |
 | `alknet-http` | HttpAdapter (axum, REST API, MCP endpoint) | alknet-core, axum |
 | `alknet-dns` | DnsAdapter (hickory-proto, pkarr, service discovery) | alknet-core, hickory-proto |
-| `alknet-napi` | Node.js native addon (call protocol client) | alknet-call, napi-rs |
-| `alknet` | CLI binary — registers handlers, starts endpoint | all handler crates |
+| `alknet-napi` | Node.js native addon — thin NAPI projection of the call protocol client | alknet-call, napi-rs |
+| `alknet` | CLI binary — registers handlers, starts endpoint | all handler crates, alknet-vault |
 
 Dependency flow:
 ```
 alknet-vault (standalone)
 alknet-core ← all handler crates ← alknet (CLI)
+alknet-call ← alknet-agent
 alknet-call ← alknet-napi
 ```
 
 No handler crate depends on another handler crate. Cross-handler communication goes through the call protocol (alknet-call) or through alknet-core's endpoint.
 
+alknet-agent depends on alknet-call (not alknet-core directly) because it uses the call protocol client for tool dispatch and the operation registry for tool registration. It retrieves LLM provider keys through alknet-call → alknet-vault (via the call protocol), never from environment variables.
+
+alknet-napi is a thin projection layer — it exposes the Rust call protocol client to Node.js via NAPI. It does not contain business logic or adapter implementations. See ADR-013.
+
 ## Consequences
 
 **Positive:**

docs/architecture/decisions/005-irpc-as-call-protocol-foundation.md

@@ -14,7 +14,7 @@ The previous implementation used `irpc` for the call protocol's operation regist
 - Request/response and streaming patterns
 - Type-safe operation definitions via derive macros
 
-The call protocol is derived from a TypeScript implementation of "operations" and "pub/sub" that can wholesale import OpenAPI schemas, wrap MCP servers, and go the other direction — exposing operations as HTTP endpoints, MCP tools, etc. This bidirectional capability is strategically important.
+The call protocol is derived from a TypeScript implementation (`@alkdev/operations`, `@alkdev/pubsub`) that informed the design of the operation registry, EventEnvelope framing, and adapter patterns (from_openapi, from_mcp, from_call). This bidirectional composition capability is strategically important. The TypeScript code is a reference that informed the Rust design — it is not a parallel implementation (see ADR-013).
 
 ## Decision
 
@@ -27,8 +27,8 @@ irpc is not replaced or wrapped in an abstraction layer — it IS the call proto
 This means:
 - The wire format is irpc's EventEnvelope framing — length-prefixed JSON
 - Operation schemas follow irpc's schema model — JSON Schema compatible
-- The TypeScript "operations" and "pub/sub" patterns that can import OpenAPI schemas and expose MCP tools are supported at the protocol level
-- Future NAPI and WASM clients speak the same wire format
+- The TypeScript operation and pub/sub patterns that can import OpenAPI schemas, wrap MCP servers, and expose operations as endpoints are supported at the protocol level — the adapter contract (from_*, to_*) is defined in Rust (see ADR-013)
+- Future NAPI and WASM clients speak the same wire format — alknet-napi projects the Rust call protocol client to Node.js; a browser SDK can be adapted from the existing TypeScript code
 
 The `VaultProtocol` in alknet-vault also uses irpc as its service protocol. This is consistent — alknet-vault's irpc service is an independent service that happens to use the same framing, not a dependency on alknet-call.
 

docs/architecture/decisions/010-alpn-router-and-endpoint.md

@@ -183,7 +183,7 @@ pub enum HandlerError {
 **Negative:**
 - alknet-core depends on both quinn and iroh (mitigated: both are feature-gated; a node that only needs one doesn't compile the other)
 - The endpoint is more complex than a single quinn listener — it manages multiple accept loops
-- TLS cert provisioning is manual (file paths) for v1 — ACME auto-provisioning is a future feature (OQ-12)
+- TLS identity provisioning has two distinct use cases: RFC 7250 raw keys (default for P2P/key-based identity) and X.509 certs (for domain-hosted services and browsers). ACME auto-provisioning for X.509 is a proven pattern from the reverse-proxy project, not speculative future work. See OQ-12.
 - No runtime handler registration without regenerating the TLS config (mitigated: two-way door, start static, add ArcSwap later if needed)
 
 ## References

docs/architecture/decisions/013-rust-canonical-implementation.md

@@ -0,0 +1,72 @@
+# ADR-013: Rust as Canonical Implementation Language
+
+## Status
+
+Accepted
+
+## Context
+
+alknet's core crates (alknet-core, alknet-call, alknet-vault) and all handler crates are implemented in Rust. A previous TypeScript implementation (`@alkdev/operations`, `@alkdev/pubsub`) informed the design of the call protocol — its operation registry, EventEnvelope framing, adapter patterns (from_openapi, from_mcp, from_call), and bidirectional composition.
+
+The question is: what is the relationship between the TypeScript implementation and the Rust implementation? Is TypeScript a parallel implementation that must be maintained in lockstep, or is Rust the canonical implementation with TypeScript serving a specific role?
+
+Five factors make Rust the canonical choice:
+
+1. **Memory safety eliminates an entire vulnerability class.** Rust's ownership model prevents buffer overflows, use-after-free, and other memory corruption bugs that are endemic in C/C++ and impossible to audit away in JavaScript runtimes.
+
+2. **LLM code generation quality is comparable across Rust and TypeScript.** Agents "grok" both languages roughly equally, so there is no productivity argument for TypeScript.
+
+3. **NPM supply chain attacks are growing rapidly.** The JavaScript ecosystem's dependency density makes supply chain attacks a persistent and increasing risk. NPM is dropping features like post-install scripts in response. This trend makes JavaScript an unreliable foundation for security-critical infrastructure.
+
+4. **Rust is significantly faster.** For networking, encryption, and protocol handling, the performance difference is material — not marginal.
+
+5. **The only legitimate JavaScript use case is the browser.** WASM/WebTransport clients need a JavaScript SDK, and the existing `@alkdev/operations` TypeScript code can be adapted for browser use cases where users want to expose operations to web applications. This is a consumer SDK, not a parallel implementation.
+
+## Decision
+
+**Rust is the canonical implementation language.** All alknet crates are implemented in Rust. The TypeScript `@alkdev/operations` and `@alkdev/pubsub` libraries are reference implementations that informed the design; they are not maintained as parallel implementations.
+
+The relationship between the TypeScript and Rust implementations:
+
+| Aspect | Rust (canonical) | TypeScript (reference/browser) |
+|--------|-----------------|-------------------------------|
+| OperationSpec, OperationRegistry | alknet-call owns canonical types | `@alkdev/operations` projects canonical types into TS |
+| Wire protocol (EventEnvelope) | alknet-call owns canonical framing | `@alkdev/pubsub` implements the same wire format for browser |
+| Adapter patterns (from_*, to_*) | alknet-call defines adapter traits and Rust implementations | Browser-adapted implementations where needed |
+| Call protocol client | alknet-call (QUIC) | alknet-napi (QUIC via NAPI) or browser SDK (WebTransport) |
+| LLM provider integration | alknet-agent (forked aisdk, simplified) | Not applicable |
+| Provider key management | alknet-vault via call protocol (no env vars) | Not applicable |
+
+**The adapter contract (from_openapi, from_mcp, from_call, to_openapi, to_mcp) lives in Rust.** These patterns convert external specifications or protocols into `OperationSpec + Handler` pairs that register in the local `OperationRegistry`. The TypeScript implementations serve as reference for browser adaptations, not as the source of truth.
+
+**alknet-napi is a thin projection layer.** It exposes the Rust call protocol client to Node.js via NAPI. It does not contain business logic or adapter implementations. TypeScript consumers who want to use alknet from Node.js use alknet-napi to access the Rust implementation.
+
+**The browser SDK is a future adaptation.** When WASM/WebTransport support is needed, the existing TypeScript code can be adapted to run in browsers, speaking the same EventEnvelope wire format over WebTransport streams. This preserves the WASM door (ADR-009) without requiring Rust-to-WASM compilation of the full stack.
+
+## Consequences
+
+**Positive:**
+- Single implementation to maintain, test, and secure
+- Memory safety eliminates a whole class of vulnerabilities
+- Provider key management through alknet-vault (call protocol) instead of env vars
+- No NPM dependency chain for security-critical infrastructure
+- The existing TypeScript code informs the Rust design — its patterns are preserved, not its implementation
+- Browser clients get a thin, adapted SDK rather than the full operations library
+
+**Negative:**
+- Browser support requires a separate JavaScript SDK (adapted from existing TS code) rather than a shared implementation
+- Contributors who only know JavaScript cannot contribute to core alknet crates
+- The `@alkdev/operations` TypeScript library may drift from the canonical Rust types if not kept in sync during the transition period
+
+**Risks mitigated:**
+- WASM door preserved: The `@alkdev/operations` TypeScript code can be adapted for browser use without recompiling Rust to WASM. The wire format is JSON, which any runtime can produce and consume.
+- NAPI consumers: alknet-napi provides the call protocol client to Node.js without reimplementing in JavaScript.
+
+## References
+
+- ADR-003: Crate decomposition
+- ADR-005: irpc as call protocol foundation
+- ADR-009: One-way door decision framework (WASM door)
+- Reference TypeScript implementation: `/workspace/@alkdev/operations`
+- Reference TypeScript pubsub: `/workspace/@alkdev/pubsub`
+- aisdk (Rust port to be forked): `/workspace/aisdk`