How to use the session timeline
Use the timeline to understand what Buffaly did, what evidence it gathered, and where a task currently stands.
What the timeline shows
The timeline records user messages, assistant progress, tool calls, tool results, final answers, lifecycle rows, queued instructions, compaction events, and artifact references in order.
It is the best place to audit how Buffaly reached a conclusion: which files were inspected, which actions ran, what validation returned, and where the work changed direction.
For delegated work, the timeline can also show when a child session was queued, when the parent checked for output, and which artifact location both sessions were expected to use.
Timeline rows to compare
Session history tooling can show timeline rows in chronological pages, including modes such as since_last_compaction and bounded date ranges. Read each row as evidence, not as a standalone conclusion.
| Timeline item | What it tells you | What to verify |
|---|---|---|
| User message | The request, constraints, paths, and acceptance criteria. | Target path, repository root, and task scope. |
| Status update | What Buffaly is trying, what it found, and what it plans next. | Later validation or final answer; status is not completion. |
| Tool call and result | The typed action, file inspection, command, service call, or source search that produced evidence. | The result immediately after the call and whether it supports the final claim. |
| Lifecycle or compaction row | Session startup, worker, recycle, compaction, or operational state. | Whether older details were summarized and where archived evidence lives. |
| Artifact reference | Plan, Scratch, task files, saved outputs, generated files, attachments, or deliverables. | Exact session-relative, repository-relative, or absolute path. |
How to read it
- Start with the user request and copy exact paths, constraints, and required output format.
- Read early status updates to confirm Buffaly identified the right source of truth and validation plan.
- Separate read-only inspection from file writes, commands, commits, service calls, or queued messages.
- Start at the latest meaningful validation result, artifact update, commit, or blocker.
- Walk backward to find the user instruction and plan that caused that work.
- Open tool results when a conclusion depends on a file, command, service response, or search result.
- Separate progress commentary from final answers; commentary explains direction, while final answers summarize completed or blocked work.
- If incomplete, ask Buffaly to continue from the last validated state rather than restart discovery.
Common uses
Resume work
Identify the last completed batch, validation result, and next unchecked task before asking Buffaly to continue.
Review delegation
Confirm what was sent to child sessions and where their output was expected to appear.
Debug a claim
Find the tool output that supports the claim, then compare it to the final answer.
Recover after compaction
Use the compacted summary as an index, but verify important details against original events or artifacts.
Example prompts
"Show the timeline rows for this session since the last compaction. Include tool rows and lifecycle rows, but omit reasoning rows unless needed."
"Read the timeline around the last commit. Tell me what files changed, which validation commands ran, and whether the final report matches the commit."
"This session looks stalled. Inspect the latest timeline rows, lifecycle events, queued messages, worker status, Plan/Scratch/task artifacts, and last tool result. Tell me the next safe recovery step."
Troubleshooting confusing timelines
Timeline ends with status only
Work may still be running, stalled, or missing a final answer. Ask Buffaly to continue from the last status row or report the exact blocker.
Final answer lacks evidence
Ask for the tool results, artifacts, validation output, and timestamps that support the final answer.
Similar sessions are confusing
Request the exact session key, parent key, target file, timestamps, and commit hash before resuming work.
Queued instruction was not processed
Check queued messages, worker status, child session key, latest lifecycle rows, and the child's final output or artifacts.
Evidence checklist
Before treating a session conclusion as reliable, look for the evidence that matches the type of work:
- For code or website changes, confirm build output and the commit hash.
- For documentation, confirm the file path, route, navigation entry, and link audit.
- For remembered knowledge, confirm whether it was stored as ontology memory, prompt guidance, or a durable task artifact.
- For operational claims, confirm timestamps, session keys, service responses, or logs.