Manage sessions in Sessions.Web
Browse, inspect, and reason about saved Buffaly sessions through the Sessions.Web admin surface before asking the Buffaly agent to resume or verify prior work.
Quick answer
Sessions.Web is a separate checked-in web application for session administration and visibility. Use it when you want to inspect stored session data, message records, artifacts, subscriptions, processes, and dashboard health from an operator view.
Use the Buffaly agent chat UI when you want to continue work, ask the agent to reason over history, run tools, validate files, or resume a task.
| Surface | Best for | Avoid |
|---|---|---|
| Sessions.Web | Browsing stored sessions, messages, artifacts, subscriptions, processes, and dashboard health. | Assuming a row resumes the agent or validates the underlying work. |
| Buffaly agent chat UI | Continuing work, inspecting evidence, running tools, validating files, and producing final answers. | Relying on memory alone when a session or artifact can be inspected. |
| Session history tools | Paging or summarizing a known session timeline. | Using semantic search when exact session key/date/page history is already known. |
| Semantic conversation search | Finding likely sessions by meaning when exact text or key is unknown. | Treating a semantic match as proof without opening or summarizing the candidate session. |
Documented Sessions.Web surfaces
The checked-in Sessions.Web project is a Sessions site, not the main Buffaly agent chat UI. Source shows its own web host, authentication/session cookies, dashboard page, kScript-backed admin pages, JsonWs stubs, scheduled process host pieces, and navigation.
Admin areas
Sessions, Messages, Dashboard, Features, Session Artifacts, Session Subscriptions, and Processes.
Common routes
/sessions, /messages, /dashboard, /features, /session-artifacts, /session-subscriptions, and /processes. Exact deployed URLs can vary.
Browse sessions
Start with the Sessions page when you need a list of saved sessions. Use it to identify session IDs or keys, likely session names, date/time context, related messages or artifacts, and whether a session is likely the source session or a watcher/search/debug session.
- Open Sessions.Web.
- Go to Sessions.
- Search or filter for a likely session name, date, or keyword if the grid supports it.
- Open the details page for the best candidate.
- Inspect related Messages and Session Artifacts tabs.
- Copy the session key or other stable identifier.
- Ask the Buffaly agent to verify and resume from that evidence.
Handoff prompt
I found candidate session <session-key> in Sessions.Web. Read its session history, inspect related artifacts if available, and summarize whether it contains the decision I need before resuming anything.
Inspect messages and timelines
Sessions.Web exposes message administration through the Messages surface and session detail tabs. Use this when you need evidence from stored messages rather than a fresh agent response.
- Look for the original user request, final answers, progress messages, timestamps, ordering, blockers, and whether the session is complete or only partially relevant.
- For long or compacted sessions, combine Sessions.Web evidence with session-history paging or summarization where supported.
Inspect session artifacts
Source shows a Session Artifacts admin area and a related artifacts tab on session details. Use artifacts when transcript text is not enough.
If an artifact points to a repository file, verify the file still exists and whether it was committed.
Use dashboard and process views
The dashboard is useful for system health rather than task-level proof. Source mentions conversation volume, tool usage, session growth, session artifacts, and semantic reindex health. Process views help diagnose scheduled work such as semantic conversation reindexing.
- Use these pages when semantic session search appears stale.
- Check dashboard/process evidence when session growth, message counts, or scheduled processes look wrong.
- Use operational context before trusting search results.
Resume or reason about prior work
Sessions.Web helps you find evidence; the Buffaly agent should do the reasoning and resumption.
Good handoff prompt
I found session <session-key> in Sessions.Web. Before resuming, inspect the session history, related artifacts, Plan/Scratch/task files if available, and current git status. Summarize the last completed step, unresolved blockers, intended target files, and next safe action.
Use when key is known
Use session-history paging/summarization plus Sessions.Web details.
Use when topic is known
Use semantic conversation search, then open candidates in Sessions.Web or summarize their histories.
Use when artifact is known
Inspect the artifact or file directly and use Sessions.Web to find the originating session.
Use before resuming
Ask Buffaly to re-read evidence and validate current repo/runtime state before editing.
Verify exact routes in your installation
- Open the Sessions.Web host root.
- Check left navigation for Sessions, Messages, Dashboard, Session Artifacts, Session Subscriptions, and Processes.
- Confirm whether common routes such as
/sessions,/messages,/dashboard,/session-artifacts,/session-subscriptions, and/processeswork. - If a route fails, inspect deployed static/kScript assets and JsonWs stubs under the running installation.
- Ask Buffaly to compare implementation paths against deployed paths before changing configuration.
Troubleshooting
Cannot find a session
Start with exact anchors: session key, date, file path, commit hash, artifact name, or distinctive error text. If that fails, use semantic search by meaning.
Too many messages
Ask Buffaly to summarize or page the session history with filters. For known sessions, session-history tools are better than manual browsing alone.
Artifacts are confusing
Use artifact rows as leads, not proof. Inspect the artifact record, filesystem path, repository state, and the final answer that referenced it.
Need to continue safely
Do not continue from Sessions.Web alone. Re-read session evidence, inspect current files, validate assumptions, and only then proceed.