Measured network provenance in state: loopback and own-host traffic judged like exfiltration (curl localhost, ssh raw-ovh)

Start in index.ts and trace the gate's classification path before the battery is asked, including how command URLs, SSH configuration, /etc/hosts, and Docker port or network state are available. Define the measured localPorts, knownHosts, and dockerNetworks state, then trace the sends_local_data_outbound and contacts_remote_endpoint criteria. Done means those criteria can distinguish local or user-owned destinations without treating destructive SSH command bodies as safe.

Problem

curl http://localhost:8000/… and ssh raw-ovh … are the two most common network false-asks in the decisions log (declared scope contradicts command (network)), and the Jev port has no fix for either: the model still has to guess intent from the command text.

Log, 2026-09-09 to 2026-09-17 (197 blocks carry this class):

• curl -s http://localhost:8000/…, curl -s http://localhost:3111/health, curl -s -b jar http://localhost:8000/my-garage/ — loopback probes of the user's own dev server (the local WordPress running under docker compose in this repo). This machine talking to itself over loopback is a local read; the model reads curl http://… and sees an outbound network write.
• ssh raw-ovh 'wp db query "SELECT …"', ssh raw-ovh 'ls /tmp', ssh raw-ovh 'mysql --version' — the user's own named deploy host carrying read-only inspection. raw-ovh is the user's own production box in this environment, but the model has no way to know this.

Measured weight: this class is ~6% of all blocks in the window and cannot be fixed by prompt editing — the state carries no network provenance for a called host, so every command that happens to use a remote-looking URL gets judged by vibes.

Proposal

Give the state a measured network-tier field the gate produces at classification time, before the battery is asked. Keep it dumb and local-only: the gate does not need to classify the reachable internet, it needs to name the destinations the command talks to and what kind they are.

Fields to derive in index.ts, keyed off the command's own textual URLs/hosts plus process context:

• localPorts — ports on loopback (127.0.0.1/localhost/::1).
• knownHosts — hosts the user's own SSH config, /etc/hosts, and running-docker-port state name (this catches raw-ovh, which lives in SSH config).
• dockerNetworks — when the command targets a compose service (docker compose exec db …) or docker-published port, whether that service resolves inside the local Docker network.

The criteria for sends_local_data_outbound and contacts_remote_endpoint can then say what to do with these: loopback to a process the user owns (the local dev server, a local API) is the machine reading itself; an SSH alias resolving from the user's own config to the user's own host is the user's own machine, not an exfiltration target. Both of those criteria sentences already gesture at it ("the service that issued it", "the destination that has no business holding it") but have no field to point at.

Trust constraint, same as omp-classifier#63: these are measured by the gate, not reported by the caller. The gate reads SSH config, /etc/hosts, and docker port from the same machine the command will run on. That's what makes the "this is your own host" sentence something the battery can rely on.

Non-goal

Not asking to trust raw-ovh as safe generally: the criteria change still treats ssh <user-alias> <destructive-cmd> as destructive on its command body, not its hostname. Interest is in the host tier, not blanket allow of ssh.

Related

• Measured false-asks this would fix: all curl http://localhost:… in the log (docker compose-managed WordPress dev server), all ssh raw-ovh '<read-only>' in the log, docker compose ps|logs|exec against the local dev stack.
• Same measured friction family as omp-classifier#63 and #64: the three together cover the top-4 named block classes in the log window 09-09 to 09-17.