Runtime logs

Recorded workflow runs keep state and output together under one run directory:

.loom/.runtime/runs/<run_id>/state.jsonl
.loom/.runtime/runs/<run_id>/events.jsonl

State records follow workflow, job, step and command transitions. Event records carry messages and stdout/stderr alongside the same context. Both files contain one JSON object per line and can be inspected directly.

Use loom runs to discover saved IDs by recorded start, workflow and status, then choose one explicitly. - means unavailable; a pending/running row is recorded state, not proof a process is alive. Corrupt or unreadable candidate state files fail discovery rather than hiding a run.

Use loom logs <run_id> --state to locate a failure and loom logs <run_id> --tail 30 to inspect recent output. MCP clients use loom_list_runs, then loom_read_run and loom_read_events for the chosen ID.

See the runtime logs contract for fields, ordering and interrupted-record handling.