refactor!: rebrand wraith to alknet

Rename all crates, CLI commands, constants, type names, doc comments,
and documentation from wraith to alknet. Includes wire-protocol changes:
ALPN wraith-ssh -> alknet-ssh, reserved destination prefix wraith- ->
alknet-, SSH auth username wraith -> alknet.

docs/architecture/decisions/001-pluggable-transport.md

@@ -4,9 +4,9 @@
 Accepted
 
 ## Context
-Wraith needs to support multiple transport modes (TCP, TLS, iroh) for SSH sessions. Each mode has different connection establishment logic but produces the same result: a bidirectional byte stream. Without an abstraction, each transport would need its own SSH connection code path.
+Alknet needs to support multiple transport modes (TCP, TLS, iroh) for SSH sessions. Each mode has different connection establishment logic but produces the same result: a bidirectional byte stream. Without an abstraction, each transport would need its own SSH connection code path.
 
-russh's `client::connect_stream()` and `server::run_stream()` both accept `AsyncRead + AsyncWrite + Unpin + Send`, meaning SSH is already transport-agnostic at the API level. The design question is whether to enshrine this in wraith's own type system or handle each transport case-by-case.
+russh's `client::connect_stream()` and `server::run_stream()` both accept `AsyncRead + AsyncWrite + Unpin + Send`, meaning SSH is already transport-agnostic at the API level. The design question is whether to enshrine this in alknet's own type system or handle each transport case-by-case.
 
 ## Decision
 Define a `Transport` trait that produces `AsyncRead + AsyncWrite + Unpin + Send` streams. Each transport (TCP, TLS, iroh) implements this trait. The SSH layer calls `transport.connect()` and passes the result to `russh::client::connect_stream()`.

docs/architecture/decisions/002-tun-separate-process.md

@@ -4,18 +4,18 @@
 Superseded by ADR-014
 
 ## Context
-TUN interface creation requires root privileges or `CAP_NET_ADMIN` on Linux, Administrator on Windows, or platform-specific VPN APIs on macOS/iOS/Android. If the core wraith binary required these privileges, the attack surface of root-required code would include the entire SSH implementation, key handling, and transport negotiation.
+TUN interface creation requires root privileges or `CAP_NET_ADMIN` on Linux, Administrator on Windows, or platform-specific VPN APIs on macOS/iOS/Android. If the core alknet binary required these privileges, the attack surface of root-required code would include the entire SSH implementation, key handling, and transport negotiation.
 
 The primary use cases (SOCKS5 proxy, port forwarding) need no privileges at all. Only the "route all traffic through TUN" use case needs root.
 
 ## Decision
-The TUN functionality is a separate `wraith-tun` binary that:
+The TUN functionality is a separate `alknet-tun` binary that:
 1. Creates a TUN device (requires root / CAP_NET_ADMIN)
 2. Reads IP packets from it
-3. Forwards each connection to the core wraith's SOCKS5 port (127.0.0.1:1080)
+3. Forwards each connection to the core alknet's SOCKS5 port (127.0.0.1:1080)
 4. Proxies bytes between TUN packets and SOCKS5 connections
 
-The core `wraith connect` binary never needs root. The `wraith-tun` binary is ~200-500 lines and does nothing except TUN ↔ SOCKS5 forwarding.
+The core `alknet connect` binary never needs root. The `alknet-tun` binary is ~200-500 lines and does nothing except TUN ↔ SOCKS5 forwarding.
 
 ## Consequences
 - **Positive**: Root-required code surface is tiny and auditable.

docs/architecture/decisions/004-ssh-over-transport.md

@@ -19,7 +19,7 @@ This is directly enabled by russh's `connect_stream()` and `run_stream()` APIs,
 - **Positive**: Adding a new transport requires implementing the `Transport` trait, not modifying SSH code.
 - **Positive**: Testing is straightforward — mock transports produce in-memory streams.
 - **Positive**: Security audit is clean — the SSH implementation has no network-facing code.
