Conversation
Implement observation-only team state tracking for Claude Code's agent teams protocol. Derives TeamState from the SDK message stream using a pure reducer pipeline: recognizer → correlation buffer → state reducer. Key components: - team-types.ts: TeamState, TeamMember, TeamTask, 8 TeamEvent types - team-tool-recognizer.ts: recognizes 7 team tools with compound discriminator for Task tool (requires both team_name and name) - team-tool-correlation.ts: buffers tool_use↔tool_result pairs (30s TTL) - team-state-reducer.ts: idempotent pure reducer for team state - session-bridge.ts: per-session correlation buffers, team event emission - events.ts: 8 bridge events (team lifecycle, members, tasks) All reducer operations are idempotent for reconnection replay safety. Backward compatible: agents[] field populated from team.members. 189 new tests, 0 regressions.
Summary of ChangesHello @teng-lin, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request integrates comprehensive agent team observation capabilities into BeamCode. It establishes a robust, observation-only mechanism to track the dynamic state of agent teams, their members, and tasks by processing the SDK message stream. The design emphasizes pure functions, idempotency, and resilience against context compression, while also providing clear eventing for consumers and maintaining compatibility with existing structures. Highlights
Changelog
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This is an excellent pull request that adds comprehensive support for observing agent teams. The changes are well-structured, following a clear implementation plan. The introduction of pure reducers, a correlation buffer, and new message types is well-thought-out. The code is accompanied by extensive and thorough tests, which is great to see. I found one critical issue regarding the implementation of idle member detection, which seems to be missing. Otherwise, the implementation is solid and aligns well with the detailed plan.
| if (prevMember.status !== member.status) { | ||
| if (member.status === "idle") { | ||
| this.emit("team:member:idle", { sessionId, member }); | ||
| } else if (member.status === "shutdown") { | ||
| this.emit("team:member:shutdown", { sessionId, member }); | ||
| } | ||
| } |
There was a problem hiding this comment.
The logic to detect when a team member becomes idle appears to be missing. This if (member.status === "idle") block will likely never be reached because there is no code in team-state-reducer.ts that sets a member's status to idle.
The implementation plan (Phase 5.7, "Idle events") specifies that idle detection is a synthetic event based on task completion without a new task claim. This logic doesn't seem to be implemented here or in the state reducer. As a result, team:member:idle events will not be emitted, which is a gap in the feature as described.
To fix this, the logic for determining and setting the idle status on a TeamMember needs to be implemented, likely within the team-state-reducer.ts or as a more complex synthetic event generation step here in the session-bridge.ts as the plan suggests.
Fix architecture principle violations #1, #3, #4, #7: - Fix #1: Remove dual lifecycle mutation by deleting applyLifecycleFromBackendMessage() which was redundant with reduceLifecycle() - Fix #3: Make transitionLifecycle() private. Add SESSION_CLOSING system signal and route coordinator's direct calls through process() - Fix #7: Route ConsumerGateway's backend:relaunch_needed emission through the runtime as BACKEND_RELAUNCH_NEEDED system signal instead of emitting directly - Fix #4: Route BackendConnector's inline broadcasts and event emissions through the runtime via routeSystemSignal callback: - Part A: Connect/disconnect lifecycle (cli_connected, backend:connected, etc.) - Part B: Slash passthrough results/errors (slash_command_result, slash_command_error) This enforces the core design principle that all state mutations flow through SessionRuntime.process(), which dispatches to the pure reducer and executes effects. All 2902 tests pass, typecheck clean. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Update docs/architecture.md: - Replace Tier 1 table with resolved summary (#1–4 all fixed) - Update Tier 2 #6 (pendingInitialize now set in correct post-reducer hook) - Update Tier 3 #14 (handleInboundCommand rejections fixed via SEND_TO_CONSUMER) - Update Tier 3 #16 (trySendRawToBackend now runtime-internal only) Also narrow SLASH_LOCAL_RESULT signal source type to "emulated" | "cli" to match ConsumerMessage contract (caught by typecheck).
1 participant
Summary
TeamStatefrom the SDK message stream using a pure reducer pipeline: tool recognizer → correlation buffer → state reducerteams: booleancapability flag toBackendCapabilities(sdk-url: true, agent-sdk: true, acp/codex: false)Architecture
~/.claude/teams/filesystemstate-reducer.tspatternagents: string[]field populated fromteam.membersNew files
core/types/team-types.tscore/team-tool-recognizer.tscore/team-tool-correlation.tscore/team-state-reducer.tsModified files (24)
session-bridge.ts— per-session correlation buffer, team event diffing on both CLI and unified pathsstate-reducer.ts— wired team reducer pipeline into message processingunified-message.ts— 3 new message types:team_message,team_task_update,team_state_changebackend-adapter.ts—teamscapability flagextensions.ts—TeamObserverinterface (observation-only, no send methods)session-state.ts—team?: TeamStatefieldevents.ts— 8 team bridge events inBridgeEventMapteamscapability declarationTest plan
Review process
Implementation plan was reviewed by a 3-agent team (architect, protocol-reviewer, devil-advocate) that identified 4 CRITICAL, 5 HIGH, 7 MEDIUM, and 5 LOW issues. All CRITICAL and HIGH findings were resolved in a plan revision before implementation began. Code was polished via a 3-stage pipeline (simplification, dual Claude+Gemini review, deep analysis) that caught and fixed 2 additional bugs (singleton buffer, missing CLI path events).