[jmacd867]

Closes #276

Summary

relay --tcp <ip:port> [--mirror <ip:port>]        (no options: unchanged, waits for clicks)

start-up    parse options ─ bad ─► print usage, exit 2
              │
              ▼
            keep_connected: connect each output given

every Update tick: retry_outputs
  TCP     no thread and due ─► tcp_connect(target)
            failed attempt   ─► next attempt in RECONNECT_INTERVAL (500 ms)
            live link drops  ─► next attempt at once
  mirror  TCP up, mirror down, due ─► SetMirror(target)   (connects on its writer thread)

Disconnect TCP / Disconnect mirror ─► stop retrying that output
Connect TCP / Connect mirror click  ─► that output is taken over by hand, no retrying

A failed write to the TCP peer now ends the connection and reports it, for clicked connections too. Before, the relay kept writing into a dead socket and still showed it as connected. While retrying, the window shows "waiting for , retrying" with no error banner. The event log gets one line per run of failed attempts, and a line when the output connects.

 relay/src/
+├── cli.rs        # --tcp / --mirror / --help parsing
 ├── main.rs       # parse before iced starts; keep_connected after the IPC connect
 ├── state.rs      # Retry per output, retry_outputs, drop detection on write
 ├── update.rs     # handlers call State methods; + 8 retry tests
 └── view.rs       # "waiting for <addr>, retrying"
 docs/adr/
+└── 0005-the-relay-outlives-the-listener.md
 GLOSSARY.md       # + Instructor, + Listener

This also includes the decision behind the launchers (#278). ADR 0005 says the relay outlives the Listener, because the plugin can't reconnect to a relay that has restarted (#256, #255). The glossary gains Instructor (replacing "operator" in two docstrings and ADR 0004) and Listener.

Evidence

• Before: the 19 new tests fail (cargo test: 25 passed, 19 failed):

  parse(["--mirror", "127.0.0.1:5001"])                 -> refused, names --tcp
  keep_connected(--tcp X); listener on X starts later    -> listener receives a sample, no clicks
  listener on --tcp restarts mid-Flight                  -> relay reconnects, sample arrives
  --mirror starts later / restarts                       -> gets copies; iMotions never held up
  Disconnect TCP / Disconnect mirror                     -> no new attempts
  clicked connection, peer closes                        -> shown as disconnected, not retried
  

  After: cargo test: 44 passed on 3 runs in a row. uv run pytest: 124 passed.
• Smoke run of the release relay.exe on Windows:

  relay --help                       -> usage, exit 0
  relay --mirror 127.0.0.1:5001      -> "--mirror needs --tcp too", usage, exit 2
  relay --tcp 127.0.0.1:5078, listener started 3 s later
                                     -> PASS  relay connected 0.8s after the listener started
  

Not verified: anything with the plugin, X-Plane, real iMotions or the lab PCs.

Merge Danger

Door: two-way

Without options the only change in behaviour is that a TCP connection whose other end has gone is now shown as disconnected. Before, it stayed "connected" in name only. Reverting the PR restores the old behaviour.

Blast Radius: relay

• The relay now detects a dead peer only on a write, so if the Listener restarts before X-Plane is sending, the first packet after that is lost.
• When X-Plane quits (BatonShutdown), a relay started with --tcp reconnects by itself. The README says so.
• A remote iMotions PC that vanishes without closing the connection still blocks writes, as before this PR.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud