Repository navigation
BOT-2328: feat(agents): give remote agents an Activity tab - #1330
Conversation
klross
changed the title
227bf91 to
ef65403
Compare
2e8d490 to
d9c0feb
Compare
|
🤖 @salman1993 never mind on the revert; I closed #1384 and #1347 stays. This PR is live-only on main now, and remote history is tracked in BOT-2351. |
d9c0feb to
ba753d5
Compare
Since #1040 an agent's Activity tab comes from its type, and the remote agent type never supplied one, so View activity on a remote agent landed on Settings or Info. The remote agent type now registers a role "activity" tab beside its Settings tab. It shows the turns the agent published to its owner over the relay while Buzz has been open, starting with the conversation it was opened from, with a toggle for all conversations. It reads the Agent Activity plugin's feed rather than holding its own lease, and says when the plugin is off or the feed is connecting or interrupted. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Katie Ross <katieross@squareup.com>
ba753d5 to
6a645e6
Compare
wesbillman
left a comment
wesbillman
left a comment
There was a problem hiding this comment.
🤖 Star Lord automated source review via Wes's account, integrating independent Rocket, Mantis and Groot review lanes.
Reviewed head 6a645e6 against base ac42eb6 (feature merge base c2c7f6f).
Two low-severity recovery issues are commented inline. The existing feed remains the lifecycle and retention owner; the documented session-only history limitation is accepted for this scope. Assessment: 8/10 until the recovery messages/control behavior below are corrected; these are non-blocking comments, not a merge verdict.
Separate public-material finding: this public PR description includes internal issue-tracker links in the Known limit paragraph and final Linear line. Please replace those links with a public description or public issue reference. The URLs expose internal workspace/issue identifiers even if their destinations require authentication. I did not access the private issues. The attached browser-fixture screenshot was inspected; no additional disclosure finding in that image.
Validation: source-only review of all ten feature files and relevant callers, session ownership, scope filtering, recovery and focus transitions. No tests, builds, app launches, live remote-agent workflow, runtime performance measurement or CI assessment. The browser test source mounts this tab on a fixture type; it does not establish live Builderlab integration. Native behavior, rendered accessibility, both themes and human acceptance remain unverified.
| turnId: "published", | ||
| payload, | ||
| }); | ||
| app.observer(frame("turn_started", {}), key); |
There was a problem hiding this comment.
🤖 Could we wait for app.relay.hasRoute("primary", "observer") before publishing these frames? Activity delivery is best effort, so publishing before the subscription is ready can legitimately lose them. Waiting here would make the test deterministic without changing the product’s delivery behavior.
There was a problem hiding this comment.
🤖 2286526 waits for the observer route before publishing.
cloud-on-prem
left a comment
cloud-on-prem
left a comment
There was a problem hiding this comment.
🤖 Approved at Prem’s direction.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Katie Ross <katieross@squareup.com>
wesbillman
left a comment
wesbillman
left a comment
There was a problem hiding this comment.
🤖 Star Lord automated source follow-up review via Wes's account.
Head 2286526; base ac42eb6. Compared the complete endpoint trees with previously reviewed 6a645e6: only a comment and observer-route readiness assertion were added in tests/browser/local-agent-activity.spec.mjs. Production code and all prior feature patches are unchanged, so this uses the small unchanged-feature solo follow-up exception.
No new actionable finding in this follow-up (9/10). The retrying assertion waits for the actual owner-only observer subscription before sending best-effort activity, preserves the existing delivery/UI assertions, and adds no browser cases or fixed delay.
The two recovery/focus comments and public-description finding in the previous review remain unresolved and are not duplicated here. The feature's prior 8/10 assessment therefore remains. I rechecked the public description and attached fixture screenshot; no additional image disclosure finding.
Validation is source-only: pinned test, fixture subscription/delivery helpers, unchanged recovery paths and relevant guidance. No tests, builds, app launches or live remote-agent execution. A single hosted-check snapshot showed one WebKit shard running and Windows native validation skipped; it does not establish complete CI success. Runtime timing, rendered failure/retry focus, accessibility and native integration remain unverified. This is a non-blocking COMMENT, not approval or merge authorization.
4 participants
Why?
Remote agents lost their activity feed in #1040. Since then an agent's Activity tab comes from its type, and the remote agent type never supplied one. So "View activity" on a remote agent lands on Settings or Info, and owners can't see what their remote agents are doing.
The remote agent type now supplies its own Activity tab, next to its Settings tab in
adapter-type/, the same way Codex, Claude Code and Goose supply theirs. It shows the turns the agent published over the relay while Buzz has been open, starting with the conversation it was opened from, with a button to show all conversations. It reads the Agent Activity plugin's feed and says when that plugin is off. Nothing else in the app changes.The screenshot is from the browser test, where a test agent type registers the plugin's Activity tab.
Known limit: turns from before Buzz was opened don't show, since #1347 removed saved activity a couple hours ago. Remote agents have no local session files, so their history has to come from Beekeeper; that's BOT-2351.
Linear: BOT-2328
🤖 Generated with Claude Code