This case’s past evaluations, newest run first
const url = 'https://beta-api.plune.ai/v1/test-cases/2489E9AD-2EE2-8E00-8EC9-32D5F69181C0/results';const options = {method: 'GET', headers: {Authorization: 'Bearer <token>'}};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request GET \ --url https://beta-api.plune.ai/v1/test-cases/2489E9AD-2EE2-8E00-8EC9-32D5F69181C0/results \ --header 'Authorization: Bearer <token>'Two ways a Result reaches here. A CLI run attaches one when it carries an eval whose id matches the case’s evalId (ADR 0010); approving a Cairn proposal attaches the verdict the proposing run already measured, so a case born that way has history from the start.
Authorizations
Section titled “Authorizations ”Parameters
Section titled “ Parameters ”Path Parameters
Section titled “Path Parameters ”Responses
Section titled “ Responses ”The case’s history
object
One past evaluation of a case, derived from the Result stored at ingest.
object
The Result — pass it to POST /v1/review-items.
The verdict. passed/failed count an eval’s assertions, and a reporter’s result has none — read the verdict here. Stability skips skipped and blocked: neither ran the check.
The version of the case this result was produced against (#1255) - GET /v1/test-cases/{id}/revisions/{version} shows the content it tested, whatever the case holds now.
Judge questions answered true across this result (BINEVAL). Both verdict counts are absent when nothing judged question-by-question — distinct from “judged, all passed”.
The result’s finished files, oldest first, as on a run’s results list (#959) — present only when there is one. Read for the whole page at once, so a client shows a result’s screenshots without a request per row.
A file of a result, everything but its bytes (ADR 0040, ADR 0041). Only a finished file is ever shown: one that was announced with uploads and not yet completed is in no list.
object
The last segment of the name it was uploaded with, cleaned of credentials as a text is.
In the database (storage: db): image/png, image/jpeg, image/webp, application/json or text/plain — a log is text/plain. In the bucket (storage: bucket): the media type it was announced with, lower case and without parameters, any type.
Bytes as kept: in the database a picture at most 2 MiB and a text at most 512 KiB, counted after its credentials are cleaned, so it can differ from what was sent; in the bucket the size that was announced and found there.
db: Plune keeps the bytes, GET /v1/files/{id} returns them. bucket: they are in the project’s own bucket, and GET /v1/files/{id} answers 409 in_bucket (the way to read them is GET /v1/files/{id}/link).
How stable the case has been, measured as transitions INTO failure ÷ runs — not a failure rate. The two are different diseases: an eval that fails every time is broken (0 transitions, stable), one that alternates is a coin toss. Read runs/failures alongside level, or a permanently broken case looks fine.
object
Transitions into failure ÷ runs. 0 for a history of ≤ 1.
Runs the score is based on — a score over 2 runs means little.
Example
{ "results": [ { "status": "passed", "files": [ { "storage": "db" } ] } ], "stability": { "level": "stable" }}No / invalid token or session
Not found or not yours
object
Example generated
{ "error": "example"}