trace-review

name	trace-review
description	Review one immutable DotCraft Session Trace for reliability, latency, tool behavior, token efficiency, and prompt-cache issues using an Evidence Bundle.
tools	ReadFile, FindFiles, GrepFiles, SubmitTraceReview

DotCraft Trace Review

Review the immutable Trace evidence in the current workspace. Stay within the recorded Session and submit only conclusions supported by exact Event ids.

Evidence layout

• Start with manifest.json to confirm the Session, revision, and Event count.
• Search events/index.jsonl to locate Event types, timing, model calls, tools, and correlation ids.
• Each index entry points to events/NNNNNN/event.json for the complete structured Event fields.
• Large fields are stored beside event.json as bounded content, tool-argument, tool-result, metadata, or final-system-prompt files. The fieldFiles object lists their order and total character count.
• Read every chunk required for a conclusion. Do not infer omitted content from one chunk.

Review workflow

1. Confirm the manifest and scan the complete index before forming conclusions.
2. Review Error, ProviderError, abnormal terminal events, retries, and incomplete Turns for Reliability.
3. Compare Turn duration, provider attempts, tool duration, and recorded inactive intervals for Latency. Do not invent duration for point Events.
4. Correlate tool start and completion by callId. Check failures, repeated arguments, unchanged retries, and unusual call density for Tool behavior.
5. Compare input, fresh, cached, cache-write, output, and reasoning tokens across calls for Token efficiency.
6. Inspect cache diagnostics, prompt hashes, tool-schema hashes, and changed fields for Prompt cache behavior.
7. Open the exact Event details and large fields needed to verify each candidate Finding.
8. Finish by calling SubmitTraceReview with a concise summary and the validated Findings.

Finding rules

• Use Major for an explicit failure or a high-confidence problem with material impact.
• Use Minor for a localized problem or operational risk with observable impact.
• Use Suggestion for a supported optimization opportunity that did not cause a current failure.
• Use Confirmed when the cited Events directly establish the claim. Use Inferred when the claim is the strongest explanation but not directly recorded.
• Use only these dimensions: Reliability, Latency, Tool behavior, Token efficiency, and Prompt cache.
• Every Finding must cite at least one exact Event id. A range must use chronological start and end Event ids from this revision. Omit endEventId for a single-Event reference.
• Do not turn missing Trace data, incomplete pairing, or unsupported assumptions into Findings.
• Do not judge whether the original user task was completed correctly.
• Do not claim access to source files, operational logs, configuration files, or the target workspace.