feat: carry role-child fields in the protocol crate (lockstep) - #36
Merged
Conversation
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).
|
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
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
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 highflame-ai/codeoid#256 (collaboration role-children, P1b). CONTRIBUTING requires this crate to move in the same change set as the daemon's
packages/protocol/.What changed
write: Option<bool>onCollaborationRole.None/false= read-only. The default is load-bearing: the daemon turns it into a leaf identity carrying no write scope plus a hard tool-deny at its fence, so a reviewer provably cannot write rather than being asked not to. Write authority is opt-in per role.CollaborationRoleRef+collaboration_roleonSessionInfo— parent session id, role name, ordinal, write. The mirror ofcollaboration(set on the orchestrating parent), so the TUI can group a fleet without inferring membership from session names.SessionInfofixtures gaincollaboration_role: None.PROTOCOL_VERSION stays at 1
Same reasoning as #35: purely additive optional fields with
#[serde(default, skip_serializing_if = "Option::is_none")]. CONTRIBUTING calls the protocol additive-safe andlib.rsscopes the bump to breaking changes; bumping one side alone would manufacture a mismatch warning against a fully compatible daemon.Verification
cargo build,cargo clippy --all-targets,cargo test --workspaceall green — 354 tests.codeoid-protocol(verified by stashing the change and re-running, not by eyeballing).wire_formatSessionInfofixture now populatescollaboration_role. A real session is either a parent or a child, never both — populated anyway so the recursive camelCase walker visitsparentSessionId/roleNameand would catch arename_allslip on the new struct.Follow-up (not here)
Nothing renders these yet. A read-only child and a writing child look identical in the TUI, and a fleet shows as N unrelated sessions. Surfacing the grouping — and especially the write/read-only distinction, since that is a real capability difference — is worth its own PR against the session list and title.
🤖 Generated with Claude Code