DoorRemoteSessions

The remote sessions of a door host, both ways (trove-parts §TPL-3, §TPN-11).

In the namespace octomy::trove::door. Declared in src/libs/libtrove/trove/door/DoorRemoteSessions.hpp.

Detailed description

One host object per remote session

A RemoteDriverHost served one driver that existed before the peer opened a session, so it could not resume a provider session (parity TPX-46). serve() puts a RemoteSessionServer on the courier instead. It makes a driver from each `open` with makeDriver(), and binds one host object to that one session.

The folder comes from the origin

A portable session job names the project's origin and the lane's branch (§TPL-2). makeDriver() clones the origin into checkoutRoot() once, fetches it for each session, and works in a worktree of the branch. One origin and branch always give the same folder, so a resumed session finds its files and its transcript.

The spec database and the commits stay with the other node

The `trove` tool in a remote session calls the door of this node, and names its working folder in the envelope (§TPD-6). The spec database that holds the session's work unit is the other node's. So forward() sends a `spec.*` call from a session's folder to that node over the control plane, adds the session's client identity (trove-spec-db §NET-3a.2), and gives back the answer of that node. A call from any other folder runs here, as before.

The origin is the one channel between the checkouts of the two nodes. After each completed turn, this node pushes the session's branch to the origin, off the thread of the door host, and only then lets the other node learn that the turn ended. The other node fetches the branch when its job completes (§TPL-5). The rule "never push" of CLAUDE.md is the rule of the session, not of this node.