-- **Positive**: The transport can be layered. Iroh connecting through a SOCKS5 proxy (which itself tunnels through wraith) is just a transport that calls out to a SOCKS5 library before establishing the QUIC connection.
+- **Positive**: The transport can be layered. Iroh connecting through a SOCKS5 proxy (which itself tunnels through alknet) is just a transport that calls out to a SOCKS5 library before establishing the QUIC connection.
 - **Negative**: SSH keepalive and reconnection must be handled at the transport level. If the transport stream dies, the SSH session dies. Reconnection means establishing a new transport + new SSH session. There's no "SSH reconnects over the same transport" — you get a new session.
 - **Negative**: Multiple SSH sessions over the same iroh connection require the iroh `Endpoint` (not stream) to be shared between sessions. The transport trait produces one stream per `connect()` call. The iroh `Endpoint` must be created externally and shared. (The `IrohTransport` struct holds an `Arc<Endpoint>`.)
 

docs/architecture/decisions/005-socks5-before-tun.md

@@ -24,14 +24,14 @@ SOCKS5 is the core because:
 TUN forwards to SOCKS5 rather than directly to SSH because:
 - The SOCKS5 code already handles TCP connection establishment and bidirectional proxying
 - TUN's job is just IP packet → SOCKS5 connection, not IP packet → SSH channel
-- The `wraith-tun` binary stays minimal (~200-500 lines)
+- The `alknet-tun` binary stays minimal (~200-500 lines)
 - No root code in the core binary
 
 ## Consequences
 - **Positive**: Core binary is root-free. TUN functionality is provided by the external `tun2proxy` tool (ADR-014).
 - **Positive**: SOCKS5 is testable without TUN — just `curl` against it.
 - **Positive**: The TUN approach is validated by tun2proxy, a well-tested existing tool. No custom TUN code to maintain.
-- **Negative**: VPN-like behavior requires running `tun2proxy` alongside `wraith connect` — two processes instead of one integrated binary.
+- **Negative**: VPN-like behavior requires running `tun2proxy` alongside `alknet connect` — two processes instead of one integrated binary.
 - **Negative**: SOCKS5 doesn't capture UDP (except DNS via SOCKS5h). TUN mode via tun2proxy handles this separately.
 
 ## References

docs/architecture/decisions/006-no-logging-of-tunnel-destinations.md

@@ -30,7 +30,7 @@ This separation ensures fail2ban has enough data to detect abusive IPs while des
 - **Positive**: Tunnel destinations are never written to disk or any observable log. This is the same guarantee OpenSSH makes with `LogLevel VERBOSE` or below.
 - **Positive**: Reduces legal and privacy exposure for server operators.
 - **Positive**: fail2ban can still work — it needs source IPs and auth failures, not destinations.
