Skip to content

Replay-Driven Triage

If you searched for replay-driven triage, the important distinction is whether the artifact root is good enough to answer the next question without reconnecting to the device. Luotsi is built around that assumption.

Luotsi writes replay-friendly material so the session can be examined after the device is gone:

  • session-timeline.jsonl
  • session-replay.json
  • screenshots and hierarchy captures
  • logcat and metadata
  • report and failure bundle outputs

That lets triage stay host-side and asynchronous instead of forcing another live session just to see what happened.

Terminal window
luotsi replay packet --artifacts ./artifacts/<run>
luotsi replay packet --artifacts ./artifacts/<run> --check
luotsi replay open --artifacts ./artifacts/<run> --dry-run --write-json --write-markdown
luotsi replay summarize --artifacts ./artifacts/<run>
luotsi replay search --artifacts ./artifacts/<run> --contains "error"
luotsi replay capsule --artifacts ./artifacts/<run>

Start with replay packet when CI or an agent needs the durable packet directly: it writes run-summary.json and run-summary.md, returns the same luotsi-run-summary.v1 object, includes the At a Glance summary, failure snapshot, primary failure, and recommended next action, and never launches a browser. Validate shared packets with replay packet --check. Use replay open --dry-run --write-json --write-markdown when a human also wants the replay front-door response and browser entrypoints.

  • The device session is expensive or impossible to repeat immediately.
  • Engineers or agents need to search, summarize, and inspect artifacts after the run.
  • You want failure evidence that can move between local debugging, code review, and CI.
  • The workflow depends entirely on live interaction and leaves no meaningful artifacts behind.
  • Your team only needs a pass or fail bit from CI and never revisits failed runs.