A2A roster reconciliation — laptop roster vs live LAB listener table (Tam, 2026-10-21)

• date: 2026-10-21
• tags: a2a, roster, ports, tunnels, dialect, pulse, lab
• status: verified (live probes, both tiers)
• source links: laptop ss -tlnp · LAB ss -tlnp · cortex/registry/agents.yaml · LAB profile a2a: blocks · /.well-known/agent-card.json probes · kanban t_0dd31a73 · kanban t_6785e6c8 (tunnel service verification, §8)
• related: Docs/Fleet/05-operations/a2a-connectivity-audit-2026-10-20 · 2026-10-03-a2a-roster-of-record

What changed

The two dead pins in the eva laptop profile are fixed: eve: 127.0.0.1:19902 → 8442 and atlas: 127.0.0.1:18306 → 18303. 19902 and 18306 had no laptop listener, no tunnel forward and no LAB listener — provably dead. Everything else in tam/eva/eve was already correct through the tunnel; the priors in the task card that called them stale were wrong (section 4 below).

1. Verified port map (LAB listeners + tunnel + Pulse doors)

Tunnel owner: one ssh process (lab@192.168.4.60, pid 4073194 under autossh 4073178) holds every forward: 18301→8301 · 18302→8302 · 18303→8303 · 18304→8315 · 18305→8314 · 18311→8311 · 18312→8312 · 18313→8313, legacy aliases 8304→8315 · 8305→8314, reverse 18441/42/43→laptop 8441/42/43. Reverse round-trip re-verified from LAB: 18441/42/43 return Eva/Eve/Tam by name.

2. Dialect — v1.0 is now enforced fleet-wide

The fleet's own client (plugins/platforms/a2a/tools.py) sends method: "SendMessage" with header A2A-Version: 1.0 (PROTOCOL_VERSION = 1.0).

Live probe of every door with lowercase message/send returns: -32600 "'message/send' is a v0.3 dialect name and v0.3 compat is OFF (ruled 2026-10-10). V3 speaks 1.0 only. Call 'SendMessage' instead."

• Heart (8301-8303): v1.0 dialect guard, SendMessage/GetTask.
• Pulse doors (8441, 8442, 8443): v1.0 dialect guard — same rejection.
• Brain (8311-8315, hence the 1831x forwards): plain JSON-RPC that accepts SendMessage and answers tasks/get as well.

Practical rule: always SendMessage + A2A-Version: 1.0. A lowercase message/send now fails everywhere, on every tier.

2b. Identity criterion — "answers with its OWN name", not "answers"

Per Eva's follow-up probe (2026-10-21 13:50), reachability is not the acceptance criterion: a reachability probe passes while an identity probe fails. Applied here in two layers.

Functional identity (authoritative) — SendMessage "reply with your agent id and unit", each peer answered as itself:

Every configured peer therefore routes to its own identity; nothing is crossed. Heart (Ace/Alpha/Atlas) and Pulse (Eva/Eve/Tam) also carry their own names on /.well-known/agent-card.json.

Residual defect — Brain agent cards are generic (Brain lane, NOT a roster problem). GET /.well-known/agent-card.json on 8311-8315 all return name: "hermes-LAB" with the stock description. Cause is exact: plugins/platforms/a2a/adapter.py:275 sets self.agent_name = _default_agent_name(), which reads only env A2A_AGENT_NAME else hermes-{hostname} (hermes-LAB). The per-profile key platforms.a2a.extra.agent_name — already present in min*/mira/sol/nova/echo profiles — is never read by this build. So a card-name check cannot tell the five Brain agents apart; identity is only obtainable from the port/profile binding or a functional probe. Fix options for Sol: (a) one line in the adapter — self.agent_name = extra.get("agent_name") or _default_agent_name() — then add agent_name: min for min, which has none; or (b) declare a2a_served_agents with per-agent name (supported by _load_served_agents, no code change). Both need the LAB hermes gateway restarted, which would interrupt all five Brain agents — schedule it, do not hot-patch mid-run.

3. Identity verification method (reusable)

