Module capability 

Daemon capabilities — what the peer on the other end of the socket can actually do, probed rather than assumed.

Why a capability set and not a version integer

The obvious fix for “a newer client silently degrades against an older daemon” is a protocol version number. It was measured and rejected, for a reason worth keeping written down:

1. It would not have caught the instance that motivated it. args was threaded through three crate::MultiplexerControl methods and the CBOR wire in commit 5974375. The daemon running on the operator’s machine at that moment was tear-0.1.8; HEAD was also 0.1.8. Ten behaviour-changing commits had landed since the version last moved. A version compare would have said “same version, all good” and the pane would still have spawned without its arguments.

2. A version is one scalar for N independent facts. What a caller actually needs to know is not “how old are you” but “do you read the args field”. Those are different questions, and only the second one has an answer that stays true as the codebase moves. A capability names a field or a behaviour, so the refusal lands at the call site that needs it and nowhere else — a caller passing no args is unaffected by a daemon that cannot read them.

The version string is still carried in DaemonHello, because it is genuinely useful in a log line and in tear status. It is not what any decision is made on.

Adding a capability

Add the variant to Capability, give it a wire_name, and classify it in advertised(). The classification is an exhaustive match, so a new variant that nobody decided about is a compile error, not a silently-unadvertised capability.

Structs

DaemonHello

What a daemon advertises about itself, in reply to Request::Hello.

DaemonIdentity

A client’s typed view of the daemon it is connected to.

Enums

Capability

One named thing a daemon build can do. Each variant names a field or a behaviour a caller can gate on — never a release, never a date.