Sessions

ReadyCheck has two types of sessions: capture sessions that record what happened, and analysis sessions that record the investigation of what happened. They are stored separately and linked by reference.

Capture Sessions

A capture session is created every time you run /check or ada capture start. It records synchronized data from all three tracks into a directory bundle:

~/.ada/sessions/<session_id>/
├── session.json     # Session metadata (status, timestamps, target info)
├── manifest.json    # Bundle manifest (entry point for queries)
├── trace/           # Function trace data (ATF)
├── screen.mp4       # Screen recording (optional)
└── voice.wav        # Voice recording (optional)

Session Timeline

All three tracks share a single timeline. Every event — whether it’s a screen frame, a voice segment, or a function call — is timestamped relative to the session start. This synchronization is what makes cross-track correlation possible.

When you say “I clicked the button and nothing happened” at timestamp 15.3s, ReadyCheck can:

  1. Find your voice segment at ~15.3s
  2. Show what was on screen at ~15.3s
  3. List every function call in the window around ~15.3s

Querying Capture Sessions

Capture sessions are queryable via the ada CLI:

# Latest session
ada query @latest time-info

# List all sessions
ada session list

# Print the bundle path for the latest session
ada session latest

# Specific session
ada query <session_id> events --limit 100

Capture Session Lifecycle

  1. Created — When capture starts, a new session directory is initialized
  2. Recording — All three tracks write data in real-time
  3. Completed — When the target app quits, recording stops
  4. Queryable — The session is immediately available for analysis

Capture sessions persist on disk until manually deleted.

Analysis Sessions

An analysis session is created when you run /analyze or ada analysis init. It references an existing capture session and stores the results of investigating it:

~/.ada/analyses/<analysis_id>/
├── index.json       # Analysis metadata (links to capture session)
└── issues/          # Discovered issues

The index.json links the analysis to its capture session:

{
  "analysis_session_id": "analysis_2026_03_08_20_35_50_a1b2c3",
  "capture_session_id": "session_2026_03_08_20_35_50_a1b2c3",
  "created_at": "2026-03-08T20:35:50.123Z"
}

Why Two Session Types?

Capture and analysis are decoupled. A single capture session can be analyzed multiple times — each producing a separate analysis session. This lets you re-investigate the same recording with different hypotheses or after code changes, without re-running the app.