refactor(*): one registry reader and one writer, and the coding agent can add a machine

CHANGELOG.md

@@ -6,6 +6,18 @@ All notable changes to Raven are documented here.
 
 ### Added
 
+- `ops_connection_add` is a trunk tool, served on `tools.connectionAdd`
+  (on in raven-code and raven-oncall, off elsewhere). It writes the machine
+  an owner described into their connection registry after reaching it, with
+  `ssh -G` filling a port, user or key they left out and each candidate key
+  probed on its own (`raven.ops.transport.make_ssh_runner(identities_only=)`).
+  The probe, the writer and the `~/.ssh/config` alias live in
+  `raven.ops.connection_add`, behind both this tool and `raven ops connection
+  add`; the on-call plugin's copies are gone. Raven-Code's guide gains the
+  rule for when to leave this computer at all: write here, verify where the
+  software is, and ask the owner for a machine only when installing the
+  software here would be wrong or heavy.
+
 - Serply joins the `web_search` vendors: `tools.web.search.provider: serply`
   with the key under `tools.web.providers.serply.apiKey` (or `SERPLY_API_KEY`).
   Google SERP rows normalised into the shared render path; the research
@@ -22,6 +34,16 @@ All notable changes to Raven are documented here.
 
 ### Changed
 
+- A sub-agent reads the connection registry in the owner's home
+  (`raven_home()/connections.json`), which the host hands it as `RAVEN_HOME`;
+  any other instance reads the one beside its config first, so a `--config`
+  host keeps its own file. A first write lands in the home. A sub-agent runs on a rendered
+  config in a state directory of its own and is handed `RAVEN_HOME`, not a
+  copy of the file; resolved beside the config alone, Raven-Code read an
+  empty directory while the owner's machines sat one level up, and reached
+  for the raw ssh address instead. The on-call plugin's `connections` module
+  now imports trunk's reader rather than mirroring it.
+
 - Progressive tool disclosure ships on (`tools.toolSearch.enabled`). Below
   `compactionThreshold` (50) nothing changes: the strategy drops `tool_search`
   from every request while the catalog fits. Above it, most tool schemas are

CONTEXT.md

@@ -337,16 +337,20 @@ agents, and nobody registered them; "builtin" — that is the in-process row, wh
 no subprocess and no launcher.
 
 **Machine** (`raven/ops/connections.py`):
-A compute host the owner registered with `raven ops connection add`, held in
-`connections.json` beside the config or wherever `RAVEN_CONNECTIONS` points.
-An on-call-style agent runs its work outside the dispatching Raven
-process — on a GPU box, a lab workstation, another machine entirely — and the
-host's whole part in that is keeping the registry and handing it over: a
-launcher points the agent's `RAVEN_CONNECTIONS` at the owner's store rather
-than copying rows into the agent's own home. Which machine a job lands on,
-and whether it can run at all, is settled inside the agent that runs it.
-Nothing on the dispatch path reads the registry, so no graph and no spawn is
-ever refused over the state of it.
+A compute host the owner registered — with `raven ops connection add`, or,
+since 2026-09-23, with the `ops_connection_add` tool an agent drives from the
+owner's answers in conversation. The registry is the path `RAVEN_CONNECTIONS`
+points at; else, for a sub-agent, the one in the raven home the host hands it,
+and for any other instance the one beside its active config, falling back to
+the home, where a first registration lands. An on-call-style agent runs
+its work outside the dispatching Raven process — on a GPU box, a lab
+workstation, another machine entirely — and the host's whole part in that is
+keeping the registry and handing it over: a launcher points the agent's
+`RAVEN_CONNECTIONS` at the owner's store rather than copying rows into the
+agent's own home, and a sub-agent inherits `RAVEN_HOME` so it resolves the
+same file. Which machine a job lands on, and whether it can run at all, is
+settled inside the agent that runs it. Nothing on the dispatch path reads the
+registry, so no graph and no spawn is ever refused over the state of it.
 _Avoid_: "host" / "server" / "node" (too broad, no link to the
 `ops connection` registry that supplies the rows); "GPU box" (only some are
 GPU hosts, and the term covers any registered compute destination);

agents/raven-code/config.json

@@ -30,6 +30,7 @@
     "exec": {
       "timeout": 600
     },
+    "connectionAdd": true,
     "web": {
       "search": {
         "maxResults": 5

agents/raven-code/plugins/code-flow/prompts/TOOLS_CODE.md

@@ -33,6 +33,32 @@ the host exec instead; follow that tool's stated limits and failure behavior.
   the timeout ceiling; poll its log with `read_file`. Stop the ones that were
   only scaffolding before you finish
 
+## exec on another machine — when, and how a machine gets listed
+
+- Write here when you can. A case, a script, an input deck: this computer
+  writes them. Go to another machine only to *verify* — one short run where
+  the software is — and only when installing that software here is the wrong
+  move: it needs a GPU or memory this box has not (installed here it would run
+  nowhere), or it is heavy to install (a compiled solver, a system toolchain,
+  a download that outlasts the verification itself). A small library that
+  installs in seconds is installed here, and nobody is asked.
+- Before building, name what the task needs to run — GPU, solver, library,
+  memory. If this box lacks it and installing it here is wrong, look at the
+  machines the owner listed: `exec` takes a `machine` id when any is listed,
+  and an unknown id answers with the list and what each machine has installed.
+  Pick the one that has what the task needs, and say which and why.
+- When none fits, or none is listed at all, ask the owner what
+  `ops_connection_add` says to ask — this computer or another, what they call
+  it, an address if another — and hand their answer to that tool. It reaches
+  the machine before writing anything; ssh's own config fills a port, user or
+  key they left out. The owner is asked once: the machine it writes is the
+  one the on-call agent reads afterwards.
+- Never reach a machine by typing an `ssh user@address` from a task statement
+  or a config file, and never put a key path or an address into a command.
+  The way onto a machine belongs to its registry row, below you; `machine=<id>`
+  is how you use it. Could not verify on the machine? Say so in the hand-off,
+  so the first on-call round is a smoke test and not a full run.
+
 ## read_file / write_file / edit_file — paging, reading before editing
 
 - `read_file` returns 2000 lines per call by default. A large file is NOT fully

agents/raven-oncall/config.json

@@ -29,6 +29,7 @@
       "timeout": 600,
       "maxTimeout": 1200
     },
+    "connectionAdd": true,
     "web": {
       "search": {
         "maxResults": 5