docs: TEMPORARY remote-site access for felhom-pve (tailnet) — see AUDIT-vacation-remote-ops-2026-07-20

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Nhk3eBHT8Mg5L8c2aj57aU

CLAUDE.md

@@ -92,6 +92,19 @@ available to CC as plain `ssh felhom-pve`. The agent pins the served leaf cert
 fingerprint still matches before a live run. Selftest modes (run locally on DooPlex, pointed at the
 demo API): `--selftest[=read|task|hub|storage|backup|restore-test|pbs-verify]`; no flag = the daemon.
 
+> **TEMPORARY — felhom-pve is at a remote site (until ~2026-08-02).** The home-LAN literal
+> `192.168.0.162` is NOT reachable from DooPlex for the duration. Access via Tailscale:
+> felhom-pve = 100.70.170.35; the `Host felhom-pve` entry in `~/.ssh/config` on DooPlex already
+> points there (the direct-LAN path stays available as `Host felhom-pve-lan`). Delete this block on
+> return. All documented `ssh felhom-pve` / `pct exec` workflows are unchanged. Path is **direct**
+> (not DERP), ~37 ms rtt per hop. At the remote site the host is on **DHCP** and currently holds
+> `192.168.0.147` — so the PVE API is at `https://192.168.0.147:8006` there, and **the agent does
+> not run at all**: `localapi` binds the literal `192.168.0.162` → `bind: cannot assign requested
+> address` → the service is `failed` and has never started at the remote site. Fixing it means
+> editing `listen_addr` in `/etc/felhom-agent/agent.json` **and** the guest's bootstrap endpoint
+> (plus the leaf-cert SAN the controller pins) — Viktor GO required. Details + findings:
+> `felhom.eu/documentation/audits/AUDIT-vacation-remote-ops-2026-07-20.md`
+
 > **Legacy: Windows workstation.** Until 2026-07-19 CC ran on Windows 11; `pct` commands over SSH
 > needed `export MSYS_NO_PATHCONV=1`, and every remote command used
 > `SSH=/c/Windows/System32/OpenSSH/ssh.exe`. Agent deploy was a two-hop copy via the Windows box

CONTEXT.md

@@ -5,6 +5,17 @@
 
 ## Current
 
+- **2026-07-20 — REMOTE SITE until ~2026-08-02; the agent is DOWN there and cannot self-recover.**
+  felhom-pve moved off the home LAN; `ssh felhom-pve` = tailnet `100.70.170.35` (direct, ~37 ms). The
+  host is on DHCP and holds `192.168.0.147`, so `localapi`'s literal `192.168.0.162` bind fails with
+  `bind: cannot assign requested address` — the daemon exits ~1.1 s after start, systemd gave up after
+  4 retries, and a manual restart reproduces it exactly. Deployed binary is **0.90.0**. Fix needs
+  `listen_addr` in `/etc/felhom-agent/agent.json` **and** the guest bootstrap endpoint (plus the
+  pinned leaf's SAN) → **Viktor GO**; re-pinning to another literal just re-breaks on the next lease.
+  Also re-observed each start: `pbs: cannot read token secret … /etc/pve/priv/storage/felhom-pbs.pw:
+  permission denied` (R-39-adjacent). Evidence + ranked findings:
+  `felhom.eu/documentation/audits/AUDIT-vacation-remote-ops-2026-07-20.md`
+
 - **v0.90.0** (2026-07-17) — **agent train: guest RAM resize (R-24) + fast-tick (R-28); LIVE on BOTH
   demo hosts (felhom-pve + nested demo-vm-felhom-4846bc).** MinAgent coupling: felhom-controller
   v0.143.0 gates its resize UI on this agent. (1) **R-24 guest RAM resize (controller-direct)** —