What the platform keeps

Five records carry everything. Two describe what you test, two describe what happened, and one is where the two meet for a human decision.

What you test

Project — the boundary. An account has exactly one, and every read is scoped to it, so there is no cross-project query to get wrong. Two projects means two accounts.

Suite — a node of the tree, and the tree is a filesystem: a node’s kind is folder or suite, a folder holds folders and suites, a suite holds cases, and GET /v1/suites answers with the tree rather than a list. Each node has a position among its siblings, an optional description, and — when an import made it from a spec’s path — the file it stands for, so the next import finds it by the file even after a rename. A node that still holds something refuses to be deleted (409) instead of taking it with it. The rule and the ways round it are on Organizing cases.

Test case — the durable unit. It has a title, a body, and any number of external keys: the identifiers other tools already use for the same test — a Playwright test id, a JUnit classname, a Cairn scenario. Those keys are what let a report from a runner that has never heard of Plune find its case, which is what GET /v1/test-cases/resolve does, up to 500 at a time. A key is at most 1024 characters; a test name longer than that is shortened by the reporter before it becomes one — the head of the name plus a digest of the whole, so the same name gets the same key on every run — and the reporter says so. Beside them it carries a description and a precondition (the text — they move its version), a priority out of five, a position among the cases of its suite, and tags — which are not a field of their own but the @names read out of the title. The table the list filters by is an index derived from titles, never the other way round; The fields of a case has the rules.

What happened

Run — one execution of many tests, from any source: the Plune CLI, a JUnit report, a Cairn session. A run is opened, filled with results, and finished; its summary is five counters — passed, failed, broken, blocked, skipped — plus two numbers that matter more than they look:

• unmapped — results that matched no case. Work arrived that nothing accounts for.
• discovered — tests offered to the queue because this project has no case for them.

Result — one test’s outcome inside one run, with its duration, its error, and its link back to the case. GET /v1/results/{id}/history walks the same test across every run it appeared in, which is the question a flaky test is usually answering.

Where they meet

Review item — a queue entry waiting on a person. It is the subject of its own page, because it is the one record whose whole reason for existing is that the platform refuses to decide on its own.

What a delete takes

Deleting a run is recursive over what the run produced, and stops there:

Goes	Stays
The run	Test cases — including ones an approval created from it
Its results	The audit log of what happened
Queue entries it produced — proposals and disputes, whatever their state	Suites

Six months, then for good

A deleted run is recoverable for six months (by the application owner, not by you — you already decided). After that a nightly sweep removes it permanently. The window is invisible from the screen, which is why the button asks first.

Cases survive on purpose

A run is one evening’s work; a case is the thing you keep. Deleting the run that first proposed a case would quietly undo a human’s decision to accept it — so created_test_case_id does not cascade, and you can rerun that case as many times as you like afterwards.