Last lesson, the mesh passed every test under vitest. Every message branch ran, and not one byte crossed a real network. But a tested transport only moves bytes. The browsers are connected now, yet the game still has no idea anyone else is at the table. A fold on seat 2's screen has to become seat 2's turn on yours. Here's the catch: PokerTableDirector, the match director that ran the solo table, must never learn it went online.

It won't have to. The single-player table already runs on intent from the EventBus. poker.turnAction goes into PokerBetting, and poker.actionTaken comes back out to the director. None of that code can tell where the intent came from. It could be a local NPC or a peer far across the network. This lesson builds the bridge that lets the wire speak the bus's language.

One entity, two components

Add a Net entity to the running scene's entities. It holds two components. The first is P2PNetwork, the game-agnostic mesh that owns the WebRTC connection and speaks generic net.* traffic. The second is PokerMultiplayer, the poker translator that turns that traffic into table intent:

"Net": {
  "components": {
    "P2PNetwork": {
      "roomCode": "table-7",
      "mySeat": 0,
      "myPlayerId": "seat-0",
      "occupiedSeats": [0, 1, 2, 3],
      "autoConnect": false
    },
    "PokerMultiplayer": {
      "roomCode": "table-7",
      "mySeat": 0,
      "occupiedSeats": [0, 1, 2, 3],
      "handNumber": 0
    }
  }
}

Every value here is a placeholder. At boot, lesson 4's buildNetConfig split overwrites roomCode, mySeat, and occupiedSeats. The autoConnect: false setting keeps P2PNetwork from opening a real mesh the instant the scene loads. The bootstrap turns that on once you've actually joined. This split is what makes the design work: P2PNetwork never mentions poker, and PokerMultiplayer never touches an RTCPeerConnection. They meet only on the bus, through net.*.