The resume story

Every long pipeline eventually meets a hard death. The laptop lid closes, the CI runner is reaped, someone trips over Ctrl-C twice. The question that decides whether that hurts is not did it crash. Everything crashes. It is what happens to the work that already finished?

In a glue script, the answer is: it re-runs. The API calls you already paid for fire again, the files you already wrote get written again, and if any step is not perfectly idempotent you now have a second problem. In a chat agent, the answer is worse: the plan lived in a context window, and the context window is gone.

Here is a workflow with real work in it: checksum the day's notes, count them, pack a 300 MB asset archive, write a manifest.

1# Hash, count and pack the day's notes into one manifest2nika: nightly-archive3​4⛨permits:5  ⛨fs:6    ⛨read: ["./notes/*", "./assets.bin"]7    ⛨write: ["./assets.bin.gz"]8  ⛨exec: ["shasum", "wc", "gzip", "echo"]9​10tasks:11  # No deps between these two → the engine runs them in parallel.12  hash_notes:13    ▷exec:14      command: ["shasum", "-a", "256", "notes/monday.md", "notes/tuesday.md", "notes/wednesday.md"]15​16  count_notes:17    ▷exec:18      command: ["wc", "-w", "notes/monday.md", "notes/tuesday.md", "notes/wednesday.md"]19​20  # Pack only once the notes are verified — the checksums gate the archive.21  pack_assets:22    after:23      hash_notes: success24      count_notes: success25    ▷exec:26      command: ["gzip", "-kf9", "assets.bin"]27​28  manifest:29    after:30      pack_assets: success31    ▷exec:32      command: ["echo", "archive ok"]33​34outputs:35  checksums: "${{ tasks.hash_notes.output }}"36  words: "${{ tasks.count_notes.output }}"

Run it. Five seconds in, while gzip is grinding through the archive, kill it the rude way. Not Ctrl-C, not a graceful shutdown hook: SIGKILL, the signal a process never gets to handle.

1❯ nika run nightly-archive.nika.yaml &2❯ sleep 5 && kill -9 $!3​4  🦋 nika · nightly-archive · 4 tasks5     permits ✓ declared boundary · default-deny6​7  ✔  hash_notes   exec · shasum  27ms8  ✔  count_notes  exec · wc  3ms ∥

That is the whole console. The two checksums finished in milliseconds; the pack was mid-flight when the process died. No cleanup ran, no state was saved on the way down: the engine never saw the signal coming.

But the run was never keeping its state in memory. Every run writes a journal as it goes: an append-only NDJSON file in .nika/traces/ beside your workflow, one typed event per line. Read the journal the crash left behind:

1❯ grep -o '"kind":"[a-z_]*"' .nika/traces/2026-07-10T10-41-21Z-0672.ndjson | sort | uniq -c2   1 workflow_started3   4 task_scheduled4   2 task_started5   2 task_completed

Two task_completed events survived the kill, because they were written the moment the work settled, not at the end of the run, not on shutdown. The journal does not need the process to die politely.

Now the whole point:

1❯ nika run nightly-archive.nika.yaml --resume .nika/traces/2026-07-10T10-41-21Z-0672.ndjson2​3  🦋 nika · nightly-archive · 4 tasks4     permits ✓ declared boundary · default-deny5​6  ↷  hash_notes   cache hit (resume)7  ↷  count_notes  cache hit (resume)8  ✔  pack_assets  exec · gzip  13.2s9  ✔  manifest     exec · echo  8ms10  ── 4/4 done · $0.00 · elapsed 13.2s ────────────────────────────11​12  resumed · 2 skipped (cache hit) · 2 ran live

↷ is the engine's glyph for not doing. The two tasks whose completion the journal recorded skip visibly, by name, as cache hit (resume), and only the interrupted pack and everything downstream of it run. Finished work never runs twice. Had hash_notes been an LLM call, those are tokens you do not pay for a second time; had it written a file, that file is not touched again.

The skip is not a guess, and this is the part worth being precise about. A task is skipped only when its identity matches a journaled success. Its identity is the task as written: the command, the resolved inputs, the shape of the thing you can read in the file. Edit the task and the match breaks. Change one flag, shasum -a 256 to shasum -a 512, and resume again:

1  ✔  hash_notes   exec · shasum  67ms2  ↷  count_notes  cache hit (resume)3​4  resumed · 1 skipped (cache hit) · 3 ran live

The edited task re-runs; its untouched sibling still skips. You cannot accidentally resume yourself into stale results from a plan you have since changed. And a trace with no resumable successes in it is a notice, never an error: the run simply happens live.

Notice what is absent from this story: a workflow cluster. A database. A coordinator service that has to stay up so your work can survive. Durable execution is usually sold as infrastructure: stand up a server, keep it healthy, and it will remember your workflows for you. Here, durability is a property of two files sitting in your repo: the plan and the journal. kill -9 the engine, lose the machine, come back tomorrow on a different one. The pair still knows exactly what is done and what is not.

The same journal is the flight recorder you can replay and the substrate the time-travel debugger steps through. One artifact, three jobs: evidence, replay, resume. Chats evaporate; files compound. It turns out the crash recovery compounds too.