docs: defer Unix client implementation within v1

docs/architecture.md

@@ -10,7 +10,10 @@ client implementation.
 
 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.
+and remains required for the complete v1 scope. It is explicitly deferred from
+the current implementation effort: implement the Linux server and native
+Windows client first, and do not begin Unix-like client implementation yet. The
+server remains Linux-first.
 
 RVBox deliberately executes arbitrary commands under locally selected
 execution identities. It is therefore an administrative tool, not a multi-

docs/implementation-plan.v1.md

@@ -12,13 +12,14 @@ binaries:
 - `rvc`: local CLI over the server's Unix-domain gRPC socket.
 
 The first supported client target is Windows connecting to a Linux server;
-Linux client support follows and remains a primary v1 goal. Build shared client
-runtime code behind OS interfaces, but complete and exercise Windows process
-management, diagnostics, resource controls, desktop hosting, and native CI
-before beginning the Linux supervisor. Windows v1 requires Windows 10 or newer,
-or Windows Server 2016 or newer. Desktop Experience is required only for the
-tray and active-session command contexts; the service and Session 0 execution
-contexts support headless Server Core.
+Linux client support remains part of complete v1 but is explicitly deferred
+from the current implementation effort. Implement the Linux server and native
+Windows client first; do not begin Unix-like client code now. Build shared
+client runtime code behind OS interfaces without prematurely implementing the
+Unix supervisor. Windows v1 requires Windows 10 or newer, or Windows Server 2016
+or newer. Desktop Experience is required only for the tray and active-session
+command contexts; the service and Session 0 execution contexts support headless
+Server Core.
 
 The released `rvbox.exe` is one signed binary with explicit SCM-service, tray,
 installer/configurator, per-command launcher, and signal-helper modes.
@@ -1266,8 +1267,9 @@ version. Assert no Task Scheduler object is created or required.
 **Exit criteria:** the native Windows client can stay alive through server
 loss/restart, execute up to capacity at most once, preserve/replay bounded
 history, manage complete Job trees, and satisfy tray/elevation/autostart behavior
-on Windows CI, including all execution-hierarchy rows. Do not begin the Linux
-supervisor phase until this gate passes.
+on Windows CI, including all execution-hierarchy rows. Reaching this gate does
+not automatically start the deferred Unix-client work; that requires an explicit
+later implementation decision.
 
 ## 8. End-to-end agent protocol (Phase 5)
 
@@ -1451,11 +1453,16 @@ structured RVBox detail as gRPC.
 stack; the Unix socket has mode `0600`; JSON-RPC behavior matches gRPC unary
 semantics and is off unless explicitly enabled.
 
-## 10. Linux client implementation (Phase 7)
+## 10. Deferred Linux client implementation (Phase 7; still required for full v1)
 
-Begin this phase only after the Windows Phase 4/5 release gates pass. Keep Unix
-code in platform-specific files/build tags and reuse the proven runtime/store/
-protocol contracts without changing their wire semantics to suit Linux.
+This phase is design-only in the current effort. Do not implement it now. Retain
+these tasks so the later Unix-client work completes the already defined v1
+contract without weakening the shipped Windows behavior.
+
+Begin this phase only after both an explicit later implementation decision and
+the Windows Phase 4/5 release gates. Keep Unix code in platform-specific files/
+build tags and reuse the proven runtime/store/protocol contracts without
+changing their wire semantics to suit Linux.
 
 The Unix supervisor starts an RVBox launcher as leader of a new session/process
 group; after authorization the launcher creates the selected `sh`/`bash` child
@@ -1589,7 +1596,7 @@ recovery and retention behavior.
 
 ## 12. Release gates and implementation order
 
-The recommended merge order is deliberately vertical:
+The currently authorized merge order is deliberately vertical:
 
 1. Phase 0: Docker-first repository/toolchain/proto generation.
 2. Phase 1: domain/config validation and state machine.
@@ -1600,8 +1607,12 @@ The recommended merge order is deliberately vertical:
 6. Phase 5: full WSS protocol and fault injection from native Windows to the
    Compose-hosted Linux server/nginx stack.
 7. Phase 6: gRPC Unix socket, `rvc`, and optional JSON-RPC.
-8. Phase 7: Linux supervisor/cgroup implementation and Linux client parity.
-9. Phase 8: operational assets, stress/fuzz/recovery testing, release review.
+8. The Windows-applicable Phase 8 operational, packaging, stress, and release
+   gates needed for the Linux-server/Windows-client milestone.
+
+Stop there for the current effort. When Unix-client implementation is explicitly
+started later, continue with Phase 7 (Linux supervisor/cgroup and client parity),
+then the remaining Phase 8 Unix operational/release gates to complete v1.
 
 Do not merge a later vertical slice by stubbing a durability/safety invariant.
 For example: foreground mode may wait on a durable background command, but must
@@ -1609,10 +1620,12 @@ not bypass persistence; client output may be truncated under the documented
 caps, but must never block a child pipe; and a reconnection may replay work,
 but may never re-execute an already accepted UUID.
 
-The Windows-client milestone is releasable only after Phases 0–6 plus its
+The current Windows-client milestone is releasable only after Phases 0–6 plus its
 applicable Phase 8 packaging/security gates pass on native Windows and a clean
 Linux server environment. Windows support cannot be marked optional or replaced
-by cross-compilation-only checks. Full v1 is ready after the later Linux client
-also passes the common protocol/durability suite and Linux-specific cgroup/
-process tests. Every release must conspicuously document self-reported identity,
-the elevated Windows execution authority, and unauthenticated optional JSON-RPC.
+by cross-compilation-only checks. Stop the current implementation effort at that
+milestone; Phase 7 remains deferred until explicitly started later. Full v1 is
+ready only after that later Linux client also passes the common protocol/
+durability suite and Linux-specific cgroup/process tests. Every release must
+conspicuously document self-reported identity, the elevated Windows execution
+authority, and unauthenticated optional JSON-RPC.

docs/platform-and-operations.md

@@ -4,9 +4,10 @@ Daemon configuration uses strict TOML as specified in
 [`configuration.md`](configuration.md); the annotated examples contain every
 v1 knob and default.
 
-The implementation order is Windows client first, Linux client second. The
-sections below describe both final contracts; their document order does not
-override that release gate.
+The current implementation scope is the Linux server plus Windows client. The
+Unix-like client remains part of complete v1 but is deferred and must not be
+implemented yet. Its section below preserves the agreed future v1 contract; the
+document order does not authorize or reprioritize that work.
 
 ## Unix-like clients