Platform — Getting started

The Plune platform is the hosted half of Plune: it keeps your test cases, records every run, and holds the queue where machine-proposed tests wait for a human decision. The CLI and the GitHub Action produce results; the platform is where they accumulate and become a history you can ask questions of.

betainvite only

Open beta.plune.ai and enter the address your invite was issued to.
Open the magic link in the email. There is no password to choose and none to lose — the link opens a session, and that session is what mints your API tokens.
You land on your runs. It is empty until something reports into it, which is the next step.

Mint a token

The web session drives the dashboard; a bearer token is what a runner or CI uses. Create one in Settings → API tokens. It is shown once, so put it straight into your secret store.

Tokens live 90 days and can be revoked individually or all at once. Signing out of the dashboard does not revoke them — a token outlives the session that created it on purpose, because CI has no session.

Send your first run

You do not need to adopt a new runner. Anything that emits JUnit XML — pytest, Jest, Vitest, Playwright, Go, JUnit itself — already speaks a format the platform reads.

npm i -g @plune-ai/cli
export PLUNE_TOKEN=plune_…          # the token you just minted
plune run import junit.xml --create  # --create opens cases for tests it has never seen

--create does not silently add test cases. It offers them: each unknown test arrives in the review queue as a proposal, and stays a proposal until a person accepts it. Re-importing the same report after accepting matches the existing cases instead of offering them again. A mature suite is thousands of such offers at once — for that, Settings → Trusted sources lets you say that tests discovered by a given runner are yours and become cases on arrival; the review queue page explains what that does and does not skip.

No provider key, no account with anyone else: this road costs nothing but the token. There are two more, and the platform does not care which one a result came by:

Import an existing suite The JUnit road in full — several CI jobs into one run, the fallback file, and what a first import looks like.

Report from Playwright directly @plune-ai/playwright — a reporter that sends results as the run goes, no file in between.

Ingest a Cairn run Tests an agent generated arrive as proposals: cairn explores, plune ingest reports, the queue decides.

Work the queue

The queue is the product’s one firm rule: nothing enters your test suite silently. Two kinds of entry land there, and they arrive from opposite directions —

Proposals — tests a runner reported that this project has no case for.
Disputes — a result whose verdict a human should look at rather than trust.

Both wait for the same decision, and a rejection has to carry a reason. Accepting a proposal is what creates the test case; the case then outlives the run that suggested it, and outlives its deletion.

Concepts — what a run, a case and a queue entry actually are The five records the platform keeps, and which of them a delete takes with it.

After the first run

The run appears at the top of Runs with its five counters — passed, failed, broken, blocked, skipped — and, from the second run on, Trends draws the pass-rate line between them. One run is a snapshot; the platform earns its keep from the third or fourth, when a test that has never failed before does.

Every test the run named is now a case with a history: open one from Cases and the history lists each run it took part in. The identity a JUnit report carries is the file path plus the title, so a renamed or moved test arrives as a new test on the next import — offered to the queue, or created straight away from a trusted source — while the old case keeps its history. Keep titles stable where you want a long line. With Playwright there is a way out: a @P<id> token in the title names the case outright and survives any rename — the reporter and the JSON import both read it. The JUnit road does not read it yet.

What you can undo

Action	Reversible?
Delete a run	Yes — recoverable for six months, then purged for good. Test cases it created survive either way.
Approve or reject a queue entry	Yes — the audit log records every change, and a change can be restored from it.
Revoke a token	No. Mint a new one.

If something goes wrong

Three things look like failures and are not:

You see	What it means
Asked for a sign-in link, no email came	The address is not on the invite list — see the note at the top. Reply to your invite and it will be added.
`plune: the API token was refused`	The token was revoked or has expired (they live 90 days). Mint a new one in Settings → API tokens.
`plune: 0 accepted · N written to .plune/pending-results.jsonl`	The platform could not be reached or refused the run; nothing is lost. The line above it says why, and `plune run report` sends the file once it is fixed.

Everything else — write to [email protected]. It is read by the people who build the platform, and each report becomes a row in the beta punch-list with a severity and a decision you will hear back about. Include the CLI version (plune --version), the exact command, every plune: line it printed, and the run id from the dashboard if there is one.