One queue entry, with its comparisons
const url = 'https://beta-api.plune.ai/v1/review-items/2489E9AD-2EE2-8E00-8EC9-32D5F69181C0';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/review-items/2489E9AD-2EE2-8E00-8EC9-32D5F69181C0 \ --header 'Authorization: Bearer <token>'The same object the listing returns, assembled by the same code — so a client holding an id never sees a different shape from one reading the page. An item of another project and an id that was never issued get the same refusal, word for word.
Authorizations
Section titled “Authorizations ”Parameters
Section titled “ Parameters ”Path Parameters
Section titled “Path Parameters ”Responses
Section titled “ Responses ”The entry
A review item plus enough of what it points at to be judged without opening it.
object
Present on an entry disputing a RESULT. Exactly one of resultId, proposedCase and discoveredTest is present: an entry with two asks two questions at once, and one with none asks nothing.
Present on an entry proposing a new case. Mutually exclusive with the other two.
object
Content-derived identity; the dedup key.
object
What the pre-review checks found, written before the proposal was queued (#1289). It marks the proposal. Only placeholder stops anything: a proposal whose title, steps or expected result still holds {{...}}, [TODO]/[TBD]/[FIXME]/[XXX] (or the same in <...>) or a run of three or more underscores cannot be approved (409 naming the places), and that check is read off the reviewer’s edited version when there is one. Absent means nothing was found.
object
Where the rule is explained.
object
Absent means never executed — NOT “no result yet”. blocked: no answer from the target.
What a match resolves through. Absent is a normal proposal, not a degraded one: an agent that names no key gets an entry with no comparison, which is exactly what a genuinely new case gets.
An identifier another tool already uses for this test, so a report can find its case without anyone typing a Plune id. The order of kind is load-bearing: it is the ranking that decides which key wins when several match different cases.
object
The reviewer’s corrected version of the proposal (#1878), beside proposedCase, which stays what the agent said. Present only after an edit; approving the item makes the case from it. Left off the page of the listing (editedBy and editedAt stay).
object
The user id of whoever saved the version in editedCase.
When editedCase was saved.
Present on an entry reporting a test the caller RUNS and this project has no case for. Mutually exclusive with the other two.
object
The identity. Order does not matter — the server ranks them and the highest-ranked kind is what deduplication reads, so two adapters sending the same keys in a different order do not produce two entries about one test.
An identifier another tool already uses for this test, so a report can find its case without anyone typing a Plune id. The order of kind is load-bearing: it is the ranking that decides which key wins when several match different cases.
object
The reporter that found it, e.g. playwright.
Where the test lives, e.g. e2e/checkout.spec.ts:12. Required while everything descriptive is optional: an approved discovery becomes an automated case, and that shape needs a spec to point at.
What it did on this run, in the reporter’ own word.
The run that turned it up, once stored.
changes_requested (#1276): a reviewer asked the author for changes (changeRequest says what). It is the item’s own state, not a mark on a reviewer: it cannot be approved until the author re-submits, which puts the item back to pending.
Raised by every re-submission; absent is 1. An approval counts only for the revision it was given on.
The user ids asked to review the item - the project’s default reviewer, when they could be asked.
The default reviewer who was NOT asked because they no longer have the right to review - the list says who was passed over.
Who approved which revision; the policy’s approvalsRequired counts those of the current revision.
object
The open request for changes (present with state: changes_requested); the author’s re-submission clears it.
object
Present on every item rejected after R4, and absent forever on rejections stored before it — those are never migrated and must keep reading without error. An item that is pending or approved usually has none, but MAY still carry one: a rejection returned to review keeps the pair in the row as a draft, and the next move to rejected must supply it in the request anyway. Read it as “meaningful only while state is rejected”, not as “absent otherwise”.
The disputed result’s own status — the «now» beside previousRun.
Judge questions; absent when none judged.
Only on an entry carrying proposedCase whose keys matched a case here.
object
Which key established the match. Named because when several keys point at different cases exactly one is shown, chosen by the kind ranking, and an unexplained choice reads as arbitrary.
object
Empty means the proposal matches the existing case field for field.
One difference between a proposal and the case it was matched to. The list is FLAT and ORDERED rather than keyed by field, because order is part of what it means — the server decides it so that two reviewers reading the same entry see the same card.
object
Only what a reviewer reads while deciding. Run identifiers are excluded on purpose: they differ on every regeneration and would report a change every single time.
The value on the existing case, absent when it records none. Untyped on purpose — a string for title, a list for steps; the two sides of steps do not even share a shape in storage, which is why they compare as one block rather than step by step.
The value the proposal carries. Same typing note as before.
Only on an entry carrying resultId for a test that has run here before.
object
What happened to the test.
Whether it behaved as expected. Independent of statusChanged: a test can stay just as unsuccessful and still move from broken to failed, and that is exactly what changes what a reviewer does next. Both axes are reported always, changed or not, so that “the state moved and the behaviour did not” is never something to infer from a missing field.
Example
{ "schemaVersion": 1, "id": "6f1c2b3a-0000-4000-8000-0000000000b1", "resultId": "6f1c2b3a-0000-4000-8000-0000000000e1", "state": "pending", "note": "Passed only on the retry — a flaky selector or a real race?", "createdAt": "2026-09-16T09:12:04.151Z", "updatedAt": "2026-09-16T09:12:04.151Z", "testCaseId": "6f1c2b3a-0000-4000-8000-0000000000c1", "testCaseTitle": "Checkout — empty cart @smoke @checkout", "runId": "6f1c2b3a-0000-4000-8000-0000000000d1", "runAt": "2026-09-16T09:12:04.151Z", "status": "passed", "outcome": "expected", "passed": 0, "failed": 0}No / invalid token or session
Not found or not yours — the two answer identically
object
Example generated
{ "error": "example"}