1 changed files with 70 additions and 0 deletions
@@ -220,3 +220,73 @@ Orchestra, which supplies identity and policy inputs.
 Roughly 10 to 20 real tasks, with the five flows covered on each harness that
 is actually up. Then read the classified failures and decide the next
 implementation unit from them.
+
+## Live findings, 2026-08-26 21:35
+
+Both halves are paired at `6f9300b`, and herdr is up (0.7.5, protocol 17). What
+remains before flow 1, and what the in-pane credential checks will really show.
+
+### Flow 1 has no repository to run in
+
+`workpc-opencode` declares exactly one project, `test-e2e`, pointing at
+`/tmp/test-e2e` and `/tmp/test-e2e-worktrees`. Neither path exists on workpc
+after today's reboot, and `/var/lib/orchestra/repos` does not exist there at
+all. Nothing can be leased to this harness until it has a project backed by a
+durable local repository.
+
+The only configured task source is Gitea `kami/correx` at
+`https://gitea.kvmx.ru` (`ORCHESTRA_GITEA_URL/OWNER/REPO`), so a real task means
+a `correx` issue. `correx` already has `machine_affinity: ["homesrv","workpc"]`
+in the coordinator's `config.jsonc`. What is missing is a workpc-local entry:
+
+```jsonc
+// /etc/orchestra/worker-projects.json, on workpc
+{
+  "correx": {
+    "repo": "/home/kami/orchestra/repos/correx.git",
+    "worktree_root": "/home/kami/orchestra/worktrees/correx",
+    "remote": "origin"
+  }
+}
+```
+
+Not `/tmp`. The burn-in outlives a reboot.
+
+### There is no vikunja ingest
+
+This repo has no Vikunja provider. `/readyz` reports `gitea` and `jsonl`. A
+"real vikunja task" cannot enter Orchestra today: it arrives as a Gitea issue or
+through the JSONL watcher.
+
+### `git push` from a pane will succeed, and no Orchestra setting stops it
+
+Panes run as `kami`, the same user as the worker, and `kami` has
+`credential.helper store` set globally. An agent in a herdr pane therefore
+inherits a usable Gitea credential over HTTPS. `worker.env` is irrelevant to
+this. Real isolation needs panes under a different unix user, or a credential
+store the pane cannot read. Expect `git push --dry-run` to succeed and record
+that as an operator-policy gap, not a code defect.
+
+### The agent surface is currently unauthenticated
+
+`ORCHESTRA_AGENT_TOKEN` is unset on the coordinator, and an unset surface token
+means the middleware performs no check for that surface. Probed live:
+
+```
+POST /v1/tasks/<id>/decision-request  -H 'X-Orchestra-Surface: agent'  -> 404 (reached the handler)
+POST /v1/tasks/<id>/phase             -H 'X-Orchestra-Surface: agent'  -> 403 (refused)
+```
+
+The capability boundary holds. Authentication does not. Set
+`ORCHESTRA_AGENT_TOKEN` in the coordinator `.env` before the burn-in, and note
+the same is true of `ORCHESTRA_MCP_TOKEN` and `ORCHESTRA_MAVEN_TOKEN`, both
+unset.
+
+### Two more unset settings that change burn-in behaviour
+
+- `ORCHESTRA_FEDERATION_ADMIT_TOKEN` is unset, so any caller may register a new
+  worker identity. Existing identities stay protected, because registering an
+  existing id with a different token is refused.
+- `ORCHESTRA_REVIEW_ACTORS` is unset, which `human.Trust` reads as "anyone not
+  explicitly ignored". Flow 4 will accept a task-moving comment from any Gitea
+  actor. Set it to `kami`.