You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: carry collaboration config in the protocol crate (lockstep) (#35)
Lockstep half of the daemon's "collaboration config on session.create"
(collaborative sessions P1a). CONTRIBUTING requires the Rust protocol crate
to move in the same change set as `packages/protocol/`.
- session.rs: CollaborationConfig + CollaborationRole, camelCase on the wire.
`name` and `provider_id` are plain strings, not enums — the role taxonomy is
data on the daemon side, so a new role like "security-reviewer" must not
need a release of this crate to parse.
- client.rs: optional `collaboration` on ClientMessage::SessionCreate.
- session.rs: optional `collaboration` on SessionInfo.
- app.rs: the TUI's create path passes None — the collaborative create dialog
is a later phase; this only keeps the frame builder compiling.
PROTOCOL_VERSION deliberately NOT bumped. It stays at 1 on both sides. The
change is purely additive (new optional fields), which CONTRIBUTING calls
additive-safe and lib.rs scopes the bump to "any breaking change". Bumping
only this crate would manufacture a version-mismatch warning on every connect
against a daemon that is otherwise fully compatible.
Verified: the existing wire_format camelCase test walks nested objects AND
arrays, so populating the SessionInfo fixture with a two-role collaboration
genuinely asserts `collaboration.roles[N].providerId` serializes camelCase —
it is not a vacuous fixture change.
cargo build + clippy + test green across the workspace (314 tests).
0 commit comments