Vocabulary
What a Credda run can end as
Every finished run ends as exactly one of these 11. 6 count as a success. Read out of core/packages/shared/src/states.ts.
6 of 11
terminal outcomes count as a success, decided by the engine function the console, CLI and check run share
core/packages/shared/src/states.ts
01The vocabulary
Every terminal outcome, with the engine’s own note.
- REPRODUCED_AND_DIAGNOSEDSuccess
A failure was reproduced, evidence was captured, and a cause was established from it. No code was changed.
- REPRODUCED_NOT_DIAGNOSEDSuccess
A failure was reproduced and evidence was captured. No cause was established from it, and no code was changed.
- CONTRADICTS_SPECIFICATIONSuccess
The reported behaviour occurred, and the repository's own currently-green test suite asserts it. No defect was established, and no cause was named, because nothing here says the code is at fault. It is NOT an abstention. The run published a report: it reproduced the behaviour, located the assertion that specifies it, and executed that one test to prove it passes. Escalating that to a human is as correct an ending as staying silent, and the report says in as many words that if the reported behaviour is wrong then the specification is wrong too.
- NO_CHANGE_REQUIREDSuccess
A reproduction ran, asserted the reported thing, and the reported thing did not happen. A success.
- NO_RUNNABLE_CHECKNot a success
Nothing runnable could be derived from the report. Not a claim about the repository, and never a success.
On a pull request this reads: No runnable check: the report could not be turned into a command
- INCONCLUSIVENot a success
Something ran and did not settle the question.
- VERIFIEDSuccess
A patch was written, applied, and independently verified against a failure demonstrated before it existed. VERIFIED and PARTIALLY_VERIFIED both reach READY_FOR_REVIEW, and the state alone cannot tell them apart, which is why `outcomeForState` takes the mechanical verdict as its second argument. Neither says the change was merged. Credda proposes; a human is the merge authority, and there is no merge function anywhere in the connection layer.
- PARTIALLY_VERIFIEDSuccess
A patch was written, applied, and independently verified against a failure demonstrated before it existed. VERIFIED and PARTIALLY_VERIFIED both reach READY_FOR_REVIEW, and the state alone cannot tell them apart, which is why `outcomeForState` takes the mechanical verdict as its second argument. Neither says the change was merged. Credda proposes; a human is the merge authority, and there is no merge function anywhere in the connection layer.
- PATCH_REJECTEDNot a success
A patch was written and verification threw it away. Nothing was left behind in the workspace: the run restores the pre-patch snapshot first.
On a pull request this reads: A fix was written and independent verification rejected it
- CANCELLEDNot a success
On a pull request this reads: Cancelled before a result was established
- ERROREDNot a success
On a pull request this reads: Credda errored, so nothing here is a result
02Two that get misread
A run that did not succeed is not a verdict on your repository.
NO_RUNNABLE_CHECK is not a success. Credda could not turn the report into a command: a fact about this product’s reach, never a verdict on your repository. Nor is PATCH_REJECTED, where a fix was written and independent verification threw it away. Both appear on /evidence and /benchmark, carrying the result of one run.