Harden daemon service installation

docs/architecture.md

@@ -52,8 +52,14 @@ on macOS, and per-user scheduled tasks on Windows. Geth does not install itself
 as a privileged system service.
 
 The common service lifecycle is available directly as `geth daemon
-install|start|stop|status|uninstall`; the nested service commands remain the
-advanced and compatibility surface. `geth daemon run --ephemeral` creates a
+install|start|stop|status|logs|uninstall`; the nested service commands remain
+the advanced and compatibility surface. Direct installation waits for local
+control readiness. A service executable resolved under a Cargo target or OS
+temporary directory is copied atomically into the selected geth home's `bin/`
+directory before the definition is written, unless the operator explicitly
+allows the transient reference. Service log inspection reads the systemd user
+journal on Linux and user-owned daemon log files on macOS and Windows.
+`geth daemon run --ephemeral` creates a
 temporary home, reports how another CLI process can select it with `--home`, and
 removes it after a normal foreground shutdown. Ephemeral mode still starts the
 same daemon-owned Iroh endpoint and local control stack; it is not a second

docs/roadmap.md

@@ -88,14 +88,26 @@ For deployment-readiness work that cuts across feature areas, see
   - `[x]` Documentation distinguishes automated coverage from real-machine,
     hardware-key, relay, and privileged-interface dogfooding.
 
-- `[ ]` Add unified service-log inspection.
+- `[x]` Add unified service-log inspection.
   Acceptance criteria:
-  - `[ ]` One CLI command gives the platform-appropriate user-service log view
+  - `[x]` One CLI command gives the platform-appropriate user-service log view
     or an exact recovery command on Linux, macOS, and Windows.
-  - `[ ]` Log access remains user-scoped and does not require a system service.
-  - `[ ]` Human and JSON output distinguish unavailable logs, an uninstalled
+  - `[x]` Log access remains user-scoped and does not require a system service.
+  - `[x]` Human and JSON output distinguish unavailable logs, an uninstalled
     service, and an installed service with no log entries.
 
+- `[x]` Verify background-service installation readiness and durability.
+  Acceptance criteria:
+  - `[x]` Direct `geth daemon install` waits for local control readiness by
+    default and reports a log-inspection recovery command on timeout.
+  - `[x]` Service executable paths are canonical regular files; Cargo-target
+    and temporary binaries are copied atomically into the selected geth home by
+    default rather than leaving a fragile service reference.
+  - `[x]` An explicit override supports intentional transient development
+    services, and advanced install can still omit immediate startup.
+  - `[x]` Tests cover transient path detection/copying, file-log states, and
+    user-scoped generated definitions.
+
 - `[ ]` Publish copy-paste installation entrypoints for release artifacts.
   Acceptance criteria:
   - `[ ]` Linux, macOS, and Windows installation instructions verify artifact
@@ -360,6 +372,9 @@ control, local CAS, service installation, and written architecture decisions.
   - Linux install targets a systemd user unit, not a system service.
   - macOS install targets a launchd user agent.
   - Windows install targets a per-user scheduled task.
+  - Direct install verifies local daemon readiness and exposes unified logs.
+  - Transient build artifacts are copied into the selected geth home before a
+    service definition references them unless explicitly overridden.
   - Tests verify generated definitions do not target privileged system services.
 
 - `[x]` GitHub CI, security, and release automation.

docs/user-workflows.md

@@ -39,11 +39,16 @@ geth status
 ```
 
 `daemon install` initializes the selected home if needed, installs and enables
-a service for the current user, and starts it. It never installs a system
-service. Common lifecycle operations are direct:
+a service for the current user, starts it, and waits for local control to become
+ready. It never installs a system service. A binary launched from a Cargo target
+or temporary directory is copied into the selected geth home first, preventing
+later build cleanup from breaking the service. Common lifecycle operations are
+direct:
 
 ```sh
 geth daemon status
+geth daemon logs
+geth daemon logs --follow
 geth daemon stop
 geth daemon start
 geth daemon uninstall
@@ -53,6 +58,9 @@ The older `geth daemon service ...` family remains supported for scripts and
 advanced options. In particular, `geth daemon service install` installs without
 starting unless `--start` is supplied.
 
+If readiness times out, inspect `geth daemon status` and `geth daemon logs`.
+Use `daemon install --no-wait` only when another process owns readiness checks.
+
 ### Keep state but run in the foreground
 
 User story: as a developer, I want persistent state and logs attached to my