docs: finalize v1 design and Windows service model

docs/architecture.md

@@ -8,9 +8,19 @@ state and exposes a local control plane to `rvc` and, optionally, JSON-RPC
 callers. This design is the v1 contract for Go implementations and a later Rust
 client implementation.
 
-RVBox deliberately executes arbitrary commands with the identity, permissions,
-and base environment of the client daemon. It is therefore an administrative
-tool, not a multi-tenant remote-execution service.
+The first supported Go client is the Windows service client. The Linux client
+is implemented afterward against the already proven shared runtime/protocol
+and remains a primary v1 target. The server remains Linux-first.
+
+RVBox deliberately executes arbitrary commands under locally selected
+execution identities. It is therefore an administrative tool, not a multi-
+tenant remote-execution service. On Windows the main service runs as
+`LocalSystem` and maps the request's elevation intent plus current login state
+to an effective user/session context. A peer that can successfully impersonate
+the client's routing identity can request elevation, whose fallback may reach
+SYSTEM. This makes the accepted self-reported-identity/network trust boundary
+especially consequential; the explicit elevation bit and tray visibility are
+intent/audit signals, not authorization controls.
 
 Both daemons use strict TOML 1.0 configuration. The normative schema and fully
 annotated examples are in the [configuration contract](configuration.md).
@@ -47,11 +57,11 @@ external access-control layer.
 ## Components
 
 ```text
-rvc -- gRPC/Unix socket -- rvbox-server -- WSS/nginx -- rvbox client -- shell
-                         |       |
-                    SQLite/WAL   +-- optional HTTP JSON-RPC (debug/batch)
-                         |
-               compressed output segment files + audit log
+rvc -- gRPC/Unix socket -- rvbox-server -- WSS/nginx -- rvbox service -- shell
+                         |       |                         |
+                    SQLite/WAL   |                  local named pipe
+                         |       |                         |
+               compressed data  +-- optional JSON-RPC    +-- per-session tray
 ```
 
 `rvc` is a thin control-plane client. The server owns durable command history,
@@ -60,10 +70,18 @@ owns active process supervision, unacknowledged output spooling, and safe
 reconnection. Neither daemon lets a slow peer, command, or output stream block
 its dispatch loops.
 
+On Windows, SCM starts one machine-wide `LocalSystem` service before login. It
+alone owns networking, durable state, logs, command admission, process handles,
+and Job Objects. A separate unelevated tray may run in each logged-in session
+and communicates only through an ACL-protected local named pipe; it is an
+optional frontend and its exit or absence does not stop the service. Task
+Scheduler is not used.
+
 ## Identity, sessions, and lifecycle
 
 1. The client connects over WSS and sends `ClientHello` with its client ID,
-   protocol capability, OS/architecture, daemon version, current daemon CWD,
+   protocol capability, OS/architecture, daemon version, configured daemon CWD/
+   Windows work root,
    supported shells, and a durable random client-instance UUID.
 2. The server accepts the current compatible protocol version, fences the
    previous connection for that ID and same client instance, and returns a
@@ -83,7 +101,8 @@ its dispatch loops.
 
 Each user request has a UUID (`issue_uuid`) and a durable request record: target
 client, request/issue timestamps, shell type, command text or script descriptor,
-CWD, environment overrides, resource-profile flags, and lifecycle state. `rvc`
+CWD, environment overrides, Windows elevation intent and effective execution
+identity, resource-profile flags, and lifecycle state. `rvc`
 normally supplies this UUID as its optional `request_id`; the server generates
 one when it is omitted. Command and mutation identifiers are UUIDv7 values.
 Transport is at-least-once, but the client durably
@@ -160,9 +179,21 @@ client and 10,000 queued commands globally, subject to the stricter byte quotas.
   PowerShell. This avoids transport quoting and Windows command-line limits;
   it never performs shell detection or fallback. Wrapper cleanup follows the
   same terminal rule as uploaded scripts.
-- A command receives the daemon account's permissions and startup environment,
-  overlaid with the persisted `env_overrides` map. The effective CWD is the
-  requested existing directory or the registered daemon CWD when omitted.
+- Unix commands receive the daemon account's permissions and startup
+  environment. Windows interprets the request's `elevated` boolean through a
+  login-aware hierarchy. With a usable active session, normal work uses a
+  deliberately non-elevated `active_user` token; elevated work tries
+  `active_user_elevated`, then `active_system`, then `local_system`. With no
+  usable active session, normal work uses `local_service` and elevated work uses
+  `local_system`. Fallback is allowed only during token selection before
+  `launch_prepared`, never after a process may have started. Requested elevation,
+  attempted contexts, effective token SID, session ID/session-owner SID, and
+  selection detail are persisted in command history.
+- A command receives the base environment for its effective identity, overlaid
+  with the persisted `env_overrides` map. The effective CWD is the requested
+  existing accessible directory when supplied. When omitted it is the registered
+  daemon CWD on Unix or an ACL-isolated identity child beneath that registered
+  root on Windows.
 - Each command is isolated into a process tree: a Unix session/process group or
   a Windows Job Object. A daemon that cannot supervise its children terminates
   them and reports interruption rather than claiming recovery it cannot make.