• GET /.well-known/agent-card.json (note: agent.json 404s — the fleet serves the v0.3+ filename) → names Heart and Pulse agents directly; Brain returns the generic hermes-LAB card, so resolve those from LAB profiles/*/config.yaml a2a: port: + cortex/registry/agents.yaml, or by functional probe.
• Side-effect-free liveness: POST GetTask for a nonexistent id → -32001 TASK_NOT_FOUND proves the door is live and speaking v1.0 without starting an agent turn.
• Authoritative identity test: SendMessage "reply with your agent id and unit". It costs one peer turn and blocks until the turn completes (a busy peer exceeds a short timeout — retry once with a longer window before calling it a failure; echo needed 150 s on the first attempt today). Use GetTask for cheap liveness, SendMessage when identity is the question.

Config edits hot-reload: load_config() caches on (mtime_ns, size), so the eva roster fix is live at the next call — no gateway restart needed.

4. Corrections to the priors in the task card

• "echo configured to 18304 but listener on 8315" — not a gap. 18304 is the laptop forward for LAB 8315; the pin is correct through the tunnel.
• "nova at 18305 dead" — no longer true. Nova serves LAB 8314 and 18305 forwards to it; probe answers.
• "tam config atlas at 18303" — correct. 18303→8303 and the card there says "Atlas", not "Ace".
• "tam-tunnel connection-refused churn" — initially not reproduced; reproduced later the same day and root-caused: it is per-request far-end failure of the down prod registry lane, not tunnel breakage (§8).

5. Correction to Mira's 2026-10-20 audit (cross-lane, reported to Min)

Docs/Fleet/05-operations/a2a-connectivity-audit-2026-10-20.md states Pulse runs the v0.3 dialect (message/send) and recommends "Echo: to reach Tam, use message/send not SendMessage". As of today that advice is inverted and would fail: all three Pulse doors enforce v1.0 and reject message/send outright. That audit also lists 8304/8305 as stale Heart listeners — they are now serving as legacy aliases for Echo (8315) and Nova (8314) through the tunnel. Flagged to Min for Mira to correct in her lane; not rewritten here.

6. Open items

• Brain card identity (§2b) — Sol's lane. Cards on 8311-8315 are all hermes-LAB; one-line adapter fix + agent_name: min, or a2a_served_agents. Needs a scheduled LAB hermes gateway restart (interrupts all Brain agents). Roster routing itself is verified correct, so this blocks discovery, not messaging.
• Central registry unreachable: laptop 8433/8434 (→ prod 8432/8434) return HTTP 000, so the POST /reports visibility lane is down (prod-side services, consistent with the known 8432/8434 dead zone). Reported in the kanban completion instead.
• systemd tunnel unit state, restart resilience and the 19100→9900 gateway forward — verified in §8 (child card t_6785e6c8's run).
• Heart/Pulse cards carry real names; Brain cards should be named per profile so a card probe alone identifies the agent — see §2b for the exact fix.

7. Method

Every claim above came from a live probe this session: ss -tlnp on both hosts, curl against each listener, git/file reads on the LAB vault, and a Python YAML re-parse of eva's edited config. Nothing was taken from an earlier note without re-measuring — the task's own priors were wrong in three places.

8. Tunnel service verification — t_6785e6c8 run (2026-10-21 ~17:07 AEDT)

The child card's remaining lane: systemd unit state, restart resilience, the 19100→9900 forward, and the tam-tunnel refused churn the card flagged.

Unit inventory (all live). Seven units on pulse. User level: lab-mesh-tunnel (autossh 4073178 / ssh 4073194, up ~45 h, holds every roster forward), laptop-tunnel, tam-tunnel, lab-a2a-tunnel, a2a-relay; system level: eva-a2a-tunnel, laptop-reverse-tunnel. All seven: ActiveState=active, Restart=always, enabled, and Linger=yes for eva — boot persistence proven by config. Note for future audits: these are user units; a plain systemctl show reads the wrong scope and reports Restart=no / inactive dead for healthy services. Query systemctl --user.

Restart resilience, live-tested. systemctl --user restart lab-a2a-tunnel → fresh PID, and 2 s later the 19100 door answers (HTTP 401 auth challenge from the LAB A2A gateway through the forward). The 19100→9900 forward is therefore alive end-to-end (GetTask through it returns -32050 unauthorized — the JSON-RPC request reaches the gateway; auth is a separate, expected gate). Unit enabled, Restart=always, running since Oct 20 21:47.

Mesh lane functional identity re-verified through the tunnel.SendMessage "reply with your agent id and unit": 18304 → "Echo — Brain (Research & …)", 18311 → "Min — Orchestrator, SolOS Brain Unit"; both TASK_STATE_COMPLETED.

tam-tunnel refused churn — root-caused (supersedes §4's first reading). The unit is the PROD lane: -L 8433→prod:8432 · -L 8434→prod:8434 plus -R doors 9906/8447 back to laptop, target ubuntu@161.33.71.67. The user journal showed 3,422 channel 2: open failed: Connection refused lines in 24 h, still firing at 17:03. Causality proven by delta: poking 8433 and 8434 once each produced exactly 2 new refused lines. The churn is per-request far-end failure — prod 8432/8434 (central registry / registry-MCP) are down and external callers keep hitting the dead lane — not tunnel breakage. The tunnel itself is healthy: local listeners bound, prod sshd binds 9906/8447, unit stable since Oct 16, Restart=always/10 s. (Process note: my earlier card comment "not observed today" was a journal-scope mistake — system journal instead of --user. Corrected here.)

Prod-side -R doors dead-end at the laptop. From prod, curl 127.0.0.1:9906 and :8447 → HTTP 000. Both -R forwards target laptop ports 8447/8448, which have no local listener — they belong to the down prod central-services stack (same dead zone as 8432/8434/8436). No established consumers seen on prod. Restore path = Sol restoring the prod services; the doors light up with no tunnel changes.

mesh 8312 bind-in-use race: closed. Zero occurrences in the last 24 h; a single ssh process (4073194) owns every forward.

Flap history is historical, not current. laptop-tunnel counts 2,095 restarts in 7 days — all from an Oct-18-and-earlier startup race: ExitOnForwardFailure=yes plus a remote -R 8448 bind still held by the sibling tunnel → exit → 10 s loop; self-limiting, last occurrence Oct 18 13:20. The current laptop-tunnel unit no longer requests 8447. tam-tunnel's flap loop ended Oct 16 15:41. Both units stable 3–5 days since.

Verdict for t_6785e6c8: tunnels UP and reserved for the Pulse lane, proven end to end — identity probes through the mesh, gateway probe through 19100, reverse doors LAB→laptop, restart + boot persistence verified. Stale refs 19902/18306 absent from every laptop profile. The one remaining dead zone is prod-side services (8432/8434/8436, doors 8447/8448) — Sol's lane.