feat: carry collaboration config in the protocol crate (lockstep) - #35
Merged
Conversation
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).
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
KunalJavelin
approved these changes
Jul 26, 2026
saucam
added a commit
that referenced
this pull request
Jul 26, 2026
Lockstep half of the daemon's P1b (highflame-ai/codeoid#250-ish — collaboration role-children). CONTRIBUTING requires this crate to move with the daemon's packages/protocol. - `write: Option<bool>` on CollaborationRole. None/false = read-only; the daemon turns that into a leaf identity with no write scope plus a hard tool deny at its fence, so a reviewer provably cannot write. Opt-in per role. - New `CollaborationRoleRef` + `collaboration_role` on SessionInfo: parent session id, role name, ordinal, write. The mirror of `collaboration` (set on the orchestrating parent), so the TUI can group a fleet without inferring it from session names. - Six SessionInfo fixtures gain `collaboration_role: None`. PROTOCOL_VERSION stays at 1 on both sides, same reasoning as #35: purely additive optional fields, which CONTRIBUTING calls additive-safe and lib.rs scopes the bump to breaking changes. Bumping one side alone would manufacture a mismatch warning against a fully compatible daemon. The wire_format SessionInfo fixture now populates collaboration_role (a real session is either a parent or a child, never both — populated anyway so the recursive camelCase walker visits parentSessionId/roleName and would catch a rename_all slip). cargo build + clippy + test green: 354 tests, no new clippy warnings (7 before, 7 after on codeoid-protocol).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Lockstep half of the daemon change in highflame-ai/codeoid#248 (collaborative sessions P1a). CONTRIBUTING requires this crate to move in the same change set as the daemon's
packages/protocol/.What changed
session.rs—CollaborationConfig+CollaborationRole, camelCase on the wire; optionalcollaborationonSessionInfo.client.rs— optionalcollaborationonClientMessage::SessionCreate.lib.rs— re-export the two new types.app.rs— the TUI'ssession_create_messagebuilder passesNone. The collaborative create dialog is a later phase; this only keeps the builder compiling.SessionInfotest fixtures gaincollaboration: None.nameandprovider_idare plainStrings rather than enums on purpose: the role taxonomy is data on the daemon side, so a new role likesecurity-reviewermust not require a release of this crate to parse.PROTOCOL_VERSION deliberately not bumped
It stays at
1on both sides.CONTRIBUTING says "if you change
codeoid-protocol, bumpPROTOCOL_VERSION", but its very next sentence says the protocol is additive-safe, andlib.rsscopes the bump to "any breaking change." This change is purely additive — new optional fields with#[serde(default, skip_serializing_if = "Option::is_none")].Bumping only this crate would manufacture a version-mismatch warning on every connect against a daemon that is otherwise fully compatible. Happy to bump both sides if you read the rule the other way — it's a one-line change in each repo.
Verification
cargo build,cargo clippy --all-targets, andcargo test --workspaceall green — 316 tests. No new clippy warnings (theresult_large_errones incodeoid-clientare pre-existing).cargo buildalone does not compile tests; the fixture breakage only surfaced under--all-targets.wire_formatcamelCase test walks nested objects and arrays, so populating theSessionInfofixture with a two-role collaboration genuinely assertscollaboration.roles[N].providerIdserializes as camelCase. Not a vacuous fixture edit — arename_allslip on either new struct fails that test.🤖 Generated with Claude Code