Record a Cairn run in Plune

Cairn explores a running app and writes what it found to disk: cases, evidence, a report.json per run. It knows nothing about Plune, and that is deliberate — a Cairn user who has never heard of Plune should not find its URL, its token or its payload shape wired into their tool.

plune ingest is the thing that carries one run across.

plune ingest

That reads the newest run under ./runs and sends it. Name the directory to send a specific one:

plune ingest runs/2026-09-09T10-22-31Z

What arrives

Three counters account for every case in the run:

Ingested Cairn run → run_a1b2c3
  12 result(s) attached to existing cases
  7 case(s) proposed — review them in Plune to accept
  3 skipped (already queued, already rejected, repeated, or never executed)

• Attached — Cairn re-ran something Plune already has a case for, so the outcome joins that case’s history.
• Proposed — Cairn found something new. It is now in the review queue, waiting for a person.
• Skipped — the case was already queued, was refused before, repeated inside this run, or never actually executed.

The result each case carries

Only a cairn api run executes what it writes, so only its cases carry a result — attached at once, or when you accept the proposal. A design run executes nothing, and an explore run’s checks are not carried across, so their cases carry none.

• passed — the response came back with the status the case expects, and its body matches the spec’s schema.
• failed — the API answered, but not as declared.
• blocked — no answer at all: the request ended in a transport error after Cairn’s retries (a refused connection, an unknown host, a request that timed out). The product said nothing either way, so it is not counted as a failure. From CLI 0.20.0; before it, such a case arrived as failed.

Nothing is created silently

An ingest cannot fill a project with cases nobody authored. A generated case arrives as a proposal; it becomes a test case only when someone accepts it in the review queue. Refusing one is a normal outcome, and a refused case is not proposed again by a later run.

Step by step

1. Save a token once.

   plune login

   The token is checked against the API before it is saved, so a wrong one fails here rather than two commands later. See Sync runs to the platform.

2. Let Cairn explore.

   cairn design --url https://app.example.com/page --session myapp

   Cairn writes the run to runs/<id>/. Anything that produces a report.json works — cairn design, cairn explore, cairn api.

3. Carry it across.

   plune ingest

   Or name the directory when the newest one is not the one you mean.

4. Review what it proposed. Open the review queue in Plune and accept or refuse each case. Only what you accept becomes a test case.

When it refuses

Every refusal names the fix and uploads nothing. Exit 2 is something to fix here and now; exit 1 may work on a retry.

Message	What happened
No Cairn run found under runs	There is nothing to send from the default directory. Name the run: plune ingest <dir>.
No Cairn run found in <dir> — expected a report.json	Usually a mistyped path. A run directory holds a report.json.
This run predates versioned Cairn artifacts	Re-run it with Cairn 0.7.0 or newer, which stamps the format so it can be read safely.
Unsupported Cairn artifact version N	Cairn is ahead of the CLI — npm install -g @plune-ai/cli@latest.
That Cairn run did not finish, so its cases are incomplete	The run failed partway and its artifact is a fragment. Re-run it.
Cannot attach results safely: the operation "X" appears more than once	Evidence carries no case identity to tell two identical operations apart, so nothing was uploaded rather than attached to the wrong case.
Not logged in / Your API token was rejected (401)	Run plune login with a fresh token.

One direction only

The link runs Cairn → Plune and never back. Cairn has no Plune configuration, no token and no awareness that this command exists; everything about the handoff lives in this CLI. Using Cairn on its own stays exactly as it was.

Bring an existing suite Already have JUnit XML or Playwright JSON? That road needs no provider key either.

Sync runs to the platform login, logout, sync — what reaches the server, and what never leaves your machine.