Record the pane-environment and herdr findings that block flow 1

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

AUDIT.md

@@ -363,3 +363,31 @@ one deployed.
 
 Not done, and both need root: the `/etc/orchestra/worker.env` scrub (mode 0600,
 root-owned) and its in-pane verification. No agent should run before that.
+
+## Pane environment and the opencode backend, probed 2026-08-26 18:45
+
+Three findings, all blocking flow 1, none of them code defects in this session's
+work.
+
+- **herdr is not running on workpc.** `herdr status server` reports `not
+  running`; the socket refuses connections and its log stops at 2026-07-30.
+  `workpc-opencode` cannot start a pane. Note that the worker logs `serving
+  harness workpc-opencode (opencode) on herdr backend` at startup **without
+  touching the socket**, so that line is not evidence of reachability. Same
+  shape as the older note about the coordinator never logging a herdr success:
+  absence of an error is not evidence here either.
+- **The two workpc harnesses inherit different environments.** An opencode pane
+  is created by the herdr daemon and inherits *herdr's* environment, so scrubbing
+  `/etc/orchestra/worker.env` does not affect it. A claude pane comes from
+  `TmuxBackend.StartAgent`, which runs `tmux new-session` via
+  `exec.CommandContext` with no `Env` set, so the tmux server inherits the
+  worker's full environment and every pane under it does too.
+- **The scrub alone cannot close the tmux path.** The worker needs
+  `ORCHESTRA_WORKER_TOKEN*` and `ORCHESTRA_FEDERATION_ADMIT_TOKEN` to function,
+  and the pane inherits exactly those. Closing it needs a filtered `cmd.Env` in
+  the backend, or a tmux server started separately with a clean environment.
+  Deliberately not built now: flow 1 is opencode only, and the burn-in order
+  puts claude at step 6.
+
+Sudo is not available in this sandbox, so the worker install, the restart, and
+the `worker.env` scrub remain operator steps.