Skip to content

feat: carry role-child fields in the protocol crate (lockstep) - #36

Merged
saucam merged 1 commit into
mainfrom
feat/collab-role-child-lockstep
Jul 26, 2026
Merged

feat: carry role-child fields in the protocol crate (lockstep)#36
saucam merged 1 commit into
mainfrom
feat/collab-role-child-lockstep

Conversation

@saucam

@saucam saucam commented Jul 26, 2026

Copy link
Copy Markdown
Collaborator

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> on CollaborationRole. 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.
  • 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 membership from session names.
  • Six SessionInfo fixtures gain collaboration_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 and lib.rs scopes 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 --workspace all green — 354 tests.
  • No new clippy warnings: 7 before, 7 after on codeoid-protocol (verified by stashing the change and re-running, not by eyeballing).
  • 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 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

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).
@gemini-code-assist

Copy link
Copy Markdown

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

@saucam
saucam merged commit a222c63 into main Jul 26, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants