[v0.1/Proto Review] Version ConnectionMode additions through the minor ledger #312

Closed

opened 2026-09-21 12:18:11 +09:00 by natsukium · 1 comment

natsukium commented

2026-09-21 12:18:11 +09:00

Owner

Why

ConnectionMode is a routing discriminator carried in ConnMsg::Hello. Adding a new mode changes which message families the daemon admits, so it is part of the long-lived IPC compatibility surface.

The current minor gate covers ConnMsg::Welcome.identity, but ConnMsg::Hello.mode is not included in felis-protocol/src/minor.rs. ConnectionMode also has no since_minor mapping. The conversion layer rejects unknown enum values, so a newer client that sends a future mode to an older daemon will likely lose the connection without a sender-side MinorTooOld result.

The design documentation says that a new surface should use a new mode rather than reintroducing per-feature bits. That makes mode growth an expected extension path, not an unlikely corner case.

Decision required before v0.1.0

Choose one compatibility policy:

Treat new modes as additive minor features. Add ConnectionMode::since_minor, include the Hello mode in MinorGated, record each mode in the minor ledger, and test mixed-minor handshakes.
Treat any mode addition as a protocol-major change and state that rule explicitly in the IPC design and schema evolution documentation.

The first option is preferable if a future observer, recorder, or headless rendering mode should interoperate with older installations without a coordinated major upgrade.

Acceptance criteria

A test proves that a client cannot send a mode whose minor is above the negotiated effective minor.
A mixed-version test covers an old daemon and a client built with a future mode.
The behavior for an unknown mode is typed and deterministic rather than an accidental decode/connection failure.
The chosen policy is recorded in the reference and explanation IPC documents and enforced by the ledger checks.

Related: #5, #46, #50.

## Why `ConnectionMode` is a routing discriminator carried in `ConnMsg::Hello`. Adding a new mode changes which message families the daemon admits, so it is part of the long-lived IPC compatibility surface. The current minor gate covers `ConnMsg::Welcome.identity`, but `ConnMsg::Hello.mode` is not included in `felis-protocol/src/minor.rs`. `ConnectionMode` also has no `since_minor` mapping. The conversion layer rejects unknown enum values, so a newer client that sends a future mode to an older daemon will likely lose the connection without a sender-side `MinorTooOld` result. The design documentation says that a new surface should use a new mode rather than reintroducing per-feature bits. That makes mode growth an expected extension path, not an unlikely corner case. ## Decision required before v0.1.0 Choose one compatibility policy: 1. Treat new modes as additive minor features. Add `ConnectionMode::since_minor`, include the Hello mode in `MinorGated`, record each mode in the minor ledger, and test mixed-minor handshakes. 2. Treat any mode addition as a protocol-major change and state that rule explicitly in the IPC design and schema evolution documentation. The first option is preferable if a future observer, recorder, or headless rendering mode should interoperate with older installations without a coordinated major upgrade. ## Acceptance criteria - A test proves that a client cannot send a mode whose minor is above the negotiated effective minor. - A mixed-version test covers an old daemon and a client built with a future mode. - The behavior for an unknown mode is typed and deterministic rather than an accidental decode/connection failure. - The chosen policy is recorded in the reference and explanation IPC documents and enforced by the ledger checks. Related: #5, #46, #50.

natsukium added the

priority/P1

release/v0.1.0

type/design

labels

2026-09-21 12:18:18 +09:00

natsukium referenced this issue

2026-09-21 12:18:27 +09:00

[v0.1/Tracker] Close release blockers before v0.1.0 #12

natsukium referenced this issue

2026-09-21 12:23:11 +09:00

[v0.1/Tracker] Close release blockers before v0.1.0 #12

natsukium referenced this issue

2026-09-21 13:02:36 +09:00

[v0.1/Tracker] Close release blockers before v0.1.0 #12

natsukium commented

2026-09-21 13:02:47 +09:00

Author

Owner

Direction agreed 2026-09-21 after three sol design-review rounds (final verdict PASS). Full plan and batch order: see the comment on #12.

#312 — option 1: ConnectionMode::since_minor, Hello.mode in
MinorGated, ledger rows per mode. After #313 every shipped mode is
since=0, so tests use a synthetic future mode.

Direction agreed 2026-09-21 after three `sol` design-review rounds (final verdict PASS). Full plan and batch order: see the comment on #12. - **#312** — option 1: `ConnectionMode::since_minor`, `Hello.mode` in `MinorGated`, ledger rows per mode. After #313 every shipped mode is since=0, so tests use a synthetic future mode.

natsukium referenced this issue from a pull request that will close it,

2026-09-21 13:32:41 +09:00

protocol: version connection modes through the minor ledger #319

natsukium referenced this issue

2026-09-21 14:11:27 +09:00

protocol: terminate a pull-paced grid cycle on the wire #321

natsukium referenced this issue

2026-09-21 14:31:19 +09:00

Resolve attach targets on the daemon, and answer sessions info in one reply #322

natsukium referenced this issue

2026-09-21 14:32:23 +09:00

protocol: terminate a pull-paced grid cycle on the wire #321