-- **Negative**: Server operators cannot audit what destinations clients are accessing. If an operator needs this for compliance, they must implement it outside wraith (e.g., network-level logging at the target host).
+- **Negative**: Server operators cannot audit what destinations clients are accessing. If an operator needs this for compliance, they must implement it outside alknet (e.g., network-level logging at the target host).
 - **Negative**: Debugging connectivity issues is harder without destination logs. Mitigated by client-side logging (the client knows what it's connecting to).
 
 ## References

docs/architecture/decisions/007-napi-single-stream.md

@@ -4,7 +4,7 @@
 Accepted
 
 ## Context
-The NAPI wrapper for wraith could expose different granularity levels:
+The NAPI wrapper for alknet could expose different granularity levels:
 
 1. **Full SSH API**: Expose channel multiplexing, `open_direct_tcpip`, `tcpip_forward`, session management. The TypeScript layer would manage channels.
 2. **Single duplex stream**: The NAPI wrapper establishes one SSH channel and returns it as a Node.js `Duplex` stream. TypeScript multiplexing (if needed) happens at the pubsub layer.

docs/architecture/decisions/008-acme-lets-encrypt.md

@@ -10,7 +10,7 @@ There are two ACME flows:
 1. **Domain-based**: Standard flow with DNS-01 or HTTP-01 challenge. Certificate is tied to a domain name, auto-renews via certbot/systemd timer. Requires port 80 or DNS access for challenges.
 2. **IP-based**: Short-lived certificates via TLS-ALPN-01 challenge on port 443. No domain needed, but cert is short-lived (days, not months). Simpler for quick setups but requires the ACME client to run continuously.
 
-Both flows are important for wraith's usability. Without ACME, TLS mode requires manual cert setup — a significant barrier for users who want "SSH over port 443" for censorship resistance.
+Both flows are important for alknet's usability. Without ACME, TLS mode requires manual cert setup — a significant barrier for users who want "SSH over port 443" for censorship resistance.
 
 ## Decision
 Support both ACME certificate provisioning paths:
@@ -21,10 +21,10 @@ Support both ACME certificate provisioning paths:
 
 3. **Manual certs** (`--tls-cert` / `--tls-key`): Always supported for users with existing certificates or specific PKI setups.
 
-The implementation should use the `rustls-acme` crate (or similar pure-Rust ACME client) to avoid an external certbot dependency. This keeps wraith self-contained as a single binary.
+The implementation should use the `rustls-acme` crate (or similar pure-Rust ACME client) to avoid an external certbot dependency. This keeps alknet self-contained as a single binary.
 
 ## Consequences
-- **Positive**: Users can run `wraith serve --transport tls --acme-domain example.com` and get working TLS with zero manual cert management.
+- **Positive**: Users can run `alknet serve --transport tls --acme-domain example.com` and get working TLS with zero manual cert management.
 - **Positive**: IP-based ACME covers the quick-setup case without requiring a domain.
 - **Positive**: Consistent with our production infrastructure (certbot + Let's Encrypt is already our standard).
 - **Negative**: ACME adds complexity to the server binary (challenge responder, cert store, renewal timer).

docs/architecture/decisions/009-default-iroh-relay.md

@@ -18,7 +18,7 @@ Default to n0's relay servers. Allow override via `--iroh-relay <url>` CLI flag.
 This matches iroh's own defaults — n0's relay is the standard starting point. Users who need production reliability self-host.
 
 ## Consequences
-- **Positive**: Zero-config iroh transport for testing and development. `wraith serve --transport iroh` just works.
+- **Positive**: Zero-config iroh transport for testing and development. `alknet serve --transport iroh` just works.
 - **Positive**: Self-hosting is a single flag override, not a complex setup requirement.
 - **Negative**: Default depends on n0's infrastructure. If n0's relay is down, default iroh connections fail (but this is the same experience as every iroh user).
 - **Negative**: Privacy-conscious users must remember to `--iroh-relay` to avoid n0. Mitigated by documentation.

docs/architecture/decisions/010-transport-chaining-cli.md

@@ -7,10 +7,10 @@ Accepted
 Transport chaining allows combining iroh with an upstream proxy, e.g.:
 
 ```bash
-wraith connect --transport iroh --proxy socks5://127.0.0.1:1080
+alknet connect --transport iroh --proxy socks5://127.0.0.1:1080
 ```
 
-This routes iroh's outbound TCP connections through a SOCKS5 proxy, which could itself be another wraith instance. This is important for:
+This routes iroh's outbound TCP connections through a SOCKS5 proxy, which could itself be another alknet instance. This is important for:
 - Nested tunnel topologies
 - Environments where iroh needs to go through an existing proxy
 - Composing transports in flexible ways

docs/architecture/decisions/011-no-ssh-config-programmatic-api.md

@@ -7,21 +7,21 @@ Accepted
 The client and server both need configuration (host addresses, keys, transport options, etc.). There are several approaches:
 
 1. **Read `~/.ssh/config`**: Parse OpenSSH config for default host/key/port. Reduces CLI verbosity for frequent connections.
-2. **Custom config file**: Wraith-specific config file (TOML/YAML) with host definitions.
+2. **Custom config file**: Alknet-specific config file (TOML/YAML) with host definitions.
 3. **Programmatic API only**: Configuration comes from CLI flags or the library API. No file parsing. `~/.ssh/` path conventions are cross-platform trouble (`~` expansion, Windows paths, etc.).
-4. **Hybrid**: `--config` flag pointing to a wraith-specific config file, but no OpenSSH config parsing.
+4. **Hybrid**: `--config` flag pointing to a alknet-specific config file, but no OpenSSH config parsing.
 
 ## Decision
 Option 3: Programmatic-first API. Configuration is provided via:
 - **CLI**: explicit flags (`--server`, `--identity`, `--transport`, etc.)
-- **Library API**: `wraith_core::client::ConnectOptions` and `wraith_core::server::ServeOptions` structs, constructable programmatically
-- **Environment variables**: for a few convenience defaults (e.g., `WRAITH_SERVER`, `WRAITH_IDENTITY`)
+- **Library API**: `alknet_core::client::ConnectOptions` and `alknet_core::server::ServeOptions` structs, constructable programmatically
+- **Environment variables**: for a few convenience defaults (e.g., `ALKNET_SERVER`, `ALKNET_IDENTITY`)
 
-No `~/.ssh/config` parsing, no wraith-specific config files. This approach:
+No `~/.ssh/config` parsing, no alknet-specific config files. This approach:
 - Avoids cross-platform path issues (`~` expansion, Windows `USERPROFILE`, etc.)
 - Makes the library API clean and straightforward for programmatic consumers (NAPI wrapper, pubsub)
 - Keeps the CLI simple and explicit — no hidden behavior from config files
-- Matches the design principle that the library crate (`wraith-core`) is the primary interface
+- Matches the design principle that the library crate (`alknet-core`) is the primary interface
 
 If users want config-file behavior in the future, it can be added as a separate layer that populates the options structs. But the core doesn't need to know about files.
 

docs/architecture/decisions/013-fail2ban-friendly-logging.md

@@ -27,11 +27,11 @@ This matches what fail2ban needs: source IP + failure indicator. Our existing fa
 This ensures that even without fail2ban, the server rejects obviously abusive connections.
 
 ## Consequences
-- **Positive**: fail2ban can parse wraith logs the same way it parses SSH and nginx logs on our production systems.
+- **Positive**: fail2ban can parse alknet logs the same way it parses SSH and nginx logs on our production systems.
 - **Positive**: Built-in rate limiting provides protection on platforms without fail2ban.
 - **Positive**: No privacy-sensitive data in logs (no tunnel destinations).
 - **Negative**: Slightly more code in the server for connection tracking per IP.
-- **Negative**: Users with custom fail2ban filters need to write regex for wraith's log format (documented examples provided).
+- **Negative**: Users with custom fail2ban filters need to write regex for alknet's log format (documented examples provided).
 
 ## References
 - [server.md](../server.md)

docs/architecture/decisions/014-defer-tun-recommend-socks5-proxy.md

@@ -4,7 +4,7 @@
 Accepted
 
 ## Context
-The original plan included a TUN shim (`wraith-tun`) as Phase 3 — a separate root-requiring process that creates a TUN device and forwards IP packets through wraith's SOCKS5 port. This would provide VPN-like "route all traffic" behavior.
+The original plan included a TUN shim (`alknet-tun`) as Phase 3 — a separate root-requiring process that creates a TUN device and forwards IP packets through alknet's SOCKS5 port. This would provide VPN-like "route all traffic" behavior.
 
 However, TUN implementation has significant complexities:
 - Platform differences (Linux TUN, macOS utun, Windows wintun.dll)
@@ -16,21 +16,21 @@ However, TUN implementation has significant complexities:
 The core SOCKS5 interface already works for the vast majority of use cases. For users who truly need VPN-like "route all traffic" behavior, `tun2proxy` is an existing, well-tested tool that does exactly this: creates a TUN device and routes traffic through a SOCKS5 proxy.
 
 ## Decision
-Defer TUN implementation entirely. Remove `wraith-tun` from the architecture. Instead:
+Defer TUN implementation entirely. Remove `alknet-tun` from the architecture. Instead:
 
-1. **Core interface**: wraith's local SOCKS5 proxy (always available, no root required)
-2. **VPN-like behavior**: Users who need it run `tun2proxy --proxy socks5://127.0.0.1:1080` alongside `wraith connect`
+1. **Core interface**: alknet's local SOCKS5 proxy (always available, no root required)
+2. **VPN-like behavior**: Users who need it run `tun2proxy --proxy socks5://127.0.0.1:1080` alongside `alknet connect`
 3. **Documentation**: Recommend tun2proxy in the README/wiki for "route all traffic" use cases
 
-This removes TUN from the project scope while still providing a path to VPN-like behavior. If demand justifies it later, `wraith-tun` can be added as a thin wrapper around tun2proxy's pattern.
+This removes TUN from the project scope while still providing a path to VPN-like behavior. If demand justifies it later, `alknet-tun` can be added as a thin wrapper around tun2proxy's pattern.
 
-The `tun` feature flag and `wraith-tun` binary are removed from the architecture. The `tun-rs` dependency is removed.
+The `tun` feature flag and `alknet-tun` binary are removed from the architecture. The `tun-rs` dependency is removed.
 
 ## Consequences
 - **Positive**: Significantly reduces project scope and complexity. No TUN code to write, test, or maintain across platforms.
 - **Positive**: tun2proxy is already well-tested for this exact use case.
 - **Positive**: Core binary remains unprivileged. No root code anywhere in the project.
-- **Positive**: Cleaner architecture — wraith only does SSH tunneling + SOCKS5. tun2proxy does TUN.
+- **Positive**: Cleaner architecture — alknet only does SSH tunneling + SOCKS5. tun2proxy does TUN.
 - **Negative**: Users need two tools instead of one for VPN-like behavior. Mitigated by documentation.
 - **Negative**: tun2proxy is an external dependency in practice, though it's widely available in package managers.
 - **Negative**: No first-class Windows/macOS TUN story. tun2proxy handles these platforms but users need to install it separately.

docs/architecture/decisions/016-napi-expose-connect-and-serve.md

@@ -4,35 +4,35 @@
 Accepted
 
 ## Context
-The NAPI wrapper needs to provide TypeScript/Node.js consumers with access to wraith's functionality. The primary use case is `@alkdev/pubsub`'s event target system, which needs both directions:
+The NAPI wrapper needs to provide TypeScript/Node.js consumers with access to alknet's functionality. The primary use case is `@alkdev/pubsub`'s event target system, which needs both directions:
 
-1. **connect()**: Establish a client connection to a wraith server. Used by workers/spokes that need to tunnel events through a wraith server.
-2. **serve()**: Start a wraith server from Node.js. Used by hubs that want to accept wraith connections and route events.
+1. **connect()**: Establish a client connection to a alknet server. Used by workers/spokes that need to tunnel events through a alknet server.
+2. **serve()**: Start a alknet server from Node.js. Used by hubs that want to accept alknet connections and route events.
 
-The previous decision (ADR-007) was to expose only `connect()` for MVP, deferring `serve()`. However, the pubsub integration requires both: a spoke needs `connect()` to reach a hub, and a hub could use `serve()` to accept connections without running a separate `wraith serve` process.
+The previous decision (ADR-007) was to expose only `connect()` for MVP, deferring `serve()`. However, the pubsub integration requires both: a spoke needs `connect()` to reach a hub, and a hub could use `serve()` to accept connections without running a separate `alknet serve` process.
 
-More importantly, both `connect()` and `serve()` are fundamental operations of the wraith library. Since the NAPI wrapper is a thin layer over `wraith-core`, exposing both is straightforward — they're just Rust functions behind `#[napi]` attributes.
+More importantly, both `connect()` and `serve()` are fundamental operations of the alknet library. Since the NAPI wrapper is a thin layer over `alknet-core`, exposing both is straightforward — they're just Rust functions behind `#[napi]` attributes.
 
 ## Decision
 The NAPI wrapper exposes both `connect()` and `serve()` from the start:
 
 ```typescript
-// @alkdev/wraith
-function connect(options: WraithConnectOptions): Promise<Duplex>;
-function serve(options: WraithServeOptions): Promise<WraithServer>;
+// @alkdev/alknet
+function connect(options: AlknetConnectOptions): Promise<Duplex>;
+function serve(options: AlknetServeOptions): Promise<AlknetServer>;
 ```
 
 - `connect()` returns a `Duplex` stream (as per ADR-007)
-- `serve()` returns a `WraithServer` object with a `close()` method and events for new connections
+- `serve()` returns a `AlknetServer` object with a `close()` method and events for new connections
 
 The NAPI layer is transport-agnostic — it doesn't know about pubsub's `EventEnvelope`. The pubsub event target adapter wraps the `Duplex` stream to implement `TypedEventTarget`. This separation ensures the NAPI wrapper is reusable for any stream-based protocol, not just pubsub.
 
 ## Consequences
 - **Positive**: Pubsub can use both directions without running a separate binary for the server side.
 - **Positive**: The NAPI wrapper becomes a complete bridge — any Node.js process can be either a client or server.
-- **Positive**: Implementation is still minimal — `serve()` is just `wraith_core::server::run()` behind `#[napi]`.
-- **Negative**: Slightly larger API surface (two functions + `WraithServer` type instead of just `connect()`).
-- **Negative**: Server-side NAPI needs to handle multiple concurrent connections, which adds complexity to `WraithServer`.
+- **Positive**: Implementation is still minimal — `serve()` is just `alknet_core::server::run()` behind `#[napi]`.
+- **Negative**: Slightly larger API surface (two functions + `AlknetServer` type instead of just `connect()`).
+- **Negative**: Server-side NAPI needs to handle multiple concurrent connections, which adds complexity to `AlknetServer`.
 
 ## References
 - [napi-and-pubsub.md](../napi-and-pubsub.md)

docs/architecture/decisions/017-stealth-mode-protocol-multiplexing.md

@@ -4,7 +4,7 @@
 Accepted
 
 ## Context
-When running a wraith server with TLS transport on port 443, the server should be indistinguishable from a regular HTTPS web server to port scanners and deep packet inspection (DPI) systems. This is important for censorship circumvention — if SSH traffic on port 443 is detectable, it can be blocked.
+When running a alknet server with TLS transport on port 443, the server should be indistinguishable from a regular HTTPS web server to port scanners and deep packet inspection (DPI) systems. This is important for censorship circumvention — if SSH traffic on port 443 is detectable, it can be blocked.
 
 After the TLS handshake completes, the server sees a raw byte stream. SSH protocol identification starts with `SSH-2.0-`, while HTTP starts with HTTP method verbs (GET, POST, etc.). The server can inspect the first bytes to determine the protocol.
 
@@ -20,7 +20,7 @@ This makes the server appear as an nginx web server returning 404 errors to all
 The fake response uses `Server: nginx` headers to match the most common web server profile.
 
 ## Consequences
-- **Positive**: TLS+wraith servers on port 443 are indistinguishable from ordinary HTTPS sites to automated scanners.
+- **Positive**: TLS+alknet servers on port 443 are indistinguishable from ordinary HTTPS sites to automated scanners.
 - **Positive**: Simple implementation — just peek at the first bytes and branch.
 - **Positive**: Consistent with censorship circumvention best practices.
 - **Negative**: Legitimate HTTPS traffic to the same port gets a 404. If the same IP needs to serve real web content, use a reverse proxy (nginx/haproxy) in front that routes by SNI or path.

docs/architecture/decisions/018-control-channel-for-pubsub.md

@@ -4,22 +4,22 @@
 Accepted
 
 ## Context
-The NAPI wrapper and pubsub integration need a way to use wraith's SSH channel as a data plane for event routing. When a `wraith connect` client opens an SSH session to a server, the `direct_tcpip` channel type is used to reach specific TCP targets (host:port).
+The NAPI wrapper and pubsub integration need a way to use alknet's SSH channel as a data plane for event routing. When a `alknet connect` client opens an SSH session to a server, the `direct_tcpip` channel type is used to reach specific TCP targets (host:port).
 
 For the pubsub use case, the client needs a dedicated bidirectional stream to the server's event bus — not a TCP connection to a random host. There are several approaches:
 
-1. **Special destination**: Use `direct_tcpip` with a reserved destination (e.g., `wraith-control:0`) that the server recognizes and routes internally instead of connecting to a TCP target.
+1. **Special destination**: Use `direct_tcpip` with a reserved destination (e.g., `alknet-control:0`) that the server recognizes and routes internally instead of connecting to a TCP target.
 2. **Port forwarding**: The server runs a pubsub hub on a specific port (e.g., 9736) and the client uses normal port forwarding (`-L 9736:hub:9736`).
 3. **Custom channel type**: Define a new SSH channel type beyond `direct_tcpip` and `forwarded_tcpip`.
 
 ## Decision
-Use approach 1: a reserved `direct_tcpip` destination string. When the server receives a `channel_open_direct_tcpip` request for `wraith-control:0`:
+Use approach 1: a reserved `direct_tcpip` destination string. When the server receives a `channel_open_direct_tcpip` request for `alknet-control:0`:
 
 1. The `channel_open_direct_tcpip` handler detects the special target via string matching
 2. Instead of connecting to a TCP target, it bridges the channel to the local pubsub event bus
 3. `EventEnvelope` JSON flows bidirectionally over the SSH channel
 
-The destination string `wraith-control` is reserved. Regular TCP targets are hostnames or IP addresses, so there is no collision risk.
+The destination string `alknet-control` is reserved. Regular TCP targets are hostnames or IP addresses, so there is no collision risk.
 
 Approach 2 (port forwarding to a specific port) is still supported as an alternative — the client can use `--forward 9736:localhost:9736` if the server runs a pubsub hub on that port. But the control channel approach is simpler and doesn't require a separate listening port.
 
@@ -27,11 +27,11 @@ Approach 3 (custom channel type) was rejected because russh's `direct_tcpip` han
 
 ## Consequences
 - **Positive**: Simple implementation — just string matching in the server's `channel_open_direct_tcpip` handler.
-- **Positive**: No separate port or service needs to run on the server. The control channel is built into wraith.
+- **Positive**: No separate port or service needs to run on the server. The control channel is built into alknet.
 - **Positive**: Compatible with the NAPI wrapper's single-duplex-stream model.
 - **Positive**: Port forwarding to a specific port is still available as an alternative.
-- **Negative**: The string `wraith-control` is a magic constant. It should be defined as a constant in the crate.
-- **Negative**: Regular TCP destinations accidentally matching `wraith-control` would be misrouted. Mitigated by reserving the entire `wraith-` prefix namespace.
+- **Negative**: The string `alknet-control` is a magic constant. It should be defined as a constant in the crate.
+- **Negative**: Regular TCP destinations accidentally matching `alknet-control` would be misrouted. Mitigated by reserving the entire `alknet-` prefix namespace.
 
 ## References
 - [napi-and-pubsub.md](../napi-and-pubsub.md)

docs/architecture/decisions/019-proxy-dual-semantics.md

@@ -4,11 +4,11 @@
 Accepted
 
 ## Context
-The `--proxy` CLI flag appears on both `wraith connect` (client) and `wraith serve` (server), but the two sides proxy fundamentally different things:
+The `--proxy` CLI flag appears on both `alknet connect` (client) and `alknet serve` (server), but the two sides proxy fundamentally different things:
 
-- **Client**: `--proxy` routes the *transport connection* through the proxy. For example, `wraith connect --transport iroh --proxy socks5://127.0.0.1:1080` means the iroh endpoint's outbound TCP connections go through the specified SOCKS5 proxy before reaching the iroh relay. The proxy wraps the transport layer.
+- **Client**: `--proxy` routes the *transport connection* through the proxy. For example, `alknet connect --transport iroh --proxy socks5://127.0.0.1:1080` means the iroh endpoint's outbound TCP connections go through the specified SOCKS5 proxy before reaching the iroh relay. The proxy wraps the transport layer.
 
-- **Server**: `--proxy` routes *outbound target connections* through the proxy. For example, `wraith serve --proxy socks5://127.0.0.1:9050` means when an SSH client opens a `direct_tcpip` channel to `db.internal:5432`, the server connects to that target through the specified proxy. The proxy wraps the data-plane connections.
+- **Server**: `--proxy` routes *outbound target connections* through the proxy. For example, `alknet serve --proxy socks5://127.0.0.1:9050` means when an SSH client opens a `direct_tcpip` channel to `db.internal:5432`, the server connects to that target through the specified proxy. The proxy wraps the data-plane connections.
 
 Using the same flag name for both is intentional — from the user's perspective, both mean "route traffic through a proxy." But the layer at which the proxy operates differs, and this needs to be explicit so implementers don't confuse the two.
 

docs/architecture/decisions/023-unified-auth-shared-key-material.md

@@ -5,7 +5,7 @@ Accepted
 
 ## Context
 
-Wraith currently authenticates connections exclusively through SSH public key
+Alknet currently authenticates connections exclusively through SSH public key
 auth in the SSH handshake. This works for SSH-over-any-transport (TCP, TLS,
 iroh) because SSH carries its own auth protocol. But WebTransport and other
 HTTP-level transports cannot perform SSH key exchange — browsers speak HTTP/3,
@@ -17,8 +17,8 @@ identity system (API keys, JWTs, session tokens). This creates two problems:
 same person connecting via SSH and WebTransport appears as two different
 identities.
 
-The `IdentityProvider` trait is needed to decouple wraith-core from any
-specific identity storage (config file vs. database). Without it, wraith-core
+The `IdentityProvider` trait is needed to decouple alknet-core from any
+specific identity storage (config file vs. database). Without it, alknet-core
 would either hardcode config-file-based auth or take a database dependency —
 neither is acceptable for a library crate.
 
@@ -42,7 +42,7 @@ AuthToken = base64url(key_id || timestamp || signature)
 Server extracts the fingerprint, looks it up in the same `authorized_keys`
 set, verifies the signature, and checks the timestamp window (default ±300s).
 
-**`IdentityProvider` trait**: Decouples wraith-core from identity storage. The
+**`IdentityProvider` trait**: Decouples alknet-core from identity storage. The
 trait resolves a fingerprint or token to an `Identity`. Default implementation
 loads from `DynamicConfig.auth` (no database). Hub implementation can back it
 with `@alkdev/storage`.
@@ -60,7 +60,7 @@ the key material.
 - **Positive**: One key set, one rotation, one `reloadAuth()` call. Adding a
   key to `authorized_keys` immediately grants access via both SSH and
   WebTransport.
-- **Positive**: `IdentityProvider` trait makes wraith-core independent of any
+- **Positive**: `IdentityProvider` trait makes alknet-core independent of any
   specific database. Default: config file. Hub: `@alkdev/storage`.
 - **Positive**: Browser clients can authenticate using Ed25519 keys via
   SubtleCrypto (Chrome 105+, Firefox 130+, Safari 17+). Deno supports it

docs/architecture/decisions/024-bidirectional-call-protocol.md

@@ -5,7 +5,7 @@ Accepted
 
 ## Context
 
-The wraith control channel (ADR-018) routes from client → server's event bus.
+The alknet control channel (ADR-018) routes from client → server's event bus.
 This is unidirectional: clients can send events to the server, but the server
 cannot call operations on the client. In the hub/spoke model, spokes (dev env
 containers) connect to a hub and expose operations (fs, bash, search) that the
@@ -35,7 +35,7 @@ Core-provided operations use short paths without a spoke prefix
 (`/services/list`, `/services/schema`). Spoke operations are prefixed
 (`/dev1/fs/readFile`).
 
-This generalizes ADR-018's control channel: the `wraith-*` destination becomes
+This generalizes ADR-018's control channel: the `alknet-*` destination becomes
 a transport for `EventEnvelope` frames with call protocol semantics, instead of
 raw pubsub dispatch.
 

docs/architecture/decisions/025-handler-spec-separation.md

@@ -5,7 +5,7 @@ Accepted
 
 ## Context
 
-The current control channel (ADR-018) is hardcoded: `wraith-control:0` bridges
+The current control channel (ADR-018) is hardcoded: `alknet-control:0` bridges
 to the local pubsub event bus. If NAPI wants to expose `fs.readFile` or
 `bash.exec` as callable operations, it has no way to register these with core's
 channel routing. The NAPI handler would need to intercept channel data outside