feat(trace): add diagnosis trace workbench
This commit is contained in:
@@ -0,0 +1,37 @@
|
||||
# Trace UI workbench
|
||||
|
||||
## Why
|
||||
|
||||
The MVP already persists diagnosis trace data and exposes it through
|
||||
`GET /api/diagnosis/{sessionId}/trace`, but reviewers still need to inspect raw
|
||||
JSON to answer basic audit questions:
|
||||
|
||||
- Which agents ran, in what order, and with what persisted counts?
|
||||
- Which evidence tools executed, how many times, and did they succeed?
|
||||
- Which facts did the Verifier check, and which evidence refs support them?
|
||||
- Did Planner only select skill metadata while Executor handled skill loading?
|
||||
- What RAG retrieval details were used by `lookup_knowledge`?
|
||||
|
||||
This slows down demo review and makes trace quality issues harder to spot.
|
||||
|
||||
## What changes
|
||||
|
||||
- Add a static Trace workbench page served by Spring Boot static resources.
|
||||
- Load a diagnosis trace by session id through the existing read-only Trace API.
|
||||
- Render session summary, agent timeline, evidence tool ledger, verifier facts,
|
||||
skill boundary checks, and RAG retrieval details.
|
||||
- Add a navigation entry from the existing chat page to the Trace workbench.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- No new backend endpoint.
|
||||
- No mutation of diagnosis sessions, agent steps, tool invocations, or feedback.
|
||||
- No new frontend framework or build pipeline.
|
||||
- No change to the persisted trace schema.
|
||||
|
||||
## Impact
|
||||
|
||||
- Frontend-only runtime surface under `src/main/resources/static`.
|
||||
- Uses the existing `Result<T>` API response contract.
|
||||
- Works with existing trace records, including sessions that lack verifier or RAG
|
||||
detail fields.
|
||||
Reference in New Issue
Block a user