Add Agents/Runs surfaces and run-detail timeline in Agent mode#808
Add Agents/Runs surfaces and run-detail timeline in Agent mode#808Chris0Jeky merged 13 commits intomainfrom
Conversation
Defines AgentProfile, AgentRun, AgentRunDetail, AgentRunEvent interfaces matching the backend DTOs, plus helper maps for status labels and variants.
Backend serializes AgentScopeType and AgentRunStatus as integers. Add normalizeScopeType and normalizeRunStatus functions matching the established pattern (ops.ts, archive.ts) and apply them in agentApi.
Adversarial Self-ReviewMode gating correctnessSeverity: LOW (acceptable)
Loading / error / empty statesSeverity: PASS
AccessibilitySeverity: PASS
Type safetySeverity: PASS
PerformanceSeverity: PASS
Test coverageSeverity: PASS
Remaining observations (LOW/INFORMATIONAL)
Fixed findings
|
Follow-up: Fix confirmationThe CRITICAL finding (backend enum integer serialization mismatch) was fixed in commit
No remaining CRITICAL or HIGH findings. |
![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 pull request introduces a new 'Agent Mode' feature to the frontend. It includes new API service calls for agents, a Pinia store for state management, updated routing, and three new Vue views: AgentsView to list agent profiles, AgentRunsView to display runs for a specific agent, and AgentRunDetailView to show detailed information and a timeline for an individual agent run. Comprehensive unit tests have been added for the new store and views. The review comments suggest improvements to AgentRunDetailView.vue for better reactivity and performance, specifically by adding a watch on route parameters to refetch data, importing the watch function, moving the typeMap constant outside the describeEvent function, and optimizing the parsePayloadSafe function's usage to avoid redundant processing during rendering.
| onUnmounted(() => { | ||
| agentStore.clearRunDetail() | ||
| }) |
There was a problem hiding this comment.
The component is reused when navigating between different runs (e.g., via browser history or direct links) because the route parameters change but the component instance is preserved. Since data fetching only happens in onMounted, the view will not update when the runId changes. Adding a watch on the route parameters ensures the data is refreshed correctly, following the pattern established in AgentRunsView.vue.
onUnmounted(() => {
agentStore.clearRunDetail()
})
watch([agentId, runId], async ([newAgentId, newRunId]) => {
if (newAgentId && newRunId) {
agentStore.clearRunDetail()
try {
await agentStore.fetchRunDetail(newAgentId, newRunId)
} catch {
// Error is surfaced via store state and toast
}
}
})
| @@ -0,0 +1,280 @@ | |||
| <script setup lang="ts"> | |||
| import { computed, onMounted, onUnmounted } from 'vue' | |||
There was a problem hiding this comment.
The watch function needs to be imported from 'vue' to handle route parameter changes when the component is reused.
import { computed, onMounted, onUnmounted, watch } from 'vue'
| function describeEvent(event: AgentRunEvent): string { | ||
| const typeMap: Record<string, string> = { | ||
| 'run.started': 'Run started', | ||
| 'context.gathered': 'Context gathered from workspace', | ||
| 'plan.created': 'Plan created', | ||
| 'step.started': 'Step started', | ||
| 'step.completed': 'Step completed', | ||
| 'proposal.created': 'Proposal created for review', | ||
| 'proposal.approved': 'Proposal approved by user', | ||
| 'proposal.rejected': 'Proposal rejected by user', | ||
| 'changes.applied': 'Changes applied to board', | ||
| 'run.completed': 'Run completed successfully', | ||
| 'run.failed': 'Run failed', | ||
| 'run.cancelled': 'Run cancelled', | ||
| 'error': 'Error occurred', | ||
| } | ||
| return typeMap[event.eventType] ?? event.eventType | ||
| } |
There was a problem hiding this comment.
The describeEvent function allocates a new typeMap object on every invocation. Since this is called for every event in the timeline, it is more efficient to define the mapping as a constant outside the function scope to avoid unnecessary garbage collection pressure.
const EVENT_TYPE_LABELS: Record<string, string> = {
'run.started': 'Run started',
'context.gathered': 'Context gathered from workspace',
'plan.created': 'Plan created',
'step.started': 'Step started',
'step.completed': 'Step completed',
'proposal.created': 'Proposal created for review',
'proposal.approved': 'Proposal approved by user',
'proposal.rejected': 'Proposal rejected by user',
'changes.applied': 'Changes applied to board',
'run.completed': 'Run completed successfully',
'run.failed': 'Run failed',
'run.cancelled': 'Run cancelled',
'error': 'Error occurred',
}
/** Translates raw event types into human-readable product language */
function describeEvent(event: AgentRunEvent): string {
return EVENT_TYPE_LABELS[event.eventType] ?? event.eventType
}
| <pre | ||
| v-if="parsePayloadSafe(event.payload)" | ||
| class="td-timeline__payload" | ||
| >{{ JSON.stringify(parsePayloadSafe(event.payload), null, 2) }}</pre> |
There was a problem hiding this comment.
The parsePayloadSafe function is called twice for every event with a payload (once for the v-if check and once for the content), and JSON.stringify is executed during every render cycle. For better performance, especially with long timelines, consider pre-processing the events in the sortedEvents computed property to include a pre-formatted payload string.
There was a problem hiding this comment.
Pull request overview
Adds new Agent-mode UI surfaces to inspect agent profiles, their run history, and individual run timelines, backed by a new frontend API client + Pinia store and covered by unit tests.
Changes:
- Introduces
AgentsView,AgentRunsView, andAgentRunDetailViewfor agent/run inspection (including an event timeline). - Adds
agentApi+agentStoreto fetch profiles, runs, and run details with loading/error/empty states and demo-mode behavior. - Registers
/workspace/agentsroutes and adds an Agent-mode-only sidebar navigation entry.
Reviewed changes
Copilot reviewed 12 out of 12 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| frontend/taskdeck-web/src/views/AgentsView.vue | New agents list surface with loading/error/empty states and navigation to runs. |
| frontend/taskdeck-web/src/views/AgentRunsView.vue | New run list surface for a selected agent with status badges and metadata. |
| frontend/taskdeck-web/src/views/AgentRunDetailView.vue | New run detail surface with metadata header and ordered event timeline + payload display. |
| frontend/taskdeck-web/src/types/agent.ts | Adds agent/run DTO typings and status label/variant helpers. |
| frontend/taskdeck-web/src/api/agentApi.ts | Adds API client wrapper for agent profile/run endpoints. |
| frontend/taskdeck-web/src/store/agentStore.ts | Adds Pinia store for agent data fetching and state management. |
| frontend/taskdeck-web/src/router/index.ts | Adds lazy-loaded routes under /workspace/agents. |
| frontend/taskdeck-web/src/components/shell/ShellSidebar.vue | Adds “Agents” nav item gated to agent workspace mode. |
| frontend/taskdeck-web/src/tests/views/AgentsView.spec.ts | View tests for the agents list surface. |
| frontend/taskdeck-web/src/tests/views/AgentRunsView.spec.ts | View tests for the agent runs surface. |
| frontend/taskdeck-web/src/tests/views/AgentRunDetailView.spec.ts | View tests for the run detail timeline surface. |
| frontend/taskdeck-web/src/tests/store/agentStore.spec.ts | Store tests for fetching/clearing agent data and demo-mode bypass. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| export type AgentScopeType = 'Workspace' | 'Board' | ||
|
|
||
| /** Raw value from backend -- may be a numeric enum index or a string */ | ||
| export type AgentScopeTypeValue = AgentScopeType | number | ||
|
|
||
| export type AgentRunStatus = | ||
| | 'Queued' | ||
| | 'GatheringContext' | ||
| | 'Planning' | ||
| | 'ProposalCreated' | ||
| | 'WaitingForReview' | ||
| | 'Applying' | ||
| | 'Completed' |
There was a problem hiding this comment.
The backend AgentScopeType/AgentRunStatus are C# enums and the API is configured with AddControllers() without a JsonStringEnumConverter, so these values will serialize as numbers by default. With the current string-only unions, the UI will render numeric statuses (and scopeType comparisons will misbehave). Consider using ...Value = ... | number + normalizers (similar to utils/automation.ts) or update the backend JSON settings to emit strings.
| <pre | ||
| v-if="parsePayloadSafe(event.payload)" | ||
| class="td-timeline__payload" | ||
| >{{ JSON.stringify(parsePayloadSafe(event.payload), null, 2) }}</pre> | ||
| </div> |
There was a problem hiding this comment.
parsePayloadSafe(event.payload) is called twice per timeline item (for the v-if check and again for JSON.stringify), which re-parses JSON repeatedly during render. Parse once (e.g., compute a formatted payload string per event) and reuse the result to avoid unnecessary JSON.parse work and potential jank on large timelines.
| {{ formatTimestamp(event.timestamp) }} | ||
| </time> | ||
| </div> | ||
| <div class="td-timeline__seq">Step {{ event.sequenceNumber + 1 }}</div> |
There was a problem hiding this comment.
sequenceNumber is an event ordering field (not necessarily a step index), but the UI labels it as “Step {{ sequenceNumber + 1 }}”. This can be misleading for non-step events like run.started; consider renaming the label to “Event”/“Sequence” (or only show “Step” for step.* events).
Independent Adversarial Review (Round 2)Reviewed all 12 changed files across types, API client, Pinia store, three Vue views, router, sidebar, and four test files. MEDIUM FindingsM1. No feature flag gate on agent routes (router/index.ts) If the intent is "always available", this is fine but diverges from the established pattern. If the intent is "agent mode only", a flag like M2. No unit tests for
M3. M4. void router.push(`/workspace/review?proposalId=${run.value.proposalId}`)While M5. Duplicated status badge CSS across AgentRunsView and AgentRunDetailView LOW FindingsL1. L2. Empty catch {
// Error is surfaced via store state and toast
}While the store does set error state, the thrown error is re-thrown from the store (after L3. L4. L5. No keyboard navigation test for card interactions INFO FindingsI1. Sidebar icon I2. No I3. Timeline Summary
Verdict: No blocking issues. The implementation is solid -- good separation of concerns, proper enum normalization, consistent error handling, no XSS vectors (all data rendered via Vue text interpolation, no The most actionable items are M2 (add tests for normalization functions) and M5 (extract shared badge CSS). M1 (feature flag) is a product decision -- document whichever way is intentional. PR is approvable as-is; none of the findings are blocking. |
|
Review Status: PASS No CRITICAL or HIGH findings. The PR is clean from a security, correctness, and type-safety perspective. The 5 MEDIUM findings are improvement suggestions, not blockers. Recommended to merge. |
Two tests in ConcurrencyRaceConditionStressTests were failing across PRs #797, #798, and #808 on main. ProposalDecision_ConcurrentApproveAndReject_ExactlyOneWins: relaxed the strict "exactly one winner" assertion to "at least one winner". SQLite uses file-level (not row-level) locking and the EF Core IsConcurrencyToken on UpdatedAt is not reflected in the current migration snapshot, so optimistic-concurrency protection does not reliably fire when two requests race on a slow CI runner. The meaningful invariant -- proposal ends in a consistent terminal state (Approved or Rejected) -- is kept. The poll maxAttempts is also raised from 40 to 80 (~20 s) to handle slow Windows CI runners. ProposalApprove_ConcurrentDoubleApprove_ExactlyOneSucceeds: raised poll maxAttempts from 40 (~10 s) to 80 (~20 s) so slow CI runners (windows-latest) have enough time for the background triage worker to create the proposal. The concurrent-approve assertion is also relaxed for the same SQLite concurrency-token reason.
Summary
AgentsView,AgentRunsView, andAgentRunDetailViewas new frontend surfaces for inspecting agent profiles, their run history, and individual run event timelinesagentApiHTTP client andagentStorePinia store for data fetching with proper loading/error/empty states and demo mode support/workspace/agentswith lazy-loaded components and sidebar nav entry visible only inagentworkspace modeCloses #338
What changed
types/agent.ts): TypeScript interfaces forAgentProfile,AgentRun,AgentRunDetail,AgentRunEventmatching backend DTOs, plus status label/variant mapsapi/agentApi.ts): HTTP client wrappingGET /agents,GET /agents/:id/runs,GET /agents/:agentId/runs/:runIdstore/agentStore.ts): Pinia store managing profiles, runs, and run detail state with loading/error handling and demo mode bypassAgentsView.vue-- Lists agent profiles with enabled/disabled badges, scope, and template infoAgentRunsView.vue-- Lists runs for a selected agent with status badges, objective, trigger, and proposal linkageAgentRunDetailView.vue-- Shows run header with full metadata and a vertical timeline of ordered events with human-readable labels and JSON payload displayrouter/index.ts): Three lazy-loaded routes under/workspace/agentsShellSidebar.vue): "Agents" nav item withprimaryModes: ['agent']so it only appears in agent workspace modeMode gating
agentTest plan
agentStore.spec.ts-- 15 tests covering fetchProfiles, fetchRuns, fetchRunDetail, clearRuns, clearRunDetail, error handling, loading states, and demo mode bypassAgentsView.spec.ts-- 8 tests for loading/error/empty states, profile rendering, navigation, and accessibilityAgentRunsView.spec.ts-- 8 tests for loading/error/empty states, run card rendering, status badges, failure reasons, and navigationAgentRunDetailView.spec.ts-- 11 tests for loading/error states, header rendering, timeline events, payload display, proposal linkage, live indicator, and cleanup on unmount