fix(web): trim phantom agent tabs and make run detail explain failures - #101
Conversation
Agent detail listed ten tabs but only branched on 'learning' — the other eight all fell through to the Overview panel, so eight distinct-looking links silently showed the same page. Overview already carries the permission, runtime, and tool evidence the readiness payload provides; the rest need APIs that do not exist. Trimmed to Overview and Learning. Add a tab back when it has content of its own. /agent-runs/[id] never rendered error or cancellationReason, so a failed run showed a bare status plus 'No typed result is available yet' — the board drawer said more about a failure than the run's own page did. It also never called its own timeline route. - Timeline route now returns failureCode, error, cancellationReason, structuredOutput, and outputHash. - The page reuses the board's AgentRunResult panel, so a run reads the same way in both places, and renders the execution timeline. - Moved onto CompanyOsShell + PageBody to match the rest of the OS, and polls only while the run is actually in flight. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 52 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…104) Those tabs were removed in #101 because they silently rendered Overview and the data was not exposed. This adds the API layer and brings them back backed entirely by stored state. New GET /api/v1/agents/[id]/profile (agents.read) returns: - Tools: the declared envelope joined with what the agent has actually called, from agent_tool_calls through its own runs. Registry metadata marks each tool read-only or mutating and names its approval action. Tools called but no longer declared are surfaced rather than hidden — a call outside the envelope is exactly what an operator needs to see, as is a declared tool the runtime registry does not implement. - Rooms: allow-listed rooms and real memberships, with Slack exposure per installation. The two disagreeing is shown, not reconciled. - Permissions: declared requirements against actual grants. 'missing' is the governance-critical one — an agent required to hold a capability it does not have fails at run time, and nothing else in the product surfaced that. 'surplus' supports least-privilege review; 'unknown' catches requirements that are not capabilities at all. The panels are strictly read-only. Grants and allow-lists stay server-controlled, and a test asserts the UI has no mutation path. Instructions, Runs, Evaluations, Versions, and Audit remain unbuilt and stay absent rather than falling through to Overview. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 participant
Tasks 15 and 16. Both found while reviewing the previous round's PRs.
Agent detail had eight phantom tabs
AgentDetailViewrendered ten tabs — Overview, Instructions, Tools, Permissions, Rooms, Runs, Learning, Evaluations, Versions, Audit — but only branched onlearning. The other eight all fell through toAgentOverview, so eight distinct-looking links silently showed the same page. Worse than a disabled button, because it fails silently rather than visibly.Trimmed to Overview and Learning rather than building eight panels. The agent object only exposes counts (
roomCount,allowedToolCount), not the underlying lists, so real Tools/Rooms/Permissions panels need APIs that do not exist yet. Overview already carries the permission, runtime, and tool evidence the readiness payload actually provides. A comment records the rule: add a tab back when it has content of its own.Run detail said less about a failure than the board did
/agent-runs/[id]never renderederrororcancellationReason— a failed run showed a bare status plus "No typed result is available yet". It also never called/api/v1/agent-runs/[id]/timelinedespite the route existing, which is why the board's link had to be worded "Open full run" rather than promising a timeline.failureCode,error,cancellationReason,structuredOutput, andoutputHash. Without them a failed run is a status with no cause.AgentRunResultpanel, so one run reads identically in both places — including the evidence framing. AshowFullRunLinkprop stops it linking to itself.CompanyOsShell+PageBodyto match the rest of the OS, and it polls only while the run is genuinely in flight.Reviewer note
Both
/api/v1/agent-runs/[id]routes require the run to be linked to a task. A run dispatched by a pack handoff has no task row, so it will 404 there. Out of scope here, but that link will dead-end for handoff-dispatched runs until the lookup widens.🤖 Generated with Claude Code